一文搞懂 AI 編程的所有核心術(shù)語

大家好，我是程序員魚皮。

在學(xué)習(xí) Vibe Coding 的過程中，你一定會(huì)遇到各種陌生的名詞和術(shù)語。比如什么是 Token？什么是上下文窗口？什么是 RAG？這些概念聽起來很高大上，但其實(shí)理解起來并不難。

這篇文章就是你的AI 編程術(shù)語詞典，我會(huì)用最通俗易懂的語言，把 Vibe Coding 中最常見、最重要的概念講清楚。墻裂建議收藏，遇到不懂的詞就來查一查。

AI 基礎(chǔ)概念 人工智能（AI）

人工智能（Artificial Intelligence）是讓計(jì)算機(jī)模擬人類智能的技術(shù)。簡(jiǎn)單來說，就是讓機(jī)器能像人一樣思考、學(xué)習(xí)和解決問題。

在 Vibe Coding 中，AI 就是你的編程助手。你只管告訴它要做什么，它就會(huì)嘎嘎幫你做方案、寫代碼、修 Bug。就像你有一個(gè) 24 小時(shí)在線的程序員朋友，隨時(shí)可以幫你干活。

大語言模型（LLM）

大語言模型（Large Language Model）是一種能夠理解和生成人類語言的 AI 系統(tǒng)。ChatGPT、Claude、Gemini、DeepSeek 都是大語言模型。

為什么叫 “大” 模型呢？因?yàn)檫@些模型的參數(shù)量非常龐大，動(dòng)輒幾十億甚至上萬億個(gè)參數(shù)。參數(shù)越多，模型通常越聰明，但也越消耗計(jì)算資源。

你可以把大語言模型理解成一個(gè)讀過海量書籍和代碼的超級(jí)學(xué)霸，它見過無數(shù)的編程案例，所以能幫你寫代碼、解釋代碼、修復(fù) Bug。

除了文本大語言模型之外，AI 領(lǐng)域還有專門處理圖片的視覺模型（比如 Stable Diffusion）、處理語音的音頻模型（比如 Whisper）、以及能同時(shí)處理文字、圖片、音頻的多模態(tài)模型（如 GPT-4o、Gemini）。在 AI 編程時(shí)，我們主要和文本大語言模型打交道。

Token

Token 是 AI 模型處理文本的基本單位。你可以簡(jiǎn)單理解為 “詞塊”。

Token 是你必須掌握的核心概念，因?yàn)?AI 服務(wù)通常按照 Token 收費(fèi)。你輸入的文字和 AI 輸出的文字都會(huì)消耗 Token。Token 用得越多，花的錢就越多。

在英文中，一個(gè) Token 大約是一個(gè)單詞或單詞的一部分。在中文中，一個(gè)漢字通常是 1 ~ 2 個(gè) Token。

舉個(gè)例子來幫助大家理解：

• "Hello World" 大約是 2 個(gè) Token

• “你好世界” 大約是 4 ~ 6 個(gè) Token

目前很多 AI 編程工具（比如 Cursor、Claude Code）都自帶了 Token 消耗量的實(shí)時(shí)統(tǒng)計(jì)和展示，方便你隨時(shí)掌握用量和成本。

輸入 Token 和輸出 Token

AI 服務(wù)在計(jì)費(fèi)時(shí)，一般會(huì)分別計(jì)算輸入和輸出的 Token。

• 輸入 Token：你發(fā)給 AI 的內(nèi)容，比如提示詞、代碼、文件等

• 輸出 Token：AI 返回給你的內(nèi)容，比如回答、生成的代碼、工具調(diào)用指令等

一般來說，輸出 Token 比輸入 Token 更貴。以 Claude Sonnet 4 為例，輸入價(jià)格是 3 美元/百萬 Token，輸出價(jià)格是 15 美元/百萬 Token，貴了 5 倍。這是因?yàn)樯蓛?nèi)容比理解內(nèi)容更消耗算力。

最簡(jiǎn)單的一個(gè)省 Token 小技巧是：用心編寫簡(jiǎn)潔清晰的提示詞，讓 AI 一次就能理解你的需求，減少反復(fù)對(duì)話。更多省 Token 技巧可以看看魚皮分享過的視頻：AI 編程省錢技巧

模型參數(shù)

參數(shù)是模型在訓(xùn)練過程中學(xué)到的 “知識(shí)點(diǎn)”，用數(shù)字的形式存儲(chǔ)在模型中。

舉個(gè)好理解的例子，模型在訓(xùn)練時(shí)讀到了大量 “天空是藍(lán)色的” 這類內(nèi)容，它就會(huì)在參數(shù)中記住 “天空” 和 “藍(lán)色” 之間的關(guān)聯(lián)關(guān)系。參數(shù)越多，模型能記住的知識(shí)和關(guān)聯(lián)就越豐富。

參數(shù)量直接影響模型的能力和使用成本。參數(shù)越多，模型越聰明，但運(yùn)行時(shí)消耗的算力（GPU 計(jì)算資源）也越多，所以價(jià)格也越貴。

目前主流大模型中，明確公開參數(shù)量的有：

• DeepSeek-V3：6710 億參數(shù)（采用 MoE 混合專家架構(gòu)，實(shí)際激活 370 億）

• Qwen3-235B：2350 億參數(shù)（通義千問系列，激活 220 億）

• Llama 4 Scout：1090 億參數(shù)（Meta 開源模型，激活 170 億）

值得一提的是，即使是同一系列的大模型，廠商也會(huì)提供不同參數(shù)量的版本供你選擇。

模型訓(xùn)練和推理

訓(xùn)練（Training）是讓 AI 模型從大量數(shù)據(jù)中學(xué)習(xí)知識(shí)的過程。這個(gè)過程需要海量的計(jì)算資源和時(shí)間，一般由 AI 公司完成。絕大多數(shù)情況下，你不需要自己訓(xùn)練模型，直接用訓(xùn)練好的成品就行。

推理（Inference）是模型訓(xùn)練完成、具備了知識(shí)之后，用學(xué)到的知識(shí)來回答問題、生成內(nèi)容的過程。我們?nèi)粘Ｊ褂?AI 工具，比如和 ChatGPT 對(duì)話、讓 Cursor 寫代碼，本質(zhì)上都是 AI 模型在進(jìn)行推理。

打個(gè)比方，訓(xùn)練就像學(xué)生上學(xué)讀書，推理就像學(xué)生參加考試答題。

模型微調(diào)（Fine-tuning）

微調(diào)是在已有模型的基礎(chǔ)上，用特定領(lǐng)域的數(shù)據(jù)繼續(xù)訓(xùn)練，讓模型在某個(gè)領(lǐng)域表現(xiàn)更好。

比如，你可以用大量的醫(yī)學(xué)資料微調(diào)一個(gè)模型，讓它成為醫(yī)學(xué)專家?；蛘哂媚愎镜拇a庫(kù)微調(diào)，讓它更了解你的項(xiàng)目風(fēng)格。

對(duì)于普通用戶來說，微調(diào)成本較高，一般不需要自己做，直接使用現(xiàn)成的模型就夠了。不過，很多大模型應(yīng)用開發(fā)平臺(tái)（比如阿里云百煉、火山引擎等）都提供了模型微調(diào)的能力，降低了微調(diào)的門檻。

上下文窗口

上下文窗口（Context Window）是指 AI 模型一次能 “記住” 的最大內(nèi)容量，用 Token 來衡量。

不同模型的上下文窗口大小不同：

• GPT-4o：128K Token（約 10 萬中文字）

• Claude Opus 4.6：標(biāo)準(zhǔn) 200K Token，支持?jǐn)U展到 1M Token（約 75 萬中文字）

• Gemini 3.1 Pro：1M Token（約 75 萬中文字），且支持同時(shí)處理文字、圖片、音頻、視頻

上下文窗口越大，AI 能處理的代碼量就越多，能記住的對(duì)話歷史就越長(zhǎng)。如果你的項(xiàng)目代碼很多，或者你不確定 AI 能否在一次對(duì)話中完成任務(wù)，選擇上下文窗口大的模型會(huì)更合適。

但要注意，上下文窗口越大，每次請(qǐng)求消耗的 Token 也越多，成本也會(huì)更高。比如在 Cursor 中使用 Claude Sonnet 模型時(shí)，單次請(qǐng)求超過 20 萬 Token，輸入價(jià)格就會(huì)翻倍。

提示詞相關(guān) 提示詞（Prompt）

提示詞是你給 AI 的指令或問題。在 AI 編程中，提示詞就是你用自然語言描述的需求。

提示詞的質(zhì)量直接決定了 AI 輸出的質(zhì)量。一個(gè)好的提示詞應(yīng)該：

• 具體明確

• 包含必要的背景信息

• 說明期望的輸出格式

比如，“做一個(gè)網(wǎng)站” 是一個(gè)模糊的提示詞，而 “用 React 做一個(gè)記賬網(wǎng)站，包含添加支出、查看列表、統(tǒng)計(jì)總額三個(gè)功能，界面用藍(lán)色調(diào)” 就是一個(gè)更好的提示詞。

在 AI 對(duì)話中，消息一般分為 3 種角色：

• 系統(tǒng)提示詞（System）：設(shè)置 AI 的角色和行為規(guī)則，對(duì)用戶不可見

• 用戶提示詞（User）：你發(fā)送給 AI 的消息

• 助手提示詞（Assistant）：AI 回復(fù)給你的消息

