给编程助手一份能验收的需求说明

“帮我优化这个页面”既没有对象，也没有完成标准。以“提交失败时保留表单输入”为例，先说明目前怎样、期望怎样，再让助手查找相关代码。这样更容易控制改动范围和审查结果。

准备这些输入

• 当前行为：操作步骤、实际结果和必要截图或错误摘要。
• 期望行为：用户完成操作后应看到什么、数据应怎样保留。
• 改动范围：相关目录、允许修改的部分与已有约定。
• 验证方式：能说明问题已解决的正常和失败场景。

1. 用前后行为描述问题

先给出触发条件，再说明当前结果和期望结果。避免只提出某种实现方案，因为真正问题可能在更上游。对无法确定的原因明确写假设，让助手先阅读再判断。

2. 提供最小必要上下文

附上相关入口、数据结构和已有检查命令，不把整个仓库历史一次塞入请求。真实密钥、客户资料和无关配置不属于必要上下文。已有逻辑经过验证时，说明哪些行为必须保持。

3. 定义交付与停止条件

要求列出实际改动、原因和验证结果。涉及新依赖、数据迁移或外部服务时应先明确范围；没有足够环境验证的部分留为限制，不把编译通过当成所有场景通过。

可调整的操作模板

任务：[当前行为→期望行为]
触发步骤：[可重复步骤]
范围：[相关目录与不能改变的行为]
通过条件：[正常、失败、边界场景]
请先检查现有实现，再完成最小必要改动，并报告实际验证和未验证部分。

这段模板只用于组织你提供的材料。使用前确认资料可以交给所选工具，工具不支持附件时可以粘贴必要的脱敏文字。

交付物与人工检查

完成后保留：需求说明＋通过条件＋改动范围。交付前逐项确认：

• 期望行为是否能被实际操作验证。
• 输入中是否混入未确认的根因判断。
• 改动范围与已有约定是否清楚。
• 通过条件是否覆盖本次真正的问题。

遇到卡点怎么办

助手提出大规模重写时，回到触发场景核对必要性。先确认较小改动为何不足，再决定是否扩大范围。

继续从需求拆解专题查看本类任务，或在工具目录了解具体工具的用途与使用条件。