coding_agent_workflow进阶约 90 分钟
11D
编码智能体：从“生成代码”到可验证的软件交付
参考：来源 F · 第 26、28 章
学完你能做到
- 区分补全、对话生成与编码 Agent
- 掌握仓库理解、修改、测试和复盘闭环
- 把人放在架构决策和最终质量门位置
什么是编码 Agent
先建立直觉
代码补全像有人替你接着写一句；编码 Agent 像新队友，先看项目、找相关文件、改动、运行检查，再根据错误继续修。
| 阶段 | Agent 应做什么 | 人应保留什么责任 |
|---|---|---|
| 理解 | 读取说明、搜索入口、建立 | 澄清目标和业务边界 |
| 计划 | 列出文件、依赖、测试和风险 | 批准架构级或破坏性方向 |
| 修改 | 小步编辑，保护无关改动 | 提供领域判断 |
| 验证 | 运行类型、测试、构建和视觉检查 | 判断测试是否覆盖真实需求 |
| 交付 | 展示差异、证据、已知限制 | 作为最终决定合并发布 |
一个好的任务简报包含什么
- 要实现的用户结果，以及明确不在范围内的内容。
- 相关入口、约束、代码规范和已有用户改动。
- 验收标准：什么测试、页面或日志能证明完成。
- 风险等级：哪些命令可自动执行，哪些写入、删除或发布必须批准。
- 交付格式：变更摘要、验证结果、已知限制和后续工作。
把一句需求改成编码任务
20 分钟- 将“给网站加登录”改成完整任务简报。
- 列出 Agent 需要先读的文件类别，但不要预先猜具体文件名。
- 设计三层验证：静态检查、自动测试、真实页面流程。
案例推演：编码 Agent 为什么不能从“重写整个文件”开始
用户只要求修复一个边界条件。Agent 若先读不相关目录、重构整个模块再补测试，会增加回归风险，也难以审查。
本节追问：怎样把生成代码变成可验证的软件交付？ 先不要急着看结论。沿着下面四步，逐项区分输入、决策、证据和失败信号。
| 阶段 | 本步要做的决定 | 什么算证据 | 最常见的失败 |
|---|---|---|---|
| 定位行为 | 复现问题并找到最小相关调用链 | 有失败测试或可重复命令 | 只凭报错文字猜原因 |
| 读取约束 | 检查类型、测试、项目规范和相邻实现 | 修改遵守现有接口和风格 | 用个人偏好顺手重构 |
| 最小变更 | 只改解决根因所需代码并补回归测试 | 差异可解释且范围有限 | 一次修改混合修 bug、格式化和升级 |
| 独立验证 | 运行相关测试、类型检查和必要构建 | 验证覆盖原失败与相邻行为 | 代码能生成就宣布完成 |
阅读方式：先遮住后两列自己回答，再用“证据”和“失败”两列检查理解。
常见误解
要求模型“一次写出完整正确代码”
实际上
可观察症状：缺少仓库上下文、运行反馈和回归证据。
更可靠的修复：采用检索—编辑—测试—审查循环，每轮围绕一个可验证假设。
案例工作坊 · 建议真正动手完成
25 分钟- 为一个数组越界 bug 写复现、定位、修改和验证计划。
- 列出最小差异审查的五个问题。
- 说明测试通过仍可能遗漏的两类风险。
查看参考答案
编码 Agent 的价值不只是生成 token，而是能理解仓库约束、做小而可审查的修改、运行工具并用测试证据闭环。
迁移检查：换一个场景还会不会
收到 bug 后第一项高价值动作通常是？
检查一下
编码 Agent 与聊天中生成代码的核心区别是什么？
谁是最终质量门？