https://www.cnblogs.com/wmyskxz/p/19754974

---

你一定经历过这种场景：

打开 Cursor，输入一段需求，AI 开始刷刷写代码。你满怀期待地等它写完，一看——方向全错。它用了你不想要的框架，改了你不让它动的文件，加了一堆你没要的功能。你叹口气，删掉重来，重新措辞，再试一次。

三个来回之后，你开始翻阅 Prompt Engineering 的教程。CRISP 框架、GOLDEN Checklist、Chain-of-Thought、Few-Shot Prompting……你认真学了一圈，记了笔记，下次打开编辑器的时候——还是不知道第一句话该怎么写。

问题不在于这些方法论不好——它们每一个都有道理。问题在于：理论太多，能直接用的武器太少。

你知道"要给上下文"，但具体给什么上下文、怎么组织、写在哪里？你知道"要加约束"，但约束太多 AI 会变死板，约束太少它又乱来，边界在哪？你知道"要让 AI 先想再做"，但这句话到底怎么写进 Prompt 里？

焚诀要做的事很简单：从一堆方法论中提炼出一个可以直接复制粘贴的模板，作为你跟 AI 沟通的默认起点。

Cursor、Claude Code、Copilot、ChatGPT、Gemini——无论你用什么工具，贴进去就能用。

下面就是这个模板。

先看完整版。每一行的作用，后面逐句拆解。

就这些。没有 XML 标签，没有角色扮演指令，没有"你是一个 10 年经验的高级工程师"。

一共三条规则，加起来不到 200 字。

你可能会觉得："就这？"

对，就这。但在我解释它为什么有效之前，先给你看一组对比。

场景：给现有项目加一个用户导出功能

裸 Prompt（多数人的写法）：

AI 大概率会直接开写。 它不知道你的项目用什么框架，不知道你的用户表有多大，不知道哪些字段可以导出、哪些是敏感信息。它会基于自己的"常见做法"做一堆假设，然后给你一个"能跑但不一定能用"的实现。运气好的话，方向大致对；运气不好，你需要推翻重来。

用焚诀模板的写法：

AI 的典型输出：

我的理解：
你想在现有的用户管理模块中增加一个导出功能。交付物是一个可以让管理员将用户数据导出为 CSV 或 JSON 文件的接口/页面。

我做了以下假设（不确定是否正确）：

• 导出的是用户列表，不是单个用户的详情
• 需要过滤掉敏感字段（密码哈希、token 等）
• 导出对象是管理员角色，需要权限验证

我的 3 个问题：

1. 导出的字段范围——是导出所有非敏感字段，还是管理员可以自选字段？
2. 数据量——用户表大概多大？如果超过 10 万行，需要考虑流式导出或异步任务
3. 现有项目用的是什么 ORM 和路由框架？我需要兼容你们的代码风格

区别在哪？

第一种写法，AI 直接开始写代码——方向对不对取决于它的假设是否碰巧跟你的需求一致。第二种写法，AI 先理解需求、暴露假设、提出关键问题——你在看到任何代码之前，就已经有机会纠正方向偏差。

需要说清楚的是：这个模板不能保证 AI 最终写出完美的代码。即使走完了"复述-提问-确认"的流程，AI 依然可能在实现阶段犯错——逻辑漏洞、边界条件遗漏、性能问题。模板解决的是方向对齐的问题，不是实现质量的问题。后者需要测试、Code Review 和你自己的工程判断力。

但方向对齐本身的价值是巨大的：在错误的方向上写出完美的代码，不如在正确的方向上写出需要打磨的代码。

打断默认行为：「在我们开始之前」

这六个字是整个模板最重要的一句话。

它做了一件事：打断 AI 的默认行为。

所有主流 LLM 都有一个根深蒂固的训练倾向——用户说了需求，就立刻开始执行。这是 RLHF 训练出来的讨好本能：用户要什么，赶紧给，越快越好，显得我很有用。

但"赶紧给"恰恰是问题的根源。AI 在还没理解你的真实意图时就开始写代码，相当于一个新来的工程师收到 Jira ticket 就开始 coding，连需求文档都没看完。

「在我们开始之前」这六个字，等于在对 AI 说：停。别急着写代码。我们先对齐。

根据 Anthropic 的 Prompt Engineering 最佳实践，让模型"先思考再行动"是提升输出质量最有效的单一策略。这句话就是这个策略的最简实现。

三重保险：「先用你自己的话说说你理解的」

这句话做了三件事，每一件都在解决一个高频问题：

第一件：复述需求。 你让 AI 用自己的话重新说一遍它理解的需求——这是最古老也最有效的沟通技术。在软件工程里，这叫 Rubber Duck Debugging 的变体：不是你对着橡皮鸭解释问题，而是让 AI 对着你解释它理解的问题。如果 AI 的复述和你的意图不一致，你在这一步就能发现，而不是等它写完 500 行代码之后。

