值得推荐：Prompt 焚诀——一个模板，终结你和 AI 的所有沟通问题（转载）-VR全景

Prompt 焚诀——一个模板，终结你和 AI 的所有沟通问题

图片[1]-值得推荐：Prompt 焚诀——一个模板，终结你和 AI 的所有沟通问题（转载）-VR全景

原文作者：我没有三颗心脏
原文链接：https://www.cnblogs.com/wmyskxz/p/19754974.html

1|1别学 100 条技巧了

你一定经历过这种场景：

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

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

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

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

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

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

下面就是这个模板。

1|2模板全文

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

在我们开始之前：

1. 先用你自己的话说说你理解的——我要解决什么问题、交付物是什么。标出你拿不准但自己做了假设的地方。如果你觉得有更好的技术方案，直接说，我来决定。

2. 然后向我提问——每次最多 3 个最关键的问题，直到你对以下三点有 100% 的把握：

– 我真正想要达成的目标是什么（而不是我字面上说的）

– 有哪些我没说出口的约束或偏好（技术栈、性能要求、需要兼容的现有代码、不能动的部分）

– 你计划怎么实现——核心思路是什么、为什么选这个方案

3. 在没有得到我明确的「可以开始」之前，不要写任何代码或修改任何文件。

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

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

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

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

1|3一组对比：同一个需求，两种写法

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

裸 Prompt（多数人的写法）：

给我写一个用户数据导出功能，支持 CSV 和 JSON 格式。

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

用焚诀模板的写法：

我要给现有的用户管理模块加一个数据导出功能，支持 CSV 和 JSON 格式。

在我们开始之前：

2. 然后向我提问——每次最多 3 个最关键的问题，直到你对以下三点有 100% 的把握：

– 我真正想要达成的目标是什么（而不是我字面上说的）

– 有哪些我没说出口的约束或偏好（技术栈、性能要求、需要兼容的现有代码、不能动的部分）

– 你计划怎么实现——核心思路是什么、为什么选这个方案

3. 在没有得到我明确的「可以开始」之前，不要写任何代码或修改任何文件。

AI 的典型输出：

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

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

导出的是用户列表，不是单个用户的详情

需要过滤掉敏感字段（密码哈希、token 等）

导出对象是管理员角色，需要权限验证

我的 3 个问题：

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

区别在哪？

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

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

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

1|4逐句拆解：这个模板在对 AI 的大脑做什么

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

在我们开始之前：

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

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

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

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

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

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

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

1. 先用你自己的话说说你理解的——我要解决什么问题、交付物是什么。

标出你拿不准但自己做了假设的地方。

如果你觉得有更好的技术方案，直接说，我来决定。

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

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

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

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

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

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

2. 然后向我提问——每次最多 3 个最关键的问题，直到你对以下三点有 100% 的把握：

– 我真正想要达成的目标是什么（而不是我字面上说的）

– 有哪些我没说出口的约束或偏好

– 你计划怎么实现——核心思路是什么、为什么选这个方案

这是模板的核心引擎。

「每次最多 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 的实践，这一步能显著降低返工率——因为修改一个方案比修改一堆代码要便宜得多。

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

3. 在没有得到我明确的「可以开始」之前，不要写任何代码或修改任何文件。

这是一道硬门禁。

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

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

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

1|5更多场景

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

场景一：修 Bug

裸 Prompt：

这个函数报错了，帮我修一下。

TypeError: Cannot read properties of undefined (reading ‘map’)

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。

我的问题：

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

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

场景二：重构

裸 Prompt：

帮我重构这个文件，代码太乱了。

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

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

AI 的典型输出：

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

我的假设：

重构的目标是可维护性，不是性能优化

你希望保持现有的函数签名不变，只做内部拆分

不引入新的设计模式（如策略模式、工厂模式），除非你认为有必要

我的问题：

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

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

1|6模板失效的时候

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

对齐之后依然翻车

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

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

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

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

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

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

需求本身就是模糊的

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

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

1|7微调指南

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

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

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

帮我把 src/hooks/useAuth.ts 第 15 行的 data 改名为 userData，同时更新所有引用。

改之前先告诉我会影响哪些文件。

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

复杂架构任务：加料

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

额外要求：

– 给出至少 2 个可选方案，列出各自的优缺点

– 画出数据流图（用 ASCII 或 Mermaid 语法）

– 列出这个方案引入的新依赖，以及每个依赖的维护状态

按工具适配

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

# .cursorrules

## 交互规则

在接到任何编码任务时，先执行以下流程，不要直接写代码：

1. 用自己的话复述你理解的需求和交付物，标出你做了假设的地方

2. 提出最多 3 个关键问题

3. 等待用户明确说「可以开始」后再写代码

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

# CLAUDE.md

## 交互协议

– 收到编码任务后，不要直接写代码

– 先复述你理解的需求，标出假设

– 提出最多 3 个关键问题

– 等用户说「可以开始」再动手

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

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

团队协作场景

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

# AGENTS.md（跨工具通用格式）

## AI 协作协议

本项目中所有 AI 编程助手必须遵守以下交互流程：

1. 收到任务后先复述需求，暴露假设

2. 提出最多 3 个关键问题

3. 等待人工确认后再编写代码

此规则无例外。

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

1|8它到底解决了什么问题

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 的示例引导，都能在焚诀模板的基础上进一步提升质量。焚诀是一个好的默认起点，但不是唯一需要的工具。

1|9焚诀的本质

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

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

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

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

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

先对齐，再动手。

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

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

1|10附：Prompt 焚诀速查卡

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

在我们开始之前：

2. 然后向我提问——每次最多 3 个最关键的问题，直到你对以下三点有 100% 的把握：

– 我真正想要达成的目标是什么（而不是我字面上说的）

– 有哪些我没说出口的约束或偏好（技术栈、性能要求、需要兼容的现有代码、不能动的部分）

– 你计划怎么实现——核心思路是什么、为什么选这个方案

3. 在没有得到我明确的「可以开始」之前，不要写任何代码或修改任何文件。

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

__EOF__

本文作者：我没有三颗心脏
本文链接：https://www.cnblogs.com/wmyskxz/p/19754974.html
关于博主：评论和私信会在第一时间回复。或者直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！