AI 研发实验该怎么做：验证的不是代码产量，而是闭环能力

如果一家软件公司准备认真做 AI 研发实验，我通常会建议：先别急着问“哪个模型最强”，也别先问“能不能完全不看代码”。

更应该先问的是：

我们到底想验证什么？

这是一个看起来很简单、但很多实验一开始就答错的问题。

很多团队做 AI 研发实验时，默认的衡量方式是：

• 写了多少代码
• 自动完成了多少功能
• 连续跑了多久
• 人工介入少不少
• 总成本高不高

这些指标不是没用，但如果把它们当成核心指标，实验很容易走偏。因为它们更多测到的是产量，而不是研发能力。

而软件研发真正要验证的，从来不只是“AI 能不能写出来”，而是：

AI 能不能在需求、实现、测试、验收和知识沉淀之间形成一个可靠闭环。

如果不能，产量再高，也只是一次漂亮的冲刺；如果能，哪怕一开始产量不高，也说明这套体系有长期价值。

---

1. 为什么“代码产量”是一个危险的主指标

产量很好看，尤其适合做演示。

比如：

• 一周内扩了多少功能
• 代码行数从几千变几万
• 新增多少页面、接口、测试
• 一个 Agent 连续工作了多长时间

这些数字天然有冲击力，管理者也容易理解。

但问题是，代码产量有三个天然偏差。

1.1 它鼓励系统追求“多做”，而不是“做对”

一旦团队把产量放在首位，AI 很容易朝下面这些方向优化：

• 更快生成代码
• 更少停下来确认边界
• 更倾向于“先做出来再说”
• 更倾向于补表层测试让结果看起来完整

这会让实验很热闹，但不一定很扎实。

1.2 它会掩盖返工成本

很多 AI 产出看起来很快，真正贵的是后面的事情：

• 第二轮需求变动后是否还能稳住
• 旧功能会不会被新功能打坏
• 新人接手时是否看得懂
• 下一轮迭代时是否需要大面积返工

如果这些成本不计入实验，产量指标就会显著失真。

1.3 它无法反映组织学习

研发实验真正有价值的部分，不只是交付了一个样品，而是团队有没有通过这次实验学会：

• 哪类任务适合 AI
• 哪些地方必须人工介入
• 哪些测试最关键
• 哪些知识必须提前结构化
• 哪种任务拆分方式最有效

这些学习如果没有沉淀，下一次实验就还会从头踩一遍坑。

---

2. 什么叫“闭环能力”

我这里说的闭环，不是一个抽象口号，而是指一件具体的事：

一个任务从提出，到实现，到测试，到验收，到经验回收，能否形成自洽、可追踪、可复用的循环。

如果一个实验真的要有方法论价值，我认为至少要看五个闭环。

2.1 需求闭环

看什么？

• 需求是否被充分澄清
• 歧义是否能在过程中被及时暴露
• 暴露出的歧义是否被回写到文档或系统
• 后续任务是否继承了这些修正

很多团队会低估这件事。实际上，需求闭环往往是实验成败的第一分水岭。

AI 不是怕复杂需求，AI 更怕模糊需求和漂移需求。

2.2 实现闭环

看什么？

• 实现方案是否与需求边界一致
• 中途发现问题后，是否能调整而不是硬凑
• 多轮修改后，代码结构是否仍然保持可维护
• 一个改动是否会牵出意料之外的连锁副作用

实现闭环关注的不是“有没有写出来”，而是“有没有在变化中持续写对”。

2.3 测试闭环

看什么？

• 测试是否覆盖最关键风险
• 测试失败时，AI 是否能真正定位原因
• 历史 bug 是否被转化为回归测试
• 测试策略是否随着需求边界更新而同步演进

如果测试闭环不成立，实验里的“通过”通常没有太大说服力。

2.4 验收闭环

看什么？

• 验收标准是否清晰且可执行
• 标准变化后，是否有机制同步到实现和测试
• 人工 review 是否集中在高价值节点，而不是被迫到处补洞
• 最终交付是否真的满足业务目的，而不是只满足形式标准

一个成熟实验的目标，不是消灭人工验收，而是把人工验收放在最有价值的位置上。

2.5 知识闭环

这是最容易被忽略、但我认为最重要的一环。

看什么？

• 这次实验学到了什么
• 哪些方案被证明有效
• 哪些失败模式反复出现
• 哪些知识应该沉淀成规则、模板、回归用例或知识卡片
• 下一轮任务能否直接复用这些成果

如果一个实验结束后，只有代码，没有知识回收，那它对组织的长期价值非常有限。

---

