编程智能体 SOP：规划→执行→监控，一张可复制的全链路清单

这是「吴恩达 AI 工程技能地图深挖」系列的第 ② 篇，对应地图第 12–16 格「使用编程智能体」。总纲：20 格自测与 12 周落地路线｜上一篇：Evals 实操手册

吴恩达在技能地图 Part 4 里对社交媒体的用法描述给了一句罕见的直接批评：

我发现社交媒体往往对如何使用编程智能体给出过于简化的描述。……目前，超长时程任务的实际效用——尤其是相对于其成本而言——被夸大了，超过了现实。相反，大多数有效的编程智能体使用，是一个复杂、高度迭代的过程，而能够以高水平判断进行干预，往往能带来好得多的结果。

"过于简化的描述"之所以流行，是因为它好传播：给个目标，让 Agent 自己跑。而真实的工作流有三段、每一步都有明确的输入、产出与检查点。这篇把它整理成一条可复制的 SOP。

一、全景：三段工作流

吴恩达在与数十位顶尖 AI 工程师访谈后，给出一条一致的高层工作流：

① 规划 Planning
   ├─ 头脑风暴：研究、实验、理解既有代码库
   └─ 写规格（spec）：需求 + 技术设计 + 架构 → 生成执行计划
      └─ 人的两个动作：质询关键假设 / 检查安全性、过度工程与其他缺口

② 执行 Execution
   ├─ 让 Agent 构建（自主性档位可调）
   └─ 用自动化 + 人工检查验证产出

③ 部署与监控 Deployment & Monitoring
   ├─ 部署（CI/CD 或人工 Gate 把关）
   └─ 用 Agent 读日志、暴露问题、提出并执行改进

两个常被忽略的性质：

项目差异极大：绿地原型的 spec 可能是一句提示词；棕地项目加大量用户，spec 需要重投入。
高度迭代：验证失败要引导重建；监控发现问题要回到上一步。SOP 的价值不是"一次走完"，而是知道每次该回到哪一段。

二、第①段：规划——spec 到底写什么

2.1 写不够和写太多，都是病

两种常见死法：提示词太模糊（"帮我把它做得更好"），或者把一份 RFC 级别的文档整个塞进上下文。后者的失败原因很具体：上下文窗口与模型的"注意力预算"有限，而且研究已证实"指令越多、每条被遵守的程度越低"（业内称为 curse of instructions）。

Addy Osmani 的建议很实用：先给高层愿景，让 AI 展开细节。你提供目标与少量核心需求（像一份 product brief），让 Agent 生成详细 spec；你保留方向控制权。已经有硬性技术约束时，才反过来自己写细。

2.2 一份合格 spec 的六个必备区（可当 checklist）

GitHub 团队分析 2,500+ 份 agent 配置文件后发现，最有效的 spec 覆盖六个区域：

#	区域	要求
1	Commands	完整可执行命令 + 参数，如 `npm test`、`pytest -v`；放在显眼位置
2	Testing	跑测试的方式、框架、测试文件位置、覆盖率期望
3	Project structure	源码、测试、文档各自在哪
4	Code style	一段真实代码示例胜过三段文字描述
5	Git workflow	分支命名、提交信息格式、PR 要求
6	Boundaries	绝不能碰的东西：密钥、依赖目录、生产配置

同一份研究还给出一个高频结论："绝不提交密钥"是出现频率最高的有效约束。

2.3 把边界写成三档，而不是一列"不要"

扁平的黑名单容易失效，因为 Agent 分不清"要不要问一下"。更好的结构是三层：

档位	语义	示例
✅ Always	直接做	提交前跑测试、遵守命名规范、错误上报到监控
⚠️ Ask first	先问人	改数据库 schema、加新依赖、改 CI 配置
🚫 Never	硬停	提交密钥、编辑 `node_modules/`、无授权删除失败测试

这正好也是把"绝不能让 Agent 自主执行的动作"从提示词防线，升级为权限与 Gate 防线的地方。

2.4 先只读、再动手

让 Agent 在只读模式下先探查代码库并产出计划（如 Claude Code 的 Plan Mode），让它主动问你歧义点、审查架构/安全/测试策略，直到"没有歧义的余地"，再放开执行。这一步的收益是：你改的是计划，而不是代码。

2.5 spec 是活文档

把 spec 存进仓库（如 SPEC.md）并纳入版本管理——它在你和 Agent 之间充当"共享事实来源"，在会话重启、上下文丢失后依然是锚点。决定改了、功能砍了，都要回写。

与技能地图的对应：这一步就是第 12 格"引导工作流"的核心动作——决定 spec 写到多细、把工作拆成哪些可验证的步骤。

三、第②段：执行——自主性档位与上下文分配

3.1 先选档位，再开工

吴恩达给出三档自主性，并要求你能说出这次为什么选它：

档位	适合
盯着做、来回交互	高风险、强探索性、方向未定
委派一大块工作	目标清晰、有验证手段（测试）兜底
给定目标、循环到成功	有明确成功判据且可自动验证的任务

关键纪律：并行跑多个 Agent 时，管理的是"你的注意力"。任务要真正独立（别让两个 Agent 写同一个文件），起步先限制在 2–3 个。

3.2 一次只喂一块：模块化上下文

三个可直接用的技巧：

拆分 spec：后端任务只给后端那节，前端任务只给前端那节；跨会话切换大功能时开新会话，避免陈旧上下文干扰。
扩展目录（extended TOC）：让 Agent 先产出一份"每节关键点 + 引用标记"的摘要索引放在上下文里，细节按需再取。它相当于给 Agent 一张随时可查的心智地图。
子智能体分工：给子 Agent 各自的 spec 切片与更小的上下文窗口（如"数据库设计者""API 实现者"），由一个主 Agent 或人来编排。

