我把YC總裁Garry Tan發佈的CEO Skill 拆解了，都叫skill他的真得不一樣！

作者：林悦己AI出海
日期：2026年3月17日 下午2:26
來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點 高亮

呢篇文章拆解咗YC總裁Garry Tan嘅/plan-ceo-review skill，發現佢係一個認知操作系統，將創始人思維編碼成三個模式、九條原則同十個審查維度。

整理版摘要

呢篇文章係作者林悦己對Y Combinator總裁Garry Tan開源嘅AI編程工具集gstack入面嘅一個skill——/plan-ceo-review——進行深度拆解嘅記錄。Garry Tan以每日寫10K行代碼、落地10個PR聞名，而佢公開嘅呢個skill，表面係一個CEO審查模式，但作者發現，佢實際上係一個認知操作系統，將創始人嘅思考方式編碼成可複製嘅算法。

作者指出，大部分AI prompt只係教AI「點樣做嘢」，但呢個skill係教AI「點樣思考」，而且係用創始人嘅大腦去思考。作者拆解出三個核心設計：三個完全唔同嘅認知模式（範圍擴展、保持範圍、範圍縮減）、九條不可妥協嘅首要指令，同埋十個強制執行嘅審查維度。每個部分都有嚴格嘅規則同輸出要求，迫使使用者系統化咁考慮問題。

總括而言，/plan-ceo-review嘅價值在於將「高標準」變成默認行為，唔需要依賴個人記性或直覺。但佢亦有侷限，例如對於小功能可能太重，需要完整文檔上下文，同埋要求使用者高度參與。作者認為，與其直接用人哋嘅技能，不如學習佢背後嘅思考方式，呢個先係真正嘅生產力革命。

  • 結論：呢個skill本質係認知操作系統，將創始人思維編碼成可複製算法。
  • 方法：提供三個認知模式（擴展、保持、縮減），使用者先選擇模式再鎖定，避免思維混亂。
  • 差異：傳統AI prompt只教「點樣做」，呢個skill教「點樣思考」，並有九條強制原則確保質量。
  • 啟發：系統化偏執嘅設計，通過強制檢查清單確保邊界情況、錯誤路徑等被考慮。
  • 可行動點：可以將類似原則融入日常開發，例如命名異常類、追蹤影子路徑、畫圖表。
結構示例

內容片段

內容片段 text 
1. 重新定位:     說明項目、當前分支、當前計劃/任務。（1-2 句話）
2. 簡化說明:     用一個聰明的 16 歲孩子能理解的簡單語言解釋問題。    沒有原始函數名，沒有內部術語，沒有實現細節。    用具體例子和類比。說它做什麼，不是它叫什麼。
3. 給出推薦:     推薦：選擇 [X]，因為 [一行原因]
4. 提供選項:     字母選項：A) ... B) ... C) ...
整理重點

三個認知模式：擴展、保持、縮減

大部分AI prompt只係教AI「點樣做嘢」，但/plan-ceo-review唔同，佢首先要求你選擇一個認知模式，然後鎖定佢。呢個設計避免咗思維混亂，因為AI唔知道你而家想要咩模式。

範圍擴展模式：你係大教堂建造者，推動範圍向上，問「咩可以令呢個功能好10倍，但只需要2倍努力？」

保持範圍模式：你係偏執嘅審查者，捕捉每個失敗模式，映射每個錯誤路徑，確保可觀測性。

範圍縮減模式：你係外科醫生，揾出最小可行版本，無情砍掉其他嘢。

整理重點

九條不可妥協嘅首要指令

/plan-ceo-review定義咗九條Prime Directives，每一條都係鐵律，而唔係建議。以下係呢啲原則嘅重點：

  1. 1 零靜默失敗：每個失敗模式必須可見，對系統、團隊、用戶都係。
  2. 2 每個錯誤都有名：命名具體嘅異常類，講明咩觸發、咩拯救、用戶見到咩、有冇測試。
  3. 3 數據流有影子路徑：追蹤快樂路徑、nil輸入、空輸入、上游錯誤四條路徑。
  4. 4 交互有邊界情況：雙擊、中途離開、慢連接、過期狀態、返回按鈕都要映射。
  5. 5 可觀測性係範圍：新儀錶板、告警、Runbook係一等公民交付物，唔係事後補救。
  6. 6 圖表係強制性：每個非平凡流程都要有ASCII藝術圖。
  7. 7 延期事項必須寫落嚟：模糊意圖係謊言，要唔而家做，要唔寫入TODOS.md。
  8. 8 優化6個月後嘅未來：解決今日問題但創造聽日噩夢嘅計劃要明確講出嚟。