3. 一个更合理的 AI 研发实验，应该怎么设计指标

如果让我给一家软件公司设计 AI 研发实验指标，我会把指标分成四类。

3.1 效率指标：可以看，但不能独大

• 单任务完成时长
• 人工介入次数
• 需求到交付的总周期
• 自动化完成的工作量占比

这些指标重要，但只能说明“快不快”。

3.2 质量指标：决定实验有没有可信度

• 核心测试通过率
• 回归缺陷数量
• 修复一个问题引入的新问题数量
• 多轮修改后的结构稳定性
• 需求变更后的适应能力

这些指标说明“稳不稳”。

3.3 学习指标：决定实验是不是一次性的

• 新发现的规则是否被记录
• 失败原因是否结构化归档
• 高价值提示词、流程模板、操作规范是否沉淀
• 历史经验是否影响后续任务表现

这些指标说明“会不会越做越强”。

3.4 系统指标：决定 AI 能不能真正进入研发体系

• 知识库是否持续更新
• 任务分工是否清晰
• 审批点是否合理
• 状态是否可追踪
• 不同 Agent / 工具 / 环节之间是否能协同

这些指标说明“能不能规模化”。

---

4. 为什么我建议从“小而真实”的任务开始，而不是从“简单 demo”开始

做 AI 实验，很多人会倾向于挑一个最简单的 demo 任务，觉得这样成功率高。

但我更倾向于另一种标准：

任务可以小，但必须真实。

什么叫真实？

• 它真的对应一个用户或业务问题
• 它真的有边界条件和历史包袱
• 它真的需要测试和验收
• 它真的会暴露组织流程中的问题

只有这样的任务，才能测出团队真正的摩擦点。

太假的 demo 往往只会验证一件事：模型很会做 demo。

这对组织设计帮助不大。

---

5. 我会怎么判断一个实验是不是“做对了”

不是看最后代码多漂亮，而是看实验结束后，团队有没有得到下面这些东西：

第一，一套更清晰的人机边界

知道：

• 什么事情可以放心让 AI 直接做
• 什么事情必须由人定义边界
• 什么节点必须人工审批

第二，一套更清晰的任务分解方式

知道：

• 什么任务适合整体下发
• 什么任务必须拆成多个阶段
• 什么任务应该由不同角色或不同 Agent 协作完成

第三，一套更清晰的测试策略

知道：

• 哪些测试最能挡住真实风险
• 哪些历史 bug 最值得优先固化为回归用例
• 哪些“跑绿”其实没有意义

第四，一批真正沉淀下来的组织知识

知道：

• 哪些模式会反复失败
• 哪些输入会显著提升成功率
• 哪些流程可以标准化
• 哪些系统信息必须结构化才能让 AI 用起来

如果一个实验做完后，这四类东西都更清楚了，那即使它没有产出惊人的代码量，我也认为它是成功的。

反过来，如果代码写了很多，但团队仍然不知道下一次应该怎么做得更稳，那它更像是一场表演，不像一套方法论验证。

---

6. 这也是为什么“AI 研发实验”最后一定会通向研发中枢

只要你认真做两三轮实验，就会很快意识到：

问题逐渐不再是“模型会不会写”，而变成了：

• 历史知识放在哪里
• 当前状态怎么同步
• 谁来维护任务上下文
• 测试经验怎么回收
• 被否决方案怎么避免反复重提
• 哪些规则应该沉淀成组织资产

一旦问题走到这一步，你就已经不再是在设计一个实验，而是在设计一个系统。

也就是我一直在说的那件事：

真正有价值的 AI 研发，不会停留在“让 AI 参与几个任务”，而会继续走向“为 AI 建立一个研发中枢”。

因为没有中枢，闭环就只能靠人肉维持；而只要规模稍微一上来，人肉闭环就一定会断。

---

7. 结语

如果你准备做 AI 研发实验，我的建议很简单：

别把“写了多少代码”当成首要答案。

真正值得验证的，是这套体系能不能把需求、实现、测试、验收和知识沉淀连成闭环；是这次实验结束后，组织是不是比实验开始前更知道如何和 AI 协作；是下一次任务来时，团队能不能在上一次的基础上继续往前走，而不是重新开始。

代码产量说明的是 AI 有多忙。

闭环能力说明的是 AI 能不能真正进入你的研发系统。

两者相比，后者才决定上限。

---

如果说前两篇文章讨论的是“为什么一次实验不够”和“为什么中间差了一个 JARVIS”，那么这一篇更想回答管理层最实际的问题：AI 研发实验到底该如何设计，才不会只得到一组好看的产量数字。