你一定经历过这种场景：打开 Cursor，输入一段需求，AI 开始刷刷写代码。你满怀期待地等它写完，一看——方向全错。它用了你不想要的框架，改了你不让它动的文件，加了一堆你没要的功能。
三个来回之后，你开始翻阅 Prompt Engineering 的教程。CRISP 框架、GOLDEN Checklist、Chain-of-Thought、Few-Shot Prompting……你认真学了一圈，记了笔记，下次打开编辑器的时候——还是不知道第一句话该怎么写。
问题不在于这些方法论不好——它们每一个都有道理。问题在于：理论太多，能直接用的武器太少。
焚诀要做的事很简单：从一堆方法论中提炼出一个可以直接复制粘贴的模板，作为你跟 AI 沟通的默认起点。
在我们开始之前：
1. 先用你自己的话说说你理解的——我要解决什么问题、交付物是什么。标出你拿不准但自己做了假设的地方。如果你觉得有更好的技术方案，直接说，我来决定。
2. 然后向我提问——每次最多 3 个最关键的问题，直到你对以下三点有 100% 的把握：
- 我真正想要达成的目标是什么（而不是我字面上说的）
- 有哪些我没说出口的约束或偏好（技术栈、性能要求、需要兼容的现有代码、不能动的部分）
- 你计划怎么实现——核心思路是什么、为什么选这个方案
3. 在没有得到我明确的「可以开始」之前，不要写任何代码或修改任何文件。就这些。没有 XML 标签，没有角色扮演指令，没有"你是一个 10 年经验的高级工程师"。一共三条规则，加起来不到 200 字。
场景：给现有项目加一个用户导出功能
裸 Prompt（多数人的写法）：
给我写一个用户数据导出功能，支持 CSV 和 JSON 格式。
AI 大概率会直接开写——不知道你的项目框架，不知道哪些字段是敏感信息，基于假设给你一个"能跑但不一定能用"的实现。
用焚诀模板后，AI 的典型输出：
我的理解：你想在现有的用户管理模块中增加一个导出功能。 我做了以下假设（不确定是否正确）： - 导出的是用户列表，不是单个用户的详情 - 需要过滤掉敏感字段（密码哈希、token 等） - 导出对象是管理员角色，需要权限验证 我的 3 个问题： 1. 导出的字段范围——是导出所有非敏感字段，还是管理员可以自选字段？ 2. 数据量——用户表大概多大？如果超过 10 万行，需要考虑流式导出或异步任务 3. 现有项目用的是什么 ORM 和路由框架？
区别在哪？你在看到任何代码之前，就已经有机会纠正方向偏差。
这六个字是整个模板最重要的一句话。它做了一件事：打断 AI 的默认行为。
所有主流 LLM 都有一个根深蒂固的训练倾向——用户说了需求，就立刻开始执行。「在我们开始之前」等于在对 AI 说：停。别急着写代码。我们先对齐。
第一件：复述需求。让 AI 用自己的话重新说一遍它理解的需求——如果复述和你的意图不一致，你在这一步就能发现，而不是等它写完 500 行代码之后。
第二件：暴露假设。「标出你拿不准但自己做了假设的地方」——让 AI 主动暴露它的不确定性。默认情况下，AI 不会告诉你它在猜，这些隐藏假设就是定时炸弹。
第三件：鼓励替代方案。「如果你觉得有更好的技术方案，直接说，我来决定」——给了 AI 一个许可：你可以不同意我的方案。但「我来决定」——决策权始终在你手里。
「每次最多 3 个」是一个刻意的约束。不设上限，AI 会一口气问你 10 个问题，其中 7 个无关紧要。限制为 3 个，迫使 AI 做优先级排序——只问最关键的。
「我真正想要达成的目标是什么（而不是我字面上说的）」——区分 stated needs 和 actual needs。用户说"帮我写一个定时任务"，真正想解决的可能是"每天凌晨同步一次数据"——AI 可能会告诉你直接用 Bull Queue 的 repeatable job 就行。
「有哪些我没说出口的约束或偏好」——解决反复甩锅问题。让 AI 主动来问约束，而不是你每次都记得提前说清。
「你计划怎么实现——核心思路是什么、为什么选这个方案」——Plan Before Code 原则。修改一个方案比修改一堆代码要便宜得多。
没有这句话，AI 经常会在回答完问题之后"顺手"就开始写代码了。这句话建立了明确的交接协议：代码审查的最高效形式不是事后 Code Review，而是事前 Plan Review。
裸 Prompt「这个函数报错了，帮我修一下」→ AI 在 map 调用前加个 if (data) 判断，表面上消除了报错，但没有追问"为什么 data 会是 undefined"。
用焚诀模板后，AI 的输出变成根因分析：
我的理解：renderUsers 在 data 还未加载完成时就调用了 .map()，但根本原因可能是 useUsers() 的加载状态没有被正确处理。 我的问题： 1. useUsers() 是用什么库实现的？（React Query / SWR / 自定义 hook） 2. 这个组件之前是正常工作的吗？还是最近某次改动后才开始报错？ 3. 你希望在数据加载中时显示什么？
一个 Bug 修复请求，变成了一次根因分析。
裸 Prompt「帮我重构这个文件，代码太乱了」→ AI 大刀阔斧地重写整个文件，改变了函数签名，所有引用都炸了。
用焚诀模板后，AI 先暴露假设：
1. 对齐之后依然翻车 焚诀解决的是方向对齐，不是实现质量。AI 可能方案说得头头是道，但在实现时忘了处理并发、搞错了 API 的调用顺序。模板必须配合测试、Code Review、渐进式验证。
2. AI 问了正确的问题但你给了错误的答案 AI 问你"用户表有多大"，你随口说"不大，几千条"，结果生产环境 50 万条直接超时。垃圾进，垃圾出——这条定律不会因为多了一个模板就失效。
3. 需求本身就是模糊的 模板不能替你想清楚需求。它能做的是让你更早地意识到需求不清晰。
帮我把 src/hooks/useAuth.ts 第 15 行的 data 改名为 userData，同时更新所有引用。
改之前先告诉我会影响哪些文件。核心思想不变：先说清楚再动手。
在模板后追加：
额外要求：
- 给出至少 2 个可选方案，列出各自的优缺点
- 画出数据流图（用 ASCII 或 Mermaid 语法）
- 列出这个方案引入的新依赖，以及每个依赖的维护状态Cursor— 写进 .cursorrules：
## 交互规则
在接到任何编码任务时，先执行以下流程，不要直接写代码：
1. 用自己的话复述你理解的需求和交付物，标出你做了假设的地方
2. 提出最多 3 个关键问题
3. 等待用户明确说「可以开始」后再写代码Claude Code— 写进 CLAUDE.md：
## 交互协议
- 收到编码任务后，不要直接写代码
- 先复述你理解的需求，标出假设
- 提出最多 3 个关键问题
- 等用户说「可以开始」再动手团队协作— 写进 AGENTS.md（跨工具兼容格式）：
## AI 协作协议
本项目中所有 AI 编程助手必须遵守以下交互流程：
1. 收到任务后先复述需求，暴露假设
2. 提出最多 3 个关键问题
3. 等待人工确认后再编写代码
此规则无例外。AI 犯错的三大根源，这个模板都能缓解：
缺上下文：「先用自己的话说说你理解的」——迫使 AI 暴露它缺了什么上下文，你补上
缺约束：「有哪些我没说出口的约束或偏好」——AI 主动来问约束
缺验证：「标出假设」+「不要在可以开始之前写代码」——给了你一个验证窗口
注意用词是"缓解"不是"解决"。模板把你从 60 分拉到 80 分，但从 80 分到 95 分需要的是领域经验和对工具特性的深入理解。
一句话：焚诀模板解决的是「对齐」问题。如果不存在对齐风险，就不需要它。
焚诀模板的本质不是一个 Prompt 技巧，而是一个沟通协议——你和 AI 之间的握手协议。
Google 的 Addy Osmani 区分了 Vibe Coding 和 AI-Assisted Engineering：前者是"让 AI 写，我验收"，后者是"我主导，AI 辅助"。焚诀模板站在后者这边。
AI 不是一个搜索引擎，也不是一个代码生成器。它是一个需要 onboarding 的新同事。焚诀模板就是那个 onboarding 流程——只是压缩到了 200 字以内。
先对齐，再动手。 最好的 Prompt 技巧，就是你不再需要想 Prompt 技巧。
在我们开始之前：
1. 先用你自己的话说说你理解的——我要解决什么问题、交付物是什么。标出你拿不准但自己做了假设的地方。如果你觉得有更好的技术方案，直接说，我来决定。
2. 然后向我提问——每次最多 3 个最关键的问题，直到你对以下三点有 100% 的把握：
- 我真正想要达成的目标是什么（而不是我字面上说的）
- 有哪些我没说出口的约束或偏好（技术栈、性能要求、需要兼容的现有代码、不能动的部分）
- 你计划怎么实现——核心思路是什么、为什么选这个方案
3. 在没有得到我明确的「可以开始」之前，不要写任何代码或修改任何文件。
核心原则：先对齐，再动手。