按阶段推进任务

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

教学服务收到空邮箱返回 500，用户要求改为参数错误，同时保留正常请求。输入 A 的 email 是空字符串，输入 B 为 a@example.test；项目约定 A 返回 400、B 返回 200。你要先确认问题，再修改并验证，而不是把几个动词排成未经检查的计划。

具体做法

把工作拆成有依赖的三个阶段：复现、修改、验证。复现阶段保存 A 的实际状态码与版本，确认对应问题；修改只针对已确认验证路径；验证重新检查 A 和 B，并读取真实输出。每阶段的结果为下一阶段输入，遇到无法复现或缺环境就报告状态，不跳写通过。

反例

修复上述空邮箱问题，顺便改进整个服务，稍后再测试。只要代码看起来合理，就报告任务完成。

改进写法

按三个阶段处理上述教学任务：1. 在当前版本用 A 复现 500，记录命令/请求与结果；无法复现先说明。2. 基于已确认路径修改空邮箱验证，保持本任务范围。3. 用 A 检查 400、用 B 检查 200，读取输出并报告对应版本。阶段未完成保留状态，不把编号计划当验证记录。

为什么这样改

先复现把修改连到真实触发路径，修改后同时检查异常和正常输入则能发现误伤。明确阶段退出条件，使“代码写了”和“行为已验证”不被混成完成。

如何验证

教学验收表包含 A：原 500、目标 400；B：目标 200，另附真实运行时才填写的结果与版本。只检查 A 而不检查 B、没有复现记录或检查后又改相关代码，不能直接沿用通过结论。

本篇给的是检查设计，未运行真实服务。

适用边界

小任务可以用简短阶段，不需要增加无关文档或重复审批。复现与测试必须在合适环境，数据和状态码采用项目契约；阶段划分不会自动赋予执行外部动作的权限。