Claude 官方總結的 AI 編程最佳實踐，我用一個項目驗證了

呢篇文章有3112字，大約要睇6分鐘。

最近更新公眾號嘅頻率低咗，係因為參與咗一個開發項目。

具體係咩項目就唔詳細講啦，事關私隱。

個項目本身都幾複雜，涉及三個平台、十幾個業務模塊、大量複雜嘅表格同表單。而且我做嘅係自己唔擅長嘅前端。

但最終睇結果，都做得唔錯。

事後我覆盤咗一下，發現做得好的原因唔單止係AI能力勁。

仲有啲唔係咁「性感」嘅因素：動手前嘅準備、過程入面嘅對齊機制、驗證環節嘅門禁等等。呢啲聽落好老套嘅工程習慣，反而係成個項目最核心嘅支撐。

啱啱最近見到Claude官方出咗篇文章，講Claude Code喺大型項目入面嘅最佳實踐。

讀完有種「豁然開朗」嘅感覺，我喺項目入面模糊感覺到嘅嘢，呢篇文章用一個框架串起曬。

今日想結合呢篇文章同我自己嘅經歷，傾下AI編程呢件事，到底點樣做先至更加靠譜。

大多數人嘅AI編程方式

2025年頭，Andrej Karpathy出咗條推文，幫一種新嘅編程方式改咗個名：Vibe Coding（氛圍編程）。

即係點解呢？

簡單講就係：用自然語言話俾AI知你想要乜，AI生成代碼，你基本上唔睇代碼細節，只睇最終效果用唔用得。。

「just vibe with it」，跟住感覺走就得。

呢種方式點解咁紅？因為門檻極低。

你唔需要識編程語言嘅語法，唔需要理解框架嘅運作原理，甚至唔需要知道代碼寫咗喺邊個檔案入面。講幾句說話，一個網頁就出咗嚟。

快感係即時嘅。

但問題嚟喇。

當項目大多少少、複雜少少，Vibe Coding就開始頂唔順。

你叫AI加個功能，佢將之前嘅邏輯改壞咗。

你想改一個bug，佢改完又彈出兩個新嘅。

你要加個新頁面，風格同前面完全唔夾。

你返轉頭想睇下代碼究竟搞咩，發現自己根本睇唔明。

因為由頭到尾你都冇睇過。

呢種體驗，用過AI編程嘅人應該都唔陌生。

Vibe Coding本身冇問題。攞嚟做原型驗證、寫個人小工具、跑一次性腳本，完全冇問題。

問題在於，好多人當咗佢係AI編程嘅全部。

連Karpathy自己喺更加正式嘅場合都轉咗講法，改用咗「Agentic Engineering」。創造者都喺度修正呢個概念嘅邊界，說明Vibe Coding確實唔應該係終點。

真正決定效果嘅，唔係模型

Claude官方喺嗰篇文章入面有一句話我印象好深：

圍繞模型構建嘅生態系統同框架，比模型本身更加能夠決定Claude Code嘅性能。

呢句話令我想起之前好紅嘅一個概念，叫 Harness。

LangChain嘅Vivek Trivedy講過一句被廣泛引用嘅話：

喺唔同地方都見到類似嘅觀點，說明呢個可能係而家嘅共識。

Harness呢個英文單詞，原本意思係馬具。繮繩、馬鞍、馬鐙呢套裝備。馬係力氣，馬具係令你可以駕馭呢股力氣嘅嘢。

放喺AI編程上，一個完整嘅AI Agent可以拆成一個簡單嘅等式：

Agent = 模型 + Harness

模型決定AI點樣諗，呢部分我哋改唔到。

Harness決定AI睇到啲乜、用到啲乜工具、失敗咗點算、結果點樣驗證。呢部分先係我哋可以搭、應該搭嘅。

一個好嘅Harness係點樣

Claude官方喺文章入面俾咗一個清晰嘅框架：五個擴展點，加埋兩個補充能力。

我覺得呢個框架嘅價值唔止係Claude Code嘅功能介紹。佢背後嘅思路，對所有AI編程工具都適用。

1. CLAUDE.md：俾AI嘅入職手冊

呢類檔案會喺每次會話開始時自動加載，話俾AI知呢個項目嘅基本規矩：技術棧係乜、代碼風格點樣定、邊啲檔案唔鬱得、測試點樣跑。

