产品的未来

Something maybe wrong

昨天写了一篇文章：新时代，软件将如何变化？

在那里面，我试图去描绘一件事情：软件提供的，是被封装的做事能力，而其所包含的代码、界面、开发流程都只是表象。而现在，软件的载体在消失，能力在泛化

写完之后，我意识到了一个问题：以往，我们认为科技公司的产品就是软件。那么，在 AI 普遍改变社会生产关系后，未来科技公司的产品还是软件吗？以及，产品的未来是怎样的？

这个问题也让我想了很久，本文制作当下想法的记录，或许在1年以后来看，我所言的都是错的

用户不再是人

一直以来，我们默认产品是给人用的

人点按钮、填表单、切页面，一步步走完操作路径。现在越来越多的产品在被 Agent 调用，Agent 读 API、传参数、拿结果、判断要不要继续下一步，它不需要看见界面

人的角色跟着变了。过去人亲自做事，现在人表达目标、检查关键节点、承担最终责任。从操作者变成了委托者，产品设计也要从帮助人操作转向帮助人委托

用户变了，产品的设计语言就要跟着变。以往，优秀的产品要让人看得懂、找得到、点得动。曾经我还提过一个“眯眼法则”：优秀的产品，需要用户在眯着眼睛完全看不清的前提下，也能知道该怎么用

而如今，如果一个产品是给 Agent 设计的，那么它几乎完全不用考虑配色、动态交互什么的，而是需要有需要清晰的能力描述、输入输出 schema、权限边界、错误返回和上下文说明。Agent-readable 在变成和 user-friendly 同等重要的产品标准

你可能没见过 Agent-readable 这个词... 这是我刚编的，但我觉得很合理

在这个过程中，产品的界面也也应该随之改变。过去 UI 帮人一步步完成操作，未来 UI 帮人看见 Agent 做到哪一步了、哪里需要确认、哪里可以回滚。界面从操作台变成了监控台

API 的粒度也在变。传统 API 是动作级的，create_order，send_email，update_record，一个接口做一个动作。Agent 更需要任务级接口，prepare_customer_meeting，summarize_contract_risk，generate_weekly_report。一个接口完成一整件事

软件给人用时体验是路径，给 Agent 用时体验是协议。未来软件的体验设计，会有一部分转化成协议设计

如果用户只和通用 Agent 对话，Agent 在后台替用户挑选和调用各种其他工具、软件、接口，那很多公司会失去直接的用户关系。外卖平台让餐厅失去了一部分堂食关系，电商让品牌失去了一部分门店关系。Agent 入口可能让 SaaS 失去前台关系

旧的默认姿态是人使用系统、AI 辅助人。新的默认姿态是 Agent 驾驶系统、人监督 Agent。当然，现如今很多公司以为给现有系统加一个 AI 功能就行了，什么自动帮你找符合你口味的外卖、自动帮你比架机票，但其实远远不够

新的一代产品，应该建立在新的地基之上

开发，不再围绕功能

我的本职是产品经理，以前做产品设计的时候，绝大多数时间是在「加功能」。核心工作是给成型产品增加各种 Feature，筛选功能、导出功能、报表功能，然后规划排期交付开发

而现在用 AI 进行开发的时候，我需要做的是定义任务节点。比如什么时候要调用哪些工具，什么时候算是交付完成，等等...

写到这里的时候我停下来想了一下：这期间发生了什么？以往的开发要围绕功能进行，这是软件行业找到的最小可计量交付单位，能估出一个工时，能辅助排期，能在上线后打勾验收

这里再说一个题外话：很多大型项目，也是按功能点和页面数量算钱的，有专门的计算方法。毕竟智力劳动很难直接定价，那就数页面、数按钮、数字段，把不可量化的工作折算成可计量的交付物。这也是为什么你打开很多大型软件，会看到密密麻麻的二级菜单，每个菜单项背后都对应一个工作量、一笔款、一次验收

这时候不难发现，基于功能点开发能反应「系统能做什么」，而基于任务的开发则是回应「要完成什么」。完成一次客户会前准备，可能涉及日历查询、邮件检索、CRM 数据拉取、摘要生成、文档排版，跨了好几个传统功能模块。Agent 产品必须围绕任务来组织能力

Skill 会成为流程的最小可复用单元。过去复用代码，SaaS 复用流程模板，Agent 时代复用 Skill。一个 Skill 是一段可迁移的做事方法，可能比某个功能更接近业务价值本身。在我看来，Agent 产品价值更会在于什么时候调用、调用后怎么判断、失败后怎么办、结果怎么验收等等..

Memory 会成为长期差异化的来源。功能可以复制，界面可以模仿，模型可以替换，但一个系统长期积累的用户上下文、项目历史、组织规则、失败案例，很难瞬间搬走。留住用户的关键，是系统越来越懂你怎么做事

Eval 同时承担两个角色：测试系统和进化引擎。没有 Eval，Agent 的进步无法被证明。没有 Eval，Skill 的升级没有方向。没有 Eval，企业不敢把核心流程交出去

Permission 会成为 Agent 产品体验的核心。用户最关心的不只是 Agent 能做什么，还有它会不会越界。能读什么、能改什么、能发什么、能删什么、哪些地方必须问人，这些边界要让用户看得见

传统软件的交互节点是按钮，Agent 软件的交互节点是确认。用户不需要每一步都参与，但关键判断必须可审查。哪些步骤自动执行、哪些步骤必须用户确认，这条分界线的设计是新课题