理解這 3 種角色有助于你更好地使用 AI。比如很多 AI 編程工具允許你設(shè)置系統(tǒng)提示詞來定義 AI 的行為規(guī)則，而你在對(duì)話框中發(fā)送的內(nèi)容就是用戶提示詞。

系統(tǒng)提示詞

系統(tǒng)提示詞（System Prompt）是在對(duì)話開始前給 AI 設(shè)置的指令，用來定義 AI 的角色、行為和限制。

比如，你可以設(shè)置系統(tǒng)提示詞：“你是一位資深的 Java 后端開發(fā)專家，請(qǐng)用簡(jiǎn)潔清晰的代碼風(fēng)格回答問題?！?/p>

系統(tǒng)提示詞在整個(gè)對(duì)話過程中都會(huì)生效，是定制 AI 行為的重要方式。

還記得前幾年 AI 剛流行的時(shí)候，市面上冒出了一大堆 AI 助手網(wǎng)站么？其實(shí)很多就是 “套殼”，底層調(diào)用的是同一個(gè)大模型，只不過給不同的 AI 助手設(shè)定了不同的系統(tǒng)提示詞，比如 “你是一個(gè)翻譯專家”、“你是一個(gè)法律顧問” 等。

提示詞工程

提示詞工程（Prompt Engineering）是設(shè)計(jì)和優(yōu)化提示詞的技術(shù)，目的是讓 AI 更好地理解你的意圖，生成更符合預(yù)期的結(jié)果。

這是 Vibe Coding 的核心技能之一。好的提示詞工程師能用更少的對(duì)話輪次、更低的 Token 成本，讓 AI 生成更高質(zhì)量的代碼。

想學(xué)習(xí)編寫提示詞的實(shí)戰(zhàn)技巧，可以看看魚皮的免費(fèi)《AI 編程教程》：提示詞編寫技巧

零樣本提示（Zero-shot）

零樣本提示是指在給 AI 下達(dá)任務(wù)時(shí)，不提供任何示例，直接描述你的需求讓 AI 去完成。

比如：“請(qǐng)把這段英文翻譯成中文?！?/p>

AI 會(huì)根據(jù)自己的訓(xùn)練知識(shí)來完成任務(wù)。

對(duì)于簡(jiǎn)單任務(wù)，零樣本提示一般就夠用了，不需要提供額外的示例內(nèi)容，還能節(jié)約一些 Token 成本。

少樣本提示（Few-shot）

少樣本提示是指在給 AI 下達(dá)任務(wù)時(shí)，額外提供幾個(gè)輸入輸出的示例，讓 AI 通過這些示例學(xué)習(xí)你想要的格式或風(fēng)格，從而更準(zhǔn)確地完成任務(wù)。

比如：

請(qǐng)按以下格式翻譯：
英文：Hello → 中文：你好
英文：Thank you → 中文：謝謝
英文：Good morning → 中文：

通過提供示例，AI 能更準(zhǔn)確地理解你的需求，輸出更一致的結(jié)果。

思維鏈提示（Chain-of-Thought）

思維鏈提示（Chain-of-Thought，簡(jiǎn)稱 CoT）是一種引導(dǎo) AI 展示推理過程、一步一步思考問題的提示技術(shù)，而不是讓 AI 直接給出答案。這對(duì)于復(fù)雜的推理任務(wù)特別有效，比如多步驟的數(shù)學(xué)計(jì)算、代碼邏輯分析、系統(tǒng)架構(gòu)設(shè)計(jì)等。

觸發(fā)思維鏈提示的方法很簡(jiǎn)單。很多推理模型（比如 DeepSeek-R1）和 AI 編程工具天然內(nèi)置了思維鏈能力，會(huì)自動(dòng)展示推理過程。你也可以在提示詞中手動(dòng)加上 “請(qǐng)一步一步思考”，AI 就會(huì)展示它的推理過程，一般能得到更準(zhǔn)確的答案。

在 AI 編程中，涉及復(fù)雜業(yè)務(wù)邏輯、多模塊交互、或者需要權(quán)衡多種技術(shù)方案的項(xiàng)目，特別適合利用推理模型和思維鏈提示能力，讓 AI 想清楚再動(dòng)手。

Markdown 語言

Markdown 是一種輕量級(jí)的文本標(biāo)記語言，用簡(jiǎn)單的符號(hào)來表示格式。比如用#表示標(biāo)題，用**文字**表示加粗，用-表示列表。

在 AI 編程中，Markdown 非常重要，因?yàn)椋?/p>

• AI 生成的回答大多數(shù)都是 Markdown 格式

• 項(xiàng)目文檔（如 README）采用 Markdown 編寫

• 定義 AI 智能體的規(guī)則文件也是 Markdown 格式

學(xué)會(huì) Markdown 能讓你更好地跟 AI 交流，也能寫出更規(guī)范的項(xiàng)目文檔。更重要的是，結(jié)構(gòu)化的內(nèi)容（標(biāo)題層級(jí)、列表、代碼塊等）有助于 AI 更準(zhǔn)確地理解你的意圖，同時(shí)也能培養(yǎng)你自己的結(jié)構(gòu)化思維能力，這對(duì)寫好提示詞非常有幫助。

AI 編程模式 Vibe Coding 氛圍編程

Vibe Coding 是由計(jì)算機(jī)科學(xué)家 Andrej Karpathy 在 2025 年 2 月提出的概念。它描述了一種全新的編程方式：通過自然語言和 AI 對(duì)話，讓 AI 幫你寫代碼，你只需要描述需求、測(cè)試結(jié)果、指導(dǎo)方向。

你不需要精通編程語法，只需要能清楚表達(dá)你的想法，AI 負(fù)責(zé)把你的想法變成可運(yùn)行的代碼。

所以說，Vibe Coding 的重點(diǎn)不是寫代碼，而是明確需求并清晰表達(dá)。你描述得越清楚，AI 給你的結(jié)果就越靠譜。

這就像點(diǎn)外賣一樣，你告訴外賣平臺(tái)你想吃什么，餐廳幫你做好送到手上。你不需要會(huì)做飯，但要知道自己想吃什么。

Agentic Engineering 智能體工程

Agentic Engineering（智能體工程）是 2026 年 2 月由 Andrej Karpathy（也就是提出 Vibe Coding 的那位大佬）提出的新概念，可以理解為 Vibe Coding 的規(guī)范版。

Vibe Coding 就是跟著感覺寫代碼：你給 AI 一句話，AI 吐出代碼，能跑就行，跑不了就把報(bào)錯(cuò)粘回去讓 AI 再改。做個(gè)小工具賊拉快，但項(xiàng)目一大就容易翻車。

而 Agentic Engineering 的思路是：你先想清楚要干嘛、寫好方案、拆好任務(wù)，再把活交給 AI 去執(zhí)行，它干完了你還得驗(yàn)收，質(zhì)量不行再打回去重做。

打個(gè)比方，Vibe Coding 的時(shí)候你是個(gè) DJ，放什么歌全憑感覺；Agentic Engineering 里你是包工頭，流程、質(zhì)量、驗(yàn)收都得你說了算。一個(gè)跟著感覺走，一個(gè)按流程來。

當(dāng)然，不是說 Vibe Coding 已經(jīng)過時(shí)了。Vibe Coding 負(fù)責(zé)讓你看到可能性，Agentic Engineering 負(fù)責(zé)把可能性變成真正能用的東西。二者適用于不同的場(chǎng)景，做小工具時(shí)可以用 Vibe Coding，做企業(yè)級(jí)項(xiàng)目就需要 Agentic Engineering 的思維。

Agentic Coding 智能體編程

Agentic Coding 智能體編程是指讓 AI 像一個(gè)自主的 “智能體”（Agent）一樣工作，能夠自己規(guī)劃任務(wù)、執(zhí)行操作、驗(yàn)證結(jié)果，而不只是被動(dòng)地回答問題。

它和前面提到的 Agentic Engineering 的區(qū)別在于，Agentic Coding 強(qiáng)調(diào)的是 AI 的自主執(zhí)行能力（AI 能干什么），而 Agentic Engineering 強(qiáng)調(diào)的是人對(duì) AI 的管理方法論（人該怎么管）。

如今，幾乎所有主流 AI 編程工具都提供了智能體編程的能力。比如在 Cursor 的 Agent 模式中，AI 可以：

• 自動(dòng)讀取和分析多個(gè)文件

• 規(guī)劃實(shí)現(xiàn)方案

• 執(zhí)行代碼修改

• 運(yùn)行測(cè)試驗(yàn)證

• 自動(dòng)修復(fù)問題

這比傳統(tǒng)的問答式 AI 更強(qiáng)大，因?yàn)樗茏灾魍瓿蓮?fù)雜的多步驟任務(wù)?？梢哉f，AI 不再只是輔助編程的配角，而是正在成為項(xiàng)目開發(fā)的核心驅(qū)動(dòng)力。

多智能體協(xié)作

多智能體協(xié)作（Multi-Agent）是指多個(gè) AI 智能體分工合作，共同完成復(fù)雜任務(wù)。

比如，一個(gè)智能體負(fù)責(zé)設(shè)計(jì)架構(gòu)，一個(gè)負(fù)責(zé)寫前端代碼，一個(gè)負(fù)責(zé)寫后端代碼，一個(gè)負(fù)責(zé)代碼審查。它們像一個(gè)軟件開發(fā)團(tuán)隊(duì)一樣協(xié)作。

