別再把 Claude Code 當聊天框了：高手已經把它訓成一支團隊

好多人用 Claude Code 嘅方法，其實好嘥。

打開。

問一句。

叫佢改個文件。

叫佢寫個腳本。

叫佢解釋一段報錯。

然後完。

咁當然有用。

但如果你只係咁用，佢最多係一個好叻嘅 programmer 朋友。

仲未係一個團隊。

最近 AI HOT 入面有一條我好在意嘅內容：

有人將 Claude Code 嘅正確用法，整理成類似 Agent Development Kit 嘅結構。

入面有幾個關鍵詞：

`CLAUDE.md`

`skills`

`hooks`

`subagents`

`plugins`

我見到呢幾個詞嘅時候，第一個反應唔係技術興奮。

而係商業興奮。

因為呢套結構背後真正講嘅，唔係「點樣令 Claude 寫 code 更勁」。

而是：

而係點樣將一個 AI 傾偈工具，組織成一支可控、可複製、可擴張嘅工程團隊。

呢樣嘢對一人公司好重要。

傾偈框思維係乜嘢？

我有個問題。

我問 AI。

AI 回答。

我再問。

佢再答。

呢個模式簡單、直接、上手快。

但佢有個天生缺陷：

上文下理唔穩定。

規則唔穩定。

質素唔穩定。

你今日同佢講一次 project 規範，佢記住咗。

聽日開個新視窗，佢又唔記得。

你今日叫佢小心改 code，佢做得好好。

聽日另一個任務，佢又開始大改特改。

所以真正嘅工程化，第一步唔係令模型更聰明。

而係畀佢組織結構。

公司點解要有制度？

唔係因為員工蠢。

而係因為就算幾聰明嘅人，如果冇共同規則，都會互相打交。

AI 都係一樣。

當你開始同 Claude Code 配 `CLAUDE.md`，寫 skills，set hooks，分 subagents，佢就唔再只係一個傾偈框。

佢開始有公司制度、職位說明、安全護欄、專職小組同 plugin 生態。

咁就完全唔同曬。

`CLAUDE.md` 可以理解為呢個 project 入面嘅公司章程。

佢話畀 Claude 知：

呢個 project 係做乜㗎。

code 嘅風格係點。

邊啲 command 可以行。

邊啲 file 唔可以掂。

測試點樣做。

遇到唔肯定嘅問題點處理。

幾時要先睇文件。

幾時唔可以直接改。

呢啲規則，如果靠你每次口頭講，會好辛苦。

寫入 `CLAUDE.md`，佢就變成 project 上文下理嘅一部分。

呢件事對非 programmer 都幾有啟發。

因為我哋做內容，都需要自己嘅 `CLAUDE.md`。

好似我嘅公眾號系統，至少要寫清楚：

我嘅帳號定位係一人 AI 公司。

我嘅讀者係想用 AI 提升生產力、做個人 IP、做細而美業務嘅人。

我嘅文章要有真實實踐，唔好空談。

我嘅選題要能夠連接 AI 工具、商業化同普通人嘅行動。

我嘅文章唔追求完美中立，要有明確判斷。

我嘅排版要適合手機閲讀。

我嘅草稿要先入公眾號草稿箱，唔直接羣發。

呢個就係內容系統嘅章程。

冇呢份章程，你每次都要重新訓練 AI。

有咗佢，AI 先至可以慢慢變成你嘅團隊成員。

如果話 `CLAUDE.md` 係公司章程，skills 就係職位說明書。

唔同崗位做唔同事。

選題編輯有選題編輯嘅規則。

主筆有主筆嘅規則。

排版有排版嘅規則。

封面設計有封面設計嘅規則。

發佈助理有發佈助理嘅規則。

數據分析有數據分析嘅規則。

你唔可以指望一個 Prompt 同時完成所有角色。

佢會亂。

又會濫。

所以我而家越來越鍾意將任務拆成 Skill。

