我做了个 SaaS，AI 一个下午就能复制——然后我想通了一件事
我做了一个 SaaS，发现 AI 一个下午就能复制。问题不是功能不好，是我选错了位置。这迫使我画出一张"栈所有权光谱"，以及一个反直觉的发现：往"轻"的方向走，也不安全。
我做了一个 SaaS，叫 Traction。帮独立开发者追踪产品增长指标。
技术上没问题——Dashboard 能用，数据能跑。但上线后我意识到：另一个开发者用 Cursor 一个下午就能跑出一个能用的 MVP。 没有什么阻止他。我的 UI？AI 生成的。我的业务逻辑？没有独占数据。我的用户体验？一个 prompt 就能复制。
公平地说，Dashboard 类产品的门槛本来就不高。但 AI 把”门槛不高”变成了”门槛为零”——这个差别是质变。
我开始想：问题到底出在哪？不是功能不好，不是设计不行。是我选错了位置。 我把全部精力放在了最容易被复制的那一层——UI 和业务流程。
这迫使我重新想一个问题：在 AI 时代做产品，你到底应该拥有技术栈的哪一层？
Stripe 没有 Dashboard，但没人能复制它
故事一：Stripe。 你用过 Stripe 的支付页面，但你可能从来没有”登录 Stripe 的产品”来完成日常工作。Stripe 没有做一个漂亮的 Dashboard 让商家每天打开——它选择只做支付 API。商家用自己的界面，调用 Stripe 的能力。
Stripe 构建的东西比 Traction 少得多——没有前端、没有用户系统、没有响应式设计。但它的支付网络和合规壁垒，让任何人都无法用 AI 复制一个 Stripe。它做得更少，但更不可替代。
故事二：Notion。 Notion 是一个完整的产品——有 UI、有编辑器、有协作功能、有托管。按理说，AI 应该很容易复制一个 Notion。
但试试看：你能用 AI 复制 Notion 的编辑器，但你复制不了 Notion 上你 3 年的笔记。用户积累的数据，才是 Notion 真正的护城河。 而且 Notion 很聪明地加了 API，让 AI 工具能调用它的数据——AI 生态反而帮它加固了壁垒。
这两个故事指向同一个问题：产品的壁垒不在你做了多少功能，而在你拥有技术栈的哪一层。
栈所有权光谱
我把这个想法整理成一个框架，叫栈所有权光谱——从”你提供一切”到”你只提供一段能力代码”：
L1 全栈交付 你提供 UI + 逻辑 + 数据 + 托管
→ Notion, Figma, 我的 Traction
L2 有界面 你提供 UI + 逻辑，用户可能自带模型
→ Slack Bot, 嵌入式 Widget
L3 无界面 你提供逻辑 + 数据，不管 UI
→ Stripe API, Twilio, OpenAI API
L4 工具接口 你定义工具，AI 负责编排和调用
→ MCP Server
L5 纯能力 你只提供一段可被调用的代码
→ npm 包, CLI 工具, Agent Skill我的 Traction 在 L1——我提供了整个栈，也承担了所有成本，同时每一层都可以被复制。Stripe 在 L3——不做 UI，但核心价值不可替代。Notion 也在 L1，但因为有数据锁定，照样稳固。
你在光谱的哪个位置不重要，重要的是你在那个位置有没有别人拿不走的东西。
那为什么这个光谱现在突然变重要了？
正在发生的三件事
AI 能造 UI 了，所以 UI 不值钱了
这是我在 Traction 上亲身感受到的。当 AI 可以即时生成一个定制化的 Dashboard，你精心设计的 UI 就从卖点变成了成本——你还在为它付出开发和维护成本，而它已经不构成竞争优势。
所以”SaaS 已死”？不。以 UI 为核心价值的 SaaS 正在失去壁垒，以数据为核心价值的 SaaS 壁垒反而在加强。 如果你有一个数据型 SaaS，你需要做的不是恐慌，而是加一层 API 或 MCP 接口，让 AI 能调用你的数据。
软件的消费者变了：从人到 AI
以前你做一个产品，价值链是这样的：
你做产品 → 用户来你的网站 → 用户操作 UI → 价值交付。 每一步都有摩擦，每一步都在流失用户。
MCP（Model Context Protocol）正在构建一条新的价值链愿景：
你定义能力 → 注册到 MCP 注册表 → 用户的 AI 自动发现并调用 → 价值交付。 自动发现和注册机制仍在早期，但方向已经明确：没有 UI 摩擦，没有注册流程，用户甚至可能不知道调用了你的服务。
这和 API 有什么区别？API 面向人类开发者——他们需要读文档、写集成代码。MCP 面向 AI agent——它只需要读 schema 就能使用。API 的消费者是人，MCP 的消费者是 AI。
而且这个趋势还在往更深处走。想象一下：你有一个自己的本地 AI——它了解你的文件、你的偏好、你的工作习惯——然后它自己去发现和调用各种工具。你不再需要一个个安装 App、注册账号、学习 UI。你的 AI 替你做这些事。
这还不是科幻。OpenClaw 这样的项目已经在探索”Chat-native Skill”模式——用户在自己的聊天环境里加载能力，自带 AI 模型，开发者甚至不承担推理成本。据报道，OpenAI 也在探索类似的 Skills 系统，让用户用 slash command 加载模块化能力。这个方向意味着：未来你的产品可能不需要被用户”打开”，只需要被用户的 AI”加载”。
MCP 是给 AI 用的工具箱，Skills 是给 AI 用的操作手册——两者互补，不是替代。但它们指向同一个结论：软件的消费者开始从人向 AI 迁移，你的产品需要为此做好准备。
而这只是第一步。想想 Dependabot：你配置一次，它每天自动检查依赖更新、提 PR、告诉你风险。你不需要”登录 Dependabot”、“使用 Dependabot 的 UI”。这就是自主 Agent 的模式——用户设置一次，AI 持续运行，按需推送结果。 它不需要争夺用户的注意力，不需要用户反复登录。这意味着更自然的按价值收费：你为结果付费，不是为”座位”付费。
如果自主 Agent 成为主流，用户对”登录一个网站、操作一套 UI”的耐心会越来越低。这不会消灭所有产品，但会持续把价值从”界面”推向”能力”——那是不是意味着往轻走就对了？
不过必须说清楚：MCP 和 Skills 生态都仍然很早期，变现模式不成熟。审慎的策略是用小成本试水（一个 MCP Server 可能只需要几百行代码，一个 Skill 可能只是一个 markdown 文件），而不是 all in。
但我要泼一盆冷水
读到这里，你可能觉得结论很清楚了——往轻的方向走，做 API、做 MCP Server、做 CLI 工具就对了。
我一开始也这么想。然后我问了自己一个不舒服的问题：
如果一个 MCP Server 只需要几百行代码，那和”Cursor 一个下午复制一个 Dashboard”有什么本质区别？
答案是：没有区别。
npm 上有超过 200 万个包，绝大多数无人使用。一个轻量级工具——不管是 MCP Server 还是 CLI——如果背后没有独占资源，它和一个通用型 SaaS 一样脆弱，甚至更脆弱，因为连品牌露出的机会都没有。
这就是为什么我说你在光谱的哪个位置不重要，重要的是你在那个位置有没有别人拿不走的东西：
- Notion 在 L1 能活，因为用户 3 年的笔记搬不走。数据锁定比任何 UI 都坚固
- Stripe 在 L3 能活，因为支付网络不是代码问题，是商业关系问题
- 一个行业数据 MCP Server 在 L4 能活，因为价值在数据，不在那几百行代码
- 但一个纯算法的 npm 包在 L5 最危险——今天的热门包，明天可能是 Claude 的内置能力
往右走不是答案。在你选的那一层建立独占资源，才是答案。
那我该怎么选？
别从”我该做什么形态”出发。从”我有什么”出发：
如果你有独占数据（用户积累的内容、行业特有数据集）——做 API 或数据服务（L3），加 MCP 接口让 AI 能调用。你的数据就是壁垒。
如果你有独占的技术能力（别人做不到或做不好的算法）——做 MCP Server 或 CLI 工具（L4）。但要诚实评估”独占”到底有多独占——如果开源社区三个月就能追上，这不叫独占。
如果你有品味和受众（个人品牌、内容能力、一群信任你的人）——做内容 + 能力输出。品味是 AI 最不擅长复制的东西。
如果你什么都还没有——先做一个 L1 产品，在过程中积累数据或受众，再考虑迁移。“先打轻量级”听起来诱人，但没有独占资源的轻量级产品和没有独占资源的重量级产品一样脆弱。
回到我自己
我用这个框架分析了自己。
说实话：我没有独占数据，没有独占算法。我有的是对 AI 产品策略的持续思考，以及把思考变成内容的能力——品味和表达。
所以我的核心策略是博客和 Newsletter（你正在读的）：建品牌、建 SEO 权重、积累信任。品味和观点是 AI 最不擅长复制的东西——AI 可以生成任何观点，但无法生成”这个人踩过坑、做过产品、值得信任”的感知。围绕这个核心引擎，我用不同形态分发同一套能力：开源 CLI + MCP Server 面向开发者社区，后台 AI pipeline（需求挖掘、趋势监控）持续运行喂养内容。
Traction 教会我的不是”SaaS 不行了”，而是一个更具体的教训：在 L1 做了一个没有独占数据的产品，是最脆弱的位置。 下次再做产品，我的第一个问题不是”做什么功能”，而是”在这一层，我有什么别人拿不走的东西”。
FAQ
Q: MCP Server 现在值得做吗？
值得试水，不值得 all in。风险极低——几百行代码的事。目前最有机会的方向是连接独占数据源的 MCP Server（行业数据库、企业内部系统、需要授权的 API），因为纯逻辑的 MCP Server 太容易被复制。变现路径有三条：免费开源建品牌 → 托管 Pro 版收费、API key 按量计费、被更大平台集成收 license。先出一个免费版本验证需求，再决定是否加码。
Q: AI 对产品形态的冲击会不会被高估了？
有这个可能。监管可能限制 AI agent 的自主行动，用户隐私焦虑可能压过便利性，模型能力也可能出现瓶颈。但即使冲击只实现了预期的一半，“价值从 UI 向数据迁移”和”AI 成为主要软件消费者”这两个方向仍然成立。做**“AI 强了有用，AI 弱了也有用”**的东西是最好的对冲——独占数据在任何场景都有价值，API 不管调用者是人还是 AI 都成立。
Q: 怎么判断我的产品在光谱的哪一层？
问自己三个问题：① 用户能不能绕过你的 UI 直接获取核心价值？如果能，你的 UI 不是壁垒。② 你的核心价值是逻辑还是数据？逻辑容易被复制，数据不容易。③ AI agent 能不能直接调用你的服务？如果不能，你正在错过一个增长中的分发渠道。三个答案连起来，你的位置和迁移方向就清楚了。
如果你觉得这篇有用，我在 Twitter 上持续分享 AI 产品策略和独立开发实践。