Prompt 优化的七条主线：会写、会推、会持续改
声明：本文仅有20%的内容有AI参考（语句流畅度调优，文章结构优化）。
引言：这篇文章会回答三个问题
这篇文章我会试着回答三个问题：
- 哪几类 Prompt 技巧最常用？
- 它们为什么有效？
- 在 vibe coding / agent / skill / AGENTS.md 里，怎么落地这些技巧？
视角是一个写过 skill、AGENTS.md，用过 Cursor / Claude Code / Codex / OpenSpec 的前端开发者。
2026-01-22 日，Anthropic 发布了第二篇关于 skills 的深度博客 《Building agents with Skills》，之后一周内我就开始大量使用 skills（因为当时在打数学建模比赛），想着沉淀一套可复用的提示词正式比赛用，现已开源：https://github.com/Jaxon1216/mathmodelworkspace
一、七种最常用的 Prompt 技巧
提前说一句：下面这 7 条不是同一层级。前 5 条是“写法层”——告诉模型怎么写；第 6 条是“流程层”——告诉自己怎么持续改 prompt；第 7 条是“位置/接口层”——告诉模型在哪里接收这套规则。
| 技巧 | 核心要点 | 示例 (用户提示词) |
|---|---|---|
| 1. 明确指定任务和角色 | 设定角色，明确任务。 | “你是一位熟悉 React 19 + TypeScript 的前端工程师。请帮我把这段 class 组件改写成函数组件，并解释 hooks 的取舍。” |
| 2. 提供详细说明和示例 (Few-shot) | 给出期望的输出格式、风格，并提供输入-输出范例。 | 给出一对样例：“输入：登录页加载慢 -> 输出：{ category: 'performance', severity: 'P1', suggested_owner: 'frontend' }”，要求模型按同样结构对新的 bug 描述做分类。 |
| 3. 使用结构化提示 | 通过列表、表格、JSON 或 XML 标签组织输入/输出格式。 | “请用 JSON Schema 描述一个 <UserCard /> 组件的 props，字段包含 name、avatarUrl、role、onClick，并在每个字段下注明类型与是否必填。” |
| 4. 思维链提示法 (CoT) | 引导模型展示推理过程，一步步思考。 | “请一步步思考：先列出可能造成 React 列表渲染卡顿的 3 个原因，再针对每个原因给出排查命令或代码定位思路，最后给出最有可能的那一个。” |
| 5. 分解任务 | 将复杂任务拆解为多个小步骤，逐步完成。 | “帮我加一个收藏按钮，按以下步骤：1.设计 props 与状态；2.列出需要新增/修改的文件；3.写出组件代码；4.补一个最小单测；5.给出 commit message。” |
| 6. 迭代式优化 | 根据模型输出分析错误，反复修改提示词。 | “初始：写一个 Cursor skill 帮我做 code review。” -> “优化：写一个 skill：触发词 /cr；输入是 git diff；输出严格按 问题 / 影响 / 修复建议 三段式；只关注本次 diff 的改动。” |
| 7. 善用系统提示词 | 设定 AI 的整体行为、个性、能力和边界。 | 在仓库 AGENTS.md 里写明：“默认使用 TypeScript；组件优先函数式 + hooks；改动需附最小可运行示例；禁止直接 push 到 main 分支。” |
一句口诀帮你串起来：角色（1） + 样例（2） + 格式（3） → 推理（4、5） → 持续优化（6、7）。
一句话记住这一节：Prompt 的工具箱其实并不大，关键是知道每条技巧解决的是哪一类问题。
二、它们为什么有效：从下一个 Token 说起
我目前（2026.05）没有深入研究过大模型训练原理，但从一个使用者的视角看，这件事抽象起来其实并不难理解。
我们都知道，AI 本质是一个概率模型，可以把生成过程抽象成：一个字一个字地预测下一个 token。
所以可以把表格里的 7 种技巧大致映射到三类影响：
- 词汇 / 风格分布层：影响下一个 token 倾向于什么风格的内容。
- 格式与样例层：影响输出的结构、节奏、固定话术。
- 推理路径层：拉长生成过程中“中间步骤”的展开，让最终答案站在更结实的基础上。
对应到具体技巧：
-
第一类（角色 / 系统提示词）：当上下文里反复出现「前端工程师、React、精简回答」这类词，模型在采样下一个 token 时，技术术语、短句、代码相关 token 的概率会被显著抬高，闲聊、长篇抒情、无关内容的概率被压低。这不是“锁死了一个词汇池”，而是整个候选 token 的分布被重新塑形。
-
第二类和第三类（few-shot / 结构化提示）：样例 = 固定的文本句式、排版、用词规则。
- 模型会学习样例里的字符排列规律：比如回答必须分点、必须带指定标题、结尾必须加固定话术。
- 在后续预测时，它会复刻样例的语序、格式、用词习惯。
- 直白例子：样例里回答全是 “1.xxx 2.xxx”，模型后续生成时，
1.这个符号的概率会被拉到最高，自然就按你的格式输出。
-
第三类的另一面（CoT / 任务拆解）：让模型显式生成中间步骤，相当于在最终答案之前多铺一层上下文。每多写一段思考，后面的预测就被这段思考强烈引导。
为什么“加格式 + 加约束”普遍更准
大模型本质是“下一个词预测器”。技巧的本质是通过明确的指令和格式，重新塑造模型输出的概率分布，从而让它生成我们期望的内容。CoT 这类做法的关键，是把“中间推理过程”显式写出来，让最终答案的预测站在更结实的上下文上。
怎么评估 Prompt 改得好不好
- 建立一个测试用例集，每次修改 prompt 后都跑一遍。
- 用自动化指标（格式正确率、字段命中率等） + 人工评估（相关性、准确性）一起看。
- 如果有条件，做 A/B 对比，挑稳定性更好的版本。
一句话记住这一节：所有提示技巧，本质都是在重塑下一个 token 的分布。
三、CoT 与 thinking 模式：一个值得展开的专题
是什么
CoT（Chain of Thought）思维链 就是让大模型别急着给答案，先把推理过程一步步写出来。在数学题、逻辑推理、多步骤问题上，CoT 通常能带来明显的稳定性和准确率提升。
核心原理很直白：人做复杂题也得打草稿，让 LLM 把“草稿”写出来，中间步骤错了更容易发现，最终答案也更靠谱。
怎么实现
实现 CoT 主要有两种方式：
1）Few-shot CoT：给几个带推理过程的例子，让模型照着学。
# Few-shot CoT 示例
问题：一本书 48 页，小明每天读 8 页，几天能读完？
思考：要求读完需要的天数，就是用总页数除以每天读的页数。48 ÷ 8 = 6
答案：6 天
问题：教室里有 5 排座位，每排 6 个座位，坐满了学生后又来了 3 个学生，现在教室里有多少学生？
思考：2）System Prompt 引导：在系统提示词里明确要求展示推理过程。
# system prompt
你是一个善于逻辑推理的助手。回答问题时，请遵循以下步骤：
1. 先分析问题的核心是什么
2. 列出解决问题需要的已知条件
3. 逐步推导，每一步写清楚依据
4. 最后给出明确答案thinking 模式是怎么回事
我们经常看到 DeepSeek 的 thinking 模式、Claude 的 thinking、OpenAI o 系列的 reasoning 模式。
在使用体感上，这些模式可以理解为：把 CoT 当成模型的默认行为，内置进了模型本体。换句话说，你不用再手动写“请一步步思考”，模型自己就会在给最终答案之前先生成一段中间推理。
严格地说，thinking 模式 ≠ 自动在上下文里拼一段 CoT prompt。不同厂商的实现细节并不一样：有的是训练阶段强化出的能力（用 RL 反复训练“先思考、后回答”），有的会把思考过程隐藏起来对外不可见。但在直觉理解上，把它类比成“内置 CoT” 是一个不错的入门思路。
简单链路可以画成这样：
用户问题 → 自动生成思考内容（写入上下文）→ 候选 token 分布被重塑 → 生成最终答案进一步思考
CoT 真要落地时，最常被追问的是这两个问题。
Q1：如果模型在 CoT 的中间步骤就推错了，后面的步骤会全跟着错，怎么缓解？
几个方向可以尝试：
- Self-Consistency：采样多条路径然后投票，单条错了只要多数对就行（答案级冗余）。
- Self-Verification：生成答案后让模型用答案反推验证，不对就重来（结果级反推）。
- Step-by-Step Verification：每一步都让模型打分评估置信度，置信度低的步骤触发重新生成（步骤级评分）。
在 reasoning 模型（OpenAI o 系列、DeepSeek-R1、Claude 的 thinking 模式等）里，这件事其实已经被部分内置了——它们在训练阶段就用 RL 反复强化“先思考、自我检查、再回答”的行为，相当于把 Self-Verification 和 Step-by-Step Verification 提前烤进了模型本体。但回到日常工程，最简单有效的依然是 Self-Consistency：多花几倍成本采样投票，稳定性提升立竿见影；再叠加一道“让模型用最终答案反推一遍输入”的兜底校验，性价比通常就够用了。
Q2：在实际项目里，怎么判断一个任务适不适合用 CoT？
看两个指标：
- 任务是否需要多步推理：如果问题本身一句就能答上来（例如“Python 列表怎么排序”），CoT 收益微弱，反而会让响应更慢。
- 直接问答的错误率：先不用 CoT 跑一批样本，如果准确率已经很高，CoT 的提升空间有限；如果错误率明显，CoT 通常能拉高一截。
一个经验法则：问题里有数字运算或条件分支时，CoT 的收益通常更明显。
在已经具备推理能力的 reasoning 模型上，你通常不需要再额外要求 CoT，模型内部已经替你做完了。
一句话记住这一节：CoT 不是魔法，它只是把“推理”显式化了；thinking 模式则是把这件事默认化、内置化。
四、工程落地：在真实项目里怎么用
到这里我们其实已经知道：
- 模型从头到尾都还是逐 Token 概率预测，没有改变底层原理；
- 所有提示技巧，本质都是扩充、改造输入上下文；
- 上下文里的角色、样本、格式、步骤，会重新塑造每一个候选 token 的概率分布：
- 符合预期的词 → 概率被显著抬高
- 偏离要求的词 → 概率被压低、几乎不会被选中
- 最终效果就是：模型“看起来”听懂了要求，全程按照你的想法输出内容。
那在实际工程里怎么用？根据我的个人经验，我把它归成几种典型场景。
场景 1：设计 skill / 自定义工具集
- 常用技巧：1（角色）、3（结构化）、4（CoT）、5（任务拆解），并在 reference 层挂 few-shot。
- 为什么是这几个：skill 是“可被反复触发的提示词包”，所以要先用角色锁定使用场景，再用结构化和任务拆解约束输出，再用 reference 给例子，让模型“照着样子干”。
场景 2：单纯 AI 对话
- 常用技巧：1（角色）、4（CoT）、5（任务拆解）、7（系统提示词）。
- 为什么是这几个：日常对话里你没有 skill 这层封装，只能靠一次性 prompt 把“角色 + 思考方式 + 拆解步骤 + 边界”一次性灌给模型。
- 写 prompt 时可以默念这五个词：角色 / 思考 / 任务拆解 / 结构化 / 边界。
下面给一个我自己常用的提示词样例，里面同时包含了角色认定、CoT 思考引导、行为边界约束这三件事：
最终回复如下，可以看到考虑的维度比较全面，我只需要一一确认就行了：
本文就是在我的草稿的基础上，用上面这套 prompt 优化得到的定稿。
场景 3：用户 / 项目级 rules、AGENTS.md
- 常用技巧：任意你个人习惯的技巧，重点是把“重复的偏好”沉淀下来。
- 为什么是这几个：这一层是 prompt 的“配置文件”，目的不是解决某一个具体问题，而是让你以后写 prompt 时自动获得一套默认偏好。
场景 4：已有的 vibecoding 范式
- Cursor / Claude Code 的 plan 模式，本质 ≈ 任务拆解（5）+ CoT（4）的显式化。
- OpenSpec、HermesAgent 等做法，本质上也是把“角色 + 结构化 + 拆解 + 评估”预先封装好，让你直接复用。
一句话记住这一节：Prompt 工程不只是“写一句话”，而是“在合适的位置，沉淀合适的技巧”。