Alex Lee

現在用 AI 開發有什麼好方法：一個老兵的 11 條實戰經驗

Sun, 25 Oct 2026 17:30:00 GMT

有人問我，現在用 AI 開發有什麼好方法。我說這主要看你把 AI 用到什麼程度了，是新項目還是維護舊項目。真要展開來說，篇幅會非常大，這裏簡單說一下我個人的幾點經驗：

需求、詳細設計可以 AI 來做，但是架構一定要自己把關。
核心約束一定要有四個：一是要求文檔、對話都要說人話；二是任何文檔的新建、改寫，都不要壓縮任何信息，不以節省 token 爲導向；三是代碼必須要有註釋，任何函數、類、接口以及重要的邏輯，必須要有註釋。這三點其實說白了，就是解決你文檔看不看得懂、代碼看不看得懂的問題。最後一個，就是能複用現有代碼就複用，能有成熟的開源項目和第三方庫就使用，不要重複造輪子。這一點也很重要，否則你會發現 AI 寫了大量代碼，實際效果不如一個成熟的庫有用。
第一批 AI 寫的文檔，一定要仔細閱讀，哪怕看着很不耐煩也要仔細閱讀，儘量把問題在文檔階段就解決掉。否則隨着 AI 寫的代碼越來越多、文檔越來越多，你會越來越不想看文檔，不想去閱讀代碼。很多的漂移和邊界擴大，都是因爲這一點。
在需求、架構、設計階段，訪談式很好用。你可以讓 agent 採用訪談式方式和你共同編寫，也可以讓 agent 和子 agent 自問自答來替代你做。但是每一步都要 append 到一個 list，不要相信它的上下文壓縮機制足夠好。
單元測試、門禁都是需要的，特別是項目越來越大時，更加需要。但是要定好規則，一個是單元測試和門禁的編寫和使用時機，一個是不要每次都跑全量。這能決定開發進度和 token 的浪費，同時避免過早進入優化的泥潭。
無論一個 agent 編寫你的項目，還是多個子 agent 並行開發，都會有一個很明顯的問題出現：那就是重複代碼、重複邏輯。這個當前很難避免，哪怕像我第 2 點寫了約束也一樣。Ponytail 這個 skill 庫有一定的作用，但是不能用原版，要修改，否則效果並不會很好。整個項目看下來，仍舊會有大量的、本可以合併或者抽象化的代碼，實際上寫了多個版本存在。而且使用不當，會導致你的代碼質量出現問題。
review 一定要，不管每次的任務大小都需要，而且 review 一定要獨立且嚴格。什麼叫做獨立？就是不要開發者自審，而是交給其他的子 agent，如果有條件，甚至可以交給其他的大模型。review 一般來說要進行多輪，而且看複雜程度，簡單的一個 agent 去審，複雜的多個 agent 從不同的角度、或者分配不同的模塊去審，然後主 agent 負責去重、交叉驗證以及終審調研。這一步非常重要，因爲很多的 issue 都需要交叉驗證才能找到根因，否則就是不斷的打補丁式開發，修復只是解決了標，但是不治本。你讓它修好了，然後再次 review 又會發現新的問題，多輪下來修復了一大堆，但是實際上根因可能只有一個。另外一個就是要注意 review 是否存在過度審查，這點可以寫提示詞或者自己寫一個技能，但是最終還是要依靠你自己的能力，任何的提示詞和技能無法保證不會出現過度審查。最後就是不要一句“你給我 review”就完事了，要指出重點審查的方面，比如審查內存是否出現越界、溢出、泄漏等內存問題，是否存在過度設計，是否線程所有權和異步線程的使用方式正確等。
skills 的使用，我不建議在當前這些頂級模型上開啓諸如 superpowers 之類的強約束技能組。這類效果是有，但是不見得收益有那麼大。個人來說，內置的 skill 和幾個自己修改過的足夠；團隊來說，工程化的 skill 一兩個足夠。再多就是負擔了。說句大白話，就算你用了 TDD、DDD 等等的玩意，實際產出的還是 AI 在審查，項目越大，人類審查的難度越大。
最重要是，就算你的項目跑了成千上萬的門禁，並且通過了，也不代表你的項目就可以上線了。這本身就是一個僞命題。因爲門禁再多，單元測試覆蓋再完整，不代表本身項目不會出問題。這些最多保證在有限的、已經驗證的前提下，項目是正常的。至於如何做，每個公司有自己的方式，比如我們一個小項目，全量門禁超過 10 萬個，跑一次要 30 分鐘，但是我們仍舊讓另外的 agent 根據設計文檔重新寫了一套攻擊程序，加在 CI 的最後一個環節。
其他的還有一些技巧，可能網上很多人都說了，就是 AGENTS.md、CLAUDE.md 只寫不超過 100 行核心提示，其他都是隻做索引。內部文檔採用結構化目錄保存，每個目錄有入口索引，測試要有臺賬，每次測試都要 append 臺賬。文檔的管理不要用編號，而是依靠 git 倉庫管理。等等之類的，就不多說了，網上到處都是。
哦，差點忘記了，還有大模型的選型。國內的模型我不是很瞭解，也基本上沒有用過。光從 Claude 和 GPT 來說，他們適合不同的領域，Claude 的分析能力非常強，在項目的架構、設計等階段執行的非常好，比 GPT 強非常多，唯一算是缺點的，就是自主能力太強了，你約束不好，它就會幫你做很多不必要的事情。GPT 在解決複雜問題上的確比 Claude 差很多，但是在幹活上就比較聽話，所以看你怎麼用了，我一般複雜的問題交給 Claude，簡單的局部的代碼編寫交給 GPT。另外很多時候我是用 Claude 來指揮 GPT 幹活，這樣效果很不錯，Claude Code 中它會監督 GPT 去做具體的任務，並及時地糾正和調整。至於模型切換，我不建議網上人說的換來換去，比如先讓它分析使用最強模型，幹活使用次級模型，一個連續的任務最好不要換來換去，除非本身就是主任務和子任務。這不是上下文的問題，而是大模型本身 cache 命中的問題。

