全部通过了，为什么还不能上线？

先讲一个让人有点不舒服的事实。

一次隔离实验里，自动化测试 40 个用例全部通过，退出码 0，日志完整，报告自动生成 —— 技术执行层面漂亮得无可挑剔。但同一份报告的另一侧写着：8 项业务预期待确认，3 个 UI 脚本未归档，人工准出未作结论。

40/40 是技术执行结果，不是验收结论。

这就是 AI 进入软件工程之后，最容易被忽略、也最要命的一道裂缝：AI 可以把事情做完，但没有人能替它签字。

01 传统 SDLC 真正的底牌，不是流程，是 "责任归属"

我们讲了二十年的 SDLC，很容易把它理解成一张流程图：需求→设计→开发→测试→发布→运维。但这张图之所以能跑起来，靠的不是流程本身，而是三件东西同时存在：

第一，具名责任。 目标、设计与放行，由具体的人决定。需求基线谁签的、设计基线谁批的、合并谁放的、发布谁准的 —— 每一个关键关口上，都站着一个有名有姓的人。

第二，工程系统。 正式状态由原系统保存。项目系统存需求与审批，Git 存代码与分支，CI 存构建与测试，运维系统存发布与告警。状态不在某个人脑子里，也不在某份文档里，而在系统里。

第三，交付记录。 每一个阶段都留下可复核的证据：需求与设计的基线、PR 与测试的变更、发布与缺陷的运行记录。

这三样东西合起来，构成了一条可追溯的责任链：G0 需求基线 → G1 设计基线 → G2 合入 → G3 准出 → G4 发布 → G5 复盘。

所以当我们说 "让 AI 参与研发"，真正的命题从来不是 "AI 能不能写代码"。代码它早就能写了。真正的命题是：AI 怎么进入这条已经运行了二十年、由具名责任和正式状态支撑起来的责任链？

答案不是另起一套，而是接进去。

02 AI-SDLC：把执行、验证、决定和学习，分成四件事

分享里给出的框架，我觉得是整场最关键的一次 "拆解"。它把 AI 参与研发这件事，干净利落地切成四段：

第一段：目标与边界 —— 人确认。 目标、约束、验收标准，必须由人确认。这一步不是 "AI 提个建议人点个头"，而是人真的要把 "什么算完成" 说清楚。

第二段：AI 受控执行。 检索、生成、修改、自检 —— 四类动作，全部限定在授权工具与操作范围之内。注意 "受控" 这两个字：不是让 AI 自由发挥，是给它一个划好边界的操场。

第三段：系统自动验证。 构建、测试、扫描、留痕。可机器判定的工作，交给系统。 这一段的可靠性不来自模型变聪明，而来自验证本身可复现。

第四段：组织持续进化。 沉淀规范、Skill 与评测集。一次做对不算本事，把做对的方法沉淀成下一次的起点，才算。

这个框架里最锋利的一句话是：人聚焦目标、例外与放行；可机器判定的事交给系统；正式状态回写原研发系统。

翻译成人话就是：人不要再跟 AI 抢 "干活" 这件事，人应该退到三个位置上 ——定义目标、处理例外、签字放行。

03 Harness 是什么：不是模型，是让 AI 任务 "可控运行" 的条件

很多人一听 Harness，第一反应是 "又一个新框架"。分享里给的定义很克制：

模型提供推理能力；Harness 组织上下文、工具与控制逻辑，使任务能够执行并接受验证。

它是一个 "运行结构"，不是模型本身。拆开看，它管五件事：

• 目标与任务契约：目标、非目标、验收与停止条件 —— 先说清楚要什么、不要什么、什么算完、什么时候停；
• 仓库与工程版本：代码、依赖、Diff 与测试基线 ——AI 改的是哪一版，必须钉死；
• 工具与真实系统：API、MCP、CLI 与受控执行器 —— 它只能碰被授权的工具；
• 知识与历史上下文：规范、设计、引用与失败样例 —— 给它 "这个团队怎么做事的"；
• 身份与授权范围：项目、目录、环境、有效期 —— 它能看什么、能改什么、能看多久。

