Personal Blog
个人博客共 38 篇
记录 AI 如何从工具走向系统。持续观察 AI 驱动下的软件工程、研发自动化与组织协作演化。
AI 写代码越来越快，为什么交付还是反复返工？
AI Coding 让代码生成越来越快，但交付中的返工，往往不是从代码阶段才开始。更早之前，产品意图、体验表达、工程约束和验证标准，已经在不同产物之间被反复交接、解释和补全。 AI 时代真正需要重构的，可能不是某一份 PRD 或设计稿，而是产设研围绕同一个交付项连续协作的方式。
Signal #14：别只看出码率了，AI Coding 的指标正在变
代码生成越来越多，不代表研发效率一定同步提升。 当 AI IDE 和 Coding Agent 开始进入真实研发流程，企业需要的，已经不只是“出码率”这一类代码层指标。
当大厂人开始等裁员补偿，组织真正失去的是什么
等裁员补偿不是错。对很多个体来说，这是不确定环境下非常现实的风险管理。 但当一个组织里越来越多人开始等待裁员补偿，它就不再只是个人选择，而是一种组织信号。 真正值得警惕的，不是有人在等，而是一个组织让越来越多人觉得：等待比行动更划算。
新器物志｜账户先生说省下了二十个人
《新器物志》第二篇。 万色坊来了一只会算人的算盘。它算得很清楚，只是不知道颜色什么时候才算入了骨。
新器物志｜百工镇来了会写字的笔
《新器物志》第一篇。 百工镇来了一支会替人落字的笔，后来大家都学会了说体面话，却越来越说不清自己的意思。
Signal #13：AI Coding 的下一站，是失败与反馈链路的自动化
过去讨论 AI Coding，很多注意力都放在“AI 能不能写出第一版代码”上。 但本周几个产品变化放在一起看，一个更值得记录的变化开始出现：Agent 正在进入代码生成之后的失败、反馈与返工链路。 AI Coding 的下一阶段，可能不只是继续追求首稿生成得更快，而是把 CI 失败、Review 反馈、Issue 分诊和工单状态，变成 Agent 持续推进任务的输入信号。
别让 Skill 变成新的文档债：从经验沉淀到行为回归
写给 Agent 看的经验，如果不能被测试，最后也会变成新的文档债。 Skill 的价值，不只在于它能沉淀多少经验，而在于它能否稳定影响 Agent 的行为。当 Skill 开始成为 Agent 执行链路里的核心资产，我们真正要问的就不再只是“如何写好 Skill”，而是“如何测试 Skill”。
AI 让所有人都能干一点别人的活，但这不代表专业消失了
AI 正在让很多岗位获得跨职能的局部产出能力：产品能搭页面，设计能做可运行原型，业务能做数据看板，研发也能更早参与需求澄清、原型验证和交互讨论。 所以，岗位边界确实变模糊了。 但一旦这些产物进入真实企业系统，权限、组件、数据、仓库、环境、验证和责任这些边界会重新显现出来。 这篇文章想讨论的是：AI 到底模糊了什么，又没有模糊什么。
对话不是工作台：AI Agent 真正缺的不是聊天窗口
当 Agent 只是回答问题时，Chat 是最自然的入口。 但当 Agent 开始理解目标、调用工具、修改系统、验证结果，真正需要承载的就不再是一串对话，而是一个可以被组织、跟踪、验证和接管的任务空间。 真正的变化，不是 Chat 消失，而是 Chat 从工作台退回入口。
AI 到底能不能从零写软件？ProgramBench 和 RepoZero 给出了两种答案
前段时间，我写过一篇关于 [ProgramBench](https://arxiv.org/abs/2605.03546) 的文章《[Meta 做了个实验：让 AI 从零重建软件，结果全军覆没](https://mp.weixin.qq.com/s/tc0BZeWCgOa2nUr09s9Gqg)》。它讨论的是：只给一个程序和文档，AI 能不能从零重建一个真实软件？ 最近，[RepoZero](https://arxiv.org/abs/2605.07122) 又从另一个角度切进了同一个问题：如果给 Agent API 规格、隐藏测试和可验证的 oracle，它能不能从零复刻一个仓库的行为？ 这两篇论文看起来像是在给出不同答案，但我更愿意把它们放在一起看：它们不是简单的互相反驳，而是在共同说明一件事——AI Coding 的瓶颈，正在从“会不会写代码”，转向“任务能不能被表示，行为能不能被验证，系统能不能在反馈中收敛”。
AI 会写代码之后，企业还需要什么样的新人？
最近 HR 找我聊了一个问题：在 AI 快速发展的背景下，今年的校招生培养方案应该怎么设计？ 这个问题看起来是在问“新人怎么培养”，但我听到的其实是另一个问题： 当 AI 已经可以写代码之后，企业还需要什么样的新人？
Signal #12：Coding Agent 正在拥有自己的运行时｜AI Coding 的界面，不再只是聊天框
最近一周，VS Code、GitHub Copilot、Cursor、OpenAI Codex 都出现了一类相似变化：它们不再只是把 Agent 放进聊天框或 IDE 插件里，而是在为 Agent 提供独立的运行空间、会话视图、远程环境和过程控制能力。 这意味着，Coding Agent 正在从“被调用的功能”，变成“可运行、可观察、可恢复、可管理的执行单元”。 AI Coding 的核心界面，可能不再只是编辑器里的聊天框，而会逐渐变成一个 Agent 执行控制台。
AI 会写 Native 之后，跨端框架还重要吗？
AI 时代，跨端框架的价值不会消失，但它的价值来源正在变化。 过去，企业选择 RN、Flutter、小程序、Hybrid，很大程度上是为了“一套代码，多端运行”，本质是在降低人力成本和重复开发成本。 但当 AI 开始可以生成 Swift、Kotlin、Java、Objective-C、Compose、SwiftUI 代码之后，“写两端代码”这件事的成本确实下降了。于是一个新的问题出现了：如果 AI 已经能写 Native，企业还需要跨端框架吗？ 我的判断是：AI 会削弱跨端框架过去“节省人力”的叙事，但不会消灭跨端。因为企业真正要优化的，从来不只是代码量，而是表达、协作、验证和长期维护的系统成本。
AI 时代，组织最该警惕的不是人才离开
人才离开往往不是问题的开始，而是问题的结果。 在更早之前，组织的反馈系统可能已经开始变慢：识别新能力变慢，授权变慢，资源配置变慢，激励兑现变慢，把个人实践转成组织资产也变慢。 AI 时代真正值得警惕的，不只是人才有没有留下来，而是组织能不能及时看见、承接并放大那些正在出现的新能力。
别急着说 AI Native 组织，先让关键链路形成闭环
AI Native 不只是用了更多 AI 工具。它更深层的变化，是公司运行方式是否开始被 AI 重新组织。 对从零开始的创业公司来说，AI Native 可能是一种“出生方式”；但对大多数既有企业来说，它更可能先表现为一种“链路改造方式”。 组织不是一开始就被整体重写的。它往往先从一段关键链路的信息流、执行权、验证方式和反馈闭环开始变化。
Meta 做了个实验：让 AI 从零重建软件，结果全军覆没
Meta 最新论文 ProgramBench 提出了一个极具挑战性的 AI Coding Benchmark： 不给源码，只给程序和文档，让模型从零重建完整软件系统。 结果是： 200 个真实项目、9 个顶级模型、完整解决率 0%。AI Coding 的问题，开始从“代码生成”进入“系统重建”。
AI Coding 别等写完再测：从输入到黑盒验收的验证分层
当 AI Coding 开始从“生成代码”走向“参与交付”，验证就不能再被理解为最后加上的一道测试关卡。 在端到端自动化里，验证需要被拆成一套分层系统：前面验证输入是否可执行、任务是否被稳定表达；中间验证 Agent 是否真的完成了目标变更、代码是否能进入工程体系；后面再验证交互、视觉、回归风险与人工验收点。 只有当这些验证层次被组织起来，AI 研发自动化才可能从“能生成代码”，走向“能稳定交付结果”。
AI Coding 的上半场是生成，下半场是验证？AI 代码被采纳，不代表需求可验收
AI Coding 最先降低的，是写代码的成本。 但它很快带来另一个问题：代码生成得越快、越多，谁来确认这些实现结果是可接受的？ 很多团队最早感受到这个问题，不是在生成阶段，而是在 Review 阶段。 AI 可以很快生成一大段代码，但如果每一次都要研发人员逐行读完，再判断有没有问题、能不能合入，那种体验并不轻松，甚至有点反人性。 这意味着，AI Coding 的上半场，是让代码可以被生成、被采纳。 AI Coding 的下半场，是让生成结果可以被验证、被修正，并最终进入稳定的工程闭环。
从工单到交付：数字员工开始承接一类 L0 需求
很多 L0 需求真正耗时的，并不是编码本身，而是围绕交付产生的一整套工程动作：查工单、绑分支、拉仓库、提 PR、跑部署、做验证。 数字员工的价值，也不只是帮忙改几行代码，而是开始把这类需求从工单到交付的完整链路接过去。
AI 时代，不是所有业务诉求都该进入研发系统
AI 时代，真正变化的，不只是研发如何更快写代码，而是业务诉求不再默认都要先翻译成研发需求。 有些问题应该先被澄清，有些应复用已有 Skill，有些适合由 NoCode 吸收，只有其中一部分，才真正需要进入研发系统。 因此，在“需求分层”之前，实际上先出现了一层更上游的分流机制：业务诉求的路由层。
All You Need Is Skill：端到端自动化的 MVP 闭环是如何跑起来的
这篇文章不讨论端到端自动化的最终形态，而是回到 MVP 阶段，讲清楚我们如何用 Skill 把多源输入、项目知识、任务建模、代码生成和 Review 组织成一个真正可运行的系统。它不是终局，却第一次让闭环成立。
当大家开始谈 Harness 时，我们真正该理解的是什么？从 Representation 到 Harness，再到 System，AI 研发正在进入新的一套系统分层
当 AI 开始真正“干活”，问题就不再只是模型够不够强，而是任务是否被稳定表达、执行是否能够持续、结果是否能够进入系统闭环。 最近业界开始频繁讨论 Context、Harness、Environment Engineering，这些词看似分散，背后其实指向同一个变化： AI 落地的竞争，正在从模型能力，走向系统组织能力。
90% 出码率是怎么来的？我们如何把研发任务组织成可运行的自动化链路
90% 出码率，不是因为 AI 已经可以直接“理解需求”，而是因为需求在进入执行前，先被组织成了系统可以接住的任务。 真正开始成立的，也不是一次更成功的 AI Coding，而是一条从多源输入、任务表达、执行编排到验证闭环的自动化链路。 如果说上一篇回答的是“链路开始成立了吗”，那这一篇要回答的，是“这条链路到底是怎么被搭起来的”。
AI 正在制造一批“伪专家”｜当“会讲”变得越来越容易，组织该如何重新判断谁值得被相信
生成式 AI 放大的，不只是效率，也不只是表达能力。 它真正带来的一个新问题是：当“像专家一样说话”变得越来越容易，组织必须重新判断，谁只是讲得清楚，谁真正做成过、跑通过，并且还能再做一遍。 当“看起来正确”变得越来越廉价，真正跑通过的经验，反而会重新变贵。
出码率到 90% 之后，我们真正验证了什么？端到端自动化的第一次真实落地
端到端自动化的关键，已经不再是单点生成能力，而是研发任务能否在真实业务约束下，被稳定地表达、执行与验证。我们真正验证的，不是一段代码能不能被生成，而是一条面向真实业务研发的端到端自动化链路，是否已经开始成立。
当网站开始为 Agent 提供接口，Web 的交互边界正在改变｜从 WebMCP 看网页如何从“界面”走向“能力入口”
当网站开始主动向 Agent 暴露可调用能力时，网页的角色就开始变化了。 它不再只是一个等待人类点击的界面，也开始成为一个可以被理解、被调用、被编排的能力入口。 WebMCP 的意义，不在于它今天已经多成熟， 而在于它让一件事情变得非常具体： Web，正在为 Agent 重写交互接口。
为什么 Spec 不是终点，而只是中间产物？软件研发正在从 Spec 驱动，走向表示驱动（RDD）
当执行不再稀缺时，软件研发的核心问题不再是“如何实现”，而是“如何让任务被系统准确表达”。 Spec 并不能解决这个问题，它只是一个开始。
当 GUI 让位于 Agent，软件为什么走向“系统”
软件工程的变化，很少从某一个具体技术点开始显现。 更多时候，是从一些具体的使用体验中，逐渐累积出来的。 当这些变化被放在一起看时，软件的形态，开始呈现出不同的方向。
为什么 PRD + 设计稿，无法支撑 AI 时代的研发协作？当 AI 开始参与研发流程：产设研协作可能会如何变化？
随着 AI 开始参与软件研发流程，一些变化正在逐渐显现。 在实际推进研发自动化的过程中，我们发现，影响并不只发生在“代码生成”这一层，更早出现在需求、设计与实现之间的协作方式上。 这篇文章基于一次真实的企业实践，尝试讨论一个具体问题： 当执行者开始从人扩展到系统时， 产设研之间的协作，是否需要重新定义？
当 AI 开始参与开发：软件研发为何会走向 Agent 协作｜从人类协作到 Agent 协作系统
当执行者开始改变之后，软件研发的协作对象也在发生变化。 从人类之间的分工，到人类与 Agent 的协同执行，一种新的研发协作结构正在逐渐形成。
信息越来越多，但我们真的更理解技术了吗？| 从信息流到主题结构
技术变化很少直接来自信息本身， 它往往是在主题不断聚合之后才逐渐显现。
从设计稿到生产代码：小红书如何用多阶段流水线自动化客户端开发
从设计稿到生产代码：小红书如何用多阶段流水线自动化客户端开发 📋 论文信息 - 标题: Production-Grade AI Coding System for Client-Side Development - 作者: Ruihan Wang, Chencheng Guo,
AI 时代，重新理解成长｜一份持续 260 期技术小报背后的技术观察
从持续 260 期的技术小报，到 AI 时代的软件工程观察。 这篇文章记录了一段技术人与技术变化共同成长的过程： 从整理信息，到观察趋势，再到参与 AI 研发自动化实践。 也是我在 AI 时代重新理解"成长"的一次回望。
当 AI 开始参与开发之后，软件工程正在重新学习“如何表达”
软件工程的下一阶段，不是更快地实现，而是让理解成为结构。 ——为什么端到端自动化最终会走向中间表示（IR）
问题也许不在 AI：软件研发开始适应新的执行者
当 AI 开始承担越来越多执行工作时，软件研发真正发生变化的，或许并不是效率本身，而是“困难出现的位置”。这篇文章尝试解释一种正在出现却尚未被明确描述的现象：研发瓶颈，正在悄然迁移。
我们可能一直误解了 AI 对软件研发的影响
当 AI 开始参与开发，真正改变的或许不是效率，而是软件研发中“谁在决定事情如何发生”。
企业研发 AI 自动化能力结构框架（v0.1）：从工具增强到端到端自动化的结构路径
写在前面：当 AI 开始进入软件研发，讨论往往集中在模型能力与生成效果上。但在企业真实环境中，自动化能否成立，更多取决于组织是否具备支撑 AI 长期运行的结构能力。 本文提出一个 L1–L4 的企业研发 AI 自动化能力框架，尝试回答三个问题： + “企业当前处在哪个自动化阶段？” + “为什么多数团队难以进入下一阶段？” + “从局部提效走向端到端自动化，需要补齐哪些结构能力？” 文章结合行业趋势与实践观察，给出控制权迁移模型、自动化断点地图与能力自测视角，作为理解与讨论企业研发自动化的一种结构工具。
从 AutoGLM 到 豆包手机：GUI Agent 技术探索与对比
引言 这个月，AI Agent 赛道接连出现两个关键动作，引发了技术圈的密切关注：先是字节的“豆包手机”作为全球首款 AI 原生硬件亮相；紧接着，被誉为“首个具备 Phone Use 能力”的智谱 AutoGLM 模型宣布开源。它们共同指向并加速了一个超越内容生成的新趋势：AI