“只加一个字段，应该很快”需要结合使用方式判断。字段只是用于展示，和需要保存、查询、导出并同步到销售系统，涉及的工作不同。评估改动时，先把新的行为说明白，再安排时间。
例子：咨询表单增加“产品型号”
假设原表单只有姓名和联系方式，现在希望客户选择产品型号，并在后台按型号分配咨询。需要检查的不只是下拉框。
| 关联位置 | 要确认的问题 |
|---|---|
| 产品数据 | 型号来自固定列表还是后台维护？停用型号怎样处理？ |
| 提交接口 | 字段是否必填？旧请求缺少字段时怎样处理？ |
| 后台记录 | 历史咨询怎样显示？是否增加筛选、导出或分配规则？ |
| 交互与测试 | 错误提示是否明确？手机和键盘能否完成选择？ |
MDN 的表单验证说明可以帮助核对输入检查；W3C 初步可访问性检查则提供操作与阅读方面的检查入口。技术资料支持的是这些检查项，不能直接给出该项目的工时。
把“能操作”写成具体的验收记录
新增“产品型号”时，字段旁边有文字还不够。按 W3C 表单标签教程，字段名称应与控件建立关联，让辅助技术能够识别用途。开发方需要核查标签关联，负责人则可以在验收记录中要求：用户能看清字段名称，使用读屏时也能知道正在选择什么。
提交被拒绝后，应能找到哪一项需要改、为什么被拒绝以及如何纠正。W3C 用户通知教程建议错误列表对应到具体控件，并给出纠正提示；提交后将焦点移至首个错误字段也是可采用的处理方式。只显示“提交失败”，不足以说明新增字段的纠错流程已经完成。
以本例为验收练习：不选择必填型号提交，检查提示是否指出“产品型号”，能否定位到该字段；再仅用键盘完成选择和重新提交，核对后台收到的型号。记录使用的浏览器、辅助技术及实际结果，作为这次变更的验收附件。这是项目讨论示例，不是客户实测，也不是完整的可访问性认证。
这些标签、错误关联和回归检查都应纳入变更估算。若原范围已经明确包含对应行为，发现遗漏时先按原约定判断缺陷；不能仅因补做测试就自动列为新增收费项。
一份够用的变更记录
记录编号和提出日期，附原先确认的功能、这次希望改变的行为，以及相关页面或截图。开发侧补充受影响的模块、依赖、测试内容和估算前提；客户侧确认本期是否必须完成。
决定暂缓时，写清后续条件，例如等接口方提供测试环境后再排期。决定纳入时，同步更新范围与验收清单，避免设计稿、后台和测试仍使用不同版本的说明。
怎么区分缺陷和新增要求
原先约定“咨询按选择的产品分类”，实际却没有分类，应该先核对是否属于未完成项；原先只约定收集联系方式，后来新增自动分派规则，则需要单独评估。判断依据是此前确认的需求和行为，而不是双方对“简单”的理解。
描述不清时，先补一个输入与预期结果的例子。比如选择型号 A 后，应产生哪条记录、由谁看到、能否修改。例子明确后，才方便讨论实现和验收。
排期怎样更新才有用
列出新增工作是否影响正在开发的模块、是否需要等待外部资料，以及哪些已完成内容需要重新测试。把原时间与调整后的时间保留在记录里，并指定确认人。
发布后按变更清单逐项核验，不把“代码已写完”直接当成“用户已能使用”。如果出现内容版本不一致，再按发布链路排查确认实际上线结果。