AI 编程提示词太长怎么压缩:上下文瘦身和实用模板

AI 编程提示词太长怎么压缩的实用指南:从任务目标、背景资料、约束条件、文件范围、日志输出和项目规则文件入手,把长提示词改成更短、更稳、更容易执行的任务卡。

AI 编程用久了,很多人会把提示词越写越长。

一开始只是说“帮我修这个 bug”,后来变成几百字背景、十几条规则、完整报错日志、项目目录说明、历史决策、个人偏好、测试要求和一堆“顺便”。看起来更完整,实际经常更难用:模型抓不住重点,工具读太多文件,token 消耗变高,任务也更容易跑偏。

提示词压缩不是把话说得越短越好,而是把低密度内容删掉,让 AI 更快看到任务边界、输入材料、约束和验收标准。

这篇给一套 AI 编程提示词压缩方法,适合 Codex、Claude Code、Cursor、Gemini CLI、Aider 这类 coding agent。

先给结论:长提示词压成任务卡

大多数 AI 编程提示词可以压成 6 行:

1
2
3
4
5
6
目标:修复登录态刷新失败。
范围:优先查看 src/auth/session.ts 和 tests/auth/session.test.ts。
限制:第一轮只分析,不修改文件;不要扫描整个仓库。
约束:不要改公开 API;不要删除文件。
验证:给出最小测试命令。
输出:列出 3 个最可能原因和下一步方案。

这比一大段自然语言更稳,因为模型能直接识别:

  • 要做什么;
  • 看哪里;
  • 不做什么;
  • 怎么验证;
  • 交付什么。

压缩提示词的目标不是“少写”,而是“少让模型猜”。

长提示词为什么会变差

长提示词并不一定更可靠。常见问题有 5 个。

1. 目标被背景淹没

你写了很多项目历史、个人判断和之前踩坑,模型可能开始总结背景,而不是解决当前任务。

2. 约束互相冲突

例如你同时写:

  • 尽量最小改动;
  • 顺便重构;
  • 补全测试;
  • 不要大改;
  • 可以调整架构;
  • 先快速修。

这些要求互相拉扯,模型很难判断优先级。

3. 文件范围过宽

提示词里出现“整个项目”“全部检查”“完整优化”“所有相关文件”,Agent 就可能读很多无关文件。

4. 日志和代码粘贴太多

完整测试日志、完整文件、完整 diff 都塞进提示词,真正有用的信息反而被埋住。

5. 临时需求混进长期规则

把一次性任务写进 CLAUDE.mdAGENTS.md 或长期 Memory,会让后续所有任务都带着旧上下文。

如果你遇到的是 Claude Code token 消耗突然变高,站内这篇更偏排查:/2026/07/08/claude-code-token-usage-spike-troubleshooting-faq/。本文重点是提示词本身怎么压缩。

第一步:先判断长在哪里

压缩前,先把提示词拆成几类:

内容类型 是否必须 压缩方式
当前目标 必须 保留一句明确动词
文件范围 必须 写具体路径或目录
约束条件 必须 保留会影响操作的约束
验收标准 必须 写测试命令或可检查结果
历史背景 看情况 只保留和当前任务有关的结论
完整日志 通常不必 只贴关键错误段
完整代码 通常不必 给路径,让 Agent 自己读
个人偏好 看情况 长期偏好放规则文件,不重复贴
情绪描述 不必 删除
“顺便”任务 不建议 拆成下一轮任务

一个简单判断标准:这句话会不会改变 Agent 的下一步操作?

如果不会,就删掉或移到参考资料里。

第二步:把自然语言压成字段

很多长提示词的问题,是用聊天口吻写需求:

1
我最近在改登录模块,之前这里有个 bug,用户反馈刷新页面以后经常退出登录。我怀疑是 session 过期时间处理有问题,也可能是 cookie 没有正确更新。你帮我看看这个问题,最好不要影响其他登录逻辑,也不要大改架构,如果可以的话顺便补一下测试,看看是不是还有别的地方也有类似问题。

压缩后:

1
2
3
4
5
目标:排查刷新页面后登录态丢失。
范围:src/auth/session.ts、src/auth/cookie.ts、tests/auth/session.test.ts。
限制:不要改认证架构;第一轮只分析,不修改。
验证:列出最小复现步骤和应补测试。
输出:按可能性排序列 3 个原因。

压缩后信息没有少,执行性更强。

AI 编程提示词最好像工单,不像散文。

第三步:只保留会影响决策的背景

背景不是不能写,而是要写成结论。

低密度背景:

1
这个项目之前做过一次登录改造,当时为了兼容老用户,我们加了一个兼容层。后来产品又要求移动端和网页端保持一致,所以这里历史上比较复杂。我记得之前还有一次 cookie 设置的问题,但不确定是不是同一个原因。

压缩后:

1
2
3
4
背景结论:
- 登录模块有旧兼容层,不要删除。
- Web 和移动端共用 session 逻辑。
- 曾出现 cookie 写入问题,优先检查 cookie 更新路径。

