文章目录
- 1 -> 引言
- 2 -> Coding Agent 改变了工作的最小单位
- 3 -> 把 Issue 写成可执行契约
- 4 -> 仓库必须先为 Agent 做好准备
- 5 -> 一次可靠任务的七个阶段
-
- 1. 只读探索
- 2. 形成计划
- 3. 隔离执行
- 4. 小步修改
- 5. 自动验证
- 6. 真实环境验证
- 7. 交付与审查
- 6 -> 并行 Agent 的正确使用方式
- 7 -> 代码审查要从风格转向不变量
- 8 -> 测试也可能是 Agent 共同犯错
- 9 -> 案例：一次跨模块权限修复
- 10 -> 团队应该衡量什么
- 11 -> 常见误区
-
- 让 Agent 自由修改整个仓库
- 用最快完成衡量最好模型
- 跳过计划直接实现
- 因为测试通过就取消人工审查
- 把领域知识交给模型代替
- 12 -> 团队落地清单
- 13 -> 结语
1 -> 引言
代码补全时代，人仍然掌握每一步：选择文件、决定实现、输入代码、运行测试。Agentic Coding 时代，开发者可以提交一个问题、需求或迁移目标，让 Agent 探索仓库、制定计划、编辑多个文件、运行命令、修复失败并准备 Pull Request。
这种变化提高了可委派工作的上限，也扩大了错误半径。一个补全错误通常影响几行代码，一个长任务 Agent 可能同时修改模型、数据库、权限、测试和部署配置。团队不能只比较“谁生成代码更快”，而要比较谁能在真实仓库中理解边界、产生可审查变更并用证据证明结果。
OpenAI 将 Codex 桌面应用定位为管理并行 Agent 的工作台；Anthropic 对大量 Claude Code 会话的研究则指出，领域专业知识没有失去价值，理解越深的人通常越能让 Agent 完成高质量工作。
2 -> Coding Agent 改变了工作的最小单位
过去的最小单位是函数、代码段或文件。现在更常见的是：
- 修复一个能够复现的 Bug；
- 实现一个带验收条件的用户故事；
- 完成一个跨模块重构；
- 迁移依赖并处理兼容问题；
- 增加测试和浏览器验证；
- 调查 CI 失败并提交修复；
- 审查一个 Pull Request 的安全与回归风险。
任务单位变大后，最大的瓶颈从输入速度转向任务定义和验收。如果需求只是“优化这个模块”，Agent 无法知道目标是性能、结构、可读性还是稳定性，更无法判断可以改变哪些外部行为。
3 -> 把 Issue 写成可执行契约
一个适合 Agent 的 Issue 应包括：
问题：用户或系统观察到什么。
期望：完成后可观察行为是什么。
范围：允许修改的模块与禁止范围。
复现：最小输入、环境和步骤。
不变量：必须保持兼容的行为。
验收：测试、构建、截图或指标。
风险：权限、迁移、数据和部署影响。
例如“修复登录问题”信息不足；“当刷新令牌过期时，Web 端应清理本地会话并跳转登录页，不循环请求；保持移动端行为不变，并增加前端集成测试”才是可执行契约。
4 -> 仓库必须先为 Agent 做好准备
Coding Agent 最依赖以下基础：
- 清晰的目录和模块边界；
- 能在本地稳定执行的测试命令；
- 可读的错误输出和退出码；
- 版本化的数据库迁移；
- 不含密钥的开发环境；
- 规则文件和贡献指南；
- 代表真实行为的测试夹具；
- 可重复启动的服务与浏览器环境。
如果人类工程师需要三天才能把项目跑起来，Agent 也不会凭空解决环境债务。Agent 放大的是现有工程系统：反馈快、边界清楚的仓库会加速；脚本脆弱、文档过期的仓库会产生更多噪声。
5 -> 一次可靠任务的七个阶段
1. 只读探索
先了解架构、相关文件、测试和当前工作区状态，不立即修改。探索阶段应输出代码事实和未知项，而不是过早决定方案。
2. 形成计划
计划说明修改点、文件、数据流、风险和验证命令。复杂或高风险任务应由人确认计划，再开始实现。
3. 隔离执行
使用独立分支、Worktree 或云环境，避免多个 Agent 写同一个工作区。隔离不仅减少 Git 冲突，也方便取消和比较方案。
4. 小步修改
每一步保持可理解，先改核心行为，再补测试和文档。不要顺手重构无关模块，否则审查者难以判断哪些变化是必要的。
5. 自动验证
运行最相关测试，再扩大到类型检查、lint、构建和集成测试。失败必须列出，不能只报告最后一次成功命令。
6. 真实环境验证
用户可见行为需要浏览器或应用验证。构建成功无法证明小屏幕没有遮挡、登录状态正确或导出文件可用。
7. 交付与审查
提交变更摘要、完整相关 diff、验证结果、范围外改动和未解决风险。审查者根据证据裁决，而不是根据 Agent 的信心。
6 -> 并行 Agent 的正确使用方式
适合并行：
- 一个 Agent 探索实现，一个分析测试缺口；
- 不同 Agent 分别验证前端、后端和安全风险；
- 对同一需求生成两个隔离方案，再进行对比；
- 独立仓库或互不重叠模块并行处理；
- 只读审查与实现同时进行，但审查者不修改文件。
不适合并行：
- 多个 Agent 同时修改同一文件；
- 共享未提交数据库迁移；
- 方案尚未确定就大规模实现；
- 每条路线都需要人频繁回答问题；
- 输出最终必须由一个人逐行合并。
并发上限不是 CPU 或套餐额度，而是合并、验证和判断能力。多开十个 Agent 并不等于产能提高十倍。
7 -> 代码审查要从风格转向不变量
AI 可以快速修正命名和格式，人的审查应更关注：
- 需求是否完整实现；
- 是否改变外部接口和错误语义；
- 身份、角色、租户和对象授权是否一致；
- 金额、时间、幂等和并发是否正确；
- 数据迁移是否可回滚；
- 测试是否能在错误实现上失败；
- 日志是否泄露隐私或凭据；
- 依赖和配置是否扩大供应链风险；
- 失败路径是否被处理；
- 是否存在无关重构。
审查 AI 代码不能只问“这段代码看起来合理吗”，而要问“什么输入能让它违反业务不变量”。
8 -> 测试也可能是 Agent 共同犯错
Agent 同时写实现和测试时，可能让二者共享错误理解。常见情况包括：
- 测试只断言函数被调用，没有断言业务结果；
- Mock 掩盖真实集成问题；
- 将错误行为写进快照；
- 只覆盖新代码的顺利路径；
- 为通过测试删除必要校验；
- 修改测试预期来适应回归。
应要求测试能够解释自己要保护的不变量，并加入独立来源：历史事故、产品验收、接口契约、人工编写的 Break Test 或另一个只读审查者。
9 -> 案例：一次跨模块权限修复
问题是普通成员能够通过详情接口读取其他团队对象，而列表接口已经正确过滤。
可靠流程不是直接在控制器增加一个条件，而是：
这个过程看似比“一行修复”更慢，却避免局部补丁留下同根问题。
10 -> 团队应该衡量什么
- 从 Issue 到首个可审查 PR 的时间；
- Agent PR 首次通过 CI 的比例；
- 人工要求重大重写的比例；
- 合并后回滚和线上缺陷率；
- 每个任务的人工介入次数；
- 代码审查发现的高价值问题数量；
- 因环境问题失败的时间；
- 生成代码中最终被保留的比例；
- 技术债务、测试和文档任务完成量；
- 开发者是否能承担过去不熟悉但可验证的工作。
不要只统计生成代码行数。代码是未来维护成本，更多不一定更好。
11 -> 常见误区
让 Agent 自由修改整个仓库
缺少范围会产生无关变化和审查困难。
用最快完成衡量最好模型
速度必须与通过率、返工、安全和成本一起看。
跳过计划直接实现
复杂任务越早写代码，方向错误的返工越贵。
因为测试通过就取消人工审查
测试只覆盖被表达的条件，高风险业务仍需要判断。
把领域知识交给模型代替
Agent 可以探索陌生代码，但业务不变量和真实部署事实仍需要专家提供。
12 -> 团队落地清单
- Issue 包含可观察验收与不变量；
- Agent 开始前执行只读探索；
- 非简单任务先确认计划；
- 并行任务使用隔离工作区；
- 不允许自动读取或提交真实凭据；
- 修改保持小步、范围明确；
- 测试能够在错误实现上失败；
- 用户可见行为经过真实环境验证；
- 高风险变更有独立只读审查；
- 交付包含完整相关 diff 和验证结果；
- 范围外用户修改不会被覆盖；
- 合并和部署始终由有权的人决定；
- 线上结果反馈回评测与规则体系。
13 -> 结语
AI 编程不会让工程能力失去价值，而是把工程能力推向更高层。开发者需要更清楚地表达目标、更快地识别错误假设、更系统地设计验证，并能够监督多个执行分支。
当仓库、测试和规则准备充分时，Coding Agent 可以承担过去因为时间不足而长期搁置的迁移、测试、文档和工具建设；当这些基础缺失时，它也会更快地产生难以维护的变化。决定结果的仍然是工程系统，而不是单次演示。
感谢各位大佬支持！！！
互三啦！！！
