AI 编程用久了,很多人会把提示词越写越长。
一开始只是说“帮我修这个 bug”,后来变成几百字背景、十几条规则、完整报错日志、项目目录说明、历史决策、个人偏好、测试要求和一堆“顺便”。看起来更完整,实际经常更难用:模型抓不住重点,工具读太多文件,token 消耗变高,任务也更容易跑偏。
提示词压缩不是把话说得越短越好,而是把低密度内容删掉,让 AI 更快看到任务边界、输入材料、约束和验收标准。
这篇给一套 AI 编程提示词压缩方法,适合 Codex、Claude Code、Cursor、Gemini CLI、Aider 这类 coding agent。
先给结论:长提示词压成任务卡
大多数 AI 编程提示词可以压成 6 行:
|
|
这比一大段自然语言更稳,因为模型能直接识别:
- 要做什么;
- 看哪里;
- 不做什么;
- 怎么验证;
- 交付什么。
压缩提示词的目标不是“少写”,而是“少让模型猜”。
长提示词为什么会变差
长提示词并不一定更可靠。常见问题有 5 个。
1. 目标被背景淹没
你写了很多项目历史、个人判断和之前踩坑,模型可能开始总结背景,而不是解决当前任务。
2. 约束互相冲突
例如你同时写:
- 尽量最小改动;
- 顺便重构;
- 补全测试;
- 不要大改;
- 可以调整架构;
- 先快速修。
这些要求互相拉扯,模型很难判断优先级。
3. 文件范围过宽
提示词里出现“整个项目”“全部检查”“完整优化”“所有相关文件”,Agent 就可能读很多无关文件。
4. 日志和代码粘贴太多
完整测试日志、完整文件、完整 diff 都塞进提示词,真正有用的信息反而被埋住。
5. 临时需求混进长期规则
把一次性任务写进 CLAUDE.md、AGENTS.md 或长期 Memory,会让后续所有任务都带着旧上下文。
如果你遇到的是 Claude Code token 消耗突然变高,站内这篇更偏排查:/2026/07/08/claude-code-token-usage-spike-troubleshooting-faq/。本文重点是提示词本身怎么压缩。
第一步:先判断长在哪里
压缩前,先把提示词拆成几类:
| 内容类型 | 是否必须 | 压缩方式 |
|---|---|---|
| 当前目标 | 必须 | 保留一句明确动词 |
| 文件范围 | 必须 | 写具体路径或目录 |
| 约束条件 | 必须 | 保留会影响操作的约束 |
| 验收标准 | 必须 | 写测试命令或可检查结果 |
| 历史背景 | 看情况 | 只保留和当前任务有关的结论 |
| 完整日志 | 通常不必 | 只贴关键错误段 |
| 完整代码 | 通常不必 | 给路径,让 Agent 自己读 |
| 个人偏好 | 看情况 | 长期偏好放规则文件,不重复贴 |
| 情绪描述 | 不必 | 删除 |
| “顺便”任务 | 不建议 | 拆成下一轮任务 |
一个简单判断标准:这句话会不会改变 Agent 的下一步操作?
如果不会,就删掉或移到参考资料里。
第二步:把自然语言压成字段
很多长提示词的问题,是用聊天口吻写需求:
|
|
压缩后:
|
|
压缩后信息没有少,执行性更强。
AI 编程提示词最好像工单,不像散文。
第三步:只保留会影响决策的背景
背景不是不能写,而是要写成结论。
低密度背景:
|
|
压缩后:
|
|
把“故事”压成“事实和风险”。
模型不需要知道你怎么想起来的,它需要知道哪些事实会影响代码修改。
第四步:把“不要做”写清楚
长提示词里经常有很多委婉提醒,比如:
|
|
压缩后:
|
|
负向约束要具体。不要只说“谨慎一点”,要说“不要改什么”。
尤其是 AI 编程里,删除、移动、重构都要明确限制。防误删可以参考:/2026/07/10/ai-coding-avoid-accidental-file-deletion/。
第五步:把“顺便”拆掉
长提示词最容易失控的词是“顺便”:
|
|
这些需求会让任务边界扩大。
更好的做法是拆成阶段:
|
|
如果你确实需要长任务,先让 Agent 写阶段计划,再逐步执行。长任务中断恢复可以看:/2026/07/10/ai-agent-long-task-resume-guide/。
第六步:不要把完整文件粘进提示词
在 coding agent 里,文件通常可以由工具读取。你不需要把完整代码贴进提示词。
低效写法:
|
|
更好的写法:
|
|
这样做有两个好处:
- 提示词更短;
- Agent 可以按需读取,不必一次性吞完整上下文。
如果文件很大,可以进一步限制:
|
|
第七步:日志只贴关键段
测试日志和构建日志特别容易把提示词撑爆。
不要贴完整日志。先压成三段:
|
|
如果需要完整日志,放文件里:
|
|
这样比把几百行输出塞进聊天框更稳。
第八步:把长期规则移出提示词
如果你每次都重复写这些内容:
- 用
pnpm; - 不要改 migrations;
- 改 API 要跑测试;
- 不要删除文件;
- 输出中文总结;
- 先看
src/lib里有没有现成 helper;
说明它们应该进入项目规则文件,而不是每次复制。
可以放到:
AGENTS.md;CLAUDE.md;.cursor/rules/;- 项目内
docs/ai-workflow.md; - Codex Skill;
- Claude Code subagent 说明;
提示词里只引用:
|
|
代码库记忆工具和规则文件怎么选,可以看:/2026/07/10/ai-agent-codebase-memory-tools-comparison/。
第九步:压缩 CLAUDE.md / AGENTS.md
很多人的提示词不长,但规则文件很长。每次 Agent 启动都带着几千行规则,也会拖慢上下文。
规则文件压缩原则:
保留
- 构建命令;
- 测试命令;
- 禁止修改的路径;
- 代码风格硬约束;
- 安全边界;
- 提交和验证要求;
- 项目特有坑点。
删除
- 过期历史;
- 重复表达;
- 情绪化提醒;
- 长篇架构背景;
- 已经在 README 里的通用介绍;
- 一次性任务记录;
- “尽量”“最好”“注意一下”这类模糊话。
改写
原文:
|
|
压缩:
|
|
如果你想用工具自动压缩长期上下文,可以参考 caveman 的思路:/2026/07/03/caveman-agent-output-compression-guide/。但关键安全规则压缩后一定要人工复读。
第十步:把提示词压成三种模板
日常 AI 编程不需要每次重新组织语言。准备三种模板就够。
1. 排查模板
|
|
示例:
|
|
2. 修改模板
|
|
示例:
|
|
3. 审查模板
|
|
示例:
|
|
如果你同时使用 Cursor、Codex、Claude Code,可以把这些模板分配给不同工具:Cursor 负责定位,Claude Code 负责实现,Codex 负责审查。三工具分工可以看:/2026/07/10/cursor-codex-claude-code-workflow-division/。
压缩前后对比
原提示词
|
|
压缩后
|
|
更短,也更清楚。
什么内容不能压太狠
提示词压缩也有边界。下面这些内容不要为了省字数删掉:
- 安全边界;
- 权限限制;
- 数据库迁移要求;
- 生产环境风险;
- 不可删除文件;
- 用户明确验收标准;
- 法务、合规、隐私相关条件;
- 代码、命令、路径、错误字符串。
尤其是路径和命令,宁可完整写,不要压成模糊描述。
错误写法:
|
|
更好:
|
|
省 token 不能牺牲可执行性。
团队版压缩规则
团队可以把下面这段放进 AGENTS.md 或 CLAUDE.md:
|
|
这类规则能让团队里的 AI 任务更像工单,而不是每次靠个人发挥。
一张压缩清单
每次提示词太长,就按这张清单删:
| 问题 | 处理 |
|---|---|
| 目标超过一句 | 改成“动词 + 对象” |
| 背景超过 5 行 | 压成 3 条事实 |
| 文件范围不明确 | 写具体路径 |
| 出现多个“顺便” | 拆成后续任务 |
| 约束很多 | 分成“必须/禁止/可选” |
| 粘贴完整日志 | 只留命令、失败用例、关键错误 |
| 粘贴完整代码 | 给路径,让 Agent 读取 |
| 重复长期规则 | 移到 AGENTS.md / CLAUDE.md |
| 输出要求很长 | 写成列表格式 |
| 不确定要不要改 | 第一轮只分析,不修改 |
总结
AI 编程提示词太长,通常不是因为你太认真,而是因为目标、背景、约束、日志、代码和长期规则混在了一起。
最稳的压缩方式,是把提示词改成任务卡:目标一句话,范围写路径,限制写清楚,验证给命令,输出定格式。背景只保留会影响决策的事实;日志只贴关键段;长期规则移到项目文件;“顺便”拆成下一轮。
提示词变短以后,Agent 不一定更“聪明”,但会更少猜、更少读错文件、更少浪费上下文。对日常 AI 编程来说,这比一大段看起来完整的说明更可靠。