中间是四个动作：上下文 | 工具 | 循环 | 检查。再加上状态管理、预算与异常：有限重试、检查点、人工交接。

右边产出两类结果：AI 真正执行的产物，以及独立检查与责任交接—— 真实构建测试扫描、验收条目与结果映射、具名人员决定风险和放行、原系统保留正式业务状态、失败案例回流规则与评测。

分享里还特意标了四条边界，很良心：运行结构不等于模型；不是统一行业标准；不预设另建独立平台；这只是企业落地扩展。 一个愿意主动说清 "我不是什么" 的分享，通常比拼命证明 "我是什么" 的分享更可信。

04 五个概念，各管一件事，千万别混为一谈

这是我觉得最值得架构师抄下来的一页。

Spec / SDD 管验收规格与变更基线 ——什么算完成； Prompt 管任务表达与输入提示 ——这次要做什么； Skill 管可复用的方法 ——这类事怎么做； MCP / API 管工具与系统接口 ——能碰到什么系统； Harness 管运行结构与控制 ——整个过程怎么被管住。

然后四个 "不是"，每一个都对应一个真实踩过的坑：

• Prompt 不是权限。 你在提示词里写 "不要删库"，那叫请求，不叫约束。
• Skill 不是治理。 一个 Skill 能被调用，不代表它该被谁调用、在什么范围调用。
• MCP 不是授权。 接上了系统，不等于它有资格操作那个系统。
• 模型不是全过程。 模型只管中间那一段推理，前后两端（契约和验证）它管不了。

同一项任务里，这五样东西必须贯通：需求变更冻结验收 → 发起任务确定方法 → 受控调用真实工具 → 系统验证检查结果 → 人工决定接受或退回 → 记录回流更新资产。

方法、证据、状态，三样东西贯穿同一条链。 缺一样，这条链就断。

05 一条任务怎么被管住：失败重试有预算，条件不明就停

分享给了一个非常具体的运行示例 —— 一张 "可执行任务卡"，编号 T-017，任务是把一段规则变更落到代码里。卡上写死了六件事：

输入基线钉在 Spec v3、commit 版本；写入范围限定在 src/rules/；验证走单测与 CI 的 run ID；修复重试最多 2 次；越权、冲突、超预算立即停止；结果是 Diff、证据与未决项。

然后是七步执行路径：固定任务与版本 → 装配有效上下文 → 先校验再调用 → 测试返回真结果 → 失败后有限修复 → 超限或不明就停 → 携证据交给人。

这里有两个细节，非常见功力。

第一，"可重试，但不能无限试到 ' 成功 '"。很多 Agent 系统最危险的地方就在这里：它会一直试，直到某一次碰巧通过。你以为它成功了，其实它只是把失败的概率采样掉了。给重试设预算，本质是承认 "试不出来就该停下来交给人"。

第二，"条件不明就停"。越权了停，契约冲突了停，规则不明了停。不是让它猜，是让它举手。

三类结果是分开的：通过 → 待审核；失败 → 有限修复；不明 / 超限 → 停止。 不是二元的成功失败，而是三种归宿。这一点很像工程上的 "三态" 设计，比布尔值可靠得多。

06 权限不是一次授予，而是动作分级

这一页我觉得所有做 Agent 平台的人都该看。

能读什么、能改什么：项目、目录、分支与数据范围，开发、测试、生产环境隔离。最小权限，范围可核验。 用什么、由谁校验：模型、Skill、MCP 与工具清单，服务端与执行器校验真实权限。Agent 与人员凭据分离。 何时停、如何恢复：越权、冲突、预算耗尽即停；复核授权与版本后恢复。有时效授权，可即时停用。

然后是动作分级控制，按风险等级配置，而且测试通过不自动扩大权限：