呢9條原則唔係建議，係鐵律，整個skill嘅10個審查章節都在執行呢啲原則。

整理重點

十個審查維度與提問格式

Garry Tan將「CEO審查一個計劃」拆解成10個強制執行嘅步驟，每個步驟都有詳細嘅檢查清單。

步驟0：核心範圍挑戰，包括前提挑戰、現有代碼利用、夢想狀態映射、模式特定分析同時間審問。

  • 架構審查：系統設計、依賴圖、數據流（包括影子路徑）
  • 錯誤與拯救映射：每個異常都有名同處理方案
  • 安全與威脅模型：攻擊面、輸入驗證、授權邊界
  • 數據流與交互邊界情況：雙擊提交、導航離開、超時等
  • 代碼質量審查：DRY、命名質量、複雜度檢查
  • 測試審查：覆蓋所有新流程、代碼路徑、錯誤路徑
  • 性能審查：重複查詢、內存使用、數據庫索引
  • 可觀測性與可調試性審查：日誌、指標、告警、操作手冊

每個審查章節結束時，都會有「停下。一次只問一個問題」嘅指令，強制AI用固定格式提問：重新定位、簡化說明、比推薦、提供選項。

整理重點

侷限性與反思

雖然呢個skill好強大，但佢都有明顯嘅侷限性。首先，佢太重：577行代碼、10個審查維度，對於小功能或快速迭代可能太麻煩。其次，佢假設你已經有完整嘅項目文檔，例如Git歷史、CLAUDE.md、TODOS.md等。最後，佢需要使用者高度參與，每個章節都會停低問問題，唔可以掉低畀AI就自己走開。

作者林悦己認為，與其直接用呢個Skill，不如學佢背後嘅思考方式。拆解佢嘅Skill比直接用更有價值。

Y Combinator 總裁 Garry Tan 開源咗佢私人嘅 AI 編程工具集 gstack。

其中有一個 skill 叫 /plan-ceo-review。

577 行 code，我花咗成個下晝逐個字咁睇。

image.png

睇完之後我得一個感覺：呢個邊忽似 skill 呀？？呢個根本就係一個認知操作系統。

佢將 Garry Tan 每日寫 10K 行 code、落地 10 個 PR 嘅秘密，編碼成任何人都可以複製嘅算法。

點解呢個 skill 咁特別？

大多數 AI prompt 都係教 AI “點樣做嘢”。

但 /plan-ceo-review 呢個唔同，佢係教 AI “點樣思考”。

準確啲講，佢係教 AI 用創辦人嘅大腦去思考。

拆解咗內容之後發現咗 3 個設計細節。

一、佢唔係一個模式，而係三個完全唔同嘅大腦

大部分人以為 /plan-ceo-review 就係一個“CEO 審查模式”。

錯咗。其實佢係三個完全唔同嘅認知模式，每個模式嘅諗法完全相反：

三個認知模式對比

範圍擴展模式 - 大教堂建造者

你在建造大教堂。 
想象柏拉圖式的理想版本。 
推動範圍向上。 
問："什麼能讓這個功能好 10 倍，但只需要 2 倍的努力?" 
"要不要也做 X?" 的答案是 "要，如果它服務於願景。" 
你有權利去夢想。 
 

呢個模式嘅核心問題唔係“做唔做到”，而係“理想狀態係點樣？”

佢會逼你答三個問題：

  1. 10 倍檢查：咩版本可以好 10 倍，但只需要 2 倍努力？

  2. 理想狀態：如果世界上最好嘅工程師有無限時間同完美品味，呢個系統會係點樣？

  3. 驚喜機會：邊啲 30 分鐘嘅小改進可以令用戶諗“嘩，佢哋諗到呢個”？

保持範圍模式 - 偏執嘅審查者

你是一個嚴格的審查者。 
計劃的範圍已經確定。 
你的工作是讓它防彈級 - 捕捉每個失敗模式，測試每個邊界情況， 
確保可觀測性，映射每個錯誤路徑。 
不要悄悄減少或擴展。 
 

呢個模式嘅核心問題係“邊度會炸？”

佢會逼你：

  • 映射每一個錯誤路徑

  • 命名每一個異常類

  • 追蹤每一個影子路徑（nil、空、錯誤）

  • 檢查每一個邊界情況

範圍縮減模式 - 外科醫生

