怎么给 AI 派任务？把提示词写成一份可验收的任务单

01｜先写“结果”，不要只写“动作”#

一个模糊任务通常只包含动作：

帮我优化登录功能。

AI 不知道你说的“优化”究竟是速度更快、界面更好，还是修复登录失效。它只能自行猜测。

把它改成结果导向的描述：

修复用户登录后偶尔跳回登录页的问题。修复后，正常登录、刷新页面和 Token 续期都应保持登录状态，现有登录流程不能被破坏。

两者的区别是：前者只告诉 AI “开始干活”，后者告诉 AI “终点在哪里”。

写目标时，尽量回答三个问题：

1. 现在有什么问题？
2. 最终希望看到什么结果？
3. 哪些现有能力不能被破坏？

02｜补充必要背景，但不要把提示词写成小说#

背景是为了减少 AI 猜测，不是为了展示你知道多少信息。

可以写：

• 当前使用的技术栈或工具
• 相关目录、文件、页面或模块
• 已经尝试过什么
• 已知报错或异常现象
• 必须沿用的方案和不能更改的部分

例如：

1
当前项目使用 Next.js 15、TypeScript 和 PostgreSQL。
2
登录逻辑位于 src/auth，相关测试位于 tests/auth。
3
问题只在刷新页面后偶发出现，首次登录正常。
4
必须保持现有公开 API 兼容。

不需要重复写十遍“请认真”“必须仔细”“一定不要出错”。这些话缺少判断标准，对执行帮助很小。

03｜用“成功标准”告诉 AI 什么叫完成#

成功标准是整份提示词最重要的部分。

如果没有成功标准，AI 很容易出现两种情况：

• 做了一点就宣布完成；
• 不知道何时结束，于是不断检查和继续优化。

成功标准应该尽量客观、可检查。例如：

1
任务完成必须同时满足：
2
1. 能稳定复现并解释问题根因；
3
2. 修复后，登录、刷新和 Token 续期流程均正常；
4
3. 增加覆盖本次问题的自动化测试；
5
4. 所有认证相关测试通过；
6
5. 不改变现有公开 API。

少写“效果更好”“代码更优雅”这类主观要求，多写“哪个测试通过”“哪个页面正常”“哪个指标达到多少”。

一个很好用的判断方法是：

如果最后无法根据这一条明确判断“通过”或“不通过”，它就还不够具体。

04｜划清权限边界：哪些能直接做，哪些必须问#

AI Agent 不只是聊天机器人。它可能拥有文件、终端、浏览器、数据库甚至部署权限。因此，提示词里最好明确审批边界。

可以把操作分成两组。

1
你可以直接：
2
- 阅读和搜索项目文件；
3
- 检查日志与配置；
4
- 修改本次任务范围内的代码；
5
- 运行本地测试和静态检查；
6
- 创建用于验证问题的临时文件。

1
遇到以下情况必须暂停并询问我：
2
- 删除或覆盖重要文件；
3
- 修改数据库结构或真实数据；
4
- 安装新的生产依赖；
5
- 部署到服务器或操作生产环境；
6
- 产生费用或调用付费资源；
7
- 修改任务范围外的模块；
8
- 存在多个会明显影响架构的技术方案。

05｜要求“实际验证”，不要接受口头完成#

AI 很容易根据代码推断“应该可以”，但“看起来正确”和“实际运行通过”不是一回事。

所以任务里要直接写出验证要求：

1
完成后必须：
2
1. 运行相关测试或检查命令；
3
2. 报告实际结果，而不是只说“应该可用”；
4
3. 列出修改过的文件；
5
4. 说明每一项成功标准对应的验证证据；
6
5. 无法验证的内容必须明确标记为“未验证”。

如果是不同类型的任务，可以换成对应证据：

• 编程任务：测试结果、退出码、修改文件、关键日志
• UI 任务：真实渲染结果、桌面端与移动端检查
• 数据任务：记录数、异常值、抽样核查、计算口径
• 调研任务：一手来源、发布日期、不同来源交叉核对
• 文案任务：字数、结构、目标读者、事实引用检查

关键原则只有一句：

让 AI 提供完成的证据，而不只是完成的声明。

06｜加入停止条件，防止无限发挥#

强自主 AI 常常会“顺便”优化更多内容。适当的停止条件可以避免任务不断扩大。

常用写法：

1
- 成功标准全部满足后立即停止；
2
- 不进行与目标无关的重构或额外优化；
3
- 同一个问题最多尝试 3 种方案；
4
- 达到重试上限后停止，报告失败原因、已尝试方法和下一步选项；
5
- 如果继续执行需要扩大任务范围，先询问我。

停止条件不是限制 AI 能力，而是让它把能力用在明确目标上。

07｜一份可以直接复制的通用模板#