3.3 环境也要定制（第 15 格）

吴恩达在 Part 4 把"定制智能体及其环境"单列成一项技能，具体动作包括：

集成并适时裁剪技能、插件、MCP 服务器（新模型可能让旧技能变得多余）；
用 hooks 把可重复流程自动化（触发代码评审、CI/CD）；
维护驻留上下文（AGENTS.md / CLAUDE.md）：代码库概况、关键架构假设、代码风格、数据访问模式；
跨会话、跨并行 Agent 保留状态，做事后复盘沉淀经验；
建立让代码库"对 Agent 可导航"的约定，并定期清理 Agent 生成的技术债。

四、第③段：监控与审阅——什么算"做完了"

Agent 的输出是不确定的，所以"完成"必须由证据定义，而不是由它宣布。

验证类型	做法
功能验证	单测/集成测试、契约测试；用户流程测试可让 Agent 提供截图作为成败证据
行为验证	定性输出用评测集 + LLM-as-a-judge（见系列第 ① 篇）
自检指令	在 prompt 末尾要求："实现后对照需求清单逐条确认，列出未覆盖项"
契约测试	把 spec 派生成语言无关的一致性用例（conformance suite），任何实现都必须通过
代码评审	智能体式代码评审 + AI 安全/架构审计；必要时插入人工评审

两个校准动作：

给测试定"力度"：测试投入应与出错的代价匹配（吴恩达在 Part 2 生产运维一节的原话）；
反过来审你的测试：确认它对应你的目标，不对就演化它。

四个失败模式与对应防护（原文列举，值得逐条对照）：

失败模式	防护
简单方案被过度工程化	spec 里写明"保持简洁、不要引入额外抽象"；按任务复杂度调整 spec 详略
缺少显式验证流程而失去严谨性	强制"定义 done 的判据"，并让 Agent 自己跑测试
没达到目标就停下	明确成功判据 + 循环到成功的档位 + 自检清单
Agent 动作破坏文件或生产数据	权限与 Gate（Never 档硬停）；只读模式先规划

五、一条可复制的 SOP（按顺序执行）

A. 规划（人来主导）

用 3–5 句写清"问题定义"：用户是谁、要什么、成功长什么样。
让 Agent 在只读模式下探查代码库，产出 spec 草案。
对照六要素补全 spec；补齐三段边界（Always / Ask first / Never）。
让 Agent 生成执行计划；你只做两件事：质询关键假设、检查安全/过度工程/缺口。
把计划拆成可独立验证的小步骤，写清每一步的验收方式。

B. 执行（Agent 主导、人定档位）

为这一步选定自主性档位，并写下选择理由。
只喂这一步需要的 spec 切片与上下文。
关键假设中途变化时，主动回写 spec / AGENTS.md，避免下游用旧前提。

C. 监控（证据主导）

让 Agent 跑测试并给出证据（含 UI 截图）；定性输出走评测集。
部署走 CI/CD 或人工 Gate；给关键动作上权限门禁。
上线后让 Agent 读日志、暴露问题、提出并执行改进——回到步骤 5 或 3。
事后复盘：记录哪些假设错了、哪些技能/插件该裁剪，更新 AGENTS.md。

六、两条不能忘的边界

1. "vibe coding" ≠ "AI 辅助工程"。 快速原型用前者完全合理，但把原型代码不做 spec、测试、评审就推上生产，是在赌运气。先想清楚自己当前在哪一种模式里。

2. 三个性质让 Agent 天然危险（Simon Willison 称之为 lethal trifecta）：

速度：它比你评审得快；
不确定性：同样输入，输出不同；
成本：便宜到诱使你削减验证。

对应的自律很简单：别让速度超过你的验证能力。Willison 的另一条个人准则是——"我不会提交一段我无法向别人解释的代码"。

七、小结

三段工作流里，规划段最容易被跳过、也最贵：真正的杠杆是"改计划"而不是"改代码"。
spec 不是越细越好，而是六要素齐全 + 三档边界清楚 + 控制长度。
自主性档位要主动选择，不是默认拉满；并行时管理的其实是你的注意力。
"完成"由证据定义：测试、截图、评测集、契约用例。
记住原文那句判断：高水平的判断力介入，远比让 Agent 长时间自治更有效。

下一篇进入地图的第 2 格：当"塞进 prompt"不再够用时，向量索引、知识图谱、语义层该怎么选。

参考来源

Andrew Ng, The AI Engineering Skills Map Part 4 — Coding Agents: How to Use Coding Agents Effectively from Planning to Execution and Monitoring，2026-09-04（三段工作流、五项技能、四个失败模式、"超长时程被夸大"论断）
Addy Osmani, How to write a good spec for AI agents（六要素来自 GitHub 对 2,500+ agent 配置的分析；三档边界：Always / Ask first / Never；模块化上下文与扩展目录；Plan Mode）
GitHub, Spec-driven development with AI（Specify → Plan → Tasks → Implement 四阶段）
Simon Willison, Vibe engineering（"house of cards code"、lethal trifecta、可解释性准则）
本站：Evals 实操手册：从 100 条 trace 到一张失败分类表｜总纲：20 格自测与 12 周落地路线

说明：第五节 SOP 为本站基于上述来源整理的可执行清单，非吴恩达或 Addy Osmani 原文表述。