• 低风险 → 自动执行：只读查询、解释代码、生成草稿。全程留痕，按需复核；
• 中风险 → 受控执行：限定分支修改代码、运行测试、创建 PR。系统验证，具名 Reviewer；
• 高风险 → 人工决定：合并主干、生产发布、权限或数据变更。按控制度审批，受保护执行。

还有两条底线：执行前校验（身份、范围、有效期与环境），执行中可停（越界拒绝，保留现场与检查点）。

一句话：审批不会自动赋予永久权限。 今天点了个 "同意"，不等于明天它还能干同样的事。

07 Reviewer 到底在看什么：改动、验证、未决项

Reviewer 不是 "再看一眼代码"。他看四件事:

关联：任务身份 —— 同一任务关联工单、发起人与 Agent； 记录：基线与动作 —— 保存版本、授权范围、工具调用与 Diff； 验证：真实结果 —— 构建、测试、扫描关联 run ID 与失败原因； 决定：人工放行 ——绿色测试不代表准出，具名人员作决定。

证据链是四段式的：任务与授权 → 执行与版本 → 独立验证 → 决定与写回。

值得一提的一个设计：独立验证要求不信任执行方自述。 在实测里，质量审查 Agent 是自己独立复跑一遍并保留日志的，而不是直接采信执行 Agent 的报告。这个细节决定了整套体系的可靠性上限 —— 用同一个不可靠来源验证两次，等于没验证。

08 六阶段 28 环节：AI 是嵌进去的，不是另建一套

分享把整个研发流程拆成 6 个阶段、28 个环节，然后标出 AI 可以在哪里插进去：

• 需求与产品（1–5）：业务问题受理、需求澄清与业务规则、PRD、验收标准与测试场景、需求评审与基线；
• 方案与设计（6–12）：影响分析与可行性、开发方案与架构设计、数据模型与数据变更、接口契约设计、安全与非功能设计、测试与发布设计、设计评审与基线；
• 开发与提交（13–17）：任务拆分、编码实现、单测与本地验证、Commit 与 PR、AI 辅助预审；
• 合并与验收（18–21）：人工代码 Review、CI 自动门禁、集成测试与业务验收、合并决定；
• 发布与运行（22–24）：发布评审、灰度与上线、监控告警与运行观察；
• 缺陷与改进（25–28）：缺陷受理与定级、根因分析、修复与回归、复盘与知识沉淀。

关键的原则有四条：

正式状态归原系统—— 需求、合并、测试、发布的正式状态不另建一套； 触发、回写均可追溯—— 事件触发取上下文，携证据回写，避免重复执行； 异常停止，人工决定—— 不是自动兜底重试； 避免重复审批与写回—— 不要把同一件事批两次、写两遍。

至于单个环节怎么封装成可插拔能力，逻辑是三步：任务契约 → 能力单元 → 工程节点。而分工非常清楚：

Skill 提供方法・MCP/API 连接系统・Harness 管状态与证据・CI / 测试仍由原系统执行。

09 实测：文档有来源，也要核对真实接口

9 月的隔离实验，是 WorkBuddy 交接给 CodeBuddy 做预审与实现 —— 注意，这不是客户生产发布，是一次有边界的实验。

结果很有意思：交接文档里说输入是 "数组示例"，但真实接口返回的是 "对象契约"。26 行新模块，复用两类现有领域函数，编码前契约核对做了，基线 5/5、场景 1/1、独立审查 3/3 都过了。但验收还是有缺口：AC7 缺 mock，交接文档未回写。

七步纠偏路径写得很务实：冻结任务边界 → 核对数据契约 → 按真实接口实现 → 执行已约定检查 → 对照验收条目 → 补证后再决定 → 保留实验边界。

这一页最值钱的一句话：文档有来源，也要核对真实接口。

多少 AI 项目死在 "文档说可以，接口说不可以" 上。AI 最擅长的就是照着文档自信地生成一个不存在的接口。

