一條指令，與它背後死掉的兩代開發流

處決之日

2026 年 6 月某日，一套富含多重驗證與數支自動化腳本的第二代 AI 開發流隆重上陣，
當天後端、前端、邊緣端各跑一輪，帶來的結果是：

浪費更多的時間、主 context 爆炸、所得結果全然不對。

當日緊急全部下架，隔天在屍體上破土而出的是第三代：
全團隊唯一使用的那條開發指令：/develop

一條指令

工程師打開 Claude，輸入 /develop，闡述需求，對談幾輪後按下確認，跑到旁邊喫了杯咖啡，
回來後看著 Claude 的回報，討論了一個它主動跳出來問的取捨，便去上了個廁所。

最終紀錄顯示著 35 次派工、16 檔改動、72 條專項測試加全套數千條全綠；
終審的 17 個審查 agent 抓回 1 個 critical 並自我修正完成。

需求達成，而這中間涵蓋：

1. 需求訪談與 UI 設計：主 agent 派發研究員查看現有程式並綜合商業邏輯文件考究詰問
2. 自主計畫與跨端交接文件：讓前後以及邊緣端人員能共享開發進度
3. 開發者確認一切就緒輸入「GO」
4. 程式撰寫、測試案例、程式審查：主 agent 派發各式專責 subagent 達成目標
5. 功能文件更新：將面向 QA 與使用者的操作情境以及從程式看不出來的商業抉擇記錄下來
6. 定期自我檢討：以不同維度回首整趟 run，記錄所有摩擦以供未來迭代
7. commit 與 PR 生成、工單回報

遙想年初為了做到以上大半的事，同時養著二十幾個 skill。
如今，一個指令便達成了。

延伸閱讀：解剖 /develop：AI 憑什麼不用問你

三代史

我們的專案是 monorepo，內含多個 project，代表三端工程師都在同一個 repo 開發，而 AI 也毫不例外。
而目標就是在這此專案下創造出每位工程師皆能使用的開發流。
然而每代更迭下來都是同一種死因：規則爆炸，只是是不同的根因而產生的爆炸。

第一代 家族：角色堆疊

每一個角色都是一個 skill：
寫程式的叫 coder；寫測試的叫 tester；
審查的叫 reviewer；更新文件的叫 syncer；統籌全局的叫 team-lead；
還有其他角色就不一一列出。

三端所需知識不一樣，做事的順序也不一樣，
前端要看 UI、後端要設計資料庫、邊緣端要處理協定邏輯。
因此同一個角色，三端各補一個前綴以因應不同的細節：
be-coder (專注 backend 的 coder),
fe-tester (專注 frontend 的 tester),
edge-team-lead (管理 edge 開發流的 team-lead)

後端工程師只要呼叫 /be-team-lead 闡述需求，他就會自己判斷並協調其他 skill 開發後端領域的 feature。
三端內容大同小異，能動，但檔案卻是實實在在的三倍，每次優化皆是痛苦。
疊床架屋，好不快活。

延伸閱讀：跨專案的開發，我怎麼確保 coder 遵守各自專案的規則？

第二代 super-*：流程堆疊

Claude Code 於五月底推出了 workflow 功能：
一支腳本編排整隊 subagent，步步有 schema 把關，全程不需要人。

這不就是我夢寐以求可以把所有步驟用官方工具直接自己跑一輪的功能？
立刻把第一代的精華萃取出來，鋪成一條全自動的軌道：
/super-plan 用 workflow 把所有需求與現況調查清楚。
/super-develop 用 workflow 把程式、測試、審查一次跑完。
/super-doc 用 workflow 把需求全部歸檔。

自己實跑一兩次，覺得不錯，
當時也認為規則已足夠嚴謹。
於是六月某日全團隊上線。

本來期待各端都能比上一代跑得更好，
結果上線那天，成了開場提及的處決之日。

上一代堆的是角色，這一代堆的是流程：

• context 爆掉：所有步驟塞進同一條 flow，主 context 比程式先陣亡；
• 一趟跑太久：十行 code 的改動，也得勞師動眾走完整條巨型 workflow；
• 效果不對標：實作偏題嚴重，中途出狀況也無法跳出來問開發者，一去不復返；
• 維護不完：monorepo 裡每個 project 都得定義自己的派發邏輯，每次故障改的都是 workflow 的定義，而不是程式。

workflow 不是拿來把所有流程跑完的，而是拿來做完全確定的一件事。

super skill 跑死了，但它卻有辦法在一天內被翻新，
因為我知道只是容器內的精華裝錯了地方。

第三代 /develop：收斂

前兩代的治病方式如出一轍：角色不夠加角色，流程不順加步驟。
直到這時我才想起軟體工程那古老的名言：

最好的程式，便是不寫程式。

開發入口不需幾十個，一條便夠；
CLAUDE.md 與 .claude/agents 不必塞滿全部專案的規則，知識只在需要的地方出現，root 那份目前只有 30 行；
模型更聰明了，那就讓它自己判斷十行的改動該是重裝上陣還是輕裝襲擊吧；
模型又進化了，那就讓它專注協調，不動手，讓 subagent 自己帶回證據回報，主 context 自然就瘦了吧；
終歸需要人的，但確認需求後的路途上人類只需要回應跨端契約改動、途中需求變更、不可逆操作等等最精華的幾種狀況。

