规范交付标准


提供验证要求

验收条件宜在任务开始时给出,使 Claude 在实现过程中就能对照检查。可根据成果类型,提供测试输入、预期输出、复现步骤、构建要求或页面截图。

例如,检查搜索功能时,可将操作与预期结果对应起来:

请按以下场景验证{笔记列表页}的搜索功能:

准备条件:
在测试数据中创建“工作”和“生活”两个分类。
“工作”分类包含“会议记录”和“项目计划”两篇笔记;“生活”分类包含另一篇“会议记录”。
当前选择“工作”分类。

检查场景:
1. 输入“  会议记录  ”:仅显示“工作”分类中的一篇“会议记录”。
2. 输入空字符串或连续空格:显示“工作”分类下的两篇笔记。
3. 输入不存在的标题:显示“暂未找到符合条件的笔记”。
4. 清除关键词:恢复“工作”分类下的两篇笔记,分类选择保持不变。

上述场景均不应显示“生活”分类中的笔记。

请优先使用项目现有的测试方式,必要时补充能覆盖此次行为变化的测试。
若检查发现失败,请查明原因并修复,然后重新执行相关检查。
如果无法运行,请说明缺少的环境或依赖,以及尚未验证的部分。

涉及界面的改动,可要求在指定窗口尺寸下检查页面并提供截图;涉及接口的改动,可核对状态码、响应内容和异常输入。验证范围应与改动相称,同时覆盖相关的回归风险。

明确交付内容

交付说明应使读者能够了解改了什么、检查了什么,以及还有哪些问题。仅有“已完成”或“测试通过”不足以判断结果,还应提供相应的执行记录和证据。

完成后,请按以下顺序交付:

1. 修改摘要:列出修改文件及各自用途。
2. 需求对应:说明各项要求的完成情况。
3. 验证记录:列出实际执行的命令或操作、检查范围及结果。
4. 未验证事项:说明未执行的检查及具体原因。
5. 使用方式:提供本地运行、查看页面或获取导出文件的方法。
6. 剩余问题:说明已知限制和需要我决定的事项;没有则注明。

请区分“实际通过的检查”“基于代码阅读的判断”和“建议后续执行的检查”。
需要我操作的步骤,请说明操作位置、输入内容和预期结果。

如果检查本身与需求不一致,应先说明冲突并确认合理的判断标准。不能通过删除有效检查、屏蔽错误或为个别示例写死结果来表示完成。

聚焦问题反馈

结果不符合预期时,可按照“当前现象—预期表现—保留内容—检查方式”组织反馈。明确问题位置和修改边界,有助于减少已经确认的部分被反复改动。

请修正{合并导出文件}中的标题层级问题。

当前现象:{每篇笔记的标题与正文中的一级标题处于同一层级}。
预期表现:{每篇笔记的标题使用一级标题;正文中原有的一至五级标题分别顺延一级,六级标题保留为六级}。
需要保留:{笔记顺序、正文内容、创建日期和现有文件命名规则}。
特殊情况:{代码块内以 # 开头的内容属于代码,不参与标题转换}。

请仅修改与标题转换有关的实现,并使用包含多级标题和代码块的笔记重新验证。
完成后展示一组修改前后的输出片段,说明实际检查结果。

如果连续修改仍未解决同一问题,应先整理复现条件、已尝试方法、实际结果和仍缺少的证据,再重新判断原因。必要时,将这些信息汇总后开启新会话,避免反复沿用未经证实的假设。

评论

登录后查看