燒了 20 億 Token ,Claude Code的3萬字使用心得分享給你

事情是這樣的。

去年年底,我讓 Claude Code 幫我改一個不到 200 行的小腳本,一個用來批量給公眾號文章配圖的玩意。

它改完了。

然後它跟我說,順手幫我修了一個 bug,在第 87 行,三個月前埋的,我自己根本不知道存在。

我當時就愣住了。

那一刻我突然意識到,我手裏這個東西,不是「更好用的 ChatGPT」,也不是「更聰明的 Cursor」。這是一個會主動思考、自己找活幹的搭檔。

從那天起到現在,差不多一年,我和我那十個 AI 員工在 Claude Code 上燒掉了 20 億 Token。

這個數字聽着挺唬人。

但你猜我這一年實際花了多少錢?

幾百到一千多塊,一張哈囉單車年卡的價格。

很多人一聽「20 億 token」就覺得這肯定是個燒錢玩意,不是大公司玩不起。坦率的講,這是我寫這篇文章最想破除的第一個誤解。

訣竅不在於多花錢,在於怎麼讓 90% 的 token 走 Sonnet,只讓最難的那 10% 走 Opus,再疊加 prompt caching,成本能壓到你想不到的程度。這個事我會在第二章細講。

所以這篇 3 萬字,不是教程。教程在官方文檔裏,你點進去看比我寫得清楚。

這篇是,一個用一張單車年卡的錢、跑了一年時間、踩了無數坑才搞明白的事,我把它整理出來,你看完最多花兩小時,能省下來的至少是幾個月的瞎摸索。

而且我要強調一點,這篇文章是寫給非程序員的。

因為我自己也不是程序員。我是一個做內容、做諮詢、做訓練營的人,公司就我一個人加十個 AI 員工。Claude Code 在我這裏的角色,不是「幫我寫代碼」,是「幫我把我每天那些重複的、瑣碎的、需要動腦但又不需要太動腦的事,全乾了」。

我用它清洗 Excel,用它寫公眾號文章,用它跑爬蟲,用它做 PPT,用它管我的知識庫,甚至用它幫我審合同。

代碼,只是它順帶能做的事而已。

所以如果你以為 Claude Code 是給程序員用的,你已經把這個工具的潛力浪費了 90%。

接下來 3 萬字,我會按一個從 0 到 1 完整使用閉環來講,你跟着讀完一遍,就知道自己卡在哪一層、下一步該往哪走。

第一章,認知校正。先把你腦子裏那些關於 Claude Code 的錯誤印象清掉。

第二章,裝好、跑通、別踩坑。三條安裝路、第一次跑通的姿勢、五個新手必踩坑、怎麼選模型才不燒錢。

第三章,CLAUDE.md。整本教程最值錢的一章。

第四章,7 個高頻場景實戰。這章最厚,8000 字,每個場景都附完整指令。

第五章,上下文管理。為什麼 Claude Code 用着用着就變傻了。

第六章,Hooks 和 Subagents。從「用工具」進化到「建系統」的分水嶺。

第七章,SOUL 大於 Skill。這章不講技術,講認知。也是我自己覺得最重要的一章。

第八章,一人公司的 Claude Code 工具棧。我自己一天 7 個使用節點,具體到每一句指令,全部公開。

最後,寫給非程序員的一句話,送你三天上手計劃。

好,開始。

六偉公眾號 ————————————————————

你以為的 Claude Code,和真實的 Claude Code

我先講一個真實的事。

前幾天,我一個做律師的朋友找我,說她最近被一個東西震撼到了。她們所裏一個專門做法務的同事,用 Claude Code 寫了一個小程序——不是給客戶用,是給所內做內部溝通用的,把那種特別難措辭的拒絕郵件、客戶難纏的回覆郵件,做成了一個輔助生成工具。

我當時第一反應是,你確定她是法務?

她說,對,法務。不會寫代碼,完全靠 Claude Code 一句一句指令搭出來的。

我突然就明白了一件事。

大多數人對 Claude Code 的認知,還停留在「這是給程序員用的寫代碼工具」。這個誤解,正在讓 90% 的非技術從業者錯過這一波最大的紅利。

我接下來要拆三個最常見的錯誤認知。這三個誤解,任何一個不破除,你都用不出 Claude Code 真正的威力。

第一個誤解,「這是給程序員用的」。

錯。

Anthropic 公司內部統計過一組數據,他們自己員工裏用 Claude Code 最重度的幾個部門,排第一的不是工程團隊,是法務和市場。法務用它做合同審查、文書起草、案例對比;市場用它做素材整理、數據分析、活動覆盤。這兩個部門,幾乎沒有人會寫代碼。

那他們怎麼用?

他們用的是 Claude Code 的「自然語言+文件操作」能力,不是它的「寫代碼」能力。

你想想看,Claude Code 能做什麼?它能讀你電腦上的任何文件,能在你電腦上執行任何命令,能上網,能調用工具,能寫文件,能改文件,能跑測試——這些能力裏,只有最後兩個跟「程序員」有關,前面那些跟你每天工作裏的 Excel、PDF、Word、合同、郵件、文檔沒有任何區別。

代碼,只是 Claude Code 能輸出的產物裏的一種。它還能輸出 Excel、能輸出 PPT、能輸出 PDF、能輸出文章、能輸出圖、能輸出幾乎任何文件。

把它當成一個會用電腦的實習生,而不是一個會寫代碼的工程師,這個工具在你眼裏立刻變了一個東西。

第二個誤解,「它就是更好的 Cursor」。

這個誤解的殺傷力其實更大,因為它會讓你按錯誤的方式去用。

Cursor 是 IDE 插件,Claude Code 是 Agent。這倆差的不是一個版本,是一個維度。

Cursor 的工作方式是,你打開一個文件,你說「幫我改這一段」,它幫你改。它在你的視線範圍內,你看着它幹活。

Claude Code 的工作方式是,你說「我要完成 XX 任務」,它自己去翻你的文件,自己去判斷哪些要讀、哪些要改、哪些要新建,中途遇到不確定的來問你,搞完了告訴你做了什麼。

Cursor 是你的副駕駛。Claude Code 是你的實習生。

副駕駛和實習生的區別在哪?副駕駛你得一直在駕駛座上,他幫你做的是「眼前這一步」的事。實習生你可以走開,他幫你做的是「整件事」。

所以你用 Claude Code 的姿勢,應該是派活而不是結對。

我舉個具體例子。同樣是「整理這周的客戶反饋」這件事——

用 Cursor 的人會這麼幹,打開反饋文檔,選中一段,說「幫我提煉一下」,然後選下一段,說「幫我提煉一下」,搞了一個小時,整理出一份摘要。

用 Claude Code 的人會這麼幹,扔給它一個文件夾路徑,說「這裏面是這周所有客戶反饋,你幫我按問題類型分類,提煉共性問題,生成一份給 PM 的反饋報告,放到 outputs 目錄」,然後去喝杯咖啡,十分鐘後回來取報告。

你看,這就是「副駕駛」和「實習生」的區別。

第三個誤解,「要會寫 Prompt 才能用好」。

這個誤解流傳最廣,因為這兩年所有人都在講「提示詞工程」。

但 Claude Code 真的不需要你會寫 Prompt。

你需要的是,把你想做的事,用普通話說清楚。就這一件事。

我跟你講我自己的真實指令長什麼樣,你感受一下——

「幫我看下 downloads 裏那個客戶反饋 Excel,我要找出來裏面所有抱怨發貨慢的,導出成一個新文件」

「這個 PDF 給我提取一下里面所有數字,做成一個表格」

「我那個公眾號草稿裏有幾個錯別字,你幫我掃一遍」

你看,這些根本不是 Prompt,這就是你跟一個新來的實習生說話的方式。

那「提示詞工程」是幹嘛的?

提示詞工程是給 ChatGPT 這種「只有一次對話窗口」的工具用的。因為它只能在那一次對話裏發揮能力,你必須把所有信息、所有上下文、所有規則,一次性塞給它,所以才需要精心設計 Prompt。

Claude Code 不一樣。Claude Code 有上下文、有記憶、有工具、有文件系統。它可以自己去翻文檔、自己去確認信息、自己來問你不清楚的地方。

所以你不需要把指令寫得多麼精妙,你只需要把目標講清楚。剩下的它自己來。

講到這,我用一個比喻徹底總結這一章。

普通 AI 工具是計算器,你按一個鍵出一個結果。Claude Code 是一個新來的實習生,你給他一個任務,他自己去翻文件、查資料、寫代碼、跑測試、報告結果,中途遇到問題來問你。

如果你能接受「我有一個不要工資、永不疲倦、隨時待命的實習生」這個設定,你就已經用對 Claude Code 了。

最後講一下它的能力邊界,免得你高估它也低估它。

它能做的事——讀寫本地任何文件、執行任何命令、操作 Excel/Word/PDF、上網搜資料、寫代碼並運行、調用各種 MCP 工具(飛書、Notion、郵件、日曆)、做數據分析、寫文章、做 PPT、跑爬蟲、自動化任何重複操作。

它做不了的事——它沒法看你的屏幕(除非你截圖給它)、它沒法點鼠標操作軟件 UI(那是瀏覽器 Agent 的事)、它沒法處理需要長期記憶的事(除非你寫進 CLAUDE.md)、它沒法在你完全不監督的情況下做高風險操作(改數據庫、刪文件、刷信用卡)。

記住一句話:它能做你電腦上 80% 的「需要動腦但不需要太動腦」的事,前提是你能把這件事用普通話講清楚。

這一章先講到這。下一章,我們裝好它,跑通它,繞過幾個新手必踩的坑。

六偉公眾號 ————————————————————

第一章講完認知,這章講操作。

我會按這個順序展開:國內怎麼裝、第一次跑通選什麼任務、新手必踩的 5 個坑、Opus 和 Sonnet 怎麼選才不燒錢。

每一段都是我自己踩過的,不是從文檔裏抄的。

先說裝。

國內用 Claude Code,有三條路可以走,我把每條路的成本、速度、穩定性給你列清楚,你自己選。

第一條路,官方直連。優點是穩定、官方更新最快、可以用 Anthropic 訂閲。缺點是需要科學上網、Anthropic 賬號在國內不好開。如果你有一個還在用的 Anthropic 賬號,直接走官方,體驗最乾淨。

第二條路,API 中轉。國內有一些第三方服務把 Anthropic API 做了轉發,你買他們的 token,他們給你一個 base_url 和 key,你改一下 Claude Code 的環境變量就能用。優點是國內速度快、付費方便、不用折騰科學上網。缺點是穩定性看商家,有時候會突然漲價或者卡頓。我自己用過 wenwen-ai、aicodemirror 這幾家,各有各的脾氣,你自己挑。

第三條路,Amazon Bedrock。亞馬遜雲上託管的 Claude,可以走 AWS 賬號付費。優點是穩定、企業級、可以走公司賬户報銷。缺點是開通流程長、價格比官方貴一些、對非技術用戶不友好。一人公司不推薦這條路,除非你已經是 AWS 重度用戶。

我自己的選擇是第二條,主用 API 中轉,關鍵任務上官方做對比。一年下來穩定性還行,價格也比官方便宜一點。

裝完之後,核心配置就一件事——告訴 Claude Code 你要用哪個模型、走哪個 endpoint。這部分官方文檔講得很清楚,我就不抄了。

裝好了,不要急着上來就讓它寫項目。

這是我看到最多新手犯的錯。第一次用就甩給它一個大項目,「幫我做一個客戶管理系統」,然後等了半小時,看它跑得亂七八糟,得出結論「這玩意不好用」。

你想想看,你公司新來一個實習生,第一天上班你就讓他獨立做一個系統?不是他能力差,是你的派活姿勢不對。

第一次用 Claude Code,選一個 45 秒能出結果的最小任務,建立信任感。

我推薦你的第一個任務——

