提示词是调用，而非教学：点准穴位，唤醒模型已有的功力

轩帅 -

你可能低估了自己正在使用的大模型。它读过大量论文、代码和设计文档，训练中也吸收了许多成熟的思维方法：第一性原理、奥卡姆剃刀、二阶思考、事前验尸（Pre-Mortem）……这些能力并不需要你从头教给它。

但为什么同一个模型，有时能给出令人惊艳的方案，有时却会自信地沿着错误的方向一路走到底？为什么你只是让它修改一段代码，它却顺手重构了半个模块；让它分析一个问题，它却急着给出答案，连问题本身是否成立都没有追问？

问题往往不在于模型缺少能力，而在于你没有明确告诉它：这一次应该调用什么能力，以什么方式思考，又以什么标准判断结果。

提示词的价值，正在于此：以极短符号激活大量共享背景知识，将意图、约束与语境压缩于一词之中——试想，“鸿门宴”一词背后究竟蕴含着怎样的文化语用预设？

与其把提示词当成一门需要反复学习的语言，不如把它理解为一组能力调用指令。你不必每次都从零解释什么是第一性原理，只需要在合适的场景下明确要求模型使用它；你也不必满足于模型给出的第一个答案，可以要求它挑战假设、寻找反例、验证结论，直到结果达到预期。

本文整理了一组可以直接用于日常工作、编程、写作、分析与决策的「思维快捷键」，说明它们适合什么场景、解决什么问题，以及使用时需要注意哪些边界。你不需要一次记住全部，只需从当前最常遇到的问题开始，逐步建立自己的提示词工具箱。

一、开工前：先让模型把"猜"的部分问出来

模型最常见的失误，不是不会，而是在你没说清的地方悄悄替你做了决定。

  • "开始之前，向我提最多 3 个你需要猜测的问题。"
    适用：长任务、需求模糊。限制数量是关键，不然它会问个没完。
  • "回答之前，一次问我一个澄清问题，直到你有 95% 的把握理解了我的意图。"
    适用：容易跑偏的任务。"一次一个"让你能边答边想。"95%"不是真实概率，只是让它别急着动手的信号。
  • "Grill me：连续追问，直到目标、约束和取舍都清晰。"
    适用：需求还在脑子里、没成形的阶段。追问的是你的想法，不是任务本身。
  • "先用你自己的话复述我的需求和成功标准，我确认后再动手。"
    适用：改动代价高的任务。复述错了，你一眼就能看出来。

二、问题定义：怀疑"题目本身问错了"

  • "从第一性原理重新分析。"
    适用：现有方案只是路径依赖。比如别顺着"再加一层 Redis"设计，先问接口为什么慢、最小必要方案是什么。
  • "不要沿着现有方案优化，重新问这个问题到底该怎么解。"
    上一条的直接版本，适合模型总在你的方案上"打补丁"的时候。
  • "列出这个方案依赖的所有隐含假设，并逐一挑战。"
    适用：决策建立在大量没验证的前提上。
  • "要让这个方案成立，哪些条件必须为真？"
    适用：把"希望"变成"可检查的前提"。和上一条搭配很好用。
  • "连续问五次为什么，找到根因再给方案。"
    适用：排障、复盘。（5 Whys）
  • "这个需求背后真正要解决的问题是什么？有没有更简单的路径达成同一个目标？"
    适用：对方给的是"方案"而不是"问题"，典型的 XY 问题。

三、Agent 开发与写代码

