最近一直在聊Agent、聊Vibe Coding。

但是在給越來越多的朋友安利的時候，發現其實，一直有一個問題被忽略了。

就是，真正卡住大多數人的，是自己沒有一個標準的工作流程。

特別在創造一個你想要的軟件或者程序的時候，沒有標準流程，其實是一件非常可怕的事情。

所以，我想給大家分享一個我自己在vibe coding的時候，一直在用的一個超好用的幫我提高Coding體驗的一個插件，也基本上是我推薦所有人都必裝的一個，基本上Claude Code、Codex、OpenCode、Cursor啥的全都適配，都可以裝的。

它在Github上，已經有11萬的star數了。

名字叫，Superpowers。

GitHub 鏈接在此：

https://github.com/obra/superpowers

也是Claude官方的認證插件，上架了Anthropic的官方插件市場，安裝量沖到了23萬，排名第二。

第一名就是那個大名鼎鼎的讓你的設計變得更有品味的超牛逼的Skill，Frontend Design。

Superpowers其實不太能算一個傳統意義上的工具，我覺得他更應該被定義為一套指導Agent如何完成任務的系統。

因為坦誠的講，絕大數的Agent，在進行任務的時候，天然都傾向于拿到任務就開始寫代碼，會跳過設計、跳過測試、跳過 review，然后產出一坨不可維護的東西。

而Superpowers會強行在Agent的鏈路里面插入一套結構化的工作流，再結合著14個skills的組合，能讓你最終的任務產出質量，上升幾個檔次。

我做了一張圖，可以簡單的讓大家看看這些Skills，每個有啥用，以及是怎么組合的，不用細看，大概知道原理就行。

所以其實可以看出來， Superpowers本質上，是一個由14個Skills組成的工作流系統，而且，這個系統，并不止可以用在開發上，因為創造一個東西的本質上都是類似的。

都是規劃 - 拆解 - 執行 - 審查 - 復盤。

所以，你也完全可以拿來做營銷方案、做PPT、做數據分析等等，基本都是相通的。

非常的好用。

我覺得可以先給大家看看，如果不用Superpowers的時候，我們拿Claude Code或者Codex開發產品的原生流程會是什么樣子的。

一般流程，其實都非常的簡單，都是要先寫需求文檔，也就是做規劃再開發。

我們拿Claude Code舉例子，在這里面，規劃就是Plan模式。

比如說，團隊有個小伙伴跟老羅一樣，有ADHD，經常看文章就很容易容易分心，最近我們就在說，是不是可以做個閱讀輔助的小東西。

就這個需求，我們打開Claude code，在對話框里面敲個/plan，進入到規劃模式。

把需求簡單的描述一下，幫我做一個面向 ADHD 用戶的中文網頁閱讀器應用。

讓他來開始去做一個計劃。

然后，他會先調研一輪，一口氣甩出好幾個問題讓你回答，這些問題其實你會發現，他們是并行的，之間沒有前后因果關系。

比如它問我使用場景、技術棧偏好，還有要加哪些ADHD友好特性，這塊我選了仿生閱讀，就是加粗每個單詞前幾個字母，一個比較經典的緩解ADHD的方法。

我回答了一下，然后它就直接開干了。

幾分鐘之后，就直接做出來了，給了你一個東西，也沒有審查啥的。

我們現在看的話，是不是好像沒啥問題？

但，其實有大問題。。。

因為這個仿生閱讀，其實是為英語設計的。

英文閱讀這么做沒問題，但是你中文，是完全不行的話，閱讀起來直接亂套了。

原因很簡單，英文單詞之間有空格，能找到邊界，中文字和字之間沒有空格，根本找不到詞的邊界，效果就會很別扭。

除了樣式它不太行，它對國內用戶的適配也很差。

我們讀中文，用得最多的是公眾號、知乎這些平臺，結果這個插件根本沒法正常讀取。

跟我想要的閱讀器差了十萬八千里。

不過坦誠的講，這確實也怪不到Claude Code頭上。

因為ADHD閱讀輔助本身就是個專業領域，需要做針對性的調研，還得考慮中文場景的適配、國內平臺的兼容。

