今年二月，我還不會用 Terminal，也就是電腦上的命令列工具。跟 Claude 合作十二天之後，我做出了四語網站和一整套自動化系統。原本需要找工程師處理的工作，我開始能自己接下來（那十二天的紀錄）。
但做得出來之後，還有一個問題：誰來判斷我是不是做錯了方向？
那十二天，Claude 寫的第一版文章，我砍掉一半；它建議的資料庫架構，我推翻過兩次。這些決定都是我做的。可是一個人能挑出自己看得懂的錯，不代表他也能看見自己不熟悉的問題。
Thorsten Ball 對軟體開發未來的預言中，有一條說，產品經理（PM）、設計師和工程師的分工將會消失。我想到的就是自己這幾個月的工作方式：工程、設計與產品決策，越來越多由我和 AI 一起完成。
我能理解他的判斷。但三種角色合到一個人身上之後，原本坐在桌子另一邊、質疑你的人，也可能一起消失。
那誰來跟你唱反調？
AI 能合併工作，產品判斷也能一個人包辦嗎？
Thorsten Ball 在 2026 年 9 月 19 日寫下十六條關於軟體開發未來的看法。
以下依原文順序整理為中文摘要，保留他對不同預測的語氣。這些是他在 2026 年 9 月的觀察與判斷，並非已確定的產業結論。
本文主要回應第 4、5、10 點，已在表中加粗：分工可能改變，產品判斷仍然重要，而需求本身也可能出錯。
| 序號 | Thorsten Ball 的看法（中文摘要） |
|---|---|
| 1 | 逐行審查程式碼將退場，人類轉向檢查整體系統。 |
| 2 | 單元測試也可能退場。 |
| 3 | 手寫程式碼的技藝將消失。 |
| 4 | 用軟體解決商業問題、決定上線與取得回饋，將更重要。 |
| 5 | 多數錯誤將來自需求不對，而非程式寫錯。 |
| 6 | AI 能參與找錯，現行開源模式不再合理。 |
| 7 | 仰賴人類優化效能仍是少數情境；必要時模型能處理。 |
| 8 | 人類將不再直接使用命令列、編輯器等開發工具。 |
| 9 | Token 將成為新的運算典範。 |
| 10 | PM、設計與工程的三方分工將消失；敏捷與 Scrum 退場，只轉交工單的工程師失去價值。 |
| 11 | 大小公司的開發方式將更分歧，新創照搬大公司更不合時宜。 |
| 12 | 為人類維護而定的「好程式碼」標準，未必仍重要。 |
| 13 | 取得足夠 Token 的成本，將讓部分人難以競爭。 |
| 14 | 廉價模型是否會被使用仍有疑問：更聰明的模型出錯與往返更少。 |
| 15 | 模型將即時生成介面，也減少對固定選單與設定頁的需求。 |
| 16 | 新舊軟體交替需要一代人的時間，十年後仍有人寫程式。 |
照我的讀法，他看重的判斷並沒有消失，只是做軟體的人得自己扛。他另一個預言更值得留意：未來許多錯誤，會出在一開始就要求了錯的東西。
這讓我想到，一個人能完成更多工作之後，原本分散在不同人身上的責任，會集中到自己身上。從我的經驗看，有些工作確實不再需要三個人分別接手；但這還不足以判斷，整個產業的三種職位會減少多少。
我更在意的是：當提案、製作與評判都由自己完成，還有什麼能讓我發現方向錯了？
PM、設計師和工程師，原本各自在擋什麼錯？
產品顧問 Marty Cagan 在〈The Four Big Risks〉裡，把產品風險分成四種，交由三種角色主要負責。其中 PM 同時關心兩件事：有沒有人需要，以及生意能不能成立。用白話說：
- PM 問： 有人願意用或付錢嗎？這個做法在生意上行得通嗎？
- 設計師問： 使用者看得懂，也知道怎麼操作嗎？
- 工程師問： 以現有的時間、技術和能力，做得出來嗎？
人變少了，該檢查的事情並沒有變少。就算產品有人需要、用起來也順手，維護成本太高，還是可能做不下去。
分工的一個好處，是有人會注意到你沒想到的問題。工程師說「這個做得出來」，設計師會接著問「使用者知道怎麼用嗎」，PM 則要問「花這些時間和錢，值得嗎」。每個人看的角度不同，就有機會提醒彼此。
當三個角色都由自己擔任，這些問題也得由自己來問。但我們通常比較容易看出自己熟悉的問題。不熟悉的部分，可能連該問什麼都不知道，卻以為已經檢查過了。
程式能正常運作，為什麼產品還是可能做錯？
假設你用 AI 做了一個預約系統。日期能選、資料能存、通知會寄出，代表這些功能照著需求運作。
但客人可能不想註冊帳號，仍然選擇打電話。這時，功能即使都正常，產品也未必解決了使用者的問題。
軟體工程常用「驗證」與「確認」區分這兩類檢查。驗證關心產品是否符合規格；確認關心產品是否滿足實際使用的需要。前者通過，不代表後者也通過。
我會讓 OpenAI 的 Codex、xAI 的 Grok 和 Google 的 Antigravity 審查 Claude 的產出，再配合測試，重要事實回到原始來源核對。這套做法與踩過的坑，我寫在〈想讓 AI 做更大的事，先把抓錯的機制搭好〉。多模型審查能幫忙找錯，但幾個模型同意，仍不等於結果正確。
尤其是需求判斷。Anthropic 在 2023 年的研究中，發現受測的五個 AI 助理在四種文字生成任務裡都有迎合使用者看法的行為。這不能直接說明今天每個模型的表現，但提醒我，不能把模型的贊同當成需求成立的證據。
四月寫〈人天已死〉時，我把 AI 協作力評量框架交給幾個模型對抗辯論，跑了三輪壓力測試。辯論抓得出論證漏洞，卻回答不了有沒有人真的要用。那個答案，還是得向使用者取得。
找人唱反調，怎麼變成真正的檢驗？
箴言 27 章 17 節說：「鐵磨鐵，磨出刃來；朋友相感也是如此。」人需要別人來磨。但有人反對，不代表他一定有道理；反對的價值，在於幫我看見可以拿去檢查的問題。
寫到這裡，我想到波普的否證精神。一個想法要值得相信，得讓它有機會被現實推翻。
所以，找人唱反調還不夠。我得先說清楚：我相信這個產品能替誰解決什麼問題？什麼結果出現時，我會承認自己想錯了？然後把東西交出去，讓使用者試，讓結果回來。
AI 可以幫我提出更多想法，也可以幫我設計檢驗。但當結果不如預期，願不願意改變判斷，仍然是我的責任。
波普在《猜想與反駁》的這篇節錄中，討論科學理論如何接受檢驗。我借用到產品工作裡的是這種態度：先說清楚什麼結果會挑戰自己的主張，認真去試；暫時沒被推翻，也不代表永遠正確。
例如，我相信一個工具能讓人更快完成工作，就該讓使用者拿它和原來的方法比較，把學習和修正錯誤的時間也算進去。結果沒有比較快，就得檢查自己究竟誤判了哪個環節。一次測試不理想，未必代表整個方向都錯了，但也不能每次都替原來的想法找理由。
一個人做產品，可以怎麼留下三道檢查？
如果把這個想法放進日常工作，我會從三個時點開始。每次都留下原先的判斷、看到的結果，以及接下來要改什麼。
動手之前：確認問題真的存在
先寫下一句話：「我要幫誰，在什麼情況下，解決什麼麻煩？」再找真正遇過這個問題的人，問他上次怎麼處理、哪裡不方便。
「你覺得這個點子好不好？」容易得到客氣的支持。「你上次遇到這件事，怎麼解決？」比較能帶回具體經驗。如果對方根本沒有這個困擾，就先調整需求或使用對象，別急著加功能。AI 可以幫忙整理訪談，但受訪者的經驗不能由模型代填。
做出最小版本之後：讓使用者自己操作
先讓產品能完成最重要的一件事，確認能在可承受的時間與成本內安全運作，再請使用者試著操作。說明任務之後，先不逐步教他，看看他在哪裡停住、誤解或放棄。
這一步補回設計師原本會提出的質疑：你覺得理所當然的操作，別人真的看得懂嗎？卡住了，就改那個地方，再請人試。功能測試與實際操作觀察，都要留下紀錄。
繼續投入之前：回頭看，值得做下去嗎？
試用前，先訂下這一輪要觀察的結果與期限。依產品用途，可以看任務時間是否減少、下次需要時是否願意再用；如果是要做生意，也要看實際付費，以及服務和維護成本能不能負擔。
把這些結果拿給一位不參與製作、願意指出問題的人看，請他追問：「現在的證據，足夠支持繼續投入嗎？」他不需要替你決定，但可以幫你發現自己正在改口、把沒達到的目標說成不重要。
證據不足，就縮小範圍再試；需求不成立，就改方向或停下來。三道檢查能提供調整的依據，不能保證產品成功。
我也插一支旗
Thorsten 把自己的預言公開寫下來，留給以後對答案。我也想留下此刻的工作原則：一個人能完成的事情越多，我越需要替自己的判斷留下被推翻的機會。
AI 讓我更容易把想法做出來。我得替自己留下機會，發現這個想法可能不值得做。
也可以從智能與秩序主題頁，看這個系列的其他文章。
💬 留言討論
載入中...