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

今年二月，我还不会用 Terminal，也就是电脑上的命令行工具。跟 Claude 合作十二天之后，我做出了四语网站和一整套自动化系统。原本需要找工程师处理的工作，我开始能自己接下来（那十二天的纪录）。

但做得出来之后，还有一个问题：谁来判断我是不是做错了方向？

那十二天，Claude 写的第一版文章，我砍掉一半；它建议的数据库架构，我推翻过两次。这些决定都是我做的。可是一个人能挑出自己看得懂的错，不代表他也能看见自己不熟悉的问题。

Thorsten Ball 对软件开发未来的预言中，有一条说，产品经理（PM）、设计师和工程师的分工将会消失。我想到的就是自己这几个月的工作方式：工程、设计与产品决策，越来越多由我和 AI 一起完成。

我能理解他的判断。但三种角色合到一个人身上之后，原本坐在桌子另一边、质疑你的人，也可能一起消失。

那谁来跟你唱反调？

AI 能合并工作，产品判断也能一个人包办吗？

Thorsten Ball 在 2026 年 9 月 19 日写下十六条关于软件开发未来的看法。

以下依原文顺序整理为中文摘要，保留他对不同预测的语气。这些是他在 2026 年 9 月的观察与判断，并非已确定的产业结论。

本文主要回应第 4、5、10 点，已在表中加粗：分工可能改变，产品判断仍然重要，而需求本身也可能出错。

照我的读法，他看重的判断并没有消失，只是做软件的人得自己扛。他另一个预言更值得留意：未来许多错误，会出在一开始就要求了错的东西。

这让我想到，一个人能完成更多工作之后，原本分散在不同人身上的责任，会集中到自己身上。从我的经验看，有些工作确实不再需要三个人分别接手；但这还不足以判断，整个产业的三种职位会减少多少。

我更在意的是：当提案、制作与评判都由自己完成，还有什么能让我发现方向错了？

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 让我更容易把想法做出来。我得替自己留下机会，发现这个想法可能不值得做。

也可以从智能与秩序主题页，看这个系列的其他文章。