當 AI 已經可以很快把程式碼寫出來，誰來判斷這份成果真的可以接受？

Question

Accepted Answer

這個問題，可能比 AI 會不會寫程式更麻煩。以前的瓶頸，是沒有人做；現在的瓶頸，是不知道做對了沒以前一個團隊缺功能，通常要找工程師、說明需求、估工時，然後等開發完成。最後再由產品負責人、資深工程師或客戶驗收。流程不一定快，但大家知道瓶頸在哪裡：工程師的時間有限。所以任務平台的價值很容易理解。它幫你找到願意接工作的人。現在不一樣了。一個人可以讓 AI Agent 讀 codebase、拆需求、寫函式、補測試，最後開一個 Pull Request。第一版可能幾十分鐘就出來了。速度變快，工作卻沒有消失。它只是往後移。你還是得確認：這段程式碼真的解決原本的問題嗎？有沒有只在 demo 情境下能跑？會不會破壞既有功能？權限和資料處理是不是安全？需求裡沒寫清楚的地方，Agent 到底猜對了沒有？AI 可以幫忙跑測試、找常見漏洞、比對規格，但它不會因為測試全綠，就知道產品真的能不能上線。能跑，不等於能交付這是 AI 產出程式碼最容易讓人誤判的地方。檔案有了，函式有了，測試也有幾個，畫面甚至可以操作。對不熟技術的人來說，這看起來就像「完成了」。但軟體最麻煩的問題，往往不是一按就爆掉的錯誤。登入可以成功，不代表權限沒有漏洞。API 可以回傳資料，不代表不會把別人的資料一起吐出來。測試可以全部通過，也不代表測試有測到真正重要的情境。而且，很多需求一開始就沒有寫清楚。「新增匯出功能」，是匯出目前畫面的資料，還是整個資料庫？「支援多人協作」，是可以同時編輯，還是只要看得到彼此留言？「改善效能」，是首頁快一秒，還是尖峰時段不能 timeout？這些不是語法問題。模型再強，也不能替團隊決定什麼叫做「夠好」。誰來驗收，會決定這個市場能不能成立一個任務市場真正交易的，不是一份程式碼。需求方買的是一個結果，而且要相信這個結果已經達到可以接受的標準。所以驗收者不是附帶角色，而是整筆交易裡最重要、也最容易被忽略的人。需求方自己驗收，當然最理想。但很多開源專案、早期團隊或非技術創辦人，就是因為沒有足夠的工程能力，才需要把工作交出去。找另一個開發者驗收？可以，只是成本會增加。原本只付一份開發費，現在還要多付審查費，而且驗收者未必理解產品真正要解決的問題。交給 AI？AI 能協助檢查，但很難替你承擔「這樣真的可以上線嗎」的責任。規格不完整時，它也只能按照你寫出來的邊界做判斷。交給社群投票？投票可以分散審查，但投票的人未必讀過程式碼，也未必願意為錯誤結果負責。所以一個可靠的任務市場，至少要先回答三件事：驗收者是否理解成果會被怎麼使用？驗收標準是否在任務開始前就寫清楚？驗收錯了，誰承擔後果？這三件事沒有答案，平台就只能幫雙方認識，不能真正降低交易風險。AI Agent 接任務，交付物不能只有 code這會改變我們寫任務的方式。以前可以說：「幫我加一個付款功能。」對 AI Agent 來說，這句話太模糊。它可能很快做出一個能 demo 的付款頁面，但「可以放心收錢」裡面還有很多事情沒有被說出來。比較好的任務描述，不只寫要完成什麼，也要寫要證明什麼。例如付款流程除了程式碼，還要交代：付款失敗和重複請款怎麼處理、不同狀態會發生什麼事、敏感資料怎麼保護、改動影響到哪些既有流程，以及第三方要怎麼重現驗收。這些文件和測試看起來不像成果，卻是成果能不能被相信的關鍵。因為程式碼只告訴你「它被怎麼寫出來」；驗收證據才讓你知道「它為什麼可以被接受」。OnlyDust 留下的問題，不只是平台成敗OnlyDust 的關閉，不能簡單解讀成開發任務平台沒有價值。開源專案仍然需要貢獻者，開發者也仍然想把能力換成收入。難的是，平台要怎麼把一個模糊、複雜，而且品質差異很大的軟體工作，變成陌生人敢交易的訂單。AI 出現後，這件事反而更難。因為平台不只要媒合「誰有時間做」，還要處理：誰提出的需求有效？誰能看出漂亮但沒用的成果？誰替驗收結果背書？什麼條件成立，錢才應該自動付出去？如果平台只負責把人找來，卻把最難的判斷全部丟回需求方，交易不會因此變可靠。以後更值錢的，是定義「完成」的人我不覺得工程師會消失，但工程師的價值會重新分層。只會把需求翻成程式碼的人，會比較容易被替代。能把問題問清楚、設計邊界、想得到失敗情境、建立驗收方法，最後願意對結果負責的人，會更重要。這也不只是在考驗工程師。產品經理要更懂技術，才知道什麼叫做可以驗收；技術主管要更懂業務，才知道哪些錯誤不能接受；客戶也不能只說「做得像某某產品」，而要講清楚什麼結果才算完成。大家都會更快做出第一版。真正困難的是，誰敢說這一版可以交付。我現在還沒有看到很好的答案，但我確定 AI 開發市場接下來要解的，不是怎麼找到更多會寫程式的人。而是：