我把馬斯克等10個最強大腦塞進Skill，被他們合夥diss了一天
整理版優先睇
用10個名人視角交叉校對自己，發現我最大的問題係覆盤太多、產出太少
作者係一個AI應用實踐者，經常使用Claude Code輔助寫code同內容創作。佢發現Claude Code分析自己問題時總係「照鏡子」，視角單一，難以突破認知侷限。所以佢參考subagent在code審核中的成功經驗，設計咗一個「多視角深度分析Skill」，收集馬斯克、張一鳴、喬布斯等10位頂尖人物的語料作為獨立顧問，用嚟分析自己3月份的內容同產品落地情況。
結果出乎意料：10個顧問出奇一致地diss佢「過度覆盤、執行力弱」，而呢個批評喺單一視角下佢只會覺得對方唔理解自己，但多維交叉驗證後佢不得不正視問題。顧問們仲提供咗好多具體視角，例如10x增長過濾器、時間分配問題、讀者獲得感缺失、一句話講清產品嘅挑戰，同埋標題評分優化空間。
最終作者決定放棄數據驅動的強制更新，轉用興趣驅動，專注深度內容同Agent實踐總結，並且減少AI在寫作中的參與，保留「手藝活」的感覺。佢將呢個Skill開源到GitHub，希望幫到更多人突破認知瓶頸。
- 透過多視角cross-check，先發現自己「覆盤>產出」呢個核心問題，而唔係單一AI可以點出嚟嘅盲點
- 構建方法：用subagent調用邏輯，將10個名人語料變成獨立顧問，每個從自己視角輸出分析報告
- 關鍵差異：多視角分析唔係為咗求同，而係睇到共識同分歧—共識係diss你嘅痛點，分歧係路徑選擇嘅啟發
- 啟發：高影響決策（如產品定位）值得用多視角，但日常迭代（如小版本更新）用subagent反而浪費資源
- 可行動：作者決定改行興趣驅動、減少強制更新、精簡AI參與寫作，專注深度內容沉澱
多視角深度分析 Skill
將10個名人語料集成嘅Claude Code Skill，用嚟分析個人問題或產品，支援自定義視角。
從照鏡子到多維透視：點解要整10個AI顧問
作者平時用Claude Code覆盤內容同產品，但發現Opus視角總係侷限於現有語料，俾嘅建議好似「照鏡子」，例如叫佢提升執行力、壓縮產品範圍，呢啲嘢佢早就知道。
佢諗起寫code時用subagent審核code可以明顯降bug率，於是諗：既然code行得通，思考討論點解唔可以複用相同邏輯？佢決定收集世界最聰明人嘅語料，將問題拋俾subagent獨立分析，再用多個視角cross-check自己判斷。
十個顧問集體diss：覆盤多過產出係最大問題
作者用呢個Skill分析自己3月份內容同CodePal產品，每個顧問獨立出一份報告，主視角opus再整合共識同分歧。共識出奇一致：diss作者「執行力弱、覆盤高於產出」。
抽樣5個視角值得留意：10x增長視角建議做事前問「有冇10x可能性」；馬斯克視角直指時間分配錯配——花太多時間討論，主線應該係內容生產；張一鳴算法視角點出讀者獲得感呢個被忽略嘅點；喬布斯產品視角問「一句話講清楚自己做咩」，令作者扎心；MrBeast內容視角則評分標題有優化空間。
- 10x增長視角：一個過濾器，冇10x可能性嘅事唔值得花太多精力
- 馬斯克視角：時間分配錯誤，主線係內容生產，其他圍繞呢個展開
- 張一鳴算法視角：忽略咗讀者真正喜歡睇嘅內容同獲得感
- 喬布斯產品視角：能否一句話講清自己喺做咩？作者暫時做唔到
- MrBeast內容視角：標題評分低，改改可能流量更高
路徑分歧：代碼優先、內容優先定興趣優先？
十個顧問唔止有diss共識，仲有路徑選擇上嘅分歧。例如代碼優先、內容優先、興趣優先，每個視角都認為自己條路最優，但呢三者唔可能同時做。
作者琢磨半天，發現自己最鍾意張小龍視角下嘅興趣驅動。佢解釋自己本身性格如此：固定更新好難，產出全靠有冇靈感；之前試過數據驅動（一週幾篇、固定日期發、覆盤數據），但發現呢個方法完全唔適合自己，因為平日只有夜晚有時間，仲要分時間coding同打機。
新計劃：少AI寫作、多深度內容、唔再強迫更新
既然決定興趣驅動，作者計劃將更多精力放喺Agent應用深度內容，例如寫好玩嘅Skill、探索Claude Code架構、研究長程任務，每個階段沉澱成教程。表達形式上用圖文產出深度內容，短文只記錄即時思考。
佢亦唔再設定強制發文週期，寫完滿意就出，未寫完就繼續積累。同時減少AI喺碼字中嘅參與，AI只做思考輔助，碼字靠自己手敲，因為呢個係手藝活，手生咗就寫唔出好內容。
- 1 方向：Agent應用深度內容，如有趣Skill、Claude Code架構、長程任務
- 2 形式：圖文深度內容 + 短文即時思考
- 3 頻率：冇強制週期，滿意先出
- 4 AI角色：輔助思考，唔再參與碼字
多視角Skill嘅使用時機：擰螺絲唔使上電鑽
作者最後反思：係咪每個環節都要用10個subagent？佢用落發現多視角分析嘅必要性取決於場景複雜度同影響力。例如CodePal迭代一個小版本，用10個subagent太浪費；但思考產品定位、冷啟動呢類關鍵問題，就值得叫齊所有人開會。
佢仲將呢個思路延伸去做Mac產品設計，叫設計師角色重新設計CodePal首頁，效果唔錯。但強調唔好濫用subagent，要按需取用。
最後作者提供咗GitHub開源連結，讀者可以直接安裝個Skill，或者叫Codex/Claude Code一鍵安裝。
上個假期我喺屋企覆盤咗3月份嘅公眾號內容同CodePal產品，我好熟練咁打開咗Claude Code同佢開始討論。
討論咗一兩個鐘之後，Claude Code畀咗我一啲建議，但我其實唔係好滿意，我唔想聽到我哋應該一齊努力提升執行力、盡量壓縮產品要做嘅事情呢類建議，呢啲嘢我早就知，而且我覺得呢個並唔係我而家最大嘅問題。
我成日覺得Opus嘅視角有啲被侷限咗，唔知係咪因為餵咗我太多語料搞成咁，我成日覺得自己好似喺度照鏡。
討論完之後我去咗水庫行咗一圈，沿途我一邊睇風景一邊諗，有冇一種方式，可以令AI幫我突破我而家嘅認知邊界？
我諗起咗我最近喺coding場景好常用到嘅一個場景。
我每次寫完code之後我都會叫opus調用subagent嚟做審核同測試，等佢自己多輪測試完之後我再去驗收，透過subagent調用可以明顯降低code嘅bug率。
既然喺code裏面呢個邏輯成立，咁思考討論場景可唔可以都重用相同嘅邏輯呢？
我去整理出全世界最聰明嘅人嘅語料，然後將我面對嘅問題一齊掟俾subagent去處理，再叫佢哋分別畀出各自嘅判斷同視角。
咁樣一嚟，我就唔止可以見到一套鏡視角邏輯，我可以用多個視角，去交叉校對我自己嘅判斷。
同時咁樣仲可以減少已有上下文對AI思考角度嘅幹擾，令佢更純粹咁去思考。
腦入面冒出呢個點子之後我覺得好值得探索，返到屋企之後我就開始叫Claude Code探索呢件事。
我同opus建立咗一套語料收集策略，基於呢個策略我哋建立咗幾個獨立嘅顧問知識庫，然後開始進行測試。
經過多輪嘅顧問知識庫優化之後，我得到咗一個好令我滿意嘅顧問語料版本，我擁有咗10個顧問。
於是我開始用佢哋，去分析我3月份嘅內容同產品落地情況。
呢10個顧問幫我做咗一輪好詳細嘅分析，剩係睇完份報告，我就用咗差唔多半個鐘。
每個顧問都從自己嘅視角畀咗一份獨立分析報告，而主對話裏面嘅opus，就基於佢哋嘅觀點，幫我做咗一份匯總分析。
因為報告比較長，下面我就抽一部分顧問分析好觸動我嘅點，然後同大家展示一下。
先由總視角開始啦，opus幫我匯總咗一份大家嘅共識同分歧內容。
共識內容反而出奇地一致喺度diss我，佢哋指出咗我喺執行力中最大嘅問題，我鍾意覆盤呢樣嘢多過產出，透過覆盤的確可以令我覺得自己好認真同AI一齊做嘢，但實際上又真係冇乜產出。
當opus得一個視角同我講覆盤太多嘅時候，我可能會覺得opus理解唔到我到底想做一件點樣嘅事。
但當10個opus加多維視角一齊diss我話覆盤太多、執行力太弱，我會認真諗嚇減少覆盤呢件事嘅頻率。
唔講得笑，始終係人多力量大啊。
目前4月份我仲未開始過覆盤，我更多時間都喺度coding同寫初稿。
主視角報告同大家展示曬啦，接下來子視角我都同大家分享嚇，10個視角完整睇完要用半個鐘，我就抽樣5個有代表性嘅內容同大家分享嚇。
1. 10倍增長視角：佢畀咗我一個好有意思嘅過濾器視角，當我準備要做一件事嘅時候，可以先問嚇自己一句：呢件事有冇10倍嘅可能性？如果冇，咁可能就唔值得投入太多精力。 
2. 馬斯克視角：佢直接指出咗我時間分配嘅問題。佢覺得我用咗太多時間浪費喺討論同思考上面，然而我自己真正嘅主線應該放喺內容生產上，其他嘅事情都係圍繞呢個主線展開嘅。
3. 張一鳴嘅算法視角：佢提出咗我最近有啲忽略嘅一個問題，我嘅讀者到底鍾意睇嘅內容係咩？對佢哋嚟講內容嘅獲得感係咩，呢個點我最近真係冇乜點花精力研究，我要揾個時間認真諗諗。
4. 喬布斯嘅產品視角：佢問咗我一個好關鍵嘅問題：你可唔可以一句話講清楚自己到底做緊咩？呢個問題都幾扎心，我確實好似都未太諗清楚，我只係想令AI編程嘅自動化程度同落地再高啲，邊做邊諗啦。
5. 內容大咖MrBeast嘅視角：呢個視角係比較偏內容側嘅評價，佢主要係對我嘅標題評分，睇完之後我覺得有唔少優化空間，可能我嗰篇openclaw標題名稱再改改，流量仲可以再上一截。
睇完呢啲內容之後，我發現咗好多平時我意識唔到嘅問題，於是我開始諗：接下來到底應該點做？
呢10個傢伙擺埋一齊，唔單止有diss我嘅共識，佢哋喺路徑選擇上仲有啲分歧點，而呢一點都幾得意。
例如話code優先、內容優先、興趣優先，每個顧問喺自己嘅視角下，畀出咗佢哋認為嘅最優路徑。
但呢三件事必然係冇可能同時存在嘅，我必須從裏面揀一個作為我接下來一段時間嘅主線。
我諗咗好耐，其實發現我更鍾意嘅事係張小龍視角下嘅興趣驅動。
原因都好簡單，我本身就係呢種性格。大家都可以睇到我嘅更新頻率，固定更新其實係一件幾難嘅事，我有幾多產出純粹睇個腦有冇想寫嘅嘢。
我之前都試過用數據驅動嚟約束自己，例如話一個星期寫幾多篇，固定邊幾日發，發完做數據覆盤同分析，諗辦法找到更高流量嘅選題。
但係由上個月嘅產能嚟睇，呢個方法好唔適合我，我平時得夜晚有時間寫字，我仲要分啲時間畀CodePal做Coding，旁邊仲有星際爭霸一直喺度引誘我。
既然決定用興趣驅動，咁我接下來會將更多精力放喺一啲有意思嘅深度內容上，嚟同大家分享我喺Agent應用實踐中嘅經驗總結。
我想去寫一啲好玩有趣嘅Skill，去探索Claude Code嘅產品架構，去研究嚇Coding嘅長程任務，爭取每個階段，將呢啲探索沉澱成啲教程，都算對自己探索嘅總結。
表達形式上會用圖文去產出一啲深度內容，短文就更多用嚟記錄喺Agent實踐中嘅即時思考，比較偏短平快多啲。
同時我都唔再畀自己設定強制嘅發文週期，寫完咗滿意就發出來，冇寫出來就繼續積累，始終寫字呢件事，都係需要啲靈感嘅。
喺寫字過程中都會盡量減少AI喺寫字中嘅參與，令AI更多變成一個輔助我思考嘅角色，寫字始終要靠手敲，呢個係手藝活，手生咗就寫唔出好嘅內容喇。
多視角深度分析Skill已經上傳到Github，你可以訪問Github代碼倉，下載安裝佢到Skills文件夾裏面。
連結：https://github.com/yunshu0909/yunshu_skillshub
multi-perspective-analysis就係今次嘅Skill。
都可以直接話畀Codex或Claude Code：
安裝這個GitHub庫的Skills到Codex和Claude Code的全局Skills文件裏：https://github.com/yunshu0909/yunshu_skillshub
你可以向多視角深度分析Skill提出你嘅問題，叫佢幫手分析。
如果你對呢啲視角唔滿意，都可以話畀多視角深度分析Skill，叫佢幫手新增一啲視角進行分析。
既然呢套邏輯係從編程裏面嚟嘅，咁我最後都將佢用返喺編程度。
我做咗一個Mac專屬嘅設計師角色，叫佢嚟進行Mac產品嘅設計，然後我叫佢將CodePal重新設計一下，佢畀咗我咁樣一個首頁。
睇完我覺得效果都幾好，咁基於呢個思路都可以延展到需求討論、code coding等多個環節。
不過喺探索設計嘅過程中，我遇到咗一個新嘅問題：我有冇必要喺每一個環節，都引入咁多subagent呢？
覆盤之所以需要多視角，係因為佢本身同一個月嘅ToDo好相關，但好似CodePal呢種產品設計，一日我其實可以迭代好幾個版本，我冇必要將邏輯搞得咁複雜。
我目前用落嚟覺得：多視角分析有冇必要取決於場景嘅複雜度同影響。
如果只係CodePal迭代一個小版本，咁叫10個subagent一齊參與優化其實有啲浪費。
但係如果喺思考CodePal到底做出嚟畀邊個用、點樣做冷啟動呢啲關鍵問題，多視角參與反而係值得嘅。
講白咗就係，扭個小螺絲，冇必要用電鑽；但要裝一部電視，淨係用螺絲批都唔夠。
📬 如果你想第一時間收到更新，都可以畀我一個星標 ⭐
🌱 睇完呢篇文章覺得有幫助嘅話，歡迎同我一齊去騰訊公益捐一筆，為小朋友出一份力丫~👇
上個假期我在家覆盤3月份的公眾號內容和CodePal產品，我熟練的打開了Claude Code和它開始討論。
討論了一兩個小時後，Claude Code給了我一些建議，但我其實並不是很滿意，我並不想聽到我們應該一起努力提升執行力、儘可能壓縮產品要做的事情這類建議，這些事情我早就知道，而且我覺得這並不是我當前最大的問題。
我總覺得Opus的視角有點被侷限住了，不知道是不是餵我的語料太多了導致的，我總覺得我在照鏡子。
討論完我去水庫上溜達了一圈，路上我一邊看風景一邊在想，有沒有一種方式，可以讓AI幫我突破我現在的認知邊界？
我想到了我最近在coding場景高頻使用的一個場景。
在我每次寫完代碼後我都會讓opus調用subagent來進行審核和測試，等它自己多輪測試完後我再去驗收，通過subagent調用能夠明顯降低代碼的bug率。
既然在代碼裏這個邏輯成立，那思考討論場景能不能也複用相同的邏輯呢？
我去梳理出世界最聰明的人的語料，然後把我面臨的問題一起扔給subagent去處理，再讓它們分別給出各自的判斷和視角。
這樣一來，我就不僅僅可以看到一套鏡子視角邏輯了，我可以用多個視角，去交叉校對我自己的判斷。
同時這樣還能減少已有上下文對AI思考角度的干擾，能夠讓它更純粹一點去思考。
腦子裏冒出來這個點後我覺得非常值得探索，在到家後我就開始拉Claude Code探索這個事情。
我和opus構建了一套語料收集策略，基於這個策略我們構建了幾個獨立的顧問知識庫，然後開始進行測試。
經過多輪的顧問知識庫優化之後，我得到了一版很讓我滿意的顧問語料，我擁有了10個顧問。
於是我開始用它們，去分析我三月份的內容和產品落地情況。
這10個顧問給我做了一輪非常詳細的分析，光是把報告看完，我就花了差不多半個小時。
每個顧問都從自己的視角給出了一份獨立分析報告，而主對話裏的opus，則基於他們的觀點，幫我做了一份彙總分析。
因為報告比較長，下面我就抽一部分顧問分析很觸動我的點，然後來根大家展示一下。
先從總視角開始吧，opus幫我彙總了一份大家的共識和分歧內容。
共識內容倒是出奇的一致在diss我，他們點出來了我在執行力中最大的問題，我愛覆盤這個事情高於了產出，通過覆盤確實能讓我感覺到我自己在認真和AI一起幹活，但實際上也確實沒啥產出。
當opus只有一個視角跟我說覆盤太多的時候，我可能會覺得opus理解不了我到底想要做一個什麼樣的事情。
但當10個opus+多維視角一起diss我說覆盤太多了執行力太弱了，我會認知思考一下減少覆盤這個事情的頻率。
不得不說，還是人多力量大啊。
目前4月份我還沒開啓過覆盤，我更多時間都在coding和碼初稿。
主視角報告跟大家展示全了，接下來子視角我也跟大家分享一下，10個視角完整看完需要花半個小時，我就抽樣5個有代表性的內容跟大家分享一下。
1. 10x增長視角：它提供給了我一個很有意思的過濾器視角，當我準備要做一件事情的時候，可以先問自己一句：這件事有沒有10x的可能性？如果沒有，那可能就不值得投入太多精力。 2. 馬斯克視角：它直接指出來了我時間分配的問題。它覺得我花了太多時間浪費在討論和思考上了，然而我自己真正的主線應該放在內容生產上，其它的事情都是圍繞這個主線展開的。
3. 張一鳴的算法視角：它提出來了我最近有點忽略的一個問題，我的讀者到底喜歡看的內容是什麼？對他們來說內容的獲得感是什麼，這個點我最近還真沒怎麼花精力研究，我得找個時間認真琢磨一下。
4. 喬布斯的產品視角：它問了我一個很關鍵的問題：你能不能一句話講清楚自己到底在做什麼？這個問題蠻扎心的，我確實好像也沒太想清楚，我只是想讓AI編程的自動化程度和落地再高一點，邊幹邊想吧。
5. 內容大咖MrBeast的視角：這個視角是更偏內容側的評價了，它主要是對我的標題進行評分，看完了我感覺有不少優化的空間，也許我那篇openclaw標題名稱再改改，流量還能網上再走一截。
看完這些內容後，我發現了很多平時我意識不到的問題，於是我開始去想：接下來到底該怎麼做？
這10個傢伙放在一起，不僅僅有diss我的共識，他們在路徑選擇上還有一些分歧點，而這一點也蠻有意思的。
比如說代碼優先、內容優先、興趣優先，每個顧問在自己的視角下，給出了他們認為的最優路徑。
但這三個事情必然是不可能同時存在的，我必須從裏邊選一個作為我接下來一段時間的主線。
我琢磨了半天，其實發現我更喜歡的事情是張小龍視角下的興趣驅動。
原因也很簡單，我本身就是這種性格。大家也能看到我的更新頻率，固定更新其實是一個蠻難的事情，我能有多少產出純看腦子裏有沒有想寫的東西。
我之前也嘗試過用數據驅動來約束自己，比如說一週寫多少篇，固定哪幾天發，發完做數據覆盤和分析，想辦法找到更高流量的選題。
但從上個月的產能來看，這個方法非常不適合我，我平時只有晚上有時間碼字，我還得分點時間給CodePal做Coding，旁邊還有星際爭霸一直在誘惑我。
既然決定用興趣驅動，那我接下來會把更多精力放在一些有意思的深度內容上，來和大家分享我在Agent應用實踐中的經驗總結。
我想去寫一些好玩有趣的Skill，去探索Claude Code的產品架構，去研究研究Coding的長程任務，爭取每個階段，把這些探索沉澱成一些教程，也算對自己探索的總結。
表達形式上會用圖文去產出一些深度內容，短文則更多用來記錄在Agent實踐中的即時思考，更偏短平快多一點。
同時我也不再給自己設定強制的發文週期，寫完了滿意了就發出來，沒寫出來就繼續積累，畢竟碼字這件事，還是需要一點靈感的。
在碼字過程中也會盡可能減少AI在碼字中的參與，讓AI更多變成一個輔助我思考的角色，碼字還是要靠手敲的，這是個手藝活，手生了就沒發寫出來好的內容了。
多視角深度分析Skill已經上傳到Github，你可以訪問Github代碼倉，下載安裝它到Skills文件夾裏。
連結：https://github.com/yunshu0909/yunshu_skillshub
multi-perspective-analysis就是這次的Skill。
也可以直接告訴Codex或Claude Code：
安裝這個GitHub庫的Skills到Codex和Claude Code的全局Skills文件裏：https://github.com/yunshu0909/yunshu_skillshub你可以跟多視角深度分析Skill提出你的問題，讓它來幫忙分析。
如果你對這些視角不滿意，也可以告訴多視角深度分析Skill，讓它來幫忙新增一些視角進行能分析。
既然這套邏輯上從編程裏來的，那我最後也把它用到了編程裏。
我做了一個Mac專屬的設計師角色，讓它來進行Mac產品的設計，然後我讓它把CodePal重新設計一下，它給了我這樣一個首頁。
看完我感覺效果還不錯，那基於這個思路也可以延展到需求討論、代碼Coding等多個環節。
不過在探索設計的過程中，我遇到了一個新的問題：我有必要在每一個環節，都引入這麼多subagent嗎？
覆盤之所以需要多視角，是因為它本身就和一個月的ToDo強相關，但像CodePal這種產品設計，一天我其實可以迭代好幾個版本，我沒必要把邏輯搞得這麼複雜。
我目前用下來感覺：多視角分析是否有必要取決於場景的複雜度和影響。
如果只是CodePal迭代一個小版本，那讓10個subagent一起參與優化其實有點浪費。
但是如果在思考CodePal到底做出來給誰用、如何做冷啓動這些關鍵問題，多視角參與反而是值得的。
說白了就是，擰個小螺絲，沒必要上電鑽；但要裝一台電視，只拿螺絲刀也不夠。
📬 如果你想第一時間收到更新，也可以給我一個星標 ⭐
🌱 看完這篇文章覺得有幫助的話，歡迎和我一起去騰訊公益捐一筆，為孩子們出一份小力~👇