这是这类提示词最高频的战场。下面几条的共同点是：抑制模型的"过度热心"。

  • "Think Before Coding：先明确陈述你的假设，不确定就问，不要默默选一种理解。"
    适用：编码前。解决的是"做得很漂亮，但做错了东西"。
  • "Simplicity First：用最少的代码解决问题，不加未请求的功能、抽象或灵活性。"
    适用：防止过度工程。
  • "Surgical Changes：只改必须改的部分，不顺手重构相邻代码。"
    适用：控制 diff 范围，让 review 变得可行。
  • "Goal-Driven：先写出可验证的完成标准（或测试），再实现，并循环到通过为止。"
    适用：给 Agent 一个不依赖你的"停止条件"。
  • "这段代码，资深工程师会觉得过度复杂吗？如果会，就简化。"
    适用：自我审查。
  • "用奥卡姆剃刀重新审查：在满足需求的前提下，删掉所有非必要机制。"
    适用：设计里出现 Kafka + Redis + 分布式锁 + 状态机这种组合拳的时候。
  • "按高内聚、低耦合原则审查职责边界，不要为了拆而拆。"
    适用：服务膨胀、模块边界模糊。后半句很重要，否则模型会把一个函数拆成七个文件。
  • "先弄清楚这段代码为什么存在，再决定能不能删。"
    适用：清理遗留代码。（Chesterton's Fence）
  • "排障时，先列出 3 个可能原因，再为每个设计成本最低的验证方法，不要直接改代码。"
    适用：防止 Agent 在错误假设上反复试错。
  • "区分哪些是已验证的事实、哪些是推断、哪些是猜测，分别标注。"
    适用：Agent 汇报结果时，防止它把猜测说成结论。
  • "我来讲我的思路，你当橡皮鸭：只在我逻辑不通或有跳步时打断提问，不要给方案。"
    适用：自己卡住、想理清思路的时候。（Rubber Duck Debugging）

写 Agent 之间的指令、系统提示词、错误信息时，建议配合下一节的 ASD-STE100。

四、写作与表达清晰度

  • "遵循 ASD-STE100。"（或"按 80% 的 ASD-STE100 写"）
    中文说明： ASD-STE100 是航空航天与国防领域的"简化技术英语"规范，最初用于让维修手册无歧义、非母语读者也读得懂。核心要求包括：短句（操作步骤约 20 词以内，说明性文字约 25 词以内）、主动语态、一词一义、不用含糊的同义替换。
    适用：技术说明、操作步骤、错误提示、Agent 间指令、对外文档。
    注意： 它本身是英文规范。写中文时，更准确的说法是"按 ASD-STE100 的精神写中文"：短句、主动语态、同一概念始终用同一个词。
  • "用主动语态、短句、一词一义重写。"
    上一条的轻量版，适合快速清理 AI 味的口水文。
  • "不写引言、总结和奉承，直接给答案。"
    适用：要信息密度的输出。
  • "用编号列表写操作步骤，每步一句，以动词开头。"
    适用：Runbook、部署步骤、故障排查指南。
  • "先给结论，再给支撑论据，论据按重要性排序。"
    适用：给领导或用户的汇报。（金字塔原理）
  • "用 SCQA 组织开头：情境、冲突、问题、答案。"
    适用：文章开头、方案文档的背景段。
  • "假设读者是一个聪明但没有背景的外行，把它讲明白。"
    适用：技术科普、对外文章。（费曼式）
  • "删掉所有删了也不影响意思的词和句子。"
    适用：定稿前最后一遍。

五、方案评审与批判

模型天生倾向于附和你。这一节的提示词，作用是强制它换到对立面。

  • "对这个方案做一次对抗性审查，优先寻找能推翻核心假设的反例。"
    适用：方案评审、Code Review、决策确认。关键词是"反例"，它逼模型找证据，而不是找理由。
  • "不要帮我的方案找理由，想办法证明它是错的。"
    更强硬的版本。
  • "做一次 Pre-Mortem：假设这个项目一年后失败了，倒推最可能的原因。"
    适用：上线前、决策前。
  • "Inversion：列出所有能保证失败的做法，然后避开它们。"
    适用：卡住的时候，或者规划策略时。
  • "先构建对方观点最强的版本（Steel-man），再反驳。"
    适用：避免稻草人式的反驳。
  • "假设你是敌对的审查者，找出所有失败模式。"
    适用：安全性、可靠性审查。
  • "说出什么证据会让你改变这个结论。"
    适用：检验一个判断是不是可证伪。答不出来，说明这个结论可能只是"感觉"。

