背景和問題
說起模塊/包，幾乎是大部分語言都有的概念，因為一個項目會很龐大，如果單純只用文件做隔離，文件可能幾千上萬個，所以需要在項目和文件之間獲得一個平衡，這個時候就有包和模塊的概念。比如python 你把一個目錄放一個__init__.py 文件，就是一個包。這里我們不區分模塊和包，我們都把他們當做一個虛擬的文件租概念來理解。
當等大語言模型開始深度參與軟件開發時，我們發現了一個有趣的現象：**傳統的模塊代碼組織方式并不適合AI理解和處理**。
想象一下這樣的場景：你向AI助手描述一個需求，希望它幫你實現一個功能。
但是面對一個龐大的項目，AI 往往有點望洋興嘆，他會嘗試查看目錄，通過關鍵字檢索一些關鍵代碼，亦或者找幾個名字可能有點像他要尋找的代碼看看。大部分情況，大模型實際上依賴于你有良好的目錄結構命名以及碰點運氣。
所以在傳統的開發模式下，對AI而言最大的挑戰是：他很難看到你項目的全貌，這包括模塊的作用，以及模塊之間的依賴。而在我們實際的項目迭代中，你的每個需求大概率是要AI能夠理解并且找到合適的已有模塊去作為依賴，并且復用他們的功能從而實現新的需求。
你或許說，那我給每個模塊寫個文檔，大模型不就知道了么，這個問題其實由來已久，只要是人類在維護文檔，這就意味著文檔很快就會和代碼更新脫節，維護文檔實在是個龐大的工作，這就導致現存的大量項目能有一個項目文檔就算不錯了，很難說在代碼中有對模塊的每個文檔。
那能不能用AI來給每個模塊寫文檔？答案是只能部分。如果模塊較大，超出大模型窗口，大模型就難以準確的寫出文檔。此外作為人類智慧的延伸，以及和人類溝通的必要，大模型也**更擅長看文檔而不是看代碼。?如果模塊過于龐大且復雜，這很容易超出大模型的能力范疇。
所以傳統的模塊其實并不適合 AI 理解和維護：
1. 模塊的設計是按人類的喜好，可能是按功能，可能是按其他的維度，較大的模塊導致大模型無法將整個模塊放進窗口，從而很難真正的理解這個模塊。
2. 模塊可能非常多，不可能每次都去加載每個模塊的所有源碼區理解模塊的使用方式。
當前限制大模型的軟件開發能力根源是無法對項目有很好的理解，而不是寫代碼的能力。我們相信，當前大模型寫代碼的能力已經足夠好。但是每次大模型看到一個項目，對他來說都是全新的，他每次都需要探查這個項目。所以帶來了加大的困惑。
AC模塊概念
為了解決在AI時代，項目結構組織的難題，我們提出了 AC模塊的概念。
AC Module（Auto Coder Module）是一種全新的以AI為中心的模塊化組織方式，專為AI時代設計。
AC 模塊的實現很簡單，當一個源碼文件夾包含了 .ac.mod.md 文件，則表示這是一個 AC 模塊。
它的核心理念可以概括為：
1. 以AI為中心的設計思想
傳統模塊化主要考慮人類開發者的需求，而AC模塊首先考慮的是：**如何讓AI更好地理解和使用這個模塊？**
-?每個模塊都有完整自描述文檔 .ac.mod.md
-?模塊需要有一組外部可訪問的API
-?使用AI友好的Markdown格式
-?嚴格控制Token數量，確保所有源碼在模型窗口內（通常200ktoken以內）
- ?.ac.mod.md 是可以讓大模型自己維護的更新而無需人工來完成。
2. 語言無關的模塊定義
AC模塊不依賴特定的編程語言或框架：
```
一個AC模塊 = 功能源碼+ AC文檔?
```
無論是Python、JavaScript、Go還是Rust，AC模塊的組織方式都是一致的。 其中
3. .ac.mod.md?
每個AC模塊都是一個**自包含的知識單元**，其 .ac.mod.md 包含了如下內容：
-?模塊概要
- 模塊目錄結構
-?對外API使用示例
-?內部核心組件/類描述以及mermaid關系圖?
-?AC模塊依賴關系（是否依賴其他AC模塊）
-?測試和驗證方法（特別重要）
? AC模塊的關鍵特性：Token限制約束下的精簡設計實現了完全AI托管
這是AC模塊最重要的約束條件。每個模塊的總Token數必須小于大模型的上下文窗口，這可以讓大模型完整的實現自動化。當一個需求來臨后：
1. 先閱讀本模塊 .ac.mod.md ，對模塊有完整了解，根據需求決定是否閱讀依賴模塊的 .ac.mod.md
2. 修改模塊后，會自動根據 .ac.mod.md 提到的測試和驗證方法執行對應的測試集命令，并且根據命令自動修復修改改出的問題。
3. 通過測試驗證后，自動更新 .ac.mod.md?
最終可以實現AI完全自主維護一個模塊，人類最多只需要干預測試和驗證集。
老項目如何實現AC模塊化改造
在最新版的 auto-coder (1.0.0) 版本中，我們會內置了AC模塊的支持。你可以很方便的在 CLI（交互式非交互式），Python API, ?Web 版產品中體驗到。在執行 atuo-coder.chat 后，進入交互式命令行窗口，這個時候你可以這么做：
/auto 把 @src/a/b/c 里的功能拆分成兩個 AC 模塊，第一個是xxxx 放在xxx目錄，實現什么，第二個是 xxxx ，具體功能是啥此時 auto-coder 會自動完成某個”傳統“模塊到 AC 模塊的轉化。對于特別復雜的情況，auto-coder會自動采用todolist 工具，確保自己支持超長超復雜的任務。
auto-coder 作為一個已經開發了一年半的項目，體量也還算可以。我們來看一個具體的case. 我們先來看看 prunner 模塊的大小：
一共是 17k, ?遠小于常見 128/200k 窗口，符合AC模塊要求。接著你只需要一句話就可以將其轉換成 AC模塊：
將?@src/common/pruner 轉換為?AC?模塊大模型就會閱讀和轉換該模塊。大家可以看到我們的 .ac.mod.md 的效果
詳細的可以看這里：
https://github.com/allwefantasy/auto-coder/blob/master/src/autocoder/common/pruner/.ac.mod.md
新項目如何創建 AC 模塊
這個就簡單太多了，你可以這么說：
/auto 創建一個?AC模塊，該模塊主要功能是balalaxxxxxx剪枝功能請使用?@src/autocoder/common/pruner/.ac.mod.md 模塊這里你就申明了創建AC 模塊，復用哪個已有AC 模塊。如果你不清楚應該復用哪個AC模塊，或者你可以這么寫：
/auto 創建一個?AC模塊，該模塊主要功能是balalaxxxxxx請先查看項目里已有的AC模塊，有可以復用的功能盡量服用，不要什么都自己實現。這樣大模型自己就會去探索項目里已經有的AC 模塊，從而更好的依賴已有的AC 模塊開發新的模塊，避免大量冗余的代碼的開發，也讓他對項目自身有更好的了解。
如何零review實現對AC模塊的改造
自從引入AI輔助編程以后，大家發現 review 工作巨大。AI 快速產生代碼和PR的能力瞬間沖擊 review 的工作。使用 AC 模塊后，人類的主要工作將會轉化為”編寫測試和驗證case“,比如：
之后當我們提需求修改pruner ，auto-coder 會自動調用 pytest 運行測試，直到滿足用戶需求并且同時通過測試才會提交PR。如果你對 test 足夠有信心，那么你完全可以不用reivew 代碼。
實際實踐
AC 項目已經在 auto-coder項目中進行了實踐，大家可以在我們項目里看到有很多模塊已經 AC 化了。
總結
實際上 AC 模塊的設計讓?AI輔助編程第一次可以完全接管一個復雜的項目，并且對項目有真正意義上的 ”深入理解“，而且不會給人類帶來復雜繁瑣的 Review 工作。人類的工作也從實在讓人蛋疼的review，給大模型打下手，變成我們是真正意義上的需求+驗收作者。 AC 模塊將真正意義第二次變革 AI輔助編程。
auto-coder 經過了一年多 400個版本的迭代，終于攜 AC 模塊迎來了自己的第一個里程碑版本： 1.0.0.?
你可以通過一條命令：
pip install -U?auto-coder來安裝。
最后，你都閱讀到這里了，來都來了，先別走，還有彩蛋。
超長對話支持
AC 模塊的引入以及基于驗證的編程，會極大的拉長對話，比如可能模型要組合1000次甚至一萬次的工具調用才能最終完成功能和過”測試驗收“。這個對 AI輔助編程工具是個巨大的挑戰， auto-coder 完美解決了這個問題。你可以用200k 的窗口拋出2000k 的上下文。當然，也小心的你錢包。
大模型聚焦機制
支持了超長對話，大模型往往容易忘記最開始的需求。auto-coder 通過一些內置支持，可以在讓用戶無感的情況下，幫助大模型聚焦原始需求，而不會隨著工具調用超過1000次以后就忘掉了之前要干什么了。
弱人機交互
現在大部分AI輔助編程工具都是強人機交互的，就是copilot 模式，我們提出需求，大模型完成，人review 和教調。隨著 AC 模塊的引入，AI輔助編程工具將直接給用戶提交PR，而且很多情況無需review ,則個時候，我們只要提出需求和驗證測試，其實就可以不管了，繼續去做其他事情。當前的 chat 交互模式是不合適的。所以我們引入了 CLI(方便在shell腳本或者編程語言中調用) 和 Python API（方便在應用中靈活集成），可以實現異步。比如：
cat?job1.md | auto-coder.run --model cus/anthropic/claude-sonnet-4 ?--pr然后你就可以去干別的，直到 github 接受到PR：
好了，這下是真的結束了，但是只是這篇文章的結束，卻是新時代的來臨。