這兩年，多智能體系統(tǒng)正在成為 AI 編程的重要趨勢(shì)。它的優(yōu)勢(shì)不僅僅是能處理更復(fù)雜的項(xiàng)目，還能通過并行工作大幅提升效率，讓原本需要幾小時(shí)的任務(wù)在幾分鐘內(nèi)完成。

智能體編排

編排（Orchestration）是指協(xié)調(diào)和管理多個(gè) AI 智能體或 AI 任務(wù)的過程，確保它們按正確的順序和方式工作。

如果說多智能體協(xié)作關(guān)注的是 “有哪些角色參與”，那編排關(guān)注的是 “誰先干、誰后干、結(jié)果怎么匯總”，它是多智能體系統(tǒng)的指揮中樞。

就像樂隊(duì)指揮一樣，編排器決定哪個(gè)智能體在什么時(shí)候做什么事情、如何傳遞信息、如何匯總結(jié)果。

Subagents 子代理

Subagents（子代理）是指主 AI 智能體將部分任務(wù)分派給獨(dú)立的子智能體來并行處理的機(jī)制。

你可以把它理解成 AI 的下屬，就像一個(gè)經(jīng)理把活分給手下的幾個(gè)員工同時(shí)干一樣。當(dāng)主 AI 遇到一個(gè)大任務(wù)時(shí)，它可以把獨(dú)立的小任務(wù)分給幾個(gè)子代理同時(shí)干，自己繼續(xù)處理其他工作。

Subagents 的好處是：

• 并行處理多個(gè)獨(dú)立任務(wù)，效率翻倍

• 主代理的上下文保持干凈，不會(huì)被子任務(wù)的細(xì)節(jié)污染

• 每個(gè)子代理可以專注于自己的任務(wù)，結(jié)果更準(zhǔn)確

比如你可以讓幾個(gè)子代理同時(shí)審查代碼庫(kù)的不同模塊，速度會(huì)快很多。

在 Claude Code 中，AI 會(huì)通過內(nèi)置的 Task 工具自動(dòng)生成子代理來處理子任務(wù)，你不需要做額外配置。你也可以在.claude/agents/目錄下創(chuàng)建自定義的子代理（用 Markdown 文件定義），給它指定專屬的角色描述、工具權(quán)限和行為規(guī)則。

不過子代理也有局限，每個(gè)子代理的上下文是獨(dú)立的，它們之間無法直接共享信息，所以不適合有強(qiáng)依賴關(guān)系的任務(wù)。另外，多個(gè)子代理同時(shí)運(yùn)行會(huì)消耗更多 Token，成本會(huì)相應(yīng)增加。就像公司招人一樣，多招幾個(gè)人確實(shí)能干得更快，但工資支出也得跟著漲，而且人多了溝通協(xié)調(diào)的成本也會(huì)上來。

Agent Teams 智能體團(tuán)隊(duì)

Agent Teams（智能體團(tuán)隊(duì)）是 2026 年興起的多智能體編程新模式，由 Claude Code 率先推出。它讓 3 ~ 5 個(gè)獨(dú)立的 AI 智能體組成團(tuán)隊(duì)，在同一個(gè)項(xiàng)目上并行工作。

和傳統(tǒng)的單 AI 對(duì)話不同，Agent Teams 中有一個(gè) Team Lead（隊(duì)長(zhǎng)）負(fù)責(zé)拆解任務(wù)和協(xié)調(diào)工作，其他 Teammates（隊(duì)員）各自領(lǐng)取任務(wù)獨(dú)立執(zhí)行，還能通過消息系統(tǒng)互相溝通。

打個(gè)比方，以前用 AI 編程就像你一個(gè)人帶一個(gè)實(shí)習(xí)生干活，現(xiàn)在 Agent Teams 相當(dāng)于你直接管了一個(gè)小團(tuán)隊(duì)，前端、后端、測(cè)試同時(shí)干，效率翻了好幾倍。Anthropic 的工程團(tuán)隊(duì)曾用 16 個(gè) Agent 同時(shí)工作，產(chǎn)出了 10 萬行 Rust 代碼！把原本需要數(shù)天的工作壓縮到了幾小時(shí)。

當(dāng)然，代價(jià)就是花費(fèi)的 Tokens 可能會(huì)更多，不是什么時(shí)候都建議使用 Agent Teams。

Background Agent

后臺(tái) Agent（Background Agent）是讓 AI 在后臺(tái)自主運(yùn)行、完成任務(wù)后再通知你結(jié)果的能力。

傳統(tǒng)的 AI 編程需要你盯著屏幕等 AI 一步步做完，電腦還不能關(guān)。而后臺(tái) Agent 允許你把任務(wù)交給 AI 后，就去做別的事情，AI 會(huì)在云端獨(dú)立完成工作，你甚至可以關(guān)掉電腦！

比如讓 AI 在后臺(tái)修復(fù)一批 Bug、跑一輪代碼審查、或者完成一個(gè)完整的功能模塊，做完了會(huì)通知你來驗(yàn)收。

目前 Claude Code、Cursor 等工具都已經(jīng)支持后臺(tái) Agent 能力。以后 AI 編程可能就像發(fā)微信一樣，你在手機(jī)上把需求發(fā)過去，該干嘛干嘛，等 AI 做完了來找你驗(yàn)收就行。

Agent Loop 智能體循環(huán)

Agent Loop（智能體循環(huán)）是 AI 智能體的核心工作機(jī)制，簡(jiǎn)單來說就是 AI 通過不斷重復(fù) “感知-思考-行動(dòng)-觀察” 的循環(huán)來一步步完成任務(wù)。

一個(gè)典型的 Agent Loop 包括：

1. 感知：獲取當(dāng)前環(huán)境信息（讀取文件、查看錯(cuò)誤等）

2. 思考：分析情況，決定下一步行動(dòng)

3. 行動(dòng)：執(zhí)行具體操作（寫代碼、運(yùn)行命令等）

4. 觀察：檢查行動(dòng)的結(jié)果

5. 循環(huán)：根據(jù)結(jié)果決定是否繼續(xù)

這個(gè)循環(huán)會(huì)一直進(jìn)行，直到任務(wù)完成或達(dá)到終止條件。

理解 Agent Loop 能幫你更好地規(guī)劃任務(wù)和管理 AI 的工作過程。需要特別注意的是，AI 編程時(shí) Agent Loop 的循環(huán)次數(shù)不要太多，很多工具都有最大循環(huán)次數(shù)限制，循環(huán)太多不僅效果不好，還會(huì)瘋狂燒 Token！有朋友一覺醒來發(fā)現(xiàn)額度用光了，就是因?yàn)樽?AI 陷入了無限循環(huán)……

ReAct 推理與行動(dòng)

ReAct（Reasoning and Acting）是一種讓 AI 智能體交替進(jìn)行推理和行動(dòng)的技術(shù)范式。它的核心思想很簡(jiǎn)單：讓 AI 先想清楚再動(dòng)手，動(dòng)完手再看看效果，然后繼續(xù)想下一步怎么做。

傳統(tǒng)的 AI 要么只思考不行動(dòng)，要么只行動(dòng)不思考。而 ReAct 讓 AI 能夠：

1. 先推理：思考當(dāng)前情況，制定計(jì)劃

2. 再行動(dòng)：執(zhí)行具體操作

3. 觀察結(jié)果：看看行動(dòng)效果如何

4. 繼續(xù)推理：根據(jù)結(jié)果調(diào)整策略

這種 “思考 - 行動(dòng) - 觀察” 的循環(huán)讓 AI 能更可靠地完成復(fù)雜任務(wù)，是現(xiàn)代 AI 編程工具的核心技術(shù)之一。

深度思考

深度思考（Deep Thinking）是讓 AI 在回答之前先進(jìn)行一段內(nèi)部推理的能力，也叫 “擴(kuò)展思考” 或 “思考模式”。

它和前面提到的思維鏈提示（CoT）有什么區(qū)別呢？

思維鏈提示是一種提示詞技巧，通過提示詞引導(dǎo) AI 展示推理過程；而深度思考是模型內(nèi)置的能力，AI 會(huì)在內(nèi)部自動(dòng)進(jìn)行深度推理，不需要你在提示詞中特別要求。

普通模式下，AI 收到問題后會(huì)直接生成回答。而開啟深度思考后，AI 會(huì)先在內(nèi)部進(jìn)行一系列推理步驟，比如分析問題、考慮多種方案、評(píng)估利弊，然后才輸出最終答案。你有時(shí)能在 AI 的回復(fù)中看到一個(gè) “思考中...” 的過程，那就是深度思考在工作。

深度思考特別適合復(fù)雜的編程任務(wù)，比如設(shè)計(jì)系統(tǒng)架構(gòu)、排查難以定位的 Bug、優(yōu)化算法等。代價(jià)是速度更慢、Token 消耗更多。

目前主流 AI 模型和 AI 編程工具都支持深度思考，并且你可以選擇是否開啟思考模式。

自適應(yīng)思考

自適應(yīng)思考（Adaptive Thinking）是深度思考的智能化版本，讓 AI 自動(dòng)判斷當(dāng)前問題需要多深的思考程度。

以前深度推理模式只能手動(dòng)開關(guān)，開了的話簡(jiǎn)單問題也慢吞吞地想半天、還浪費(fèi)錢，關(guān)了的話復(fù)雜問題又容易出錯(cuò)。

AI 有了自適應(yīng)思考能力后，可以做到簡(jiǎn)單問題秒回，復(fù)雜問題會(huì)自動(dòng)進(jìn)入深度思考模式。這樣既保證了質(zhì)量，又節(jié)省了時(shí)間和成本。

