80% 的 App 会被替代？Clawdbot 创始人更在意：AI 能不能把事办成

全文 3,000字 | 阅读约 8 分钟

（Peter Steinberger：80% 的 App 会被替代）

“这可能会让你手机上 80% 的 App 消失。”

Peter Steinberger 在 2026 年 2 月1 日的访谈里抛出这个判断时，不是在预测，而是在描述他的日常。

去年 11 月在摩洛哥，有人在 Twitter 报告 Bug。他在外面吃饭，顺手截图发到 WhatsApp。几分钟后，智能体回复：已修复，代码已提交。

整个过程，读取 Twitter 内容、检查代码库、修复 Bug、提交代码、回复用户，全部自动完成。

而 Peter 只是在外面和朋友聊天。

这就是他说的“80% App会消失”的逻辑：既然有了足够聪明的助手，为什么还需要单独的健身App、待办App、购物App？这些功能，智能体都能直接完成。

但 App 会不会消失，取决于 AI 能不能真正把活做完。而 Peter 要证明的，正是这一点。

作为 PSPDFKit 创始人，他曾把 PDF 工具打磨到被全球 10 亿台设备使用。但几年后，他选择用另一种方式重启：离开团队，抛开流程，选择用 AI 作为合作伙伴。

一个人交付完整产品OpenClaw（原名Clawdbot）。

第一节｜5 到 10 个智能体，并行交付

现在，Peter 不再是自己写代码，而是指挥多个智能体一起开工。

他说：

“我现在做的事，更像个调度员。我有 5 到 10 个智能体在同时干活，我来规划路线、验证成果、打通环节。”

这些不是人，是 AI 编程工具：Claude Code、Gemini CLI、Codex……它们各自负责不同任务：

• 有的智能体在建前端页面；

• 有的在重写数据模型；

• 有的在写命令行工具 ；

• 有的在处理 WhatsApp 消息接入 ；

• 有的在调试 API 调用问题 ……

Peter 把这种方式比作玩星际争霸：你得同时管着多个基地，每个基地都在生产不同的东西。

他通常同时开5 到 10 个终端窗口，每个运行不同的智能体。有的在写代码需要40 分钟，他就切到另一个终端处理别的任务。在这些终端间快速切换，像指挥官在战场上调度部队。

“它们不是一次性帮我写完，而是需要不断对话、不断修正。就像带一个远程团队，你要分配任务、检查成果，遇到问题还得随时沟通。”

在这个系统里，他既是使用者，也是设计者：他理解哪种任务适合 Claude Code，哪种更适合 Codex；他知道什么时候要拆解指令，什么时候要补充上下文；他也知道怎么设计测试，让模型能自我检查、逐步改进。

“我设计的协作结构，能让所有代码都更容易验证。这比我亲自写每一行更有效。”

从管理者的角度看，这几乎是一个人同时扮演了产品经理、技术负责人、架构师、测试工程师，以及一个十人团队。

第二节｜本地验证替代CI，2分钟闭环

这套协作系统怎么运转？关键在验证机制。

在大多数公司里，代码要上线，得过三道关：代码审查（Code Review）、持续集成测试（CI）、再由技术负责人最终批准。流程长，反馈慢，错一步就得重新来。

在 Peter 这里，流程完全不同。

“我不审代码了，也很少等CI。我的模型自己测试，自己验证。”

他用的是另一套逻辑：闭环验证。

什么意思？就是每一段由智能体写出的代码，都必须能自己跑、自己测、自己查错、自己改。否则不允许上线。

这些智能体会自动：

• 为新功能生成测试用例；

• 模拟运行结果，验证输出是否合理；

• 检查是否有报错、卡死；

• 如果失败，重新提示自己修复；

• 成功后，自动记录文档、更新配置。

整个效率远超传统开发。过去一段代码要等 CI 跑完至少 10 分钟，现在智能体 2分钟内能完成测试、诊断、撤销、重试。Peter 甚至用本地命令行工具替代了CI测试流程：

“我在本地就跑完所有测试，它说 OK，我就合并。更快、更稳，也不打断节奏。”

他不是不在乎质量，而是用另一种方式把控质量：验证结果而非验证过程。

代码好不好，不再靠工程师的 LGTM（代码看起来没问题），而是靠实际验证：能运行、测试通过、改动无影响。

这套验证机制的效率极高，但 Peter 发现，很多人误解了它的本质。

“我看到太多人以为这意味着可以完全自动化，花几个月构建复杂的编排系统，让几十个AI互相对话。但那些系统缺少最重要的东西：品味。如果人不在循环里指导，产出就是一堆垃圾。”

