好的提示词不是越长越好，而是让 AI 清楚知道：背景是什么、要改变什么、不能碰什么、怎样算完成。这一篇给出一套可以重复使用的任务模板。

六个部分

1. 背景

说明项目是什么、当前状况是什么。只提供完成任务需要的上下文，不要把整个聊天记录都粘进去。

2. 目标

用结果描述需求，例如“让移动端导航不遮挡正文标题”，不要只说“把页面改好看”。

3. 范围

说明允许查看和修改哪些文件。范围越清楚，越容易检查 diff。

4. 约束

说明不能做什么，例如不能更换依赖、不能修改数据库、不能删除现有内容、不能改变公开 API。

5. 验收

把结果写成可以人工检查的条件，例如“390px 宽度下按钮不被截断”“点击复制后显示已复制”。

6. 验证

指定要运行的命令和人工检查。没有测试命令时，也要说明手动检查什么。

例子一：修复样式

模糊说法：

帮我修一下首页移动端，很挤。

可执行说法：

背景：这是一个 Next.js 博客，首页有文章卡片。
目标：修复 390px 宽度下文章卡片标题被截断的问题。
范围：先检查首页卡片组件和相关样式，只修改必要文件。
约束：不要改变桌面端布局，不新增依赖，不修改文章数据。
验收：390px 下标题可以显示至少两行，日期和链接仍然可点击。
验证：说明修改原因，并运行项目已有的构建检查。
请先给出计划，暂时不要修改。

例子二：增加小功能

背景：文章页面已有目录组件，手机端目前看不到目录。
目标：在手机端正文前增加可滚动的文章目录。
范围：只检查文章页面、目录组件和文章样式。
约束：保留桌面端目录，不改变文章链接，不引入新 UI 库。
验收：375px 和 390px 下目录可展开、链接可点击、页面没有整体横向滚动。
验证：运行构建，并检查至少一篇长文章的锚点跳转。

例子三：解释错误

我在项目根目录运行 pnpm build，出现下面的错误：

<粘贴脱敏后的错误文本>

请先判断错误发生在哪个阶段，再列出最可能的三个原因。暂时不要安装依赖、删除文件或修改配置。

排错时先让 AI 分析，能避免它为了“让命令通过”而随意升级依赖或删除缓存。

什么时候拆成多个任务

当任务同时包含设计、数据、接口、页面和部署时，应该拆开。一个任务最好只有一个主要结果：

1. 先理解现状并给方案；
2. 再实现最小改动；
3. 再补测试或手动验收；
4. 最后才考虑部署或发布。

不要让 AI 在没有验收前同时修改十几个目录。任务越大，出错后越难知道是哪一步造成的。

完成检查

• 我写了背景和目标；
• 我限制了范围和禁止事项；
• 我写了可观察的验收条件；
• 我指定了验证命令或人工检查；
• 大任务已经拆成多个小任务。

下一步

继续阅读第九章：常见错误排查，把“报错后怎么办”也变成有顺序的流程。