很多团队把 Cursor 用不稳，不是因为提示词不够详细，而是因为根本没有“任务单”这一层。
如果输入只是一句“帮我把这个需求做掉”，你得到的往往不是交付结果，而是一份高风险草稿。
任务单的作用，就是把模糊需求压缩成可执行 Brief，让模型知道：
- 这次到底要做什么
- 哪些不能动
- 结果怎么验收
- 出问题后如何回退
建议结合阅读 Cursor 项目级提示词规范、Cursor 与文档协作工作流、代码质量门禁与 CI 集成 和 Cursor 提示词反例库。
先给结论：一个能执行的任务单，至少要有 5 个字段
| 字段 | 作用 | 缺失后会怎样 |
|---|---|---|
| 输入 | 告诉模型当前上下文 | 模型只能猜背景 |
| 输出 | 明确最终产物形式 | 结果无法对齐预期 |
| 验收 | 定义什么叫完成 | 任务无法收口 |
| 风险 | 提前暴露高风险点 | 结果越界或返工 |
| 回滚 | 明确失败后的恢复方式 | 出错后处理成本高 |
这五项不齐，任务单就很难支持多人协作和稳定复用。
一、为什么“把需求写详细一点”仍然不够
很多任务描述已经很长，但还是不好用。根因在于它们写的是“业务背景”，不是“执行协议”。
任务单和普通需求说明最大的差异是：
$$ 背景说明 \neq 可执行边界 $$
模型并不天然知道：哪些是背景信息，哪些是必须遵守的边界。所以你要把它们拆出来。
二、一个可直接复用的 Cursor Brief 模板
任务目标：
- 本次只完成什么问题
输入上下文：
- 当前文件 / 参考文件 / 依赖关系
输出要求：
- 需要产出什么（计划、代码、测试、文档）
验收标准：
- 功能通过标准
- 质量与性能底线
风险与限制：
- 哪些文件不能改
- 哪些依赖不能动
回滚方案：
- 失败后按什么粒度恢复
这个模板的重点不在“字多”，而在字段之间没有歧义。
三、任务单里的“输出要求”必须写到可检查
很多团队会写“帮我完成这个功能”，但不会写“完成后要交付什么”。
更稳的写法是具体到产物：
- 先输出改动计划
- 再输出涉及文件清单
- 再执行代码改动
- 最后给出验证结果
这样做的好处，是你能在执行前先审一次方案，而不是等代码已经生成了再发现方向错了。
四、验收写不好，任务单就没有收口能力
验收不能只写“功能正常”。至少要分三层：
- 功能是否完成
- 是否引入新错误
- 是否满足最小质量门槛
例如一个页面任务，验收可以写成：
- 移动端首屏不超过两屏
- 无新增 console error
- CTA 点击链路不变
比起“优化页面”，这种验收更适合真实交付。
五、风险字段的作用，是在执行前拦截高代价错误
任务单里的风险不是写给项目经理看的，而是写给执行阶段看的。
建议至少声明：
- 允许改动范围
- 禁止修改的文件或配置
- 可能影响的链路
- 若发现未知依赖时是否停止执行
这会显著减少“本来只是改 UI，最后动到路由和配置”的情况。
六、回滚字段不能省，因为 AI 任务本质上是高迭代动作
任务执行速度越快，回滚设计越重要。没有回滚字段，团队只能在出错后临时商量怎么处理。
建议至少写：
- 回滚粒度是函数、组件还是文件
- 是否保留旧版代码块以便比较
- 哪一步验证失败就停止继续扩散修改
一个失败案例：背景写了很多，执行还是跑偏
典型情况是：
- 任务单用了 300 字解释业务背景
- 但没写允许改哪些文件
- 也没写交付物是什么
- 结果 Cursor 给了“看起来很完整”的大改方案
问题不在于背景不重要，而在于背景没有被翻译成约束。
任务单检查清单
- 是否区分了背景、边界和交付物
- 是否写清了输入上下文和参考文件
- 输出要求是否能被 reviewer 逐项检查
- 验收是否包含功能、质量、风险三个层面
- 是否标注禁止改动项
- 是否提供最小回滚方案