他不用MCP、不用多层代理，只是直接和智能体对话：告诉它做什么、怎么验证。简单、直接、可控。

这才是闭环验证的核心：不是让AI完全自主，而是让人能更高效地把控质量。

第三节｜不写文档，只做对话

过去要做一款产品，流程很熟悉：先开会写需求文档，再开会做功能拆解，然后排期排优先级，最后才进入开发。

Peter 不这么做。

我不写文档，也不开会。产品怎么做？就和 AI 聊。

他用 Claude、GPT 等 AI 工具，把整个产品设计过程变成了一场持续对话：从想法到功能规划，从界面交互到实现逻辑，全程通过提示一步步生成、推敲、重构。

比如他要加一个自动提醒功能，不是写文档告诉别人怎么做，而是直接对助手说：

“我想让它在我三天没联系某人时提醒我，能做到吗？我们需要查哪些信息？”

AI 会先提出几种可行方式，解释各自的优缺点，然后追问：你希望在哪个平台提醒？要不要支持语音？

这个过程，像是一个懂技术、会思考的产品搭档，不断接近真正可落地的方案。

更重要的是，这些对话内容自动记录为产品说明、开发线索和使用指南，不再需要人手动写需求文档、知识库、注释说明。

“每一段聊天，都是功能文档的一部分。”

Peter 甚至让智能体自己生成用户文档、调试接口、测试计划，把原本需要写下来的工作变成了说出来就能完成。

这种对话式工作甚至改变了他看待代码贡献的方式。

“我现在更喜欢把Pull Request 叫做 Prompt Request（提示请求）。我读提示词比读代码更感兴趣，因为提示词传达了意图和思路，比代码本身更有价值。”

一些非技术背景的人也开始给他提交代码。比如他的前商业合伙人是律师出身，现在也在发PR。Peter 会提取他的意图，然后用 AI 重写代码。

传统流程里需要三四个角色、几轮会议、几份文档才能完成的事，他一个人通过 AI 对话就能完成。

第四节｜一个人用智能体搭建团队

Peter 的工作方式看起来是一个人单干，实际上是一套新的协作模式。

传统团队的协作靠明确的职责分工、规范的流程节点、频繁的沟通对齐。他的协作系统靠的是清晰的任务边界、实时的反馈验证、持续的上下文共享。

区别在哪？

• 他不需要开会对齐，因为每个智能体都能看到完整的上下文；

• 他不需要等待反馈，因为验证在本地就能完成；

• 他不需要文档交接，因为对话记录本身就是文档。

更重要的是，这种方式让他保持了产品的完整性。

“在团队里，你得不断解释：跟产品经理解释技术限制，跟设计师解释实现难度，跟前端解释后端逻辑。每次沟通都是妥协。但现在，我脑子里有完整的画面，智能体帮我把它实现出来。”

从想法到上线，不再需要经过无数个人。

这可能才是智能体改变软件开发的真正意义：不是让每个人写代码更快，而是让少数有完整产品思维的人，可以不依赖庞大团队，就能把产品做出来。

Peter 的 Clawbot 在Discord 上线一周，就有 3000 多开发者围观，贡献了 500多个代码提交。

这些人看到的不只是一个智能体产品，而是一种新的可能性：也许未来的软件公司，不是几百人的团队，而是十几个有完整产品能力的人，各自用智能体把想法变成现实。

访谈结束时，Peter 说：我再也回不去传统写代码的方式了。

一个人，完整地把想法变成产品。

Peter 证明了，一个人靠 AI 智能体干出一个团队的活，至少在 2026 年，这件事已经可以做到。

识自AI

本文由AI深度研究院出品，内容整理自Peter Steinberger（PSPDFKit创始人、Clawdbot开发者）2026年1月访谈等网上公开素材，属评论分析性质。内容为观点提炼与合理引述，未逐字复制原访谈材料。未经授权，不得转载。

星标公众号， 点这里 1. 点击右上角 2. 点击"设为星标" ← AI深度研究员 ⋮ ← 设为星标

https://www.youtube.com/watch?v=W2cBTVr8nxU

https://openai.com/index/introducing-prism

https://m.economictimes.com/tech/artificial-intelligence/openai-launches-prism-heres-all-you-need-to-know-about-the-free-ai-workspace-for-scientific-research/articleshow/127684206.cms

https://techcrunch.com/2026/01/27/openai-launches-prism-a-new-ai-workspace-for-scientists

https://www.youtube.com/watch?v=AcwK1Uuwc0U

来源：官方媒体/网络新闻，

排版：Atlas

编辑：深思

主编：图灵