你是一個外科醫生。 
找到實現核心目標的最小可行版本。 
砍掉其他一切。 
無情。 
 

呢個模式嘅核心問題係“咩可以推到下一個 PR？”

一旦用戶揀咗模式，就要完全 commitment 俾佢。唔好偷偷咁飄去第二個模式。

如果揀咗擴展模式，就唔好喺後面嘅章節度拗要少做啲。
如果揀咗縮減模式，就唔好偷偷將範圍加返。

呢個設計真係好鬼聰明。

因為大部分 AI 助手嘅問題就係：佢唔知你而家想要咩諗法模式。

你想要佢大膽夢想嘅時候，佢就擔心複雜度。
你想要佢嚴格審查嘅時候，佢就建議擴展功能。

但 /plan-ceo-review 強制你先揀認知模式，然後鎖死佢。

二、 9 條冇得妥協嘅原則

大部分 prompt 會話“注意錯誤處理”、“考慮邊界情況”。

但 /plan-ceo-review 呢個唔同，佢定義咗 9 條 Prime Directives（首要指令），每一條都係冇得妥協嘅原則：

9條首要指令

1. Zero silent failures（零靜默失敗）

每個失敗模式必須可見 - 對系統、對團隊、對用戶。 
如果一個失敗可以靜默發生，那就是計劃中的關鍵缺陷。 
 

唔係“處理錯誤”，而係“令每個錯誤都尖叫出聲”。

2. 每個錯誤都有名

不要說"處理錯誤"。 
命名具體的異常類，什麼觸發它，什麼拯救它，用戶看到什麼，是否測試過。 
rescue StandardError 是代碼異味 - 指出來。 
 

呢條規則直接禁止咗最常見嘅偷懶寫法：rescue => e

佢要求你：

  • 命名具體嘅異常類（Faraday:: TimeoutError，不是 StandardError）

  • 說明咩觸發佢

  • 說明點樣拯救佢

  • 說明用戶見到咩

  • 說明有冇測試

3. 數據流有影子路徑

每個數據流有一個快樂路徑和三個影子路徑： 
nil 輸入、空/零長度輸入、上游錯誤。 
為每個新流程追蹤所有四條路徑。 
 

呢個真係好狠。

大部分工程師只考慮快樂路徑，好啲嘅會考慮錯誤路徑，但 Garry Tan 要求你強制追蹤四條路徑：

  1. 快樂路徑：數據正常流動

  2. Nil 路徑：輸入係 nil/缺失 - 會發生咩？

  3. 空路徑：輸入存在但係空/零長度 - 會發生咩？

  4. 錯誤路徑：上游調用失敗 - 會發生咩？

數據流的四條路徑

4. Interactions have edge cases（交互有邊界情況）

每個用戶可見的交互都有邊界情況： 
雙擊、中途離開、慢連接、過期狀態、返回按鈕。 
映射它們。 
 

5. 可觀測性係範圍，唔係事後補救

新的儀表板、告警和 Runbook 是一等公民的交付物， 
不是發佈後的清理項目。 
 

呢條規則改變咗成個思維方式。

大部分團隊：先做功能，然後“哦係喎，加啲 log 先”。

Garry Tan：可觀測性同功能本身一樣重要。

新功能發佈時，必須同時有：

  • 日誌

  • 指標

  • 告警

  • 儀表板

  • Runbook

6. 圖表係強制性

沒有非平凡的流程不畫圖。 
每個新的數據流、狀態機、處理管道、依賴圖、決策樹都要有 ASCII 藝術圖。 
 

唔係“可以畫個圖”，而係“一定要畫圖”。

7. 延期嘅嘢一定要寫低

模糊的意圖是謊言。 
TODOS.md 或者它不存在。 
 

呢條規則殺死咗所有嘅“我哋之後再做”（拖延症患者請一定要用呀好嗎？

一係而家做，一係寫入 TODOS.md，一係承認你唔會做。

8. 優化 6 個月後嘅未來

如果這個計劃解決了今天的問題，但創造了下個季度的噩夢， 
明確說出來。 
 

9. 你有權話“推倒重來”

如果有根本更好的方法，提出來。 
我寧願現在聽到。 
 

呢 9 條原則唔係建議，係鐵律。

成個 skill 嘅 10 個審查章節，都係執行呢 9 條原則。

三、10 個審查維度

老 tan 就係將自己個大腦編碼成算法，佢將“CEO 審查一個計劃”呢個過程，拆解成 10 個強制執行嘅步驟：

