硅基coding时代，90%代码 AI写，人的价值是什么？其实，AI Agent 越强，越需要人类画图纸

90%代码 AI写，人的价值是什么？其实，AI Agent 越强，越需要人类画图纸

尼恩说在前面：硅基单兵到硅基团队，是眼下的前沿热点

尼恩辅导了大量小伙伴，从零平地飞起、去做 AI 架构。近日有 VIP 学员面试求助，说猎头问了这么一道题：

你进一家制药企业，从零负责内部 AI 转型，还要带动员工用 AI 的积极性，你怎么着手？

其实，最近一段时间， 尼恩 很多 拿到了 AI架构师 offer的 VIP，都反馈过类似的场景题，比如：

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

这种一系列的问题，最怕以下 的两种答法：

• 一是背工具清单：上 CoPilot、上知识库、上 Agent；
• 二是喊口号：全员 AI 化， 过嘴巴瘾。

尼恩辅导过大量 AI 小白，进大厂如 腾讯、阿里、美团、拼多多、北汽集团、中国移动 做 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 是具备独立长程规划、自带沙盒终端 + 编辑器 + 浏览器工具集，可以端到端跑完完整软件工程任务的独立智能体AI Wiki。

回顾这个一个 Devin 原始发布 案例 核心能力。 Devin 发布会放出的示范案例，也就是硅谷广为传播的 Devin 案例，流程大致如下：

(1) 接收一段自然语言任务描述，自主拆解工程计划；

(2) 在隔离沙盒环境，操作 shell、编辑器、浏览器；

(3) 读取代码库、写代码、跑单元测试、定位 bug、反复调试；

(4) 最终产出代码、提交 PR，完成需求交付；

(5) 官方演示场景：独立搭建生命游戏网页并部署、修复开源库数学 bug、承接 Upwork 外包开发任务、基于论文复现模型微调任务Cognition。

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

传统软件工程中，工程师大约10%精力用于定义问题、架构取舍、判定对错，剩下90%消耗在写代码、调试、修复bug、琐碎实现细节。

现在AI智能体可以接管绝大多数90%的执行工作。

Cognition Devin创始人Scott Wu的结论：AI可以承担90%代码实现执行，人类剩下核心能力是把问题讲清楚、做架构决策、判断结果对错。

很多人就此得出一个简单结论：未来人类工程师只需要"用嘴巴把需求说清楚，让AI干活"。

但结合尼恩硅基单兵‑硅基团队的落地实践，现实会狠狠击碎这个理想化想象：

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

很多团队，在 AI Coding 踩坑，底层原因其实就在这里：

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

快手、Faros的统计现象 复现的下面的 一些大问题 ：

• Agent可以疯狂产出PR，代码生成率大幅上涨
• 但需求交付周期、返工率、spec漂移率这些组织指标没有改善。

这正是硅基架构开篇的核心不等式：使用AI工具 ≠ 个人提效 ≠ 组织提效。

参考文章（《尼恩硅基团队圣经·13-02 理论篇（1）》）：这段不等式正是 13-02 立论的底层认知。

快手数据（交付周期降 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这类宪法点；做模块边界、角色硬约束（Codex不碰UI、前端不碰service）；定义风险分级，划定哪些变更需要HITL人工审批	Superpowers执行TDD、切片、单元测试；生成实现代码、迁移脚本；在已经划定的契约之内完成开发，无权私自修改架构宪法点
结果取舍与判断对错	两阶段评审：①spec合规审查（实现是否匹配规格契约）；②架构质量审查；高爆炸半径变更人工门审批；失败后的方向调整、经验回流，把教训回流更新进spec基线	执行三连止损；执行自动化门禁impact.py、lint、测试套件；产出artifact、测试报告；遇到越界、重大缺陷向上上报Harness，等待人类决策，不私自做业务取舍

关键认知：人类的判断，不能只发生在看完代码diff的最后一步。判断要前置到规格定义阶段。

如果把所有判断全部后置到PR环节，就会重演Faros观测的现象：

• PR数量暴涨441.5%评审时长，bug人均上涨54%，人类被淹没在海量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人工门、经验回流。

参考文章（《尼恩硅基团队圣经·13-09 团队总论》+ 13-05 单兵篇（1）总论）：

这段"人类职责集中在 OpenSpec 基线评审、Harness 拆解、治理层 HITL、经验回流"，正是 13-09 四层架构（范围/执行/调度/治理）的人类职责分配；13-05 补充"单兵靠纪律、团队靠机制"——人类的 10% 工作不是口头叮嘱，而是被显式编码进四层组件并形成机制化关卡。

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 回传→治理层取舍→经验回流。

参考文章（《尼恩硅基团队圣经·13-09 团队总论》+ 13-05 单兵篇（1）总论）：这正是 13-09"四层架构（范围/执行/调度/治理）"的总览图——人类的价值不在写代码，而在范围定义、调度拆解、风险门与经验回流；13-05 补充"单兵靠纪律、团队靠机制"，人类职责被显式编码进四层组件，而不是靠口头叮嘱。

---

