规矩写进文件，AI 才会照着做

7 月 28 日我写了一份功能台账的方法文档，起因是我自己做出来的一个功能不好用。

那时 yPulse 刚上了一个「完成度」页面，给每个项目列一张已实现、未实现的清单。真用起来我就发现，清单得由我来填。可我连 yAssets 这种复杂一点的项目都列不全，每个功能我都参与过，参与过和能随时一条条报出来是两种记忆。我在文档里写，人是这个系统里最贵、最不可靠的一环，状态不该靠人脑维护。

那份文档的第一条原则是，状态的更新必须是干活顺手带出来的，不能单独成为一件事。企业里管多个项目的办公室早就证明过，要人额外填报的状态系统，最后不是被糊弄就是被废弃，填报和干活是两件事。

所以台账住在每个项目自己的仓库里，跟代码放在一起。我的活大多是 AI 会话在干，每个仓库的说明文件里写着，做完一个功能，就在同一次提交里把台账对应的那一条改掉。发版的时候再核对一遍，台账和这次发布的内容对不上就不发。每天夜里 yPulse 把所有台账收一遍，只校验，不替任何人编状态。现在矩阵里有 27 份台账，yLookbook 那一份有 282 条。

台账也出过事。yLookbook 有一次发版，台账里有一条的分类不在规定的词表里，yPulse 那边收台账的检查红了一上午。后来 yLookbook 多了一个检查台账的脚本，发版前先跑。yPulse 也有一条同样的命令，推送台账之前要跑，一份解析失败的台账会让整个仓库悄悄掉出夜里的同步。

页面的做法也是这样一份一份写下来的。八月份我陆续写了几份页面规范，数据表格页是 8 月 9 日，表单页是 8 月 16 日，第二天是反馈，提示、加载、空状态和出错用同一套说法。这些规范的原件住在组件库 yBlocks，抄到每个项目里。每个项目的说明文件里有一张表，先判断要做的页面属于哪一类，再去读那一类的规范，用现成的组件拼，不许手搭外壳。

发版也写成了文件。每个仓库有一张发版卡，写着版本号在哪个文件、门禁跑哪几条命令、产物发到哪里、上线以后怎么核验。我说一声「发版」，后面十几步照着卡走完。卡上记的都是实测过的事。比如 yLookbook 的构建常常卡在下载字体上，有一次删掉缓存重试，连败了七次，后来发现不删缓存直接重跑，31 秒就过了。这句话现在就写在那张卡上，下一个会话不用再试七次。

有几条规矩是被事故逼出来的，写在我自己的全局说明里，每个会话开头都会读到。我同时开着整个矩阵的好几个本地服务，曾经有会话按名字批量结束进程，一下把它们全杀了，这种事前后出了三四次。现在的规矩是只能按编号结束自己这个会话起的进程，别人的一概不碰。还有一条是收尾的流程分两套。主业那个项目要开合并请求，副业的项目只提交、不开请求。副业这边近两百个版本里只有一个合并请求，是 AI 照着主业那一套开出来的。从那以后，两套流程在说明文件里分开写，每一步都标明归哪一套。

平台上的数据也走同一条路。10 月 7 日，B 站后台显示《秩序之下》有三集前三秒就流失了三成多的观众，同类视频的中位数是 24.7%。我没有停在一句「以后开头要好看」，而是写了一个脚本，每支片子导出以后量开头三秒，第一秒内画面不动就不出片。这个脚本后来抽进了 yReel，几个仓库共用。

我这么做的理由很简单。AI 的每个会话都是从零开始的，聊天里交代过的事，换一个会话就没了。写进文件的规矩，下一个会话开工前会读到，也不会因为我某天忘了提而失效。

上周末查出 YouTube 上十几条视频都被我选成了「面向儿童」，几乎零播放。改过来以后，我顺手把这件事写进了 YouTube 的发布手册，填表脚本交给我点之前，也会先提醒一句受众该怎么选。