90%代码交给AI后，人的价值在哪？OpenSpec规格契约驱动硅基Agent团队

说在前面：硅基单兵到硅基团队，正成为眼下的前沿热点

大量小伙伴从零起步去挑战 AI 架构方向，最近不少拿到 AI 架构师 offer 的朋友反馈，面试中频繁出现这样一类场景题：你进一家制药企业，要从零负责内部 AI 转型，还要带动员工用 AI 的积极性，你会怎么着手？

类似的题目还有很多，比如：

• 集团打算推广 Agent 开发，业务部门都想要独立的 Agent，但平台资源有限、容易出现大量 Agent 孤岛。作为 AI 架构师，你如何设计组织机制与技术架构？
• AI Agent 直接写代码容易出现 spec 漂移，需求改一点，代码到处乱改。怎么搭建规格基线体系，管控 AI 开发全流程？需求频繁变更时，如何设计变更闭环，防止需求蔓延，保证每一次改动可追溯、可回归？
• 在 AI 生成代码的流水线中，如何把 TDD 验收断言嵌入规格基线，保证 Agent 产出必须满足验收标准才能进入基线？基线评审、数据迁移、核心接口这类高风险变更，怎么设计 HITL 人工触发规则？

这类问题最怕两种答法：一是背工具清单——上 CoPilot、上知识库、上 Agent；二是喊口号——全员 AI 化。真正的思路应该把它当成一道架构设计题：转型不是"买什么工具"，而是"把 AI 的生成速度，变成组织可验证、可规模化、可审计的生产力"。

《尼恩团队 硅基单兵-硅基团队学习圣经》中的系列文章，正是围绕这套底层套路展开的。

《尼恩团队 硅基单兵-硅基团队学习圣经》的 17-27 篇文章清单：

本文是第 17 篇。

大量企业 AI 转型卡在中间阶段的共性痛点

不少团队都抱着一个朴素假设：只要人把需求用自然语言说清楚，AI 就能高质量交付。但 Faros、METR、快手的实测数据反复指向同一个结论：口头讲清楚，不等于可被硅基 Agent 执行的规格契约。

口头需求的问题相当直接：会落入 Vibe Coding 陷阱，放大 AI 幻觉与 spec 漂移；同时催生一个"单兵 PR 暴涨、团队交付原地不动"的生产力悖论。

换句话说，很多企业落地 AI 编码、Agent 平台之后，都会陷入同一个业务陷阱：团队兴冲冲引入大模型与 AI 智能体，短期看开发产出暴涨，代码 PR 数量成倍增加，业务方也觉得 AI 能快速写功能，预期被拉满。

但跑上 1-3 个月就会发现，返工率持续走高、需求来回拉扯、版本 bug 层出不穷。业务人员习惯用自然语言描述想法，口头追加需求、临时调整逻辑，没有固定基线约束，AI 顺着零散对话不断修改代码，spec 漂移随之而来。多团队并行时，不同业务线各自搭建独立 Agent，形成大量 Agent 孤岛，同样的业务规则多套实现，数据口径也各说各话。研发、QA、合规岗位对 AI 产出缺乏统一校验标准，安全漏洞、知识产权、审计追溯等风险隐而不发。业务团队还容易误认为 Agent 可以直接承接完整项目，忽略任务拆分与边界管控，最终导致 AI 大量无效产出。

PR 爆炸随之而来。研发评审人力被海量 PR 淹没，投入成本持续走高，业务交付效率却没有实质提升。这正是大量企业 AI 转型卡在中间阶段的共性痛点。而硅基单兵与硅基团队架构，核心目标就是要解决这一类组织层面的生产力悖论。

行业案例：一个业内自主 AI 软件工程师 Agent 的工作流程

正式展开之前，先看一个业内的自主 AI 软件工程师 Agent。

Devin 是 Cognition 公司 2024 年 3 月发布、由 Scott Wu 团队打造的自主 AI 软件工程师 Agent。它和 Copilot 副驾驶编辑器不是一类产品：Copilot 是辅助编码，而 Devin 是具备独立长程规划、自带沙盒终端 + 编辑器 + 浏览器工具集，可以端到端跑完完整软件工程任务的独立智能体。

回顾一下 Devin 发布时放出的示范案例，流程大致如下：