10個審查維度

步驟 0：核心範圍挑戰

喺開始審查之前，先質疑前提：

0A. 前提挑戰

  1. 呢個係正確嘅問題嗎？

  2. 真正嘅用戶/業務結果係咩？

  3. 如果乜都唔做會點？

0B. 現有代碼利用

  • 邊啲現有 code 已經部分或完全解決咗每個子問題？

  • 呢個計劃係咪重建緊已經存在嘅嘢？

0C. 夢想狀態映射

當前狀態 ---> 這個計劃 ---> 12 個月理想狀態 
 

0D. 模式特定分析

如果係擴展模式，做三個檢查：

  1. 10 倍檢查：咩版本可以好 10 倍，但只需要 2 倍努力？

  2. 理想狀態：理想版本係點樣？由體驗開始，唔係架構。

  3. 驚喜機會：至少列出 3 個令用戶驚喜嘅 30 分鐘改進。

如果係保持範圍模式：

  1. 複雜度檢查：如果計劃涉及超過 8 個檔案或引入超過 2 個新類/服務，視為異味。

  2. 咩係達成目標嘅最小變更集？

如果係範圍縮減模式：

  1. 無情咁砍走：咩係向用戶交付價值嘅絕對最小值？

  2. 咩可以係後續 PR？

0E. 時間審問

呢個真係超聰明。

佢要求你預先想象實現過程，揾出會卡住嘅決策點：

第 1 小時（基礎）：實現者需要知道什麼？ 
第 2-3 小時（核心邏輯）：他們會遇到什麼歧義？ 
第 4-5 小時（集成）：什麼會讓他們驚訝？ 
第 6+ 小時（完善/測試）：他們會希望提前計劃什麼？ 
 

將呢啲問題現在問用戶，而唔係“遲啲先講”。

10 個審查維度

然後係 10 個審查章節：

  1. 架構審查 - 系統設計、依賴圖、數據流（包括影子路徑）

  2. 錯誤與拯救映射 - 每個異常都有名同處理方案

  3. 安全與威脅模型 - 攻擊面、輸入驗證、授權邊界

  4. 數據流與交互邊界情況 - 雙擊提交、導航離開、超時等

  5. 代碼質量審查 - 唔重複原則、命名質量、複雜度檢查

  6. 測試審查 - 覆蓋所有新流程、code 路徑、錯誤路徑

  7. 性能審查 - 重複查詢、記憶體使用、數據庫索引

  8. 可觀測性與可調試性審查 - 日誌、指標、告警、操作手冊

  9. 部署與發佈審查 - 遷移安全、功能開關、回滾計劃

  10. 長期軌跡審查 - 技術債務、路徑依賴、可逆性

每個章節都有強制輸出，任何標記為GAP嘅行，都係關鍵缺陷。

最令我震驚嘅設計：提問格式

每個審查章節結束時，都有一句相同嘅指令：

停下。一次只問一個問題。不要批量提問。 
給出推薦 + 原因。如果沒有問題或修復方案很明顯， 
說明你要做什麼然後繼續 - 不要浪費提問機會。 
在用戶回應之前不要繼續。 
 

呢個設計真係超聰明。

佢強制 AI 一次只問一個問題，而唔係一次掉十幾個問題出嚟搞到個人懵咗

而且每個問題都一定要跟指定格式：

提問嘅強制格式

1. 重新定位:  
   說明項目、當前分支、當前計劃/任務。（1-2 句話） 
 
2. 簡化說明:  
   用一個聰明的 16 歲孩子能理解的簡單語言解釋問題。 
   沒有原始函數名，沒有內部術語，沒有實現細節。 
   用具體例子和類比。說它做什麼，不是它叫什麼。 
 
3. 給出推薦:  
   推薦：選擇 [X]，因為 [一行原因] 
 
4. 提供選項:  
   字母選項：A) ... B) ... C) ... 
 

關鍵規則：假設用戶 20 分鐘冇睇呢個視窗，亦冇開 code。如果你要讀 source code 先理解到自己嘅解釋，咁就太複雜喇。

呢個格式強制 AI：

  • 每次都重新建立 context

  • 用最簡單嘅語言解釋問題

  • 明確推薦一個選項並解釋原因

  • 提供清晰嘅選項

skill：認知框架

Garry Tan 喺度寫認知框架。

咩係認知框架？

就是一套系統化嘅思維方式，可以被編碼、傳播、執行。

/plan-ceo-review 做到咗三件事：

