「让编码 agent 写代码」听起来像一句提示词的事，但 Andrew Ng 在 AI Engineering Skills Map: Using coding agents 里给出了完全不同的答案：这是一项和传统编程并列的核心 AI 工程技能——既能指挥 agent 写代码，也能让它做非代码任务（分析数据、管理系统运维），而且它演化得比 AI 工程其他顶级技能都快。
为什么快？专有 agent（Claude Code、Codex、Cursor）和开源 agent（OpenCode、Pi）都在同时改进 harness 与模型两侧，跟上它的唯一方式，是持续的实验、搭建与学习循环。
这篇文章值得拆开读的，是作者访谈数十位顶级 AI 工程师、并结合团队实践后总结出的高层工作流与五项关键技能。它没有停留在「把需求丢给 agent」的层面，而是把这件被社交媒体过度简化的事情还原成了一套可执行的方法。
先看工作流：计划和规格重新成为主角
用编码 agent 造软件的高层工作流，与没有 agent 的时代相似——但关注点变得不同：我们不太再聚焦代码本身，而是聚焦决定造什么、设计架构、写规格、验证输出。 分三步：
- 计划。 包括头脑风暴——研究、实验、理解现有代码库（如果有）；然后写一份规格，捕获需求、技术设计与架构，再生成执行计划。关键动作是审查计划：质疑其中的关键假设，检查安全风险、过度工程化和其他缺口。
- 执行。 在这里构建、测试、验证，保持 agent 自主性与人类监督之间的平衡：让 agent 以校准过的自主度构建软件，再用自动化或人工检查验证产出。
- 部署与监控。 部署——可以用 CI/CD 流水线或额外的人工门禁把守；然后让 agent 盯日志、暴露问题、提出并执行改进。
各步骤的时长差异很大，也可以省略。绿地原型（从零开始）的规格，可能就是快速写下的一个提示词；而棕地项目（已有系统、用户众多）的规格，需要更多精力来编写和验证。工作流高度迭代：熟练的开发者知道什么时候该让后一步的反馈把自己带回前一步——验证失败，就指挥 agent 重建并修复错误；监控发现问题，就让 agent 更新系统并重新部署。
五项关键技能
围绕这条工作流，作者提炼出五项技能。注意它们的共同点：没有一项是「提示词写得漂亮」。
1. 导航工作流
你得知道怎么走完上面每一步，并决定每步该投多少人类精力、多少 agent 精力，什么时候回退到更早的步骤迭代。这要求深入理解速度、成本、技术风险与人力投入之间的取舍：前期该做多少调研和计划，什么时候把关键工作保留给人类，架构怎么选，计划制品（比如规格）要写多细，以及如何把任务拆成可验证的步骤。
2. 校准 agent 自主度
自主度不是开关，而是一个连续谱：是盯着 agent 来回交互，还是委托更大一块工作？什么时候设定清晰目标让它循环直到成功？这里还有几件容易被忽略的事：
- 上下文管理。 随着构建推进，要持续把关键学习、用户反馈和假设变化写进 agent 能用的上下文——尤其那些中途变了的假设。
- 并行编排。 决定是否把任务分解后让多个 agent 并行跑（由人或更高层的 agent 编排），以及如何在多个并发会话间分配自己的注意力。
- 安全运行。 设置权限、给操作加门控，让开发快速推进的同时限制泄漏、数据丢失或其他破坏的风险。
3. 审查产出
编码 agent 的输出是不确定的——事先不知道它会想出什么好主意，也不知道它会引入什么 bug。审查与验证是确保你得到想要结果的关键步骤：
- 设计与任务匹配的测试，行为验证与功能验证按需组合；测试用户流程时，可以让 agent 提供截图作为成功或失败的证据。
- 定性或行为评估可以用 eval 集，可能配 LLM-as-a-judge。
- 决定多少测试自动化；主动评估测试是否对应真实目标，不对就演进它们。
- 用 agentic code review 和 AI 安全与架构审计；当 AI 审查不够时，有判断地插入人工审查——审查行为，偶尔审查代码——同时继续探索如何进一步自动化。
- 最后验证部署，并用 agent 把监控与事故管理运营化。
注意作者的措辞：「有判断地」插入人工审查，而不是无脑全审。
4. 定制 agent 及其环境
这项技能关于「装备」你的 agent：集成 skills、插件和 MCP 服务器，并在不再必要时剪掉它们（比如新模型让某个 skill 过时）；用 hooks 自动化重复环节，比如触发自动代码审查或 CI/CD；维护 agent 工作的上下文——用 AGENTS.md/CLAUDE.md 持续记录代码库信息、关键架构假设、代码风格与数据访问模式；在多个会话与并行 agent 之间保留状态，通过事后复盘（retrospective）积累「什么行、什么不行」的经验；建立一致的约定与结构让代码库对 agent 可导航；偶尔清理 agent 生成的债；在团队里协调不同开发者各自的 agent 之间的上下文。
把 AGENTS.md 当作文档的人，和把它当作持续维护的产品的人，用 agent 的效果会拉开差距。
5. 理解编码 agent 的原理
最后，这里给了「黑盒」一个出口。理解 agent 如何工作，能让你在整条工作流里做出更好的决定：它怎么搜索/检索代码库、怎么管理上下文窗口、各种操作（添加工具调用、MCP 服务器等）如何影响上下文、agent 与 subagent 如何交互、agent 本质上是在 LLM 外面包了一层 harness。
这些原理直接对应可识别的失败模式：把简单方案过度工程化；因为 agent 缺少显式验证流程而失去严谨；停在离目标半步；以及 agent 动作有损毁文件或生产数据的风险。理解之后，你才能给对处方、给对上下文，并在监控运行中发现它走偏时及时介入。
一个现实矫正：长时自主运行被高估了
作者最后给了一个很有分量的判断：社交媒体上对编码 agent 的描述经常过度简化。有时让 agent 自主运行数小时、烧掉数百万甚至上千万 token 确实有用——但当前超长时程任务的实用效用，尤其是相对成本而言，被放大到了超过现实的程度。 大多数有效的编码 agent 使用，是一个复杂、高度迭代的过程，高技能的介入会带来好得多的结果。
这和我们最近的观察是一致的：真正把 agent 用好的团队，比的不是谁让它跑得更久，而是谁更会校准自主度、谁更认真审查、谁把环境维护得更干净。
现在就能检查的五件事
把五项技能转成一次自评，每项问自己一个问题：
- 导航工作流：我最近一个任务，规格里写清了假设、验收标准和安全边界吗？还是只有一句「做出来」？
- 自主度：我今天是选择了一个明确的自主度，还是默认放任？权限和门控设了吗？
- 审查：我的验证是「跑通就行」，还是行为与功能两层都有证据？eval 集（哪怕很小）存在吗？
- 定制环境：
AGENTS.md/CLAUDE.md是三个月没动过，还是跟随架构假设更新？过时的 skills 剪掉了吗？ - 原理：这个 agent 在检索什么、上下文里有什么、一个工具调用会怎样占用窗口——我说得清楚吗？
如果五题里有三题答不上来，这篇所描述的差距就真实存在。好消息是它不依赖模型、不依赖工具：校验自主度与门禁、把环境写成持续维护的文档、坚持审查证据，今天就可以开始。
Aide Hub 会继续分享 AI 助手、开发工具与软件工程实践中的具体做法。