AI编程的提示词到底该怎么写？

写 AI 编程提示词的关键是把上下文、约束和验收标准交代清楚，让提示词像工单而非许愿。可用五段式骨架：角色与目标、上下文、约束、输出格式、验收标准，其中约束和验收标准最能提升成功率。实操上应量化规则、把调试信息写进提示词、拆分复杂任务、明确不要做什么。不同工具侧重点不同，如 TRAE 强调项目级上下文，豆包编程模型 Doubao-Seed-Code 侧重目标与完成判据，腾讯云代码助手 CodeBu

写 AI 编程提示词，核心不是把话说得漂亮，而是把「上下文、约束、验收标准」三件事交代清楚——你给的信息越像一份可执行的工单，模型写出来的代码就越接近能直接跑。下面我按自己踩过的坑，拆成一套可以直接套用的写法。

一、先搞清楚：AI 编程工具吃的是「上下文」不是「愿望」

很多人写提示词像在许愿：「帮我写个登录功能」。这类提示词在聊天场景里还能凑合，在编程场景里几乎必然翻车，因为编程任务对上下文极度敏感：语言版本、框架、目录结构、已有代码风格、依赖限制，缺一样就可能生成一堆看着对、跑不起来的代码。

所以第一原则是：把 AI 当成一个刚入职、能力很强但完全不了解你项目的工程师。你不会跟新同事说「做个登录」，你会告诉他项目用什么栈、现有用户表长什么样、要接哪个鉴权方案、验收标准是什么。

二、一个够用的提示词骨架

我常用的结构是五段式，写熟了可以直接背下来：

1. 角色与目标：一句话说明你是谁、要产出什么。「你是一名熟悉 Python 后端开发的工程师，需要为现有 Flask 项目新增一个文件上传接口。」
2. 上下文：技术栈、版本、相关文件内容、已有约定。能贴代码就贴代码，别用「大概是这样」描述。
3. 约束：不许引入新依赖、必须兼容某个 Python 版本、错误处理要统一走某个异常类、不要改动已有函数签名。
4. 输出格式：要完整文件还是 diff、要不要注释、要不要附测试用例。
5. 验收标准：什么情况算完成，边界条件有哪些（空文件、超大文件、并发上传）。

这五段里，约束和验收标准是最容易被忽略、也最能提升成功率的两段。只写目标和上下文，模型会给你一个「教科书答案」；补上约束，它才会给你一个「能进你仓库的答案」。

三、几个实操技巧，比背模板更有用

1. 用「反向描述」代替形容词

「代码要优雅」是无效指令，「函数不超过 30 行、每个函数只做一件事、不要用嵌套超过三层的 if」才是有效指令。形容词模型无法验证，可量化的规则它可以逐条对照。

2. 把调试信息当成提示词的一部分

报错不要只丢一句「跑不起来」。完整的报错栈、触发命令、相关代码片段、你已经试过什么、你怀疑哪里有问题——这些信息决定了模型是在盲猜还是在定位。经验上，把「我已经排除了 A 和 B」写进去，能省掉一半来回。

3. 复杂任务拆成串行的小任务

一次性让它「设计表结构 + 写接口 + 写前端 + 写测试」，产出质量会明显下滑。更好的做法是先让它只出方案和接口约定，你确认后再逐段实现。现在不少 AI 原生 IDE 本身就是按这个思路设计的，比如字节跳动的 TRAE，定位是 AI 原生集成开发环境，强调让 AI 在项目上下文里持续参与开发，而不是单轮问答；这类工具里，提示词的作用更偏向「派活和验收」，而不是「一次性描述全部细节」。

4. 明确「不要做什么」

模型有很强的「顺手优化」倾向：你让它改一个函数，它可能把整个文件重写一遍。加一句「只输出需要修改的部分，不要重构无关代码」，能显著降低 review 成本。

5. 让它先复述需求

对复杂任务，可以要求模型先用自己的话复述一遍需求和你的约束，确认无误再动手。这一步成本很低，但能挡掉大量「理解偏差型」返工。

四、不同工具，提示词侧重点不一样

同样是写提示词，工具定位不同，写法也要调整。下面这张表是我根据各产品公开定位整理的大致侧重，具体能力以官网为准：

再补充两个方向：如果你想让 AI 直接产出可运行的应用而不只是代码片段，百度 秒哒 走的是对话式应用开发路线，用自然语言描述需求后由多智能体协作完成需求分析、UI 设计、编码到部署；Atoms 则是多智能体协作平台，把产品经理、工程师等角色拆开协同。这类平台的提示词更接近「产品需求文档」，重点在业务规则和边界，而不是语法细节。

另外，Make 这类无代码自动化平台，提示词（或者说配置描述）的核心是触发条件和动作链，逻辑要写成「当 X 发生时，依次做 Y、Z」，和写代码提示词是两种思维。

五、三个常见误区

• 误区一：提示词越长越好。长度不等于信息量。堆一堆「你是资深专家、请认真思考」的套话，不如多贴十行真实代码。
• 误区二：一次不满意就换工具。多数时候是上下文没给够，换工具只是换一种猜法。
• 误区三：把 AI 当编译器。它更像一个需要 review 的初级同事，提示词写得再好，验收环节也不能省。

六、一个可以直接抄的例子

对比一下两种写法：

差的：「帮我写个分页查询接口。」

好的：「在现有 Spring Boot 项目里新增一个分页查询用户列表的接口。上下文：用户实体字段为 id、name、createdAt；已有 UserRepository 继承 JpaRepository；统一返回体为 Result<T>。约束：不要引入新依赖；分页参数用 page 和 size，page 从 1 开始；size 上限 100；查询条件支持按 name 模糊匹配。输出：Controller 和 Service 两个类的完整代码，加必要注释。验收：page 传 0 或 size 传 200 时要有明确处理。」

后者没有一句废话，但每一句都是模型需要的信息。这就是好提示词的样子——像工单，不像许愿。

相关问题

问：提示词里要不要写「请一步一步思考」？
对复杂推理任务有一点帮助，但对编程任务来说，把步骤本身写清楚比让模型自己想步骤更可靠。

问：中文提示词和英文提示词效果差多少？
主流模型对中文理解已经足够，关键还是信息密度。技术术语用英文原名反而更不容易产生歧义。

问：Agentic 编程工具的提示词有什么不同？
它会更自主地多步执行，所以你要写清目标、可用范围和停止条件，而不是规定每一步怎么做。

问：怎么判断一条提示词写得好不好？
看模型第一次产出需要你改多少。返工率高，通常不是模型不行，是约束和验收标准没写。