六、验证与归因

  • "给这些优化设计消融实验，判断真正的收益来自哪里。"
    适用：一次加了多个改动，需要区分哪个有效、哪个只是增加了复杂度。
  • "核心机制必须通过消融实验验证，不能只靠整体指标好看。"
    适用：强调每个设计的贡献都要被证明。
  • "这个结论是相关还是因果？有没有混杂因素？"
    适用：解读数据、A/B 结果。
  • "回答完后，列出你做出的所有可验证的事实性断言，并逐条核对。"
    适用：减少幻觉，尤其是涉及数字、版本号、API 行为的回答。
  • "每个结论标注置信度，并说明依据。"
    适用：需要知道哪些部分可以放心用。
  • "扮演元认知推理专家：分解问题 → 求解 → 验证 → 综合 → 反思，并给出每一步的置信度。"
    适用：需要显式推理路径和自检的复杂问题。

七、产品与决策

  • "做二阶思考：先分析直接后果，再分析后果的后果。"
    适用：决策有连锁反应，比如改定价、改权限模型。
  • "10-10-10：分别从 10 分钟、10 个月、10 年三个尺度评估这个决策。"
    适用：拉开时间视角，避免被眼前情绪带走。
  • "列出机会成本，并与"不行动"的成本对比。"
    适用：判断一件事值不值得做。
  • "先列出关键约束和权衡，再给建议。"
    适用：架构或技术选型。顺序很关键：先摆约束，避免模型直接给"最佳实践"。
  • "这个决定是可逆的还是不可逆的？可逆的就快速决定，不可逆的就充分论证。"
    适用：避免在小事上纠结，也避免在大事上拍脑袋。（单向门 / 双向门）
  • "按 MECE 原则拆解这个问题：各部分相互独立、完全穷尽。"
    适用：拆需求、拆问题、做分类，避免遗漏和重叠。
  • "用 RICE 给这些需求排序，并说明每个分数的依据。"
    适用：需求太多、要排优先级。后半句让它交代依据，你才能挑出不靠谱的打分。
  • "这个功能用户是想'雇佣'它完成什么任务？"
    适用：不确定用户为什么需要它的时候。（Jobs To Be Done）
  • "给出最小可行版本，并明确列出这一版不做什么。"
    适用：砍范围。"不做什么"往往比"做什么"更重要。
  • "倒推：假设产品已经发布，先写发布公告和常见问题，再回头看哪些细节还没想清楚。"
    适用：产品立项阶段。（Working Backwards）
  • "用六顶思考帽分析：事实、情感、批判、乐观、创意、流程。"
    适用：复杂决策、团队讨论。
  • "按 80/20 原则：指出贡献 80% 价值的那 20%。"
    适用：需要聚焦。

八、画图与可视化

Karpathy 推荐过一类很实用的做法：别让模型只用文字解释复杂东西，换一种输出形式。

  • "用 Mermaid 图表示，而不是纯文字。"
    适用：流程、架构、状态机。
  • "画图前，先列出所有节点和它们之间的关系，再画。"
    适用：图一复杂就乱。先结构化，再可视化，出错率会低很多。
  • "用时序图表示这几个角色之间的交互。"
    适用：多服务、多 Agent 之间的调用链。
  • "输出为可交互的 HTML 页面。"
    适用：需要探索、演示、调参的解释。
  • "生成 3Blue1Brown 风格的讲解视频（配合语音）。"
    适用：深度概念，需要直觉层面的讲解。

九、学习与引导式提问

这一类提示词的共同点是：让模型不直接给答案，而是当教练。

  • "用苏格拉底式提问引导我：每次只问一个问题，等我回答后再继续，不要直接给答案。"
    适用：学新概念、理清自己的方案、准备面试或答辩。它通过连续追问暴露你理解里的缺口。
    怎么用得更好：
    • 加一句"除非我说放弃，否则不要揭晓答案"，防止它问两句就忍不住讲课。
    • 也可以反过来用："用苏格拉底式提问检验我的方案"，让它盯着你的假设和论证追问。
    • 想快点出结论时别用，它本来就是慢的。
  • "出题考我，错了再讲解。"
    适用：检验自己是不是真的懂了。
  • "只使用我提供的资料，帮我用 80/20 法则学习【主题】，指出贡献大部分理解的核心概念。"
    适用：学习新领域、知识压缩。
  • "只使用提供的文档，不要补充外部知识。"
    适用：需要严格基于来源的回答。注意：它防的是"编造"，不保证模型理解对。
  • "我来用自己的话讲一遍，你指出讲错或讲漏的地方。"
    适用：费曼学习法。能讲清楚，才算懂。

