短繩 AI 程式設計方法：打造高品質軟體

短繩方法：以人類監督為先，勝過 AI 自主性

為了在安全關鍵系統中產出高品質軟體，資深開發者必須將 AI 代理視為需要持續監督的工具，而非自主指揮者。「短繩」方法拒絕「氛圍工程」的做法——即多個代理平行運作、極少人工介入——而是要求人類開發者在流程的每一步都保持主要決策者與審查者的角色。

自主 AI 程式編寫的失敗案例

自主 AI 程式編寫系統常會產生「爛碼」——雖然能執行卻效率低下、外觀不佳，且缺乏架構完整性。這在訓練資料稀少的利基領域尤為常見，因為模型無法超出其訓練集的範圍思考。

自主使用 AI 的主要風險包括：

• 失去程式碼庫的理解：開發者若將自己從編寫過程中抽離，將失去對自家軟體運作方式的認知。
• 代理漂移：AI 代理常會「跑偏」，實施不必要的變更或刪除先前已完成的工作。
• 品質退化：即使是前沿模型如 Fable 5，若未受監督也可能產出低效且「醜陋」的程式碼。

實施短繩工作流程

短繩方法專為具備專業領域知識、能在特定領域超越前沿 AI 模型的軟體開發者設計。工作流程包含以下需求：

1. 規劃與追蹤

開發者應使用專門的規劃階段來研究任務並制定計畫。可利用「tasks skill」等工具，將大型目標拆解為可管理的子任務，以精確追蹤進度。

2. 嚴格的權限控制

為防止 AI 任意變更，開發者必須：

• 停用「YOLO」模式：絕不跳過權限提示。
• 分析 Diff：使用能在權限提示中顯示變更差異的程式碼代理，開發者必須在授予權限前手動檢視每一項變更。
• 拒絕權限：對任何不符合預期目標的變更立即拒絕。

3. 持續整合與版本管理

為避免工作遺失——這是如 Opus 等模型的已知問題——每完成一個子任務後必須提交一次 commit。如此可確保 AI 不會意外刪除先前已驗證的進度。

雙層 AI 與人工審查

高品質程式碼需要混合審查流程。由人類與 AI 共同審查的 PR，始終比僅由其中一方審查更為精確。在此模型中，AI 扮演高速 lint 工具的角色，捕捉常見錯誤；而人類則聚焦於高層次的架構問題與方向性變更。

審查協議

• 情境化 AI 審查：AI 審查者必須能取得完整情境，包括議題、PR 說明、程式碼庫以及具體變更。
• AI 披露：每個 PR 說明必須包含「AI 披露」標題，明確列出使用的模型。此舉讓維護者了解模型可能的弱點，並確保透明度。
• 強制自我審查：若使用 AI 產生程式碼，作者必須以審查陌生人程式碼的標準，逐行檢視自己的 PR，並在請求維護者審查前明確確認批准。

此流程確保提交 PR 的人完全理解其提交的程式碼，維護安全關鍵系統的完整性。