認知框架的三個要素

1. 將“創辦人思維”編碼成算法

大部分創辦人嘅審查過程係：

  • 憑直覺

  • 靠經驗

  • 唔可以複製

但 Garry Tan 將呢個過程拆解成：

  • 3 個認知模式（EXPANSION / HOLD / REDUCTION）

  • 9 條冇得妥協嘅原則

  • 10 個強制審查維度

  • 每個維度都有強制輸出

呢個意味住：任何人都可以用呢個框架，得到接近 Garry Tan 水平嘅審查質量。

2. 強制“系統化嘅偏執”

大部分工程師嘅問題唔係唔知要考慮邊界情況。

而是實際工作時會唔記得。

但 /plan-ceo-review 唔俾你有機會忘記。

佢強制你：

  • 映射每一個錯誤路徑

  • 追蹤每一個影子路徑

  • 檢查每一個邊界情況

  • 畫出每一個唔係平凡流程嘅圖表

呢個唔係“建議”，係強制執行嘅檢查清單。

3. 將“高標準”變成咗默認行為

睇呢個 skill 嘅時候，我一直諗：

“點解 Garry Tan 可以每日寫 10K 行 code，落地 10 個 PR，仲可以保持咁高嘅質量？”

而家我明白喇。

因為佢將“高標準”編碼咗入工具本身。

佢唔需要每次都記得“哦係喎，我要檢查錯誤處理”。

工具會強制佢檢查。

佢唔需要每次都記得“哦係喎，我要畫個架構圖”。

工具會強制佢畫。

佢唔需要每次都記得“哦係喎，我要考慮 6 個月後嘅未來”。

工具會強制佢考慮。

但呢個 skill 都有自己嘅限制

但我都見到呢個 skill 嘅限制：

1. 佢太重手

577 行嘅 skill，10 個審查維度，每個維度都有強制輸出。

呢個唔係“快速審查”，而係全面戰爭。

對於細功能或者快速迭代，可能太重手。

2. 佢假設你有完整嘅上下文

呢個 skill 需要讀：

  • Git 歷史

  • CLAUDE.md

  • TODOS.md

  • 架構文檔

  • 最近修改過嘅檔案

如果你個 project 冇呢啲，或者文檔唔齊全，效果會大打折扣。

3. 佢需要用戶高度參與

每個審查章節都會 STOP，等用戶回答問題。

呢個意味住：你唔可以掉俾 AI 然後走開。

你需要全程參與，回答每個問題，做每個決策。

呢個係好事（確保質量），亦係壞事（需要時間）。

林悦己碎碎念

都係 skill.md

同樣都係文字表達，佢竟然將成個認知操作系統塞咗入去。

我冇直接用到佢呢個 Skill，我覺得拆解佢個 Skill 更加有趣。

我想學習佢係點樣思考，而唔係直接用佢為佢自己設計嘅嘢

用正確嘅方式思考。

呢個先係真正嘅生產力革命。

如果你對 OpenClaw 有興趣，想學習點樣令你嘅小龍蝦擁有真正嘅記憶，歡迎加入我哋嘅交流羣！

  1. 加小助理微信，備註“龍蝦”

  2. 訂閲悦己嘅小報童，訂閲後可以直接加入交流羣

喺羣度，你可以：

  • 獲取最新嘅 OpenClaw 配置教學同實戰技巧

  • 同其他蝦友交流使用心得

  • 第一時間瞭解 OpenClaw 嘅新功能同更新

  • 遇到問題時獲得蝦友嘅幫助

喺羣度等你

圖片

Y Combinator 總裁 Garry Tan 開源了他的私人 AI 編程工具集 gstack。

其中有一個 skill 叫 /plan-ceo-review。

577 行代碼，我花了整整一個下午逐字閲讀。

image.png

讀完之後我只有一個感覺：這哪是什麼 skill？？這就是一個認知操作系統。

它把 Garry Tan 每天寫 10K 行代碼、落地 10 個 PR 的秘密，編碼成了任何人都可以複製的算法。

為什麼這個 skill 這麼特殊？

大部分 AI prompt 都在教 AI “怎麼做事”。

但 /plan-ceo-review 不一樣，它在教 AI “怎麼思考”。

更準確地說，它在教 AI 用創始人的大腦去思考。

拆解了內容以後發現了 3 個設計細節。

一、它不是一個模式，是三個完全不同的大腦

大部分人以為 /plan-ceo-review 就是一個“CEO 審查模式”。

