起草局部代码修改与验证方案

这个场景能帮你做什么

小改动也可能漏掉调用方和边界条件。WorkBuddy 可以在明确范围内起草代码差异与验证方案，帮助开发者把需求、改动和测试对应起来。

开始前需要准备什么

提供代码副本或独立开发分支、明确需求、允许修改的文件、团队规则和已有测试。说明能否执行命令及可用测试环境，禁止连接生产数据或自动合并发布。

具体怎么做

第一步：确认修改点和依赖

先说明当前行为、目标行为、涉及模块与调用方。公共函数改变时检查所有已知引用，不只修改函数本身。

第二步：起草最小差异

只改需求必要内容，保留已有用户修改和兼容约束。新增依赖、数据格式或接口变动单列，不能为方便顺手重构无关区域。

第三步：设计验证并如实执行

将正常、边界、异常和回归样例对应到改动。得到执行授权且环境可用时运行合适检查，保留真实命令与结果；不能运行则明确未运行，不声称通过。

第四步：交付评审

输出改动说明、差异、验证结果与未解决问题。开发者审阅后再决定提交、合并和后续测试。

可以直接交给 WorkBuddy 的完整要求

在指定副本/分支按附件需求起草局部修改，先说明现状、目标、文件范围和受影响调用。
只做最小必要改动，保留已有修改；新增依赖、接口或数据变化单列待确认。
提出正常/异常/边界/回归验证。只在允许环境执行获授权命令，逐项报告实际结果，未跑不得写通过。
交付可审阅差异与限制，不提交合并、不部署、不改生产数据。

完成后会得到什么

一份可评审代码差异、对应测试与真实验证说明。环境未准备好时，交付可以是修改草稿加未运行清单。

结果应该怎么检查

开发者检查业务规则、调用方、异常处理及测试是否真正覆盖改变的行为。测试通过仍需理解改动，不能只看模型解释。

遇到这些情况怎么处理

测试失败先定位原因，不能删除断言以通过。现有修改冲突时停止覆盖并澄清。修改范围明显扩大时重新评估，不沿原“小改”授权无限推进。

哪些必须人工决定

开发者对代码与验证负责，授权人员决定合并和发布。AI 可起草与执行明确检查，不自行取得生产权限。