技能介绍

你要解决的问题

模型「不够聪明」的时刻，多半不是能力问题，而是提示词本身含糊。be helpful 这类空泛指令不会约束模型行为；把多个不相关任务塞进一个 prompt、要求「有创意」却期待确定性输出、只说 don't do X 却不给出替代做法，都会让结果难以复现。排查这类问题时，工程团队缺的不是调参技巧，而是一份可对照、可评审的写作规范。

技能如何工作

这个技能把提示词拆成几个可操作的组件，并给出明确的写法约束：

结构化系统提示：按角色（role）、范围（scope）、输出格式、约束四段组织，且要显式写明模型不应做什么。
思维链（Chain-of-Thought）：对多步推理任务，强制模型展示中间步骤，而不是直接给结论。
少样本示例：提供 3-5 个多样化示例，既演示期望格式，也覆盖边界情况。
工具调用描述：写函数说明时要讲清 WHEN 该用这个工具，而不只是它做什么。
模板化而非硬编码：prompt 应以 {diff} 形式的占位参数化，方便复用与测试。

同时附带一份反模式清单，逐条点名常见的坏写法，并给出一份评审 checklist，覆盖输出格式声明、温度与 top_p 配置、对抗性输入测试等项目。

适用边界与注意点

这套规范面向的是工程化的提示词管理，不是 prompt hacking 或模型微调指南。思维链在多步推理上有效，但会抬高延迟与 token 成本，简单问答不必启用。少样本示例需要持续维护，示例本身也可能过时或带有偏见。工具描述写得再好，也只是降低误调用概率，仍应在运行时做参数校验与兜底逻辑。最后，checklist 不能替代测试：没有对抗性输入的验证，提示词的正确性无从谈起。