其他的一時半會要麼想不起來，要麼要展開說纔行。總之上面這些就是簡單的我的一些經驗。真正如果展開說，這是非常大的一塊內容，不是簡單幾條就能說清楚的。正好你問起來了，我就簡單地說了下我的經驗，可能因爲是臨時起意，有些不完整和不對的地方，僅供參考。

我把 HumanLayer 的源碼拆了一遍：能管住 AI，但你的會話要先上它的雲

Sat, 24 Oct 2026 12:13:00 GMT

HumanLayer 前幾天把整套系統開源了。11.8k star，Apache 2.0，官方說雲上跑的也是同一套代碼。它做的這件事，恰好是現在很多人想要的：讓 AI 編程助手自己幹活，危險操作先停下來問人。

倉庫兩千多萬字節，我先通讀了一遍，關鍵文件又對着官方文檔核了一輪。工程是真工程，思路也對。但它比看上去重得多，有幾個問題，官方博客裏是不會主動提的。

它賣的是什麼

你讓 Claude Code 或者 Codex 自己寫代碼，它就會自己跑命令、改文件、裝依賴。快是真快。問題是你不可能一直盯着屏幕，它刪錯一個目錄、跑錯一條命令，往往就一秒鐘的事。

HumanLayer 賣的就是一個審批層。AI 每想幹一件有風險的事，先停下來，把這件事推到你的網頁或手機上。你點了批准它才繼續；點拒絕，它就收手，拒絕的理由它還看得見。你不在電腦前，也能遠程看着它幹活、遠程批。

聽起來簡單。真做起來，它分了三種接法，性質完全不一樣。

第一種：它自己當司機

你在它的網頁上下一個任務，你電腦上裝的那個常駐程序接到活，自己把真正的 Claude Code 拉起來幹。

因爲進程是它拉起來的，每一道關都攥在它手裏。只有少數幾個動作（搜代碼、查文件、調用技能）自動放行，其他操作先在雲端記一條“待審批”，程序就地卡住，等你那邊的結果。你批了，它放行；你拒了，它把你的原話轉給 AI 看。

這一種是真攔截。因爲方向盤在它手裏。

第二種：你自己開車，它在旁邊轉播

你習慣自己在終端裏開 Claude Code，它有個插件可以裝。Claude Code 本來要停下來問你的時候，插件把這個問題同步一份到網頁，你在網頁上點同意也算數。終端彈窗和網頁同時在，誰先答算誰的。

聽着挺聰明。但有個天花板，它自己的說明文檔寫得也算坦白：如果你的 Claude Code 設的是“別問我，直接幹”，那它根本不產生問題，插件就沒東西可轉播了，只剩記錄，沒有攔截。插件靠的還是 Claude Code 一個比較新的內部接口，官方哪天改版，它就得跟着追。

第三種：它那個“Codex”，是它自己寫的

這是我拆源碼時最意外的一處。

你在 HumanLayer 裏選 Codex 這個選項，跑起來的是它自研的一個程序，拿你的 ChatGPT 登錄去調 OpenAI 的接口，工具是它自己實現的，對話存在它自己的數據庫裏。它文檔裏那句“Codex 會話由 HumanLayer 保存”，就是這麼來的。