它問我的那幾個簡單的不痛不癢的問題，就肯定覆蓋不了全部需求，那也很難做出你心中想要的答案。

而大多數的用戶呢，心里也就是只有一個模糊的想法，他知道他要解決一個具體的問題，但是具體要做成啥樣、該用什么路徑去實現、邊界在哪，大多數人，是真的想不清楚的。

所以在非Agent的時代，我寫過一篇文章，叫

其中有一個Prompt心法，就是叫做蘇格拉底式提問法，用一段Prompt，讓AI在動手之前，先一個問題一個問題地拷打和追問你，直到把需求聊透了再開始。

然后才給出方案

在Agent時代，其實也差不多，只不過從一個Prompt，升級到了流程中的一個Skill。

我們再用Superpowers這個東西，再來開發試一下。

首先自然是安裝這個插件了。

你直接跟你的Agent說一句話就行了：

https://github.com/obra/superpowers

安裝完以后，記得要重啟一下才能生效，不是熱加載。

還是那個ADHD閱讀器，我們再試試。

一模一樣的Prompt發過去。

你就能看到，開始調用Superpowers和工作流了。

它做的第一件事，是先問我用戶會怎么用，這一步就直接解決了那些抓取不到的墻的問題。

但跟剛才Plan模式的并行提問完全不一樣，Superpowers一次只問一個問題，你答完這個，它才決定下一個問什么，就是剛才說的蘇格拉底式提問，這樣才能保證這些問題真的能夠非常深入而不是浮于表面。

我選了瀏覽器擴展，然后它又問了核心功能，到這一步的時候，我看著這些選項愣了一下，因為我自己也沒那么熟，所以我說直接我都不是很了解，你去給我查一查吧。

它就真的去查了，回來給了我一份調研結果。

然后給了我一個建議，整理出了核心功能優先級的清單。

比如仿生閱讀，就是上次加粗前幾個字母的方案，它直接標了弱但用戶喜歡，還引用了研究說這玩意對ADHD用戶中文閱讀并沒有顯著的改善。

我就繼續讓它幫我選了幾個功能。

之后他就繼續往下拷打我，逼著我想清楚，比如目標瀏覽器是哪個？中文分詞庫有沒有偏好？UI語言和風格？

也就是逼著你想清楚。

這個演示的項目其實不是很復雜，但是當你開發一個大型的項目的時候，你就會真正的發現，那種被拷打的汗流浹背的感覺了。

在問題你都回答完之后，AI它也大概知道了你的需求。

這時候，它跟Plan模式不一樣的點，就是它會提出三個架構方案，每個方案的優缺點、適用場景列得清清楚楚。

讓你來挑一個，當然你也可以直接用它推薦的。

我直接選了B，我不想要混合方案。

然后它又讓我挨個確認不同的細節。

整體架構、功能模塊的詳細設計、控制面板、數據流與存儲等等等等。。。。

又一次確認的我汗流浹背，感覺到了自己在AI面前的菜雞與渺小。

等所有東西都確認完以后，他才終于，把整份的設計文檔給寫好，放在了本地。

巨長巨詳細的一份。

所以很多朋友在開發的時候，感覺最后開發的東西不是你想要的，其實真的不是AI菜逼，是你的需求并沒有說清楚。

規劃2小時，執行10分鐘，我現在越來越覺得，執行真的沒有那么重要，前期的規劃想清楚，才是最最最最最重要的。

我們自己做AIFUT的票務小程序的時候，其實就是因為盲目自大以及AI輔助流程不規范，很多用戶需求前期沒有考慮清楚就直接上線了，邊界風險考慮的也不清楚，這其實就是前期的規劃問題。

所以現在我的感受是，AI來開發已經夠快了，真正該花時間的地方是動手之前。

你需要不斷的被拷打，不斷的跟團隊分析所有的邊界情況，還必須有老師傅坐鎮和把關，最后才能出來一個能真正向用戶交付的東西。

說回Superpowers，第一步的規劃其實就全部OK了，上面的所有的東西，其實都還只是，Superpowers流程中的第一個Skill。

也就是brainstorming（頭腦風暴）。

對，第一個。

設計文檔確認之后，你是不是以為，它應該開始直接寫代碼了？

