前言

「镜室」最开始不是一个“产品”，更像是一个很私人、很实验性的想法：我想把一个人、一套思维方式、一种长期积累下来的判断习惯，蒸馏成可以反复进入的 .skill，然后通过对话把它重新激活。

一开始我做的是自己的 禹尧珅.skill。它不是简单的“模仿我说话”，而是希望能在不同关系、不同场景里切换语气：和自己复盘时更理性，和朋友聊天时更松弛，面对工作、老师、同事时更清楚、更克制。后来我发现，如果这个机制只服务于一个人，它会很有意思；但如果它可以接入更多 skill，它就会变成一个真正可扩展的对话平台。

于是，「镜室」从一个本地 skill 文件，慢慢长成了现在这个网站。

一、最早的起点：先把“我自己”蒸馏出来

这个项目的第一步，其实不是写网页，而是做 skill。

我把自己和一些重要关系里的聊天记录、个人描述、博客信息都整理出来，先尝试蒸馏一个「禹尧珅.skill」。当时的核心问题是：这个 skill 到底应该像谁？

后来逐渐明确下来，它不是“女朋友视角”，也不是“别人眼中的我”，而是一个帮助我理解自己的工具。它应该每次先判断对话对象是谁，再决定语气。如果是我本人在和它对话，它应该偏理性、偏复盘、偏帮助我看清自己；如果是朋友、家人、亲密关系，则可以更生活化、更有情绪温度；如果是老师、同事、工作协作，就要更严谨。

这一阶段最重要的收获是：一个 skill 不能只是语气包，它必须有使用边界、场景判断和长期记忆。

所以后面做网站时，我没有把它设计成普通 ChatGPT 壳子，而是围绕 skill 来组织一切。

二、从聊天页开始：先做一个能用的镜室

最早的网页版本很简单：选择一个 skill，选择模型和温度，然后开始对话。

但真正用起来之后，问题马上暴露出来：

• 对话历史需要保存，不然每次刷新都断掉。
• 不同用户的对话必须隔离。
• AI 回复要支持 Markdown，不然长内容很难读。
• 用户应该能复制、点赞、点踩、反馈，让 skill 慢慢吸收。
• 移动端不能只是“勉强能看”，否则实际使用会很痛苦。

于是聊天页经历了很多轮重构。现在的 /chat 已经更接近一个工作台：左侧是历史对话，右侧是当前对话，中间通过 dock 栏切换主页、skill、账户和定价。模型和温度后来从用户界面拿掉，统一放到后台管理，避免用户每次都陷入“我到底该选哪个模型”的选择成本。

这个阶段我做了几个对体验很关键的小功能：

1. 云端同步对话历史
   对话不再只存在浏览器本地，而是按用户保存到 Supabase。换设备或刷新页面之后，历史仍然能回来。

2. 导出 Markdown
   每个对话可以导出成 .md，这对复盘、写作、整理观点都很有用。

3. 反馈进入记忆
   点赞、点踩和评论不只是 UI 动作，而是可以沉淀到 skill 记忆里，让后续回复更贴近真实使用偏好。

4. 更稳的错误处理
   早期经常遇到模型超时、返回空内容、Netlify 函数报错、JSON 解析失败。后来逐步增加了更清楚的中文报错、模型测试、主用/备用模型切换，至少不会让用户卡在一个莫名其妙的英文错误里。

三、Skill 库：镜室真正变成“平台”

当 禹尧珅.skill 跑通之后，我开始接入更多公开 skill。

现在镜室里已经放进了毛选、八字、乔布斯、马斯克、芒格、峰哥、张雪峰、巴菲特等不同类型的 skill。它们的价值不在于“扮演某个人”，而在于提供一种可进入的思维框架。

比如：

• 毛选更适合做问题分析、矛盾拆解、战略判断。
• 乔布斯更适合讨论产品、审美、取舍和表达。
• 马斯克更适合第一性原理、工程压强、目标拆解。
• 芒格更适合多元思维模型、反向思考和长期主义。
• 八字 skill 则是另一类结构化推演工具。

