Coding Agent 的完整工作流程包含哪些阶段？
| 阶段 | 核心动作 | 完成标准 |
|---|
| 项目理解 | 建立整个项目的认知框架，必要时补齐文档 | 知道模块与依赖关系 |
| 需求澄清 | 探索边界、必要时与用户对话 | 目标、权衡、瓶颈明确 |
| 设计文档 | 把抽象需求转为具体实现计划 | 用户审查并批准 |
| 实现与测试 | 写代码、写测试、跑到全绿 | 测试通过而非代码写完 |
| 自我审查 | 批判性审视自己的产出 | 无已知缺陷遗留 |
| 文档同步与交付 | 更新架构文档 | 文档与代码共同演化 |
- 原则: 计划先于行动、验证贯穿始终、文档与代码共同演化;
复杂需求为什么必须先澄清？
- 简单任务: 修正已知 bug、调整函数参数这类边界清晰、影响有限的需求可直接实现;
- 模糊性来源一: 用户知道想要什么但无法精确表达;
- 模糊性来源二: 实现路径多样，多种方案各有取舍;
- 模糊性来源三: 影响范围广，需改多个模块并可能破坏现有功能;
- 例证: “优化系统性能”要先问清目标是响应时间、内存还是吞吐，可接受哪些权衡（改接口？降低易用性？），当前瓶颈在哪;
- 代价: 在需求模糊状态下开始编码往往导致大量返工;
设计文档的作用是什么？
- 回答: 修改哪些模块及原因、采用什么方案及其相对优势、引入哪些新依赖、预期对系统的影响;
- 作用一: 迫使 Agent 深度思考，在投入编码前先在概念层面验证可行性;
- 作用二: 为人类提供高效介入点——审查简洁的设计文档远比审查数百行代码容易;
- 流程: 完成后提交用户审查，等待批准再继续;
测试-修复循环为什么是可靠性的分水岭？
- 覆盖: 正常路径、边界条件、异常情况;
- 失败处理: 不向用户报告失败，而是分析原因、定位问题、改代码直到所有测试通过;
- 迭代: 循环可能需要多次，正是这种自我纠错把 Coding Agent 从代码生成器提升为可靠工程助手;
- 常见偷懒: 写完代码不跑测试就报告“任务完成”;
- 完成标准: 把“测试通过”而非“代码写完”定义为完成，是 Loop 工程“由验证判定何时可以停”在编码场景的落地;
自我代码审查检查什么？
- 检查项: 可读性与注释、潜在性能问题或安全漏洞、是否遵循项目风格与最佳实践;
- 手段: 阅读代码、运行 lint、调用专门的代码审查子 Agent;
- 处理: 发现问题回到修改阶段，而不是把缺陷交付给用户;
文档同步为什么不能省？
- 触发条件: 引入新模块、改变模块间依赖、修改核心抽象语义等架构级变化;
- 理由: 过时文档比没有文档更糟糕，它会误导未来的开发者;
- 效果: 每次重要修改后自动更新，维持项目知识库的完整性与时效性;
真实产品会完整走完流程吗？
- 现实: Claude Code、Codex 等按需裁剪——简单 bug 修复跳过设计文档，任务复杂、影响面大时才走完各阶段;
- 定位: 完整流程是推荐的工程化流程，不是固定脚本;
“何时停止收集信息、开始行动”的阈值由什么决定？
- 两种风格: 有的模型先广泛阅读目录、实现、调用方和测试；有的只读少数最可能相关的文件就提交补丁，把编译与测试反馈当作调查的一部分;
- 归属判断: 这首先是模型学到的行为策略，而不只是 Coding 产品的界面风格;
- 证据一: 更换 Harness 后阈值仍可能随模型保持不变;
- 证据二: 同一 Harness 内切换模型，阈值也可能随之改变;
- 作用面: Harness 的提示词、工具与预算能放大或抑制它，但不必是它的来源;