順便交代另外兩個：OpenCode 的接法是第二種轉播；Pi 的那個插件只有轉播，連審批都沒有，它自己的 README 寫了，Pi 不問就全跑。

你的數據到底在哪

這是我最想提醒的一段。

官方裝法是云爲中心的。你電腦上那個程序只負責幹活，賬本在雲上。你的每一次對話、每一步操作、改了哪些代碼、任務文件、用了多少額度，統統寫進 HumanLayer 雲上的數據庫，再同步回你的各個設備。

它文檔裏明確寫了，它不代理你調模型的那部分流量，這點是好的。但會話內容本身，就是在人家的雲上躺着的。

它也給了自建的路。自己從源碼編譯、自己部署，官方說不回傳任何數據，那些統計和上報的開關都在配置裏，沒設就是關的。這條我認。但自建現在很毛坯，好幾個第三方服務的密鑰不填，服務起都起不來，官方指南還寫着“在寫了”。還有個小瑕疵：它最核心的那兩個包，包文件裏沒寫許可證字段。代碼是公開的，但這種細節，做過開源的都懂，差一口氣。

再說封號風險，這個最少有人提

用訂閱賬號的登錄，去第三方工具裏調模型，這件事 Anthropic 在 2026 年初已經劃過線了：文檔寫明不許，技術上堵過，賬號真封過一批，後來解封了些。理由也簡單，訂閱是按官方客戶端定的價格，你拿去喂第三方程序，用量對不上，人家不認。

對照着看 HumanLayer。它的 Claude 路徑走官方工具鏈拉起真 Claude，相對還在框裏。但它那個自研的“Codex”，拿的是你的 ChatGPT 登錄，在它自己的程序裏直調接口。這正好是各家在收緊的那種用法。現在 OpenAI 還沒照着 Anthropic 的劇本走完，但線已經擺在那了。哪天真收緊，先疼的是你的賬號。

這類工具幫你省的是訂閱的錢，你押上的是賬號本身。這筆賬得自己算。

還有一層是體量。兩千多萬字節的代碼，功能越全，面越大。開源是加分項，但開源不等於有人審過。11.8k star 裏，真正把審批那條鏈讀完的沒幾個。判斷一個工具值不值得託付，我的老辦法是看它把數據放在哪、把關卡設在哪，剩下的都是宣傳。

說回我的看法：這事被做複雜了

我做了 24 年全棧。當年帶團隊，最大的教訓之一就是系統越重，你要託付的東西越多。

HumanLayer 這套，雲端賬本、實時同步、多端界面、任務系統、評論系統，全套下來是給團隊用的：多人協作、留痕審計、幾個 AI 並行幹活，這些場景它確實值。但如果你是個個人開發者，想要的只是“AI 幹活我看得見、危險操作先問我、我不在電腦前也能批”，爲這一個功能把全部會話交給一個雲，賬算不過來。

而且這事官方自己留了門，根本不用繞這麼大圈子。

Codex 本身就帶一個叫 app-server 的標準接口。OpenAI 自家的編輯器插件和 App，都是走它跟 Codex 對話的。這個協議裏天生就有“請求用戶批准”這一環，還是開源的。Claude Code 這邊，有個叫 ACP 的開放協議，Zed 牽頭做的，也能把它封裝起來，權限請求在協議裏是一等公民，現成的適配器就有。兩條路走的都是官方工具、官方接口，工具自帶的安全限制照常生效，它本來就會在危險操作前停下來問。

剩下的活就小得多了。寫一個轉發小程序，用 hook 把“它要問你了”這個事件接住，把問題推到你的 WhatsApp 或者 Telegram。你在聊天裏回個“準”或者“駁”，小程序把你的話原樣塞回去。會話數據不出你的電腦（聊天軟件本身除外），沒有云端賬本，沒有誰拿你的訂閱登錄去別的地方調接口。代碼量跟上面那一整套比，不是一個數量級。

醜話說前面：轉發這條路糙。界面就是聊天窗口，任務看板、diff 評論、多人協作這些都沒有。你要是帶團隊、正經做審計，那類重傢伙該買買、該建建。我這條路適合單幹圖省事的。它還有個隱藏好處：哪天官方改了政策，你斷的是自己寫的小程序，修起來一個下午；押在別人整套平臺上的，遷移成本是另一回事。

我打算自己先把這條轉發鏈做出來試試。好不好用，做完再來彙報。

源碼與出處：HumanLayer 倉庫 github.com/humanlayer/humanlayer；官方開源公告 hlyr.dev/blog/open-sourcing-humanlayer；文中架構細節均出自該倉庫源碼與自帶文檔，封號政策部分據 Anthropic 2026 年公開文檔與說明整理。