每个 skill 都有自己的详情页，里面会说明它适合做什么、怎么使用、原始 GitHub 仓库在哪里。这个设计很重要，因为 skill 不是盲盒。用户在使用前应该知道：这个 skill 的“味道”是什么，它适合解决什么问题，不适合被期待成什么。

后来我还加了「提交你自己的 skill」入口。用户可以提交名称、GitHub 仓库地址和简要说明，后台审核通过后再上线。这里我没有做成完全无审核的自动发布，因为外部 GitHub 仓库不能未经检查就进入生产环境。现在的逻辑更稳一点：用户提交，管理员审核，通过后再进入自动/半自动发布流程。

四、账户、权限和邀请码

随着网站从“自己玩”变成“别人也能用”，账户系统就变得必须。

现在镜室使用 Supabase 做登录注册。注册时需要邮箱验证码，也需要同意隐私政策和服务条款。后来我又重新加回邀请码机制：新用户注册必须填写邀请码 08060910，已经注册过的用户不受影响。

之所以加邀请码，不是为了故意制造门槛，而是因为这个阶段的网站还在持续变化。模型成本、额度、支付审核、skill 发布流程、后台权限都还需要观察。公开注册太快放开，反而会让系统还没稳定时就承担太多不可控的使用。

账户系统里还做了这些东西：

• 昵称和邮箱唯一性检查。
• 邮箱验证码注册。
• 忘记密码。
• Free / Plus / Pro / 管理员身份。
• 每个用户独立额度。
• 订阅到期时间。
• 管理员无限额度。

五、支付：从 Paddle 到手动收款码

一开始我考虑过接 Paddle，也讨论过 Stripe、Lemon Squeezy、Creem 这些方案。但真正落地时发现，海外支付系统对主体、审核、地区、收款都有要求，不适合立刻作为第一版上线。

所以最后先做了一个更朴素但可控的方案：微信/支付宝收款码 + 后台人工审核。

用户在定价页选择 Plus 或 Pro 后，会弹出支付方式。选择微信或支付宝后显示对应收款码，用户支付完成后填写自己的微信/支付宝用户名并提交。后台审核通过后，系统会自动给用户改套餐、增加额度、设置一个月后的到期时间。

目前的套餐逻辑大概是：

• Free：默认试用额度。
• Plus：适合轻度用户，额度更多。
• Pro：适合更高频、更深度使用。
• 支持续费。
• Plus 可以补差价升级到 Pro。
• 后台可以手动调整用户套餐、额度和到期时间。

这套方案不够“自动化”，但很适合早期产品：流程透明、成本可控、问题容易定位。

六、后台：从“能看数据”到“能运营”

如果只是自己用，后台可以没有。但一旦有用户、有支付、有 skill 提交、有通知，就必须有后台。

现在后台主要做了几块：

1. 用户管理
   查看用户、套餐、额度、到期时间，支持修改套餐、修改额度、删除用户。

2. Skill 管理
   管理员可以决定某个 skill 是否启用。禁用后，普通用户在首页、详情页、聊天选择里都看不到；管理员仍然能管理。Skill 也可以拖动排序，用来控制首页展示顺序。

3. Skill 审核
   用户提交 skill 后，管理员可以通过、拒绝、填写备注。通过后进入发布流程。

4. 支付审批
   用户提交支付记录后，后台审核。通过变绿、拒绝变红，并同步通知用户。

5. 通知中心
   管理员可以发布公告或活动，支持全体用户或指定用户。活动可以领取额度。用户端通过铃铛看到未读消息。

6. 模型管理
   模型选择从前台移到后台。管理员可以配置提供商、模型、API 节点、key、温度，并设置一个主用模型和一个备用模型。主用失败时自动切备用，用户侧不需要关心这些细节。

后台后来也做了不少体验打磨：比如 tab 切换时先显示缓存内容，再静默刷新；Skill 开关、支付审批、提交审核尽量局部更新，不让页面每点一次就整块闪烁。这个改动很小，但对“产品感”非常关键。

七、模型路由：把复杂性藏到后台

最开始我把模型、温度、提供商都暴露给用户。后来越用越觉得不对。

普通用户不是来做模型评测的，他们只是想进入某个 skill，把问题聊清楚。如果每次都要选 DeepSeek、OpenRouter、SiliconFlow，再选一堆模型名，再调温度，使用门槛会变高。