下面这份模板适合编码、调研、写作、数据处理等大多数任务。把方括号里的内容替换掉即可。

1
## 目标
2
我要实现：[描述最终结果，而不是只写一个动作]
3

4
## 背景
5
当前情况：[技术栈、已有材料、相关文件、已知问题]
6
本次任务范围：[允许处理的模块、页面或内容]
7
不在范围内：[明确不希望动的内容]
8

9
## 成功标准
10
任务只有在以下条件全部满足时才算完成：
11
1. [可以客观检查的标准]
12
2. [测试、质量、性能或内容标准]
13
3. [必须保持兼容或不能破坏的内容]
14
4. [最终需要交付的文件或结果]
15

16
## 执行权限
17
你可以直接读取资料、搜索相关内容、修改任务范围内的文件，并运行本地验证。
18

19
遇到以下情况必须先询问我：
20
- 删除或覆盖重要文件；
21
- 安装新依赖；
22
- 修改数据库或真实数据；
23
- 部署、发布或操作生产环境；
24
- 产生费用；
25
- 修改任务范围外的内容；
26
- 存在会显著影响结果的重要歧义或技术选择。
27

28
## 验证要求
29
完成后必须实际验证，并提供：
30
1. 执行或修改清单；
31
2. 验证方法与实际结果；
32
3. 满足每项成功标准的证据；
33
4. 未验证内容、剩余问题和风险。
34

35
## 停止条件
36
成功标准全部满足后立即停止，不做无关重构或额外优化。
37
同类失败最多重试 3 次；仍未解决时停止，说明原因、证据和可选方案。
38

39
## 最终输出
40
1. 完成了什么
41
2. 修改或生成了什么
42
3. 如何验证、结果如何
43
4. 剩余问题或风险

08｜只想快速派任务：用这个极简版#

不是每个任务都需要完整模板。日常任务可以压缩成一段：

1
目标：[最终想获得的结果]。
2

3
完成标准：[满足哪些条件才算完成]。
4

5
请自主分析并选择合适的实现方式，不要做与目标无关的扩展。你可以读取资料、修改任务范围内的文件并运行本地验证；涉及删除文件、安装依赖、数据库、部署、费用、生产环境或扩大任务范围时，必须先询问我。
6

7
完成后请实际验证，并给出修改清单、验证方法和实际结果。没有验证的内容必须明确说明。满足完成标准后立即停止。

对于一分钟能讲清的小任务，这一版通常已经足够。

09｜完整示例：给编程 AI 派一个修复任务#

模糊版本：

修一下登录 Bug，顺便优化代码。

推荐版本：

1
## 目标
2
修复用户登录后偶尔跳回登录页的问题。
3

4
## 背景
5
项目使用 Next.js 15、TypeScript 和 PostgreSQL。
6
认证代码位于 src/auth，相关测试位于 tests/auth。
7
问题在刷新页面后偶发出现，首次登录正常。
8

9
## 成功标准
10
1. 找到并解释根因，而不是只增加重试；
11
2. 登录、刷新页面和 Token 续期均保持正常；
12
3. 增加能覆盖本次问题的自动化测试；
13
4. 所有认证相关测试通过；
14
5. 保持现有公开 API 兼容。
15

16
## 权限边界
17
你可以检查代码和日志、修改认证模块并运行本地测试。
18
涉及数据库结构、安装生产依赖、删除文件、修改其他模块或部署时，必须先询问我。
19
如果存在多个会影响架构的方案，请先说明利弊并让我选择。
20

21
## 验证与停止
22
完成后列出根因、修改文件、测试命令和实际结果。
23
未实际验证的内容必须明确标记。
24
成功标准全部满足后停止，不做无关重构。
25
同类失败最多尝试 3 次，仍未解决就报告阻塞原因和可选方案。

这个版本没有规定 AI 必须先打开哪个文件、再运行哪条命令。它保留了 AI 自主分析的空间，同时把结果、边界和验收方式写清楚了。

10｜常见错误：提示词不是越长越好#

结语｜把“聊天请求”升级成“任务契约”#

给 AI 派任务，不需要背诵复杂的提示词技巧，也不需要堆叠几十条规则。

真正有用的是把六件事讲清楚：

1. 目标：最后到底要得到什么；
2. 背景：AI 做判断需要知道什么；
3. 成功标准：什么状态才算完成；
4. 权限边界：哪些能直接做，哪些必须询问；
5. 验证要求：如何证明真的完成了；
6. 停止条件：什么时候应该停下来。

最值得记住的一句话是：

不要只告诉 AI“做什么”，还要告诉它“做到什么算完成、如何证明完成、哪些事不能擅自做，以及什么时候必须停下来”。

下一次给 AI 派任务时，先别急着写一大段流程。把目标和验收标准写清楚，再补上权限、验证和停止条件，通常就已经是一份很好的提示词了。