上一篇我写过，我给自己做了一个很小的 iMessage 到 Codex 网关。
手机发一句话，家里的电脑收到以后，把这个请求交给mac mini上的codex处理，再把结果回到手机上。
这件事看起来很方便。人在外面，手机在手边，突然想确认一个后台任务、整理一段文字、查一个公开资料、判断一个配置问题，不用打开远程桌面，也不用在手机上来回切换工具。
但我真正花时间想的，反而不是怎么让它更强。
而是怎么让它不要太强。
很多个人自动化出问题，并不是因为功能太少，而是因为一开始就给了太多能力。能读所有目录，能写文件，能调用插件，能打开浏览器，能连各种账号，能保存完整日志，还能从远程入口触发。
听起来很自由，实际上很危险。
所以我做这类 AI 辅助工具时，第一版宁愿笨一点，也要先只读、先受限、先能复查。
我真正需要的，不是“手机控制电脑”。
我需要的是：手机可以请求家里的电脑替我完成一个受限的小任务。
这两句话差别很大。
如果是远程控制电脑，那它应该能打开应用、移动文件、运行脚本、改配置、登录后台，甚至替我操作很多东西。
但我的真实场景没这么复杂。
我更多遇到的是这些事：
这些需求，本质上都不需要写入权限。
既然不需要，就先不给。
这是我现在做个人 AI 工具时很重要的一个原则：不是因为 AI 做不到，所以不给权限；而是因为当前任务不需要，所以不给权限。
入口越宽，后面的风险越难控制。
所以我没有给这个小工具做公网入口，也没有先做成一个完整 Web 服务。对我来说，第一版只需要一个很窄的入口：固定的消息通道、固定的触发前缀、固定的一对一使用场景。
这不是为了显得原始，而是为了减少需要防守的面。
一个普通人做自己的自动化工具，最怕的是一开始就把入口做得像产品。多端登录、多用户、网页面板、远程 API、长会话、历史记录、任务队列，听起来很完整，但每多一个入口，就多一层需要考虑的权限和误触。
我的做法很简单：
| 边界 | 我的选择 |
|---|---|
| 谁能触发 | 只保留自己使用的一对一入口 |
| 怎么触发 | 固定前缀，普通消息不执行 |
| 从哪里进入 | 不开放公网服务，不做通用 API |
| 出错怎么办 | 返回结果或状态，不默默继续扩大权限 |
先把入口做窄，工具就不容易失控。
我不希望一个远程触发的小请求，默认进入我平时工作的所有项目。
所以它应该在一个单独的、干净的工作目录里运行。这个目录可以很空，也可以只放少量专门给它看的材料。它不应该默认读取我的主项目、历史草稿、私人配置和各种工作文件。
这个设计的意义很实际。
当我在手机上发一句“帮我查一下某件事”，codex不需要顺手扫完整个电脑。当我让它判断一个状态，它不需要顺便接触所有项目。当我让它整理一段文字，它也不需要看到和这段文字无关的文件。
很多人谈 AI 安全，会直接跳到很复杂的权限系统。
但个人使用里，一个非常朴素的办法就是：让它先待在一个空房间里。
需要什么，再把什么递进去。
只读是我最看重的一层。
它的意思不是工具永远不能写入，而是第一阶段不写入。
先让 AI做这些事：
暂时不让它做这些事：
这样做以后，哪怕它理解错了我的意思，损失也有限。
它最多回答得不好，或者判断得不准。这个问题我可以复查、重问、修正。但如果一开始就给写入权限，它理解错一次，就可能把问题从“回答不准”变成“东西被改了”。
这不是不相信 AI。
这是承认自动化的基本事实：能力越大，误触成本越高。
我做这个小工具时，还会刻意关掉很多看起来很有用的能力。
比如插件、个人配置、浏览器控制、外部应用控制、图片生成、多代理协作、默认记忆，以及各种可能读到更多上下文或发起外部动作的入口。
不是这些能力不好。
而是这个具体场景暂时用不上。
如果我只是想让手机发一句话，得到一个受限回答，那么它不需要突然变成一个全能工作台。全能当然诱人，但全能也意味着每次触发时，我都要担心它到底能碰到哪里。
我的经验是：个人 AI 工具第一版要先做减法。
能不联网，就不联网。
能不写入，就不写入。
能不保存，就不保存。
能不用插件，就不用插件。
能让人最后确认，就不要自动替人提交。
工具先变可靠，再慢慢变强。
很多自动化系统喜欢保存完整历史。
这对调试当然方便，但对个人工具来说，也可能变成新的风险。尤其是消息入口、AI 请求、任务内容和返回结果，如果全部长期保存，时间久了就会堆出一份很不必要的个人记录。
所以我更愿意只保留必要状态。
比如最近是否运行成功、最后一次错误大概是什么、当前是否准备好、任务有没有超时。至于完整消息内容、私人问题、临时请求，如果不是当前排错必须，就不要长期保存。
一个小工具是否成熟，不只看它能做什么，也要看它不保存什么。
只读不是终点，而是起点。
如果一个 AI 辅助工具连续一段时间都稳定，确实能帮我减少切换成本，也没有出现误触和越界，我才会考虑慢慢放开一点能力。
但放开也不是一下子全开。
我会按这样的顺序来：
| 阶段 | 可以做什么 | 仍然不做什么 |
|---|---|---|
| 只读阶段 | 查资料、看状态、总结、建议下一步 | 不写文件，不操作外部账号 |
| 草稿阶段 | 生成草稿、生成命令建议、整理检查清单 | 不自动执行，不自动提交 |
| 半自动阶段 | 在指定目录生成文件，等待人工检查 | 不直接发布，不直接删除 |
| 授权阶段 | 单次明确授权后执行具体动作 | 不保留长期无限权限 |
这样做虽然慢一点，但每一步都知道自己增加了什么风险。
对普通人来说，AI 工具最好的状态，不是替你完全接管，而是把你从重复的小动作里解放一点，同时保留最后的判断权。
如果你也想把 AI 接进自己的工作流，我觉得可以先问这些问题。
入口
权限
数据
执行
复查
这些问题不复杂，但很有用。
它们能帮人从“我想让 AI 替我做更多事”，回到“我到底需要它帮我做哪一小段事”。
我现在越来越觉得，真正能长期用下去的个人工具，不一定是最炫的。
它可能很小，入口很窄，权限很低，功能也不多。
但它刚好解决一个真实问题。
比如人在外面时，帮我查一个公开信息；不在电脑前时，帮我确认一个状态；脑子里冒出一个想法时，帮我整理成几条清楚的下一步。
这些事情单独看都不大，但它们减少的是生活里的摩擦。
而一个中年人真正缺的，很多时候不是更多功能，而是更少切换、更少担心、更少需要记住的东西。
所以我宁愿先做只读和受限执行。
不是因为我不想让 AI 更有用。
而是因为我希望它有用得更让我安心一点。
本文是个人技术实践记录，不构成安全方案、产品推荐或部署指南。涉及远程触发、自动化执行、消息处理、账号权限和本地文件访问的工具，都应根据自己的设备、账号、权限和风险承受能力谨慎设置；不建议在不了解边界的情况下开放公网入口、保存敏感消息或授予自动化工具长期写入权限。
莫白来 建立&维护