AI HOT Skill 負責揾 AI 資訊。

寫作 Skill 負責生成公眾號長文。

排版 Skill 負責將 Markdown 轉成公眾號 HTML。

封面 Skill 負責做圖。

發佈腳本負責發草稿箱。

每個 Skill 淨係做自己應該做嘅嘢。

就好似公司入面分工。

唔係為咗複雜。

而係為咗穩定。

當一個人想日更 5 篇嘅時候，最怕嘅唔係寫唔出。

最怕嘅係所有環節撈亂曬。

你一便揾選題，一便寫文章，一便排版，一便做封面，一便發後台。

個腦會俾頻繁切換拖垮。

Skill 嘅價值，就係將呢啲角色拆開。

好多人對 AI 編程最大嘅恐懼，係佢亂改嘢。

呢個恐懼係合理嘅。

AI 好勁，但佢都有可能犯好低級嘅錯。

例如刪錯 file。

蓋過用戶修改。

行危險 command。

將密鑰寫入公開文件。

所以工程化入面一定要有 hooks。

你可以將 hooks 理解成自動檢查同安全護欄。

某啲動作發生之前，先檢查。

某啲 file 俾人改咗之後，自動行測試。

某啲危險操作，直接攔住。

呢件事映射到內容營運裏面，都係一樣。

公眾號發佈之前，都應該有 hooks。

檢查正文係咪重複標題。

檢查有冇殘留 QR code 佔位符。

檢查 AppSecret 有冇被寫入文章。

檢查封面是否存在。

檢查正文長度係咪合理。

檢查係咪先入草稿箱。

呢啲嘢如果靠人手檢查，遲早會漏。

寫成自動檢查，系統就穩定好多。

自動化真正嘅成熟，唔係行得快，而係知道幾時要停。

當任務越來越複雜，一個 AI 一次過做曬所有嘢，會好攰。

上文下理會亂。

注意力會散。

所以需要 subagents。

佢哋好似專職小組。

一個負責調研。

一個負責 code。

一個負責測試。

一個負責文案。

一個負責審稿。

每個小組淨係拎自己需要嘅上文下理。

咁樣效率更高，亦更可控。

我而家做公眾號自動化，都越來越感受到呢個諗法。

將來如果我要每日更 5 篇，最好唔係叫一個 AI 由頭做到尾。

而係叫唔同角色協作：

選題 Agent 由 AI HOT 同 Obsidian 裏面揾題目。

寫作 Agent 負責長文。

短片 Agent 負責拆條。

排版 Agent 負責公眾號格式。

封面 Agent 負責視覺。

發佈 Agent 負責草稿箱。

覆盤 Agent 負責數據回收。

最後我做總編輯。

我唔需要每個環節都親自落場。

但我一定要決定今日打邊幾場仗。

一個團隊唔可以剩係得把口。

佢要能夠連接工具。

瀏覽器。

本地文件。

伺服器。

公眾號 API。

圖片生成。

表格。

知識庫。

呢啲外部能力，就係 plugins 或工具接口嘅價值。

我今次跑通公眾號草稿箱自動化，最有感受嘅就係呢點。

如果 Codex 只可以傾偈，佢冇可能將文章發到公眾號。

佢一定要能夠讀本地 Obsidian。

一定要能夠生成文件。

一定要能夠處理圖片。

一定要能夠連接伺服器。

一定要能夠調用微信接口。

一定要能夠將真實結果送入草稿箱。

呢個就係由「識講」到「識做」嘅分別。

好多 AI 產品嘅問題，係淨係俾到建議。

真正有價值嘅 Agent，係能夠進入你嘅工作現場。

好多人聽到工程化，會覺得係大公司嘅事。

我以前都係咁諗。

但而家我越來越覺得，一人公司更加需要工程化。

因為你冇團隊幫你兜底。

你冇營運同事。

冇編輯。

冇美術設計。

冇技術。

冇項目經理。

如果你嘅流程唔工程化，所有混亂都會返返你自己身上。

