花了約兩個月，做一套讓 AI 持續開發軟體的系統。最後，我決定把它停下來。
不是因為它完全不能動。
恰恰相反，它接上過真實模型、完成過小型任務，也做出過真的程式修復。但當我把目標換成既有產品裡一個有實際用途的功能，它又停在理解需求、規劃工作和修補控制流程之間。
這讓我開始認真問自己：
我到底是在開發產品，還是在開發一套永遠需要我照顧的開發工具？
一開始，我只是想少當一點傳話的人
這場實驗從 8 月 20 日開始，最初叫 codex-controller，後來重新整理成 Synforge，直到 10 月 23 日正式封存。
我的想法不複雜：由我決定產品要解決什麼問題，再讓 AI 讀程式、拆工作、實作、測試、檢查，完成一件就接著做下一件。
真的需要產品決策時再問我。能從程式與需求找到答案的工程問題，就讓它自己調查。
我不想一直在不同對話之間搬資料，也不想每完成一步，就再貼一次「好，繼續」。
所以我開始做控制器，把這些步驟接起來。
但接起來之後，才發現真正麻煩的不是怎麼呼叫 AI。
是怎麼知道它到底做了什麼，以及下一步能不能相信上一步。
自動化之後，失敗也必須有規則
自己操作時，看到程式報錯，可以直接看畫面、查檔案，再決定怎麼處理。
換成系統自動執行，很多原本靠人判斷的事，都要變成明確的規則。
例如，工作做到一半中斷了，重新啟動後要重做，還是接著做？如果操作可能已經完成，只是結果沒傳回來，再跑一次會不會重複修改？檢查者讀到的程式，跟實際要執行的版本是不是同一份？
這些不是多餘的問題。要讓 AI 動手改既有產品，本來就不能只相信一句「完成了」。
於是系統逐漸加入工作紀錄、版本核對、獨立檢查與中斷恢復。
每一項單看都有道理，但加起來之後，新的問題出現了。
控制器自己修了一版，舊工作的批准和紀錄還能不能沿用？為了讓產品繼續往前，又得先修控制器的接續流程。
我原本想減少人工作業，結果開始做另一種人工作業：維護讓 AI 能繼續工作的條件。
小任務跑通，不代表大產品也會跟著跑通
10 月中，我把累積太多歷史包袱的系統重新整理，命名為 Synforge。
不是把之前的成果全部丟掉，而是保留可重用的程式與測試，讓新實驗不用先處理完所有舊事故。
重新開始後，確實出現一些進展。先驗證工作能被接受、能接續，再接上真實模型，完成小型三任務流程，也跑過隔離的 SaaS 案例。
這些成功是真的。
但它們回答的是「這套流程能不能在有限條件下運作」，不是「它能不能接手一個大型既有產品」。
既有產品的困難，往往不在某一段程式怎麼寫，而是改了這裡，會不會影響另一條流程。資料從哪裡來？權限在哪裡判斷？哪些行為是刻意保留的？測試是不是只驗到最容易的那一條路？
光把需求拆成清單，並不代表這些關係已經被理解。
一個訂閱問題，讓我看見「再修一輪」的陷阱
有一次，要處理的問題很直白：使用者取消訂閱，但已付費的期限還沒到，應該繼續保有使用權。
結果工作逐漸擴大到日期格式、時區、非法日期與各種解析邊界。
其中確實有需要修的錯誤，不能因為覺得麻煩就跳過。但另一部分，必須先回答：這種輸入真的會從產品入口進來嗎？
不能因為某個日期解析函式接受一種字串，就認定產品有義務支援所有形式。
這輪實驗累積了約 714 萬個已知 tokens，仍沒有穩定完成交付。這不是整個專案的總用量，也不能直接換算成帳單金額；但足以提醒我，持續分析不等於持續前進。
更值得注意的是，有些反覆推理，根本不是模型想得不夠深。
有時是檢查者沒拿到完整測試資料，有時是工具沒有提供需要讀的失敗版本。資料沒傳對，換一個更強的模型再想一次，也不會讓缺少的檔案自己出現。
對開發者來說，這很像函式收到錯誤參數。該修的是資料怎麼傳進來，而不是要求函式更努力。
測試通過，還要問通過了什麼
這兩個月讓我對「測試全過」這句話變得更謹慎。
型別檢查通過，代表某一層沒有問題；預先安排好模型回答的流程測試通過，代表接線可能正確。它們都不能直接證明，真實 AI 已經理解需求並交付功能。
獨立檢查也有價值。它確實找出固定測試沒有涵蓋的錯誤。但檢查通過，仍然要對得上正確版本、實際資料與使用情境。
最後一次調整，我們改成讓 AI 分批讀程式，先釐清一小塊，再逐步規劃，不要求一開始就理解整個產品。
方向比較合理，但結果仍然要如實看待：回歸測試是 181 項通過、1 項錯誤，不是全綠；模型角色採用預先安排的回答，也不能當成真實模型驗收。真正想完成的產品功能，依然沒有做出來。
測試數字可以增加，使用者能做的事情卻可能沒有增加。
這兩件事，不能混在一起。
最後讓我停止的，不是某一個 bug
最後一次真實產品挑戰，經過三輪規劃、8 次已確認的模型呼叫，消耗約 167 萬個 tokens，仍然沒有一份被正式接受的工作規劃，也沒有完成任何被接受的產品任務。
從第一個呼叫開始到最後完成，跨了約九個半小時。這裡面包含修補、審查與等待，不是模型連續思考了九個半小時。
技術上，當然還能繼續。
可以補資料、改工具、調整權限，再做一輪檢查。但到這個階段，我需要回答的已經不是「下一個 bug 修不修得掉」。
而是「這套工具，有沒有證明值得我繼續投入？」
當時沒有足夠證據顯示，它比我直接使用 Coding Agent 更有效率。這不代表已經透過公平比較證明它一定比較差，而是我沒有理由，把尚未證明的效率當成繼續投入的前提。
所以我選擇停止，保存程式、測試、失敗紀錄與尚未完成的部分，再正式封存。
不是把未完成改寫成成功，也不是把所有成果都當成沒有價值。
而是承認：局部技術成果有價值，但還不足以支持這個方向繼續產品化。
如果再做一次，我會先把範圍縮小
我不會因此不用 AI。相反地，這次實驗讓我更清楚，自己需要理解什麼，才能把 AI 用好。
如果再做一次，我會先選一個自己看得懂的功能：一個畫面、一條 API、一段資料保存流程。先確認使用者怎麼操作、什麼結果算完成、哪些舊功能不能壞，再讓 AI 協助實作與檢查。
遇到缺資料，就先查資料。遇到工具壞掉，就修工具。不把同一個問題換幾個角色重問，當成新的進度。
我也更願意親手理解 NestJS、Next.js 裡的資料流與關鍵程式。不是要跟 AI 比誰寫得快，而是至少要能判斷：它提出的修改是否必要？測試究竟保證了什麼？出了事，我能不能接手？
等某個流程真的穩定、重複很多次，而且手動搬運確實浪費時間，再把它抽成工具。
順序應該是先做成，再自動化，而不是先打造一套可以做成所有事情的系統。
這兩個月有學到東西，但學到東西，不代表所有投入都值得。機會成本不會因為經驗很珍貴，就自動消失。
這場實驗也不能證明所有 AI 自主開發都不可行。它只能說明，在這次的目標、架構與條件下，我沒有得到足以繼續投入的交付結果。
我原本希望工具替我省下時間。
當維護工具開始吃掉更多時間，願意把它停下來，也是一種開發能力。