# AI 讓一個人同時當 PM、設計師和工程師，那誰來跟你唱反調？

> AI 讓一個人能兼做產品、設計與工程，但誰來質疑自己的方向？從親身經驗、產品風險與波普的否證精神，談動手前確認需求、最小版本觀察操作、繼續投入前檢查成效的三道檢查。

- Author: Paul Kuo（郭曜郎）
- Date: 2026-10-25
- Pillar: 智能與秩序 / Intelligence & Order
- Tags: 超級個體, 人機協作, 產品管理, 使用者測試, 驗證與確認, 波普, 否證精神
- Canonical: https://paulkuo.tw/articles/one-person-triad/
- Site index for LLMs: https://paulkuo.tw/llms.txt

---

今年二月，我還不會用 Terminal，也就是電腦上的命令列工具。跟 Claude 合作十二天之後，我做出了四語網站和一整套自動化系統。原本需要找工程師處理的工作，我開始能自己接下來（[那十二天的紀錄](/articles/super-individual-case-study)）。

但做得出來之後，還有一個問題：誰來判斷我是不是做錯了方向？

那十二天，Claude 寫的第一版文章，我砍掉一半；它建議的資料庫架構，我推翻過兩次。這些決定都是我做的。可是一個人能挑出自己看得懂的錯，不代表他也能看見自己不熟悉的問題。

Thorsten Ball 對軟體開發未來的預言中，有一條說，產品經理（PM）、設計師和工程師的分工將會消失。我想到的就是自己這幾個月的工作方式：工程、設計與產品決策，越來越多由我和 AI 一起完成。

我能理解他的判斷。但三種角色合到一個人身上之後，原本坐在桌子另一邊、質疑你的人，也可能一起消失。

那誰來跟你唱反調？

## AI 能合併工作，產品判斷也能一個人包辦嗎？