「幫我分析一下 Downloads 文件夾裏那個最新的 Excel,告訴我裏面有沒有異常數據。」

為什麼是這個任務?

第一,Excel 幾乎每個非程序員都有,門檻為零。第二,「異常數據」這個表述很模糊,但 Claude Code 能自己理解成「空值、重複值、格式錯誤、明顯偏離的極值」,這就讓你立刻感受到它的「自己理解需求」能力。第三,45 秒能出結果,即時反饋,建立信任。

你跑完這一個任務,大概率會有一個「卧槽這玩意真的能幹活」的瞬間。

那個瞬間,就是你正式入門 Claude Code 的起點。

接下來講新手必踩的 5 個坑。

第一個坑,上下文窗口沒管理好,越聊越亂。

很多人用 Claude Code 是這麼用的——開一個會話,從早聊到晚,什麼事都在這一個會話裏聊。聊到下午,它開始犯迷糊,你以為它笨,其實是上下文塞太滿,關鍵信息被淹沒了。

正確的姿勢是,一個獨立任務開一個新會話。任務結束就 /clear,或者直接開新窗口。把上下文窗口當成內存,而不是硬盤。這件事我第五章會單獨詳細講。

第二個坑,沒有 CLAUDE.md,每次都要重新說規則。

這是新手最常見的低效來源。每次開會話都要重新告訴它「我是幹嘛的、我的文件放哪、我的偏好是什麼」。

這些事應該一次寫好,放進 CLAUDE.md,Claude Code 每次啓動自動讀取。這個文件就是你和 AI 的契約。第三章我會用一整章講它,因為它確實是整本教程最值錢的一章。

第三個坑,用它寫完代碼沒有跑,直接交付。

這個坑專門坑那些非程序員的——AI 給你寫了一段代碼,你看着語法工整、邏輯通順,直接複製走了。結果一跑,報錯。

記住,讓 Claude Code 自己跑一遍。指令很簡單,「寫完直接幫我跑一下看有沒有問題」。它會自己運行、自己看報錯、自己修。

這是 Claude Code 跟傳統 AI 助手最大的區別——它不只是生成代碼,它會對結果負責。前提是你要讓它對結果負責。

第四個坑,任務太大沒拆分,中途上下文溢出。

我前面說過,Claude Code 是實習生。再聰明的實習生,你也不能一上來就甩給他「把整個公司業務流程梳理一遍」這種任務。

正確的姿勢是,先拆任務,再派活。你可以讓 Claude Code 自己拆,「這個事我大概想做 XXX,你幫我先拆解成幾個獨立的小任務,我們一個一個來」。它會給你一個 todo list,然後逐個執行。

第五個坑,權限沒控制好,讓它改了不該改的文件。

Claude Code 默認每個文件操作都會問你確認。但很多人嫌煩,直接開了 --dangerously-skip-permissions,然後某天它一不小心把你重要的文件覆蓋了。

我的建議是,前三個月,不要開 skip-permissions。等你完全摸清楚它的脾氣,知道它什麼時候會亂來、什麼時候不會,再考慮開。

講完坑,講費用。這是新手最焦慮的事。

Opus 4.7 是 Anthropic 當下最強的模型,但是貴。Sonnet 4.7 是它的弟弟,價格只有 Opus 的五分之一,但能力上對一人公司日常任務來說,95% 的場景夠用。

什麼時候用 Opus?什麼時候用 Sonnet?

我自己有一個非常粗暴但好用的決策樹——

默認用 Sonnet。Excel 清洗、文檔整理、爬蟲、內容生產、文件操作、調用 MCP 工具,這些用 Sonnet 全都夠。

遇到下面這三種情況切到 Opus:第一,需要做戰略性思考、需要它「想清楚再動手」的複雜任務;第二,需要它讀懂一個大型代碼庫、做架構層面的判斷;第三,Sonnet 試了兩次效果不好,覺得它沒理解到位。

光這一招,我自己一年下來,Opus 的使用佔比控制在 20% 以內,整體賬單比無腦全開 Opus 便宜了 5 倍。

再疊加一個 prompt caching 的小竅門——

Claude Code 有一個自動機制,會把你 CLAUDE.md 和最近讀過的文件緩存起來,下一次調用時這部分只算十分之一的錢。這個機制是默認開的,你不用管,但你需要知道它的存在,因為它直接決定了你怎麼組織你的項目。

什麼意思?如果你的 CLAUDE.md 寫得很好、很穩定,Claude Code 每次啓動都會命中緩存,你實際付的錢只有標價的十分之一。所以 CLAUDE.md 不只是「讓 Claude 懂你」,它還在「幫你省錢」。

這一章先停在這。下一章,我們正式進入整本教程最值錢的部分——CLAUDE.md。

六偉公眾號 ————————————————————

你的 AI 員工手冊

如果讓我從這 3 萬字裏挑一章,只能保留一章,我會留這一章。

不是因為別的章不重要,是因為沒有 CLAUDE.md,你永遠停留在「每天重新教 AI 一遍你是誰」的循環裏,Claude Code 在你這裏就是一個高級版的 ChatGPT,完全發揮不出 Agent 的威力。

我先講一件事。

Claude Code 的核心開發者 Boris Cherny,在一次訪談裏說過一句話,大意是——「Anthropic 內部團隊維護着一份純文本知識庫,裏面記錄 Claude 每一次犯過的錯、每一個學到的偏好、每一條不要碰的紅線,這份文件每週更新」。

那份文件,就是他們的 CLAUDE.md。

CLAUDE.md 不是配置文件,是契約。

是你和這個 AI 實習生之間,關於「你是誰、你想要什麼、你不要什麼」的全部約定。

這份契約越完整,Claude Code 就越像「你訓練出來的那個版本」,而不是「一個通用的 AI」。

這一章我會講四件事:CLAUDE.md 的完整結構、它的進化規律、三層記憶系統、一份真實的模板。

先講完整結構。

一份合格的 CLAUDE.md,我自己總結下來有 6 個核心板塊。

板塊一,關於我。

這裏寫你是誰。不是簡歷,是「Claude 需要知道的關於你的事」。

我自己 CLAUDE.md 裏的「關於我」長這樣——

「我是袁六偉,一人 AI 公司創始人,主業做 AI 教育訓練營和企業智能體交付。公司就我一個人加十個 AI 員工。我自己不會寫代碼但會用 AI 寫,做事節奏快、不喜歡繁瑣確認、追求一次性把事情做對。」

就這一段話,Claude Code 在我這裏所有的輸出就自動調成了「直接給結論、少廢話、按一人公司視角思考」的模式。

這段話不是 Prompt,是身份聲明。Claude Code 看到這段話之後,會內化成它對「我是誰」的理解,然後所有後續行動都基於這個理解。

板塊二,項目背景。

這裏寫你正在做的事情、你的資源、你的工具鏈。

「我的內容生產管道是 Tavily 搜索 → khazix 寫作風格 → liuwei-layout 排版 → wechat-formatter 出圖。我的智能體系統叫 OpenClaw,跑在飛書和 Telegram。我的知識庫在 Obsidian。我所有的項目代碼在 ~/Projects 目錄。」

為什麼要寫這個?因為當你說「幫我寫一篇公眾號」的時候,Claude Code 需要知道走哪條管道。它不需要每次問你,它需要默認就懂。

板塊三,禁止事項。

這個板塊最重要,我用紅線標出來——

CLAUDE.md 裏寫 10 條「不要做什麼」,比寫 100 條「要做什麼」都管用。

為什麼?因為 AI 天生傾向於「多做」。你不給它邊界,它就會自由發揮。而你大多數的不滿,都來自它「自由發揮得不符合你的預期」。

我自己 CLAUDE.md 裏的禁止事項長這樣——

「不要在文章里加 emoji。不要用『總的來說』『綜上所述』。不要在沒確認之前刪除任何文件。不要修改 ~/Projects/important 目錄下的任何東西。不要給我推薦 Notion、推薦 Xiaohongshu(這倆我不用)。不要假設我用 Mac,我用的是 macOS 但配置可能不同。」

這些「不要」每一條都是我踩過坑總結出來的。每一條都讓 Claude Code 在我這裏更省心一分。

板塊四,輸出規範。

這裏寫你要的輸出長什麼樣。

我的規範是——

「所有文件輸出到 ~/Outputs。所有公眾號文章用 liuwei-layout 排版,文件名純英文。所有代碼項目附 README。所有 PPT 走黑金風。所有信息圖走 4K PNG。」

這些規則讓 Claude Code 不用每次問你「輸出到哪、用什麼格式」,它默認就懂。

板塊五,常用路徑。

「~/Projects 是項目目錄。~/Notes 是 Obsidian 知識庫。~/Outputs 是輸出目錄。~/Skills 是技能庫。」

這個看起來很簡單,但是當 Claude Code 不知道你的目錄結構時,它會瞎找,浪費一堆 token,而且經常找錯。寫清楚之後,它直接去對的位置取文件,效率高一倍。

板塊六,歷史錯誤記錄。

這是 Boris Cherny 那個原話的核心——每次 Claude 犯了錯,你修復完之後,把這個錯和修復方式寫進 CLAUDE.md。

比如,「上次讓 Claude 排版公眾號文章,它把章節頭用 div 直接交付,粘到公眾號變成純文字。以後所有章節頭必須 PNG 化,實際寬度 ≥2000px」。

這一條寫進去之後,以後再排版,它不會再犯同樣的錯。

講完結構,講進化規律。

你的 CLAUDE.md 不是一次寫完的,是長出來的。

第一週,你的 CLAUDE.md 可能只有 10 行,就是「我是誰、我的項目在哪」。

第一個月,它會長到 50 行。因為你陸續發現「哎,這個事它老搞錯」「這個偏好它每次都問」「這個路徑它每次找不到」,你把這些一個一個寫進去。

第三個月,它會到 200 行甚至更多。這時候它已經包含了你的全部工作偏好、項目知識、協作規則、踩坑記錄。

到了這個階段,你已經訓練出了一個「定製版的 Claude」。

我的實測數據是,有完整 CLAUDE.md 和沒有 CLAUDE.md,同樣的任務,Claude Code 的一次成功率差 3 倍以上,token 消耗差 5 倍以上。

不是模型變了,是你給的上下文變了。

講完進化,講三層記憶。

Claude Code 的記憶系統有三層,不同的東西放不同的層——

第一層,全局記憶。位置在 ~/.claude/CLAUDE.md。這一層放所有項目通用的規則——你是誰、你的偏好、你的禁忌、你的常用工具鏈。

第二層,項目記憶。位置在每個項目根目錄的 CLAUDE.md。這一層放項目專屬的規則——這個項目是幹嘛的、它的目錄結構、它的特殊約定、它的不要碰的文件。

第三層,會話記憶。在當前對話裏。這一層是臨時的,關掉會話就沒了。所以重要的東西不能依賴會話記憶,該寫進 CLAUDE.md 的必須寫進去。

會話記憶像短期內存,關機就丟;CLAUDE.md 像硬盤,長期持有。重要的東西從來都該寫硬盤。

最後講一份真實模板。

我給你看一段我自己 CLAUDE.md 的真實片段(脱敏過)——

# CLAUDE.md - 袁六偉

## 關於我
我是袁六偉,一人 AI 公司創始人。
做事節奏快、追求一次性做對、不喜歡繁瑣確認。
公司就我一個人加十個 AI 員工。

## 我的內容生產管道
搜索 Tavily → 寫作 khazix-writing-style → 排版 liuwei-layout → 出圖 wechat-formatter。
默認輸出到 ~/Outputs。

## 禁止事項(紅線)
- 不要給我加 emoji
- 不要用「總的來說」「值得注意的是」
- 沒確認前不要刪任何文件
- 不要推薦我用 Notion / Xiaohongshu(我不用)
- 公眾號文章章節頭必須 PNG 化,≥2000px