減法 > 更改 > 加法，是此階段的教條。

誰死誰活

如今排開屍體，死因出奇地整齊：

• 知識準則：今天抄專案現況，明天程式改完就過期；
• 模型釘選：寫死派什麼模型？明天模型升級就淘汰；
• 流程儀式：為了滿足儀式感？不如要求每次推進都留下可核對的證據。

而一路保留到現在的，有一類規則特別顯眼：

邊界在哪裡。

coder 不准碰測試檔、orchestrator 不准寫程式、subagent 只准讀自己的角色檔。
各司其職，在全能的 AI 到來之前，邊界有助於使 agent 高效率的專注達成一件事。

同時還有一個前提：

全公司共用同一套規則，不依賴本機狀態。

通用規則絕不藏在某人的本機；規則不進 git，就等於不存在。
畢竟流程早已不是個人的玩具，三端工程師每天輸入的是同一條指令：
需求隨他談、模型隨它換、輕重隨 AI 自己判斷，彈性放到最大；
但各專案該做的審查與驗證，都得在交付前完成。

延伸閱讀：規則怎麼死？沒死就有用？

自我迭代

你在預想一個問題，然後你創造方法解決它，事實上問題不曾存在過。
有人以為某些注意事項需要提及，就自主加了進去，像是「注意不要改壞現有功能」這種句子。
有人為了防止下次出錯，在同一份描述裡舉了某支模組的實作範例、smoke test 細節，其中一條甚至自己還不小心標下「today only」。
這些都是雜訊：一種無關緊要，一種根本不通用。
然而人類終究在 PR 幾千行中漏掉了它們，於是它們留了下來，跑進 AI 判斷，最後花掉無謂的 token 去推理。

我怎麼知道這描述是否必須？我不知道。
除非結果的體感明顯有問題，否則我們根本不會這麼詳細的分析流程中的每個字句，遑論字句之間的因果。
然後，前兩代逐漸膨脹的毛病又犯了。

不過，「retro」的思路出現了。
在收尾時自主分析整趟哪裡出現摩擦、開發者出手糾正了幾次、哪道閘門重試過，
回頭檢視流程描述，哪段是「缺規則」，哪段是「有規則沒被遵守」，哪段「根本不需要」？
全部記成一份報告。
報告累積，定期收割：有價值的教訓升級成規則、沉進該住的層，然後刪掉。
數個月裡多波清倉，目前最大一波一次消化 29 份，
29 份人類親手運用而產生的摩擦。

但要怎麼消化這些摩擦、怎麼收束 context 的浪費、怎麼定義更好的結果？
最終怎麼沉澱到流程本身。
甚至再朝根源邁進一點，如何定義 retro 要怎麼分析？它遵循的憲法是什麼？
那又是另外一段故事了。

支線撰寫中：22 份摩擦：retro 的收割季

為什麼不用現成的

開源社群的套件遍地都是：
BMAD 把整個敏捷團隊做成 agent，analyst、PM、architect、QA 各司其職；
spec-kit 用規格先行，把開發鋪成一條 /specify 到 /implement 的軌道；
claude-flow 乾脆讓幾十個 agent 組成蜂群，全自動跑完長程任務；
Superpowers 則把 brainstorm 到 TDD 的每一步紀律，都磨得比我的精緻。
每一套都比我的漂亮，為什麼要自己造輪子？

堆角色的，是我親手埋葬的第一代；放手讓 agent 全自動跑到底的，是我處決過的第二代。
這些問題帶來的經驗，終究是原本的維護與交接問題能不能解決。

採用一個框架，得先分析它的流程與我們的做法怎麼接；
而我們最值錢的流程，偏偏全是自己家的：
跨端交接是一份 PLAN.md 三端接力，可以跨工程師又跨 session；
工單回報給 PM 是一道 SOP，什麼樣的角度、什麼樣的結論才能讓人類直接買單；
commit 是一道總結，足以讓 agent 分析一個 sprint 的進度而產出交付的 release note；
這些團隊自己的要求，換哪套框架都得另外接上，並持續維護。

而故障之後，retro 之所以能問「缺規則，沒遵守，還是根本不需要」，是因為每條規則都出自你手；
套別人的框架，摩擦會多出第四種：「它的規則不適合我們」，
而且你永遠分不清眼前這個，到底是四種裡的哪一種。

自己造當然慢。但年初大家都站在起跑線上，混亂之中百家爭鳴，沒有哪一套熟到可以直接賭；
慢慢造繳的學費，換來的是每一條規則我都知道它為什麼存在，也判得出它哪天該死。
處決當天，能分得出什麼是精華、什麼是容器，而讓我有底氣一天之內拆掉重蓋，
靠的就是這筆資本。第一代三倍檔案的維護之痛，就是學費。

閉門造車不代表事事苦幹蠻幹：
哪天某段流程拆得夠小夠純，而全世界已經幫你把它做完整了，換上去就是唯一正解。
但前提是，你得確定你換得動。

支線撰寫中：但我會怎麼死

一個人的開發流，拉的是他自己的上限；
全公司共用一條開發流，守的是所有產出的下限。

2026 年 7 月某日，一張 bug 卡發給了前端，
前端看了看，發現是一個簡單的後端問題。
/develop 指令下去，半小時後發了 PR 給後端。
而修補的程式與新增的測試，與後端本身的架構與風格如出一轍。