所以后面我把模型选择放进管理员后台。用户只需要选 skill，剩下由系统决定。

现在的模型路由逻辑是：

• 后台设置一个主用模型。
• 后台设置一个备用模型。
• 主用模型正常时直接使用。
• 主用模型超时、失败或返回空内容时，自动切备用。
• 后台可以测试模型是否连通，并显示响应秒数。

这个设计的意义是：把不稳定性挡在产品背后。用户看到的是“能聊”，管理员看到的是“为什么能聊、哪里坏了、怎么切换”。

八、上线前的稳定性打磨

这个网站后面花了很多时间在一些“不显眼但很重要”的地方：

• 首页返回时不要重新播放动画。
• 对话回复不要被额度刷新接口拖慢。
• 后台操作不要整页刷新。
• 移动端历史列表和聊天区要能正常滑动。
• 滚动条不要使用浏览器默认的廉价样式。
• Markdown 回复要自动渲染。
• 网站图标、通知图标、dock 图标风格要统一。
• 404、隐私政策、服务条款、退款政策都要补齐。
• Netlify 环境变量、Supabase schema、模型 key、支付记录表都要能对上。

这些东西单独看都不大，但它们决定了网站到底像“临时 Demo”，还是像一个可以被别人认真使用的产品。

九、现在的镜室是什么

如果用一句话概括，现在的镜室是：

一个点击即用的蒸馏 skill 对话平台。

它不是单纯的 AI 聊天框，而是一个围绕 .skill 展开的使用空间。每个 skill 都是一种可进入的思维房间；用户选择房间，提出问题，得到回应，再通过反馈让它慢慢接近自己想要的形态。

目前它已经具备这些基础能力：

• 官网首页。
• Skill 库和详情页。
• 聊天页。
• 用户登录注册。
• 邀请码注册。
• 云端对话历史。
• Markdown 回复。
• 对话导出。
• 反馈记忆。
• Free / Plus / Pro 套餐。
• 手动支付审核。
• 通知中心。
• 后台用户管理。
• 后台 Skill 管理。
• 后台模型管理。
• Netlify 部署。
• Supabase 数据存储。

十、后面还可以继续做什么

镜室现在已经能公开试用，但还远远不是终点。

后面我觉得最值得继续做的方向有几个：

1. 更好的 Skill 标准
   现在不同 skill 的质量、结构、使用说明还不完全统一。后面可以定义更清楚的 SKILL.md 规范，比如适用场景、输入格式、禁用边界、参考资料、示例对话。

2. 更自动但安全的发布流程
   未来可以让后台审核通过后，由 worker 自动拉取 GitHub 仓库、校验 SKILL.md、生成详情页、更新白名单、触发 Netlify 部署。但这个流程必须非常谨慎，不能让未经校验的仓库直接进生产。

3. 更强的长期记忆
   现在反馈记忆已经能用，但还可以更结构化：区分表达偏好、事实记忆、关系背景、长期目标和负反馈。

4. 更细的额度和成本控制
   模型调用成本是真实存在的。后面可以做更细的模型成本统计、失败重试策略、不同套餐的调用策略。

5. 更完整的产品叙事
   镜室不是“又一个 AI 工具”。它真正有意思的地方，是把人的思维方式、知识系统和关系语气封装成可以进入的房间。这件事需要更清楚地讲出来。

结语

回头看，镜室的开发过程其实很像它自己的产品隐喻：一开始只是一个房间，后来不断加镜子、加门、加走廊，最后变成了一个可以反复进入、不断扩展的空间。

它从 禹尧珅.skill 开始，经历了聊天页、Skill 库、用户系统、支付系统、后台管理、通知中心、模型路由和稳定性打磨，慢慢从“我自己能用”变成“别人也可以试用”。

这个过程里最有价值的不是写了多少功能，而是逐渐看清楚了产品的核心：

镜室不是替用户思考，而是给每一种思维方式一间可以被进入、被对话、被修正的房间。

这也是我愿意继续把它做下去的原因。

项目地址：https://github.com/yys806/shen.skill
体验网址：https://skill-chat.cn/