RE:CZ

待办事项：系统开放、AI资产化、用户与支付系统

系统架构

👤 技术开发者、系统架构师、业务决策者以及对AI资产化和用户系统优化感兴趣的专业人士
本文记录了作者在2026年2月4日的工作思考，主要围绕四个核心议题展开。首先，讨论了开放系统权限的重要性，提出通过非对称权限设计来控制数据访问，以支持Yuan作为数据源和下单平台的发展。其次，分析了AI资产化的能力，指出API资产化是初级形态，未来BYOK可能成为趋势，但中间商在业务组装中仍有价值。第三，探讨了用户系统的增强，提出通过Edge Function实现Supabase的PassKey登录方案，以提升用户体验。最后，简要提及支付系统的构建需求，强调对接支付平台以解决收款合规性问题。文章旨在为技术开发者和业务决策者提供实践参考。
  • ✨ 系统权限需非对称设计以控制数据访问，支持开放平台发展
  • ✨ AI资产化通过API管理实现利润，但BYOK未来可能成为趋势
  • ✨ 用户系统可通过Edge Function增强，支持PassKey登录提升体验
  • ✨ 支付系统需对接平台解决合规收款问题
  • ✨ 技术设计应兼顾安全性与用户体验，推动业务创新
📅 2026-02-04 · 1,481 字 · 约 6 分钟阅读
  • 系统权限
  • AI资产化
  • 用户系统
  • 支付系统
  • 技术设计
  • 业务优化
  • Supabase
  • API管理

Table of Contents

一些待办事项一、开放我们的系统二、AI 资产化的能力三、用户系统的增强四、支付系统

一些待办事项

现在是 2026 年 2 月 4 日，0 点。

工作了一整天，总的来说是一边让 AI 干活，一边思考的过程。有点困了，明天再接着搞。

有一些值得做的事情，记录一下。

一、开放我们的系统

Yuan 的主机内的权限，连接主机的权限是否能进行非对称设计？即，并非所有的终端连入主机后都能获得相同的权限。这有助于我们更好地控制权限，也就能更好地开放我们的数据。目前由于主机内的权限机制的缺失，导致我们不得不暂时封闭一些数据源，也不敢随意公开给 AI。最终这影响了实验的进展。

具体来说，读取 SQL 的权限可以给吗？写 SQL 的权限可以给吗？在 Method 层面，是默认可以访问还是默认禁止访问？授权又该如何进行？这些问题都需要好好设计一番。

好处是，我们可以给 Yuan CLI 更高的权限，从而让 AI 更好地工作。

未来，Yuan 可能会成为一个数据源和下单平台。而中间的策略往往是百花齐放的。就目前而言，除了 Yuan 内置的 Kernel+Agent 体系的策略平台，还有 Mage 做的 TimeLab 策略平台，还有我最近在做的持久战实验仓库。它们基于不同的设计理念和技术栈，未来都可能会并存。然而，这些策略平台都需要访问 Yuan 的数据和下单接口。

因此，如何设计好权限体系，是一个重要的问题。开放，必先设防（奉化腔）。

二、AI 资产化的能力

最近在用一些中转的 API，我发现它们在用 New API 这个项目进行用户管理和计费。它们本质上是将自己的订阅池资产化了，批发转零售，卖给用户。但这样的出售方式，由于不绑定业务，导致无法卖出高价。这里的议价权，让步给了上游业务侧。

从某种程度上来说，它们属于是 AI API 资产化，属于 AI 资产化的初级形态。而构建上游 AI 产品，可以利用底层的 API 资产，润滑上游的业务，可以让用户不需要直接面对 API 配置的复杂性，从而提升用户体验。直接订阅产品，或者按量付费产品！用户只会在意组合之后的产品，而不会在意底层的 API 是怎么配置的。这里又是一层利润空间。

目前，API KEY 的管理，对于普通用户来说，依然是一个门槛。很多用户并不清楚 API KEY 的概念，甚至不知道如何去申请和管理 API KEY。因此，AI 业务的中间商，依然有很大的机会。其实这就是一个认知差的问题。这种利润是极易规模化的。

当然，我认为未来，BYOK 肯定是一个趋势。用户会希望使用自己的 API Key，从而避免数据泄露的问题。另一方面，用户也希望以 API 成本价购买 AI 服务，而不是被中间商赚差价。其实，中间商也是做了很多业务组装的，这也是有价值的。在业务侧的 BYOK，可以作为一个选项，但最近这几年，在 API KEY 的概念充分普及之前，BYOK 并不会成为主流。

三、用户系统的增强

Supabase 依然是一个不错的选择，但它的用户系统，依然有一些不足之处。例如，不支持 PassKey 这种无密码登录方式。我想到一个令 Supabase 支持 PassKey 的方案，它来源于：

在 Edge Function 里用 admin（service_role）身份为某个用户创建 Supabase session，并拿到 access_token / refresh_token，返回给前端。

  • Supabase 没有“admin 直接生成任意用户 session”的官方 API。
  • 官方推荐做法：在后端（Edge Function）使用 auth.admin.generateLink + auth.verifyOtp 的组合，模拟一次 magic link 登录流程，从而获得该用户的 session 对象（里面就有 access_token / refresh_token 等）。
  • 这个流程完全可以在 Edge Function 内部完成，不必真的发邮件给用户，也不需要用户点击链接。

因此，我们可以通过 Edge Function 完全实现 PassKey 登录的功能。自此，基于 Supabase 的用户系统，能用邮箱注册，用邮箱登录，可以再用 PassKey 登录。整个过程是无密码的，用户体验会更好。不过 PassKey 是一个重型的交互方式，不适合对每次操作都用，它只适合与一开始的登录，以及一些重要操作（例如修改密码，修改支付方式等）绑定。平时的会话保持，仍然复用 Supabase 的 access_token / refresh_token 机制即可，JWT 机制就很好用了。

四、支付系统

一个非常老而现实的问题，怎么让用户付钱？怎么合规地打到公司的收款账户上？怎么样才能绑定一个二维码，用户扫码支付，然后钱能打到公司的账户上？这些问题都需要解决。

我们会有若干方案，对接支付平台或许是一个不错的选择。必须去走一走流程了，回头再来分享。

Referenced By