当 AI 能复刻一个 App，你还在为什么付钱？

概念插图：相似的外观背后，可能承担着不同的工作。

最近看到一个介绍 REA 的 Reddit 帖子。按照帖子的介绍，它能让 AI 调用工具分析现有应用，研究功能如何实现，再尝试为自己的项目做出类似功能。

到了 TikTok，创作者 @casey.aicreates 给这个话题加上了一个更大胆的说法：这会不会是软件的终结？

从项目介绍到这个结论，还有很远。但它让一个问题变得具体了：如果我想要的功能越来越容易自己做，每个月的软件订阅还值不值？

有些功能，确实可以自己做

很多人只需要一款庞大软件里的几个功能。为了偶尔合并文件、生成报告、处理一张表，长期支付一整套产品的费用，很容易让人想寻找替代方案。

AI 降低了尝试的成本，也让这种选择更现实。

一个规则清楚、使用范围有限的内部工具，可能不需要复杂的产品体系。团队了解输入、输出和使用者，就可以从一个很小的版本开始，观察它是否足够解决问题。

自建因此成为更多团队能够认真考虑的选择。

使用时间越长，付钱的对象就越复杂

团队买下的可能还有几年的历史数据、同事之间形成的协作方式、客户正在使用的入口，以及出了问题能找到支持的确定性。

界面可以相似，功能也可以接近。把这些关系一起搬走，往往是另一项工程。

客户管理软件就是一个容易理解的例子。客户表、搜索和跟进记录只是使用的一部分。重复数据怎么处理、成员离职后记录如何交接、已有集成是否正常，以及出现故障时谁负责恢复，也会影响团队的选择。

这些成本仍然存在。自建意味着由自己承担其中一部分；购买服务则意味着评估供应商能否持续承担。

所以，未来很多团队会同时做两件事：自己生成一些轻量工具，继续使用一部分成熟服务。

决定之前，可以用下面几项对照自己的情况：

要考虑的事	比较适合先尝试自建	比较值得继续购买服务
需求范围	单一任务，规则清楚，使用者少	多人协作，需求经常变化
故障影响	暂停后可以手动完成	会中断客户服务或重要业务
数据与连接	数据少，导出和迁移容易	历史记录多，已有多个系统依赖它
维护安排	有人愿意长期接手修改和排错	团队没有稳定的维护人手

不妨先挑一个小功能试两周。除了记录省下多少订阅费，也记下修错、调整和处理异常花了多久。一次演示能说明它做得出来，实际使用才能告诉你是否值得继续自己养着它。

工具变多之后，协调仍然需要有人完成

新工具里的数据，怎么进入原有流程？客户信息放在 CRM，讨论发生在 Slack，文档留在 Notion，新做的应用又多了一个入口。

工具省下的钱，可能被来回复制信息的时间吃掉。

对已经在用的服务，团队未必要急着替换。也可以先让它们配合得更好。

Leina 提供了一种做法：在团队聊天中交代任务，通过已授权的 Apps 汇集相关资料，再按要求准备或执行后续工作。具体操作取决于对应连接和账号权限。

对于“我只需要一份跨工具的汇总，却在考虑再买一个软件”的情况，可以先试着在现有工具上完成任务。比如把 CRM 和会议记录放到同一个客户视角下看：

根据已连接的 CRM 和本月客户会议记录，整理仍在推进的客户。列出最近进展、尚未解决的问题，以及记录里已经约定的下一步，每项附来源。两边内容不一致的单独列出，不修改原记录。

先看看这份结果是否已经满足需要，再判断要不要多买或自建一个系统。原来的工具继续承担各自擅长的工作，人少做一些来回复制和查找。

至于自己做的新工具，也可以逐项评估：哪些值得接进现有流程，哪些只是偶尔使用，不需要再增加维护负担。

续费之前，多问一个问题

AI 会继续改变实现功能的成本，也会改变我们衡量软件订阅价值的方式。

下次续费时，除了“这个功能能不能自己做”，还可以问：这项服务持续替我承担了哪些工作？如果换掉它，这些工作会落到谁身上？

把订阅费用、维护时间、迁移成本和团队协作放在一起看，才更容易做出适合自己的选择。

REA 引发的讨论值得继续看。功能更容易实现，会给软件公司带来压力，也会给用户更多选择。但对正在经营业务的团队来说，决定是否继续付钱的，往往还有明天能不能放心使用，以及能省下多少自己的时间。

如果你也有一项卡在多个工具之间的工作，可以先到 Leina 集成目录找找已有服务，再创建 Leina试着完成一次。先用手头的数据做出有用的结果，再决定下一笔软件预算花在哪里。