和大模型打交道，本质是在用自然语言「编程」——提示词就是你的接口文档。下面是一套在日常里很稳的写法，不追求玄学，只追求可复现。
为什么「多说几句」往往更准
模型不知道你没说出来的前提。省略上下文时，它会用统计上最常见的补全来填坑，于是出现答非所问、漏条件、格式不对等问题。把任务拆清楚，比换模型更划算。
一个简单的四段式结构
- 角色与背景：你是谁、文档面向谁、领域是什么。
- 任务：要完成的动作，用动词开头（总结、翻译、对比、生成表格）。
- 约束：长度、语气、必须包含/禁止提及的点、知识边界（例如「仅根据下文引用」）。
- 输出格式：Markdown 标题层级、JSON 字段名、表格列名等，必要时给示例。
写成一段话或分条都可以，关键是四块都要有；缺了「约束」，就容易自由发挥；缺了「格式」，后处理会痛苦。
少样本（Few-shot）什么时候用
当你要的不是常识推理，而是固定风格或固定结构时，在提示里贴 1～3 个「输入 → 期望输出」示例，往往比长篇规则更有效。注意示例要干净、彼此一致，不要互相矛盾。
链式任务：一次只做一步
复杂需求可以拆成多轮：先让模型列大纲或提取要点，再在下一轮基于该结果写正文或改代码。每轮提示只负责一个明确子任务，比「一句话塞满」更可控。
和幻觉共处
模型会「编得像真的」。对事实敏感的内容要要求引用出处或标注不确定，并在流程里保留人工核对。提示里写「不知道就说不知道，不要编造」能降低胡编概率，但不能替代校验。
小结
把提示词当成小型需求文档：角色、任务、约束、格式四件套 + 必要时 few-shot + 复杂任务分步，通常就能从「偶尔好用」变成「基本稳定好用」。真正上线时，再把成功提示版本化，和代码一起迭代。