1. 接收一段自然语言任务描述，自主拆解工程计划；
2. 在隔离沙盒环境中操作 shell、编辑器、浏览器；
3. 读取代码库、写代码、跑单元测试、定位 bug、反复调试；
4. 最终产出代码、提交 PR，完成需求交付；
5. 官方演示场景包括：独立搭建生命游戏网页并部署、修复开源库数学 bug、承接 Upwork 外包开发任务、基于论文复现模型微调任务。

Cognition 创始人 Scott Wu 有一句很有冲击力的公开言论：

传统软件工程中，工程师大约 10% 精力用于定义问题、架构取舍、判定对错，剩下 90% 消耗在写代码、调试、修复 bug、琐碎实现细节上。现在 AI 智能体可以接管绝大多数 90% 的执行工作。

由此很多人得出一个简单结论：未来人类工程师只需要"用嘴巴把需求说清楚，让 AI 干活"。但从硅基单兵到硅基团队的落地实践来看，现实会很快击碎这个理想化想象。

"嘴上说清楚需求"是人的自然语言能力；"产出机器可校验的规格契约"，才是驾驭硅基 Agent 的工程能力。二者天差地别。

很多团队在 AI Coding 上踩坑，底层原因恰恰就在这儿：

• 人类以为自己讲明白了业务意图，但只停留在聊天框的自然语言里，没有把意图固化成 OpenSpec 范围层的工具契约；
• 哪怕是能力很强的 Devin 类 Agent，依然会发生 RBAC 角色逻辑写反、遗忘 Non-Goals、偷偷扩大范围、架构私自改动等幻觉问题。

快手、Faros 的统计现象也在复现同样的困境：Agent 可以疯狂产出 PR，代码生成率大幅上涨，但需求交付周期、返工率、spec 漂移率这些组织指标并没有改善。

这正是硅基架构开篇的核心不等式：使用 AI 工具 ≠ 个人提效 ≠ 组织提效。快手数据（交付周期降 53%、人均需求提升 38%）也证明，只加速编码救不了组织效率。

硅基 Agent 时代人类的核心价值

有了硅基 Agent 之后，人类从 Coder 升级为 Builder，核心价值从"写代码"转为"产出机器可校验的规格契约"。Scott Wu 所说的人类三大核心价值——问题定义、架构决策、结果取舍——在硅基体系中并非靠聊天对话完成，而是完整落在 OpenSpec、Harness 调度层、治理层 HITL 人工门这一整套机制里。

上图把"传统 Vibe Coding 误区"与"硅基范式"并置对照：

• 左侧：人类口述需求→AI 自由发挥→看 diff 判断对错→PR 爆炸；
• 右侧：人类先产出 OpenSpec 规格契约→Agent 在契约内执行 90%→机器门禁先行过滤→人类只做高价值判断。

两种路径之间隔着的，正是从"生产力悖论"到"可控交付"的完整跃迁。

一、重新拆解：10% 人类工作，90% 硅基 Agent 执行工作

分工	人类（碳基）10% 核心工作	硅基 Agent（单兵/团队）90% 执行工作
问题定义	撰写 OpenSpec 的 proposal.md、spec.md；明确 Must/Should/Could/Won't-have；写明 Non-Goals、验收标准、不做什么；划定业务边界与爆炸半径	读取已经冻结的规格基线；不允许自己凭空脑补业务意图
架构决策	产出 ADR 架构决策记录；定义 OpenAPI、数据库 Schema 这类宪法点；做模块边界、角色硬约束；定义风险分级，划定哪些变更需要 HITL 人工审批	Superpowers 执行 TDD、切片、单元测试；生成实现代码、迁移脚本；在契约之内完成开发，无权私自修改架构宪法点
结果取舍与判断对错	两阶段评审：spec 合规审查 + 架构质量审查；高爆炸半径变更人工门审批；失败后的方向调整、经验回流，把教训写回 spec 基线	执行三连止损；执行自动化门禁 impact.py、lint、测试套件；产出 artifact、测试报告；遇到越界或重大缺陷向上报到 Harness，等待人类决策

关键认知在于：人类的判断，不能只发生在看完代码 diff 的最后一步。判断要前置到规格定义阶段。 如果把所有判断全部后置到 PR 环节，就会重演 Faros 观测到的现象——PR 数量暴涨、评审时长被大幅拉长、bug 人均上涨，人类被淹没在海量 AI 产出的代码里。

