Prompt 优化不是写得更长，而是把上下文分层给 AI

很多人用 AI 编程一段时间后，会进入一个误区。

Prompt 越写越长，背景越贴越多，要求越列越细，结果 AI 反而更容易抓不住重点。

不是信息越多越好。

先说结论：Prompt 优化的关键，不是写得更长，而是把上下文分层给 AI。

你要让它知道哪些是背景，哪些是当前问题，哪些是限制，哪些是期望输出。

否则一大段文字丢过去，它只能自己猜重点。

在此之前，我把配置教程，常见字段，排查顺序和首次测试模板整理成了一个持续更新的资料页，可以点击这里快速开始

https://gitcode.com/u011635002/little_ai/blob/main/docs/安装基础教程/02-OpenAI Codex CLI 配置教程.md

长 Prompt 为什么会失控

长 Prompt 最大的问题，不是长本身。

问题是没有层次。

比如你这样写：

这个项目之前是别人写的，我现在想改一下列表页，搜索好像有点问题，之前接口也改过，分页也有问题，样式也不太统一，你帮我看看怎么优化一下，最好顺便把代码整理一下。

这段话里混了很多东西：

• 老项目背景
• 列表页问题
• 搜索问题
• 接口变化
• 分页问题
• 样式问题
• 代码整理

AI 可能每一项都回应一点，但没有一项真正收住。

熟练者要做的，不是继续补更多解释，而是先分层。

最实用的 5 层上下文

我建议把 AI 编程 Prompt 分成 5 层：

1. 背景
2. 当前问题
3. 已确认事实
4. 限制条件
5. 期望输出

这 5 层足够覆盖大部分日常任务。

背景告诉 AI 项目大概是什么。

当前问题告诉它这次要解决什么。

已确认事实告诉它哪些东西不要重复猜。

限制条件告诉它哪些事不能做。

期望输出告诉它你要计划、代码、解释，还是验收清单。

这比写一大段自然语言稳很多。

第一层：背景，只给必要信息

背景不是项目介绍大会。

你不需要把所有历史都讲一遍。

背景只要回答一个问题：AI 需要知道什么，才能理解当前任务？

比如：

背景：
这是一个 React 管理后台项目。
当前任务只涉及用户列表页。
项目里已经有统一请求封装，不希望本次修改请求库。

这就够了。

不要把所有业务故事都放进背景里。

背景越长，当前问题越容易被淹没。

第二层：当前问题，要具体到现象

"帮我优化一下"不是一个好问题。

"搜索不生效"也还不够。

更好的写法是：

当前问题：
用户列表页输入关键词后点击搜索，页面会刷新 loading，
但列表数据没有按关键词变化。
清空关键词后，列表也没有恢复全部数据。

这比"搜索有问题"清楚很多。

它包含了操作、现象和异常点。

AI 才能沿着交互链路去查。

第三层：已确认事实，减少重复猜测

这是很多人会漏掉的一层。

你已经知道的事情，应该直接告诉 AI。

比如：

已确认事实：
1. 接口本身可以按 keyword 返回正确结果
2. 浏览器 Network 里能看到请求发出
3. 当前页面使用的是 UserList.tsx
4. 最近只改过搜索区域组件

这层信息能明显减少 AI 的无效探索。

否则它可能从接口是否存在、项目怎么启动、页面在哪重新查一遍。

熟练者用 AI，要学会把自己已经确认过的事实交给它。

这不是啰嗦，是减少浪费。

第四层：限制条件，决定边界

限制条件是 Prompt 里非常关键的一层。

它告诉 AI 本次不要做什么。

比如：

限制条件：
1. 不重构列表组件
2. 不修改公共请求封装
3. 不引入新依赖
4. 不调整全局样式
5. 如果必须扩大范围，先说明原因

没有限制条件，AI 很容易按"工程上更完整"的方向做。

但你这次可能只想修一个小 bug。

不是完整方案不好，而是当前任务不需要。

第五层：期望输出，别让 AI 猜你要什么

你要计划，就说要计划。

你要代码，就说要代码。

你要排查顺序，就说排查顺序。

很多 Prompt 失败，是因为用户没有指定输出。

比如你说：

帮我看看这个问题。

AI 可能会解释原因，也可能会直接改代码，也可能会列很多可能性。

更稳的写法是：

期望输出：
请先不要修改代码。
请先输出：
1. 最可能的 3 个原因
2. 每个原因对应要查看的文件
3. 最小排查顺序
4. 确认后再修改

这样它就知道第一轮该交付什么。

分层 Prompt 模板

你可以直接复制这个模板：

请先不要修改代码。

