全文 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
编辑：深思
主编：图灵
热门跟贴