把需求写成可执行任务
用目标、现状、约束和验收标准，把模糊需求变成 AI 可以持续推进的工程任务。
一份好的任务说明，应当让执行者知道要改变什么、去哪里寻找依据，以及如何判断已经完成。“优化搜索体验”表达了方向，但没有给出可执行的边界。补上具体用户场景，任务才会稳定下来。
先写用户能观察到的变化
从一个真实问题开始：用户输入关键词后，列表没有及时更新，必须重新打开页面。期望行为可以写成“提交关键词后展示匹配结果；清空关键词后恢复全部结果”。这样的描述可以直接转化为验收步骤，也能避免过早绑定某种实现。
把已知事实和推测分开。例如，“列表页会发出请求”是观察，“缓存导致结果过期”只是待验证的解释。让 Agent 先检查调用链，再决定改动位置，通常比指定一个未经验证的修复更可靠。
给出够用的任务边界
| 要素 | 应该包含的信息 |
|---|---|
| 目标 | 一次明确的行为变化，以及受益的使用场景 |
| 入口 | 相关页面、接口、文件或复现步骤 |
| 约束 | 必须兼容的行为、不能改变的数据结构 |
| 验收 | 正常、边界和失败场景的预期结果 |
| 交付 | 需要提供的代码、预览和验证说明 |
入口不必一次找全。可以允许 Agent 继续检索，但要告诉它哪些是确定的信息，哪些需要在实施前确认。
可直接使用的模板
目标：为文章列表增加标题关键词筛选。
现状：列表能展示全部文章，但没有筛选入口。
入口：先查找文章列表页面及其数据来源。
约束：保留现有排序；不改变文章地址。
验收：
1. 关键词匹配时只展示符合条件的文章。
2. 无匹配时显示清晰的空状态。
3. 清空关键词后恢复全部文章及原有顺序。
交付：完成修改，验证以上场景，说明改动与剩余限制。让拆分服务于验证
当任务包含多个独立结果时，按可验收的行为拆分。例如先完成筛选，再加入高亮，再处理持久化。每一步都应当能够运行、检查和回退。若一个步骤结束后只能判断“代码写了一半”，拆分方式还可以调整。
执行中发现新约束，要同步更新任务说明，避免最终实现依赖过时假设。涉及多个页面或模块时，可结合上下文与项目规则保存决策；完成后再按交付流程检查实际行为。