从 AI 写代码，到 AI 驱动研发：中间差了一个 JARVIS
从 AI 写代码，到 AI 驱动研发：中间差了一个 JARVIS
今天很多团队已经接受了一件事：AI 会写代码，而且会越写越好。
无论是 Copilot、Cursor，还是各种 coding agent，大家都已经见过它们在局部任务上的惊艳表现：补函数、改 bug、写测试、搭页面、重构样板代码、生成接口调用、解释旧代码……这些事，AI 确实已经很能打。
但奇怪的是，真正把 AI 用进研发体系里的团队，还是很少。
原因不在于模型不够强，而在于很多团队对“AI 参与研发”的理解，还停留在一个过于简化的画面里：
给 AI 一份需求，它就去写代码；写完后人来验收。
这当然是起点，但离真正的“AI 驱动研发”还差得很远。
我现在越来越明确：
从 AI 写代码，到 AI 驱动研发，中间不是差一个更强的模型，而是差一个 JARVIS。
这里说的 JARVIS，不是某个具体产品名，也不是一个酷炫的 Agent 壳，而是一个更本质的东西：AI Native 研发中枢。
1. “AI 写代码”到底是什么范式
先说清楚，AI 写代码并没有错，而且已经很有价值。
它的典型工作方式是：
- 人提出一个任务
- AI 读取当前代码和上下文
- AI 生成修改方案
- AI 编写或修改代码
- 人类 review、测试、决定是否接受
这个范式为什么有效？因为它很好地利用了 LLM 的几个长处：
- 语言到代码的映射能力
- 对常见模式的归纳能力
- 对局部上下文的推理能力
- 高速生成样板和重复结构的能力
在任务短、边界清晰、上下文有限的时候，这种模式甚至已经足够强。
但它有个根本限制：
它默认问题主要发生在“实现层”。
换句话说，它假设：只要需求大致明确，真正需要 AI 解决的主要就是代码实现。
而真实的软件研发并不是这样。
2. 研发真正复杂的地方，不在“写”，而在“持续做对”
一个工程任务越往后走，你就越会发现，真正消耗团队的并不是写代码本身，而是下面这些东西：
- 这个需求边界到底是什么
- 为什么历史上会这样设计
- 之前类似问题有没有踩过坑
- 某个改动会影响哪些模块
- 哪些方案看起来合理，但组织已经否决过
- 哪些测试是关键守门点
- 哪些地方必须人工批准，哪些可以自动推进
这些东西共同决定了：
- 代码是不是“业务上正确”
- 修复会不会引入回归
- 新需求会不会和旧约束冲突
- 团队会不会重复讨论同一个问题
- AI 会不会每轮都像一个刚入职的新同事
所以研发的难点，从来不只是“生成能力”，而是：
如何在长周期、多约束、会变化的环境里，保持记忆和秩序。
而这正是“AI 写代码”范式天然缺的部分。
3. 为什么单个 coding agent 很难直接升级成研发系统
一个强 coding agent，通常已经能做很多事：
- 读代码
- 写代码
- 跑命令
- 执行测试
- 修改文件
- 总结结果
但一旦你希望它承担研发系统级职责，它马上会碰到几个结构性问题。
3.1 它的记忆是脆弱的
即使模型上下文越来越大，研发中的关键记忆仍然不是靠“塞更多 token”解决的。
因为真正重要的记忆不是一堆文本片段，而是：
- 设计决策
- 历史 bug 模式
- 被否决需求及理由
- 模块之间的因果关系
- 当前版本计划和 backlog 状态
- 哪些知识已经过期，哪些仍然有效
这些内容需要被组织、维护、演化，不是简单堆在上下文里就够。
3.2 它对“现在的状态”掌握得不稳定
研发不是只有代码仓库。还有很多关键状态分散在别处：
- issue 系统
- MR / PR 审查
- 版本计划
- 发布环境
- 测试环境
- 人员分工
- 历史讨论
单个 coding agent 很容易只看见“当前 checkout 的代码”，却看不见“这个任务此刻在整个组织里处于什么状态”。
3.3 它缺少角色分层
真实研发里，开发、测试、产品判断、风险评估、知识维护，并不是一个动作。
如果让单个 Agent 同时扮演所有角色，表面上看很统一，实际上很容易出现：
- 自己写、自己测、自己宣布成功
- 没有独立视角去发现目标漂移
- 没有机制把经验沉淀给下一轮
- 没有边界去阻止“为了通过而通过”
这会让系统越来越黑盒。
3.4 它无法天然处理长期协同
任务一旦跨天、跨周、多分支、多模块推进，就需要有人维护这些信息：
- 现在有哪些任务在进行中
- 谁依赖谁
- 哪个结论已经确认
- 哪个实验失败了
- 哪些知识应该固化进系统
- 哪些流程应该被调整
如果没有一个中枢，所有任务都只是局部冲刺。你会看到很多“局部都很聪明，整体却越来越乱”的场面。
4. JARVIS 真正补上的，不是编码能力，而是系统能力
我现在更愿意把 JARVIS 理解成这样一个系统：
它负责让 AI 在研发过程中拥有记忆、知道状态、会使用工具、能回收经验，并在关键节点接受人类约束。
这意味着 JARVIS 要补上的，不是一两个功能，而是几类核心能力。
4.1 记忆层：让 AI 不再每次从零开始
如果一个 AI 每次接任务都像第一次接触这个产品，那它再强也只是“高智商实习生”。
记忆层至少应该包括：
- 历史功能和设计决策
- 历史 bug 与修复模式
- 已知风险和边界条件
- 被否决需求和原因
- 过去实验的结论与失败教训
这类记忆不只是为了检索，更是为了帮助 AI 在一开始就进入“组织语境”。
4.2 状态层：让 AI 知道现在发生了什么
除了历史，AI 还必须知道“此刻”的状态：
- 当前 open issue 和优先级
- 版本节奏与排期
- 哪些任务已经在进行中
- 哪些代码已合并、哪些还在 review
- 测试环境和发布环境的现实情况
没有状态层，AI 很容易给出“理论上正确、当下不适用”的建议。
4.3 编排层：把研发活动拆成可控环节
研发中很多事情不该由一个 Agent 一把梭，而应该被拆成：
- 需求澄清
- 方案判断
- 实现
- 测试
- 回归验证
- 知识更新
- 风险审查
编排层的意义在于：
- 不同环节可以调用不同能力
- 每一步都有明确输入输出
- 出错时可以知道错在哪一层
- 失败经验可以回写到具体环节，而不是笼统归因给“AI 不行”
4.4 测试层：让系统对“做对”有真实反馈
很多团队把 AI 测试理解成“让 AI 自己写点测试”。
这远远不够。
测试层真正的职责是：
- 把历史 bug 变成可复现、可回归的守门点
- 把业务边界显式化，而不是隐藏在口头经验里
- 让每次修复都能留下防重复发生的结构
测试不是附属品，而是 AI 研发闭环里的约束器。
4.5 人机边界层：让自动化不会滑向失控
真正成熟的 AI 研发体系，不是“人不看代码”，而是：
- 人不需要盯每一个局部动作
- 但人要定义边界、审批点、验收标准和风险阈值
哪些环节可放权，哪些必须停下来问人，这不是工程细节，而是系统设计问题。
5. 为什么我说“中间差了一个 JARVIS”
因为从能力结构上看，这中间确实有一道清晰的断层。
AI 写代码时，关注的是：
- 当前任务
- 当前代码
- 当前窗口里的局部正确性
AI 驱动研发时，关注的是：
- 历史连续性
- 当前组织状态
- 多环节之间的协同关系
- 失败后的恢复机制
- 经验的沉淀与复用
前者更像一个很强的执行器。
后者开始接近一个真正的研发系统。
而把执行器变成系统，中间必须有一个负责记忆、状态、编排和边界控制的中枢。这就是我说的 JARVIS。
6. JARVIS 不是“一个更大的 Prompt”
这是最容易被误解的地方。
很多人会下意识地认为：
- 多给点文档
- 把 prompt 写复杂一些
- 接上更多 MCP / Tool
- 换个更强模型
是不是就等于 JARVIS 了？
不是。
这些东西可能是材料，但不是系统。
真正的 JARVIS 至少有三个关键特征：
第一，它有结构化记忆，而不是临时喂料
它知道哪些是历史事实，哪些是当前状态，哪些是未来判断。
第二，它能持续更新，而不是一次性构建
每次修 bug、做决策、发生回归，都会反向更新它的记忆和规则。
第三，它服务于组织，而不是服务于单次对话
它不是为了让某一次回答更聪明，而是为了让整个研发体系越来越稳定、越来越会积累。
所以，JARVIS 的本质不是“更聪明地回答问题”，而是“让组织的 AI 能力具有连续性”。
7. 在我的实践里，JARVIS 为什么越来越像必选项
最近我越来越强烈地感受到：
如果没有研发中枢，AI 在复杂研发任务里会不断出现同一种浪费：
- 明明以前分析过的问题，又重新分析一遍
- 明明以前否过的方案，又重新提出来
- 明明以前修过的 bug，没有沉淀成回归测试
- 明明系统里已有知识，Agent 却像不知道一样重新摸索
这些浪费看起来是“小问题”，累积起来却会吞掉大量信心和效率。
相反，一旦你开始把：
- issue 历史
- 模块知识
- 设计决策
- 已知问题
- 回归测试
- 当前 backlog
- 版本计划
逐渐组织成一个能被 AI 调用、也能随着研发共同演进的体系，很多东西就开始变了。
AI 不再只是“帮你写”。
它开始能够：
- 基于历史判断问题是不是重复出现
- 提前指出某类改动的结构性风险
- 把零散 issue 看成模式，而不是孤立事件
- 在多次任务之间形成连续上下文
也就是说，它开始不是一个代码工人，而是一个真正参与研发判断的成员。
8. 结语
软件行业接下来几年一定会继续看到更强的 coding agent。
但如果一个团队只是把更强的 agent 接进现有流程，最后大概率只会得到一个更能干的局部执行器，而不是一个真正的 AI 研发系统。
从 AI 写代码，到 AI 驱动研发，中间真正差的那一步，不是模型升级，不是 token 扩容，也不是 prompt engineering。
中间差的是一个能承载组织记忆、实时状态、任务编排、测试约束和人机边界的研发中枢。
我把它叫做 JARVIS。
它不是为了让 AI 看起来更酷，而是为了让 AI 真正能够成为软件公司的长期生产力。
上一篇文章讨论了为什么单次实验测不出真正上限；这一篇想说明，要跨过那道上限，缺的不是更强的“写”，而是一个能让 AI 持续“做对”的系统。