## 我用的工具
- 編輯器 Cursor
- 知識庫 Obsidian (~/Notes)
- 智能體系統 OpenClaw (~/openclaw)
- 項目代碼 ~/Projects

## 歷史犯錯記錄
- 不要在 wechat-formatter 輸出裏留 position:absolute,公眾號會過濾
- 不要把中文文件名傳給前端預覽,會 404
- 不要在沒拆解任務前就開始改代碼

就這麼一份文件,大概 100 行,我用了一年。

這一年裏,我每次讓 Claude Code 幹活,不用再重複介紹自己、不用再交代偏好、不用再說項目背景。它默認就懂。

這就是 CLAUDE.md 的力量。

講到這,我說一個反常識的判斷——

評估一個人的 Claude Code 使用水平,你看他寫代碼的能力,不如看他 CLAUDE.md 的長度和質量。

代碼是終點,CLAUDE.md 是起點。

下一章,我們進入整本教程最厚的部分——7 個高頻場景實戰。

六偉公眾號 ————————————————————

這章是這本教程的肉。

8000 字,7 個場景,每個場景都按同一個結構展開——背景、指令示例、Claude Code 幹了什麼、踩坑提示、進階玩法。

我按我自己一人公司真實在用的權重鋪,所以你會看到 Excel 清洗、內容生產、爬蟲這幾個場景佔的篇幅明顯多。這不是湊數,這是真實使用頻率。

場景一:數據清洗

這是我用 Claude Code 頻率最高的場景。每週至少 3 次,每次省下我 1-2 小時。

背景:做內容、做營銷、做訓練營,你天天都在跟髒數據打交道。客戶反饋表、報名表、訂單表、調研問卷,沒有一份是乾淨的。空值、重複值、格式錯誤、口語化的輸入、混亂的時間格式,清洗它們是個體力活,但它需要的「智力」其實很低——這種事就該 AI 幹。

指令示例:

「~/Downloads 那個最新的客戶反饋 Excel,你看一下,做這幾件事:1)刪掉重複行 2)統一時間格式成 YYYY-MM-DD 3)把『手機號』那列裏明顯格式錯的標紅 4)按反饋類型分類,生成一份統計 5)結果存到 ~/Outputs,文件名帶今天日期」

Claude Code 幹了什麼:

它會先打開 Excel,告訴你這個文件有幾行幾列、每列長什麼樣。然後它會自己判斷哪些行是重複的、哪些時間格式異常、哪些手機號有問題。它會用 Python 起一個清洗腳本,跑完之後再用 pandas 做分類統計,最後輸出一個新的 Excel + 一份簡短的清洗報告。

整個過程 45 秒到 90 秒。

踩坑提示:

第一,不要直接覆蓋原文件。讓它輸出到新文件,保留原始數據。我自己習慣讓它在文件名後面加日期,feedback_cleaned_20260512.xlsx 這種。

第二,讓它告訴你刪了多少行、改了多少格。這是它「對結果負責」的關鍵 checkpoint。如果刪的太多,你能立刻發現異常。

第三,第一次用 Excel MCP 之前,先讓它裝好。具體怎麼裝第六章會講,這裏你先記住要裝。

進階玩法:

把這種「清洗任務」做成一個 Slash Command。我自己有一個 /clean-feedback 命令,只要把新文件丟進 Downloads,敲一句 /clean-feedback,它就按預設好的規則跑完。

這個就是從「每次都問」進化到「一句話指令」的關鍵路徑。

下面我把這個場景拆開,講三個真實的子案例。你會看到「數據清洗」遠不止「刪重複行」那麼簡單。

子案例一:訓練營報名表清洗(每月固定動作)

我每月開 2-3 期訓練營,每期 80-120 人報名。報名表是一份 Excel,字段包括:姓名、手機號、微信號、所在城市、報名時間、付款金額、備註。

報名表的髒程度我用三個數字告訴你——重複行平均 8-12 條(同一個人填了兩遍)、手機號格式錯誤 5-8 條(多輸了一位、少輸了一位、加了空格、加了短橫線、寫成 86 開頭)、備註欄完全自由發揮(從「我是某某推薦的」到「能加羣嗎」到一段 500 字的自我介紹都有)。

以前的處理流程:開 Excel → 排序找重複 → 手動刪 → 一列一列對手機號 → 備註欄挨個看挨個改。一份 100 行的表,1.5 個小時起步。

現在的流程:

「Downloads 裏那個『xx 期訓練營報名表.xlsx』,做以下處理:

1)按手機號去重,保留最早一行,告訴我刪了幾條

2)手機號統一成 11 位,去掉所有非數字字符,有問題的標紅

3)備註欄做分類:有問題的歸一類、有需求的歸一類、純自我介紹歸一類、空的歸一類

4)輸出三份文件:清洗後的總表、需要回復的問題表、需要單聊的需求表

5)文件名帶今天日期,存到 ~/Outputs/training-camp/」

這一段指令我已經存成了 /clean-camp 這個 Slash Command。每個月開新一期之前,我把報名表丟進 Downloads,敲一句 /clean-camp,90 秒之內三份文件就位。

這件事的本質,不是「Claude Code 替我清洗數據」,是「Claude Code 把一個 90 分鐘的體力活變成一個 90 秒的命令」。

更深一層的本質是,這 90 分鐘省下來之後,我能幹別的更值錢的事。比如給那幾個有特殊需求的報名學員單獨發一條歡迎語——這件事原來根本沒時間做,但它正是「百萬俱樂部轉化率」的關鍵動作。

子案例二:客戶反饋數據歸因(月度動作)

每月底我會讓 Claude Code 跑一遍「客戶反饋歸因報告」。

數據源是三份表:訓練營滿意度問卷、百萬俱樂部成員反饋、諮詢客戶覆盤記錄。三份表加起來一般有 200-400 行,字段從 8 個到 15 個不等,格式完全對不上。

我的指令:

「~/Data/customer-feedback/ 這三個 Excel,做月度歸因分析:

1)統一字段,合併成一份『客戶反饋總表』

2)按反饋類型分:產品建議、服務投訴、續費意向、其他

3)按情緒極性分:正面、負面、中性、混合

4)交叉分析:負面反饋集中在哪些環節、續費意向高的客戶在誇什麼

5)輸出一份 Markdown 歸因報告,3000 字以內,含具體引用

6)報告裏所有結論都要有數據支撐,不要空泛」

最後一條「不要空泛」是關鍵。AI 默認會輸出「客戶對服務整體滿意」這種廢話,你必須明確告訴它「每個結論必須有數據支撐、必須有具體引用」。

跑完之後我得到一份 2500-3000 字的歸因報告,包含——

• 續費意向 TOP 3 的關鍵動作(數據:42% 提到「單獨溝通」、31% 提到「定期覆盤」、24% 提到「真實案例分享」)

• 負面反饋的集中環節(數據:報名後 7 天內的「冷啓動」環節差評率最高,佔負面反饋的 38%)

• 下個月該重點改的三件事

這一份報告,以前我得花 4-6 個小時整理。現在 15 分鐘。而且 Claude Code 的歸因比我自己做的還細——它不會漏掉低頻但重要的信號,我會。

子案例三:即興清洗(每週 1-2 次)

最高頻的還不是上面這兩個,是「即興清洗」。

某個客戶突然丟給我一份 CSV 說「能不能看看這份數據」,某個朋友羣發了一份「行業調研問卷結果」,某個夥伴讓我幫忙整理一下他的「學員名單」——這種事一週 1-2 次,每次都是不同的數據、不同的字段、不同的要求。

以前這種事我一律拒絕,因為「處理這種數據要 1-2 個小時,不值得」。

現在的標準動作:

第一步,讓 Claude Code 先「看一眼」——

「~/Downloads/某某.csv 這份數據,你先幫我看一下,告訴我:

1)行數列數

2)每列大概是什麼內容、數據質量怎麼樣

3)有哪些明顯的髒數據

4)如果我要做 XXX 分析,這份數據夠不夠、缺什麼」

這一步不動數據,只是「偵察」。30 秒之內 Claude Code 會給我一份「數據健康度報告」。

第二步,根據報告決定下一步——

• 數據夠 → 直接說「按這幾個維度分析,輸出報告」

• 數據不夠 → 讓它告訴對方「還需要補充什麼字段」

• 數據髒到沒法用 → 直接放棄,告訴對方「這份數據沒法分析」

這個「先偵察、再決定」的兩步走,是我用 Claude Code 處理髒數據的核心心法。它避免了「一頭扎進去發現做不了」的浪費,也避免了「數據明明不夠還硬要做出結果」的幻覺。

數據清洗這一個場景,我能省多少時間?算給你看——

報名表清洗:每月 3 次 × 90 分鐘 = 270 分鐘 / 月 反饋歸因:每月 1 次 × 300 分鐘 = 300 分鐘 / 月 即興清洗:每週 1.5 次 × 60 分鐘 × 4 周 = 360 分鐘 / 月

合計每月省下 15.5 小時,等於多出來 2 個完整工作日。

更重要的是,這 15.5 小時不是「替代我」的時間,是「我原本根本不會去做」的事。比如即興清洗——以前我直接拒絕,現在我能接,這擴大了我的服務半徑。

一人公司的核心矛盾是「服務半徑有限」。Claude Code 不是讓你做得更快,是讓你能做的事變得更多。

最後講一個反常識的踩坑——

不要用 Claude Code 做「實時數據看板」。

我剛開始用 Claude Code 的時候,以為它能做「實時同步的數據大屏」——飛書表更新一行,看板自動刷新。這事它做不好,而且成本極高。

Claude Code 是「一次性任務」的高手——你扔一份數據給它,它處理完返回。但「常駐監控、實時刷新」這種需求,它不擅長。

如果你要做實時看板,用專門的工具(Looker Studio、Power BI、飛書多維表),Claude Code 只負責「數據清洗」這一段。這就是工具的邊界。

場景二:從需求到產品

這個場景的殺傷力是最大的。因為它直接幹掉了「我有想法但是我不會做」這個最常見的卡點。

背景:你看到一個產品需求,可能是你自己的、可能是你朋友的、可能是你在某個羣裏看到的——你腦子裏有一個「這事我能做出來」的衝動,但是你不會寫代碼,所以你什麼也做不了。

Claude Code 把這個卡點徹底打掉。

指令示例:

我前段時間在小紅書看到一個博主吐槽,說她每天都要寫「日報、週報、月報」三份東西,每份都要從飛書、微信、郵件裏翻聊天記錄、找會議紀要、整理客戶反饋,一份報告至少 1 小時,一週花在寫報告上的時間超過 10 小時。

我看了之後給 Claude Code 發了一句話——

「幫我做一個『彙報助手』,功能是:讀取我指定目錄下的飛書會議紀要 + 微信聊天記錄 + 郵件,自動按『日 / 周 / 月』三個維度生成報告,輸出到 Word。第一步先幫我寫 PRD,我審完之後再寫代碼。」

Claude Code 幹了什麼:

它先幫我寫了一份完整的 PRD,包括產品定位、用戶痛點、核心功能、輸入輸出、技術方案、風險點。我看完,改了兩個地方,然後說「按這個寫」。

它接下來,寫了一個 Python 腳本,大概 400 行,跑通了。One shot 80% 完成度,剩下 20% 是我跟它來回調了 4 次。整個過程大概 2 個小時。

踩坑提示:

第一,先 PRD,再代碼。永遠不要跳過 PRD 直接說「幫我做一個 XXX」。PRD 不是給程序員看的,是用來讓你自己確認「我到底要什麼」。很多需求,你以為想清楚了,寫出 PRD 才發現根本沒想清楚。

第二,讓它列技術方案,不要讓它直接選。讓它給你 2-3 個方案的對比,你選一個。這一步看起來多此一舉,但能避免它選了一個對你來說「過度複雜」的方案。

第三,做完之後,讓它寫 README。哪怕這個工具就你一個人用,README 也要寫。一個月之後你打開這個項目,如果沒有 README,你自己都看不懂這是幹嘛的。