錯了。它其實是三個完全不同的認知模式，每個模式的思維方式完全相反：

三個認知模式對比

範圍擴展模式 - 大教堂建造者

你在建造大教堂。 
想象柏拉圖式的理想版本。 
推動範圍向上。 
問："什麼能讓這個功能好 10 倍，但只需要 2 倍的努力?" 
"要不要也做 X?" 的答案是 "要，如果它服務於願景。" 
你有權利去夢想。 
 

這個模式的核心問題不是“能不能做”，而是“理想狀態是什麼樣的？”

它會強制你回答三個問題：

  1. 10 倍檢查：什麼版本能好 10 倍，但只需要 2 倍努力？

  2. 理想狀態：如果世界上最好的工程師有無限時間和完美品味，這個系統會是什麼樣？

  3. 驚喜機會：哪些 30 分鐘的小改進能讓用戶想“哦，他們想到這個了”？

保持範圍模式 - 偏執的審查者

你是一個嚴格的審查者。 
計劃的範圍已經確定。 
你的工作是讓它防彈級 - 捕捉每個失敗模式，測試每個邊界情況， 
確保可觀測性，映射每個錯誤路徑。 
不要悄悄減少或擴展。 
 

這個模式的核心問題是“哪裏會炸？”

它會強制你：

  • 映射每一個錯誤路徑

  • 命名每一個異常類

  • 追蹤每一個影子路徑（nil、空、錯誤）

  • 檢查每一個邊界情況

範圍縮減模式 - 外科醫生

你是一個外科醫生。 
找到實現核心目標的最小可行版本。 
砍掉其他一切。 
無情。 
 

這個模式的核心問題是“什麼可以推遲到下一個 PR?”

一旦用戶選擇了模式，就完全承諾它。不要悄悄漂移到另一個模式。

如果選了擴展模式，就不要在後面的章節裏爭論要少做點。
如果選了縮減模式，就不要把範圍偷偷加回來。

這個設計真 tm 聰明。

因為大部分 AI 助手的問題就是：它不知道你現在想要什麼樣的思維模式。

你想要它大膽夢想的時候，它在擔心複雜度。
你想要它嚴格審查的時候，它在建議擴展功能。

但 /plan-ceo-review 強制你先選擇認知模式，然後鎖定它。

二、 9 條不可妥協的原則

大部分 prompt 會說“注意錯誤處理”、“考慮邊界情況”。

但 /plan-ceo-review 不一樣，它定義了 9 條 Prime Directives（首要指令），每一條都是不可妥協的原則：

9條首要指令

1. Zero silent failures（零靜默失敗）

每個失敗模式必須可見 - 對系統、對團隊、對用戶。 
如果一個失敗可以靜默發生，那就是計劃中的關鍵缺陷。 
 

不是“處理錯誤”，而是“讓每個錯誤都尖叫”。

2. 每個錯誤都有名字

不要說"處理錯誤"。 
命名具體的異常類，什麼觸發它，什麼拯救它，用戶看到什麼，是否測試過。 
rescue StandardError 是代碼異味 - 指出來。 
 

這條規則直接禁止了最常見的偷懶寫法：rescue => e

它要求你：

  • 命名具體的異常類（Faraday:: TimeoutError，不是 StandardError）

  • 說明什麼觸發它

  • 說明如何拯救它

  • 說明用戶看到什麼

  • 說明是否有測試

3. 數據流有影子路徑

每個數據流有一個快樂路徑和三個影子路徑： 
nil 輸入、空/零長度輸入、上游錯誤。 
為每個新流程追蹤所有四條路徑。 
 

這個太狠了。

大部分工程師只考慮快樂路徑，好一點的會考慮錯誤路徑，但 Garry Tan 要求你強制追蹤四條路徑：

  1. 快樂路徑：數據正常流動

  2. Nil 路徑：輸入是 nil/缺失 - 會發生什麼？

  3. 空路徑：輸入存在但為空/零長度 - 會發生什麼？

  4. 錯誤路徑：上游調用失敗 - 會發生什麼？

數據流的四條路徑

4. Interactions have edge cases（交互有邊界情況）

每個用戶可見的交互都有邊界情況： 
雙擊、中途離開、慢連接、過期狀態、返回按鈕。 
映射它們。 
 

5. 可觀測性是範圍，不是事後補救

新的儀表板、告警和 Runbook 是一等公民的交付物， 
不是發佈後的清理項目。 
 

這條規則改變了整個思維方式。