把“故事”压成“事实和风险”。

模型不需要知道你怎么想起来的,它需要知道哪些事实会影响代码修改。

第四步:把“不要做”写清楚

长提示词里经常有很多委婉提醒,比如:

1
这个地方比较敏感,最好别动太多,我担心会影响其他功能,如果不必要的话不要改太大。

压缩后:

1
2
3
4
5
禁止:
- 不改 public API。
- 不改数据库 schema。
- 不删除旧兼容逻辑。
- 不做无关重构。

负向约束要具体。不要只说“谨慎一点”,要说“不要改什么”。

尤其是 AI 编程里,删除、移动、重构都要明确限制。防误删可以参考:/2026/07/10/ai-coding-avoid-accidental-file-deletion/。

第五步:把“顺便”拆掉

长提示词最容易失控的词是“顺便”:

1
2
3
4
顺便优化一下结构。
顺便补一下测试。
顺便看有没有其他问题。
顺便整理一下文档。

这些需求会让任务边界扩大。

更好的做法是拆成阶段:

1
2
3
4
阶段 1:只定位 bug 原因,不修改。
阶段 2:只修复最小代码路径。
阶段 3:补最小相关测试。
阶段 4:单独评估是否需要重构。

如果你确实需要长任务,先让 Agent 写阶段计划,再逐步执行。长任务中断恢复可以看:/2026/07/10/ai-agent-long-task-resume-guide/。

第六步:不要把完整文件粘进提示词

在 coding agent 里,文件通常可以由工具读取。你不需要把完整代码贴进提示词。

低效写法:

1
2
3
4
5
6
下面是 session.ts 的完整代码:
...
下面是 cookie.ts 的完整代码:
...
下面是测试文件:
...

更好的写法:

1
2
3
4
5
6
请读取这些文件:
- src/auth/session.ts
- src/auth/cookie.ts
- tests/auth/session.test.ts

第一轮只总结相关逻辑,不要修改。

这样做有两个好处:

  • 提示词更短;
  • Agent 可以按需读取,不必一次性吞完整上下文。

如果文件很大,可以进一步限制:

1
只关注 session refresh、cookie update 和 logout 分支。

第七步:日志只贴关键段

测试日志和构建日志特别容易把提示词撑爆。

不要贴完整日志。先压成三段:

1
2
3
4
命令:pnpm test -- auth
失败用例:refresh session keeps user logged in
关键错误:Expected status 200, received 401
相关堆栈:tests/auth/session.test.ts:42

如果需要完整日志,放文件里:

1
2
完整日志在 .tmp/auth-test.log。
请先只读取最后 80 行。

这样比把几百行输出塞进聊天框更稳。

第八步:把长期规则移出提示词

如果你每次都重复写这些内容:

  • pnpm
  • 不要改 migrations;
  • 改 API 要跑测试;
  • 不要删除文件;
  • 输出中文总结;
  • 先看 src/lib 里有没有现成 helper;

说明它们应该进入项目规则文件,而不是每次复制。

可以放到:

  • AGENTS.md
  • CLAUDE.md
  • .cursor/rules/
  • 项目内 docs/ai-workflow.md
  • Codex Skill;
  • Claude Code subagent 说明;

提示词里只引用:

1
2
请先遵守项目 AGENTS.md。
本轮任务额外限制:不要修改 src/db/migrations。

代码库记忆工具和规则文件怎么选,可以看:/2026/07/10/ai-agent-codebase-memory-tools-comparison/。

第九步:压缩 CLAUDE.md / AGENTS.md

很多人的提示词不长,但规则文件很长。每次 Agent 启动都带着几千行规则,也会拖慢上下文。

规则文件压缩原则:

保留

  • 构建命令;
  • 测试命令;
  • 禁止修改的路径;
  • 代码风格硬约束;
  • 安全边界;
  • 提交和验证要求;
  • 项目特有坑点。

删除

  • 过期历史;
  • 重复表达;
  • 情绪化提醒;
  • 长篇架构背景;
  • 已经在 README 里的通用介绍;
  • 一次性任务记录;
  • “尽量”“最好”“注意一下”这类模糊话。

改写

原文:

1
这个项目是一个比较复杂的前端项目,之前有很多人参与维护,所以风格有点不统一。大家在开发的时候要注意尽量复用已有组件,不要随便新建组件,否则后面维护起来会很麻烦。

压缩:

1
2
- 新增 UI 前先搜索 `src/components`,优先复用现有组件。
- 不要为单次页面改动新建通用组件。

如果你想用工具自动压缩长期上下文,可以参考 caveman 的思路:/2026/07/03/caveman-agent-output-compression-guide/。但关键安全规则压缩后一定要人工复读。

第十步:把提示词压成三种模板

日常 AI 编程不需要每次重新组织语言。准备三种模板就够。

1. 排查模板

1
2
3
4
5
6
目标:
范围:
现象:
关键错误:
限制:第一轮只分析,不修改文件。
输出:最可能的 3 个原因 + 最小验证步骤。