传统误区是：人类聊天框口述需求→AI 自由实现→人类看代码 diff 判断对错。所有判断全部后置，这就是 Vibe Coding。✅ 硅基范式则是：人类先产出 OpenSpec 范围层的规格契约，完成问题定义与架构决策→硅基单兵/团队在契约内执行 90% 实现工作→机器门禁先做大规模过滤→人类只做高价值的结果取舍。

# proposal.md 核心骨架（5-10行关键代码）
## Must Have
- 图书CRUD API，支持ISBN唯一校验
- 借阅记录关联用户ID

## Won't Have（Non-Goals）
- 暂不实现借阅过期罚款
- 不涉及支付流程

## 验收标准
- 单元测试覆盖率 ≥ 80%
- API响应时间 < 200ms

这段 proposal.md 骨架是"人类 10% 工作"的第一份工具：用 Must/Won't-Have 把"做什么"和"不做什么"同时冻结，再配上验收标准与覆盖率/响应时间硬指标，把模糊的业务意图压缩成机器可读的边界。

---

二、为什么"口头把需求说清楚"远远不够？

很多人被 Devin 案例误导，以为只要人语言表达能力强，就可以甩开规格工具。现实里却有三层绕不开的缺陷。

(1) 自然语言没有强制不可修改的基线，极易发生 spec 漂移

聊天会话的内容可以被遗忘、被上下文冲刷，Agent 也可以选择性忽略人类的口头约束。口头的"不要做动态角色"经过多轮迭代之后可能直接消失。而 OpenSpec 范围层 specs/ 目录下面的批准基线，是磁盘上的永久工具。Agent 只能只读，修改动作必须走 changes 变更提案流程。

(2) 缺少可校验的验收依据，"判断对错"没有客观标尺

口头需求不存在标准化验收标准。人类看完代码之后，才一边读 diff 一边反向脑补当初的需求，评审成本会变得非常高。OpenSpec 范围层工具会把验收标准与边界条件写进 spec——判断对错的标尺是提前存在的，不是临时脑补出来的。

(3) 单兵升级硅基团队之后，口头需求完全不可规模化

当你从单个 Agent 升级为多 Worker 硅基 Team，Codex、前端、评审 Agent 多个实例同时运行。口头对话无法在多个 Agent 之间共享真相源。如果没有 OpenSpec 全局基线，每个 Agent 各自解读人类的自然语言，必然出现理解分裂。

Scott Wu 的观察是对的：90% 执行交给 AI。但前提条件是——人类要把 10% 的问题定义、架构决策转化为机器可读的规格契约，而不是停留在自然语言聊天里。没有这层前置，Agent 越强，制造的混乱就越大。

左侧 spec.md 片段用 BDD 场景（given/when/then）把验收标准写成可执行用例；右侧把"口头需求三层缺陷"（无强制基线/spec 漂移、无验收标尺/评审爆炸、不可规模化/多 Agent 分裂）逐层映射到"OpenSpec 工具解法"（磁盘永久基线、标准化验收场景、全局唯一真相源）。

---

三、映射到硅基四层架构：人类的 10% 工作落在哪些组件？

复盘一下硅基四层架构：OpenSpec 范围层、Superpowers 执行纪律层、Harness 调度层、治理层。

• Agent 绝大部分工作运行在"范围层只读访问"+ 执行纪律层 Superpowers 上；
• 人类的核心职责集中在 OpenSpec 基线评审、Harness 调度层任务拆解、治理层 HITL 人工门、经验回流的整个闭环里。

这里的"人类职责"不是口头叮嘱，而是被显式编码进四层组件并形成机制化关卡。

1. OpenSpec（范围层）：人类完成问题定义与业务边界划定

人类主导产出 proposal、spec、ADR、OpenAPI/Schema 宪法点；评审变更提案，归档合并进入 specs/ 批准基线。Agent 可以辅助生成 spec 草稿，但基线的业务决策、Non-Goals、边界约束的最终决定权属于人类。Agent 只能产出局部 changes 变更提案 artifact，不能直接改写全局批准基线。

