AI coding 時代，模組到底該按什麼拆？我要找的不是模板，是拆分背後的方法論

作者：#忆江南 板块：#开发调优 做 AI coding 一年多，前後六七個專案，每個都寫過設計文件，寫法也換過好幾種：純手寫、OpenSpec、大文件瀑布加審批、Matt Pocock 的 skills。每次開新專案都卡在同一個地方： ▎ 模組怎麼拆、接口怎麼定、上下游怎麼接？ 後來我想清楚了：拆成什麼樣是表，按什麼拆才是裡。 文件寫在哪、用什麼格式，換個工具就變。真正讓我每次都沒把握的，是「這裡為什麼該切一刀」「這兩塊為什麼該合併」的判斷依據。沒有這個依據，拆出來的結構只能靠感覺，換個需求就開始走樣。 我查了三個熱門工具，結論是：它們給的都是表 這三個工具我都直接讀了 10 月中旬最新版的原始碼： OpenSpec：技術棧寫在設定檔的一段自由文字裡。設計文件可寫可不寫，格式自由，跟著單次變更一起歸檔。至於按什麼標準拆模組，一句都沒有。 spec-kit：技術方案裡有 9 行固定的技術棧欄位、一份目錄樹、一份對外接口契約，模組內部只要求寫資料模型。一樣沒有講拆分依據。 pstack（Cursor 工程師 poteto 開源的一套 agent skills）：三家裡唯一講到「裡」的。它的拆分判準大致是： 按「模組擁有什麼知識」拆，不按執行順序拆。不要切成「讀取、驗證、轉換、儲存」四個模組，那樣同一套規則會散在四處。 介面要小，藏住的複雜度要大。呼叫方得串好幾個方法才能完成一件事，就是拆錯了。 每份狀態只有一個擁有者，別人想改得透過它。 最有意思的一條：假設每個貢獻者都是agent，它只看得到自己打開的幾個檔案、會照抄最近的範例、會走最短的能編譯通過的路。所以結構要設計成「從一個檔案看起來對的改動，對整個 repo 也是對的」。 還有一個發現：spec-kit 作者自己 repo 的 design/目錄裡，手寫了官方模板沒要求的東西，包括誰負責什麼、誰不能碰什麼、接口欄位、並行規則。看起來作者做自己的專案時，也需要模板以外的那一層。 我的困惑 經典的拆分理論我知道一些：Parnas 的資訊隱藏、Ousterhout 的深模組、DDD 的限界上下文、康威定律。但我拿不準兩件事： 這些理論各有側重。實際拆的時候，你們以哪條為主？衝突時怎麼取捨？ 讀程式碼的從人變成了 agent，拆分的依據要不要跟著變？pstnt」讓我覺得要變，但我還說不清楚該怎麼變。 想問問大家 你們拆模組時，主要依據是什麼？業務領域、變更的原因和頻還是別的？ 有沒有一條你實際在用、能判斷「這裡該切」或「這兩塊該合」的標準？ 經典理論在 AI coding 下有哪些還成立、哪些需要修正？ 拆分原則怎麼落地成可以檢查的東西，例如依賴規則、lint、型別，而不是停在文件上？ 有沒有推薦的書、文章，或拆得好的真實專案？