示例:

1
2
3
4
5
6
目标:排查登录态刷新失败。
范围:src/auth/session.ts、tests/auth/session.test.ts。
现象:刷新页面后用户变成未登录。
关键错误:session test 期望 200,实际 401。
限制:第一轮只分析,不修改文件。
输出:最可能的 3 个原因 + 最小验证步骤。

2. 修改模板

1
2
3
4
5
6
目标:
允许修改:
禁止修改:
实现要求:
验证命令:
输出:改动文件 + 验证结果 + 风险。

示例:

1
2
3
4
5
6
目标:修复 session refresh 后 cookie 未更新。
允许修改:src/auth/session.ts、tests/auth/session.test.ts。
禁止修改:数据库 schema、公开 API、登录 UI。
实现要求:最小改动,保留旧兼容逻辑。
验证命令:pnpm test -- auth.
输出:改动文件 + 验证结果 + 风险。

3. 审查模板

1
2
3
4
目标:只读审查当前 diff。
重点:
限制:不要修改文件。
输出:按严重程度列问题;没有问题就明确说未发现高风险问题。

示例:

1
2
3
4
目标:只读审查当前 diff。
重点:bug、回归风险、权限边界、测试缺口、无关重构。
限制:不要修改文件。
输出:按严重程度列问题;没有问题就明确说未发现高风险问题。

如果你同时使用 Cursor、Codex、Claude Code,可以把这些模板分配给不同工具:Cursor 负责定位,Claude Code 负责实现,Codex 负责审查。三工具分工可以看:/2026/07/10/cursor-codex-claude-code-workflow-division/。

压缩前后对比

原提示词

1
我现在登录这里有个问题,用户刷新页面之后经常会掉登录态。这个项目之前登录逻辑改过几次,有一些兼容旧 token 的逻辑,cookie 这里也比较绕。你帮我完整看一下相关代码,看看是不是 session 过期时间或者 cookie 写入的问题。最好不要影响其他功能,也不要大改架构。如果可以的话顺便补一下测试,看看其他地方有没有类似问题。输出的时候详细解释一下原因。

压缩后

1
2
3
4
5
6
目标:排查刷新页面后登录态丢失。
范围:src/auth/session.ts、src/auth/cookie.ts、tests/auth/session.test.ts。
背景:有旧 token 兼容逻辑,不要删除。
限制:第一轮只分析,不修改;不要扫描整个仓库。
验证:给出最小复现和测试建议。
输出:按可能性列 3 个原因。

更短,也更清楚。

什么内容不能压太狠

提示词压缩也有边界。下面这些内容不要为了省字数删掉:

  • 安全边界;
  • 权限限制;
  • 数据库迁移要求;
  • 生产环境风险;
  • 不可删除文件;
  • 用户明确验收标准;
  • 法务、合规、隐私相关条件;
  • 代码、命令、路径、错误字符串。

尤其是路径和命令,宁可完整写,不要压成模糊描述。

错误写法:

1
跑相关测试。

更好:

1
运行 `pnpm test -- auth`。

省 token 不能牺牲可执行性。

团队版压缩规则

团队可以把下面这段放进 AGENTS.mdCLAUDE.md

1
2
3
4
5
6
7
8
9
## Prompt Discipline

- Treat each task as a small work order.
- Prefer fields: goal, scope, limits, validation, output.
- Do not scan the whole repository unless explicitly requested.
- Ask before reading large logs or unrelated directories.
- Keep command output summarized; save full logs to files.
- Do not mix new feature work, refactor, docs, and cleanup in one task.
- Preserve exact paths, commands, error messages, and safety rules.

这类规则能让团队里的 AI 任务更像工单,而不是每次靠个人发挥。

一张压缩清单

每次提示词太长,就按这张清单删:

问题 处理
目标超过一句 改成“动词 + 对象”
背景超过 5 行 压成 3 条事实
文件范围不明确 写具体路径
出现多个“顺便” 拆成后续任务
约束很多 分成“必须/禁止/可选”
粘贴完整日志 只留命令、失败用例、关键错误
粘贴完整代码 给路径,让 Agent 读取
重复长期规则 移到 AGENTS.md / CLAUDE.md
输出要求很长 写成列表格式
不确定要不要改 第一轮只分析,不修改

总结

AI 编程提示词太长,通常不是因为你太认真,而是因为目标、背景、约束、日志、代码和长期规则混在了一起。

最稳的压缩方式,是把提示词改成任务卡:目标一句话,范围写路径,限制写清楚,验证给命令,输出定格式。背景只保留会影响决策的事实;日志只贴关键段;长期规则移到项目文件;“顺便”拆成下一轮。

提示词变短以后,Agent 不一定更“聪明”,但会更少猜、更少读错文件、更少浪费上下文。对日常 AI 编程来说,这比一大段看起来完整的说明更可靠。

记录并分享
使用 Hugo 构建
主题 StackJimmy 设计