最近半年开发时有个变化越来越明显：写代码的时间越来越少，而写提示词的时间越来越多。
这不是懒惰。而是我切身体会到：给 AI 一个高质量的提示词，它能在 30 秒内生成一个原本需要花 20 分钟才能写完的模块；但如果提示词写得模棱两可，AI 产出的代码就像实习生第一天的作品——能运行，但不敢直接上线。
所以这篇文章不谈“AI 是否会取代程序员”这类宏大话题，只聚焦一个具体问题：如何编写提示词，才能让 AI 输出真正可用的代码。
一、先搞清楚一件事：提示词不是“聊天”
很多人使用 AI 写代码的方式是这样的：
然后 AI 给你一段 HTML + CSS + JS，样式停留在 2018 年，逻辑里直接“把密码明文发给后端”。你只看了一眼就关掉了。
问题出在哪？不是 AI 不够强，而是你给的信息太少。
试想，如果你对新来的同事说“帮我写个登录页面”，他大概率也会追问一堆问题：用什么框架？有设计稿吗？要不要记住密码？后端接口的格式是怎样的？
AI 不会主动追问。它只会“猜测”。
因此第一条原则：提示词不是闲聊，而是一份简明但完整的需求文档。
二、一个好提示词的五根骨头
根据踩坑和反复调优的经验，一个靠谱的提示词，在结构上需要五类要素：
1. 角色（Task/Role）
告诉 AI 它的身份。这并非角色扮演，而是帮助它锁定“该用哪种知识体系来回应你”。
对比：
- 弱：“帮我写个网络请求封装”
- 强：“你是一个有 5 年 iOS 开发经验的工程师，精通 Swift Concurrency 和 URLSession，请帮我封装一个网络请求层”
添加角色后，AI 的输出会明显更“对味”——它知道该用 async/await 还是回调，该不该引用第三方库。
2. 上下文（Context/Content）
将 AI 需要的原始数据直接提供给它：代码片段、API 文档、错误日志、数据结构定义……你给得越精确，它需要猜测的就越少。
一个实用习惯：直接把相关代码贴进去，而不是用自然语言描述代码。
“我有一个 User 模型，包含 name、email、avatar 字段”——不如直接把 struct 定义贴过去。AI 读取代码比理解文字描述准确得多。
3. 指令（Instructions）
分步骤告诉 AI 你希望它做什么。这里有一个反直觉的经验：你写得越像操作说明书，AI 的输出质量越高。
例如：
这比“帮我封装一个网络请求”好十倍。
4. 示例（Examples）
这是很多人容易忽略的杀手锏。给 AI 一个输入输出的范例，效果相当于手工调参。
如果你希望 AI 生成的代码与你项目的风格保持一致，最好的方法就是贴一段项目里已有的代码，并告诉它：“请参考这个风格来写。”
Few-shot learning 听起来像学术术语，其实核心就是“别光说，给它看”。
5. 约束（Constraints）
告诉 AI 什么不能做、什么格式必须遵守。这是控制输出质量的最后一道屏障。
常见约束包括：
- “不要使用任何第三方库”
- “所有方法必须添加注释”
- “返回的 JSON 必须符合以下 schema”
- “不要省略错误处理”
- “代码中不包含中文注释”
最常用的一条：“不要省略任何实现细节，不要用 // ... 占位”。因为 AI 特别喜欢在关键逻辑处偷懒。
三、进阶：十个维度把提示词武装到牙齿
如果说上面五根骨头是“能用”，下面这十个维度就是“好用”。这是从实践总结的全景清单，编写复杂提示词时建议逐项检查。
1. 任务背景
用一两句话说明你在做什么项目、解决什么问题。别让 AI 在真空中写代码。
2. 语气/风格
你希望得到“严谨的生产级代码”还是“快速验证的原型”？AI 会根据这个调节代码的详细程度和防御性编程的力度。
3. 背景数据
把所有需要的信息都喂进去：代码文件、接口文档、截图、错误堆栈。信息不足时，AI 只能依靠想象力填空——而 AI 的想象力，就是你的 bug。
4. 详细任务描述与规则
这是提示词的主体部分。越具体越好，越结构化越好。使用编号列表、层级缩进，不要写成大段自然语言。
5. 示例
前面提过，这是杀手锏。特别是当你需要特定的输出格式或代码风格时，一个例子胜过千言万语。
6. 对话历史
如果是在多轮对话中迭代，注意 AI 的上下文窗口。关键信息如果出现在很早之前的对话里，建议重提一遍。不要指望 AI 的“记忆力”。
7. 即时任务请求
在长提示词中，把“你现在要做的事”放在最后，并且要醒目。AI 对“最后出现的指令”权重更高。
8. 逐步思考（Chain-of-Thought）
在提示词中加入一句“请逐步思考”或“Think step by step”，对复杂逻辑问题有肉眼可见的提升效果。
这听起来像玄学，但确实有效。原理很简单：你让 AI 把中间推理步骤写出来，它就不容易跳跃出错。就像让人“心算 347 × 28”和“在纸上算 347 × 28”，后者的准确率要高得多。
9. 输出格式
明确告诉 AI 你想要的格式：纯代码？Markdown？JSON？带注释还是不带？一个文件还是多个文件？
经验表明：如果你不指定格式，AI 会按自己的心情输出。而它的心情，不太稳定。
10. 预填回复（Prefill）
部分 AI API（如 Claude）支持在 assistant 消息里预填内容。这个技巧在代码生成场景下特别好用——你可以预填 ``swiftn` 来强制它直接输出代码，省掉前面那段“好的，我来帮你实现……”的废话。
四、实战模板：一个常用的提示词结构
说了这么多方法论，不如直接看一个日常使用的模板框架：
## 角色你是一个资深 [语言/平台] 工程师，擅长 [具体领域]。## 背景我正在开发 [项目简述]，当前需要实现 [功能简述]。## 相关代码/数据[直接贴代码、接口定义、数据结构]## 任务请按以下步骤实现：1. [步骤一]2. [步骤二]3. [步骤三]## 约束- [约束一]- [约束二]- [约束三]## 输出要求- 输出完整可运行的代码- 不要省略任何实现- [其他格式要求]
这个模板不是固定的。简单任务会砍掉一半内容，复杂任务会加上示例和对话历史的引用。但这个骨架能节省大量“反复调试提示词”的时间。
五、最后说两句大实话
提示词工程不是银弹。 它能把 AI 的输出从 60 分拉升到 85 分，但最后那 15 分——架构判断、边界 case、性能调优——仍然需要你自己完成。AI 是你的副驾驶，不是你的替身。
写好提示词的最佳练习，就是多写代码。 这听起来像废话，但事实如此：你对目标代码的理解越深，就越清楚该在提示词里写什么、不写什么。一个不懂网络编程的人，写不出能让 AI 生成高质量网络层的提示词。
别追求一次完美。 好的提示词往往是迭代出来的。第一版给 AI，看它哪里理解错了，然后补充约束、加上示例、调整措辞。这个过程本质上就是在与 AI“对齐认知”。跟带新人一样：第一次没说清楚很正常，重要的是你能快速定位到“哪句话让它理解偏了”。
写到这里突然想到一件有意思的事：写好提示词所需的能力——清晰表达需求、结构化思维、预判边界条件——其实就是写好技术文档和写好代码所需的能力。
工具在变，底层能力没变。
