三大AI編程框架 - 做對了什麼?還可以如何優化?
Hello 大家好
今天我們來看一個新的問題
現在AI寫代碼
最大的痛點已經不再是寫不出來了
而是在它寫完之後
我們心裏沒有底
它到底可不可靠
沒有測試
框架亂七八糟
安全問題可能一抓一大把
改起來時間可能比從頭再寫一遍還要長
這歸根到底是一個信任的問題
那怎麼辦呢
社區的做法是在搞各種各樣的框架
給AI的自由度賞
加上各種條條框框
現在最火的有三個
第一個
Super Powers有九萬多star
GSD有三萬五star
G-Stock有差不多兩萬六star
光看數據
我們可能會覺得它們是競爭對手
但我們把它的源碼拆開來研究一下
會發現
其實它們三個在不同的維度上
來試圖解決這個問題
而且我們還發現了
G-Stock在結構性上有一些缺陷
現在還沒有被很好的討論過
先說Super Powers
它想解決的問題很簡單
AI寫代碼沒有規矩
你讓它加一個功能
它可能埋頭把它寫完了
但測試沒有寫
實現方式跟當初聊的可能也不太一樣
代碼的質量有時候好
有時候不好
就像團隊中那些寫代碼很快
但從來不做代碼測試的處局工程師
Super Powers是怎麼處理它的呢
它把整個開發流程
變成了一條特別嚴格的流水線
一開始是頭腦風暴
但不是你隨便聊聊
是結構化的需求對話
它會按模塊展示設計
每部分都會需要你確認
纔會繼續往下走
然後它會生成一個非常詳細的實施計劃
是到每一步改哪個文件
預期得到什麼樣的結果
怎麼驗證
接下來怎麼執行
實現強制的測試驅動開發
所以Super Powers的本質
就是用流程化的紀律來保證代碼的質量
它的核心假設是
AI的問題不是能力不夠
是太散漫
給它定好規矩
它的輸出就會穩定很多
再來看GSD
它需要解決的是另一個問題
上下文腐爛
Context Rot
你跟Cloud聊了半個小時
它會開始偷懶
忘記事情
甚至開始胡說八道
這不是你的錯覺
上下文的窗口用到50%以上
質量就開始下滑了
用到70%以上
幻覺就變得明顯了很多
你的項目越大
聊天的內容越長
這個問題就會越嚴重
GSD的解決方法也很直接
徹底隔離上下文
它把工作拆成一個個原子任務
每個任務都會開一個全新的Cloud實例
一個乾淨的200K上下文的窗口
就像跟你第一次對話一樣清醒
而它自己的主繪畫
只用作調度
負載總保持在30%到40%
不幹重活
所有的項目狀態
需求 路線圖 進度
都存成文本
放在磁盤上
不會丟失
每當開始一個新的session
你可以讀回來
重新接着完成
之前沒有完成的任務
所以GSD的本質上
是一套上下文工程系統
它的假設是
AI的質量完全取決於
上下文窗口的乾淨程度
環境乾淨
輸出就穩定
最後來看一下GStack
它解決的問題
跟前面兩個不在同一個角度上
它不管你寫代碼怎麼寫
也不管你上下文乾不乾淨
它管的是
誰來做什麼樣的決定
它定義了15個角色
每個角色對一個特定的命令
比如Office Hours
這個角色
會挑戰你的產品方向
你說你要做一個日曆應用
它會說你其實想做的
可能是一個AI的行政助理
另外Plant Engineer Review
這個角色負責
鎖定框架
畫出數據流
列出各種各樣的邊界情況
Review做代碼審覈
遇到問題
一些小的問題
它可以自己解決
QA
它會打開一個真實的瀏覽器
點進去應用
作爲一個用戶的視角
來嘗試尋找各種各樣可能的Bug
Shape負責推代碼
開PR
還有三個專門做設置審查的角色
它們用來識別那種
AI生成的千篇一律的UI
保證設置的可靠性和獨特性
所以G-Stack的核心是一套角色治理系統
它的核心假設是
AI輸出的質量
取決於它用什麼樣的視角
用什麼角色來思考
用對的視角
判斷的質量就會好很多
所以你可以看到
這三個框架
並不是在同一個方向上來解決這個問題
Superpowers約束的是過程
GSD約束的是環境
而G-Stack約束的是視角
表面上看
G-Stack好像是在給Cloud起了15個名字
但讀完它的Architecture和各種Skill源碼後
你會發現
它至少在做五件不同的事情
第一
角色聚焦
讓Cloud以工程經理的身份去審查代碼
它會自動忽略UI顏色不好看這種反饋
從而專注於框架和可維護性
這相當於給AI模型的注意力做了一次聚焦
只看該看的維度
第二層是數據的編排
Office Hours產生的設計文檔
Plan CEO Review會讀取這個文檔做產品審覈
Plan Engineer Review會再讀取上面的產出
鎖定框架和架構
每一步的輸出都成爲了下一步的輸入
到了Review這一步
審查者手裏已經握着完整的項目上下文
產品定位
架構決策
設計標準
第三層 質量管控
Ship之前它會展示一個審查就緒面板
跑過哪些審查 缺了什麼
這個PR是否有跑過相對應的審查等
都會羅列在那邊
第四層 決策偏好的注入
G-Stack有一個核心的哲學
叫做Boiler Lake
注意它特地區分了Boiler Ocean和Boiler Lake
這裏的背景知識是
湖泊和海洋在它眼裏是不一樣的
它認爲湖泊是可以被煮沸的
比如把一個模塊的測試覆蓋率做到100%
把所有的邊界情況和錯誤路徑都處理乾淨
這些事情讓AI來做成本很低
幾乎是可以忽略不計的
但海洋是永遠煮不開的
比如從頭寫一個完整的系統
或者做一個跨季度的平臺的遷移
這種級別的任務AI搞不定
也不該讓它來做
所以G-Stack的策略是
煮沸每一個可以煮沸的湖泊
同時把那些海洋級別的任務
它在做規劃的時候
會同時給你展示兩個時間
比如這個功能人工做大概要兩週
但讓Cloud做可能大概要一個小時
然後它會問用戶
爲了省這幾分鐘
我們跳過測試覆蓋率
你覺得值得嗎
這個問題本身就是在直接改變
Cloud在做的夠用和做到完整之間的默認取捨
第五層是認知負載的適配
當它檢測到你開了三個或以上的繪畫時
所有的skill都會進入到一種叫ELI16的模式
就是Explain Like I'm 16
每次的交互都會重新交代一遍上下文
因爲它知道你現在可能正在切換多個窗口來完成任務
這是我見過的唯一一個會主動去適配人類工作狀態的AI編碼工具
這五層加在一起
說明G-Stack其實是一套流程治理系統
而不是簡單的一堆prompt和一堆角色的扮演
接下來我覺得最值得聊的一個發現是
G-Stack的流程是思考、規劃、構建、審查、測試、發佈這五個階段
我統計了每個階段有多少skill
思考和規劃階段有五個
審查階段有三個
測試有兩個
發佈有兩個
但是在構建階段卻沒有
也就是說
規劃通過之後
Cloud Code就回到了它的默認模式
沒有TDD
沒有任務拆分
沒有子代理
也沒有增量審查
直到你手動執行review命令後
纔會重新開始有了約束
而構建階段恰恰是Superpowers和GSD最擅長的工作
所以一個自然的想法是
能不能把它們組合起來
用G-Stack來做規劃和審查
用Superpowers來做構建
理論上這完全是可以互補的
但實際上卡在了一個技術上的問題
Superpowers在構建的過程當中
會彈出一系列交互式問答
這時候Cloud Code的輸入就被卡住了
它在等用戶打字
就算我們用Agent Teams
那個被卡住的繪畫
也收不到其他Agent的消息
因爲它根本就沒辦法運行
只是在乾等着
這個框架的集成問題
目前還沒有一個乾淨的解決方法
我們也注意到
Android Capacity最近提出了一個叫Auto Research的項目
提供了一個新的思路
Auto Research的模式非常簡單
Agent修改代碼
跑一段固定時間的實驗
測量一個特定的指標
然後指標改善了就保留
沒改善就重置丟棄
然後再循環
直到跑完一定數量的實驗
這個模式有兩個關鍵點
第一,它是單個Agent自己的集體頻環
它不需要多個Agent之間的相互通信
所以不存在被卡住的問題
第二,它用一個可量化的
單一的數字來做保留和丟棄的決策
沒有模糊的判斷
把這個思路搬到軟件工程裏
可以想象一下
一個Optimized SKU
它會自動修改代碼
跑測試
測量代碼的覆蓋率
Lighthouse的分數
打包體積
指標漲了就提交
沒漲就重置
循環
我們可以在睡覺前把它跑起來
早上起來可能就會發現相對應的指標就被提升了
這不是簡單的去填補構建階段的空白
而是在G-Stack的發佈之後
增加一個全新的能力
無人值守的持續優化
G-Stack現在的模式是
做完一個功能就發佈它
它沒有持續的改進和迭代代碼這一環節
Auto Research的這種循環模式正好可以補上
當然有一個開放的問題
繼續學習訓練的指標是一個天然的數字
Loss降了就是降了
但軟件工程的代碼質量
很難用一個數字完全的代表
比如覆蓋率漲了
但新增的測試可能是一些完全沒有用的斷言
這些問題還需要進一步的深入思考
最後來看一個實際的問題
G-Stack推薦用Conductor來做並行開發
作者說
它同時跑10到15個任務就是靠這個
但Conductor只支持macOS
Linux和Windows用戶完全沒有官方的方案
實際上它底層的原理還是Git WorkTrees
而Cloud Code本身就原生支持WorkTree參數
我們開幾個ToolMix的窗口就能做到一樣的事情
我已經給G-Stack提了一個SprintSkill的PR
希望能把這個方案變成G-Stack內置的正式功能
讓大家都能用上
簡單的總結一下
G-Stack不是一個角色prompt的簡單集成
它是一整套由五層設計的流程治理體系
它最強的點在於用產品思維和質量管控
但最大的缺點在構建階段
它跟Superpowers、GSD是互補而非競爭的關係
但跨框架的集成目前還存在技術瓶頸
而Auto Research那種循環的模式
是一個挺值得探索的新的方向
關於這三個框架
你有什麼想聊的
歡迎在評論區留言
我們下期再見