你可以理解成俾新同事嘅入職文檔。能力再強嘅人，第一日返工都要先知道公司嘅規則。

AI都係一樣。

2. Hooks（鈎子）：自動執行嘅規則

與其靠AI記住「每次提交前跑一次格式化」，不如直接寫一個鈎子腳本自動執行。

靠提示詞係「請你記得做」，靠鈎子係「唔理你記唔記得，系統幫你做」。程序嘅約束比語言嘅提示靠譜得多。

3. Skills（技能）：按需加載嘅專業知識

一個大項目入面有幾十種唔同類型嘅任務。如果將所有知識都塞入每次會話，上下文好快就會爆。

Skills嘅做法係按需加載：做安全審查時加載安全規則，寫文檔時加載文檔規範，需要乜就加載乜，平時唔佔空間。

4. Plugins（插件）：好配置嘅打包分發

團隊入面成日有人將AI環境調校得好好。但如果呢啲經驗只留喺個人配置入面，其他人用唔到，好做法就變咗部落知識。

Plugin將一整套配置打成一個包，新人裝上就有同樣嘅AI環境。

5. MCP Server：連接外部世界嘅橋

AI默認只睇到你本地嘅檔案。

但實際開發中，你可能需要佢去讀需求管理工具上嘅ticket、查內部文檔、調內部API。MCP Server就係令AI掂得到呢啲外部資源嘅通道。

補充能力：子代理（Subagent）

呢個喺大項目入面特別有用。你可以將一個大任務拆俾多個獨立嘅AI實例並行處理，每個實例有獨立嘅上下文，互不幹擾，做完之後彙總結果。

呢五個擴展點嘅思路係通用嘅。

唔理你用緊Claude Code、Cursor、Copilot定係其他工具，你都需要諗清楚呢幾件事：AI進入項目時睇到啲咩上下文？重複性嘅規則有冇自動化？唔同任務嘅知識點樣管理？好嘅配置能唔能夠複用？

我嘅實踐：一套令AI唔走偏嘅SOP

講返我自己。

坦白講，做呢個項目之前，我對AI編程嘅理解都幾樸素。俾需求、睇代碼、改bug、繼續。冇咩體系。

但今次項目嘅複雜度唔容許我咁隨意。十幾個模塊、三個平台、仲要係自己唔擅長嘅前端。如果仲係「講一句睇一步」，好大機會會出事。

最終我係配合 superpower 呢個Skills跑通嘅係一套固定嘅作業流程，每個模塊行一次：

食透上下文 → 交互式對齊 → 寫精確計劃 → 拍板確認 → 子Agent執行 → 端到端驗證 → 合併

gather context（吃透上下文）
 → brainstorming（交互式對齊：一次一個問題，把意圖/邊界/成功標準問清，產出 spec）
 → writing-plans（寫實現計劃：精確到文件路徑 + 完整代碼 + 測試命令，no placeholder）
 → 用戶 greenlight（拍板）
 → subagent-driven-development（逐任務派子 Agent 實現 + 複核 diff/tsc）
 → 端到端驗證（browser-harness/ playwright Test ）
 → finishing-a-development-branch（合併回 main，本地 ff-merge）

呢入面有幾個環節，我覺得好有用。

對齊前置。

喺寫任何代碼之前，先用交互式嘅問答，將AI嘅理解同自己嘅意圖對齊。

通過一輪輪對話，最終產出一份雙方都認可嘅設計規格。

點解要咁麻煩？因為錯誤越早發現越抵。AI理解嘅方向同你想嘅唔同，寫咗幾百行代碼先發現要推倒重來，咁就係純粹浪費。

十分鐘嘅對齊，可以慳兩小時嘅返工。呢個我反覆驗證過。

計劃即代碼。

呢度講嘅「計劃」唔係粗略嘅待辦清單，係精確到檔案路徑、冇模糊佔位符嘅具體實施方案。

計劃寫完嗰一刻，執行階段就變咗機械性嘅工作。所有需要人做判斷嘅嘢，喺寫計劃時已經全部做曬。AI跟住執行就得。

呢一步嘅好處喺後面先真正顯現出嚟。

驗證體系。

類型檢查全部通過、單元測試全綠、多語言文本對齊、自動瀏覽器入面實際跑一次睇效果。呢套檢查清單，每次合併前必須全部通過。