第二件：暴露假设。「标出你拿不准但自己做了假设的地方」——这一句的作用是让 AI 主动暴露它的不确定性。默认情况下，AI 不会告诉你它在猜。它会默默做出假设，然后基于这些未经验证的假设写出看起来很完整的代码。这些隐藏假设就是定时炸弹——表面上代码能跑，但建立在错误前提上的逻辑迟早要爆。

Level Up Coding 的一篇分析文章将这种行为称为 Black Box Blindness（黑箱盲信）——你接受了 AI 的输出，但不知道它背后做了什么假设。这句 Prompt 的作用就是把黑箱撬开。

第三件：鼓励替代方案。「如果你觉得有更好的技术方案，直接说，我来决定」——这句话给了 AI 一个许可：你可以不同意我的方案。默认状态下，AI 会尽量按你说的做，即使你的方案不是最优的。这句话打破了这种"唯命是从"的模式，让 AI 敢于提出更好的建议。但注意后半句——「我来决定」——决策权始终在你手里。

核心引擎：「然后向我提问」

这是模板的核心引擎。

「每次最多 3 个」 是一个刻意的约束。不设上限，AI 会一口气问你 10 个问题，其中 7 个无关紧要，你看完就不想回答了。限制为 3 个，迫使 AI 做优先级排序——只问最关键的。这个数字不是随便选的，而是经过反复测试的实践经验：3 个问题足够覆盖核心未知，又不会让对话变成问卷调查。

「我真正想要达成的目标是什么（而不是我字面上说的）」 ——这一句是在教 AI 区分 stated needs 和 actual needs。用户说"帮我写一个定时任务"，真正想解决的可能是"每天凌晨同步一次数据"。如果 AI 只听字面意思，它会从零写一个 cron 调度器；如果 AI 理解了真实目标，它可能会告诉你："你的项目已经用了 Bull Queue，直接加一个 repeatable job 就行，不需要单独写定时任务。"

「有哪些我没说出口的约束或偏好」 ——这句话解决的是 Prompt Thrashing（反复甩锅） 问题。你说"帮我加个缓存"，AI 用了 Redis。你说"不要 Redis"，AI 改成 Memcached。你说"也不要 Memcached"，AI 再改成内存缓存……三个来回浪费了三轮对话，其实你一开始就应该说"用项目里已有的 node-cache 做内存缓存"。但你不会每次都记得提前说清所有约束——这句 Prompt 让 AI 主动来问你。

「你计划怎么实现——核心思路是什么、为什么选这个方案」 ——这是 Plan Before Code 原则的自然语言实现。你不是在要求 AI 写一份正式的技术方案文档，而是让它在动手之前先说清楚"我打算怎么干"。根据 Spec-Driven Development 的实践，这一步能显著降低返工率——因为修改一个方案比修改一堆代码要便宜得多。

硬门禁：「在没有得到我明确的『可以开始』之前，不要写任何代码」

这是一道硬门禁。

没有这句话，AI 经常会在回答完问题之后"顺手"就开始写代码了——"既然我已经理解了需求，那我就直接写了吧。"不行。你还没看它的方案对不对，它就已经动手了。

这句话建立了一个明确的交接协议：AI 负责理解和规划，你负责审批和放行。只有你说了"可以开始"，代码才会产生。

这个设计来自一个很朴素的工程经验：代码审查的最高效形式不是事后 Code Review，而是事前 Plan Review。 在代码已经写完之后做 Review，你面对的是沉没成本——推翻重来的心理阻力很大，很容易变成"差不多得了"。在方案阶段做 Review，推翻成本接近于零。

上面的用户导出功能是一个"新功能开发"的场景。下面再看两个不同类型的场景。

场景一：修 Bug

裸 Prompt：

AI 的常见反应： 在 map 调用前加一个 if (data) 判断，表面上消除了报错，但没有追问"为什么 data 会是 undefined"——真正的 Bug 可能在上游的数据获取逻辑里。

用焚诀模板： 在报错信息和上下文描述后面附上焚诀模板（"出错的函数是 UserList.tsx 的 renderUsers，代码在第 42 行，组件从 useUsers() hook 拿数据"+ 模板原文）。

AI 的典型输出：

我的理解： renderUsers 在 data 还未加载完成时就调用了 .map()，导致 undefined.map() 报错。但根本原因可能不是缺少空值判断——而是 useUsers() 的加载状态没有被正确处理。

我的假设： useUsers() 可能是一个异步 hook（如 React Query 或 SWR），有 isLoading / data / error 三个状态，但组件可能只用了 data 而忽略了 isLoading。

我的问题：

