怎么写好提示词：几个不玄学的原则
Prompt Engineering 被包装得很玄，其实就几条经验和一点实验精神。分享我日常用 AI 写代码、学东西时实际有效的做法。
一句话：把 AI 当成一个聪明但不了解你背景的人
它不知道你要什么，不知道你懂什么，不知道什么对你来说是「好的」还是「坏的」。你的 prompt 就是在给它补这些上下文。
所以好 prompt 的核心不是「用什么魔法词」，是给足够清晰的上下文和约束。
原则 1：角色 + 边界一起给
❌ 「解释一下 Transformer」
✅ 「你是一个 AI 技术讲师，向有 3 年后端开发经验的程序员解释 Transformer。
用数据库查询类比 Q/K/V。不要讲数学公式，除非我问。」角色告诉它「以什么身份说话」，边界告诉它「什么是不能做的」。两者缺一不可。
我写的 System Prompt 里有一条硬规则：
「如果资料中没有答案，明确说'资料中未找到相关信息'」
这条约束让 AI 不会为了「看起来有用」而编造答案。
原则 2：给例子比给定义快十倍
❌ 「写一篇关于 Python 协程的文章」
✅ 「像下面这种风格写一篇 Python 协程的文章：
我之前写的《手写 RAG 全链路》开头：
> 我搭了一个 RAG 系统，每一层都是手写的——没有用 LangChain 的
> VectorstoreIndexCreator 一行出结果。本文记录全链路的技术决策和代码。
对，就是这种'做了什么 + 为什么这么做'的风格，不要说教。」这就是 Few-shot Prompting——给 AI 看一两个例子，比描述要求快得多。
原则 3：让 AI 自己思考过程
❌ 「这段代码有什么问题」
✅ 「逐行分析这段代码的问题。先列出你发现的每个问题，再给修复建议。」「逐行分析」「先……再……」——这些词触发的是 Chain-of-Thought。AI 在「思考过程」中产生的中间步骤，往往比直接蹦出来的结论准确。
对比一下数学题：
问：「357 × 468 = ?」
直接回答：→ 经常错
先让 AI 列竖式一步步算：→ 几乎全对原则 4：约束输出格式
❌ 「给我列几个 RAG 系统的优化点」
✅ 「用表格列出 RAG 系统的优化点。三列：环节 | 优化方法 | 预期收益。
不要加'总结'或'建议'段落，就一个表格。」LLM 很能说。不给格式约束它会写一篇小作文。给格式约束，输出变成结构化的、可解析的。
这是 LLM-as-Judge 评估靠谱的关键——我在评估脚本里每个 prompt 都要求「只回答一个数字」或「只回答相关/不相关」，因为 LLM 在约束格式下更少跑偏。
原则 5：迭代，不要一次写完
好的 prompt 是试出来的。我的流程：
- 写一版 prompt，跑三次看输出
- 输出哪里不满意，直接把问题告诉 AI：「你第二次给的例子太泛了，给我具体的代码」
- 把修正后的约束加进 prompt
- 重复到稳定
不要追求一次写出完美的 prompt。追求快速迭代。
总结
| 做 | 不做 |
|---|---|
| 给角色和边界 | 写「请帮我...」这种空泛提示 |
| 给 1-2 个例子 | 写一长串抽象要求 |
| 让 AI 一步步思考 | 期待一次出正确结果 |
| 约束输出格式 | 接受 AI 默认的啰嗦风格 |
| 迭代 3-5 轮 | 改一次就放弃 |
这些不是魔法，是工程化思维——把 AI 当一个需要清晰接口的模块，明确输入输出格式，测试、修正、再测试。