進階玩法:

把 PRD 模板做成一個 Skill。我自己有一個 /prd 命令,它會按固定結構(背景、目標用戶、核心功能、輸入輸出、技術棧、里程碑、風險)生成 PRD。

這一招讓我從「需求到 PRD」的時間從 1 小時壓到 10 分鐘。

場景三:自動化內容生產

這是我用 Claude Code 第二高頻的場景,僅次於數據清洗。

背景:做公眾號、做視頻號、做小紅書,最大的痛點不是寫不出來,是「從選題到發佈」中間有 10 個動作——找選題、查資料、寫初稿、改稿、排版、配圖、做封面、複製粘貼、定時發佈、回評論。每個動作都不難,但 10 個串起來,就是一天的工作量。

我用 Claude Code 把這個流程串成了一條龍。

指令示例:

我自己每天的內容生產,大致是這麼一句話指令——

「今天寫一篇公眾號,主題:Claude Code 給非程序員的實戰指南。先用 Tavily 搜近一週的相關動態,然後用 khazix-writing-style 寫 4000 字,最後用 liuwei-layout 出公眾號 HTML + 封面。」

Claude Code 幹了什麼:

第一步,它調用 Tavily,搜了近一週關於 Claude Code 的所有動態——包括 Anthropic 官方更新、社區討論、爆款帖子、新案例。它會把搜到的東西做一個摘要,告訴我「這個角度最近被討論得多、這個數據是最新的、這個案例可以用」。

第二步,它按 khazix-writing-style 的規則寫文章——四層質檢、金句加粗、章節大數字、文化升維。

第三步,它調 liuwei-layout 出 HTML,調 wechat-cover-generator 出封面,調 wechat-formatter 做 4K PNG 化,最後給我一份「一鍵複製」的公眾號 HTML 文件。

全程我只發了一句指令。耗時大概 15-20 分鐘。

踩坑提示:

第一,搜索是必做的。哪怕你覺得這個主題你自己很懂,也要讓 Claude Code 搜一遍。最新的數據、最新的案例、最新的爭論,你的腦子裏一定不是最新的。搜索是它給文章「時效性」的核心。

第二,Skill 鏈路要提前搭好。如果你沒有 khazix-writing-style 這種 Skill,Claude Code 寫出來的文章就是「通用 AI 文風」,沒有辨識度。Skill 系統是把「你的風格」固化進 AI 的核心機制,第六章會講。

第三,4K PNG 是公眾號的紅線。我自己一開始不知道這個,出的圖在 iPhone Pro Max 上看糊得一塌糊塗。後來才知道公眾號需要 4× DPI 才能在視網膜屏上清晰顯示。

進階玩法:

把整個流程做成一個 Slash Command,/article 主題詞,一句話出整篇。

更進階——加一個「熱點雷達」Subagent,它每天早上自動跑一遍,把當天 AI 圈的熱點摘要發到飛書,你看完選一個主題,直接 /article。

這套流程的本質,是把「人腦裏的工作流」翻譯成「機器能執行的工作流」。你腦子裏那些「先做 A 再做 B 再做 C」的步驟,Claude Code 都能學。前提是你要把它說清楚。

我把這套流水線展開講,這是這本教程裏最值得你抄走的一段。

這套流水線長什麼樣?

每天早上 8 點,我打開電腦,Claude Code 已經在終端裏候着。我說一句——

「今天的選題:Claude Code 給非程序員的實戰指南」

之後我大概只會再說 2-3 次話:選題方向確認一次、初稿審一次、最終成片確認一次。中間所有的搜資料、寫、改、配圖、排版、出封面,Claude Code 自己幹。

下午 4 點左右,一篇 4000-8000 字的公眾號 HTML、4K 封面圖、9 張數據可視化圖、一份發佈前 checklist,全部就位。

這不是「AI 幫我寫文章」,是「AI 把內容生產線全自動化」。區別在哪?

「AI 幫我寫文章」=「我打開 ChatGPT,丟一個 prompt,得到一段文字,我自己複製到公眾號後台,自己改、自己排版、自己配圖」。這種模式 AI 替我做了「寫」這一步,但「找資料、改、排版、配圖、發佈」這 5 個步驟還是我做。

「AI 把內容生產線全自動化」=「我說一句話,90 分鐘之後我得到一份可以直接複製粘貼到公眾號後台的成片」。這種模式 AI 替我做了所有非決策的環節,我只保留「選題決策」和「成片確認」這兩個不可替代的動作。

差別有多大?以前我一篇文章從選題到發佈,平均 6-8 小時;現在平均 90 分鐘,其中我自己花的時間不到 30 分鐘。

這套流水線怎麼搭起來的?

它不是一天搭起來的。我花了 4 個月反覆迭代,踩了大概 20 個坑,才把這套流水線穩定到「不用我盯」的程度。

下面我把這套流水線的 4 個核心模塊拆給你,你可以按自己的需求複製。

模塊一:研究層(Research Layer)

這一層的作用是「讓 Claude Code 在寫之前先變成專家」。

工具:Tavily MCP(主)、Web Search(輔)、自建知識庫(我的所有歷史文章)。

我自己有一個 /research 主題 命令,它做三件事:

第一,用 Tavily 搜近 30 天的最新動態——這一步保證文章的「時效性」。AI 模型的訓練數據是有截止時間的,任何最近 30 天的事它都不知道,必須搜。

第二,用 Tavily 搜「反向聲音」——任何主題都有人在吹、有人在踩。我會讓它專門搜「批評、反對、質疑」這類視角的內容。這一步保證文章不偏聽偏信。

第三,搜我自己歷史文章裏的相關內容——避免重複觀點、保持 IP 一致性。

三步跑完,我會得到一份「研究備忘錄」,大概 1500-2000 字,包含 10-15 條關鍵信息、3-5 個反向視角、5-8 個可引用的具體案例。

這份備忘錄就是文章的「彈藥庫」。

模塊二:寫作層(Writing Layer)

這一層的作用是「按我的風格寫,不是按 AI 的通用風格寫」。

工具:khazix-writing-style Skill(我自己開發的寫作 Skill)。

這個 Skill 裏寫了什麼?寫了我的 IP 全息檔案——

我的核心定位、我擅長的話題、我的語言節奏(短句多、對比多、數字多)、我的禁用詞(「賦能、抓手、閉環」這種空話一律不許出現)、我的金句習慣(每個章節至少一句加粗金句)、我的論證習慣(先舉具體例子再上升到原則)、我的收尾習慣(「與你共勉,做長期主義者」固定簽名)。

這份 Skill 總共 1200 行,我花了將近 30 個小時打磨。但它一旦穩定下來,我的所有文章都有同一個「人格」,讀者看 3 篇就能認出來這是六偉寫的。

寫作層啓動之後,Claude Code 會按這個流程走:

1. 看 brief 和研究備忘錄 2. 生成大綱(3-5 個章節,每個章節 800-1500 字) 3. 大綱給我看一眼(這是我中間介入的第 2 次) 4. 寫初稿(按大綱鋪,每段都對照風格 Skill) 5. 自檢一遍(對照風格 Skill 的紅線表打分,低於 80 分自動重寫)

這一步出來的初稿,我大概只改 5%-10%。

模塊三:配圖層(Image Layer)

這一層的作用是「讓文章不只是『字』,是『圖文混排的內容產品』」。

工具:Playwright(渲染)、article-illustrator Skill(畫圖)。

我的文章配圖分三種:章節頭、數據可視化圖、段落配圖。

章節頭是每章開頭的一張大圖,橫版、2400×520px、4× DPI,用純色背景 + 大數字 + 章節名。這個是 liuwei-layout Skill 的標誌性元素。

數據可視化圖是文章中有數據對比、流程圖、決策樹時用的圖。統一風格(淺色背景 + 蘋果字體 + 4-6 個色塊),用 HTML + CSS 渲染,然後 Playwright 截 4K PNG。

段落配圖是文章中間用來強調或破節奏的圖。這種圖我用得很剋制,一般 4000 字的文章只放 2-3 張,因為放多了會讓閲讀節奏變碎。

所有圖都必須 PNG 化、4K 化。為什麼?因為公眾號會過濾 HTML 裏的 CSS,任何用 div + 樣式畫出來的「卡片」「圖表」,粘到公眾號都會變成純文字。這是公眾號鐵律。

我自己踩過這個坑——有一次我做了一份很漂亮的「數據對比卡片」,div + flex 佈局,粘到公眾號變成了 6 行白字。從那次開始我立了鐵律:所有非純文字內容,必須 PNG 化才能交付。

模塊四:排版層(Layout Layer)

這一層的作用是「讓文章在公眾號裏好看」。

工具:liuwei-layout Skill(版式)、wechat-formatter Skill(渲染)。

公眾號排版的核心是 4 件事:

第一,字號和行距。公眾號正文用 16px,行距 1.85。比一般網頁大一些,因為公眾號有相當多讀者在手機上看,字號小了眼睛累。

第二,章節區分。我的版式用三種區分手段:章節頭大圖、章節標題用藍色、章節之間用「六偉公眾號 ————」橫線分隔。三重區分,讀者掃讀時不會迷路。

第三,強調點。每段 1-2 個加粗 + 藍色的關鍵詞,每章 2-3 句獨立金句段。強調點的密度要夠,但不能濫用——濫用強調等於沒強調。

第四,段落長度。公眾號段落必須短,1-3 行最佳,不能超過 5 行。原因還是手機閲讀——長段落在手機上是一面牆,讀者直接劃過。

這 4 層串起來的真實效果

我現在每週穩定發 3-4 篇公眾號長文。全部走這條流水線。

讓我量化一下這件事的槓桿——

寫作時間:從 6-8 小時 / 篇,壓到 90 分鐘 / 篇(其中我自己只花 30 分鐘)。

質量穩定性:之前 10 篇裏有 2-3 篇是「湊數」,現在 10 篇裏 8-9 篇能達到我自己滿意的水平。

產能上限:之前一週穩定 1-2 篇是極限,現在一週 3-4 篇還有富餘。 

學習成本:這套流水線我從零搭起來花了 4 個月,但任何一個非程序員都能在 2-3 周內復刻一套。

踩坑提示,這裏講三個——

第一,不要讓 AI 「替你思考選題」。

我嘗試過讓 Claude Code 「自動選題」,效果很差。AI 選出來的選題都是「安全但平庸」的——「AI 改變了什麼」「未來的趨勢」這種,沒有人格、沒有鋒芒、沒有具體性。

選題必須你自己定。你在洗澡時想到的、你跟朋友聊天時迸發的、你刷到某條信息時血脈賁張的——那才是好選題。AI 只能幫你執行,不能幫你定方向。

第二,初稿一定要你過一遍,不能直接發。

我見過有人完全相信 AI 出的初稿直接發,結果出過兩種事故:一是數據造假(AI 編了一個根本不存在的統計數據),二是觀點漂移(寫着寫着觀點變成了 AI 自己的常識,跟你的 IP 不一致)。

永遠要審稿。我自己審稿大概 15-20 分鐘,看三件事:數據真不真、觀點是不是我、語言節奏對不對。

第三,公眾號有圖片張數上限,要控制。

公眾號單篇文章圖片最多 50 張(具體看版本)。3 萬字的文章如果圖片用太密,會撞上限。

我的標準:每 1500-2000 字一張配圖。超過這個密度就太碎,低於這個密度就太乾。

場景四:爬蟲和數據入庫

背景:做內容、做競品分析、做行業研究,你天天需要扒數據。同行公眾號在寫什麼、競品產品在更新什麼、行業動態有什麼新東西。這些數據,沒有現成的接口,只能爬。

但「爬蟲」這個詞在大多數非程序員腦子裏是一道天花板——「這得會 Python 啊、得會反爬蟲啊、得搭代理啊」。

Claude Code 把這道天花板敲掉了。