10 月的测试实测同样精彩：10 月 WorkBuddy 隔离实验，35 个新增 + 5 个既有，共 40 个用例全部通过；质量审查 Agent 独立复跑并保留日志。但边界依然划得很清楚：字符串 false、否定语境，需要业务规则确认—— 这种地方机器判不了，必须留给人。

然后是那句必须重复一遍的话：40/40 是技术执行结果；8 项业务预期仍待确认。录屏时长不代表完整任务耗时或验收完成。

10 组织落地：从 "一个节点" 起步，让团队自己跑起来

分享对落地节奏的建议，是一句我很认同的话：从一个工程节点起步。

先选一个高频、可验证、责任清楚的节点，而不是一上来搞全流程重构。路径是七步：工具训练 → 选定节点 → 能力共建 → 样例评测 → 真实试跑 → 证据验收 → 独立接管。

角色分工也清楚：工程辅导团队负责导入任务契约、工具与验证方法，共建场景、Skill 与评测集，协助问题闭环和知识转移；企业工程团队负责提供真实任务、接口与授权，定义验收基线和人工责任，独立做配置、评测、停用与回滚。

怎么判断 "团队能不能接管"？三条：任务可以复现（固定样例、环境和版本，重跑能得到可解释的结果与证据）；人员能够独立操作（不是 "听完培训"，是真能独立完成配置、评测、发布和回滚）；方法能够持续更新（失败案例、规则和操作方式进入版本管理）。

还有一条容易被略过但很关键的机制：把一次契约纠偏，沉淀成可回归的 Skill。 记录纠偏 → 沉淀四件套（说明书、执行脚本、评测集、发布契约）→ 验证后再复用。发布原则只有两条，但很硬：AI 作者不得自批；高风险动作人工放行。

11 明天就能试：为一个 PR 写清任务契约

所有宏大叙事，最后都要落到 "明天做什么"。分享给的起点极小，就四个字段：

输入：选定一个已有 PR，填仓库 / PR 编号、固定 commit 与 Diff、适用规范与验收条目； 权限：只读预审，不合并 —— 可读授权仓库与规范，可做检索 / 分析 / 产出意见，禁止写主干、合并与发布； 输出：能核查的预审意见 —— 文件位置、依据、修改建议、实际 CI 记录与验收映射、未决项与风险； 交接：具名 Reviewer 接手，人工决定接受、退回或终止；版本变化、越权、规则不明即停。

四步：选一个真实 PR（范围要小）→ 填好输入和边界 → 跑一次检查证据 → 留下一条失败样例。

最后那句收束，我觉得可以当成整个 Harness 体系的方法论：

人保留判断，AI 执行，系统验证；每次纠偏都让下一次更可靠。

结语：AI 不缺能力，缺的是 "可被信任的运行条件"

这两年我们看了太多 "AI 写代码有多快" 的演示。但真实企业里，代码从来不是最贵的东西。最贵的是责任—— 是谁决定做、是谁决定放、出了问题是谁签字。

AI 进入软件工程，不是把 SDLC 这张图重画一遍，而是把自己接进一条已经运行了二十年、由具名责任与正式状态支撑的责任链。这条链接不进去，AI 永远只能停在 "帮我写个草稿"；接进去了，它才能做 "预审"" 根因分析 ""测试准备" 这些真正进入价值链的活。

而接进去的条件，就是 Harness 这一整套东西：契约先于执行，权限小于能力，验证独立于执行，放行必须具名。

三个可以带走的判断：

01 执行、验证、决定、学习，必须分开。 混在一起，就会出现 "AI 自己生成、自己检查、自己说通过" 的荒谬闭环。

02 测试通过不等于可以准出。 40/40 只证明 "跑完了"，不证明 "做对了"。正确答案由谁确认，这个问题不能被技术结果替代。

03 从一个节点开始，比做一套平台更靠谱。 先建立基线，再讨论提升。接入既有系统，不必另建平台。

AI 不缺能力。它缺的是一套让人敢把责任交出去的运行条件。谁能把这件事做成，谁就拿到了下一轮软件工程的门票。