2. Superpowers（执行纪律层）：硅基 Agent 承担的 90% 执行工作

TDD 红灯绿灯、任务切片、编写单元测试、编码实现、自测、三连止损，遇到问题上报。本层不做业务层面的问题定义与架构决策，严格服从 OpenSpec 基线。

3. Harness 调度层（ACP）：人类做顶层任务拆解，Lead 只派活不写业务代码

人类给 Lead（Harness）输入高层业务意图，Lead 把意图转化成五契约任务包，通过 ACP 分发给各个 Worker 单兵 Agent。Harness/Lead 本身不做业务实现；Worker 单兵拿到任务包后，内部跑完整单兵闭环。

4. 治理层：人类做架构与风险取舍，HITL 人工门

• 风险分级：区分低风险小修改与高爆炸半径变更（数据库大改、权限体系）；高风险动作触发人类审批门；
• 两阶段审查：第一阶段 spec 合规审查（对照 OpenSpec 基线，判断实现是否符合意图），第二阶段代码质量审查；
• 经验回流：线上缺陷回溯到 OpenSpec 工具，如果是 spec 缺失边界，由人类主导把约束回流写入全局基线，完成组织知识沉淀。

# ADR 架构决策记录模板（5-10行关键代码）
# ADR-003: 选择FastAPI而非Flask
## 背景
需要异步支持 + 自动OpenAPI文档生成

## 决策
采用FastAPI作为图书管理服务后端框架

## 宪法约束（写入OpenSpec全局基线）
- 所有API必须产出OpenAPI 3.1 schema
- 禁止引入Flask依赖

这段 ADR 是架构决策的"宪法点"工具：背景→决策→宪法约束三段式，把"为什么选 FastAPI、禁止 Flask、必须产 OpenAPI 3.1"固化为不可随意推翻的基线条目。

重要反模式（很多 Devin 类 Agent 使用者的踩坑点）

❌ 反模式：人类只丢一大段自然语言 prompt，直接让 Agent 全权处理，Agent 自己去推导边界、自己做架构决策、自己改"spec"。后果是 Agent 在执行的同时兼任"问题定义 + 架构决策 + 编码实现"，人类只剩最后看代码 diff 这一道关口。全部压力后置到交付之后，自然重现生产力悖论：PR 很多，返工很多，组织收益很低。

✅ 正确模式：人类完成 OpenSpec 工具（问题定义 + 架构决策），冻结基线；Agent 在契约边界之内完成 90% 的执行工作；机器门禁先行过滤；人类只负责处理高风险审批与结果取舍。

上图把"人类 10% 工作落点"（OpenSpec 范围层、Harness 调度层、治理层 HITL）与"Agent 90% 执行工作"（Superpowers 执行层、只读基线产出局部提案）用带箭头的契约关系串起来：人类冻结基线→Agent 执行→artifact 回传→治理层取舍→经验回流。

---

四、完整人机协同工作流：融合 Scott Wu 观点与硅基单兵到硅基团队

还是沿用前面的图书管理 Demo 举例：开发图书借阅后台。

1. 人类完成 10% 核心工作（问题定义、架构决策）

人类主导产出 OpenSpec：proposal.md 明确 Must/Won't-have（Won't-have：暂不实现借阅过期罚款）；产出 spec、OpenAPI 契约、数据库 schema、ADR 架构记录；评审提案，归档进入 openspec/specs/ 全局基线。Agent 可以辅助生成草稿，但业务边界与 Non-Goals 由人类最终确认。

{
  "input": {
    "specRef": "/abs/openspec/specs/book-borrow.md",
    "roleConstraint": "Codex后端，禁止写UI"
  },
  "output": "借阅API实现+单元测试",
  "artifact": ["borrow.py", "test_borrow.py"],
  "specChange": "仅产出局部变更提案",
  "testReport": "tests/borrow_report.md"
}

这段五契约任务包 JSON 是"人类意图→硅基团队"的传输载荷：input 携带 OpenSpec 基线路径与角色约束（Codex 后端禁写 UI），output/artifact/specChange/testReport 定义了交付与验收口径。Harness 把人类高层意图转成结构化任务包经 ACP 下发，Worker 只读基线履约。

2. Harness Lead 接收人类高层意图，组装五契约任务包