有咗呢套體系，每次新增完功能，修復完Bug，我都可以放心合併，可以極大提升自己嘅生產效率。

AI編程嘅三個階段

講到呢度，我想將前面嘅內容串返起。

如果將AI編程嘅方式排一條路徑，大致可以分三個階段：

階段一：Vibe Coding（氛圍編程）

講幾句說話令AI生成代碼，唔睇細節，只睇效果。適合原型驗證、個人小工具、一次性腳本。

快，但唔可持續。

階段二：Spec-driven Coding（規範驅動開發）

喺叫AI動手之前，先用規範文檔將產品嘅各個維度定義清楚：產品係乜、今次要整啲乜、視覺係點樣、技術架構點樣定。

簡單講就係：先諗清楚，再叫AI寫代碼。

用規範文檔約束AI嘅每一次決策，保證咗一致性同可維護性。

Spec-driven比Vibe Coding前進咗一大步。但佢主要解決嘅係「想清楚先做」嘅問題。當項目進一步複雜，你仲需要解決另一個問題：點樣令AI喺執行過程中唔出錯、唔走偏？

階段三：Harness Engineering（駕馭工程）

唔止係寫規範，而係搭建一整套環境：上下文管理、自動化約束、反饋迴路、驗證體系、子代理編排。令AI喺一個好嘅工作環境入面做嘢。

呢三個階段唔係非此即彼。Vibe Coding有佢嘅位置，Spec-driven解決咗一大類問題，Harness Engineering處理複雜項目效果最好。

寫喺最後

簡單總結一下今日傾嘅嘢。

如果只係想用AI快速驗證某個項目，做個個人小工具，跑個一次性腳本，咁只需「just vibe with it」。

但如果需要用AI參與需要長期維護嘅項目，唔止係靠同AI對話，仲需要先諗清楚、搭建對應嘅Harness環境。

目前我自己都仲摸索緊，今次累積嘅經驗，下次未必全部適用。工具喺變，模型喺變，最佳實踐都喺變。

但如果只能留一條建議，大概就係：咪急住叫AI寫代碼，先將需求討論清楚。

• AI時代，你嘅上下文先係最值錢嘅資產

• 2026年點樣用得好AI，我發現呢啲能力更加重要

• Openclaw咁紅，但你真係需要佢嗎？

• 全網都喺度抄Karpathy嘅知識庫，但大多數人只學到皮毛

• Claude Code最佳實踐之一，將你嘅重複工作打包成一個Skill

• 點樣用Claude Code開啟10倍學習法？

本文字數 3112，閲讀大約需 6 分鐘

最近這段時間更新公眾號頻率有所下降，是因為在參與一個開發項目。

具體是什麼項目就不展開了，涉及一些隱私。

項目本身還是有一定複雜程度的，涉及三個平台、十幾個業務模塊、大量複雜表格和表單。而且我做的還是自己並不擅長的前端。

但最終從結果上來看，完成得還是不錯的。

事後，我覆盤了一下，我發現能做好不只是因為 AI 能力很強。

還有一些不是那麼「性感」的因素：動手前的準備、過程中的對齊機制、驗證環節的門禁等。這些聽起來很老派的工程習慣，反而是整個項目最核心的支撐。

剛好最近看到 Claude 官方發了一篇文章，講的是 Claude Code 在大型項目中的最佳實踐。

讀完有一種「豁然開朗」的感覺，我在項目裏模糊感知到的東西，這篇文章用一個框架給串了起來。

今天想結合這篇文章和我自己的經歷，聊聊 AI 編程這件事，到底該怎麼做才能更靠譜。

大多數人的 AI 編程方式

2025 年初，Andrej Karpathy 發了一條推文，給一種新的編程方式取了個名字：Vibe Coding（氛圍編程）。

什麼意思呢？

簡單說就是：用自然語言告訴 AI 你想要什麼，AI 生成代碼，你基本不看代碼細節，只看最終效果能不能用。

「just vibe with it」，跟着感覺走就行。

這種方式為什麼火？因為門檻極低。

你不需要懂編程語言的語法，不需要理解框架的運作原理，甚至不需要知道代碼寫在了哪個文件裏。說幾句話，一個網頁就出來了。

快感是即時的。

但問題來了。

當項目稍微大一點、複雜一點，Vibe Coding 就開始撐不住。

你讓 AI 加一個功能，它把之前的邏輯改壞了。

