为什么一次封闭式 AI 开发实验，测不出真正的上限
为什么一次封闭式 AI 开发实验，测不出真正的上限
最近我听到一种很典型、也很有代表性的想法：找一个规模不大的软件，把需求、操作说明和测试方法先定义得足够清楚，然后把开发和测试尽量交给 AI 连续跑几天，看看它最终能做成什么样，花多少钱，踩多少坑。
我觉得这个想法并不差。恰恰相反，它是一个很自然的起点。因为只要一个团队认真思考 AI 研发，迟早都会走到这一步：先找一个边界可控的样本，做一次尽可能完整的实验。
但问题在于，很多人会把这个实验的结果，误当成“AI 研发上限”的答案。
这就不对了。
一次封闭式 AI 开发实验，最多只能测到某一类能力的上限；它测不出真正的研发上限。因为软件研发真正困难的部分，从来不只是“把代码写出来”，而是如何在长周期、不完整信息和持续变化中，把事情持续做对。
1. 这种实验到底在测什么
如果我们把任务压缩成下面这种形式：
- 选一个小型项目
- 预先写清需求
- 预先写清操作文档
- 预先写清测试方法
- 把完整任务交给 AI 执行
- 最后按结果验收
那么它主要测到的是三件事：
第一，模型的代码生成能力
AI 能不能快速补齐 CRUD、页面逻辑、数据流转、脚手架、测试样例、配置文件。
第二，任务说明的完备程度
需求写得越清楚，AI 的成功率通常越高。很多所谓“模型不行”，本质上是输入根本没定义清楚。
第三，单轮自治的可行性
也就是在一个相对封闭、变化较少的任务里，AI 能不能不被频繁打断，连续推进一段时间。
这三件事都很重要。但它们仍然只是研发能力里的一个切片。
它更接近“AI 能否完成一个项目包”，而不是“AI 能否成为稳定的研发能力”。
2. 真正的上限，卡在代码之外
一个软件项目只要稍微拉长一点，就会出现几个立刻把单次实验打穿的问题。
2.1 需求不是一次性交付物，而是持续重写的东西
很多管理者天然会想：
先把任务书写完整，再交给 AI 执行。
这当然没错，但真实研发里几乎不存在“写完就不变”的任务书。
开发过程中你会不断发现：
- 原来的边界条件没定义全
- 某个交互看起来可行，但用起来不对
- 某个测试口径和业务口径并不一致
- 某个旧约束会和新需求冲突
- 客户真正要解决的问题，和最初提的需求不是一回事
所以软件研发不是“任务定义完毕 -> 开发开始”，而更像是：
需求澄清 -> 实现 -> 发现歧义 -> 回写需求 -> 调整实现 -> 更新测试 -> 再次验收
这是一个循环，不是一个投递动作。
如果实验设计默认需求是静态的，那么它天然测不到这个循环中的大量摩擦。
2.2 测试不是写几条 case，而是建立可信的反馈系统
很多 AI 开发实验都会写测试，但“有测试”不等于“有反馈闭环”。
真正关键的是：
- 测试覆盖的是不是核心风险点
- 测试是不是会被 AI 用来“迎合”而不是验证
- 回归测试能不能在需求变化后持续成立
- 失败时能不能定位到真正原因
- 测试结论能不能被人信任
如果这些条件不满足，那么测试只是在制造一种“看起来像工程化”的安全感。
AI 很容易学会把测试跑绿，却不一定学会真正守住系统边界。
2.3 项目一旦变长，上下文就会成为主要矛盾
短任务里，AI 的上下文看起来够用。长任务里，问题会立刻出现：
- 前面说过的话后面忘了
- 之前定过的约束被悄悄改写
- 旧决定没有沉淀，新决定又重复推翻
- 修一个点时没意识到另一个模块已经依赖了旧行为
- 相同问题被多次重新讨论
这不是某一个模型独有的问题，而是长程研发任务的结构性问题。
软件越复杂，决定成败的越不是“当前窗口里写得对不对”，而是“过去的决策有没有被保存、组织、继承和调用”。
3. 为什么很多人会误以为这就已经接近上限
因为这种实验很容易给人一种“已经非常接近真实研发”的错觉。
它有需求文档，有实现，有测试，有验收，甚至还有预算统计。看起来已经很完整了。
但它仍然和真实研发之间隔着几道很厚的墙。
3.1 它默认了知识已经存在于任务书里
现实里最稀缺的不是代码，而是上下文：
- 这个模块为什么这样设计
- 以前类似问题踩过什么坑
- 哪些方案被讨论过又否掉了
- 哪些约束是技术性的，哪些是业务性的
- 哪些看似合理的改动会引发跨模块副作用
这些东西通常不在任务书里，而散落在：
- 老员工脑子里
- issue 评论里
- 提测记录里
- 代码历史里
- 各种群聊和会议里
当实验把这些全部压缩成一份“清晰任务书”时，它其实偷偷把最难的那部分工作先做掉了。
3.2 它默认了验收标准不会漂移
真实团队里，验收不是绝对静态的。随着产品理解加深，大家会调整对“完成”的定义。
这也是为什么一个功能常常会出现这种情况：
- 第一轮觉得能用
- 第二轮发现边界不清
- 第三轮发现扩展性不足
- 第四轮发现测试方法本身有问题
所以真正的研发能力，不只是把一份静态标准做到位，而是在标准不断被修正时仍然能稳定推进。
3.3 它默认了失败是局部的，而不是系统性的
单次实验里，失败常常被理解成：
- 这段代码写错了
- 这个测试没补到
- 这个需求理解偏了
但很多研发失败并不是局部错误，而是系统结构有问题：
- 任务分解方式不对
- 知识没有沉淀
- 审批点设置太少
- 工具链断裂
- 测试口径与业务目标脱节
这类失败不是换一个更强模型就能解决的。
4. 真正该验证的，不是“写了多少代码”，而是“形成了什么闭环”
如果一个团队真想摸清 AI 研发的上限，我认为指标不该围绕“产量”设计，而应该围绕“闭环”设计。
比起下面这些问题：
- AI 连续跑了几天？
- AI 写了多少行代码？
- 一次生成通过率多高？
- 最后交付了多少功能？
我更关心这些问题：
4.1 需求闭环是否成立
- 需求歧义是在什么时候暴露出来的？
- 暴露后有没有被结构化回写？
- 后续任务有没有继承这次修正？
4.2 测试闭环是否可信
- 测试是否真的覆盖核心风险？
- 回归是否能挡住历史上已经踩过的坑？
- 测试失败后，AI 能否区分“测试错了”还是“实现错了”？
4.3 知识闭环是否形成
- 本次开发学到的教训有没有沉淀？
- 下一个任务是否还能复用这些知识？
- 被否决的方案有没有被记下来，避免来回重提？
4.4 管理闭环是否可控
- 人类在什么节点介入最有效？
- 哪些环节可以放权，哪些环节必须审批？
- 失败发生时，能否快速止损、回滚、重规划？
这些指标才决定了 AI 是在“完成一次活”，还是在“形成一种可复制的研发能力”。
5. 我为什么越来越不相信“单 Agent 就能测出终局”
我并不怀疑单个强模型、强 Agent 可以在局部任务上表现惊艳。事实上，现在已经有很多任务可以做到非常好。
但只要任务进入下面这些状态，单 Agent 模式就会迅速暴露极限：
- 任务跨度跨天、跨周
- 需求会在中途变化
- 需要多种工具配合
- 需要追溯历史决策
- 需要维护长期知识
- 需要多个子任务并行推进
- 需要把失败经验沉淀到下一轮
这时决定成败的已经不是“这个 Agent 强不强”，而是有没有一个更高层的系统来负责：
- 记忆
- 状态
- 任务分发
- 工具编排
- 测试反馈
- 人机边界
换句话说：
单 Agent 擅长完成动作，研发中枢负责维持秩序。
真正的上限，不在“一个 AI 能连续做多久”，而在“一个系统能否让多个 AI 环节长期协同且不失真”。
6. 这也是为什么我会走向 JARVIS
我后来越来越明确一件事：
软件公司的 AI 研发，真正要解决的不是“怎么让 AI 多写一点代码”，而是“怎么让 AI 在研发过程中不反复失忆、不反复踩坑、不反复回到零”。
这就要求你有一个研发中枢，而不是一个会写代码的黑盒。
这个中枢至少要能处理几件事：
- 记住产品历史，而不是每次从头问一遍
- 区分已交付能力、当前 backlog、未来判断，而不是全部混成一锅
- 把历史 bug、设计决策、被否决需求变成可检索、可调用的记忆
- 让测试不只是“跑绿”，而是真正成为边界守卫
- 在多个任务和多个 Agent 之间维持统一状态
我把这类东西叫做 JARVIS。它不是一个更酷的名字，也不是一个更大的 prompt，而是一个研发系统层面的答案。
7. 所以这类实验还有没有价值？当然有
我并不是在否定“小范围 AI 开发实验”。
相反，我认为它依然非常值得做，只是不要把它误读成终局验证。
它最适合验证的是：
- 哪类任务最适合交给 AI
- 需求清晰度对成功率的影响有多大
- 测试前置能带来多大收益
- 人工介入点应该放在哪里
- 当前模型在本团队工具链里的真实表现如何
它是一个很好的局部压测手段，也是很好的组织教育工具。团队做完一次，就会更清楚：AI 的强项在哪里，弱项在哪里，组织真正的瓶颈在哪里。
但一旦你想把 AI 从一次性实验，升级成持续性的研发能力，你就必须进入下一个问题：
不是 AI 能不能做完这个任务，而是组织能不能把 AI 放进一个稳定闭环里。
8. 结语
一次封闭式 AI 开发实验，测得出模型能力、任务设计能力和局部自治能力；但它测不出软件研发真正的上限。
真正的上限，取决于一家公司能否把需求、实现、测试、验收、知识沉淀和组织记忆连接成一个持续运转的系统。
如果没有这个系统，AI 最多只是一个偶尔惊艳的开发者。
如果有这个系统，AI 才有可能变成稳定的研发力量。
而这两者之间，差的不是几万行代码，差的是一整套闭环能力。
延伸阅读：如果说本文讨论的是“为什么一次实验不足以说明问题”，那么下一步真正要讨论的，就是从 AI 写代码到 AI 驱动研发，中间到底差了什么。