但這個時候，第二個skill開始接入，用using-git-worktrees這個Skill，創建了一個隔離的工作區。

就是從主分支拉出一個新分支，所有后續的開發都在這個新分支上進行。主分支的代碼不受影響，新分支上不管怎么折騰都不會波及原有的東西。做完了覺得沒問題，再合并回去。

這就是做隔離，很多人都是直接就在之前的項目上改，然后沒有版本隔離，就直接全部改炸了，那其實是個很不好的壞習慣。

再接下來，第三個Skill，writing-plans skill登場了。

注意啊，這一步依舊還是沒有寫代碼。

它干的事情是，把剛才那份設計文檔拆解成一步一步的開發任務的清單，而且是拆成2～5分鐘就能完成的開發任務清單計劃。

這個特別有意思，因為他們的目標，原話是：“讓一個沒有品味、沒有判斷力、沒有項目上下文、而且厭惡測試的熱情初級工程師也能照著做。”

當時看到給我笑樂了。

所以啊，你用了Superpowers，其實并不是只能用Claude Opus 4.6，其實越是能力一般的模型，反而得到的加持會越大，這就是這個Skill發揮的作用。

而且拆細了還有一個好處，就是每完成一個小任務就能驗證一次，出了問題馬上能發現，不用等整個項目寫完了才發現直接爆炸了。

這一點，到了執行階段體現得更明顯。

這一步完事了以后，終于，要到了寫代碼的執行階段。

這時候，它會調用subagent-driven-development這個Skill。

直接開了好幾個子Agent，去做上面所有的事情。

每個任務開發完，也不是直接就扔給你了，而是會過兩道檢查。

第一輪派一個獨立的審查Agent，看這個任務到底有沒有按需求來，該做的有沒有做到，不該做的有沒有瞎加，有沒有神經病一樣整出一堆毫無意義的過度設計。

第二輪再派一個審查Agent，查的是代碼質量，這一輪主要就看代碼寫得規不規范，好不好維護。

兩道審查都不通過就打回修改，改完再審，然后如此循環，直到都通過為止。

這10個小任務，終于開發完了，審查還沒完，下一個環節，requesting-code-review這個skill會派一個最終審查Agent出來，把所有代碼從頭到尾通看一遍。

之前每個任務的審查，盯的是局部，這一輪盯的是全局，看模塊之間能不能集成、有沒有遺漏、整體一不一致。

最后收尾，跑一遍驗證，確認所有測試通過，沒有殘留問題，然后把代碼合并回主分支，清理工作區。

最后，終于，做完了。

我們看下這個閱讀器的效果。

它有兩種很實用的閱讀模式。

一種是詞性著色，會把名詞、動詞、形容詞用不同顏色標出來，句子結構會清楚很多。

還有一種模式是段落聚焦，正在閱讀的這一段會被高亮，其他段落會壓暗，適合讀長段落，能明顯減少周圍文字帶來的干擾，避免跑神。

對ADHD用戶來說，最大的敵人就是注意力被周圍的文字分散。

這個閱讀器，就是把閱讀重點變得更清楚，讓該看的內容更容易被看見，周圍干擾少一點，整篇讀下來就不會那么累了。

而且這次，因為用的插件方案，所以公眾號、知乎這些頁面全都能正常讀取了。

真的是一遍過，讓我省心太多太多了。。。

這樣充分的說明了一個AI時代，正確的工作流程應該是啥樣的。

規劃2小時，執行10分鐘，審查1小時。

大概就是這樣。

除了上面我提到的一些觸發了的Skills，還有一些其他的我沒提到的Skills，我就不詳細提了，大家用的時候到時候可以自己去試一下。

這個插件，是我推薦大家的，必裝插件。

在我心中，可能是跟skill-creator平級的必裝插件了。

相信我，絕對能大大提升你的工作質量。

還有工作效率。

以上，既然看到這里了，如果覺得不錯，隨手點個贊、在看、轉發三連吧，如果想第一時間收到推送，也可以給我個星標?～謝謝你看我的文章，我們，下次再見。

>/ 作者：卡茲克、可達

>/ 投稿或爆料，請聯系郵箱：wzglyay@virxact.com