Anthropic 在 Claude Opus 4.6 中率先引入了自適應(yīng)思考能力，開發(fā)者可以設(shè)置不同的思考力度級(jí)別來平衡質(zhì)量和成本。

工具調(diào)用

工具調(diào)用（Tool Use / Function Calling）是讓 AI 能夠使用外部工具和功能的技術(shù)。

AI 本身只能生成文字，但通過工具調(diào)用，它可以讀寫文件、搜索網(wǎng)頁、執(zhí)行命令和腳本、調(diào)用 API、操作數(shù)據(jù)庫(kù)等等。

工具調(diào)用的工作流程分為 4 步：

1. 識(shí)別需求：AI 判斷當(dāng)前任務(wù)需要使用工具

2. 選擇工具：從可用工具中選擇合適的

3. 執(zhí)行調(diào)用：用正確的參數(shù)調(diào)用工具

4. 整合結(jié)果：將工具返回的結(jié)果融入回答，繼續(xù)完成任務(wù)

舉個(gè)例子，用戶想要獲取 編程導(dǎo)航網(wǎng)站 的熱門文章，下面這張圖清晰地展示了工具調(diào)用的完整流程：

需要注意的是，AI 模型本身并不直接執(zhí)行工具，而是生成 “我想調(diào)用這個(gè)工具，參數(shù)是這些” 的指令，由外部系統(tǒng)執(zhí)行后把結(jié)果返回給 AI。

有了工具調(diào)用，AI 就從 “只會(huì)說” 變成了 “能動(dòng)手”。如果沒有工具調(diào)用，AI 只能告訴你該怎么改代碼，你還得自己去復(fù)制粘貼；而有了工具調(diào)用，AI 可以直接幫你讀取文件、修改代碼、運(yùn)行命令，一條龍搞定。比如 Cursor 的 Agent 模式就是通過工具調(diào)用來實(shí)現(xiàn)自主編程的。

MCP 模型上下文協(xié)議

MCP（Model Context Protocol）是 Anthropic 在 2024 年底推出的開放標(biāo)準(zhǔn)，用于讓 AI 模型安全地連接外部數(shù)據(jù)源和工具。

你可以把 MCP 理解成 AI 世界的 “USB 接口”。就像 USB 接口讓各種設(shè)備（鍵盤、鼠標(biāo)、U 盤）都能用同一種方式連接電腦一樣，MCP 讓各種外部工具（文件管理、數(shù)據(jù)庫(kù)、搜索引擎等）都能用同一種方式連接 AI，不用為每個(gè)工具單獨(dú)寫一套對(duì)接代碼。

MCP 的核心價(jià)值在于標(biāo)準(zhǔn)化。開發(fā)者不需要為每個(gè) AI 工具單獨(dú)開發(fā)連接器，只需要按照 MCP 標(biāo)準(zhǔn)開發(fā)一次，就能被所有支持 MCP 的 AI 工具使用。目前 Claude Code、Cursor、Windsurf 等主流 AI 編程工具，以及各種網(wǎng)頁 AI Agent 應(yīng)用都已經(jīng)支持 MCP 協(xié)議。

在 Vibe Coding 中，MCP 讓 AI 能夠連接更多外部工具和數(shù)據(jù)源，大大擴(kuò)展了 AI 的能力邊界。比如通過 Figma MCP，AI 可以直接讀取設(shè)計(jì)稿并生成對(duì)應(yīng)的網(wǎng)頁代碼；通過 GitHub MCP，AI 可以直接操作代碼倉(cāng)庫(kù)、創(chuàng)建 PR；通過數(shù)據(jù)庫(kù) MCP，AI 可以查詢和分析業(yè)務(wù)數(shù)據(jù)。

想要發(fā)現(xiàn)更多好用的 MCP 服務(wù)？可以訪問 魚皮 AI 導(dǎo)航 - MCP 大全，持續(xù)更新優(yōu)質(zhì) MCP，幫你重塑 AI 工作流。

Agent Skills 智能體技能

Agent Skills（智能體技能）是 Anthropic 在 2025 年 10 月推出的 一套開放標(biāo)準(zhǔn)，目的是讓 AI 能夠?qū)W習(xí)使用各種專業(yè)技能，快速擴(kuò)展特定領(lǐng)域的專業(yè)能力。

簡(jiǎn)單來說，Agent Skills 就是給 AI 準(zhǔn)備的技能包。技能包里有精心設(shè)計(jì)的提示詞、代碼腳本、還有各種資源文件。

把 AI 想象成一個(gè)職場(chǎng)小白，給他裝上文檔處理技能，它就立刻知道怎么生成 PPT、處理 Excel 表格；裝上代碼規(guī)范技能，它就知道怎么按照公司標(biāo)準(zhǔn)寫代碼。

Skill 的本質(zhì)是一個(gè)包含SKILL.md文件的文件夾，里面可以放置指令說明、腳本代碼、參考資料等。當(dāng) AI 遇到相關(guān)任務(wù)時(shí)，會(huì)自動(dòng)加載對(duì)應(yīng)的 Skill 來增強(qiáng)自己的能力。

Skills 的核心設(shè)計(jì)是漸進(jìn)式披露，AI 只在需要時(shí)才加載相關(guān)內(nèi)容，不會(huì)一次性把所有信息都塞進(jìn)上下文，既節(jié)省 Token 又保持靈活性。

想要發(fā)現(xiàn)更多好用的 Agent Skills？可以訪問 魚皮 AI 導(dǎo)航 - Skills 大全，持續(xù)更新優(yōu)質(zhì)技能，讓 AI 幫你干更多活。

Hooks 鉤子

Hooks（鉤子）是 AI 編程工具中的一種自動(dòng)化觸發(fā)器。當(dāng) AI 完成某個(gè)動(dòng)作（比如生成代碼、提交代碼、運(yùn)行命令）時(shí)，Hook 會(huì)自動(dòng)執(zhí)行你預(yù)設(shè)的腳本或檢查流程。

各種主流 AI 編程工具都支持 Hooks，比如在 Claude Code 中，Hooks 可以用來：

• 代碼生成后自動(dòng)運(yùn)行格式化工具

• 文件修改后自動(dòng)執(zhí)行測(cè)試

• 權(quán)限請(qǐng)求時(shí)自動(dòng)判斷是否安全并批準(zhǔn)

• 提交代碼前自動(dòng)檢查代碼規(guī)范

Hooks 讓你的 AI 工作流更加自動(dòng)化，減少手動(dòng)操作。但是要注意，Hooks 配置不當(dāng)可能會(huì)阻塞 AI 的正常工作流程，建議先在小范圍測(cè)試，確認(rèn)沒問題再推廣到整個(gè)項(xiàng)目。

斜杠命令

斜杠命令（Slash Commands）是在 AI 編程工具的對(duì)話框中輸入/觸發(fā)的快捷指令，可以快速執(zhí)行常用操作。

你可以把斜杠命令理解成操作 AI 的快捷鍵。Cursor、Claude Code 等主流 AI 編程工具都支持斜杠命令，比如 Claude Code 內(nèi)置了這些常用的斜杠命令：

• /help：查看可用命令

• /compact：壓縮當(dāng)前對(duì)話的上下文

• /config：修改配置

• /skills：查看已安裝的技能

你可以自定義斜杠命令，把常用的工作流封裝起來復(fù)用。比如創(chuàng)建一個(gè)/commit-push-pr命令，一次性完成代碼提交、推送和創(chuàng)建 PR；或者搞個(gè)/techdebt命令，每次會(huì)話結(jié)束跑一下清理重復(fù)代碼。

自定義命令的本質(zhì)其實(shí)就是一個(gè) Markdown 文件，在 Cursor 中，只需要在項(xiàng)目的.cursor/commands/目錄下創(chuàng)建.md文件，里面寫上你想要 AI 執(zhí)行的指令，這個(gè)文件名就會(huì)變成一個(gè)斜杠命令。還可以用 Git 版本控制工具來管理自定義命令的文件，跨項(xiàng)目復(fù)用。

A2A（Agent-to-Agent）

A2A（Agent-to-Agent）是指 AI 智能體之間相互通信和協(xié)作的協(xié)議或方式，是多智能體系統(tǒng)的基礎(chǔ)技術(shù)。

就像人和人之間需要語言來溝通，AI 智能體之間也需要標(biāo)準(zhǔn)化的方式來交換信息、分配任務(wù)、匯報(bào)結(jié)果。

A2A 協(xié)議讓不同的 AI 智能體能夠組成團(tuán)隊(duì)，分工合作完成復(fù)雜任務(wù)。這個(gè)協(xié)議由 Google 在 2025 年推出，目前已有超過 150 家企業(yè)加入支持。

不要把 A2A 和 MCP 搞混！二者是互補(bǔ)關(guān)系，MCP 解決的是 AI 連接工具的問題，A2A 解決的是 AI 之間溝通協(xié)作的問題。

BMAD 敏捷 AI 開發(fā)方法

BMAD-METHOD（Breakthrough Method of Agile AI-Driven Development，突破性敏捷 AI 驅(qū)動(dòng)開發(fā)方法）是一套系統(tǒng)化的 AI 智能體開發(fā)框架，目標(biāo)是將原本混亂的 AI 編程過程變得結(jié)構(gòu)化、可復(fù)用。

BMAD 使用角色化智能體的方式組織開發(fā)流程，每個(gè)智能體扮演特定角色：