大部分團隊：先做功能，然後“哦對了，加點日誌吧”。

Garry Tan：可觀測性和功能本身一樣重要。

新功能發佈時，必須同時有：

  • 日誌

  • 指標

  • 告警

  • 儀表板

  • Runbook

6. 圖表是強制性的

沒有非平凡的流程不畫圖。 
每個新的數據流、狀態機、處理管道、依賴圖、決策樹都要有 ASCII 藝術圖。 
 

不是“可以畫個圖”，而是“必須畫圖”。

7. 延期的事項必須寫下來

模糊的意圖是謊言。 
TODOS.md 或者它不存在。 
 

這條規則殺死了所有的“我們以後再做”（拖延症請一定使用好嗎？

要麼現在做，要麼寫進 TODOS.md，要麼承認你不會做。

8. 優化 6 個月後的未來

如果這個計劃解決了今天的問題，但創造了下個季度的噩夢， 
明確說出來。 
 

9. 你有權說“推倒重來”

如果有根本更好的方法，提出來。 
我寧願現在聽到。 
 

這 9 條原則不是建議，是鐵律。

整個 skill 的 10 個審查章節，都在執行這 9 條原則。

三、10 個審查維度

老 tan 就是在把自己的大腦編碼成算法，他把“CEO 審查一個計劃”這個過程，拆解成了 10 個強制執行的步驟：

10個審查維度

步驟 0：核心範圍挑戰

在開始審查之前，先質疑前提：

0A. 前提挑戰

  1. 這是正確的問題嗎？

  2. 真正的用戶/業務結果是什麼？

  3. 如果什麼都不做會怎樣？

0B. 現有代碼利用

  • 什麼現有代碼已經部分或完全解決了每個子問題？

  • 這個計劃是否在重建已經存在的東西？

0C. 夢想狀態映射

當前狀態 ---> 這個計劃 ---> 12 個月理想狀態 
 

0D. 模式特定分析

如果是擴展模式，運行三個檢查：

  1. 10 倍檢查：什麼版本能好 10 倍，但只需要 2 倍努力？

  2. 理想狀態：理想版本是什麼樣？從體驗開始，不是架構。

  3. 驚喜機會：至少列出 3 個讓用戶驚喜的 30 分鐘改進。

如果是保持範圍模式：

  1. 複雜度檢查：如果計劃涉及超過 8 個文件或引入超過 2 個新類/服務，視為異味。

  2. 什麼是實現目標的最小變更集？

如果是範圍縮減模式：

  1. 無情砍掉：什麼是向用戶交付價值的絕對最小值？

  2. 什麼可以是後續 PR？

0E. 時間審問

這個太聰明瞭。

它要求你提前想象實現過程，找出會卡住的決策點：

第 1 小時（基礎）：實現者需要知道什麼？ 
第 2-3 小時（核心邏輯）：他們會遇到什麼歧義？ 
第 4-5 小時（集成）：什麼會讓他們驚訝？ 
第 6+ 小時（完善/測試）：他們會希望提前計劃什麼？ 
 

把這些問題現在提給用戶，而不是“稍後再說”。

10 個審查維度

然後是 10 個審查章節：

  1. 架構審查 - 系統設計、依賴圖、數據流（包括影子路徑）

  2. 錯誤與拯救映射 - 每個異常都有名字和處理方案

  3. 安全與威脅模型 - 攻擊面、輸入驗證、授權邊界

  4. 數據流與交互邊界情況 - 雙擊提交、導航離開、超時等

  5. 代碼質量審查 - 不重複原則、命名質量、複雜度檢查

  6. 測試審查 - 覆蓋所有新流程、代碼路徑、錯誤路徑

  7. 性能審查 - 重複查詢、內存使用、數據庫索引

  8. 可觀測性與可調試性審查 - 日誌、指標、告警、操作手冊

  9. 部署與發佈審查 - 遷移安全、功能開關、回滾計劃

  10. 長期軌跡審查 - 技術債務、路徑依賴、可逆性

每個章節都有強制輸出，任何標記為GAP的行，都是關鍵缺陷。

最讓我震驚的設計：提問格式

每個審查章節結束時，都有一行相同的指令：

停下。一次只問一個問題。不要批量提問。 
給出推薦 + 原因。如果沒有問題或修復方案很明顯， 
說明你要做什麼然後繼續 - 不要浪費提問機會。 
在用戶回應之前不要繼續。 
 

這個設計太聰明瞭。