你會變成一個俾自己業務吞噬咗嘅人。

我喺《大廠小民》嘅筆記入面寫過一個感受：

大廠嘅人會俾大系統吞噬。

一人公司嘅人，都有可能俾自己搭嘅小系統吞噬。

如果你每日都喺低價值任務入面打轉，一人公司並唔會更自由。

佢只係將老細、員工、財務、營運、客服、編輯，全部塞入你一個人身體入面。

所以，我而家要做嘅唔係請人。

而係先搭好個系統。

用得機械解決嘅，一定唔請人。

用得外包解決嘅，一定唔全職。

用得 Skill 解決嘅，一定唔每日手動重複。

呢個唔係偷懶。

呢個係生存。

我唔想將某一個工具吹到天上有地下無。

Claude Code 有 Claude Code 嘅強項。

Codex 有 Codex 嘅強項。

Cursor、Warp、OpenCode，亦都有自己嘅生態。

工具會變。

但方向唔會變。

將來嘅 AI 工作者，唔會淨係得一個傾偈窗口。

佢會有一套 Agent 工程底盤。

入面有規則文件。

有 Skill 庫。

有安全 hooks。

有子 Agent。

有 plugin。

有本地知識庫。

有外部 API。

有自動化發佈鏈路。

呢套嘢，就係一人公司嘅隱形團隊。

你見唔到佢坐喺辦公室。

但佢每日都喺度行。

幫你揾選題。

幫你寫草稿。

幫你排版。

幫你發草稿箱。

幫你覆盤。

幫你提醒下一個動作。

呢個就係我話「唔好將 Claude Code 當傾偈框」嘅原因。

傾偈框只係入口。

工程化系統，先至係終局。

如果你今日仲係偶爾問 AI 幾句，都冇問題。

所有人都係由嗰度開始。

但你要知道，下一步喺邊。

下一步唔係寫更長嘅 Prompt。

下一步係搭建組織。

同 AI 寫章程。

同 AI 分崗位。

同 AI 加護欄。

同 AI 接工具。

同 AI 安排協作。

然後你由執行者，慢慢變成總編輯、產品經理、老細。

呢個就係我最近兩星期打地基嘅真正原因。

我唔係研究工具。

我係喺度同自己搭一間公司。

只不過，呢間公司暫時冇員工。

佢由知識庫、Skill、Agent、腳本、伺服器組成。

聽起嚟有啲怪。

但佢真係已經開始行緊。

很多人用 Claude Code 的方式，其實很浪費。

打開。

問一句。

讓它改個文件。

讓它寫個腳本。

讓它解釋一段報錯。

然後結束。

這當然有用。

但如果你只這樣用，它最多是一個很強的程序員朋友。

還不是團隊。

最近 AI HOT 裏有一條我非常在意的內容：

有人把 Claude Code 的正確用法，整理成了類似 Agent Development Kit 的結構。

裏面有幾個關鍵詞：

`CLAUDE.md`

`skills`

`hooks`

`subagents`

`plugins`

我看到這幾個詞的時候，第一反應不是技術興奮。

而是商業興奮。

因為這套結構背後真正講的，不是“怎麼讓 Claude 寫代碼更厲害”。

而是：

怎麼把一個 AI 聊天工具，組織成一支可控、可複製、可擴張的工程團隊。

這對一人公司太重要了。

聊天框思維是什麼？

我有一個問題。

我問 AI。

AI 回答。

我再問。

它再答。

這個模式簡單，直接，上手快。

但它有一個天然缺陷：

上下文不穩定。

規則不穩定。

質量不穩定。

你今天告訴它一次項目規範，它記住了。

明天新開一個窗口，它又忘了。

你今天讓它謹慎改代碼，它做得很好。

明天另一個任務，它又開始大刀闊斧。

所以真正的工程化，第一步不是讓模型更聰明。

而是給它組織結構。

公司為什麼要有制度？

不是因為員工笨。

