个人与其他工作隔离：部署前先判归属，密钥只写路径
一、先说事故
我是 Hugozen。这篇从一次不太体面的失误讲起：我把一个本不属于个人站的工具，部署到了我个人的托管账号里。
东西上线之后才发现归属不对。当时我没有尝试"就这样留着"或者"改改再用"。我把它整个删掉，在该去的地方重建了一遍。损失不大，但这个动作让我意识到：部署前我没有一个固定的"判归属"步骤。部署命令能跑通，并不说明目标对。
我在旗舰文里写过，个人项目和其他工作要隔离：个人项目用个人的模型账号和密钥，其他工作走它自己的通道，两边不混用。那篇讲的是原则。这篇讲的是原则落到操作层要做什么，以及我在密钥这一块踩过的另一个坑。
对外我只会说"个人项目与其他工作隔离"，不展开其他工作的任何细节。这也是这套做法的一部分：边界划清，说话也要在边界之内。
二、部署前归属判定三问
现在每次部署前，我（或者我派出去的 bot）必须先回答这三个问题。答不上来就不动手。
1. 这个东西属于谁？ 是个人站的，还是其他工作的？这一问看的是项目本身，不看命令行里当前是哪个账号。很多人会反过来，看当前登录的是谁就往里推，我就是这么出错的。
2. 这次部署的目标账号是谁？ 在执行之前，明确读出当前登录的是哪个身份、会推到哪个项目。读出来的结果要和第一问的答案对上。对不上，停。
3. 推错了怎么办？ 能不能整体撤回、谁来批准、需不需要先备份。涉及线上配置、域名解析、数据迁移这类动作，默认由我本人批准。我这次的做法是删除重建，之所以代价可控，是因为那个东西还很新，没有积累数据。如果是已经有数据的东西，这条路走不通。
三问加起来不到一分钟，但它把"我以为是对的"换成了"我核对过是对的"。这也是我整套协作方式的核心：把相信换成核对。
我还加了一条配套规则：bot 不自动部署。写稿、改代码、跑构建都可以交给 bot，但部署这一步由我执行，或者至少由我在三问之后点头。
三、模型与密钥分流
隔离不只是部署目标，还有"谁在花谁的钱、谁在碰谁的密钥"。
我的做法分两层：
模型分流。 个人项目的任务走个人的模型通道，其他工作的任务走它自己的通道。个人敏感的任务只走个人通道，不会因为"那边额度还有"就借用。我平时用的是几家主流模型服务与编辑器类工具，但无论用哪个，归属先于便利。
密钥分流。 个人项目的密钥只在个人项目里用。同一个站的测试，也只用这个站专用的、带封顶的密钥，不借别的站的。这样即使某个密钥泄露或者被刷，影响范围也只在那一个站。
四、密钥进专用保险库，文档里只写路径
这一条我执行得很死：
- 所有 API key 迁入专用的密钥保险库，不放在笔记、聊天记录、brief 或者仓库里。
- 笔记和文档里只写取用路径，也就是"去哪里取"，永远不写值本身。
- 这条对 bot 同样适用。brief 里的红线之一就是"不要出现任何密钥"。
- 写文章也一样，所以你在这篇里看不到任何保险库的名字、条目名或者路径，这是刻意的。
只写路径的好处是：笔记可以放心地分享和交接，接手的人（或者新的 bot）知道去哪取，但拿不到值。取值需要它自己有权限。
五、每台机器各自一个服务账号
保险库解决了"值放哪"，下一个问题是"谁来取"。
我的规则是：每台机器各用各的服务账号，而不是一个账号到处用。理由很直接：
- 某台机器出问题，可以单独停用它，不连累别的机器。
- 哪台机器取过什么，能分得清。
- 轮换的时候可以一台一台来。
六、踩坑：轮换时旧令牌先删了
这是我在密钥上踩的坑。
我轮换服务账号时，旧的 token 被删掉了。依赖它的那一侧随即开始报「服务账号已被删除」，取密钥的动作全部失败。问题不在新账号，而在旧的先没了，而新的还没有被所有用到的地方切换过去。
回头看，错在顺序。现在我按这个顺序做：
- 先建新的服务账号和 token。
- 在这台机器上换成新的，跑一次真实的取值，确认能用。
- 确认所有依赖旧账号的地方都已经切换。
- 最后才删旧的。
另外，报错信息里常带账号标识，贴到笔记或聊天里之前，先把标识抹掉，只留错误类型。这条和"密钥只写路径"是同一个道理。（报错原文里的账号标识一律抹掉，只留错误类型。）
七、可执行清单
把上面的内容收成能直接抄的检查项：
- 部署前先判归属： 这个东西是个人站的，还是其他工作的？答不出来不部署。
- 读出目标账号： 执行前确认当前登录身份和目标项目，与第一条的答案一致。
- 先想回滚： 写清能否撤回、谁批、要不要备份。涉及密钥、DNS、支付、数据迁移的，本人批准。
- bot 不自动部署： 它交证据（构建结果、线上检查），部署由我来。
- 模型与密钥分流： 个人通道和其他工作通道不混用，一个站一个封顶密钥。
- 密钥只进保险库，文档只写路径： 笔记、聊天、brief、仓库里都不放值，报错里的账号标识也要抹掉。
- 每台机器一个服务账号： 能单独停用，能分清谁取了什么。
- 轮换先建后删： 新的验证通过、所有依赖都切完，再删旧的。
八、小结
这些规则没有一条是新发明，事故都是因为没有固定步骤，靠"我觉得没问题"。一个人维护这么多站，靠记忆和小心不可靠，可靠的是把关键动作写成清单，让自己和 bot 每次都走一遍。
协调者模型、任务流和更多踩坑，在旗舰文里：我怎么用一群 AI bot，一个人跑独立站矩阵。
我会继续把 Agent 协作、SEO·出海、商业化三条线上的经验写成这样的清单。想跟进的话可以订阅 /posts 的 RSS。