• Analyst Agent 分析師：創(chuàng)建項(xiàng)目簡(jiǎn)報(bào)，包含市場(chǎng)分析和用戶畫像

• PM Agent 產(chǎn)品經(jīng)理：將簡(jiǎn)報(bào)轉(zhuǎn)化為詳細(xì)的產(chǎn)品需求文檔（PRD）

• Architect Agent 架構(gòu)師：設(shè)計(jì)技術(shù)實(shí)現(xiàn)方案和系統(tǒng)架構(gòu)

BMAD 中的智能體分為兩種類型：

• Simple Agents 簡(jiǎn)單智能體：?jiǎn)挝募?、自包含，適合代碼審查、文檔生成等聚焦任務(wù)

• Expert Agents 專家智能體：具有跨會(huì)話持久記憶，配有專屬文件夾存放資源，適合復(fù)雜的多步驟工作流

每個(gè)智能體都有標(biāo)準(zhǔn)化的組成部分，包括人設(shè)（角色、身份、溝通風(fēng)格、原則）、能力列表、交互菜單，以及可選的關(guān)鍵行動(dòng)。

BMAD 在 GitHub 上獲得了幾萬+ Star，說明這種結(jié)構(gòu)化的 AI 開發(fā)方法正在被越來越多的開發(fā)者認(rèn)可。

Browser Use 瀏覽器使用

Browser Use（瀏覽器使用）是讓 AI 智能體能夠自主操控網(wǎng)頁瀏覽器的技術(shù)能力。通過 Browser Use，AI 可以像人類一樣瀏覽網(wǎng)頁、點(diǎn)擊按鈕、填寫表單、提取數(shù)據(jù)。

Browser Use 的典型應(yīng)用場(chǎng)景：

• 自動(dòng)化研究：讓 AI 在多個(gè)網(wǎng)站上搜索、整理信息

• 數(shù)據(jù)采集：從網(wǎng)頁中提取結(jié)構(gòu)化數(shù)據(jù)

• 表單填寫：自動(dòng)完成繁瑣的在線表單

• 跨平臺(tái)操作：在不同網(wǎng)站間完成多步驟任務(wù)

比較知名的開源項(xiàng)目是 Browser-Use，支持通過 Python 調(diào)用多種大模型來控制瀏覽器。此外，Cursor、Claude Code 等主流 AI 編程工具也內(nèi)置了 Browser Use 能力，可以在開發(fā)過程中自動(dòng)打開瀏覽器預(yù)覽效果、執(zhí)行測(cè)試等操作。

Browser Use 的一個(gè)關(guān)鍵優(yōu)勢(shì)是，AI 可以利用你現(xiàn)有的瀏覽器會(huì)話和登錄狀態(tài)，無需為每個(gè)網(wǎng)站單獨(dú)開發(fā) API 集成。也就是說，AI 能夠訪問那些沒有公開 API 的網(wǎng)站，大大擴(kuò)展了自動(dòng)化的應(yīng)用范圍。

Computer Use 計(jì)算機(jī)使用

Computer Use（計(jì)算機(jī)使用）是 Anthropic 公司在 2024 年推出的 AI 能力，讓 Claude 大模型能夠像人類一樣操作整個(gè)計(jì)算機(jī)桌面。

和 Browser Use 只能操作瀏覽器不同，Computer Use 可以操作任何桌面應(yīng)用程序，比如：

• 查看屏幕截圖，理解界面元素

• 移動(dòng)鼠標(biāo)光標(biāo)，點(diǎn)擊按鈕

• 使用鍵盤輸入文字

• 執(zhí)行命令行操作

Computer Use 的工作原理是一個(gè)持續(xù)的反饋循環(huán)：

1. 截圖分析：AI 捕獲并分析當(dāng)前屏幕

2. 決策規(guī)劃：根據(jù)任務(wù)目標(biāo)確定下一步操作

3. 執(zhí)行操作：發(fā)送鼠標(biāo)/鍵盤輸入

4. 觀察結(jié)果：檢查操作效果，調(diào)整策略

為了安全起見，Computer Use 一般需要在虛擬機(jī)或容器中運(yùn)行，不會(huì)直接控制你的真實(shí)電腦。

Computer Use 代表了 AI 從 “只能生成文字” 到 “能夠操作軟件” 的重大跨越，徹底改變?nèi)藱C(jī)交互方式。

基于 Computer Use 技術(shù)，Anthropic 在 2026 年推出了 Claude Cowork，這是一個(gè)桌面端 AI 助手，可以直接訪問你電腦上的文件和文件夾，幫你整理下載目錄、從截圖中提取數(shù)據(jù)到表格、準(zhǔn)備品牌報(bào)告等日常辦公任務(wù)。

上下文管理 上下文（Context）

上下文是 AI 在回答問題時(shí)能夠參考的所有信息，包括：

• 當(dāng)前對(duì)話的歷史

• 你打開的代碼文件

• 項(xiàng)目的結(jié)構(gòu)和配置

• 你提供的參考資料

上下文越豐富、越和當(dāng)前任務(wù)相關(guān)，AI 生成的代碼就越符合你的需求。這就像給一個(gè)新同事交接工作，你給的背景信息越多，他上手就越快。

在 Cursor 中，你可以通過對(duì)話框附近的 Token 用量指示器來大致了解當(dāng)前上下文的大??；在 Claude Code 中，可以使用/context命令查看上下文占用情況。

上下文工程

上下文工程（Context Engineering）是有策略地管理和優(yōu)化提供給 AI 的上下文信息的技術(shù)。

核心目標(biāo)是讓 AI 擁有恰到好處的信息。既不能太少（導(dǎo)致 AI 不了解情況），也不能太多（導(dǎo)致信息過載、成本上升）。

好的上下文工程包括：

• 選擇最相關(guān)的文件

• 提供必要的背景說明

• 使用規(guī)則文件定義項(xiàng)目規(guī)范

• 適時(shí)清理無關(guān)的對(duì)話歷史

上下文工程是目前 AI 領(lǐng)域非常熱門的研究方向。2026 年的趨勢(shì)正在從簡(jiǎn)單的上下文管理，演進(jìn)到更復(fù)雜的記憶架構(gòu)—— 讓 AI 擁有短期記憶（當(dāng)前對(duì)話上下文）、長(zhǎng)期記憶（跨會(huì)話的知識(shí)積累）和外部記憶（向量數(shù)據(jù)庫(kù)、知識(shí)圖譜等）。

比如 Claude Opus 4.5 就引入了 Memory Tool，能讓 AI 在超出上下文窗口的情況下，通過文件系統(tǒng)式的持久化存儲(chǔ)來記住重要信息。根據(jù) Anthropic 官方數(shù)據(jù)，這項(xiàng)技術(shù)在長(zhǎng)時(shí)間工作流中減少了 84% 的 Token 消耗！

可以說，誰能更好地解決上下文和記憶的問題，誰就能在 AI 編程領(lǐng)域占據(jù)優(yōu)勢(shì)。

上下文壓縮

上下文壓縮（Context Compaction）是 AI 自動(dòng)壓縮和總結(jié)之前對(duì)話內(nèi)容的技術(shù)，解決的是長(zhǎng)時(shí)間運(yùn)行任務(wù)中上下文溢出的問題。

以前跑長(zhǎng)任務(wù)的時(shí)候，AI 經(jīng)常會(huì)撞到上下文長(zhǎng)度的天花板，前面聊過的內(nèi)容被擠掉后 AI 就失憶了，導(dǎo)致生成的代碼和之前的約定對(duì)不上。有了上下文壓縮，AI 會(huì)在上下文快要滿的時(shí)候，自動(dòng)把前面的對(duì)話總結(jié)成更精簡(jiǎn)的形式，保留關(guān)鍵信息的同時(shí)釋放空間，這樣就能持續(xù)工作更久而不會(huì)失憶。

你可以把它想象成項(xiàng)目經(jīng)理寫會(huì)議紀(jì)要。已經(jīng)開了 3 小時(shí)的會(huì)，不可能把每句話都記下來，但關(guān)鍵決策、待辦事項(xiàng)、重要結(jié)論都會(huì)被記錄。AI 的上下文壓縮也是類似的思路，把冗長(zhǎng)的對(duì)話歷史濃縮成關(guān)鍵信息。

Claude Opus 4.6 已經(jīng)內(nèi)置了上下文壓縮能力，搭配它的 100 萬 token 上下文窗口，可以讓長(zhǎng)時(shí)間運(yùn)行的編程任務(wù)更加穩(wěn)定。

規(guī)則文件

規(guī)則文件（Rules File）是放在項(xiàng)目中的配置文件，用來告訴 AI 你的項(xiàng)目規(guī)范、技術(shù)棧、代碼風(fēng)格等信息。有了規(guī)則文件，AI 每次生成代碼時(shí)都可以參考這些規(guī)則，生成的代碼更符合你的項(xiàng)目風(fēng)格，省去了反復(fù)強(qiáng)調(diào)的麻煩。

不同 AI 編程工具使用不同的規(guī)則文件格式：

• Cursor：早期使用.cursorrules單文件格式，現(xiàn)在推薦使用.cursor/rules/*.mdc多文件格式

• Claude Code：使用CLAUDE.md文件

• GitHub Copilot：使用.github/copilot-instructions.md文件

以 Cursor 為例，.mdc規(guī)則文件支持 YAML 元數(shù)據(jù)（frontmatter），可以指定規(guī)則的適用范圍。根據(jù) Cursor 官方文檔，其格式如下：

---
description: React 組件開發(fā)規(guī)范
globs: src/components/**/*.tsx
alwaysApply: false
---
# React 規(guī)范
- 使用函數(shù)式組件
- 優(yōu)先使用 hooks

