上周我在准备和团队 9 月初的一次对焦，主题是工程 AI 化。
预对齐时有人说：「我们 AI 用得挺好的——一半的 PR 是 AI 写的，Copilot 全员开通，还有人用 Claude Code 重构了老模块。」
我问了一个问题：「那挑一个 5 人天的真实需求，从提 Issue 到验收关闭，让 AI 端到端跑一遍给我看。」
会议室安静了几秒。安静不是因为没用过 AI，而是因为这条链路从来没有人完整走通过。AI 写过代码的片段，但片段之后是谁在收尾，说不清楚。
这个安静就是分界线：AI 写过代码，不等于工程 AI 化。
一次成功，不是能力
先做个区分。很多团队说的「工程 AI 化」，其实是两种完全不同的状态：
- 辅助：AI 参与开发的某些环节——补全、Review、写测试。人仍然是主体，AI 是更快的工具。
- 交付：人只提需求和验收标准，AI 自主完成从需求分析到合并的全链路。人退到验收者的位置。
这两件事的指标看起来可以一样——「AI PR 占比」两边都能很高。但性质完全不同：辅助模式下，AI 干不动的地方人来兜底，链路断在哪都行；交付模式下，闭环必须自己合上，没有兜底的位置。
交付是真实可行的，行业已经给出了证据。Anthropic 官方披露，他们产品团队 65% 的代码 PR 由内部的团队 Agent 开出——「AI 提 PR、人验收」在那里已经是日常工作方式，不是演示（这组数据我在从 Cowork 到 Tag 里讨论过它的组织含义）。
但大多数团队卡在中间地带：一次性成功也有过——某次 AI 一口气实现了一个功能，全组兴奋。然后就没有然后了，下一个需求还是老样子，或者 AI 写一半、人收尾。
一次性的成功是幸存者偏差，可复现才是能力。 就像一次事故响应成功不代表稳定性体系成熟，一次端到端跑通，也不代表团队掌握了 AI 工程。
所以管理者该验收什么？答案不能是「AI 使用率」——那是投入指标。应该是产出指标：「人提需求、AI 端到端交付」的闭环，能不能在 5 人天级的复杂度上稳定复现。
围绕这把标尺，我们整理出六条验收标准。
六条验收标准
标准一：流程闭环——全链路 6 步，缺一不可
完整的闭环有 6 步，从人提需求开始，到人验收关闭结束：
① 需求入口 人提出需求 → AI 自动创建 Issue
② 需求分析 AI 拆解需求，确认 Goal 与验收标准
③ 编码实现 AI 自主完成开发
④ PR + Review AI 提交 PR，通过 Code Review
⑤ 测试验证 单元测试 + E2E 测试
⑥ 交付关闭 合并 PR、关闭 Issue、交付功能
# generated by hugo AI
其中两步值得单独强调。
第 ② 步不是「AI 理解了需求」，而是 AI 要把 Goal 和验收标准写出来，并得到人的确认。这一步决定了后面所有动作的质量——Evals 是新的 PRD 说的就是这件事：验收标准不是事后核对的清单，它就是需求本身。AI 拿错 Goal，能力越强，偏得越快。
第 ⑤ 步的 E2E 是大多数团队最大的能力缺口：它要求 AI 具备 Computer Use / Browser Use 能力，能直接操作真实界面，并且有 vision 验证能力——看着截图判断交付结果对不对。只会看代码、不会看屏幕的 AI，永远走不完最后一公里。 它自己写测试、自己宣布通过，人最后还得亲自打开浏览器点一遍——那仍然是辅助，不是交付。
标准二：知识沉淀——记忆为主，漫游共享
沉淀的载体是 agent 记忆（AGENT.md 类），在与 Claude Code 这类编码工具的日常交互中自然沉淀，不强求写 Wiki。关键决策与经验，同步归档到 Issue 与 Memory。
这里有一条硬要求：核心记忆必须漫游共享，这是多人协作的基础。A 的 Claude 踩过的坑，B 的 Claude 不该再踩一遍。如果记忆不漫游，团队就只是 N 个各自用 AI 的孤岛，协作方式一点没变。
标准三：实践验收——拿 5 人天级复杂需求当标尺
实践标尺：单人 5 天工作量的复杂需求——性能优化、端到端加密、群聊功能这一级。明确 Goal 与验收标准后，AI 自主连续工作数小时（目标 8 小时+），完成开发并成功交付。
为什么是 5 人天？我的理解是：它足够小，失败一次的成本可控；又足够大，能暴露所有真实问题——跨会话的上下文管理、测试覆盖、与存量代码的协调、环境配置。0.5 人天的小需求跑通说明不了什么，5 人天跑通，才说明 Harness 体系能撑起长程任务。
但要提醒一句：8 小时是投入指标，不是产出指标。 验收的是「交付成功」，不是「跑了多久」。否则团队会去优化跑时长，而不是交付率。
标准四：工程条件——模型、工具、Harness、运行时
- 最好的模型 + 最好的工具（GitHub 级平台）
- 构建 AI Harness 工程体系：Issues / PR / Actions CI 全链路
- 具备 AI 操作与验证真实环境的运行时（浏览器自动化、vision）
这里要补一句：锁定「选型标准」，不要锁定「具体型号」。 最好的模型每半年就换一代，标准要回答的是「模型满足什么条件才够格」，而不是「用哪个模型」。我们在好的 Runtime 不挑模型 里踩过这个点：真正沉淀下来的是 Harness——CI 门禁、测试基线、记忆积累——换模型不用重来。模型是租来的，Harness 才是自己的。
标准五：人机分工——人守住三件事，AI 全程留痕
人的职责收敛为三件：提出需求、定 Goal 与验收标准、最终验收与决策。AI 负责全流程执行，并且过程留痕——Issue / PR / 测试记录全程可追溯。
留痕不是好习惯，是交付模式的必要条件：当 AI 成为执行主体，人的验收能力完全依赖可追溯性。你验收的不再是「这位同事写的代码」，而是「这条 AI 工作链路的完整证据」。没有留痕，就没有验收；没有验收，就没有关闭。
标准六：阶段目标——对焦数据，不对焦流程
原始总纲里这一节只有一句话：「产出阶段性结果，9 月 1 日当面对焦。」我把它补成了一个 13 天冲刺（见下文），并明确对焦口径：对焦数据，不对焦流程描述。 「我们已经把 Issue→PR→CI 链路搭起来了」是流程描述；「跑了 3 个 5 人天需求，2 个一次闭环，人工救火平均 1.5 次」才是数据。
「稳定复现」必须量化
六条标准里最含糊的是总纲那句「稳定复现」。不量化，对焦时必然变成感觉。我给出的起步值——这些是基于我们团队现状的建议起点，不是行业标准，跑完第一轮再校准：
| 指标 | 起步值 | 防的是什么 |
|---|---|---|
| 闭环样本数 | ≥3 个 5 人天级真实需求 | 防一次成功当样本 |
| 一次交付成功率 | ≥2/3 | 防「人兜底完成」也算成功 |
| 人工救火次数 | 每单 ≤2 次（定 Goal 与验收标准不计） | 防「AI 自主」名不副实 |
| 人的验收耗时 | ≤ 传统开发的 20% | 防验收环节成为新瓶颈 |
| 成员覆盖 | 任意成员提需求都能跑通 | 防「一个人掌握」冒充团队能力 |
最后一行最容易被忽略：「团队掌握」的意思是任何一个成员提需求都能跑通。 如果只有一个高手能驱动 AI 完成交付，团队得到的是一个新的单点依赖，不是新的能力。这和招 Agent 工程师，我第一个看的不是技术 里讲的是同一件事的两面：个人的 AI 原生能力是必要条件，但团队要的是把个人能力沉淀成任何人都能使用的环境。
三个暗坑：不补，标准会塌
总纲有三个不起眼的地方，会让整套标准失效。
一、只有成功路径，没有失败路径。 6 步全部假设 AI 一路顺畅，但真实世界里更常见的是 AI 在错误的方向上狂奔。需要一条 escalation 规则：连续若干小时无实质进展，自动上报、止损、交还给人。否则「自主工作 8 小时」会退化成「无人值守地空转 8 小时」——损失比人自己干还大。
二、自评。 AI 写代码、AI 做 Review、AI 写测试，等于 AI 给自己批作业。要有独立性约束：Review 的 Agent 和写码的 Agent 用不同的 session 甚至不同的模型；验收标准在编码开始前就由人或独立 agent 锁定。Review 的价值在于审查者不是作者——这条常识不会因为作者换成 AI 而失效。
三、Memory 漫游没有治理。 两个人沉淀了互相矛盾的经验听谁的？一条错误经验污染所有后续任务怎么回滚？只解决「写入」、不解决「清理」，记忆半年内就会从资产变成负债。这和 Tag 在 Anthropic 内部 Slack 撞上的治理墙是同一件事：AI 一旦进入协作层，治理就必须跟上——区别只是工程团队在 Harness 这一层更早遇到它。
最强反方：这是不是变相 KPI？
预判一个最尖锐的挑战：「标准一量化就变成 KPI。团队会拆需求凑数、挑简单的做、把数据刷得漂漂亮亮——就像当年考核代码行数。」
这个挑战对了一半。如果把这张表塞进绩效模板，它一定会被刷。但它的设计意图恰恰相反：
第一，它是能力体检表，不是绩效标尺。 它回答「团队的 AI 工程能力是否成型」，不回答「这个季度谁干得好」。体检数据是团队自己用来看病强身的，不是用来排名的。
第二，5 人天门槛本身就是防刷设计。 把需求拆碎，单个不到 1 人天——不算；挑简单的做，CRUD 级任务达不到「性能优化、端到端加密」的复杂度。标尺锁的是复杂度等级，不是数量。
第三，也是最根本的：量化的对象不是 AI 能力，是团队自己的 Harness 工程能力。 模型一直在进化，你量化不了它；但 CI 门禁、测试基线、记忆治理、失败 escalation，这些是团队自己可控的工程，模型换代它们也不作废。明天换一个更强的模型，闭环工程的差距依然存在——它不会自动补齐。
所以这套标准的本质是：不量化 AI，量化你自己的工程。
把第六节填空：13 天冲刺
从今天到 9 月 1 日，13 天。阶段目标拆成这样：
| 阶段 | 时间 | 交付物 |
|---|---|---|
| 打地基 | 8/19–22 | Issue 模板、Goal/验收标准 checklist、CI 门禁、浏览器 + vision 运行时、AGENT.md 种子 |
| 首跑 | 8/23–27 | 选一个真实 5 人天需求，端到端走完 6 步，沉淀第一版 Memory |
| 复现 | 8/28–31 | 复现 2–3 次，统计成功率、救火次数、验收耗时 |
| 对焦 | 9/1 | 拿数据对焦，不拿流程描述对焦 |
首个需求的选取有三个要点：必须是 真实需求 而不是练习题；复杂度要够 5 人天级；范围可控，不选强依赖跨团队的。第一个选得好，它暴露的问题就是 Harness 的建设清单。
结尾
回到开头那个问题。当被问到「你们团队 AI 化得怎么样」，有两种回答：
一种是投入式的——Copilot 开通率多少，AI 写的 PR 占比多少。这些数字好看，但回答不了「AI 能不能交付一个完整的 5 人天需求」。
另一种是产出式的——3 个 5 人天需求，2 个一次闭环，救火平均 1.5 次，任何成员提需求都能跑通。
工程 AI 化的分界线，不是 AI 有没有参与你的开发，而是你敢不敢把一个完整的需求交给它——这个「敢」，靠的是 Harness，不是运气。
一个问题留给你：你团队的下一个 5 人天需求，敢不敢建个 Issue，然后只等 PR？
你在实际跑通过类似的闭环吗？踩过什么坑？欢迎留言讨论。