AI-native 不是多用几个 Token，而是重新设计工作流

最近，OpenAI 分享了 Basis、Clay 和 Exa 三家 AI-native 公司的实践。

这些案例并不是简单地让员工多使用几个 AI 工具，而是把 Agent 放进了公司的实际工作流程：

Basis 把员工 onboarding 过程变成了可以重复使用的 Agent Skill；Clay 为每个客户建立持续更新的工作空间和专属 Agent；Exa 则让 Agent 主动发现集成机会、收集背景信息、创建代码、运行测试，并把结果交给人类审核。

新闻链接：OpenAI：How AI-native companies turn workflows into operating capability

这篇文章让我重新思考，究竟什么才算一家 AI-native 公司。

现在很多企业都在使用 AI。员工用 AI 写邮件、总结会议、生成文案或者回答问题。公司每个月消耗了大量 Token，看起来非常“AI 化”。

但如果公司的工作方式没有发生变化，AI 仍然只是一个更方便的辅助工具。

AI用得多，并不等于公司已经成为AI-native。

真正的变化发生在工作流本身。

传统软件通常等待人来推动流程：员工登录系统、寻找功能、整理资料、填写表格，然后把任务交给下一个人。

在 AI-native 的工作方式中，Agent 可以持续观察状态，在触发条件出现时主动开始工作，调用需要的工具，保留执行证据，并在关键节点把决定交给人。

人的角色也随之发生变化：从重复执行每个步骤，转向定义目标、处理例外和审核结果。

这也是我们设计 SnapLedger 和 Snappy 时正在尝试的方向。

例如，传统财务软件可能会展示一个 Dashboard，告诉用户还有多少笔交易没有处理。但它仍然需要用户自己发现问题、理解问题，再逐项寻找对应功能。

Snappy of the Day 的想法则不同。

Snappy 应该结合用户的银行流水、文档、账本状态、工具使用轨迹和合规日期，判断用户现在最需要完成的事情：

今天是否有一笔大额交易等待确认？ 是否有一张发票没有找到对应付款？ VAT申报日期是不是正在接近？ 用户上次没有完成的任务是否需要继续？ 某个新工具能否帮助用户解决眼前的问题？

它不只是告诉用户“这里有一个功能”，而是把上下文、工具和下一步行动连接起来。

同样，Snappy Front Desk 也不应该只是生成一封营销邮件。它需要从发现潜在客户开始，理解客户背景，选择合适的沟通渠道，记录对话进展，并在客户产生兴趣后继续推动注册和使用。

客户提出需求或者报告 Bug 后，也不应该停留在一句聊天记录里。相关信息可以被整理成工单，进入开发和测试流程，再由我定期审核哪些修改可以真正合入产品。

在这些例子中，AI 的价值都不在于生成了多少文字，而在于它是否把一项工作从开始推动到了结果。

因此，衡量一家 AI-native 公司，也不应该只看模型调用量或者 Token 消耗量，而应该看一些更真实的问题：

• 一个完整任务需要多少人工接力？
• Agent能够持续保留多少上下文？
• 有多少工作从提醒推进到了完成？
• 异常情况是否能够及时交还给人？
• 成功的工作方式能否被保存并重复使用？
• 效率提升最终是否转化成更低成本、更快交付或更好服务？

我越来越相信，未来企业之间的 AI 差距，不会简单来自谁使用了更强的模型。

真正的差距在于：一家公司是否能够把自己最重要的工作拆解清楚，为 Agent 提供正确的上下文、工具、权限和完成标准，再让成功的过程不断重复和改进。

模型提供智能，工作流把智能变成能力。

AI-native不是让每个人都多使用一点AI，而是让整个组织用一种新的方式完成工作。