而是因為再聰明的人，如果沒有共同規則，也會互相打架。

AI 也是一樣。

當你開始給 Claude Code 配 `CLAUDE.md`，寫 skills，設 hooks，分 subagents，它就不再只是一個聊天框。

它開始有公司制度、崗位說明、安全護欄、專職小組和插件生態。

這就完全不一樣了。

`CLAUDE.md` 可以理解為這個項目裏的公司章程。

它告訴 Claude：

這個項目是幹什麼的。

代碼風格是什麼。

哪些命令可以跑。

哪些文件不能碰。

測試怎麼做。

遇到不確定問題怎麼處理。

什麼時候要先讀文件。

什麼時候不能直接改。

這些規則，如果靠你每次口頭說，會累死。

寫進 `CLAUDE.md`，它就變成項目上下文的一部分。

這件事對非程序員也很有啓發。

因為我們做內容，也需要自己的 `CLAUDE.md`。

比如我的公眾號系統，至少要寫清楚：

我的賬號定位是一人 AI 公司。

我的讀者是想用 AI 提升生產力、做個人 IP、做小而美業務的人。

我的文章要有真實實踐，不要空談。

我的選題要能連接 AI 工具、商業化和普通人的行動。

我的文章不追求完美中立，要有明確判斷。

我的排版要適合手機閲讀。

我的草稿要先進公眾號草稿箱，不直接羣發。

這就是內容系統的章程。

沒有這份章程，你每次都要重新訓練 AI。

有了它，AI 才能逐漸變成你的團隊成員。

如果說 `CLAUDE.md` 是公司章程，skills 就是崗位說明書。

不同崗位做不同事。

選題編輯有選題編輯的規則。

主筆有主筆的規則。

排版有排版的規則。

封面設計有封面設計的規則。

發佈助理有發佈助理的規則。

數據分析有數據分析的規則。

你不能指望一個 Prompt 同時完成所有角色。

它會亂。

也會泛。

所以我現在越來越喜歡把任務拆成 Skill。

AI HOT Skill 負責找 AI 資訊。

寫作 Skill 負責生成公眾號長文。

排版 Skill 負責把 Markdown 轉成公眾號 HTML。

封面 Skill 負責做圖。

發佈腳本負責發草稿箱。

每個 Skill 都只做自己該做的事。

這就像公司裏分工。

不是為了複雜。

而是為了穩定。

當一個人想日更 5 篇的時候，最怕的不是寫不出來。

最怕的是所有環節混在一起。

你一邊找選題，一邊寫文章，一邊排版，一邊做封面，一邊發後台。

大腦會被頻繁切換拖垮。

Skill 的價值，就是把這些角色拆開。

很多人對 AI 編程最大的恐懼，是它亂改。

這個恐懼是合理的。

AI 很強，但它也可能犯很低級的錯。

比如刪錯文件。

覆蓋用戶修改。

跑危險命令。

把密鑰寫進公開文件。

所以工程化裏必須有 hooks。

你可以把 hooks 理解成自動檢查和安全護欄。

某些動作發生前，先檢查。

某些文件被改後，自動跑測試。

某些危險操作，直接攔住。

這件事映射到內容運營裏，也一樣。

公眾號發佈前，也應該有 hooks。

檢查正文是否重複標題。

檢查是否殘留二維碼佔位。

檢查 AppSecret 有沒有被寫進文章。

檢查封面是否存在。

檢查正文長度是否合理。

檢查是否先進草稿箱。

這些東西如果靠人肉檢查，遲早漏。

寫成自動檢查，系統就穩很多。

自動化真正的成熟，不是跑得快，而是知道什麼時候該剎車。

當任務越來越複雜，一個 AI 一口氣做完所有事，會很累。

上下文會亂。

注意力會散。

所以需要 subagents。

它們像專職小組。

一個負責調研。

一個負責代碼。

一個負責測試。

一個負責文案。

一個負責審稿。

每個小組只拿自己需要的上下文。

