“SaaS 已死”的迷思:从 AI 驱动的内部开发失败中汲取的教训

@emooove
日语2026年8月14日
134K
405
66
7
389

TL;DR

一位 CEO 分享了他利用 AI 构建内部工具的经验,强调虽然创建过程很简单,但对于大多数企业而言,维护、安全和用户体验依然是 SaaS 能够更好地解决的重大难题。

"SaaS 已死"这个说法最近很流行。论点是我们身处一个 AI 可以写代码的时代,应该停止为 SaaS 支付月费,转而自己构建所需系统。

在我的公司 Emooove,过去几个月我们全力投入构建内部系统。真正做下来,我既体验到了成功,也尝到了痛苦的教训。今天,我想基于这段真实经历,分享我对"SaaS 已死"这个说法的看法。

需要明确的是,我是以系统使用者/构建者的身份来写这篇文章的,而不是 SaaS 提供商。

一个任何人都能构建系统的惊人时代

首先,作为一个前提,Claude Code 的出现确实带来了一个"任何人都能构建系统"的时代。这绝非夸张。

在 Emooove,一位入职仅两个月的招聘负责人构建了一个内部 ATS(申请人跟踪系统)。她不是工程师,没有任何工程经验。尽管如此,她创建了一个功能完整的系统,涵盖从导入候选人到筛选管理和仪表盘的全部功能。

此外,我们目前正在开发一个内部系统,以提升核心业务——销售代理服务——的运营效率和质量。我本人每天都投入其中,开始不到两周,我就感觉我们即将做出一个相当不错的东西。

当你可以在内部构建原本每月需要花费数万甚至数十万日元 SaaS 费用的系统时,人们想喊"SaaS 已死"的心情完全可以理解。

然而,一切并非一帆风顺

这是本文的重点。当我们真正去尝试时,事情并没有那么美好。

1. 维护极其困难

不管好坏,你可以"边做边想"地构建东西,所以成型很快。然而,由于需求没有完全梳理清楚,难免有很多粗糙之处。

以我们的 ATS 为例,我们遇到了这些情况:

  • 本该导入的数据没有导入成功。
  • 仪表盘的数字莫名其妙出错。
  • 关键按钮缺失,导致业务操作陷入停滞。

我们遇到了很多"用了之后才发现的遗漏"。在我们的内部销售支持系统上,甚至有一天早上突然无法访问,页面根本打不开。

当然,这些问题可以通过更仔细地定义需求或在使用中持续改进来在一定程度上修复。但在那段时间里,正常的业务运营会受到干扰。如果你抱着"简单又快速"的预期开始构建,最终会陷入困境。我意识到,不应该抱着"构建完就结束"的心态开始,而应该是"构建完继续修"。

由于我们的招聘规模不大,即使 ATS 短暂停摆也能应付。但如果这是一个涉及众多利益相关方的系统,光想想就让我不寒而栗。随着用户数量和影响范围的增加,一次故障造成的损失会变大,难度也会急剧上升。

对于内部系统,你或许还能容忍这些问题;但对于任何对外销售或面向外部世界的东西,比如咨询表单,你应该极其谨慎。

2. UI/UX 永远不会被打磨到精致

我在自己构建系统的过程中意识到:最终效果有些平庸。

AI 最初生成的界面看起来"还行",但实际使用时,细节却很笨拙。虽然你可以通过反复下达指令最终让它看起来不错,但这需要极强的执着和大量的时间。大多数人很可能在中途就妥协了。

SaaS 的界面之所以精致,是因为专业设计师花了数年时间反复吸收用户反馈;这可不是免费就能得到的。

3. 安全问题

这是最可怕的部分。

即使是非工程师,也可以抱着"边做边看"的态度,用 Claude Code 构建功能和 UI/UX。但安全方面也能这样临时抱佛脚吗?至少对我来说不行。身份验证、权限管理、漏洞响应——"能用"和"安全"完全是两回事。

在我们的案例中,幸运的是有一位有安全工程师经验的人,所以这部分我们会让他来负责。即便如此,心中仍有一些不安。一想到没有专家的组织,把客户信息放在一个临时拼凑的系统上并对外公开,我就冷汗直冒。

非黑即白的"生死论"是错误的

我列举了自主开发的种种负面问题,但说实话,它也有很多好处。

  • 你可以打造完全贴合自身业务的系统。
  • 想修什么,第二天就能搞定。
  • 几乎没有月度成本。
  • 公司能积累"我们也能自己构建系统"的诀窍和信心。

问题在于把它简单化为"SaaS 会活还是会死"。采用 SaaS 还是自主构建,取决于公司的具体情况。根据我的经验,这里有五个考量点:

要点 1:公司内部有工程师吗?

如果没有,在安全等领域你会栽跟头,因为非工程师无法凭一时兴起搞定这些。最可怕的地方在于,你能在没有意识到危险的情况下就把功能做出来。关键的分水岭在于,能否找到有经验的人来审查关键环节。

要点 2:利益相关方的数量

如果太多,一旦出故障损失巨大,难度也会急剧上升。相反,小型组织更容易尝试,因为就算系统停摆,道个歉就行了。从影响范围较小的业务开始是比较现实的做法。

要点 3:外部系统还是内部系统

对于内部系统,出了问题风险是可控的。但任何面向外部的系统,一次信息泄露就可能是不可逆的。SaaS 可以把部分责任转移给供应商,而自主开发则一切责任都由自己承担。凡是面向外部的东西,SaaS 那种"久经验证的安心感"的价值就会凸显。

要点 4:你能为维护投入工时吗?

维护的工作量远超你的想象。自主开发不是"构建完就结束",而是"不断修复"。你能带着这种预见去开始吗?如果以敷衍了事的态度开始,你将被修复缺陷的琐事淹没,核心业务也会受到挤压。

要点 5:你喜欢/想做 AI 开发吗?

归根结底,一切取决于这一点。AI 开发比你想象的更繁琐、更困难,而且当 AI 不听话时真的很让人抓狂(笑)。即便如此,你还能坚持到底吗?对于乐在其中的人来说,这是一个很棒的时代,但我不认为仅靠责任感就能坚持下去。

总结:SaaS 并没有死,只是选择更多了

我在标题中用了"失败"这个词,但更准确地说,其实是"好几次差点失败"。我们之所以继续自主开发,是因为我们有经验丰富的工程师,组织规模还小,主要供内部使用,我们做好了投入维护的准备,而且最重要的是,我自己想做。可以说,我们之所以能做这件事,是因为我们处于一个五项条件全部满足的得天独厚的环境中。

反过来,如果一家不满足这些条件的公司把"SaaS 已死"当真,试图自主构建核心业务系统,那才是真的会失败。

SaaS 并没有死。只是"自己动手构建"这个选项现在对所有人敞开了。冷静评估你公司的状况,同时用好 SaaS 和自主开发,难道不是应对这个既便利又充满不确定性的时代的最佳方式吗?

二次创作

使用 YouMind 创作爆款文章

收集素材、拆解爆点、生成视觉资产、撰写内容,并在一个 AI 工作空间里完成分发。

了解 YouMind
写给创作者

把你的 Markdown 变成干净的 𝕏 文章

图片上传、表格、代码块,往 𝕏 上手动重排太痛苦。YouMind 把整篇 Markdown 一键转成干净、可直接发布的 𝕏 文章草稿。

试试 Markdown 转 𝕏

更多可拆解样本

近期爆款文章

探索更多爆款文章