指令示例:

「幫我爬一下某某競品的官網,看他們最近 3 個月的產品更新日誌,提取每個版本的更新內容,整理成 Excel,存到 ~/Outputs/competitor-updates.xlsx」

Claude Code 幹了什麼:

它會先打開那個網站,看看頁面結構。如果是簡單的 HTML,它用 requests + BeautifulSoup 就搞定。如果是 JS 渲染的,它會切到 Playwright(它知道該切)。如果遇到反爬蟲,它會自己加 User-Agent、加請求間隔、加 Playwright 的隱身模式。

整個過程它不會問你「我該用什麼庫」,它自己判斷。

踩坑提示:

第一,反爬蟲這個事 Claude Code 比你想象的更熟練。它知道怎麼偽裝 User-Agent、知道 Playwright 怎麼開 stealth 模式、知道哪些網站需要走真實瀏覽器。你不用懂這些,你只需要知道「告訴它你遇到了什麼問題」,它會換方案。

第二,爬之前問一句合規。這不是技術問題,是法律問題。讓 Claude Code 幫你看一下目標網站的 robots.txt 和服務條款,確認不是禁爬。

第三,爬完的數據要做去重和清洗。直接爬下來的數據是髒的,你需要讓它做一遍清洗才能用。這一步和場景一的數據清洗可以串起來。

進階玩法:

把爬蟲做成定時任務。我自己有一個腳本,每天早上 7 點自動跑,把當天 AI 圈的熱點新聞、競品動態、行業數據,自動彙總成一份『早報』,發到我的飛書機器人。

我每天起牀第一件事就是看這份早報,完全不用自己刷資訊。

這個就是從「手動爬一次」進化到「自動化每天爬」的關鍵。

場景五:代碼庫接管

這個場景寫給「有一點點基礎」的讀者。如果你完全不碰代碼,可以跳過這一節。

背景:你接手一個陌生項目,可能是別人離職留下的、可能是你自己很久沒動的、可能是開源項目你想改造一下。沒有文檔、沒有註釋、沒有人能問。

傳統姿勢是,你打開第一個文件,從頭讀起,讀到第 50 個文件你已經暈了。

Claude Code 的姿勢是,讓它先讀懂,你再動手。

指令示例:

「~/Projects/legacy-tool 這個項目我接手過來,你幫我做這幾件事:1)讀完整個項目,告訴我整體架構 2)主要的模塊和功能 3)入口在哪 4)有沒有明顯的代碼壞味道 5)如果我要加一個 XXX 功能,應該改哪些文件」

Claude Code 幹了什麼:

它會先掃一遍整個項目目錄,告訴你大概有多少文件、用什麼技術棧。然後它會進入 think 模式,逐個讀關鍵文件,最後給你一份「項目地圖」——架構圖、模塊清單、入口位置、關鍵文件、潛在問題。

這一份地圖,讓你「接手成本」從一週壓到一小時。

踩坑提示:

第一,think 模式不是默認開的。你需要明確說「認真讀、慢慢想」,或者在指令裏寫「think hard」「ultrathink」(對,這是 Claude Code 的隱藏指令)。普通模式它會跳讀,深度不夠。

第二,讓它輸出一份「項目地圖」文檔。這份文檔以後每次你打開這個項目都用得上。它本質就是一份事後補的 README。

第三,它的判斷你要 cross-check。AI 對陌生代碼的理解有時候會錯,關鍵判斷要你自己再確認。

進階玩法:

把「項目接管」做成一個 Slash Command。/onboard 項目路徑,自動出地圖。

更進階——出完地圖之後,讓它自動生成 CLAUDE.md。這個項目以後再讓 Claude Code 幹活,它就直接懂結構。

場景六:MCP 工具鏈

背景:Claude Code 自己是有邊界的,它只能讀你電腦上的東西、執行你電腦上的命令。但你的工作不只在電腦上——你的會議紀要在飛書、你的知識庫在 Notion(或者 Obsidian)、你的客戶在微信、你的日程在 Google Calendar。

MCP(Model Context Protocol) 就是把這些「電腦外的世界」接進 Claude Code 的協議。

指令示例:

我自己裝了這幾個 MCP——

「飛書 MCP」讓它能讀我的飛書文檔、發飛書消息。 「Obsidian MCP」讓它能讀寫我的知識庫。 「Excel MCP」讓它能直接操作 xlsx 文件。 「Playwright MCP」讓它能跑真實瀏覽器。 「Tavily MCP」讓它能搜實時網絡信息。

裝好之後,我的指令變成這樣——

「讀一下我飛書裏那篇《Claude Code 教程大綱》,按裏面的結構,幫我寫一篇 3 萬字文章,寫完存到 Obsidian 的 『公眾號草稿』 文件夾。」

Claude Code 幹了什麼:

它調飛書 MCP 讀文檔 → 在 Claude Code 裏寫文章 → 調 Obsidian MCP 把結果存進去。整個流程不用我打開任何一個 App,不用我複製粘貼任何一段文字。

踩坑提示:

第一,MCP 不是裝得越多越好。每個 MCP 都會佔上下文 token,裝太多反而拖慢決策。我自己常駐就 5 個,臨時用的隨用隨裝。

第二,MCP 的權限要單獨配。飛書 MCP 默認只有讀權限,你要給它寫權限要在飛書後台手動開。這一步很多人忘記,導致它能讀不能寫,以為是 bug。

第三,自建 MCP 的成本不高,但臨界點要算。如果某個工具你每天用 3 次以上,值得自建。每天用 1 次以下,用現成的開源 MCP 就行。

進階玩法:

MCP 可以串成工作流。比如「飛書消息觸發 → Claude Code 處理 → Obsidian 存檔 → 微信通知」,這一串可以做成一個全自動的「會議紀要管家」,你開完會,會議紀要、行動項、跟進任務,十分鐘之內全部就位。

場景七:多 Subagent 並行任務

最後一個場景,也是最炫的一個。

背景:有些任務是「一個 Agent 幹不完」的——比如「寫一篇 3 萬字帶配圖帶排版的文章」。這種任務裏有「寫作」「配圖」「排版」「質檢」四個完全不同的子任務,讓一個 Agent 全乾,它要麼累死要麼亂套。

Subagent 系統的核心思路是——主 Agent 當總指揮,子 Agent 各管一攤。

指令示例:

「這篇文章我用『多 Agent 模式』搞定。Orchestrator 協調,Writer Agent 寫正文,Designer Agent 出配圖,Layouter Agent 排版,Reviewer Agent 做最後質檢。」

Claude Code 幹了什麼:

它會自動啓動 4 個 Subagent,每個 Agent 都有獨立的上下文窗口(這一點是關鍵,意味着它們不互相污染)。

主 Agent 把任務拆解、分發、收集結果、做總結。

我自己測過,這種 4-Agent 並行模式,完成一篇帶配圖帶排版的文章,效率比單 Agent 模式快 60%,token 消耗低 40%。

為什麼 token 還能低?因為每個 Subagent 的上下文只裝它需要的部分,沒有「寫作上下文」污染「排版上下文」,所以每次調用都精準、短、便宜。

踩坑提示:

第一,不要瞎用 Subagent。如果任務可以一個 Agent 搞定,就不要拆。拆 Agent 的成本是「協調」,只有任務足夠複雜時才划算。

第二,Agent 之間要按「上下文邊界」拆,不要按「功能邊界」拆。功能邊界是「這是寫代碼、那是改 Bug」,上下文邊界是「這兩個事用到的資料不一樣、需要的偏好不一樣」。後者才是 Subagent 真正發揮威力的地方。

第三,主 Agent 要負責「收尾」。每個 Subagent 幹完之後,主 Agent 要把結果整合、檢查一致性、做最後輸出。不要讓 Subagent 直接交付,中間一定要有個總指揮。

進階玩法:

把多 Subagent 工作流做成模板,固化下來。我自己有一個「內容生產流水線」,叫 OpenClaw,就是 6 個 Subagent 串起來的——選題、寫作、配圖、排版、審核、發佈。

從早上 8 點出選題,到下午 5 點文章發佈,中間我只需要確認兩次:選題選哪個、文章定稿沒問題。其他的全是 Agent 幹。

這就是「一人 AI 公司」的真實工作流。

我把多 Subagent 這件事拆開講——這是 Claude Code 這個工具裏最被低估的能力,也是非程序員最容易學的「進階玩法」。

為什麼說「最被低估」?

絕大多數 Claude Code 的入門教程,講到「讓 AI 寫一段代碼」就停了。但 Claude Code 真正的殺手鐧,是它原生支持「多 Agent 並行」——你能在一個 Claude Code 會話裏啓動多個獨立的子 Agent,每個 Agent 都有自己的上下文窗口、自己的工具權限、自己的任務邊界。

這個能力對程序員來說不算太稀奇——他們以前用過 LangGraph、AutoGen 這些框架。但對非程序員來說,這是個革命:你能在不寫一行代碼的前提下,搭出一套「多人協作」的 AI 工作流。

舉一個真實例子:OpenClaw 是怎麼搭起來的?

OpenClaw 是我的內容生產系統的代號(取自小龍蝦的英文 craw,大家開玩笑叫它"小龍蝦"),它本質就是一套多 Subagent 工作流。

它包含 6 個 Subagent——

1. 秘書 Agent(Secretary) 負責日程、提醒、信息彙總。它是入口——我所有的事都先跟秘書 Agent 說,它分發給下面的幾個 Agent。

2. CEO Agent(決策層) 負責「這件事該不該做、什麼時候做、優先級多少」。它是決策層——任何需要判斷價值、判斷時機的事,都過這個 Agent。

3. 內容工廠 Agent(Content Factory) 負責公眾號、視頻號、小紅書的內容生產。它是流量層——每天的內容產出都由它驅動。

4. 課程開發 Agent(Course) 負責訓練營、百萬俱樂部的課程內容。它是產品層——所有跟「教學」相關的內容都在這裏沉澱。

5. 商業交付 Agent(Delivery) 負責給企業客戶做 AI Agent 交付的項目。它是項目層——跟具體客戶、具體項目相關的事都在這裏。

6. 文案 Agent(Copy) 負責朋友圈、小綠書、視頻號文案、廣告文案這類「短文案」。它是營銷層——跟「讓人看到、讓人感興趣、讓人轉化」相關的事都在這裏。

這 6 個 Agent 怎麼協作?

關鍵是「主 Agent 當總指揮」的設計。

我自己作為「總用戶」,只跟一個 Agent 說話——也就是 Claude Code 主會話。主會話會根據我的需求,判斷該啓動哪幾個 Subagent、按什麼順序、用什麼參數。

舉個例子,我說一句:

「下週二要開一期訓練營,主題:Claude Code 實戰。幫我搞定從招生到開課的全部內容。」

主 Agent 接到這個任務後,會自動拆解成 5 個子任務——

1. 課程開發 Agent:基於訓練營主題,搭課程大綱、寫 PPT、寫講師 brief。 2. 內容工廠 Agent:寫 3 篇公眾號預熱文章(招生文 + 答疑文 + 倒計時文)。 3. 文案 Agent:出 5 條朋友圈營銷文案、3 條視頻號腳本。 4. 商業交付 Agent:把訓練營的服務流程、退費規則、羣運營 SOP 整理好。 5. CEO Agent:最後審核所有產出,給我一份『發佈前 checklist』。

這 5 個 Agent 並行啓動,各幹各的。大概 30-45 分鐘之後,所有產出彙總到主 Agent 那裏,我只需要審最終交付物。

以前我開一期訓練營的「內容準備」要花 3-5 天,現在半天搞定。

這套架構的關鍵設計原則——

我把多 Subagent 設計的「5 個原則」總結給你,這是我踩了無數坑總結出來的——

原則一:上下文邊界 > 功能邊界

很多人拆 Agent 是按「功能」拆——「這個負責寫、那個負責改、那個負責審」。這是錯的。