背景：
【项目类型、当前模块、必要上下文】

当前问题：
【具体操作 + 实际现象 + 期望结果】

已确认事实：
1. 【已经确认的信息】
2. 【已经排除的问题】
3. 【最近改动】

限制条件：
1. 不要修改【文件或模块】
2. 不要做【重构或额外功能】
3. 不要引入新依赖
4. 如果必须扩大范围，请先说明原因

期望输出：
1. 请先判断可能原因
2. 请列出需要查看的文件
3. 请给出最小修改方案
4. 等我确认后再动手

这套模板不花哨，但很稳定。

它最大的价值是让 AI 不用猜重点。

什么时候需要继续分层

如果任务比较复杂，还可以继续加两层：

• 验收标准
• 风险提醒

比如：

验收标准：
1. 输入关键词后只显示匹配用户
2. 清空关键词后恢复全部用户
3. 分页仍然正常

风险提醒：
如果修改会影响分页、筛选或公共请求，请先停下来说明。

这两层适合功能修改、bug 修复和上线前检查。

它能把 AI 从"改完就算"拉到"可验收、可复核"。

不要把所有历史都塞进同一轮

如果对话已经很长，不要继续在原来的长上下文里追加。

可以先让 AI 帮你压缩：

请把当前对话压缩成 5 层上下文：
1. 背景
2. 当前问题
3. 已确认事实
4. 限制条件
5. 下一步期望输出

不要加入新推测。

然后用这份压缩结果开启下一轮任务。

这比不断补充"还有一个情况"更稳。

分层以后，还要控制每一层的长度

分层不是把每一层都写得很长。

如果背景写了 1000 字，当前问题只写一句话，AI 还是容易跑偏。

我更建议每一层先控制在很短的范围：

背景：3 到 5 句话
当前问题：操作 + 现象 + 期望结果
已确认事实：3 到 6 条
限制条件：3 到 6 条
期望输出：明确本轮要什么

如果信息真的很多，也不要全部塞进第一轮。

可以先让 AI 判断还需要哪些信息。

比如：

我先给你第一轮上下文。
如果信息不足，请只告诉我还缺什么，不要直接猜方案。

这句话能让对话更稳。

你不是一次性把所有材料扔过去，而是让 AI 按需索取。

不同任务可以换不同分层

不是所有任务都用同一套模板。

修 bug 时，最重要的是复现步骤和已确认事实。

加功能时，最重要的是目标、非目标和验收标准。

做代码 Review 时，最重要的是审查维度和风险优先级。

所以熟练者可以准备三套简化版本。

修 bug：

背景：
复现步骤：
实际结果：
期望结果：
已排除：
限制条件：
期望输出：

加功能：

背景：
目标：
非目标：
涉及页面或模块：
验收标准：
限制条件：
期望输出：

代码 Review：

变更背景：
本次 diff：
重点审查：
不需要关注：
输出格式：

这样比一套模板打天下更稳。

Prompt 优化到最后，不是模板越复杂，而是你知道当前任务最需要哪几层信息。

最常见的分层错误

第一，把限制条件写成建议。

比如"最好不要重构"，AI 可能会理解成可以重构。

更稳的写法是"本轮不要重构；如果必须重构，先停下来说明原因"。

第二，把期望输出写得太泛。

"帮我看看"不够。

你要写"请先列出 3 个可能原因，不要修改代码"。

第三，把已确认事实和猜测混在一起。

已确认事实应该是你已经验证过的内容。

如果只是怀疑，就写到"可能线索"里。

事实和猜测混在一起，AI 会把你的猜测当成前提。

这一点在排查 bug 时尤其危险。

一个最终版模板

请先不要修改代码。

背景：
【3 到 5 句话说明项目和模块】

当前问题：
【我做了什么操作，实际发生什么，期望发生什么】

已确认事实：
1. 【已经验证过的事实】
2. 【已经排除的问题】
3. 【最近相关改动】

可能线索：
1. 【只是怀疑，不要当成事实】

限制条件：
1. 本轮不要修改【范围】
2. 不要新增依赖
3. 不要重构
4. 如果必须扩大范围，先停下来说明原因

期望输出：
1. 先给可能原因
2. 再列需要查看的文件
3. 再给最小修改方案
4. 等我确认后再动手

这个版本比普通长 Prompt 稳定很多。

它把事实、猜测、限制和输出拆开了。

AI 不需要在一大段话里猜你的重点。

最后说句最实在的话。

Prompt 优化不是把话写得越来越长，而是让信息各归各位。背景归背景，问题归问题，事实归事实，限制归限制，输出归输出。AI 接到的上下文越清楚，代码协作就越不容易跑偏。