编码实验室：上下文选取、最小变更、测试与代码审查

参考：来源 F · 第 26、28 章进阶

学完你能做到

构建任务相关的仓库上下文包
把变更拆成可验证的小步
设计测试金字塔、审查门和安全交付

编码 Agent 的上限通常由上下文决定，不只由模型决定。给整个仓库会挤满噪声，只给一个文件又看不到调用方、类型、测试和约定。可靠做法是先建立仓库地图，再围绕任务逐层扩展上下文。

上下文选取漏斗：从仓库全局地图出发，只把与任务、依赖和验证直接相关的材料送入工作上下文。

上下文材料	为什么需要	何时不应加入
任务说明与验收标准	定义“完成”	永远需要
相关实现文件	理解当前行为和约定	仅凭文件名猜相关
调用链和类型	防止局部改动破坏上下游	与目标没有依赖关系
已有测试	理解隐含行为并提供回归	测试本身明显过期时需标注
外部文档/API Schema	校验集成契约	来源不明或版本不匹配
用户未提交改动	必须保护并区分来源	绝不能当成可随意覆盖的基线

最小变更为什么是一种推理策略

一次改十个文件会让错误归因困难。编码 Agent 应先写出最小可验证假设：如果原因是 X，只改 Y 应让测试 Z 通过。测试失败后先读取新证据，再决定扩大范围；不能用“大面积重写”掩盖没有理解根因。

测试金字塔与交付证据。底层便宜、快速、数量多；越靠上越接近真实用户，但更慢、更脆弱。

错误出现在哪	Agent 下一步应做什么	不应做什么
类型检查	定位第一个根因和受影响类型	批量加 any 或关闭规则
单元测试	比较预期、实际和最近改动	无解释地修改测试迎合实现
集成测试	检查环境、契约、迁移和副作用	反复重跑等待偶然通过
页面流程	检查网络、状态、交互和视觉	只截图首页宣布完成
生产监控	回滚、保存证据、复现并补回归	在线直接试探性修改

小步编码闭环

map = inspect_repository(task)
hypothesis = explain_current_failure(map, evidence)
change = propose_minimal_diff(hypothesis)
apply(change, preserving_user_work=True)
result = run_targeted_checks_then_broader_checks()
if result.failed: update_hypothesis(result.first_root_cause)
else: review_diff_security_performance_and_acceptance()

完整编码任务演练

30 分钟

为“给课程增加学习进度”建立仓库上下文包。
写出一个最小变更假设和三层测试计划。
模拟集成测试失败，写出 Agent 应如何更新假设、保护现有改动并交付当前状态。

综合演算：完成一次带脏工作区的安全修复

仓库已有用户未提交修改，测试又在另一个文件失败。Agent 必须区分原有变化与本次任务，避免覆盖用户工作，并提供可审查的修复证据。

本节追问：自治编码怎样在共享仓库中保持边界和可恢复性？ 先不要急着看结论。沿着下面四步，逐项区分输入、决策、证据和失败信号。

四步案例推演。手机上可左右滑动查看；每个箭头都代表一次需要证据支撑的状态转换。

阶段	本步要做的决定	什么算证据	最常见的失败
检查现场	读取状态与差异，识别用户已有修改	本次允许触碰的文件范围明确	直接还原所有未提交内容
建立基线	运行最小复现并记录当前失败	知道失败是否在修改前已存在	把历史失败误算为本次回归
局部实施	避开无关差异，用小补丁解决根因	差异仅包含任务相关修改	格式化全仓造成巨大噪声
交付证据	运行分层验证并说明未覆盖项	审查者能复现测试与理解风险	只说“应该可以了”

阅读方式：先遮住后两列自己回答，再用“证据”和“失败”两列检查理解。

常见误解

为得到干净状态执行破坏性重置

实际上

可观察症状：用户未提交工作被不可逆丢失。

更可靠的修复：保留并绕开现有变化；无法安全分离时停止并请求范围确认。

案例工作坊 · 建议真正动手完成

25 分钟

给一份模拟 git 状态标出用户修改与任务修改。
设计从单测到构建的分层验证顺序。
写一份包含范围、证据和剩余风险的交付说明。

查看参考答案

安全编码 Agent 把仓库视为共享现场：先观察、保留未知修改、建立基线，再做最小补丁并用可复现证据交付。

迁移检查：换一个场景还会不会

发现不相关的未提交文件时，正确默认动作是？