1. useUsers() 是用什么库实现的？（React Query / SWR / 自定义 hook）
2. 这个组件之前是正常工作的吗？还是最近某次改动后才开始报错？（帮助定位是回归 Bug 还是一直存在的问题）
3. 你希望在数据加载中时显示什么？（loading spinner / 骨架屏 / 空状态）

一个 Bug 修复请求，变成了一次根因分析。AI 没有急着贴创可贴，而是先搞清楚伤口在哪。

场景二：重构

裸 Prompt：

AI 的常见反应： 大刀阔斧地重写整个文件，改变了函数签名、引入了新的设计模式、可能还重命名了变量——改完之后所有引用这个文件的地方都炸了。

用焚诀模板： 在重构需求描述后面附上焚诀模板（"我想重构 src/services/payment.ts，目前它有 800 行，职责混在一起了"+ 模板原文）。

AI 的典型输出：

我的理解： 你想把 payment.ts 拆分成更小的模块，让每个模块职责单一。交付物是一组拆分后的文件，对外的 API 保持不变（不破坏调用方）。

我的假设：

• 重构的目标是可维护性，不是性能优化
• 你希望保持现有的函数签名不变，只做内部拆分
• 不引入新的设计模式（如 策略模式、工厂模式），除非你认为有必要

我的问题：

1. 这个文件目前大致有几个职责？（我需要先读文件才能回答，但想确认你心中是否已有初步的拆分方向）
2. 有没有哪些函数是其他模块直接 import 的？（确认公开 API 的边界，重构时保持这些不变）
3. 你是希望一次性完成重构，还是分步进行？（如果是分步，我会先给出拆分计划，每一步确认后再执行）

注意 AI 的第三个假设："不引入新的设计模式"。如果没有模板，AI 在重构时最爱干的事就是把你的代码塞进某个设计模式里——你要的是"拆分文件"，它给你搞了一套"策略模式 + 工厂模式 + 依赖注入"。焚诀模板迫使 AI 先把假设摊开来，让你决定要不要搞那么复杂。

到这里你可能觉得这个模板挺好用。但我必须诚实地说：它不是银弹，有几类情况下它帮不了你。

对齐之后依然翻车

最常见的失败模式：AI 走完了"复述-提问-确认"的全流程，你看了它的方案觉得靠谱，说了"可以开始"——然后它写出的代码依然有问题。

这不是模板的 Bug，而是模板的设计边界。焚诀解决的是方向对齐——确保 AI 理解了你要什么。但"理解了需求"和"写出正确的实现"之间还有一道鸿沟。AI 可能方案说得头头是道，但在实现时忘了处理并发、搞错了 API 的调用顺序、或者用了一个有已知 Bug 的库版本。

所以模板必须配合下游的质量保障手段——测试、Code Review、渐进式验证。它不是终点，是起点。

AI 问了正确的问题但你给了错误的答案

另一个失败模式：AI 问你"用户表有多大？"，你随口说"不大，几千条"。结果上线后发现用户表其实已经有 50 万条了——之前你看的是测试环境。AI 基于你的回答选择了全量查询方案，生产环境直接超时。

模板让 AI 来问你，但你的回答质量决定了最终结果。垃圾进，垃圾出——这条定律不会因为多了一个模板就失效。

需求本身就是模糊的

有时候你自己也不知道想要什么。你说"帮我优化一下这个页面的体验"——AI 问你"具体哪个方面的体验？加载速度、交互流畅度、还是视觉布局？"你想了想，发现自己也说不清。

模板不能替你想清楚需求。它能做的是让你更早地意识到需求不清晰——通过 AI 的追问，你被迫面对自己还没想清楚的部分。这本身是有价值的，但解决方案不在 Prompt 层面，而在需求分析层面。

焚诀模板是"满配版"。在不同场景下，你可以做减法。

简单任务：砍到只剩一句话

如果任务足够简单——比如"把这个变量名从 data 改成 userData"——你不需要完整模板。但即使是简单任务，你也可以保留模板的精神，只用一句话：

核心思想不变：先说清楚再动手。

复杂架构任务：加料

如果任务涉及架构级别的决策——比如"设计一个消息队列系统"或"把单体服务拆成微服务"——可以在模板后面追加：

按工具适配

Cursor： 模板直接粘贴在对话框即可。如果你想让它变成默认行为，写进 .cursorrules 文件：

Claude Code： 写进项目根目录的 CLAUDE.md：

根据 Claude Code 的分层规则系统，写在 CLAUDE.md 里的指令会成为项目级的默认行为——你不需要每次对话都粘贴模板了。

ChatGPT / Gemini / 其他： 直接粘贴在对话开头即可。这些工具没有项目级指令文件的机制，所以需要每次新对话都贴一次。一个变通方案是保存为自定义 GPT 的 System Instructions 或 Gemini Gems 的指令。

团队协作场景

如果你在团队中使用 AI 编程工具，可以把模板固化为团队规范：

