先区分两个概念，后面才好用：提示词描述目标，指令控制过程。「写一份竞品分析」是提示词；「先列三家竞品，再按价格、渠道、卖点三列对比，最后给一句结论」是指令。前者决定方向，后者决定形状。
01指令到底在控制什么
模型每次回答，其实在做四个决定：说多少、说什么、怎么说、说得多确定。指令就是在替你把这四个决定提前定下来。
说多少
长度、条数、层级。不定就会给你一篇不长不短的中间态。
说什么
范围、优先级、必须包含与明确排除的内容。
怎么说
语气、人称、专业度、能不能用比喻。
多确定
要不要给不确定的地方打标记，能不能说「不知道」。
02六类高频指令词
① 控制输出量
| 指令 | 效果 | 适用 |
|---|---|---|
| 用三句话概括 | 强制压缩，砍掉铺垫 | 汇报、摘要 |
| 只保留结论，不要过程 | 去掉推理链 | 给领导看的材料 |
| 展开第 2 点，其余不动 | 局部加深，避免整体重写 | 已经改了七成的稿子 |
| 每条不超过 20 字 | 逼出短句，适合做标题或要点 | PPT、海报 |
② 限定范围
| 指令 | 效果 |
|---|---|
| 只讨论 2024 年之后的变化 | 排除过时信息 |
| 不要提价格，只谈使用体验 | 避开敏感或不想碰的角度 |
| 面向完全不懂行的人 | 强制降低术语密度 |
| 假设预算只有 5000 元 | 把泛泛建议逼成可执行方案 |
③ 调整风格
| 指令 | 效果 |
|---|---|
| 去掉「赋能、闭环、抓手」这类词 | 去黑话，立刻像人话 |
| 用第一人称，像在跟朋友说话 | 口语化，适合社媒 |
| 不要用感叹号和问句 | 去掉推销腔 |
| 保持中性，不做价值判断 | 适合分析、对比 |
④ 推进流程
| 指令 | 效果 |
|---|---|
| 先问我三个问题再开始 | 把缺失信息补上，最有用的一条 |
| 先给三个方向，我选一个你再展开 | 避免一步做错全部重来 |
| 分成三步，每步等我确认 | 长任务可控 |
| 如果你不确定，先列出来问我 | 减少编造 |
⑤ 要求核验
| 指令 | 效果 |
|---|---|
| 标出哪些是推测 | 把事实和猜测分开 |
| 给出你的判断依据 | 方便你反驳 |
| 如果有反例，也列出来 | 避免只找支持性证据 |
| 不确定就说不确定，不要编 | 显著降低幻觉 |
⑥ 约束格式
| 指令 | 效果 |
|---|---|
| 用 Markdown 表格，三列 | 直接能贴进文档 |
| 按「问题—原因—动作」三段写 | 结构固定，便于比对 |
| 输出成 JSON，字段名用英文 | 给程序用 |
| 不要任何开头和总结 | 去掉「好的，我来为你…」 |
03三套能连着跑的流程
单条指令解决小问题，真正省时间的是把几条串起来。下面三套可以直接照抄。
流程一：从零写一篇能发的稿子
流程二：把一个模糊需求变成方案
流程三：审一份已经写好的东西
不加这句，模型会顺手把你满意的部分也一起「优化」掉。这是长文档修改里最常见的返工原因。
04六种基本没用的指令
| 无效指令 | 为什么没用 | 换成 |
|---|---|---|
| 写得专业一点 | 「专业」是评价，不是动作 | 用行业术语，但每个术语后加一句白话解释 |
| 要有创意 | 没有约束的创意等于随机 | 给 10 个方向，其中 3 个必须有反常识角度 |
| 尽量详细 | 详细到什么程度它自己定 | 每个要点展开到 3 句，共 6 个要点 |
| 你懂的 | 它不懂，它只会猜 | 把你以为它懂的那句背景写出来 |
| 做得更好一些 | 不知道「更好」的方向 | 指出具体不足：太笼统 / 缺少数字 / 语气太硬 |
| 不要出错 | 无法执行，也不会降低错误率 | 不确定的内容标注「待核实」 |
05写指令的三条规矩
- 一条指令只说一件事。「写短一点，语气活泼，多用例子，不要用术语」四条挤一句，通常会只执行前两条。
- 用可验证的词。「短」不可验证，「不超过 100 字」可验证。差别在于后者你能检查它对没做到。
- 指令放在任务之后。先说做什么，再说怎么给。顺序反了，模型容易把约束当成任务的一部分。
指令越多不等于越可控。超过六七条之后，模型会开始丢条目，而且丢的往往是你最在意的那条。真需要那么多约束，说明任务该拆成两步。
06怎么积累自己的指令库
别抄清单，抄你自己验证过有效的那几条。做法很简单：每次用完，如果结果明显好于预期，就把那条指令单独记下来，写清它当时解决的什么问题。
三个月后你会有一份十几条的清单，比任何「200 条指令大全」都好用——因为它对应的是你真实踩过的坑。
FAQ常见问题
指令和提示词有什么区别？
提示词描述目标，指令控制过程。实际使用中两者写在同一段话里，区分它们只是为了让你知道哪句话在起什么作用，方便排查失效原因。
指令越多越好吗？
不是。超过六七条之后模型开始丢条目，而且丢的常是你最在意的。需要很多约束时，正确做法是把任务拆成两步，而不是堆指令。
为什么「写得专业一点」没用？
因为它是评价标准，不是可执行动作。模型不知道你心里的「专业」是术语多、还是逻辑严、还是语气稳。换成具体动作，比如「每个术语后加一句白话解释」。
多步流程会不会太麻烦？
前几次麻烦，之后可以直接存成固定模板反复用。而且多步的价值在于错在前面能及时掉头，一步到位做错了要全部重来。
可以让模型先提问吗？
可以，而且这是最容易被低估的一条指令。「先问我三个问题再开始」能补上你忘了交代的背景，成本几乎为零。
指令失效了怎么办？
先看是不是一条指令塞了太多要求，再看是不是用了不可验证的词。这两条能解决大部分情况。剩下的通常是任务本身跨度太大，需要拆。