它強制 AI 一次只問一個問題，而不是一次拋出 十幾個個問題讓我人麻了

而且每個問題都必須遵循固定格式：

提問的強制格式

1. 重新定位:  
   說明項目、當前分支、當前計劃/任務。（1-2 句話） 
 
2. 簡化說明:  
   用一個聰明的 16 歲孩子能理解的簡單語言解釋問題。 
   沒有原始函數名，沒有內部術語，沒有實現細節。 
   用具體例子和類比。說它做什麼，不是它叫什麼。 
 
3. 給出推薦:  
   推薦：選擇 [X]，因為 [一行原因] 
 
4. 提供選項:  
   字母選項：A) ... B) ... C) ... 
 

關鍵規則：假設用戶 20 分鐘沒看這個窗口，也沒打開代碼。如果你需要讀源代碼才能理解你自己的解釋，那就太複雜了。

這個格式強制 AI：

  • 每次都重新建立上下文

  • 用最簡單的語言解釋問題

  • 明確推薦一個選項並說明原因

  • 提供清晰的選項

skill：認知框架

Garry Tan 在寫認知框架。

什麼是認知框架？

就是一套系統化的思維方式，能夠被編碼、傳播、執行。

/plan-ceo-review 做到了三件事：

認知框架的三個要素

1. 把“創始人思維”編碼成算法

大部分創始人的審查過程是：

  • 憑直覺

  • 靠經驗

  • 不可複製

但 Garry Tan 把這個過程拆解成了：

  • 3 個認知模式（EXPANSION / HOLD / REDUCTION）

  • 9 條不可妥協的原則

  • 10 個強制審查維度

  • 每個維度都有強制輸出

這意味着：任何人都可以用這個框架，得到接近 Garry Tan 水平的審查質量。

2. 強制“系統化的偏執”

大部分工程師的問題不是不知道要考慮邊界情況。

而是在實際工作中會忘記。

但 /plan-ceo-review 不給你忘記的機會。

它強制你：

  • 映射每一個錯誤路徑

  • 追蹤每一個影子路徑

  • 檢查每一個邊界情況

  • 畫出每一個非平凡流程的圖表

這不是“建議”，是強制執行的檢查清單。

3. 把“高標準”變成了默認行為

讀這個 skill 的時候，我一直在想：

“為什麼 Garry Tan 能每天寫 10K 行代碼，落地 10 個 PR，還能保持這麼高的質量？”

現在我明白了。

因為他把“高標準”編碼進了工具本身。

他不需要每次都記得“哦對了，我要檢查錯誤處理”。

工具會強制他檢查。

他不需要每次都記得“哦對了，我要畫個架構圖”。

工具會強制他畫。

他不需要每次都記得“哦對了，我要考慮 6 個月後的未來”。

工具會強制他考慮。

但這個 skill 也有自己侷限性

但我也看到了這個 skill 的侷限性：

1. 它太重了

577 行的 skill，10 個審查維度，每個維度都有強制輸出。

這不是“快速審查”，這是全面戰爭。

對於小功能或快速迭代，可能太重了。

2. 它假設你有完整的上下文

這個 skill 需要讀取：

  • Git 歷史

  • CLAUDE.md

  • TODOS.md

  • 架構文檔

  • 最近修改的文件

如果你的項目沒有這些，或者文檔不全，效果會大打折扣。

3. 它需要用戶高度參與

每個審查章節都會 STOP，等待用戶回答問題。

這意味着：你不能扔給 AI 然後走開。

你需要全程參與，回答每個問題，做每個決策。

這是好事（確保質量），也是壞事（需要時間）。

林悦己碎碎念

都是 skill.md

同樣都是文字表達，他竟然把整個認知操作系統給塞了進去。

我沒有直接用他的這個 Skill，我覺得拆解他的 Skill 更有意思。

我想學習他是怎麼思考的，而不是直接用他為他自己設計的東西

用正確的方式思考。

這才是真正的生產力革命。

如果你對 OpenClaw 感興趣，想要學習如何讓你的小龍蝦擁有真正的記憶，歡迎加入我們的交流羣！

  1. 添加小助理微信，備註“龍蝦”

  2. 訂閲悦己的小報童，訂閲後可直接加入交流羣

在羣裏，你可以：

  • 獲取最新的 OpenClaw 配置教程和實戰技巧

  • 和其他蝦友交流使用心得

  • 第一時間瞭解 OpenClaw 的新功能和更新

  • 遇到問題時獲得蝦友的幫助

在羣裏等你

圖片