規(guī)則文件的激活方式有多種，比如：

• 始終生效：設(shè)置alwaysApply: true

• 模式匹配：當(dāng)引用匹配globs的文件時(shí)自動(dòng)激活

• 手動(dòng)調(diào)用：在對(duì)話中用@規(guī)則名引用

• AI 自主決定：AI 根據(jù)任務(wù)相關(guān)性自動(dòng)加載

注意，隨著工具版本的更新，這些文件的名稱和標(biāo)準(zhǔn)可能會(huì)發(fā)生改變，一切以工具官方文檔為主。

AGENTS.md

AGENTS.md 是一種開放的文件格式，專門用于給 AI 編程智能體提供項(xiàng)目指令。它本質(zhì)上也是一種規(guī)則文件，只不過是跨工具通用的開放標(biāo)準(zhǔn)。

傳統(tǒng)的 README.md 是寫給人看的，主要介紹項(xiàng)目是什么、怎么用。而 AGENTS.md 是寫給 AI 看的，包含 AI 工作時(shí)需要的技術(shù)細(xì)節(jié)：

• 項(xiàng)目的構(gòu)建和啟動(dòng)命令

• 測(cè)試運(yùn)行方式

• 代碼風(fēng)格和規(guī)范

• 項(xiàng)目結(jié)構(gòu)說明

一個(gè)典型的 AGENTS.md 文件大概長(zhǎng)這樣：

# 項(xiàng)目設(shè)置
- 安裝依賴：npm install
- 啟動(dòng)開發(fā)：npm run dev
- 運(yùn)行測(cè)試：npm test


 # 代碼規(guī)范
- 使用 TypeScript 嚴(yán)格模式
- 組件文件使用 PascalCase 命名
- 工具函數(shù)使用 camelCase 命名

AGENTS.md 的優(yōu)勢(shì)在于它是一個(gè)開放標(biāo)準(zhǔn)，被數(shù)萬個(gè)開源項(xiàng)目采用。當(dāng)你使用支持該標(biāo)準(zhǔn)的 AI 編程工具（比如 Claude Code、Codex、Cursor、GitHub Copilot 等）時(shí)，AI 會(huì)自動(dòng)識(shí)別項(xiàng)目根目錄下的 AGENTS.md 文件，并將其中的指令發(fā)送給 AI，不需要你手動(dòng)引用。

SDD 規(guī)范驅(qū)動(dòng)開發(fā)

SDD（Spec-Driven Development，規(guī)范驅(qū)動(dòng)開發(fā)）是 AI 時(shí)代的一種新型開發(fā)方法論，強(qiáng)調(diào)在編碼之前先創(chuàng)建明確的、AI 能直接理解和執(zhí)行的規(guī)范文檔。

傳統(tǒng)開發(fā)流程是：想到什么寫什么，邊寫邊改，最后再補(bǔ)文檔。這樣容易導(dǎo)致需求不清晰、代碼和文檔對(duì)不上。

而 SDD 的思路正好相反：先把需求寫成規(guī)范文檔，并且把規(guī)范文檔當(dāng)作代碼的唯一真相來源。

你可以把規(guī)范文檔理解為 “項(xiàng)目憲法”，它包含了詳細(xì)的需求描述、系統(tǒng)設(shè)計(jì)和接口定義。AI 必須嚴(yán)格遵守這些條文來生成代碼，確保產(chǎn)出完全符合預(yù)期。

為什么 SDD 越來越受重視？

因?yàn)?AI 生成代碼的質(zhì)量直接取決于上下文的清晰度，而不僅僅是依靠提示詞技巧。一個(gè)清晰的規(guī)范文檔能比任何 Prompt 黑魔法更有效地減少錯(cuò)誤。

SDD 的典型工作流程如下：

1. Constitution 制定準(zhǔn)則：定義項(xiàng)目的基本原則、代碼規(guī)范、性能標(biāo)準(zhǔn)

2. Specify 編寫規(guī)范：描述要做什么功能、為什么做、用戶需求是什么

3. Clarify 澄清疑問：讓 AI 提出結(jié)構(gòu)化問題，明確邊界情況和錯(cuò)誤處理

4. Plan 制定方案：確定技術(shù)棧、系統(tǒng)架構(gòu)、數(shù)據(jù)模型、API 接口

5. Tasks 拆解任務(wù)：把計(jì)劃拆解成可執(zhí)行的任務(wù)列表，標(biāo)注依賴關(guān)系和優(yōu)先級(jí)

6. Implement 執(zhí)行實(shí)現(xiàn)：AI 按照任務(wù)列表生成代碼，人類驗(yàn)證

其實(shí)這和程序員在企業(yè)中開發(fā)項(xiàng)目的標(biāo)準(zhǔn)流程非常相似，只不過執(zhí)行者從人變成了 AI。

2025 年 9 月，GitHub 發(fā)布了開源的 Spec Kit 工具包，幫助開發(fā)者在 AI 編程中實(shí)踐 SDD 方法論。它支持 Claude Code、GitHub Copilot 等主流編程工具，通過一套斜杠命令引導(dǎo)你完成上述流程。即使你不是軟件開發(fā)專家，也能在 AI 的引導(dǎo)下輕松地走完規(guī)范的項(xiàng)目開發(fā)流程。

RAG 檢索增強(qiáng)生成

RAG（Retrieval-Augmented Generation 檢索增強(qiáng)生成）是一種讓 AI 能夠先檢索外部知識(shí)庫(kù)、再基于檢索結(jié)果生成回答的技術(shù)，目標(biāo)是讓 AI 的回答更準(zhǔn)確、更有依據(jù)。

普通的 AI 只能依賴訓(xùn)練時(shí)學(xué)到的知識(shí)，而這些知識(shí)可能已經(jīng)過時(shí)了。RAG 能讓 AI 在回答問題時(shí)，先從你的文檔、代碼庫(kù)、知識(shí)庫(kù)中檢索相關(guān)信息，然后基于這些信息生成回答。

這對(duì)于 Vibe Coding 特別有用，因?yàn)?AI 可以參考你項(xiàng)目中的已有代碼，生成風(fēng)格一致的新代碼。

RAG 檢索增強(qiáng)生成的工作流程如下圖所示，做 AI 應(yīng)用開發(fā)的程序員朋友們可以深入了解一下：

向量數(shù)據(jù)庫(kù)

向量數(shù)據(jù)庫(kù)是專門用來存儲(chǔ)和查詢 “向量”（一種數(shù)字表示形式）的數(shù)據(jù)庫(kù)。在 AI 領(lǐng)域，它常用來存儲(chǔ)文本的語義表示。

什么是向量呢？

簡(jiǎn)單來說，向量就是一串?dāng)?shù)字組成的數(shù)組，比如[0.1, 0.5, 0.3, 0.8]。每個(gè)數(shù)字代表一個(gè)特征維度。AI 可以把一段文字、一張圖片、一段代碼轉(zhuǎn)換成這樣的向量，語義相似的內(nèi)容轉(zhuǎn)出來的向量也會(huì)很接近。

當(dāng)你把代碼或文檔存入向量數(shù)據(jù)庫(kù)后，AI 就能快速找到語義相似的內(nèi)容，即使搜索詞和原文不完全一樣。

比如，你搜 “用戶登錄”，它能找到叫 "handleAuth" 的函數(shù)，因?yàn)樗鼈冊(cè)谡Z義上是相關(guān)的。

隨著 AI 的爆發(fā)，市面上涌現(xiàn)了非常多支持向量存儲(chǔ)的數(shù)據(jù)庫(kù)：

嵌入 Embedding

嵌入是把文本、代碼等內(nèi)容轉(zhuǎn)換成數(shù)字向量的過程。這些向量能夠捕捉內(nèi)容的語義信息。

在向量空間中，語義相似的內(nèi)容會(huì)靠得更近。這就是為什么向量數(shù)據(jù)庫(kù)能進(jìn)行語義搜索的原理。

你不需要深入理解嵌入的技術(shù)細(xì)節(jié)，只需要知道它是 RAG 和代碼語義搜索的基礎(chǔ)技術(shù)就好。

AI 輸出相關(guān) AI 幻覺

AI 幻覺（Hallucination）是指 AI 輸出了不符合事實(shí)的內(nèi)容，可能是編造了不存在的 API、給出了錯(cuò)誤的函數(shù)用法、推薦了根本不存在的庫(kù)，甚至胡編亂造一些看起來很合理但完全錯(cuò)誤的信息。

比如下面這段對(duì)話，我讓 AI 介紹一下程序員魚皮，結(jié)果它一本正經(jīng)地胡說八道，我的本名可不是這個(gè)……

這是大語言模型的固有問題，因?yàn)樗鼈兪腔诟怕噬蓛?nèi)容的，有時(shí)會(huì) “腦補(bǔ)” 不存在的東西。

在 AI 編程時(shí)，我們可以通過以下方法盡量減少幻覺帶來的影響：

• 要求 AI 提供文檔鏈接驗(yàn)證

• 自己查官方文檔確認(rèn)

• 換個(gè)模型試試

• 開新對(duì)話重新描述問題

• 利用 Context7 等獲取到最新技術(shù)文檔的 MCP 擴(kuò)展

