当前位置:首页 > 文章 > 正文内容

2026年Prompt Engineering实战:三层框架让你的AI编程效率翻倍、Token省75%

廖万里7小时前文章4

2026年Prompt Engineering实战:三层框架让你的AI编程效率翻倍、Token省75%

同样用Codex写代码,有的人10分钟搞定一个功能,有的人30分钟还在来回拉扯。差别在哪?不是工具、不是模型、不是网速——是指令。给AI的指令精确到哪个文件、哪个函数、哪种异常处理方式,输出质量天差地别。这篇文章不讲玄学,只讲实测有效的提示词框架——以及如何用最少的Token获得最好的输出。

一、为什么AI编程的提示词和ChatGPT聊天不一样?

很多人把和ChatGPT聊天的习惯直接搬到了Codex和Claude Code上,结果发现效率不升反降。因为两者的Token消耗模式和上下文管理方式完全不同:

维度ChatGPT对话AI编程工具
单次交互Token200-2000 Token5000-50000+ Token(含代码上下文)
上下文纯文本对话记录对话 + 文件内容 + 代码历史 + 工具调用结果
输出要求自然语言回答可执行的代码 + git diff + 文件写入
精度要求意思对就行语法、类型、接口签名、import路径全要对

AI编程的提示词本质上是用最少的Token描述清楚「改哪里、怎么改、边界是什么」。一个好的提示词可以省下50%以上的Token消耗——因为模型不需要反复试错来猜你的意图。

二、三层提示词框架

实测效果最好的AI编程提示词结构,分三层:

【层级一:目标层】你想达成什么

「为 src/api/users.ts 的列表接口添加分页功能」

【层级二:约束层】怎么改、有什么限制

「使用已有的 PaginationParams 类型,每页默认20条,支持 page 和 pageSize 查询参数,前端已适配」

【层级三:边界层】什么不能动

「不要修改数据库层的查询逻辑,不要改动其他接口,不要引入新的依赖包」

三层信息的完整示例:

在 src/api/users.ts 的 GET /users 接口中添加分页功能。
使用已有的 PaginationParams 类型(在 src/types/common.ts 中),
每页默认20条,支持 page 和 pageSize 查询参数。
不要修改 src/db/ 下的数据库查询逻辑。
不要改动其他接口。
不要引入新的 npm 依赖。
分页参数校验使用已有的 validatePagination 工具函数。

对比一下效果:

指令类型对话轮数Token消耗代码质量
模糊指令:「帮我给用户列表加分页」4-6轮约80,000 Token需要手动修改
精确指令:三层框架完整描述1-2轮约20,000 Token直接可合并

同样的功能,精确指令节省了75%的Token。以 bblabu 的价格计算(GPT-5.5百万Token约¥0.83),一次精确指令省下的60,000 Token相当于省了约¥0.05。看起来不多,但一天几十次交互,一个月就是几十块的差距。

三、不同任务的提示词模板

3.1 新增功能

在 [文件路径] 中新增 [功能描述]。
输入:[入参类型和来源]
输出:[返回值格式]
使用已有的:[相关工具函数/类型/组件]
不要:[限制条件]
测试用例:[关键测试场景]

3.2 Bug修复

在 [文件路径] 的 [函数名/行号] 有一个Bug:
现象:[具体什么表现]
预期:[应该是怎样的]
线索:[已知的调试信息、日志、报错]
不要改动:[相关但不需要改的部分]

3.3 代码审查

审查 [文件路径] 的代码:
- 安全性:SQL注入、XSS、权限校验、敏感信息泄露
- 性能:N+1查询、无索引查询、不必要的循环、未释放的资源
- 可维护性:命名、注释、函数长度、职责单一
按严重程度排序,给出具体修改代码

3.4 重构

重构 [文件路径/模块名]:
目标:[拆分/合并/抽象/简化]
保持:[外部接口不变、现有测试通过]
移除:[旧代码/废弃API/冗余逻辑]
新结构:[期望的目录或文件组织方式]