任务包携带 OpenSpec 工具路径，Worker 单兵只读全局基线，不能直接改写批准态 spec。

3. 硅基 Agent 承担 90% 执行工作（Superpowers 执行层）

每个 Worker 单兵内部运行完整单兵闭环：读取 spec 基线、/sp:plan、TDD 实现、单元测试、两阶段自审查。如果发现 spec 存在缺陷，产出局部变更提案 artifact，回传给 Harness。Agent 无权直接修改全局 specs 基线。

4. 治理层分层校验（机器优先，人类只处理高价值判断）

① 机器门禁：impact.py 校验改动范围、lint、全量测试套件，不通过直接打回；

② 普通低风险变更：Human-On-the-Loop，机器自动放行；

③ 高爆炸半径变更（数据库 schema 改动、权限）触发 HITL 人工门，人类做架构与风险取舍。

# impact.py 范围门禁（5-10行关键代码）
declared = parse_spec_impact("specs/book-borrow.md")
actual = git_diff_files()
violations = [f for f in actual if not match_any(f, declared)]
if violations:
    print(f"超出spec声明范围: {violations}")
    sys.exit(1)

这段 impact.py 是"范围门禁"的最小实现：解析 spec 声明的改动范围，对比实际 git diff 文件，超界即 exit 1 打回。它把"Agent 是否越权扩大范围"变成可自动判定的硬卡点。

5. 人类做结果取舍与经验回流

人类审阅分两步：第一看是否匹配 OpenSpec 规格契约，第二看代码架构质量。

• 通过：Harness 执行 openspec archive，合并变更写入全局基线；
• 不通过：明确指出 spec 或实现里的缺陷，退回 Agent 重新迭代；
• 如果暴露的根因是 spec 缺失边界：由人类主导，把缺失约束回流更新 OpenSpec 基线，沉淀为组织级知识。

整条链路里，人类并不是等代码写完了才去判断对错。判断的标尺——OpenSpec 规格契约——在编码之前就已经存在了。

---

五、现实误区澄清：不要神话"强大 Agent 可以听懂人话"

很多人认为：模型越来越强，我只需要口述需求，就可以抛弃 spec 工具。结合硅基架构来看，这里有两个关键现实约束。

(1) 单 Agent 小 Demo 场景，口头需求往往可以跑通；一旦进入迭代阶段、多 Agent 团队场景，口头需求往往就会失效。

Demo 一次性任务里上下文是完整的；真实软件项目会持续迭代、会话会被清空、多个 Worker 并行工作，聊天记忆相对并不可靠。OpenSpec 工具的价值，正是提供会话销毁之后依旧能够留存的永不丢失的真相源。

(2) Agent 能力提升，提升的是执行能力，不等于提升"替人类做业务价值判断的能力"。

业务的"要不要做、什么不能做、风险边界"，是业务人的价值判断，不属于代码实现问题。Agent 可以辅助起草 spec，但不能替人类承担业务决策责任。

Scott Wu 说工程师从"砌砖工变成建筑师"。建筑师不是只靠嘴讲房子长什么样，而是要输出图纸——对应 OpenSpec 规格工具——再交给施工队（硅基 Agent）去砌砖。没有图纸，再好的施工队也会盖错房子。图纸，就是 OpenSpec 的 spec 范围基线。

---

六、架构思维：从碳基到硅基团队的范式升维

站在架构视角审视 AI Agent 落地，核心不是工具堆叠，而是契约先行、分层隔离、风险分级的系统思维。架构师需要跳出单点 Agent 能力评估，转向组织生产力体系设计。

首先要做职责分层，把业务决策、规格定义留在碳基人类一侧，执行类工作下沉到硅基 Agent，用 OpenSpec 构建全局唯一真相源，消除多智能体理解歧义。其次要做边界隔离，通过四层架构切割职责域，禁止执行层 Agent 修改基线宪法点，所有变更统一走提案评审流程，以此抑制 spec 漂移。

再依托 Harness 调度层完成任务切片与资源管控，治理层配套 HITL 人工门，依据变更爆炸半径动态选择自动放行或人工审批，平衡交付效率与风险。整套架构设计遵循"先约束，后执行"原则，用自动化门禁、TDD 断言、审计链路形成多层防护，把大模型本身的不确定性隔离在执行层。架构师的核心目标，是构建一套能持续规模化、可审计、可控的人机协同系统，而不是单纯追求 Agent 单次任务的炫酷能力。