四、完整人机协同工作流（融合Scott Wu观点 + 硅基单兵→硅基团队）

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

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

人类主导产出OpenSpec：proposal.md，明确Must/Won't‑have（Won't‑have：暂不实现借阅过期罚款）；产出spec、OpenAPI契约、数据库schema、ADR架构记录；评审提案，归档进入openspec/specs/全局基线。

Agent可以辅助生成草稿，但业务边界、Non‑Goals由人类最终确认。

# 五契约任务包 JSON（5-10行关键代码）
{
  "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 定义交付与验收口径。

参考文章（《尼恩硅基团队圣经·13-14 DeerFlow 专篇》+ 13-09 团队总论）：

• 13-14 定义 ACP 五接口传输的正是这套标准化五契约——Harness 把人类高层意图转成结构化任务包经 ACP 下发，Worker 只读基线履约；
• 13-09 强调"中枢只管派活、不写业务代码"，五契约是人与硅基团队之间唯一不掉链子的协作介质。

2. Harness Lead接收人类高层意图，组装五契约任务包，通过ACP下发给硅基单兵Worker

任务包携带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 Human‑In‑the‑Loop人工门，人类做架构与风险取舍；

# 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 是否越权扩大范围"变成可自动判定的硬卡点。

参考文章（《尼恩硅基团队圣经·13-06 OpenSpec 专篇》+ 13-05 单兵篇（1）总论）：

• 13-06 的"影响面闭环"要求每次变更先声明影响半径、只重跑受影响切片，impact.py 正是该纪律的代码化守门人；
• 13-05 把"不过不许进"做成机制化关卡——范围门禁挂在 CI/子进程钩子，AI 没有说服 bash 忽略越界的空间。

5. 人类做结果取舍 + 经验

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

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

整个流程：人类不是等代码写完才来判断对错；判断的标尺（OpenSpec规格契约）在编码之前就已经存在。

左边 HITL 风险分级代码按"触碰 db 迁移/权限/核心 API"累加风险分，≥8 触发人工审批；右边流程图把"人类产出契约→Harness 组装→Worker 执行→治理层校验→低风险自动放行 / 高风险 HITL→合并归档→经验回流"画成闭环。

---

五、现实误区澄清：不要神话"强大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 生成速度才会真正沉淀为组织可审计、可规模化的交付生产力，这也是从“会用 AI”走向“驾驭 AI”最硬的工程分水岭。

七、总结

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

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

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

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

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

模型可以越来越聪明，但是不可控的聪明，依然比笨拙但是受契约约束更加危险。

图纸（规格契约）才是驾驭Agent的根本，而不是人的口才。

规格契约才是驾驭 Agent 的根本，而非人的口才。

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

延伸阅读：《尼恩硅基团队圣经》系列（16 篇）

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

(1) 理论篇（1）：AI Coding 的工程范式重构（13-02）——建立底层认知：不等式「使用 AI 工具 ≠ 个人提效 ≠ 组织提效」背后存在两道传导关卡；借助快手数据（交付周期降 53%、人均需求提升 38%）证明，单纯加速编码并不能拯救组织效率；区分「硅基单兵」与「硅基团队」，给出Coder→Builder角色升级方案，以及从需求到交付的最小闭环。本文的"口头讲清楚 ≠ 机器可校验契约"，正是从它延伸出来最直白的推论。

(2) 单兵实现篇（1）总论：把闭环机制化与选型（13-05）——将 Spec→Plan→Implement→Verify 四步闭环 + 门禁 + 切片 + 影响面，落地为「状态机 + 五条纪律」，同时给出 OpenSpec/Superpowers/自定义 Skill 三类载体的选型方案。本文里面 proposal/ADR/impact.py/HITL 逐条对应的机制化关卡，都是这套"纪律要机制化、不能只靠提醒"思路的实例化体现。

(3) 单兵实现篇（2）OpenSpec 专篇（13-06）——这一篇就是本文的核心配套：讲清楚 specs/（批准态基线）与 changes/（提案态增量）双目录、change-centric 模型、validate/archive 命令，还有「回写规格、不回写聊天记录」「影响面闭环留痕」这两条纪律。读完它，就能补齐本文没有展开的命令细节，以及"宪法点写入基线"对应的工程锁。

(4) 单兵实现篇（3）Superpowers 专篇（13-07）——把切片、TDD、止损、站在初级工程师视角评审，封装成「加载即强制生效」的 skill 调用，点明它属于改写Agent行为契约的流程锁。本文提到的三连止损、范围门禁、角色硬边界，这一篇会讲明白它们是如何被机制化落地的。

(5) 硅基团队实现篇（1）总论：从单兵闭环到多 Agent 工程平台（13-09）——解答「单兵闭环放大N倍之后为何往往会塌方」这个问题：spec冲突、token爆炸、人工审核崩盘、基线漂移这四道壁垒；给出「单兵依靠纪律、团队依靠机制」的总纲，还有四层架构（范围/执行/调度/治理）。本文的"人类10%工作落点图"，往往就是这套四层架构对应的人类职责分配图。