这是《从“模板库”到“工作流”》系列的第 2 篇。 上一篇：底层逻辑：模型怎么工作
我们最后固定下来的其实是一个很朴素的骨架。即便你只补齐这其中的两三项，结果几乎总会明显变好。
角色（Role）：
你扮演什么身份？（如“你是资深 B2B 文案”）。
受众（Audience）：
谁会读这段内容？（如“中型公司的运营经理”）。
背景（Context/Background）：
当前任务发生在什么场景？有哪些可用材料？
任务（Task）：
你要完成什么？
约束（Constraints）：
语气（Tone）：如“自信但不过度推销”。
具体限制：字数、禁用项、遇到缺失信息怎么办。
输出格式（Format）：
Markdown 表格、JSON、4 条要点等。
这层骨架的核心价值在于把任务“收窄”，减少模型猜测的空间。OpenAI 和 Google 的提示设计文档里反复强调的也正是这些点：说明白角色、任务、限制、格式，并且通过迭代不断修正。(OpenAI Developers)
结构化提示与分隔符
为了避免指令和待处理内容混淆，我们建议显式使用分隔符：
- 使用 标题 和 冒号（如
待处理文本:）。 - 使用 分隔线（如
###或---）。 - 使用 三引号（
"""）包裹长文本。 OpenAI 的官方建议也强调了这一点：把指令放前面，并用分隔符将指令与上下文隔开，能显著降低模型误读的概率。(OpenAI Help Center)
Zero-shot 和 Few-shot，我们是按“格式敏感度”来选的
团队一开始特别喜欢问“这个任务到底该用 zero-shot 还是 few-shot”。后来我把问题换了个问法：你这件事到底有多怕输出格式跑偏？
如果任务本身很直接，比如情感分类、短摘要、简单改写、固定事实问答，zero-shot 通常够用。 但只要任务开始涉及到严格的标签集、JSON 字段、特定风格或微妙的判断标准，few-shot 往往就值回票价。
比如标签映射、字段抽取、固定写作腔调、统一化简历表述。这类任务里，示例往往比长篇解释更稳。
复杂推理路径：从 CoT 到 ToT
在复杂任务里，我们更少追求“直接给答案”，更多先让模型拆问题。
Chain-of-Thought (CoT)
Chain-of-Thought 系列方法的核心不是“把思维过程写得越长越厉害”，而是因为复杂任务本来就需要中间步骤。论文里给出的结论也很明确：在复杂算术、常识和符号推理任务上，带中间推理示例的 prompting 能显著改善表现。(arXiv)
ReAct (Reasoning and Acting)
ReAct 的核心不是单纯多想两步，而是把 reasoning 和 acting 交织起来：模型一边生成推理轨迹，一边调用外部信息源或环境动作，再根据观察结果继续推进。这在需要边查边答、边做边改的业务流中极其实用。(arXiv)
Tree of Thoughts (ToT)
Tree of Thoughts 解决了候选路径太多的问题。它不是只沿着一条路径往前走，而是把中间想法当成可以展开、评估、回退的节点，允许多路径探索和自我评估。这在做方案权衡、优先级排序等决策任务时表现极佳。(arXiv)
更多进阶调优手段
采访式提示（Interview-style Prompting）
当你也不确定需要提供哪些背景时，直接让模型先采集信息。
- 写法：先告诉模型目标，然后要求它“一次先问我三个问题，收集必要的背景，直到你认为信息足够了再开始产出”。
- 优点：能逼出平时容易被你省略的关键信息（如受众痛点、公司禁忌等），结果往往比“一次性随手写”更对味。
链路拆解（Prompt Chaining）
复杂任务不要指望一个万能提示词搞定。
- 做法：先生成提纲 -> 扩写内容 -> 抽取摘要 -> 质检 SEO。
- 优点：降低漏项风险，每一步都可以单独检查和重试，极大地提升了自动化流水线的可靠性。
自我评估（Self-evaluation）
把模型产出的结果再交给模型（或另一个会话）做一轮质检。
- 做法：要求模型评价一段内容的清晰度、完整度并给出修改建议。
- Tip：最好换一个新会话做，防止模型为了“面子”而自我合理化；或者让另一个更强的模型作为裁判。
继续阅读： 下一篇：业务落地、附件与 RAG