# AI 让一个人同时当 PM、设计师和工程师，那谁来跟你唱反调？

> AI 让一个人能兼做产品、设计与工程，但谁来质疑自己的方向？从亲身经验、产品风险与波普的否证精神，谈动手前确认需求、最小版本观察操作、继续投入前检查成效的三道检查。

- Author: Paul Kuo（郭曜郎）
- Date: 2026-10-25
- Pillar: 智能与秩序 / Intelligence & Order
- Tags: 超级个体, 人机协作, 产品管理, 用户测试, 验证与确认, 波普, 否证精神
- Canonical: https://paulkuo.tw/zh-cn/articles/one-person-triad/
- Language: Simplified Chinese (简体中文)
- Translation: AI-translated from the zh-Hant (Traditional Chinese) original
- Original (zh-Hant): https://paulkuo.tw/articles/one-person-triad.md
- Site index for LLMs: https://paulkuo.tw/llms.txt

---

今年二月，我还不会用 Terminal，也就是电脑上的命令行工具。跟 Claude 合作十二天之后，我做出了四语网站和一整套自动化系统。原本需要找工程师处理的工作，我开始能自己接下来（[那十二天的纪录](/zh-cn/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-zh-cn.svg)

## 程序能正常运作，为什么产品还是可能做错？

假设你用 AI 做了一个预约系统。日期能选、数据能存、通知会寄出，代表这些功能照着需求运作。

但客人可能不想注册账号，仍然选择打电话。这时，功能即使都正常，产品也未必解决了用户的问题。

软件工程常用[「验证」与「确认」](https://www.nasa.gov/ivv-overview/)区分这两类检查。验证关心产品是否符合规格；确认关心产品是否满足实际使用的需要。前者通过，不代表后者也通过。

我会让 OpenAI 的 Codex、xAI 的 Grok 和 Google 的 Antigravity 审查 Claude 的产出，再配合测试，重要事实回到原始来源核对。这套做法与踩过的坑，我写在[〈想让 AI 做更大的事，先把抓错的机制搭好〉](/zh-cn/articles/ai-ambition-is-infrastructure)。多模型审查能帮忙找错，但几个模型同意，仍不等于结果正确。

尤其是需求判断。Anthropic 在 [2023 年的研究](https://www.anthropic.com/research/towards-understanding-sycophancy-in-language-models)中，发现受测的五个 AI 助理在四种文字生成任务里都有迎合用户看法的行为。这不能直接说明今天每个模型的表现，但提醒我，不能把模型的赞同当成需求成立的证据。

四月写[〈人天已死〉](/zh-cn/articles/beyond-man-days)时，我把 AI 协作力评量框架交给几个模型对抗辩论，跑了三轮压力测试。辩论抓得出论证漏洞，却回答不了有没有人真的要用。那个答案，还是得向用户取得。

## 找人唱反调，怎么变成真正的检验？

箴言 27 章 17 节说：「铁磨铁，磨出刃来；朋友相感也是如此。」人需要别人来磨。但有人反对，不代表他一定有道理；反对的价值，在于帮我看见可以拿去检查的问题。

写到这里，我想到波普的否证精神。一个想法要值得相信，得让它有机会被现实推翻。

所以，找人唱反调还不够。我得先说清楚：我相信这个产品能替谁解决什么问题？什么结果出现时，我会承认自己想错了？然后把东西交出去，让用户试，让结果回来。

AI 可以帮我提出更多想法，也可以帮我设计检验。但当结果不如预期，愿不愿意改变判断，仍然是我的责任。

波普在《猜想与反驳》的[这段节选](https://tildesites.bowdoin.edu/~j.knockel/falsification/)中，讨论科学理论如何接受检验。我借用到产品工作里的是这种态度：先说清楚什么结果会挑战自己的主张，认真去试；暂时没被推翻，也不代表永远正确。

例如，我相信一个工具能让人更快完成工作，就该让用户拿它和原来的方法比较，把学习和修正错误的时间也算进去。结果没有比较快，就得检查自己究竟误判了哪个环节。一次测试不理想，未必代表整个方向都错了，但也不能每次都替原来的想法找理由。

## 一个人做产品，可以怎么留下三道检查？

如果把这个想法放进日常工作，我会从三个时点开始。每次都留下原先的判断、看到的结果，以及接下来要改什么。

### 动手之前：确认问题真的存在

先写下一句话：「我要帮谁，在什么情况下，解决什么麻烦？」再找真正遇过这个问题的人，问他上次怎么处理、哪里不方便。

「你觉得这个点子好不好？」容易得到客气的支持。「你上次遇到这件事，怎么解决？」比较能带回具体经验。如果对方根本没有这个困扰，就先调整需求或使用对象，别急着加功能。AI 可以帮忙整理访谈，但受访者的经验不能由模型代填。

### 做出最小版本之后：让用户自己操作

先让产品能完成最重要的一件事，确认能在可承受的时间与成本内安全运作，再请用户试着操作。说明任务之后，先不逐步教他，看看他在哪里停住、误解或放弃。

这一步补回设计师原本会提出的质疑：你觉得理所当然的操作，别人真的看得懂吗？卡住了，就改那个地方，再请人试。功能测试与实际操作观察，都要留下记录。

### 继续投入之前：回头看，值得做下去吗？

试用前，先订下这一轮要观察的结果与期限。依产品用途，可以看任务时间是否减少、下次需要时是否愿意再用；如果是要做生意，也要看实际付费，以及服务和维护成本能不能负担。

把这些结果拿给一位不参与制作、愿意指出问题的人看，请他追问：「现在的证据，足够支持继续投入吗？」他不需要替你决定，但可以帮你发现自己正在改口、把没达到的目标说成不重要。

证据不足，就缩小范围再试；需求不成立，就改方向或停下来。三道检查能提供调整的依据，不能保证产品成功。

## 我也插一支旗

Thorsten 把自己的预言公开写下来，留给以后对答案。我也想留下此刻的工作原则：一个人能完成的事情越多，我越需要替自己的判断留下被推翻的机会。

AI 让我更容易把想法做出来。我得替自己留下机会，发现这个想法可能不值得做。

也可以从[智能与秩序](/zh-cn/topics/ai/)主题页，看这个系列的其他文章。