四、提示词里的「元信息」很重要

给AI编程工具的提示词比给ChatGPT的多了一层——你需要提供足够的项目元信息,让AI能理解代码上下文。最有效的做法是在项目根目录维护一个 .context.md 文件:

# 项目上下文
- 技术栈:TypeScript + Express + Prisma + PostgreSQL
- 目录结构:src/api(路由)、src/services(业务)、src/db(数据层)
- 通用类型:src/types/common.ts
- 工具函数:src/utils/
- 测试框架:Jest,文件命名 *.test.ts
- 代码规范:函数不超过50行,每个文件只export一个主函数
- 数据库:所有查询走 Prisma,不写原始SQL

把这个文件放在项目根目录,每次开新对话时引用一下:

# 配置API聚合平台(如bblabu)作为后端
export OPENAI_API_KEY="你的Key"
export OPENAI_BASE_URL="https://api.bblabu.cn/v1"

codex "参考 .context.md 的项目规范,然后在 src/api/orders.ts 中添加分页功能"

这样不用每次对话都把项目信息重新讲一遍——.context.md里的一次性Token投入,换回的是每一次对话的高质量输出。

五、提示词优化的实测数据

我做了个实验:同一个任务「实现用户注册API」,用模糊指令和三层框架指令分别让Codex执行,对比结果:

指标模糊指令三层框架指令提升
对话轮数6轮2轮3倍效率
总Token消耗94,50023,20075%省
手动修改次数3处0处100%省
包含输入校验缺失完整-
包含异常处理缺失完整-
代码符合规范部分不符合完全符合-

模糊指令的结果是:代码能跑,但缺少校验和异常处理,需要人工补充。三层框架指令的结果是:直接可以合并,零改动。两者的Token费用差了整整4倍。

六、常见的提示词错误

错误1:太模糊

# 错误:模型需要猜你的意图
codex "帮我优化一下这个函数"

# 正确:明确优化目标和限制
codex "优化 src/utils/parser.ts 的 parseConfig 函数:
- 目标:减少正则表达式的执行次数
- 限制:不改变函数签名和返回值格式
- 线索:当前瓶颈在第45行的嵌套循环"

错误2:缺少边界

# 错误:模型可能改动不该动的代码
codex "给用户接口添加分页功能"

# 正确:明确什么不能动
codex "给 src/api/users.ts 的 GET /users 添加分页功能。
不要修改数据库查询逻辑。
不要改动其他接口。
不要引入新的依赖。"

错误3:一次说太多

# 错误:一个提示词包含5个不相关的功能
codex "添加分页、搜索、排序、导出、缓存功能"

# 正确:一个提示词一个功能
codex "在 src/api/users.ts 的 GET /users 添加分页功能..."
# 完成后再做下一个功能

七、总结

AI编程提示词的核心原则就三条:

  1. 说清楚「改哪里」——文件名、函数名、行号,越精确越好
  2. 说清楚「怎么改」——数据类型、接口格式、命名规范、异常处理
  3. 说清楚「别动什么」——保护不该动的代码,比告诉AI该做什么同样重要

好的提示词不是「更聪明」,而是「更精确」。精确到什么程度?精确到AI不需要猜你的意图。AI猜一次就用掉几千Token,猜三次就上万——而你的API账单上,每一Token都在计费。

掌握三层框架和四套模板,日常的AI编程效率至少提升一倍——而且代码质量更高,来回拉扯更少。配合低Token单价的 API聚合平台,同样的预算可以做更多的事。


相关资源:

本文作者是一名全栈开发者,专注AI编程工具和效率优化。如果你有好的提示词经验,欢迎在评论区分享。

本文链接:https://www.kkkliao.cn/?id=3976 转载需授权!

分享到:

版权声明:本文由廖万里的博客发布,如需转载请注明出处。


发表评论

访客

看不清,换一张

◎欢迎参与讨论,请在这里发表您的看法和观点。