這樣效率更高，也更可控。

我現在做公眾號自動化，也越來越能感受到這個思路。

未來如果我要每天更 5 篇，最好不是讓一個 AI 從頭幹到尾。

而是讓不同角色協作：

選題 Agent 從 AI HOT 和 Obsidian 裏找題。

寫作 Agent 負責長文。

短視頻 Agent 負責拆條。

排版 Agent 負責公眾號格式。

封面 Agent 負責視覺。

發佈 Agent 負責草稿箱。

覆盤 Agent 負責數據回收。

最後我做總編輯。

我不需要每個環節都親自下場。

但我必須決定今天打哪幾個仗。

一個團隊不能只靠嘴。

它要能接工具。

瀏覽器。

本地文件。

服務器。

公眾號 API。

圖片生成。

表格。

知識庫。

這些外部能力，就是 plugins 或工具接口的價值。

我這次跑通公眾號草稿箱自動化，最有感觸的就是這一點。

如果 Codex 只能聊天，它不可能把文章發到公眾號。

它必須能讀本地 Obsidian。

必須能生成文件。

必須能處理圖片。

必須能連接服務器。

必須能調用微信接口。

必須能把真實結果送到草稿箱。

這就是從“會說”到“會做”的區別。

很多 AI 產品的問題，是隻能給建議。

真正有價值的 Agent，是能進入你的工作現場。

很多人聽到工程化，會覺得那是大公司的事。

我以前也這麼想。

但現在我越來越覺得，一人公司更需要工程化。

因為你沒有團隊幫你兜底。

你沒有運營同事。

沒有編輯。

沒有美編。

沒有技術。

沒有項目經理。

如果你的流程不工程化，所有混亂都會回到你自己身上。

你會變成一個被自己業務吞掉的人。

我在《大廠小民》的筆記裏寫過一個感受：

大廠的人會被大系統吞掉。

一人公司的人，也可能被自己搭的小系統吞掉。

如果你每天都在低價值任務裏打轉，一人公司並不會更自由。

它只是把老闆、員工、財務、運營、客服、編輯，全塞進你一個人身體裏。

所以，我現在要做的不是招人。

而是先把系統搭起來。

能用機器解決的，絕不招人。

能用外包解決的，絕不全職。

能用 Skill 解決的，絕不每天手動重複。

這不是偷懶。

這是活下去。

我不想把某一個工具吹成神。

Claude Code 有 Claude Code 的強項。

Codex 有 Codex 的強項。

Cursor、Warp、OpenCode，也都有自己的生態。

工具會變。

但方向不會變。

未來的 AI 工作者，不會只擁有一個聊天窗口。

他會擁有一套 Agent 工程底盤。

裏面有規則文件。

有 Skill 庫。

有安全 hooks。

有子 Agent。

有插件。

有本地知識庫。

有外部 API。

有自動化發佈鏈路。

這套東西，就是一人公司的隱形團隊。

你看不到它坐在辦公室裏。

但它每天在跑。

給你找選題。

給你寫草稿。

給你排版。

給你發草稿箱。

給你覆盤。

給你提醒下一個動作。

這才是我說“別把 Claude Code 當聊天框”的原因。

聊天框只是入口。

工程化系統，才是終局。

如果你今天還只是偶爾問 AI 幾句話，也沒關係。

所有人都是從那裏開始的。

但你要知道，下一步在哪裏。

下一步不是寫更長的 Prompt。

下一步是搭組織。

給 AI 寫章程。

給 AI 分崗位。

給 AI 加護欄。

給 AI 接工具。

給 AI 安排協作。

然後你從執行者，慢慢變成總編輯、產品經理、老闆。

這就是我最近兩週打地基的真正原因。

我不是在研究工具。

我是在給自己搭一家公司。

只不過，這家公司暫時沒有員工。

它由知識庫、Skill、Agent、腳本、服務器組成。

聽起來有點怪。

但它真的已經開始跑了。