按功能拆 Agent,你會發現每個 Agent 都要看一遍同樣的資料、記同樣的偏好,上下文嚴重重複,token 翻倍但效率沒翻倍。

按「上下文邊界」拆,意思是——這個 Agent 用的資料、規則、偏好,跟另一個 Agent 完全不一樣。比如「內容工廠」用的是公眾號風格 Skill,「文案 Agent」用的是短文案的 Skill,這兩套規則是衝突的(公眾號要長、要穩;短文案要短、要爆)。必須拆開,否則 Agent 會精神分裂。

原則二:每個 Agent 必須有「人設檔案」

Subagent 的本質,是給一個通用 Claude 模型「裝上一個特定角色」。這個角色裝得越精細,Agent 幹活越靠譜。

我自己的每個 Agent 都有一份「人設檔案」(本質是一份 CLAUDE.md),包含 5 個部分——

1. 它是誰(秘書 / CEO / 內容工廠...) 2. 它幹什麼(職責範圍、不該幹什麼) 3. 它用什麼工具(允許調用哪些 MCP、哪些 Skill、哪些 Slash Command) 4. 它的輸出標準(格式、字數、風格) 5. 它的紅線(絕對不能做什麼)

人設檔案越細,Agent 的「不可替代性」越強——你換個模型,它該怎麼幹還是怎麼幹。

原則三:主 Agent 只做協調,不做執行

很多人犯的錯是「主 Agent 既協調又執行」——主 Agent 一邊分發任務,一邊自己也在寫、改、審。這樣會讓主 Agent 的上下文嚴重過載,最後 Agent 系統整體崩盤。

正確的做法是,主 Agent 只做三件事:拆解任務、分發任務、整合結果。具體的「寫、改、審」全部交給 Subagent。

我自己有一個規矩:主 Agent 的指令長度,不超過 200 字。這是一個硬約束,迫使我把「執行」的部分推給 Subagent。

原則四:Subagent 之間不直接通訊

非常多人犯的錯,是讓 Subagent 之間互相調用——「內容工廠 Agent 調用文案 Agent 出朋友圈」。

這樣會讓鏈路爆炸。一旦 Subagent 之間有耦合,你想換掉任何一個 Agent 都要改一堆聯動。

正確的做法是,所有 Subagent 都只跟主 Agent 通訊。Subagent 之間互不知道彼此存在。這樣任何一個 Agent 都可以獨立換、獨立升級,整個系統的解耦性極強。

原則五:每次任務結束,主 Agent 必須輸出「執行報告」

這是質量控制的關鍵。

每次多 Subagent 任務跑完,主 Agent 必須輸出一份「執行報告」——包含:啓動了哪幾個 Agent、每個 Agent 輸出了什麼、有沒有失敗、token 消耗了多少。

這份報告我自己每次都會掃一眼,主要看「token 消耗」——如果某個 Agent 消耗異常高,說明它的任務設計不合理,需要拆。

這是我用了 4 個月才悟出來的「持續優化方法」。沒有報告,你就是黑盒;有了報告,Agent 系統才能持續進化。

最後,一個反常識的提醒——

不是所有任務都該用 Subagent。

我自己的標準是:只有同時滿足以下 3 個條件,才用 Subagent——

1. 任務複雜度足夠(單 Agent 上下文會爆) 2. 子任務有清晰的上下文邊界(不是簡單的功能拆分) 3. 子任務可以並行(如果只能串行,用 Slash Command 鏈更划算)

不滿足 3 條的任務,用單 Agent + Slash Command 就夠了。

「為了用 Subagent 而用 Subagent」是新手最常犯的錯。

我自己一開始也犯過——什麼任務都拆 Subagent,結果 token 消耗翻倍、調試成本翻倍、整體效率反而下降。

工具的邊界感,比工具本身更重要。

7 個場景講完。

你會發現,這 7 個場景裏只有「場景五:代碼庫接管」是真正跟編程相關的。其他 6 個,Excel、內容、爬蟲、PRD、MCP、Subagent,沒有一個需要你會寫代碼。

這就是我一開始說的——Claude Code 給非程序員的潛力,是程序員視角看不到的 90%。

下一章,我們講一個所有人都會遇到的問題:為什麼 Claude Code 用着用着就變傻了?

六偉公眾號 ————————————————————

為什麼 Claude Code 用着用着就變傻了

我先說一個反直覺的事。

Claude Code 「變傻」這件事,90% 不是它笨,是你沒管好它的記憶。

新手最常見的劇本是——開始用的時候,覺得這玩意太聰明瞭,跟它聊得不亦樂乎,一個會話從早開到晚,從這個項目聊到那個項目,結果聊到下午,它開始忘事、開始重複犯錯、開始答非所問。

你的判斷是,「這玩意不行,變笨了」。

真相是,你的上下文窗口滿了。

上下文窗口是 AI 的「工作記憶」,所有它「當下知道」的東西,都在這個窗口裏。

Claude 4.7 的上下文窗口是 200K token,聽起來很大,但你架不住一個會話裏塞了 30 個文件、20 段對話、500 行歷史記錄——很快就滿了。

滿了之後會發生什麼?它開始「記憶污染」。

什麼意思?當上下文塞太滿,關鍵信息會被淹沒在大量不相關的內容裏。AI 在做決策時,它可能用到的是 30 分鐘前你隨口說的一句話,而不是 5 分鐘前你明確的指令。

你以為它沒聽懂,其實它聽懂了,但它「記錯了」。

這一章我會講四件事:什麼時候該 /clear、任務邊界怎麼切、關鍵結論怎麼沉澱、長任務怎麼續接。

第一件事,/clear 的正確使用時機。

/clear 是 Claude Code 內置的清屏指令。它會把當前會話的上下文清空,只保留 CLAUDE.md。

什麼時候該 /clear?

我的判斷標準是——當你從一個任務切到另一個不相關的任務時,立刻 /clear。

比如,你上午讓它清洗了一份 Excel,下午要讓它寫一篇文章。這兩件事完全沒關係,Excel 那部分上下文留着只會干擾文章寫作。直接 /clear,從頭開始。

很多人不願意 /clear,因為覺得「前面聊了那麼多,清掉可惜」。這是個誤區。

前面聊的那些內容,該沉澱的應該已經沉澱進 CLAUDE.md,沒沉澱的說明它本來就不值得保留。

記住這一點,/clear 不是浪費,是必需。

第二件事,任務邊界切割原則。

我自己的原則是,一個獨立任務,開一個新會話。

什麼算「獨立任務」?完成它需要的上下文,跟其他任務沒有重疊,就是獨立任務。

比如,「清洗 Excel」「寫文章」「跑爬蟲」「做 PPT」,這四件事之間沒有任何信息重疊——清洗 Excel 用到的反饋數據,跟寫文章用到的 Tavily 搜索結果,沒有任何關係。

所以這四件事應該開四個不同的會話(或者一個會話裏每次切換都 /clear)。

反例是什麼?

「寫一篇文章,然後基於這篇文章生成一個朋友圈」——這兩件事是有信息重疊的(都需要這篇文章的核心觀點),所以這兩件事在同一個會話裏做更高效。

判斷的關鍵不是「任務類型像不像」,是「它們需要的資料有沒有重疊」。

第三件事,關鍵結論要提煉進 CLAUDE.md。

我前面說過,會話記憶是臨時的,關掉就丟。

但有些事是「你不希望每次都重新說一遍」的——比如你的偏好、你的工具鏈、你踩過的坑、你的常用路徑。

這些事,永遠不要依賴會話記憶,該寫進 CLAUDE.md 的必須寫進去。

我自己的習慣是,每次跟 Claude Code 協作,如果出現了一個「以後還會用到的判斷 / 偏好 / 規則」,我會立刻讓它幫我加到 CLAUDE.md。

指令長這樣——

「這個判斷不錯,你加到 CLAUDE.md 的『歷史犯錯記錄』裏,一句話總結就行。」

這種「即時沉澱」的習慣,讓我的 CLAUDE.md 一直在長,但永遠是「我親自審過的」。

第四件事,長任務用 --resume 續接,不要重新開。

有時候你在做一個超長任務,比如「讀完 50 個 PDF 提取關鍵信息」。這種任務可能跑到一半上下文就滿了。

新手的姿勢是,「啊上下文滿了,我開個新會話重新讓它做吧」——這一開新會話,前面的進度全丟了,token 全白燒。

正確姿勢是 /compact 或 --resume。

/compact 是 Claude Code 的「上下文壓縮」指令。它會自動把當前對話壓縮成一份摘要,騰出空間繼續幹。

--resume 是「續接」模式,你下次啓動 Claude Code 時,它能接着上次的進度繼續。

這兩個指令是新手最容易忽略的,但它們的實際省錢效果非常大。

最後講一個比喻,這一章的核心你只要記住這一句話——

上下文窗口像內存,CLAUDE.md 像硬盤。重要的東西永遠寫硬盤,不要堆在內存裏。

理解了這個比喻,你的 Claude Code 就再也不會「變傻」了。

不是它笨,是你沒管好它的記憶系統。

下一章,我們從「用工具」進化到「建系統」——講 Hooks 和 Subagents。

六偉公眾號 ————————————————————

從「用工具」到「建系統」

前 5 章講的都是「怎麼用」,這一章講「怎麼建」。

這是 Claude Code 真正的護城河——它不只是一個聰明的工具,它是一個可以讓你『建工廠』的平台。

講兩個核心概念,Hooks 和 Subagents。

先講 Hooks。

Hooks 翻譯過來是「鈎子」,它的作用是在 Claude Code 幹活的某些關鍵節點,自動插入你預設的動作。

比如,「每次它要寫文件之前,自動給我備份一份」「每次它要跑命令之前,自動檢查這個命令安不安全」「每次它幹完一件事,自動 commit 到 git」。

Hooks 的核心價值是——給 Claude Code 裝護欄。

我前面說過,新手不要開 --dangerously-skip-permissions,因為你不知道它什麼時候會亂來。

但等你裝好 Hooks 之後,你可以放心開 skip-permissions,因為護欄幫你兜底。

Hooks 有兩種觸發時機——

PreToolUse,工具調用之前觸發。比如它要寫文件,先經過你的檢查。 PostToolUse,工具調用之後觸發。比如它寫完文件,自動備份。

我自己用的最多的一個 Hook:

# 每次寫文件前,如果是已存在的文件,自動備份
PreToolUse(Write|Edit) {
  if file_exists($path):
    cp $path ~/.claude-backup/$(date +%Y%m%d_%H%M%S)_$path
}

就這一個 Hook,讓我在用了一年 Claude Code 之後,從來沒丟過一份文件。

哪怕它某次腦抽把我重要文件覆蓋了,我也能從備份裏撈回來。

Hooks 的另一個高級用法是「自動質檢」。

比如,Claude Code 寫完一份公眾號文章 HTML,我有一個 PostToolUse Hook,自動跑 grep 檢查 5 條紅線(章節塊殘留、position:absolute 殘留、base64 圖片數量、4K 清晰度、display:grid 殘留)——任何一條不通過,自動打回。

這一個 Hook,讓我從來沒把不合格的文章交付出去過。

這就是從「用工具」進化到「建系統」的第一步——把質量標準固化進 Hooks。

再講 Subagents。

Subagents 我前面第四章場景七已經講了一部分,這裏再深入。

Claude Code 內置了 3 個基礎 Agent——

Explore Agent,探索類任務用,擅長「讀懂一個新項目」。 Plan Agent,規劃類任務用,擅長「拆解一個複雜目標」。 通用 Agent,執行類任務用,默認 Agent。

但真正強大的是「自定義 Subagent」。

自定義 Subagent 怎麼寫?你只需要寫一份 Markdown。

一份 Subagent 的 Markdown 長這樣——

---
name: writer-agent
description: 公眾號文章寫作專家。
當用戶需要寫長文、寫公眾號、產出 4000 字以上內容時使用。
---

