Appearance
人机协作模式：从探索到可验证交付
Last updated: 2026-07-27
编程智能体不会取消工程判断。它会放大工程判断。真正重要的能力，是知道什么时候用智能体探索，什么时候把意图固化成规格，什么时候放手让它执行，以及什么时候必须慢下来验证。
为什么 "Vibe vs Spec" 太小了
过去的问题是：应该 vibe coding，还是 spec-first coding？这个问题曾经有用，但对真实工程来说太窄。
vibe coding 不是一套完整研发方法，而是一种探索模式：当想法还模糊、犯错成本很低、目标是把问题变具体时，它很好用。它的产物不是生产代码，而是更清楚的意图。
spec-first 工作也不是全部答案。规格能在目标行为足够稳定时提供约束，但规格本身不能保证正确性。你仍然需要执行边界、测试、审查，以及把经验沉淀回持久上下文的机制。
更好的问题是：
根据需求清晰度、变更风险和验证成本，这次工作应该采用哪种人机协作模式？
本章连接 编程智能体工作原理 里的机制理解，以及 自治级别与人类干预模式 里的控制框架。智能体能读文件、跑工具、改代码；你的工作是为任务选择正确的协作契约。
AI 拉高下限，人拉高上限
最简单的心智模型是：
AI 拉高下限，人拉高上限。
智能体擅长快速给出一版可用基线。它可以起草代码、扫描代码库、枚举边界场景、生成测试和文档，速度远超过人手写。
但上限仍然来自人的判断：
- 什么问题值得解决？
- 什么明确不在本期范围内？
- 哪种架构适合这个系统的未来？
- 哪种失败模式不可接受？
- 哪个取舍符合真实业务语境？
错误不在于使用 AI。错误在于让 AI 替你做那些需要产品语境、架构品味和风险所有权的决策。
当协作有效时，智能体承担重复工作，人类守住方向、约束和验收标准。
协作光谱
把协作看成连续光谱，而不是二选一：
text
Explore -> Frame -> Specify -> Execute -> Verify -> Capture每个阶段都有不同的目标、产物和责任边界。
| 阶段 | 目标 | 智能体角色 | 人类角色 | 产物 |
|---|---|---|---|---|
| Explore 探索 | 把模糊想法变具体 | 原型、提问、列方案 | 反馈、比较、选择方向 | 原型、笔记、待决问题 |
| Frame 定界 | 决定什么重要 | 暴露约束和取舍 | 划边界、定优先级 | 问题框架、非目标 |
| Specify 规格化 | 把意图变成契约 | 起草需求和边界场景 | 修正业务判断 | 规格、验收标准 |
| Execute 执行 | 实现边界清楚的工作 | 改代码、写测试、补文档 | 审查范围和 diff | 可运行变更 |
| Verify 验证 | 证明结果成立 | 运行检查、生成证据 | 判断证据是否足够 | 测试结果、审查记录 |
| Capture 沉淀 | 让经验可复用 | 总结规则、更新文档 | 批准持久上下文 | AGENTS.md、文档、测试 |
这也是为什么 提示词原则 和 使用 AGENTS.md 很早就重要。好的提示词启动循环，持久上下文让下一次循环不必从零开始。
责任分工
最重要的设计决策不是用哪个模型，而是谁负责哪类工作。
只能由人做的决策
这些决策可以让智能体提供输入，但最终拍板必须是你：
- 产品边界：这次解决什么，以及明确不解决什么。
- 架构：服务边界、数据模型形态、缓存策略、系统集成方式。
- 技术取舍：数据库选择、队列模型、并发策略、依赖引入。
- 系统一致性：API 风格、日志规范、错误语义、权限模型。
- 风险接受：什么可以坏，什么不能坏，回滚必须是什么样。
智能体能给出选项和后果，但它不知道你的组织应该重视什么。
AI 起草，人类验收
这是很多应用层项目的主工作区：
- 业务逻辑实现。
- API controller、service、data access 代码。
- 前端页面和组件。
- 单元测试、集成测试和 API 文档。
- 迁移草稿和兼容性说明。
硬规则只有一条：
不要接受你解释不清的代码。
如果你解释不清最终接受的代码，要么需求仍然不清楚，要么实现已经超出了你的控制范围。这两种情况都应该停下来，重新定界。
AI 全权处理的机械工作
有些工作风险低、主要是机械重复：
- 格式化和 lint 修复。
- 简单重命名。
- 样板代码脚手架。
- 脚本和配置生成。
- 基础测试框架搭建。
- 重复性文档更新。
这类任务可以给更高自治度。你仍然要扫一眼结果，但不应该把高级工程师注意力耗在每个 token 上。
这正对应 自治级别与人类干预模式：可逆、边缘、重复的工作给高自治；核心逻辑和高影响半径变更必须严格监督。
需求文档的六维体系
规格如果只是 paperwork，就会失败。规格真正有用，是因为它成为人类意图和智能体执行之间的精确契约。
一份适合编程智能体消费的需求文档，应该覆盖六个维度：
| 维度 | 作用 | 智能体通常能贡献什么 | 人类责任 |
|---|---|---|---|
| 业务目标 | 定义问题和目标用户 | 从现有代码和笔记反推草稿 | 修正方向 |
| 用户场景 | 描述真实工作流和痛点 | 建议常见场景 | 确认真实优先级 |
| 接口契约 | 锁定输入、输出、错误和路由 | 按代码风格起草 | 批准兼容性 |
| 边界场景 | 避免只覆盖 happy path | 枚举技术性失败 | 决定产品行为 |
| 老项目约束 | 避免破坏现有系统 | 从 AGENTS.md、文档和代码提取规则 | 确认哪些约束必须遵守 |
| 不在范围内 | 防止需求膨胀 | 列出可排除项 | 果断砍范围 |
智能体强在代码形状的问题：接口契约、技术边界和老项目约束。它弱在业务目标、优先级和范围取舍。
这就是工作流的核心：让智能体起草它擅长的 70%，然后把你的判断力集中在决定功能是否正确的 30%。
在团队规模上，这会自然连接到规格即单一事实来源（见 英文版 Level 4，中文翻译进行中）。规格不是官僚文档，而是意图的源代码。
一套可复用的交付循环
面对真实功能或老系统改造，可以使用一套可复用的交付循环：
- Discovery 需求调研：定义模块、用户、必需能力、依赖和非目标。
- Data first 数据先行：在 API 形态之前，先设计或检查核心实体、状态表、索引和持久化规则。
- 分层实现：自底向上处理 storage、domain service、DTO/facade、controller，再到 UI。
- 分段验证：每层完成后立刻用单测、API 调用或小型可执行检查验证。
- 端到端验收：跑通一条从数据库状态到浏览器行为的完整用户路径。
- Capture 沉淀：把重复经验转成规格、测试、
AGENTS.md规则、模板或 review checklist。
这个循环能防止智能体漂移，也能把一次成功交付变成未来工作的复利上下文。
在本章后面，上下文管理原则 会解释如何保持上下文干净；子智能体 会解释什么时候隔离高噪声调研或验证任务；系统化思考 会展示如何把 memory、skills、sub-agents、hooks 和工具组合成更大的工作流。
模式切换门槛
工作变了，协作模式也应该变。用明确门槛切换模式。
| 信号 | 从 | 切到 | 原因 |
|---|---|---|---|
| 你一直在改变目标行为 | Specify | Explore | 需求还不稳定 |
| 原型暴露出真实工作流 | Explore | Frame | 已经有足够证据选择方向 |
| 多人或多个系统会依赖它 | Frame | Specify | 意图必须变得可审查 |
| 变更触及数据、鉴权、资金或核心逻辑 | Execute | Verify | 失败成本高 |
| diff 大到你无法舒服地审查 | Execute | Specify | 范围需要拆小 |
| 智能体反复犯同一个错 | Execute | Capture | 规则应该进入持久上下文 |
| review 发现问题在意图，而不只是代码 | Verify | Frame | 问题定义错了 |
这才是对 "vibe 或 spec" 的真正升级：你不是选择一个身份，而是在不同模式之间有意识地移动。
反模式
原型滑进生产。 原型因为"基本能跑"就进了生产。缺失的一步，是把原型中学到的东西转成规格、测试和可审查约束。
规格表演。 文档存在，但没有明确行为、边界场景和非目标。如果智能体仍然要猜关键部分，这份规格就没有发挥作用。
上下文粥。 需求、代码片段、旧决策、失败尝试和随机工具输出都堆在一个长对话里。应该总结、拆分，或把耐久部分沉淀下来。
验证表演。 智能体说测试通过，但没人检查这些测试是否证明了正确行为。证据只有匹配风险时才有价值。
自治错配。 你盯着格式化细节，却草率放过架构决策。应该反过来，把注意力花在失败代价最高的地方。
无人负责判断。 因为人没有说清楚决策，智能体就替你做了产品判断。只要影响用户、风险或长期维护，就需要一个人类 owner。
结论
成熟工作流不是"只靠 vibe"，也不是"永远先写 spec"。它是一套协作系统：
text
意图模糊时探索。
取舍重要时定界。
结果需要被依赖时规格化。
工作边界清楚时执行。
失败成本高时验证。
经验值得复用时沉淀。智能体让软件生产变快，但不会让判断变得可选。
最好的构建者用智能体拉高下限，再用自己的品味、产品感和工程纪律拉高上限。这才是真正的人机协作模式。