你想改一個 bug，它改完又冒出兩個新的。

你要加一個新頁面，風格跟前面完全對不上。

你回頭想看看代碼到底怎麼回事，發現自己根本看不懂。

因為從頭到尾你就沒看過。

這種體驗，用過 AI 編程的人應該都不陌生。

Vibe Coding 本身沒有問題。拿來做原型驗證、寫個人小工具、跑一次性腳本，完全沒毛病。

問題在於，很多人把它當成了 AI 編程的全部。

連 Karpathy 自己在更正式的場合都換了說法，改用了「Agentic Engineering」。創造者都在修正這個概念的邊界，說明 Vibe Coding 確實不該是終點。

真正決定效果的，不是模型

Claude 官方在那篇文章裏有一句話我印象很深：

圍繞模型構建的生態系統及框架，比模型本身更能夠決定 Claude Code 的性能。

這句話讓我想到了前段時間特別火的一個概念，叫 Harness。

LangChain 的 Vivek Trivedy 說過一句被廣泛引用的話：

在不同的地方都能看到類似的觀點，說明這可能就是當下的共識。

Harness 這個英文單詞，原義是馬具。繮繩、馬鞍、馬鐙這套裝備。馬是力氣，馬具是讓你能駕馭這股力氣的東西。

放到 AI 編程上，一個完整的 AI Agent 可以拆成一個簡單的等式：

Agent = 模型 + Harness

模型決定 AI 怎麼想，這部分我們改不了。

Harness 決定 AI 能看到什麼、能用什麼工具、失敗了怎麼辦、結果怎麼驗證。這部分才是我們能搭、該搭的。

一個好的 Harness 長什麼樣

Claude 官方在文章裏給出了一個清晰的框架：五個擴展點，加上兩個補充能力。

我覺得這個框架的價值不只是 Claude Code 的功能介紹。它背後的思路，對所有 AI 編程工具都適用。

1. CLAUDE.md：給 AI 的入職手冊

這類文件會在每次會話開始時自動加載，告訴 AI 這個項目的基本規矩：技術棧是什麼、代碼風格怎麼定、哪些文件不能動、測試怎麼跑。

你可以理解成給新同事的入職文檔。能力再強的人，第一天上班也得先知道公司的規則。

AI 也一樣。

2. Hooks（鈎子）：自動執行的規則

與其靠 AI 記住「每次提交前跑一下格式化」，不如直接寫一個鈎子腳本自動執行。

靠提示詞是「請你記得做」，靠鈎子是「不管你記沒記得，系統替你做」。程序的約束比語言的提示靠譜得多。

3. Skills（技能）：按需加載的專業知識

一個大項目裏有幾十種不同類型的任務。如果把所有知識都塞進每次會話，上下文很快就爆掉了。

Skills 的做法是按需加載：做安全審查時加載安全規則，寫文檔時加載文檔規範，需要什麼就加載什麼，平時不佔空間。

4. Plugins（插件）：好配置的打包分發

團隊裏總有人把 AI 環境調教得特別好。但如果這些經驗只留在個人配置裏，其他人用不上，好做法就變成了部落知識。

Plugin 把一整套配置打成一個包，新人裝上就擁有同樣的 AI 環境。

5. MCP Server：連接外部世界的橋

AI 默認只能看到你本地的文件。

但實際開發中，你可能需要它去讀需求管理工具上的 ticket、查內部文檔、調內部 API。MCP Server 就是讓 AI 夠得着這些外部資源的通道。

補充能力：子代理（Subagent）

這個在大項目中格外有用。你可以把一個大任務拆給多個獨立的 AI 實例並行處理，每個實例有獨立的上下文，互不干擾，做完後彙總結果。

這五個擴展點的思路是通用的。

不管你用的是 Claude Code、Cursor、Copilot 還是別的工具，你都需要想清楚這幾件事：AI 進入項目時能看到什麼上下文？重複性的規則有沒有自動化？不同任務的知識怎麼管理？好的配置能不能複用？

我的實踐：一套讓 AI 不跑偏的 SOP

說回我自己。

坦白說，做這個項目之前，我對 AI 編程的理解挺樸素的。給需求、看代碼、改 bug、繼續。沒什麼體系。

但這次項目的複雜度不允許我這麼隨意。十幾個模塊、三個平台、還是自己不擅長的前端。如果還是「說一句看一步」，大概率翻車。

