Agent 开发中途增加需求，怎样记录范围变化

Agent 开发中途增加需求，先把新要求与已确认范围对照，再决定是修复缺陷、补充说明还是扩大交付。不要只在聊天里回复“这个也加上”。一条变更记录应让业务、开发和验收人员看到原来做什么、现在增加什么、哪些旧能力需要重新验证。本文提供工程记录方法，不判断合同效力。

先找到原来共同确认的基线

基线包括流程版本、允许输入、资料范围、用户角色、系统动作和验收样本。它可以来自需求文档、演示确认记录或已接受的接口契约。没有基线时，先整理双方能一致确认的当前状态，标明争议部分；不能由任一方回忆一句口头约定就认定全部范围。

例如原任务是客服查询保修期并生成回复草稿，新增要求是“顺便自动创建维修工单”。看似只加一个按钮，实际增加了写权限、必填字段、重复提交处理与人工确认。先写清新增业务结果，才能判断它是否影响现有身份体系、接口和验收标准。

下载范围变化记录表，三条合成记录分别演示新增写动作、增加文件类型和新增渠道。表中有基线、新要求、分类、影响范围、决策、验证项与负责人。它不是任何合同的固定附件格式，可以按项目管理方式调整。

缺陷修复是已约定行为没有做到，例如需求明确写缺少型号要追问，系统却直接生成工单。说明澄清是原描述存在歧义，需要明确但没有增加业务对象，例如“近期”到底以哪个日期计算。范围增加则引入新的角色、动作、资料类型或系统连接。这三类对工作和验收的影响不同，应把判定理由记录下来。

分类不确定时，用具体输入和期望输出讨论。若客户说“回答再智能一点”，追问是哪条问题、现有答案哪里不符合依据、期望改变什么。把质量问题与新业务规则分开，有助于避免开发方把所有反馈都算变更，也避免客户把全新流程都叫优化。

同一次变化可能同时包含不同类别。新增扫描件上传可能是范围增加，而原本支持的电子文档解析失败仍是缺陷。拆成两条记录后分别处理，不必为了形成一个统一标签而掩盖差异。记录中可以保留未决项，但需要明确谁负责补充证据。

从入口开始检查新增内容：是否新增个人信息，原权限是否足够，是否要走新的模型或解析服务，是否需要保存新的日志。接着检查业务动作：只读变写入是否需要确认，重试是否会重复产生记录，结果如何回传。最后看交付：文档、部署配置、培训和运维是否都要更新。

结构化接口的变化尤其容易被低估。JSON Schema 对象文档说明可以通过必填属性约束字段。把可选字段改为必填，即使字段名称不变，也可能使旧调用失败。因此变更记录应包含字段契约版本与旧调用兼容策略，不能只比较界面是否多了一列。

工作量估算在影响分析之后进行。让开发方列出分析、实施、资料处理、联调和回归的变化，并写前置条件。尚未取得接口资料的部分可以列为待评估，不必伪造精确数字。业务方再决定接受、延期、缩小或放弃，结论应指向具体范围版本。

合成变更“新增自动创建维修工单”先记录原版本只生成草稿。新版本要求客服确认后提交，展示设备编号、故障分类和联系方式。影响项包括工单写接口、客服角色、提交状态和错误记录。排除项明确为自动审批与配件采购，避免一个新动作继续扩散成整套售后系统。

验收至少增加正常提交、取消确认、超时后查询结果、重复点击和权限不足五类。原来的保修查询也要回归，因为新增身份或字段可能影响旧链路。关闭条件是新范围获确认、测试证据齐全、操作说明已更新，不能仅以代码合并或按钮出现为准。

失败分支同样需要记录。若写接口无法支持结果查询，超时后可能无法判断是否创建成功，此时应转人工核对并暂停自动重试。把这个限制反馈给业务方，由业务决定接受这种流程还是要求系统侧补充能力；不能让模型自行猜测结果。

变更表保留提出日期、决策人、当前状态和关联版本。讨论可以在会议或聊天中进行，但最终结论应回到同一条记录，避免不同团队拿着不同截图执行。被拒绝的要求也保留简短原因，后续再提出时就不必重新解释全部背景。

关于范围的技术边界，可看低代码能力边界；跨系统动作可看流程自动化专题。如果现有项目需求越加越多，可通过联系入口提供当前基线和变更样例，先梳理影响链，再讨论定制实现与分阶段交付。