AGENTS.md 是一种跨工具兼容的格式，Cursor、Claude Code、Copilot Workspace 等多个工具都能读取。

AI 犯错的原因有很多，但其中最常见的三个，这个模板都能缓解。

缺上下文

AI 不知道你的项目结构、技术栈、代码风格、业务背景。它只能看到你发给它的那几行 Prompt。缺失的上下文 = 它需要猜测的空间 = 猜错的概率。

模板怎么缓解的：「先用你自己的话说说你理解的」 ——迫使 AI 把它理解到的（以及没理解到的）全都暴露出来。你一眼就能看出它缺了什么上下文，补上就行。

缺约束

AI 的输出空间是巨大的。"写一个导出功能"有一万种实现方式，不加约束就是在解空间里随机采样。

模板怎么缓解的：「有哪些我没说出口的约束或偏好」 ——AI 主动来问你约束是什么，而不是你绞尽脑汁去想"我还有什么没说清的"。

缺验证

AI 不会主动告诉你它不确定的地方。它会用自信的语气写出错误的代码。

模板怎么缓解的：「标出你拿不准但自己做了假设的地方」+「在没有得到我明确的『可以开始』之前，不要写任何代码」 ——前者让 AI 主动标注不确定性，后者给了你一个验证窗口。

注意我用的词是"缓解"而不是"解决"。模板提供的是一个更好的沟通起点，不是一个万无一失的保障。上下文可能补了但不够，约束可能问了但漏了，假设可能标了但你没注意看。模板把你从 60 分拉到 80 分，但从 80 分到 95 分需要的是领域经验、精确的上下文和对工具特性的深入理解。

模板不适用的场景

纯探索性对话——你还没有明确的任务，只是想让 AI 帮你调研一个技术方向，或者头脑风暴一些方案。这时候你不需要"先对齐再动手"，你需要的是发散式对话。模板此时反而是束缚。

极短的一次性指令——"帮我格式化这段 JSON"、"这个正则表达式是什么意思"。这类问题的上下文完全自包含，不需要模板介入。

AI 已经充分理解项目上下文时——如果你已经通过 CLAUDE.md / .cursorrules 给了充分的项目上下文，并且在同一个会话中已经完成了多轮对齐，后续的小改动可以直接下指令，不需要每次都走完整流程。

一句话总结：焚诀模板解决的是"对齐"问题。如果不存在对齐风险，就不需要它。

和其他方法论的关系

市面上不缺 Prompt 方法论。焚诀模板和它们的关系不是替代，而是互补：

• CRISP 框架告诉你"要给上下文"，焚诀模板让 AI 自己来要上下文
• GOLDEN Checklist 告诉你"要定义约束"，焚诀模板让 AI 自己来问约束
• Chain-of-Thought 告诉你"让 AI 分步推理"，焚诀模板的第 2 条本质上就是 CoT 的自然语言版
• Few-Shot Prompting 和焚诀模板不冲突，你可以在模板后面追加示例

区别在于：方法论要求你在写 Prompt 之前做功课。焚诀模板把其中一部分功课转移给了 AI。

这不是说方法论没用——当你面对特别复杂或特别关键的任务时，CRISP 的系统化思考、Few-Shot 的示例引导，都能在焚诀模板的基础上进一步提升质量。焚诀是一个好的默认起点，但不是唯一需要的工具。

Vibe Coding 的支持者和反对者一直在吵一个问题："Vibe Coding 到底是不是真正的编程？" Google 的 Addy Osmani 在他广泛传播的文章中给出了一个更精准的区分：Vibe Coding 和 AI-Assisted Engineering 是两件完全不同的事——前者是"让 AI 写，我验收"，后者是"我主导，AI 辅助"。

焚诀模板站在后者这边。它的本质不是一个 Prompt 技巧，而是一个沟通协议——你和 AI 之间的握手协议。它确保双方在动手之前达成共识：需求是什么、约束是什么、方案是什么。

这和你跟人类工程师协作的道理完全一样。你不会对一个新来的同事说"帮我写个导出功能"然后转身就走。你会先确认他理解了需求，回答他的问题，看他的方案再说"可以"。

AI 不是一个搜索引擎，也不是一个代码生成器。它是一个需要 onboarding 的新同事。 焚诀模板就是那个 onboarding 流程——只是压缩到了 200 字以内。

所以，焚诀之后，你要记住的不是这个模板的具体文字——你可以随时查这篇文章复制粘贴。你要记住的是背后那一条原则：

先对齐，再动手。

这条原则在你用 AI 写代码时有效，在你跟人协作时有效，在你自己做任何需要明确方向的事情时，都有效。

最好的 Prompt 技巧，就是你不再需要想 Prompt 技巧。

复制下面的文本，直接粘贴到你的 CLAUDE.md / .cursorrules / AGENTS.md 里。

核心原则：先对齐，再动手。