最終我是配合 superpower 這個 Skills 跑通的是一套固定的作業流程，每個模塊走一遍：

吃透上下文 → 交互式對齊 → 寫精確計劃 → 拍板確認 → 子 Agent 執行 → 端到端驗證 → 合併

gather context（吃透上下文）
 → brainstorming（交互式對齊：一次一個問題，把意圖/邊界/成功標準問清，產出 spec）
 → writing-plans（寫實現計劃：精確到文件路徑 + 完整代碼 + 測試命令，no placeholder）
 → 用戶 greenlight（拍板）
 → subagent-driven-development（逐任務派子 Agent 實現 + 複核 diff/tsc）
 → 端到端驗證（browser-harness/ playwright Test ）
 → finishing-a-development-branch（合併回 main，本地 ff-merge）

這裏面有幾個環節，我覺得很有用。

對齊前置。

在寫任何代碼之前，先用交互式的問答，把 AI 的理解和自己的意圖對齊。

通過一輪輪對話，最終產出一份雙方都認可的設計規格。

為什麼要這麼麻煩？因為錯誤越早發現越便宜。AI 理解的方向跟你想的不一樣，寫了幾百行代碼才發現要推倒重來，那就是純浪費。

十分鐘的對齊，能省兩小時的返工。這是我反覆驗證過的。

計劃即代碼。

這裏說的「計劃」不是粗略的待辦清單，是精確到文件路徑、沒有模糊佔位符的具體實施方案。

計劃寫完的那一刻，執行階段就變成了機械性的工作。所有需要人做判斷的事情，在寫計劃時已經全部做完了。AI 照着執行就行。

這一步的好處在後面才真正顯現出來。

驗證體系。

類型檢查全部通過、單元測試全綠、多語言文本對齊、自動瀏覽器裏實際跑一遍看效果。這套檢查清單，每次合併前必須全過。

有了這套體系，每次新增完功能，修復完 Bug，我都可以放心合併，能極大提升自己的生產效率。

AI 編程的三個階段

聊到這裏，我想把前面的內容串一下。

如果把 AI 編程的方式排一條路徑，大致可以分三個階段：

階段一：Vibe Coding（氛圍編程）

說幾句話讓 AI 生成代碼，不看細節，只看效果。適合原型驗證、個人小工具、一次性腳本。

快，但不可持續。

階段二：Spec-driven Coding（規範驅動開發）

在讓 AI 動手之前，先用規範文檔把產品的各個維度定義清楚：產品是什麼、這次要做什麼、視覺長什麼樣、技術架構怎麼定。

簡單說就是：先想清楚，再讓 AI 寫代碼。

用規範文檔約束 AI 的每一次決策，保證了一致性和可維護性。

Spec-driven 比 Vibe Coding 前進了一大步。但它主要解決的是「想清楚再做」的問題。當項目進一步複雜，你還需要解決另一個問題：怎麼讓 AI 在執行過程中不出錯、不跑偏？

階段三：Harness Engineering（駕馭工程）

不只是寫規範，而是搭建一整套環境：上下文管理、自動化約束、反饋迴路、驗證體系、子代理編排。讓 AI 在一個好的工作環境裏幹活。

這三個階段不是非此即彼。Vibe Coding 有它的位置，Spec-driven 解決了一大類問題，Harness Engineering 處理複雜項目效果最好。

寫在最後

簡單總結一下今天聊的。

如果只是想要用 AI 快速驗證某個項目，做個個人小工具，跑個一次性腳本，那隻需「just vibe with it」。

但如果需要用 AI 參與需要長期維護的項目，不只是靠跟 AI 對話，還需要先想清楚、搭建對應的 Harness 環境。

目前我自己也還在摸索，這次積累的經驗，下次未必全部適用。工具在變，模型在變，最佳實踐也在變。

但如果只能留一條建議，大概就是：別急着讓 AI 寫代碼，先把需求討論清楚。

• AI 時代，你的上下文才是最值錢的資產

• 2026 年如何用好 AI，我發現這些能力更重要

• Openclaw 這麼火，可你真的需要它嗎？

• 全網都在抄 Karpathy 的知識庫，但大多數人只學到了皮毛

• Claude Code 最佳實踐之一，把你的重複工作打包成一個 Skill

• 如何用 Claude Code 開啓10 倍學習法？