提示词写到一定程度会遇到天花板：同一个模型，别人问出来的答案结构清晰、拿来就能用，你问出来的还是一堆散装段落。差别通常不在"话说得漂亮"，而在三个技术动作——让它先想、给它例子、要求它按格式交。
思维链：先想再答，准确率会变
思维链（Chain of Thought）不是一个开关，而是一种要求：让模型把推理步骤写出来，再给结论。对多步计算、条件判断、逻辑排错这类任务，先列步骤的答案通常更稳——因为模型生成每一步时都在重读前面的推理，相当于自己给自己做了检查。
用法很朴素，在问题后面加一句"先分步推理，最后单独给出结论"。但要注意两点：简单任务别用，白烧 token，还可能把原本直接的答案绕复杂；如果你要拿最终结果去用，就让推理和结论分开写，别混在一段里。
让它先想，不是让它啰嗦——步骤该短就短。
少样本：两个好例子胜过十句形容词
少样本（Few-shot）就是在提问里附上几个"输入 → 输出"的范例，让模型照着你给的样式来。它对风格和边界最有效：语气要什么味、字段怎么填、什么情况下该拒答，说十句不如给两个例子。
挑例子有三条经验。一是覆盖差异：正例之外至少给一个反例，模型才知道边界在哪。二是格式完全一致：标点、字段名、换行都要对齐，只要有一处不统一，模型就可能学到错的东西。三是例子控制在三个以内，超过之后收益递减，还白占上下文。
例子是给模型看的"标准答案"，不是给它看的"范文赏析"。
结构化输出：让结果能直接被程序用
三种做法，按可靠程度从低到高排。最低是自然语言要求：在提示里写清字段名和顺序，适合人看的场景。中间是模板约束：先给一段空的 JSON 或表格骨架，让它只填值，格式跑偏的概率会明显下降。最稳的是走接口的结构化输出能力：在请求里声明要 JSON，服务端会强制校验，模型吐不出合法 JSON 就会被退回重试。
无论用哪种，都要在提示里把"空值怎么办"和"没有依据时怎么答"写清。前者决定你会不会拿到一堆空字段，后者决定模型会不会为了填满字段而硬编内容。
常见问题
思维链会让回答变慢吗
会，输出 token 变多，整体耗时自然拉长。判断标准是任务值不值得：算账、排错、多条件筛选值得；改错别字、查名词解释不值得。
少样本和系统提示词能一起用吗
可以，而且推荐。系统提示词定规则——角色、语气、禁区；少样本给样式——具体长什么样。规则负责"不许做什么"，例子负责"要长成什么样"，两者不冲突。
做了结构化输出还要不要兜底校验
要。接口层的 JSON 模式能保证语法合法，但保证不了语义正确：字段可能填错、值可能超出枚举。落库或调下游之前，仍然要校验一遍取值范围。