十、换个视角：发散，再收敛

  • "先给出 3 个方向不同的方案，再比较优劣，最后推荐一个。"
    适用：避免模型一上来就给"唯一答案"。
  • "站在第一次使用的新用户视角，指出哪里会卡住。"
    适用：产品体验、文档、接口设计。
  • "用一个生活中的类比解释这个概念，再说明这个类比在哪里会失效。"
    适用：理解抽象概念。后半句很重要，它防止类比被过度使用。
  • "先说你最不确定的三个地方。"
    适用：拿到一份很自信的回答、想知道该重点核对哪里的时候。

十一、会话延续

长任务一定会跨会话。结束前，让模型写一份交接说明：

  • "写一份 HANDOFF.md：哪些做法有效、哪些无效；做过的决定和取舍；容易踩的坑；下次从哪里开始。"
    规则：没有新东西就跳过；链接文档，不要复制内容。

怎么组合？

单条提示词管一个环节，组合起来才是工作流。比如评审一个设计方案：

从第一性原理重新分析 → 对抗性审查 → 消融实验验证 → 奥卡姆剃刀删除复杂度 → 高内聚低耦合整理边界

写一篇技术文章：

Grill me 澄清读者和目标 → 先给结论的结构 → 按 ASD-STE100 的精神重写 → 删掉所有不影响意思的句子

学一个新领域：

80/20 找核心概念 → 苏格拉底式提问 → 出题考我 → 讲给你听、你来纠错

什么时候别用

  1. 你需要的是具体事实，不是思考方式。 这类提示词不会让模型知道你们公司的内部约定。
  2. 任务很简单。 给一个改变量名的小任务套上 Pre-Mortem，只会得到一堆废话。
  3. 一次叠太多。 同时塞五个框架，模型会各做一点、都不深。先用一条，不够再加。
  4. 对抗类提示词用完要收尾。 "证明我是错的"会让模型倾向于挑错，评审结束后，记得让它再给出"哪些问题真的需要改"。

把提示词变成自己的工作流

真正值得积累的，不是越来越长的提示词清单，而是对「什么问题该调用什么能力」越来越敏锐的判断。

当需求模糊时，先让模型追问；当方案看似合理时，让它挑战假设；当代码越写越复杂时，用奥卡姆剃刀删掉不必要的机制；当结论听起来过于自信时，要求它区分事实、推断与猜测，并核验关键依据。

这些方法不必一次全部启用。先识别问题，再选择方法；先验证效果，再沉淀经验。 每当某条指令确实改善了结果，就把它记录下来，附上适用场景、真实案例和必要的注意事项。经过反复实践，你积累的将不再是一份静态的提示词大全，而是一套适合自己的、能够持续迭代的 AI 工作流。

不过，有一个边界必须始终记住：模型拥有广泛的通用知识，不代表它知道你的具体环境。

团队约定、内部系统、项目架构、业务规则、权限边界，以及那些只存在于你的经验和组织内部的信息，都不能指望模型凭空知道。需要它遵循的规范、依赖的资料、必须满足的约束，仍然要由你主动提供；如果相关信息已经存在于它能够访问的项目文档或工具中，也应明确告诉它去哪里查、以什么为准。

这也是人与模型协作时真正重要的分工：模型负责调用能力、探索方案、分析问题和执行任务；你负责定义目标、提供上下文、设定边界，并验证结果是否符合真实需求。

不要试图把所有知识都写进提示词，也不要期待一句提示词解决所有问题。让模型发挥它已经具备的能力，把它不知道的事情交代清楚，再用验证闭环确保结果可靠。

这才是调用大模型能力的关键：不是让提示词越来越复杂，而是让每一次协作都更加准确、可控，并且可以复用。