核对代码变更与开发文档的一致性

这个场景能帮你做什么

接口、配置和口头需求改了，文档没跟上，会让后续开发继续用旧信息。WorkBuddy 可以对照最终差异和工程文档，定位需要增量更新的内容。

开始前需要准备什么

提供代码基准与目标版本、变更说明、已确认口头修改记录、架构/接口/配置/操作文档。说明哪些文档是设计目标，哪些记录实际实现，不能一概以代码覆盖意图。

具体怎么做

第一步：提取行为变化

整理接口、字段、配置、模块职责和错误处理的实际增删改，保留代码位置与版本。无关格式改动不扩散成文档重写。

第二步：寻找对应说明

将行为变化映射到具体章节，检查外层响应、默认值、权限和异常是否仍相符。没有文档对应的列缺项。

第三步：区分错误实现与旧文档

文档和代码冲突时对照已确认需求。不能自动把文档改成代码现状以掩盖实现偏差，也不能擅自改代码。

第四步：起草增量更新

仅对确认需要变化的段落给新旧对照、依据和适用版本，附联调或测试需要确认的事项。

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

对照附件代码变更、确认记录和开发文档，提取实际行为变化并定位受影响章节。
逐项列代码现状、文档描述、需求依据和冲突。无法判断哪方应改则留问题，不以一致性为由掩盖实现错误。
只给必要增量修订及版本说明，不重写无关内容、不修改代码或发布文档。

完成后会得到什么

一份代码—需求—文档差异表和局部修订草稿，能够解释每一处更新理由。

结果应该怎么检查

开发者检查关键接口、包装、默认值和异常，确认文字与目标行为一致。口头修改需要有效确认，不能用聊天猜测补齐。

遇到这些情况怎么处理

确认记录缺失先澄清。代码未合并时标候选版本。设计意图仍正确但实现偏差时创建研发问题，不直接改文档迁就。

哪些必须人工决定

产品和技术负责人确认目标，开发与作者确认修订。AI 找冲突与拟改，不决定需求是否改变。