# 你是一個公眾號寫作 Agent

## 你的工作流
1. 接到主題之後,先調 Tavily 搜近一週的相關動態
2. 按 khazix-writing-style 的規則寫
3. 字數硬性要求 4000 字以上
4. 寫完做四層自檢

## 你的偏好
- 不用「總的來說」
- 不加 emoji
- 章節大數字 01/02/03

## 輸出
Markdown 格式,放到 ~/Outputs/articles

就這麼一份 Markdown,放到 ~/.claude/agents/ 目錄,Claude Code 就多了一個「Writer Agent」。

下次你說「幫我寫一篇文章」,主 Agent 會自動調用這個 Writer Agent,完成所有細節。

Subagent 的核心威力,在於它有獨立的上下文窗口。

什麼意思?

我前面講過,上下文塞太滿會污染判斷。但 Subagent 不會——每個 Subagent 是一個完全獨立的「Claude 實例」,它的上下文窗口是空的,你給它什麼它知道什麼。

這意味着——你可以讓一個 Subagent 專心做一件事,完全不受其他事幹擾。

我自己有 6 個常用 Subagent——

Writer,專門寫文章 Designer,專門做配圖 Coder,專門寫代碼 Researcher,專門查資料 Reviewer,專門審稿 Architect,專門做技術方案設計

一個複雜任務來了,主 Agent 自動判斷該調哪幾個 Subagent,分工幹活,最後彙總。

這就是 OpenClaw 的底層架構。

最後講一個進階概念——Agent Development Kit(ADK)。

如果 Hooks 是裝護欄,Subagent 是組團隊,那 ADK 就是「整套工程化體系」。

一個完整的 ADK 項目,有這 5 個文件夾——

my-claude-project/
├── CLAUDE.md          # 你和 AI 的契約
├── skills/            # 你的技能庫(寫作風格、排版規範等)
├── hooks/             # 你的護欄(備份、質檢、git 提交等)
├── subagents/         # 你的團隊(Writer、Designer 等)
└── plugins/           # 你的工具(MCP、自定義命令等)

把這 5 個文件夾搭起來,你就從「會用 Claude Code 的人」進化成了「在管 Claude Code 團隊的人」。

我自己的 ADK 項目叫 OpenClaw,6 個 Subagent + 70 個 Skill + 20 個 Hook + 12 個 MCP,組合起來就是我的「一人 AI 公司」全部底層基礎設施。

從「用工具」到「建系統」,這一步是 Claude Code 跟所有其他 AI 工具的真正分水嶺。

而這一步,大多數人壓根就沒意識到。

下一章,我們離開「技術」,聊一個更重要的事——SOUL 大於 Skill。

六偉公眾號 ————————————————————

真正的護城河在哪裏

這一章不講技術,是全文最重要的一章。

我先講一個最近發生的事。

OpenAI 前段時間推出了一個叫「Switch to Codex」的工具,作用是把你在 Claude Code 裏的配置、記憶、Skill,一鍵遷移到 OpenAI 的 Codex CLI。

很多人看了這個新聞第一反應是,「啊 OpenAI 來搶市場了,Claude Code 危險了」。

我看完第一反應不一樣。

OpenAI 推「Switch to Codex」,本質是承認了一件事——用戶在 Claude Code 裏積累的東西,已經形成了遷移成本。

什麼東西?

不是 Claude Code 這個工具本身。是你的 CLAUDE.md、你的 Skill 庫、你的 Subagent、你的 Hooks、你訓練出來的那個「懂你的 AI」。

這些東西,才是用戶的真正資產。

OpenAI 用「一鍵遷移」來降低用戶切換成本,反過來證明了——這個東西本來就不好切換。

這就是我說的——SOUL 大於 Skill。

什麼是 SOUL?

Skill 是「能力」——你會寫代碼、你會做 PPT、你會用 Excel。 SOUL 是「靈魂」——你的偏好、你的判斷、你的風格、你的工作流、你的知識庫、你訓練 AI 的方式。

Skill 可以被替代。任何一個 AI 工具都能寫代碼、做 PPT、用 Excel,而且做得一年比一年好。

SOUL 不可替代。因為它是你自己的靈魂——你這一年踩過的坑、積累的判斷、形成的偏好、寫過的 CLAUDE.md、訓練過的 Subagent。

你用 Claude Code 三個月之後,你擁有的是什麼?

第一,一份記錄了你所有思維習慣的 CLAUDE.md。 第二,一套針對你業務場景的 Skill 庫。 第三,一個越來越懂你的 AI 搭檔。

這三個東西,換一個工具不會自動出現。你的 CLAUDE.md 寫給 Claude 的,Codex 不一定完全兼容;你的 Skill 是基於 Claude Code 的協議寫的,遷移過去要重寫一半;你訓練出來的那個「懂你的 AI」,本質上是你跟 Claude 的關係,遷移工具搬不過去。

這就是為什麼我說,工具會被替代,但你訓練出來的 AI 不會。

我再講一個更深的層面。

大多數人對 AI 的理解還停留在「會用 AI」這個層級——會問問題、會寫 Prompt、會用工具。

但「會用 AI」這件事,正在迅速貶值。

因為模型越來越聰明、產品越來越好用,「會用」的門檻會一年比一年低。今天「會用 Claude Code」是稀缺技能,兩年之後,「會用 Claude Code」會跟「會用 Word」一樣,人人都能。

那時候,你的真正壁壘在哪?

在於你有沒有把自己「灌」進 AI。

我把這件事叫做「有一個 AI 版本的你」。

什麼意思?

我現在的工作流裏,有一個 Subagent 叫 Writer Agent,它寫出來的文章,90% 像我親自寫的。不是它學會了「我的寫作風格」那麼簡單,是它知道我喜歡什麼角度切、不喜歡什麼禁忌詞、習慣怎麼文化升維、慣用哪些口語化表達。

這個 Writer Agent,就是「AI 版本的我」。

它的靈魂,來自我這一年餵給它的——

我每篇文章寫完之後,給它的修改批註。 我每次說「這段不行」,告訴它「不行在哪」。 我每次踩坑之後,寫進 khazix-writing-style 的禁用規則。 我每次發現一個好的寫法,沉澱進 Skill 的「推薦口語化詞組」。

這一年我做的事,本質上就是在『訓練一個 AI 版本的我』。

而這個「AI 版本的我」,不在 Claude Code 裏,也不在 OpenAI 裏。它在我的 CLAUDE.md 裏,在我的 Skill 庫裏,在我的 Subagent 裏。

這些東西,我換任何一個 AI 工具,都能帶走。

這就是 SOUL 的護城河。

最後講一個判斷。

未來 3 年,AI 行業會發生一件事——模型層、工具層會高度同質化。

Claude、GPT、Gemini、DeepSeek、Qwen,它們之間的差距會越來越小。

Claude Code、Codex、Cursor、Cline,它們之間的差距也會越來越小。

所以「用哪個工具」這件事,會越來越不重要。

那什麼重要?

你有沒有訓練出『一個 AI 版本的你』——這件事會越來越重要。

而訓練「AI 版本的你」,今天 Claude Code 是最好的載體。不是因為 Claude 最聰明(雖然它確實很聰明),是因為 Claude Code 的整套體系(CLAUDE.md + Skill + Subagent + Hook + MCP)是目前所有 AI 工具裏最完整的。

你今天在 Claude Code 上積累的每一行 CLAUDE.md、每一個 Skill、每一個 Hook,未來都可以遷移到任何一個 AI 平台。

訓練營要教的,不是讓你「會用 Claude Code」。是讓你「有一個 AI 版本的你」。

這個目標,跟工具無關。

工具是載體,你才是核心。

下一章,講一個最具體的事——我自己一天是怎麼用 Claude Code 的。

六偉公眾號 ————————————————————

我自己一天是怎麼過的

講完認知、講完技術、講完心法,最後一章講最具體的——我自己一天 24 小時,Claude Code 在哪幾個時間點出現、幹什麼事、用什麼指令。

這是我從早 8 點到晚 11 點的真實工作流,沒有美化、沒有簡化、也不藏私。

先說配置層級。

我給非程序員朋友推薦兩個配置檔位——

最小可用配置,月成本控制在 500 元以內。

只要一個 Claude API + Claude Code 本體 + 3 個核心 MCP(Excel、Playwright、Tavily)。這個配置夠你跑 80% 的日常任務,包括數據清洗、內容生產、網頁爬取、文件操作。

進階配置,月成本 1000-2000 元。

在最小配置基礎上加幾個東西——飛書 MCP(對接會議)、Obsidian MCP(對接知識庫)、Notion MCP(如果你用 Notion)、微信 MCP(對接公眾號草稿箱)、Slack/Telegram MCP(對接團隊/社羣)。

這個配置,能把你的全部內容生產 + 知識管理 + 團隊協作鏈路打通。

我自己用的是進階配置,月成本大概 1500 元。

下面是我一天的真實時間軸。

早上 8:00 - 起牀早報

我起牀第一件事不是看手機,是看飛書機器人推送的『AI 早報』。

這份早報是 Claude Code 在凌晨 7:30 自動生成的——它跑了 Tavily 搜索、抓了我關注的 20 個公眾號、整理了知乎熱榜,最後彙總成一份 5 分鐘能讀完的早報。

我看完早報,大概就知道今天 AI 圈發生了什麼、今天的寫作選題有沒有候選。

早上 8:30 - 選題決策

如果早報裏出現了我想寫的話題,我直接開 Claude Code,跑選題決策。

指令長這樣——

「我看了今天的早報,覺得『XXX』這個話題有意思。你幫我從『一人 AI 公司』的角度,出 3 個寫作切入點,每個切入點給一個備選標題,我從裏面選一個。」

90 秒之後,3 個切入點擺在我面前。我選一個,然後說「按這個寫」。

Writer Agent 啓動,我去洗漱、吃早飯、跑步。

上午 10:00 - 文章定稿

跑完步回來,文章初稿已經躺在那。

我從頭讀一遍,標紅需要改的地方,指令長這樣——

「這裏太繞了,改簡潔。這裏舉的例子換一個,用『XXX』這件事。這裏的金句不夠炸,再想 3 個備選。整體節奏 ok,不用大改。」

來回 2-3 輪,文章定稿。Designer Agent 接力,出配圖。Layouter Agent 接力,出公眾號 HTML。

我去吃午飯。

中午 12:30 - 文章發佈

吃完飯回來,公眾號 HTML、封面、4K 配圖,全部躺在 outputs 目錄,等我審最後一遍。

我審完,直接複製粘貼到公眾號後台,定時下午 5 點發布。

全程從「看到選題」到「文章發佈」,大概 4 小時,我自己實際投入 1 小時。

下午 2:00 - 客戶諮詢

下午開始處理客戶諮詢。

我有一個 Subagent 叫 「Consultant Agent」,它跑在我的飛書機器人裏——學員問問題,先經過 Consultant Agent 過一遍,常見問題它直接答(基於我之前的所有回覆,它學會了我的回答風格),複雜問題它整理後轉給我。

我下午的工作,基本上就是處理 Consultant Agent 轉上來的「複雜問題」。

這一招讓我處理學員諮詢的時間從每天 3 小時壓到 1 小時。

下午 4:00 - 智能體開發

下午一段時間用來推進 OpenClaw 的開發。

我自己不會寫代碼,但是我會描述需求。

指令長這樣——

「OpenClaw 的 Writer Agent 最近寫出來的開頭不夠炸,你幫我看下 prompt,找一下原因。如果是 prompt 的問題,改一下。如果是 Skill 規則的問題,改 Skill。改完跑一下測試。」

Claude Code 自己讀代碼、自己定位問題、自己改、自己測。我只需要看最後的結果。

這種『需求 → 代碼』的鏈路,讓我一個不會寫代碼的人,做出了 70+ 個 Skill 和 6 個 Agent。