飞机自动执行高风险过程所以需要黑匣子，Agent 自动执行复杂任务同样需要。Trace 记录的不只是动作，还有上下文、判断依据、工具调用和结果。没有 Trace，Agent 进不了严肃业务场景

当然，在开发的过程中，很多东西也在发生显著的变化

比如，前文提到过的，以前规划产品是在加功能，而后续的产品开发可能是在加能力。举个例子，对于办公软件迭代的时候，是围绕着「上传」、「下载」、「创建副本」这种按钮去开发；而对于 Agent 产品，则是添加能力，比如「生成图片的能力」、「剪辑音频的能力」。产品进化，从功能增加变成能力增长，产品规划，从 Feature Roadmap 到 Capability Roadmap

于此同时，验证产品是否有用的方式。以前是通过构建 MVP 最小可执行版本，来验证一个产品能不能用。而接下来则是应该验证一个真实任务能不能闭环。如果起一个名次的话，我觉得可以叫可以叫 MVT，Minimum Viable Task。用户给出意图后 Agent 能否完成，结果是否可接受，过程是否可追踪，失败是否可恢复

方法的产品化

这里得说一下，Skill 和提示词是不同的：提示词通常是一段文本，告诉模型怎么回答问题，Skill 则是一个打包的 .zip，里面可以包含多种素材（比如包含能直接运行的 .py 文件），以及一份说明书告诉 Agent 怎么完成一类任务，让 Agent 稳定完成某类事

一个好的 Skill 包含任务边界、执行步骤、工具说明、输入输出格式、示例、脚本、模板、错误处理和质量标准。它是流程、知识、工具、模板和评估标准的混合体，更像一个轻量级的安装包，中心从代码换成了方法

通过 Skill，方法本身可以产品化了。咨询公司的方法论、律师的审查框架、编辑的改稿流程、运营的复盘模板，都可以变成 Skill 直接分发。过去各种工具，只能封装高度标准化的流程，现在连需要判断力的方法也可以封装。

以前是 SaaS，Software as a Service；现在则是 SaaS，Service as a Software，服务业的软件化，从这里打开了新入口。在这里，Skill 是一次性软件和长期软件之间的中间形态，但每次执行都可以生成不同的过程和结果。换句话说：Skill 可复用的过程生成器

我自己的公众号排版，本身也是一套 Skill 流水线，封装了我之前收工排版、程序排版的经验，以及我在公众号排版里遇到的各种 Bug 和我的处理办法，这样每次 AI 就能一次性的把我的内容进行正确的、一致的进行排版

Skill 加上 Memory 才能从通用能力变成个人能力。还是以排版这个事儿为例，你看到的各种加粗，都是排版期自主决定的...我的 AI 知道我的创作偏好、历史风格，甚至各种奇怪的恶趣味，然后不断内化成了自己的风格。还有，以上这些还得再加上 Eval 才能持续进化。结果是否符合格式、是否遗漏关键信息、是否减少人工修改，这些都应该进入评估，这是一种稳健的工程化，你也可以把它叫做 Harness

Skill 的竞争，是隐性经验的结构化能力。什么时候该这样做、什么时候绝对不能这样做、异常怎么判断、优先级怎么排、什么结果看起来对但其实有隐患。这些判断长在做了十年这件事的人的直觉里

这时候会发现，一个 Skill 改了就可能影响大量 Agent 任务。Skill 需要版本管理、回滚、灰度、测试和审计。所以未来想必也会出现 SkillOps，和今天的 DevOps、MLOps 一个逻辑

OPC？NPC！

前段时间各地都出台了 OPC（一人公司）的相关政策：一个人通过各种 AI 工具，能够产生匹敌一个团队的生产力，在这里：人提出目标，Agent 去执行。本质上，还是自动化的增强版

那么，下一代产品会从复杂系统转向简单的委托关系。信任会成为比功能更重要的体验

商业模式也跟着变。如果 Agent 真正交付任务结果，按账号收费就太粗糙了。按完成任务数、节省时间、处理量、成功结果、自动化比例来计费，这些方式在慢慢出现。卖的东西越来越接近结果本身

再往远看一步，如果 OPC 是 ok 的，那么为什么不做 NPC（零人公司），在这里，意图本身也可能由系统生成。库存数据异常，系统自己发起补货任务。客户流失风险升高，系统自己发起挽回动作。项目延期概率上升，系统自己调整资源。没有人下达指令，系统根据数据、环境和目标函数自己判断该做什么

到那个阶段，Agent 的驱动力来自更高层的目标函数：增长目标、成本目标、风险目标、效率目标、服务质量目标。Agent 网络围绕这些目标持续生成任务、分配资源、执行动作、评估反馈。Agent 不再围绕用户请求运行，开始围绕目标状态运行

如果未来是一个人管理一群 Agent，那么他自然也可以是 Agent 之间自己发现问题、提出任务、互相调用、互相审计。人只在少数高风险、高责任的节点进入，定义系统为什么存在、什么不能做、什么代价不可接受

这时候权限问题会变得更尖锐。过去管的是 Agent 能不能发邮件、能不能改文件。未来还要管它能不能主动发现目标、主动创建任务、主动影响资源分配。Agent 治理，从执行权限升级到意图权限

最终形态，可能是一个会自我生成任务的 Agent 执行网络，用户看不见页面，甚至看不见任务提出的过程，看到的只是一个组织持续运行后的状态变化

最后

写到这里的时候，发现今天是 5月4号，青年节，的确是一个值得奋斗的时候

过去十五年，互联网和软件，在一个个行业的吞下，接下来被吞掉的，则是自己的旧形态