china麻豆天美,火影奖励网站V.2.8.7破解版,国产原创精品视频,236宅宅最新俚片,一起草视频在线,freeHD18 麻豆养身,边喂奶边中出的人妻,辽宁老熟女高潮狂叫视频,动漫美女内衣,老司机午夜剧免费,国产传媒无码,毛茸茸BwBwBw,探索新潮风尚,hd国产高清在线视频,《91看片链接》:高清在线,初中男生袜子舒适玩法

別學 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. 然后向我提問——每次最多 3 個最關鍵的問題，直到你對以下三點有 100% 的把握：
   - 我真正想要達成的目標是什么（而不是我字面上說的）
   - 有哪些我沒說出口的約束或偏好（技術棧、性能要求、需要兼容的現有代碼、不能動的部分）
   - 你計劃怎么實現——核心思路是什么、為什么選這個方案
3. 在沒有得到我明確的「可以開始」之前，不要寫任何代碼或修改任何文件。

就這些。沒有 XML 標簽，沒有角色扮演指令，沒有"你是一個 10 年經驗的高級工程師"。

一共三條規則，加起來不到 200 字。

你可能會覺得："就這？"

對，就這。但在我解釋它為什么有效之前，先給你看一組對比。

一組對比：同一個需求，兩種寫法

場景：給現有項目加一個用戶導出功能

裸 Prompt（多數人的寫法）：

給我寫一個用戶數據導出功能，支持 CSV 和 JSON 格式。

AI 大概率會直接開寫。 它不知道你的項目用什么框架，不知道你的用戶表有多大，不知道哪些字段可以導出、哪些是敏感信息。它會基于自己的"常見做法"做一堆假設，然后給你一個"能跑但不一定能用"的實現。運氣好的話，方向大致對；運氣不好，你需要推翻重來。

用焚訣模板的寫法：

我要給現有的用戶管理模塊加一個數據導出功能，支持 CSV 和 JSON 格式。
在我們開始之前：
1. 先用你自己的話說說你理解的——我要解決什么問題、交付物是什么。標出你拿不準但自己做了假設的地方。如果你覺得有更好的技術方案，直接說，我來決定。
2. 然后向我提問——每次最多 3 個最關鍵的問題，直到你對以下三點有 100% 的把握：
   - 我真正想要達成的目標是什么（而不是我字面上說的）
   - 有哪些我沒說出口的約束或偏好（技術棧、性能要求、需要兼容的現有代碼、不能動的部分）
   - 你計劃怎么實現——核心思路是什么、為什么選這個方案
3. 在沒有得到我明確的「可以開始」之前，不要寫任何代碼或修改任何文件。

AI 的典型輸出：

我的理解：
你想在現有的用戶管理模塊中增加一個導出功能。交付物是一個可以讓管理員將用戶數據導出為 CSV 或 JSON 文件的接口/頁面。

我做了以下假設（不確定是否正確）：

• 導出的是用戶列表，不是單個用戶的詳情
• 需要過濾掉敏感字段（密碼哈希、token 等）
• 導出對象是管理員角色，需要權限驗證

我的 3 個問題：

1. 導出的字段范圍——是導出所有非敏感字段，還是管理員可以自選字段？
2. 數據量——用戶表大概多大？如果超過 10 萬行，需要考慮流式導出或異步任務
3. 現有項目用的是什么 ORM 和路由框架？我需要兼容你們的代碼風格

區別在哪？

第一種寫法，AI 直接開始寫代碼——方向對不對取決于它的假設是否碰巧跟你的需求一致。第二種寫法，AI 先理解需求、暴露假設、提出關鍵問題——你在看到任何代碼之前，就已經有機會糾正方向偏差。

需要說清楚的是：這個模板不能保證 AI 最終寫出完美的代碼。即使走完了"復述-提問-確認"的流程，AI 依然可能在實現階段犯錯——邏輯漏洞、邊界條件遺漏、性能問題。模板解決的是方向對齊的問題，不是實現質量的問題。后者需要測試、Code Review 和你自己的工程判斷力。

但方向對齊本身的價值是巨大的：在錯誤的方向上寫出完美的代碼，不如在正確的方向上寫出需要打磨的代碼。

逐句拆解：這個模板在對 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，推翻成本接近于零。

更多場景

上面的用戶導出功能是一個"新功能開發"的場景。下面再看兩個不同類型的場景。

場景一：修 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。

我的問題：

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"——你不需要完整模板。但即使是簡單任務，你也可以保留模板的精神，只用一句話：

幫我把 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 等多個工具都能讀取。

它到底解決了什么問題

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 技巧。

附：Prompt 焚訣速查卡

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

在我們開始之前：
1. 先用你自己的話說說你理解的——我要解決什么問題、交付物是什么。標出你拿不準但自己做了假設的地方。如果你覺得有更好的技術方案，直接說，我來決定。
2. 然后向我提問——每次最多 3 個最關鍵的問題，直到你對以下三點有 100% 的把握：
   - 我真正想要達成的目標是什么（而不是我字面上說的）
   - 有哪些我沒說出口的約束或偏好（技術棧、性能要求、需要兼容的現有代碼、不能動的部分）
   - 你計劃怎么實現——核心思路是什么、為什么選這個方案
3. 在沒有得到我明確的「可以開始」之前，不要寫任何代碼或修改任何文件。

核心原則：先對齊，再動手。