晚上 7:00 - 數據回收

晚飯後,我跑一次「當日數據回收」。

指令長這樣——

「跑一下今天的數據回收:1)公眾號今天的閲讀、在看、轉發 2)訓練營今天的新增報名 3)百萬俱樂部今天的諮詢數 4)彙總成一張圖,發到飛書。」

Claude Code 自己去後台爬數據(那些有 API 的)、自己讀飛書消息(沒有 API 的)、自己彙總、自己出圖、自己發。

我看完圖就知道今天哪個動作有效、哪個動作沒效。

晚上 9:00 - 覆盤和沉澱

睡前最後一個時段,我會跟 Claude Code 做一次覆盤。

指令長這樣——

「今天我們一起幹了這幾件事:寫文章、改 Agent、回學員、做數據。你幫我覆盤一下,哪些地方你覺得我處理得不夠好、哪些地方我們可以做得更高效。如果有可以沉澱到 CLAUDE.md 的判斷,直接幫我加上。」

它會給我一份「覆盤報告」,包括我今天的低效環節、可以優化的工作流、新發現的偏好。

覆盤完,它會自動把今天的新判斷、新偏好、新規則,加到 CLAUDE.md。

第二天的 Claude Code,就比今天的更懂我一點。

晚上 11:00 - 關機

關機前,Claude Code 不睡。它會跑一個夜間任務,生成明天的早報,準備明天的素材庫,跑一次 Skill 庫的 backup**。

第二天早上 8 點,新的早報已經躺在飛書裏等我。

循環開始。

講完一天 7 個節點的時間軸,我再補兩段你最容易忽略的關鍵內容——配置檔位的真實賬單、和我自己用了 4 個月才悟到的「最高 ROI 動作」。

配置檔位的真實賬單

我前面說「最小配置月成本 500 元、進階配置 1000-2000 元」,這是粗口徑。下面我把我自己的真實賬單拆給你看,精確到每一項——

Claude API 訂閲(Pro 月費):約 ¥150(按當前匯率算)。

這是核心成本。我用的是 Claude Pro,無限對話 + 優先模型 + Claude Code 包含在內。對一人公司來說,這一項是「水電費」級別的必須開支。

注意:Claude Pro 不能用國內信用卡直接付,需要用支持境外消費的卡(招行 Visa、Mastercard 這類)。這是我幫很多學員踩過的第一個坑。

API 額外消費(超過 Pro 配額時):月均 ¥200-400。

我每個月會跑一些 Pro 之外的高頻任務——比如多 Subagent 工作流、批量數據清洗、夜間自動早報等等。這些超出 Pro 的對話量,走 API 計費,按 token 單價。

我的 token 消耗,主要在 Sonnet 4.7 (¥3/百萬 input,¥15/百萬 output),少部分在 Opus 4.6 (¥15/百萬 input,¥75/百萬 output)。

按月均算,多花 ¥200-400 在 API 上,合計 ¥350-550。

MCP 服務(部分要單獨付費):月均 ¥0-100。

大部分 MCP 是免費開源的(飛書 MCP、Obsidian MCP、Excel MCP、Playwright MCP 都免費)。只有 Tavily MCP 要訂閲,基礎版 ¥0,進階版約 ¥30/月。我自己用進階版。

第三方 API(可選):月均 ¥50-200。

比如某些 OpenAI API、某些 SerpAPI、某些圖像處理 API。這些是按需用的——有任務才花錢,沒任務零成本。

合計真實月成本——

最小配置(只用 Claude Pro):¥150/月 進階配置(Pro + API + MCP):¥400-800/月 重度使用(我自己):¥1000-1500/月

這個賬單告訴你什麼?

告訴你「一人 AI 公司」的固定成本極低——每月不到一杯精品咖啡的錢(¥150),就能跑起來最小可用配置。

我以前僱過一個內容編輯,月薪 8000。她的產出是每週 1-2 篇公眾號長文。

我現在用 Claude Code + 我自己,每週穩定 3-4 篇公眾號長文,成本不到原來的 1/50。

這不是「替代員工」的故事——是「成本結構整體重構」的故事。這才是這個時代真正的紅利。

「最高 ROI 動作」是什麼?

如果只讓我推薦一個動作——只學一招、只做一件事,就能讓你的 Claude Code 使用效率翻倍,我會選哪一個?

不是學 Subagent、不是學 MCP、不是學 Skill。

是「每週一次的 CLAUDE.md 覆盤」。

聽起來很無聊?這個動作的槓桿係數,是其他動作的 5-10 倍。

我給你講清楚——

為什麼 CLAUDE.md 覆盤是槓桿點?

因為 Claude Code 跟你協作的「友好度」,幾乎完全由 CLAUDE.md 的質量決定。

第三章我講過——CLAUDE.md 是 Claude Code 的「記憶」。它知道你是誰、你的偏好、你的紅線、你的工具棧。沒有 CLAUDE.md,Claude Code 每次都是一個陌生人;有了 CLAUDE.md,它每次都是一個跟你共事很久的老朋友。

但是,CLAUDE.md 不是一次寫完就完事的。它必須每週更新。

為什麼?因為你每週都在變——你學了新工具、你形成了新偏好、你踩了新坑、你建立了新紅線。這些變化,如果不沉澱到 CLAUDE.md,就會丟失。

而「每週覆盤」就是把這一週的變化,系統性沉澱到 CLAUDE.md 裏。

覆盤怎麼做?

我自己的標準動作,每週日晚上 9-10 點之間,半小時,跟 Claude Code 一起做。

指令長這樣——

「我們做一次本週覆盤。看一下這一週我們一起幹了哪些事,回答 5 個問題:

1)這一週我重複犯過什麼錯?(說明 CLAUDE.md 裏漏了某條紅線)

2)這一週我用了哪些新工具或新 Skill?(說明 CLAUDE.md 裏漏了某項工具說明)

3)這一週我反覆糾正過你哪些行為?(說明 CLAUDE.md 裏漏了某項偏好)

4)這一週我做得最爽的 3 件事是什麼?(找出可以固化成 Slash Command 的工作流)

5)這一週我做得最鬱悶的 3 件事是什麼?(找出可以讓你接管的環節)

>

回答完之後,根據這些答案,直接幫我更新 CLAUDE.md。改完給我看 diff,我確認。」

跑完這個指令,大概 15-20 分鐘之內,我會得到一份「本週覆盤報告 + CLAUDE.md 更新建議」。

我看一遍,絕大部分直接合並。偶爾有一兩條我不同意,跟它討論一下,改掉。

這個動作的累積效應

我從去年 6 月開始堅持這個動作,到現在 11 個月。

我的 CLAUDE.md 從最初的 80 行(只有最基本的人設),擴展到現在的 1200 行(包含 6 個 Subagent 的人設、20+ 個 Slash Command 的快捷指令、47 條紅線、35 條偏好、12 個常用工作流的固定模板)。

每一行都來自真實的覆盤。沒有一行是空想的、沒有一行是抄的。

這份 CLAUDE.md 的價值,如果讓我估值,我願意花 ¥20,000 買一份別人的(同樣在一人公司方向有 11 個月經驗沉澱的)。

但別人的 CLAUDE.md 對我沒用——因為它沉澱的是別人的工作流、別人的偏好。CLAUDE.md 的價值是「專屬」的,不可流通。

這就是為什麼我說——「每週一次的 CLAUDE.md 覆盤」是 ROI 最高的動作。

它不會立刻讓你的某一篇文章寫得更好,但它會讓你 6 個月後的整體工作流效率,比現在高 3-5 倍。

這才是真正的複利。

關於這個動作,我額外的提醒——

不要追求一次覆盤把 CLAUDE.md 寫到完美。

我見過有人想「一次寫好」,花一整天憋一份「完美 CLAUDE.md」。結果第二週用一次就發現各種問題,推倒重來——心態崩了,放棄了。

正確的姿勢是「小步快跑」。每週加 5-10 條,慢慢累積。一年下來,你的 CLAUDE.md 自然會有 500-1000 行。

也不要追求「CLAUDE.md 越長越好」。

我自己的 1200 行,已經是上限了。再長,Claude Code 自己加載就要消耗大量 token,反而拖慢響應。

質量比長度重要。每一行都問自己:「這一行沒了,Claude Code 會不會變笨?」 如果不會,刪掉。

最後一點——

每月做一次「CLAUDE.md 大掃除」。

每月底,跟 Claude Code 一起把 CLAUDE.md 整體過一遍——

「我們做一次 CLAUDE.md 大掃除:

1)有沒有過期的規則?(我已經不用的工具、已經改掉的偏好)

2)有沒有重複的內容?(兩條規則講的是一個事)

3)有沒有相互衝突的規則?(A 處說要短,B 處說要長)

4)能不能合併或精簡?

>

處理完之後,給我一份『瘦身後的 CLAUDE.md』。我看一遍,覺得 ok 就替換。」

這個動作,每月一次,半小時搞定。

它保證你的 CLAUDE.md 永遠是「精煉的、當下的、有效的」,不是「臃腫的、過期的、互相打架的」。

講到這,你會發現一個事——

我的一天裏,Claude Code 在 7 個時間節點出現。早報、選題、定稿、諮詢、開發、數據、覆盤。

這 7 個節點,每一個都涉及『需要動腦但不需要太動腦』的事。這種事,過去我必須自己幹。現在,它們大部分是 Claude Code 在幹。

我自己呢?

我只在每個節點上花 10 分鐘做判斷和把關。

剩下的時間,我用來跑步、讀書、陪家人、思考下一步該往哪走。

這才是「一人 AI 公司」的真實樣子。

不是「一個超人幹所有事」,是『一個普通人 + 一堆 AI 實習生』,組成了一個『超人級別的團隊』。

過去十年,有人通過僱傭員工把自己變成老闆。

接下來十年,有人會通過訓練 AI 把自己變成一個團隊。

這是這個時代,普通人最大的紅利。

而你能不能拿到這份紅利,取決於你今天有沒有開始動手。

六偉公眾號 ————————————————————

寫給非程序員的一句話

3 萬字,我儘量寫到這裏。

最後,我想跟你說一句最重要的話——

你不需要懂代碼。你需要懂你自己的業務。然後把這份理解,用普通話清清楚楚地告訴 Claude Code。

它的上限,取決於你對自己業務的理解深度,而不是你的編程水平。

我自己就是最好的例子。我不會寫代碼,但我知道自己每天在做什麼、知道自己想要什麼、知道自己討厭什麼。這份『對自己業務的清晰認知』,讓 Claude Code 在我手裏能做到 90% 程序員都做不到的事。

不是因為我比程序員厲害。是因為程序員的優勢在『怎麼實現』,而 Claude Code 的關鍵在『要實現什麼』。

「要實現什麼」這件事,永遠是業務方說了算,不是技術方。

而你,就是業務方。

如果你想從今天開始動手,我給你一個三天上手計劃——

第一天,裝好 Claude Code,跑通第一個最小任務(就用我第二章推薦的那個 Excel 異常檢測)。目標是建立信任感,知道這玩意真的能幹活。

第二天,寫你的第一份 CLAUDE.md。就 10-20 行,把『你是誰、你的偏好、你的禁忌』先寫進去。然後用這份 CLAUDE.md 跑 5 個不同任務,感受「它越來越懂你」的體感。

第三天,挑你工作裏最煩最重複的一件事(可能是清洗 Excel、可能是整理週報、可能是回客戶諮詢),讓 Claude Code 幫你跑一次。如果跑通了,把這個流程固化成一個 Slash Command,以後一句話搞定。

三天之後,你就正式入門了。

剩下的事,交給時間和重複。

每天用一點、每週沉澱一點、每月迭代一點。三個月之後,你回頭看你的 CLAUDE.md,你會看到一個「AI 版本的你」正在成型。

那個時候,你就擁有了這個時代,普通人最稀缺的資產。

與你共勉,做長期主義者。