“谁能看到什么”这道难题：给你的 AI 应用加上用户权限

你用 AI 做出来的应用不再只属于你自己的那一刻，就是权限真正成为一个问题的那一刻。在那之前，每个页面都展示所有内容，每个列表都展示每一行，每个按钮对所有人都管用。它是一个假装成多人应用的单人应用。

然后你加上了第一个队友，或第一个客户，或第一个内测用户 —— 而他们看到了一样本不该看到的东西。也许是他同事的工资。也许是一份还没准备好的草稿。也许是管理员设置，意外地暴露了出来。

这就是**“谁能看到什么”**这道难题，它也是非技术型创客在交付一个 AI 应用构建器项目时，最容易弄错的那一件事。好消息是：你不需要变成一个安全专家才能解决它。你只需要一套清晰的方式，去跟你的 AI 构建器谈这件事。

为什么你用 AI 做的应用一开始权限是全开的

当你向一个 AI 构建器描述一个应用时 —— “我想要一个 CRM，让我能添加客户和记录” —— 构建器只为一件事做优化：让它对那个正在描述它的人能用起来。默认做出来的应用是”任何登录的人都能看到所有东西”。这对一个个人工具来说没问题。可一旦出现第二个用户，它就是一场灾难。

这并不是 AI 应用构建器的一个 bug。它是你没告诉它谁被允许看什么的自然结果。构建器根本不知道你的客户名单是敏感的，也不知道”记录”里可能装着你不想让客户看到的东西。这些，你得说出来。

加第二个用户之前要问的三个问题

在你邀请任何人之前，先问自己三件事。把答案写下来 —— 下一步你会把它们喂给你的 AI 构建器。

1. 有哪些角色？

不是哪些人 —— 而是哪些类别。大多数应用有两到四个角色。对一个自由职业者门户来说：“我”和”客户”。对一个内部工具来说：“管理员""经理""团队成员”。对一个社群应用来说：“版主""成员""访客”。早期要忍住别超过四个角色。每多一个角色，你要盯着的规则就翻一倍。

2. 每个角色能看到什么？

在脑子里把应用的每一个页面都过一遍。对每一个都问：客户到底该不该看到这个页面？他们该看到上面所有的数据，还是只看到属于自己的那部分？他们该看到这个页面、但其中某些字段是隐藏的吗？

最简单的模式：所有者看到一切；其他所有人只看到明确授权给他们的内容。这套模式不用怎么定制，就能搞定 80% 的应用。

3. 每个角色能做什么？

同样的练习，但针对按钮和操作。一个成员能删除一个项目吗？一个客户能编辑自己的资料、但不能改自己的套餐吗？一个经理能邀请新人吗？大多数非技术型创客把这一步完全忘了，结果做出来的应用，任何登录的用户都能一键删掉整个数据库。

跟你的 AI 构建器谈权限

一旦有了答案，给你 AI 构建器的指令就自己写好了。它看起来是这样：

更新这个应用，让它支持两个角色：所有者和客户。

所有者能看到所有客户、所有项目、所有发票。所有者能创建、编辑和删除任何东西。

客户只能看到自己的项目和自己的发票。他们看不到客户名单、团队页面或设置页面。他们能查看自己的项目，但不能编辑它们。他们能查看并支付自己的发票。

当一个客户登录时，隐藏指向”设置”和”团队”的导航链接。如果一个客户试图通过网址访问那些页面，把他重定向到自己的仪表盘。

那条指令里有三件事很关键：

按页面和操作来说清楚。“客户能看到他们的项目”是含糊的。“客户能在 /projects 页面上查看、但不能编辑自己的项目”才是 AI 构建器真正能落地的东西。
**说清楚导航该怎么处理。**隐藏链接跟拦住页面不是一回事。这两个你都要。
**把手动输网址的情况也覆盖到。**否则一个好奇的用户，就能往浏览器地址栏里粘一个 /admin，然后大摇大摆地走进去。

我每周都见到的四个错误

看了很多创客交付他们的第一个多用户应用之后，同样的错误反复出现：

**隐藏按钮不等于隐藏数据。**如果你让你的 AI 构建器”为客户隐藏删除按钮”，按钮是会从屏幕上消失。但如果有人摸清了怎么去调用它，底层那个删除操作仍然管用。修法：再告诉构建器”在后端拒绝来自非所有者账户的删除请求”。如果构建器不明白”后端”在你的应用里指的是什么，就让它”在服务端拦住这个操作，而不只是隐藏按钮”。

**一个角色干两份活。**人们会把”付钱的人”和”用应用的人”混为一谈。一个为某项工作付你钱的客户，和一个使用你为那个客户搭建的仪表盘的客户方员工，不是同一个角色。如果你把它们混在一起，接下来一个月你都会在打各种一次性的补丁规则。两个角色。永远如此。

**从第一天起就让用户去邀请用户。**马上加上”邀请一个队友”很诱人。别。对你的头 10 个用户，自己来邀请，手动地，从一个只有你自己看得到的管理面板里邀请。自助邀请是一整类权限规则（谁能邀请谁？被邀请者拿到什么角色？他们能再去邀请别人吗？）。等到你真的需要它的时候再说。

**AI 构建器说什么就信什么，不去核实。**AI 构建器会很笃定地告诉你，权限已经设好了。也许设好了。也许没有。永远要去测：用一个非所有者的身份登录，然后去试着做坏事：点删除按钮、粘贴管理员网址、编辑那些你本不该能改的字段。如果有任何本不该管用的东西管用了，就让构建器专门去把它修好。

邀请任何人之前的一份快速清单

在你把第一份邀请发给第二个用户之前，过一遍这个：

我能用一只手数得过来我应用里的角色。
对每个角色，我都清楚他们该看到哪些页面、不该看到哪些。
我已经用一个非所有者的身份登录过，并确认了那些不该看到的页面是隐藏的。
我已经试过用非所有者的身份往浏览器里粘一个管理员网址，并被拦下了。
我已经试过去点那些本该禁止的删除或编辑按钮，并被拦下了。
如果出了岔子，我有办法迅速移除一个用户的访问权限。

如果以上任何一条没过，那就是你跟 AI 构建器的下一次对话 —— 在你发出邀请之前，而不是之后。

一个能帮上忙的思维转变

为一个多用户应用做权限，主要就是去想象你是一个稍微有点爱打探的、你最不守规矩的那个用户的版本。不是怀有恶意 —— 只是好奇。他们会到处点。他们会粘贴网址。他们会试着去看一眼你截图里被他们瞄到的那个”设置”页面上有什么。

你的活儿 —— 以及你 AI 构建器的活儿 —— 就是确保当他们去看的时候，答案始终如一：要么他们能看到，因为那是他们的数据；要么他们看不到，因为那不是。没有边角漏洞。没有意外暴露的管理员页面。没有”我忘了还有那个页面”。

大多数创客在出了什么尴尬事之前，根本不会去想权限。好消息是：在交付前花 20 分钟把角色想清楚，能帮你省下日后 20 个小时去修它的工夫，外加那封你绝不想写的、给看到了不该看的东西的客户的邮件。

正在做一个带多用户那一面的东西？下次你坐下来跟你的 AI 应用构建器一起干活时，就用一件事开场：把你应用里的角色一个个大声念出来。这是最容易养成的五分钟习惯，而且它能在大多数最糟糕的错误发生之前就把它们逮住。