真正值得沉淀的架构思维其实只有一句话：用契约约束聪明，而不是用口才驾驭模型。

Agent 执行力越强，系统越需要把"图纸"前置冻结。模型可以不可控地聪明，但生产系统绝不能不受约束地聪明。当每一次变更都可声明、可校验、可归档、可回流，AI 生成速度才会真正沉淀为组织可审计、可规模化的交付生产力。

---

七、总结

(1) Scott Wu 的洞察很有价值：往后 90% 的代码实现、调试、琐碎执行工作都会交给硅基 Agent；人类的核心价值集中在问题定义、架构决策、结果取舍。

(2) 但这三项人类核心工作，不能仅仅依靠自然语言聊天对话来完成。必须固化为 OpenSpec 范围层里可校验的规格契约工具。口头"讲清楚需求" ≠ 产出机器可执行的契约。跳过这一步，再强大的 Agent 往往只会放大生产力悖论：PR 数量暴涨，组织交付指标却原地踏步。

(3) 在硅基四层架构之下：

OpenSpec 范围层承载的是人类的问题定义 + 业务边界 + 架构宪法点；Agent 只能读取基线，不能私自改写处于批准态的基线。Superpowers 执行层承载 Agent 占绝大部分的 90% 编码执行工作；Harness 调度层负责做好任务分发；治理层 HITL 人工门，由人类完成高风险决策、结果取舍、经验回流。

(4) 人机分工的本质：人类输出"图纸"（OpenSpec 规格契约）；硅基 Agent 在图纸约束之内完成绝大部分施工实现；机器先行开展大规模自动化校验；人类只聚焦高价值的架构判断与业务判断。

模型可以越来越聪明，但不可控的聪明，依然比笨拙却受契约约束更危险。图纸——规格契约——才是驾驭 Agent 的根本，而不是人的口才。

左侧的 archive_change 把已评审的 change 合并进 specs/ 全局基线并写审计日志；右侧核心结论图把"人类出图纸→Agent 在契约内施工→机器门禁过滤→人类聚焦高价值判断→经验回流"串成完整闭环。

在云栈社区上，关于 OpenSpec 与多 Agent 架构的落地讨论也在持续积累。当每一次变更都可声明、可校验、可归档、可回流，AI 生成速度才会真正沉淀为组织可审计、可规模化的交付生产力，这也是从"会用 AI"走向"驾驭 AI"最硬的工程分水岭。

延伸阅读：本系列强相关文章

本文把"90% 代码交给 AI 后人的价值 = 产出可校验规格契约"这一命题，落到 OpenSpec 工具与硅基四层架构上。下面 5 篇与本文强相关，建议按"理论→单兵→团队"顺序补读：

1. 理论篇（1）AI Coding 的工程范式重构——建立底层认知：不等式「使用 AI 工具 ≠ 个人提效 ≠ 组织提效」背后存在两道传导关卡；借助快手数据证明单纯加速编码救不了组织效率；区分硅基单兵与硅基团队，给出 Coder→Builder 角色升级方案。

2. 单兵实现篇（1）总论：把闭环机制化与选型——将 Spec→Plan→Implement→Verify 四步闭环 + 门禁 + 切片 + 影响面，落地为状态机与纪律，同时给出 OpenSpec/Superpowers/自定义 Skill 三类载体的选型方案。

3. 单兵实现篇（2）OpenSpec 专篇——讲清楚 specs/（批准态基线）与 changes/（提案态增量）双目录、change-centric 模型、validate/archive 命令，以及"回写规格、不回写聊天记录""影响面闭环留痕"这两条核心纪律。

4. 单兵实现篇（3）Superpowers 专篇——把切片、TDD、止损、站在初级工程师视角评审封装成"加载即强制生效"的 skill 调用，点明它属于改写 Agent 行为契约的流程锁。

5. 硅基团队实现篇（1）总论：从单兵闭环到多 Agent 工程平台——解答"单兵闭环放大 N 倍之后为何往往会塌方"：spec 冲突、token 爆炸、人工审核崩盘、基线漂移这四道壁垒，并给出四层架构的总纲。