Thorsten Ball 在 2026 年 9 月 19 日寫下[十六條關於軟體開發未來的看法](https://thorstenball.com/blog/2026/09/19/what-i-believe-about-the-future-of-software-development/)。

以下依原文順序整理為中文摘要，保留他對不同預測的語氣。這些是他在 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〉](https://www.svpg.com/four-big-risks/)裡，把產品風險分成四種，交由三種角色主要負責。其中 PM 同時關心兩件事：有沒有人需要，以及生意能不能成立。用白話說：

- **PM 問：** 有人願意用或付錢嗎？這個做法在生意上行得通嗎？
- **設計師問：** 使用者看得懂，也知道怎麼操作嗎？
- **工程師問：** 以現有的時間、技術和能力，做得出來嗎？

人變少了，該檢查的事情並沒有變少。就算產品有人需要、用起來也順手，維護成本太高，還是可能做不下去。

分工的一個好處，是有人會注意到你沒想到的問題。工程師說「這個做得出來」，設計師會接著問「使用者知道怎麼用嗎」，PM 則要問「花這些時間和錢，值得嗎」。每個人看的角度不同，就有機會提醒彼此。

當三個角色都由自己擔任，這些問題也得由自己來問。但我們通常比較容易看出自己熟悉的問題。不熟悉的部分，可能連該問什麼都不知道，卻以為已經檢查過了。

![四格漫畫：PM、設計師和工程師，原本各自在擋什麼錯？ 不同的人會替不同的問題說話。 有人願意用或付錢嗎？生意上行得通嗎？ 使用者看得懂，也知道怎麼操作嗎？ 以現有的時間、技術和能力，做得出來嗎？ 工程師認為能做，設計師可能指出使用者看不懂；兩邊都滿意了，PM 還得問，值得投入嗎？ 三個位子收成一個之後，這些爭吵會搬進同一顆腦袋。 人跟自己吵架很難吵輸；輸掉的，多半是自己最不熟的那一邊。 一個人能完成的事情越多，我越需要替自己的判斷留下被推翻的機會。](/images/articles/one-person-triad/01-three-chairs-v2.svg)

## 程式能正常運作，為什麼產品還是可能做錯？

假設你用 AI 做了一個預約系統。日期能選、資料能存、通知會寄出，代表這些功能照著需求運作。

但客人可能不想註冊帳號，仍然選擇打電話。這時，功能即使都正常，產品也未必解決了使用者的問題。

軟體工程常用[「驗證」與「確認」](https://www.nasa.gov/ivv-overview/)區分這兩類檢查。驗證關心產品是否符合規格；確認關心產品是否滿足實際使用的需要。前者通過，不代表後者也通過。

我會讓 OpenAI 的 Codex、xAI 的 Grok 和 Google 的 Antigravity 審查 Claude 的產出，再配合測試，重要事實回到原始來源核對。這套做法與踩過的坑，我寫在[〈想讓 AI 做更大的事，先把抓錯的機制搭好〉](/articles/ai-ambition-is-infrastructure)。多模型審查能幫忙找錯，但幾個模型同意，仍不等於結果正確。

尤其是需求判斷。Anthropic 在 [2023 年的研究](https://www.anthropic.com/research/towards-understanding-sycophancy-in-language-models)中，發現受測的五個 AI 助理在四種文字生成任務裡都有迎合使用者看法的行為。這不能直接說明今天每個模型的表現，但提醒我，不能把模型的贊同當成需求成立的證據。

四月寫[〈人天已死〉](/articles/beyond-man-days)時，我把 AI 協作力評量框架交給幾個模型對抗辯論，跑了三輪壓力測試。辯論抓得出論證漏洞，卻回答不了有沒有人真的要用。那個答案，還是得向使用者取得。

## 找人唱反調，怎麼變成真正的檢驗？

箴言 27 章 17 節說：「鐵磨鐵，磨出刃來；朋友相感也是如此。」人需要別人來磨。但有人反對，不代表他一定有道理；反對的價值，在於幫我看見可以拿去檢查的問題。

寫到這裡，我想到波普的否證精神。一個想法要值得相信，得讓它有機會被現實推翻。

所以，找人唱反調還不夠。我得先說清楚：我相信這個產品能替誰解決什麼問題？什麼結果出現時，我會承認自己想錯了？然後把東西交出去，讓使用者試，讓結果回來。

AI 可以幫我提出更多想法，也可以幫我設計檢驗。但當結果不如預期，願不願意改變判斷，仍然是我的責任。

波普在《猜想與反駁》的[這篇節錄](https://tildesites.bowdoin.edu/~j.knockel/falsification/)中，討論科學理論如何接受檢驗。我借用到產品工作裡的是這種態度：先說清楚什麼結果會挑戰自己的主張，認真去試；暫時沒被推翻，也不代表永遠正確。

例如，我相信一個工具能讓人更快完成工作，就該讓使用者拿它和原來的方法比較，把學習和修正錯誤的時間也算進去。結果沒有比較快，就得檢查自己究竟誤判了哪個環節。一次測試不理想，未必代表整個方向都錯了，但也不能每次都替原來的想法找理由。

## 一個人做產品，可以怎麼留下三道檢查？

如果把這個想法放進日常工作，我會從三個時點開始。每次都留下原先的判斷、看到的結果，以及接下來要改什麼。

### 動手之前：確認問題真的存在

先寫下一句話：「我要幫誰，在什麼情況下，解決什麼麻煩？」再找真正遇過這個問題的人，問他上次怎麼處理、哪裡不方便。

「你覺得這個點子好不好？」容易得到客氣的支持。「你上次遇到這件事，怎麼解決？」比較能帶回具體經驗。如果對方根本沒有這個困擾，就先調整需求或使用對象，別急著加功能。AI 可以幫忙整理訪談，但受訪者的經驗不能由模型代填。

### 做出最小版本之後：讓使用者自己操作

先讓產品能完成最重要的一件事，確認能在可承受的時間與成本內安全運作，再請使用者試著操作。說明任務之後，先不逐步教他，看看他在哪裡停住、誤解或放棄。

這一步補回設計師原本會提出的質疑：你覺得理所當然的操作，別人真的看得懂嗎？卡住了，就改那個地方，再請人試。功能測試與實際操作觀察，都要留下紀錄。

### 繼續投入之前：回頭看，值得做下去嗎？

試用前，先訂下這一輪要觀察的結果與期限。依產品用途，可以看任務時間是否減少、下次需要時是否願意再用；如果是要做生意，也要看實際付費，以及服務和維護成本能不能負擔。

把這些結果拿給一位不參與製作、願意指出問題的人看，請他追問：「現在的證據，足夠支持繼續投入嗎？」他不需要替你決定，但可以幫你發現自己正在改口、把沒達到的目標說成不重要。

證據不足，就縮小範圍再試；需求不成立，就改方向或停下來。三道檢查能提供調整的依據，不能保證產品成功。

## 我也插一支旗

Thorsten 把自己的預言公開寫下來，留給以後對答案。我也想留下此刻的工作原則：一個人能完成的事情越多，我越需要替自己的判斷留下被推翻的機會。

AI 讓我更容易把想法做出來。我得替自己留下機會，發現這個想法可能不值得做。

也可以從[智能與秩序](/topics/ai/)主題頁，看這個系列的其他文章。