對(duì)于做 AI 應(yīng)用開發(fā)的程序員來說，如何消除幻覺是一個(gè)需要重點(diǎn)攻克的挑戰(zhàn)。前面提到的 RAG（檢索增強(qiáng)生成）技術(shù)就是目前最主流的解決方案之一，通過讓 AI 先檢索真實(shí)數(shù)據(jù)再回答，大幅降低幻覺的概率。

溫度

溫度（Temperature）是控制 AI 輸出隨機(jī)性的參數(shù)，取值一般在 0 ~ 2 之間（不同大模型和 AI 編程工具的設(shè)置范圍可能會(huì)有區(qū)別）。

• 溫度低（如 0.1）：輸出更確定、更保守，適合寫代碼

• 溫度高（如 1.0）：輸出更隨機(jī)、更有創(chuàng)意，適合頭腦風(fēng)暴

在編程場(chǎng)景中，一般使用較低的溫度，讓 AI 生成更穩(wěn)定、更可預(yù)測(cè)的代碼。而在需要 AI 發(fā)揮創(chuàng)意的場(chǎng)景（比如起名字、寫文案、頭腦風(fēng)暴產(chǎn)品方案），可以適當(dāng)調(diào)高溫度，讓 AI 給出更多樣化的建議。

比如下圖，我把溫度調(diào)高，輸出的結(jié)構(gòu)可能完全不同：

流式輸出

流式輸出（Streaming）是指 AI 一邊生成內(nèi)容，一邊實(shí)時(shí)顯示給用戶，而不是等全部生成完再顯示。

這就像看直播而不是看錄播，你能實(shí)時(shí)看到 AI 的輸出過程和生成的內(nèi)容，如果發(fā)現(xiàn)方向不對(duì)，可以及時(shí)中斷，避免浪費(fèi) Token。

大多數(shù) AI 編程工具都支持流式輸出，讓交互體驗(yàn)更流暢。

在技術(shù)實(shí)現(xiàn)上，流式輸出一般基于 SSE（Server-Sent Events，服務(wù)器推送事件）技術(shù)，服務(wù)端通過持續(xù)推送數(shù)據(jù)片段給客戶端，做到實(shí)時(shí)展示。

開發(fā)工具概念 IDE 集成開發(fā)環(huán)境

IDE（Integrated Development Environment 集成開發(fā)環(huán)境）是程序員用來寫代碼的綜合軟件，一般包含代碼編輯器、調(diào)試器、終端、插件擴(kuò)展市場(chǎng)等。

VS Code 是目前最流行的輕量級(jí) IDE，由微軟開發(fā)并開源。Cursor 和 Windsurf 都是基于 VS Code 開發(fā)的 AI 代碼編輯器，繼承了 VS Code 的界面風(fēng)格和功能，同時(shí)大幅擴(kuò)展了 AI 能力。

代碼編輯器

代碼編輯器是用來編寫和修改代碼的工具，提供語法高亮、代碼補(bǔ)全、錯(cuò)誤提示等功能，幫助你更高效地寫代碼。

常見的代碼編輯器有 Sublime Text、Vim 等。區(qū)別于 IDE 集成開發(fā)環(huán)境，它們相對(duì)輕量、啟動(dòng)快速，適合快速編輯單個(gè)文件；而 IDE 的功能更全面，集成了調(diào)試器、終端、版本控制等工具，適合專業(yè)開發(fā)者和大型項(xiàng)目開發(fā)。

在 Vibe Coding 時(shí)代，代碼編輯器集成了 AI 能力，可以根據(jù)你的提示詞自動(dòng)生成代碼、解釋代碼、修復(fù)錯(cuò)誤。比如早期的 Cursor 雖然功能強(qiáng)大，但它的核心還是一個(gè) AI 增強(qiáng)的代碼編輯器。

零代碼平臺(tái)

零代碼平臺(tái)（No-Code Platform）是不需要寫代碼就能創(chuàng)建應(yīng)用的平臺(tái)。與之相近的還有低代碼平臺(tái)（Low-Code Platform），它允許通過少量代碼加上可視化拖拽來構(gòu)建應(yīng)用，自由度更高一些。

在 AI 時(shí)代，像 Bolt.new、Lovable、v0.dev、百度秒噠這樣的平臺(tái)結(jié)合了零代碼和 AI，你可以用自然語言描述需求，平臺(tái)自動(dòng)生成完整可在線訪問的應(yīng)用。

零代碼平臺(tái)特別適合完全沒有編程經(jīng)驗(yàn)的新手，或者想快速做原型的場(chǎng)景。不過缺點(diǎn)也很明顯，出了問題不好調(diào)試，也很難深度定制，項(xiàng)目做大了容易遇到瓶頸。

代碼補(bǔ)全

代碼補(bǔ)全（Code Completion）是指 AI 根據(jù)你當(dāng)前的代碼上下文，自動(dòng)預(yù)測(cè)你接下來要寫的內(nèi)容并提供建議。

當(dāng)你寫代碼時(shí)，AI 會(huì)根據(jù)上下文推測(cè)你的意圖，提供代碼片段供你選擇。按下 Tab 鍵就能接受建議，大大提高編碼速度。

早在 2021 年，GitHub 就推出了 Copilot，開創(chuàng)了 AI 代碼補(bǔ)全的先河。但誰也沒想到，短短幾年后 AI 已經(jīng)從 “補(bǔ)全幾行代碼” 進(jìn)化到了 “自主開發(fā)整個(gè)項(xiàng)目”。如今各大 AI 編程工具都支持代碼補(bǔ)全，但越來越多的開發(fā)者已經(jīng)不滿足于逐行補(bǔ)全了，而是直接用 Agent 模式讓 AI 一口氣寫完整個(gè)功能。

代碼審查

代碼審查（Code Review）是檢查代碼質(zhì)量、發(fā)現(xiàn)問題、提出改進(jìn)建議的過程。

沒有代碼審查的項(xiàng)目，Bug 往往要等到上線之后才被發(fā)現(xiàn)，修復(fù)成本很高。而有了代碼審查，很多問題在代碼合并之前就能被提前發(fā)現(xiàn)和修復(fù)。

在傳統(tǒng)開發(fā)中，代碼審查一般由同事或上級(jí)來做。在 Vibe Coding 中，你可以讓 AI 幫你審查代碼，它會(huì)指出潛在的 bug、安全問題、性能問題，并提供修改建議。

但要注意，AI 的審查不能完全替代人工審查！特別是對(duì)于重要的生產(chǎn)代碼。

Linter 代碼檢查器

Linter 是自動(dòng)檢查代碼問題的工具，能發(fā)現(xiàn)語法錯(cuò)誤、風(fēng)格問題、潛在 bug 等。

常見的 Linter 有前端的 ESLint、Python 的 Pylint、Go 的 golint 等，它們像一個(gè)嚴(yán)格的語法老師，幫你保持代碼規(guī)范。

在 Vibe Coding 中，Linter 能幫你快速發(fā)現(xiàn) AI 生成代碼中的問題。而且很多時(shí)候，AI 在幫你創(chuàng)建前端項(xiàng)目時(shí)會(huì)自動(dòng)整合 ESLint 等 Linter 工具，省去了你手動(dòng)配置的麻煩。

Debug 調(diào)試

調(diào)試（Debug）是找到并修復(fù)代碼中錯(cuò)誤的過程。當(dāng)代碼運(yùn)行結(jié)果不符合預(yù)期時(shí)，你需要調(diào)試來定位問題。

調(diào)試的常用方法包括：

• 設(shè)置斷點(diǎn)，逐步執(zhí)行代碼

• 查看變量的值

• 閱讀錯(cuò)誤信息和堆棧跟蹤

• 添加日志輸出

在 AI 編程時(shí)，你可以直接把錯(cuò)誤信息發(fā)給 AI，讓它幫你分析原因并提供修復(fù)方案，甚至是自主修復(fù)。

項(xiàng)目管理概念 MVP 最小可行產(chǎn)品

MVP（Minimum Viable Product 最小可行產(chǎn)品）是指用最少的功能滿足核心需求的產(chǎn)品版本，簡(jiǎn)單來說就是一個(gè) “能跑起來、核心功能能用” 的最簡(jiǎn)版本。

很多同學(xué)剛開始做產(chǎn)品的時(shí)候會(huì)有各種奇思妙想，恨不得一口氣把所有功能都做出來，結(jié)果花了大量時(shí)間在不必要的功能上，越做越復(fù)雜，最后覺得太難就直接放棄了，屬于是自己把自己嚇跑了。而做 MVP 的思路正好相反，先用最少的功能把核心價(jià)值跑通，快速驗(yàn)證想法是否可行，拿到用戶反饋后再逐步迭代。

比如做一個(gè)記賬 APP，MVP 版本可能只有記錄支出、查看列表兩個(gè)功能，其他高級(jí)功能以后再加。

迭代開發(fā)

迭代開發(fā)是把大項(xiàng)目分成多個(gè)小周期，每個(gè)周期完成一部分功能的開發(fā)方法。

每個(gè)迭代周期包括：計(jì)劃 => 開發(fā) => 測(cè)試 => 發(fā)布 => 反饋 => 改進(jìn)。

這種方法特別適合 Vibe Coding，因?yàn)槟憧梢宰?AI 先實(shí)現(xiàn)核心功能，測(cè)試沒問題后再逐步添加新功能。

