文章目录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 - 案例一次跨模块权限修复问题是普通成员能够通过详情接口读取其他团队对象而列表接口已经正确过滤。可靠流程不是直接在控制器增加一个条件而是只读追踪列表与详情的数据路径找到授权应归属的共享边界建立失败测试其他团队 ID 必须被拒绝建立正向测试所有者、同团队成员和合法管理员仍可访问检查缓存、批量接口和导出是否共享漏洞实施最小修复运行模块和完整测试在隔离环境验证真实请求由独立审查者检查租户边界记录同类调用点和后续治理。这个过程看似比“一行修复”更慢却避免局部补丁留下同根问题。10 - 团队应该衡量什么从 Issue 到首个可审查 PR 的时间Agent PR 首次通过 CI 的比例人工要求重大重写的比例合并后回滚和线上缺陷率每个任务的人工介入次数代码审查发现的高价值问题数量因环境问题失败的时间生成代码中最终被保留的比例技术债务、测试和文档任务完成量开发者是否能承担过去不熟悉但可验证的工作。不要只统计生成代码行数。代码是未来维护成本更多不一定更好。11 - 常见误区让 Agent 自由修改整个仓库缺少范围会产生无关变化和审查困难。用最快完成衡量最好模型速度必须与通过率、返工、安全和成本一起看。跳过计划直接实现复杂任务越早写代码方向错误的返工越贵。因为测试通过就取消人工审查测试只覆盖被表达的条件高风险业务仍需要判断。把领域知识交给模型代替Agent 可以探索陌生代码但业务不变量和真实部署事实仍需要专家提供。12 - 团队落地清单Issue 包含可观察验收与不变量Agent 开始前执行只读探索非简单任务先确认计划并行任务使用隔离工作区不允许自动读取或提交真实凭据修改保持小步、范围明确测试能够在错误实现上失败用户可见行为经过真实环境验证高风险变更有独立只读审查交付包含完整相关 diff 和验证结果范围外用户修改不会被覆盖合并和部署始终由有权的人决定线上结果反馈回评测与规则体系。13 - 结语AI 编程不会让工程能力失去价值而是把工程能力推向更高层。开发者需要更清楚地表达目标、更快地识别错误假设、更系统地设计验证并能够监督多个执行分支。当仓库、测试和规则准备充分时Coding Agent 可以承担过去因为时间不足而长期搁置的迁移、测试、文档和工具建设当这些基础缺失时它也会更快地产生难以维护的变化。决定结果的仍然是工程系统而不是单次演示。感谢各位大佬支持互三啦