順便提一下，迭代開發(fā)是敏捷開發(fā)（Agile Development）方法論的核心實(shí)踐之一。敏捷開發(fā)強(qiáng)調(diào)小步快跑、快速反饋、擁抱變化，非常適合 AI 編程的工作節(jié)奏。

重構(gòu)

重構(gòu)（Refactoring）是在不改變功能的前提下，改進(jìn)代碼結(jié)構(gòu)和質(zhì)量的過程。

重構(gòu)的目的是讓代碼更清晰、更易維護(hù)、更高效。常見的重構(gòu)包括：

• 提取重復(fù)代碼為函數(shù)

• 改進(jìn)變量和函數(shù)命名

• 簡(jiǎn)化復(fù)雜的邏輯

• 拆分過長(zhǎng)的文件

在 Vibe Coding 中，你可以讓 AI 幫你重構(gòu)代碼，但要小步進(jìn)行，每次重構(gòu)后都要測(cè)試。

注意，如果你只是用 AI 快速做個(gè)小工具，代碼能跑就行，沒必要花時(shí)間重構(gòu)。但如果是長(zhǎng)期維護(hù)的企業(yè)級(jí)項(xiàng)目，代碼質(zhì)量直接決定了后續(xù)迭代的效率和穩(wěn)定性，定期重構(gòu)就非常有必要了。

技術(shù)債

技術(shù)債（Technical Debt）是為了快速完成功能而采用的臨時(shí)方案，這些方案在未來需要花時(shí)間修復(fù)和改進(jìn)。

就像信用卡欠款一樣，雖然現(xiàn)在透支方便，但遲早要還，還要加利息。

在 Vibe Coding 中，AI 生成的代碼可能不是最優(yōu)方案，積累太多技術(shù)債會(huì)讓項(xiàng)目越來越難維護(hù)。定期重構(gòu)是償還技術(shù)債的有效方法，防止出現(xiàn)屎山代碼。

版本控制

版本控制是記錄代碼變更歷史的系統(tǒng)，讓你能追蹤每次修改、對(duì)比不同版本、回退到之前的狀態(tài)。

Git 是最流行的版本控制工具，注意別把它和 GitHub 搞混了，Git 是在你電腦上運(yùn)行的工具，GitHub 是在線的代碼托管平臺(tái)，用來存放和分享你用 Git 管理的代碼。

在 Vibe Coding 中，版本控制特別重要。因?yàn)?AI 可能會(huì)生成有問題的代碼，有了版本控制，你隨時(shí)可以回退到之前正常的版本。

部署

部署（Deployment）是指把開發(fā)好的應(yīng)用發(fā)布到服務(wù)器上，讓用戶能夠訪問并使用。

最原始的部署方式是自己登錄服務(wù)器，把代碼文件打包上傳后手動(dòng)運(yùn)行，又麻煩又容易出錯(cuò)。好在現(xiàn)在有很多自動(dòng)化的部署平臺(tái)，傻瓜式操作，點(diǎn)幾下就能部署項(xiàng)目，常用的有：

• Vercel：適合前端和全棧應(yīng)用

• Netlify：適合靜態(tài)網(wǎng)站和前端應(yīng)用

• Railway、Render：適合后端服務(wù)

很多零代碼平臺(tái)（如 Bolt.new）都支持一鍵部署，點(diǎn)個(gè)按鈕就能上線。

此外，還可以利用 MCP 來實(shí)現(xiàn)更智能的部署。比如通過 EdgeOne Pages MCP，你只需要跟 AI 對(duì)話，AI 就能幫你自動(dòng)完成網(wǎng)站的打包和部署，連部署平臺(tái)都不用自己登錄~

前后端概念 前端

前端（Frontend）是用戶能直接看到和交互的部分，包括網(wǎng)頁界面、按鈕、表單、動(dòng)畫等。說得粗暴一點(diǎn)，你在瀏覽器里看到的一切，都是前端！

前端技術(shù)棧通常包括：

• HTML：頁面結(jié)構(gòu)

• CSS：樣式和布局

• JavaScript：交互邏輯

• React/Vue/Next.js：現(xiàn)代前端框架

在 Vibe Coding 中，前端是 AI 最擅長(zhǎng)生成的部分，因?yàn)樾Ч梢灾苯涌吹剑奖泸?yàn)證和調(diào)整。你還可以利用 Agent Skills 和精心編寫的提示詞來美化 AI 生成的前端頁面，去掉那股子 AI 味兒。具體技巧可以看魚皮的視頻：如何去除網(wǎng)站的 AI 味兒

后端

后端（Backend）是用戶看不到的部分，負(fù)責(zé)處理業(yè)務(wù)邏輯、數(shù)據(jù)存儲(chǔ)、用戶認(rèn)證等。

比如你在電商網(wǎng)站上點(diǎn)擊 “下單” 按鈕，前端把你的訂單信息發(fā)給后端，后端負(fù)責(zé)校驗(yàn)庫(kù)存、計(jì)算價(jià)格、扣款、生成訂單，然后把結(jié)果返回給前端展示。

后端技術(shù)棧通常包括：

• Node.js/Python/Java：編程語言

• Express/FastAPI/Spring：Web 框架

• MySQL/PostgreSQL/MongoDB：數(shù)據(jù)庫(kù)

后端比前端更復(fù)雜，需要考慮安全性、性能、數(shù)據(jù)一致性等問題。因此 AI 生成的后端代碼需要更仔細(xì)地審查。

全棧

全棧（Full-stack）是指同時(shí)包含前端和后端的完整應(yīng)用。全棧開發(fā)者是能同時(shí)處理前端和后端工作的程序員。

在 Vibe Coding 中，像 Cursor、Bolt.new 這樣的 AI 編程工具可以一次性生成全棧應(yīng)用，前后端代碼都幫你寫好。

想進(jìn)一步了解全棧程序員是什么、怎么成為全棧程序員？可以看魚皮的這篇文章：全棧程序員是什么？

API

API（Application Programming Interface）是不同程序之間通信的接口。

你可以把 API 理解成餐廳的菜單。菜單告訴你有什么菜可以點(diǎn)，怎么點(diǎn)，點(diǎn)了之后會(huì)得到什么。你不需要知道廚房怎么做菜，只需要按菜單點(diǎn)餐。

在 Web 開發(fā)中，前端通過 API 和后端通信，獲取數(shù)據(jù)或提交操作。

想進(jìn)一步了解 API 接口和標(biāo)準(zhǔn)的 API 接口設(shè)計(jì)規(guī)范，可以觀看 魚皮的 API 動(dòng)畫科普視頻。

數(shù)據(jù)庫(kù)

數(shù)據(jù)庫(kù)是存儲(chǔ)和管理數(shù)據(jù)的系統(tǒng)。應(yīng)用中的用戶信息、內(nèi)容、設(shè)置等都存在數(shù)據(jù)庫(kù)里。

常見的數(shù)據(jù)庫(kù)類型有：

• 關(guān)系型數(shù)據(jù)庫(kù)（MySQL、PostgreSQL）：數(shù)據(jù)以表格形式存儲(chǔ)

• 文檔數(shù)據(jù)庫(kù)（MongoDB）：數(shù)據(jù)以 JSON 文檔形式存儲(chǔ)

• 鍵值數(shù)據(jù)庫(kù)（Redis）：適合緩存和快速查找

在 Vibe Coding 中，你可以用 Supabase、Firebase 等現(xiàn)成的云數(shù)據(jù)庫(kù)服務(wù)，不用自己搭建和管理數(shù)據(jù)庫(kù)。

如果你想系統(tǒng)學(xué)習(xí)數(shù)據(jù)庫(kù)知識(shí)，可以看魚皮的數(shù)據(jù)庫(kù)入門教程：數(shù)據(jù)庫(kù)入門教程

BaaS 后端即服務(wù)

BaaS（Backend as a Service 后端即服務(wù)）是提供現(xiàn)成后端功能的云服務(wù)，包括數(shù)據(jù)庫(kù)、用戶認(rèn)證、文件存儲(chǔ)等。

以前沒有 BaaS 的時(shí)候，你得自己買服務(wù)器、裝數(shù)據(jù)庫(kù)、寫后端接口、處理各種運(yùn)維問題，光是搭環(huán)境就得折騰好久。而現(xiàn)在使用 BaaS，這些都是現(xiàn)成的，你不需要自己寫后端代碼和管理服務(wù)器，注冊(cè)個(gè)賬號(hào)就能直接用，能大大加快開發(fā)速度，特別適合 Vibe Coding 的場(chǎng)景。

常用的 BaaS 服務(wù)有：

• Supabase：開源的 Firebase 替代品

• Firebase：Google 的 BaaS 平臺(tái)

• PlanetScale：托管的 MySQL 服務(wù)

這篇文章涵蓋了 Vibe Coding 中最常見的概念和術(shù)語。當(dāng)然，AI 和編程領(lǐng)域的新概念還在不斷涌現(xiàn)，這份詞典也會(huì)持續(xù)更新。

你不需要一次記住所有概念，遇到不懂的詞，回來查一查、或者問一問 AI 就好。隨著你不斷地實(shí)踐 Vibe Coding，這些概念會(huì)自然而然地變得熟悉。

一些對(duì)大家有用的資源：
100+ 編程學(xué)習(xí)路線 / 實(shí)戰(zhàn)項(xiàng)目 / 求職指導(dǎo)
100+ 簡(jiǎn)歷模板
300+ 企業(yè)面試題庫(kù) mianshiya.com
500+ AI 資源大全
1 對(duì) 1 模擬面試
動(dòng)畫學(xué)算法教程