周五下午没什么事，我把 settings.py 里 AI_CHAT_ 开头的行全捞出来看了一遍。十一个。
有点意外。记忆里没加过这么多，可顺着往下数，AI_CHAT_ENABLED、AI_CHAT_TIMEOUT、AI_CHAT_DAILY_LIMIT、AI_CHAT_FALLBACK_PERCENT、还有几个我得看注释才想起来当初是干什么的。其中四个从上线那天起就是 False 或者默认值，一次都没被打开过。
AI_CHAT_ENABLED 是唯一一个真被拨动过的，演练那天关了十五分钟（95 篇那次），之外一直开着。它也是唯一有明确处置流程的开关。
AI_CHAT_DAILY_LIMIT=20 从防被刷写起，后来变成防我自己算错账（77 篇里那四百多块），再后来在灰度期间还兼了个"天花板"的角色。一个配置项被三种理由反复解释，倒也不算坏事，至少每次都真用上了。
AI_CHAT_TIMEOUT=8 没改过。当初是从 20 个 sync worker 和 timeout=1800 倒推出来的，属于那种"看一眼就知道别乱动"的值。
AI_CHAT_FALLBACK_PERCENT 从 0 到 10，卡了两周，最后跳到 100（93 篇）。它现在还叫"灰度比例"，实际已经没有灰度了。
AI_SUMMARY_COMPRESS 是想把长对话的早期轮次压成摘要（83 篇那个思路），代码写了一半，卡在"压缩器自己也可能丢关键信息"，没接上线。
AI_MEMORY_CROSS_SESSION 是跨会话记忆，讨论时所有人都说该做，一碰到隐私和账号体系就散会，连代码都没有。
AI_RERANK_ENABLED 倒是完整写完了，79 篇那次只在离线批处理里开过，实时链路因为多两三百毫秒没敢开。这个开关本身没问题，问题是它守着的那套 rerank 服务后来被挪去做别的了，现在打开会连到一个已经不存在的地址。
AI_PROMPT_CACHE_DEBUG 是我为了查缓存命中率临时加的，查完就忘了。它现在还会往日志里多写一行，没人看。
四个里，两个是"想做没做完"，一个是"做完了没敢用"，一个是纯粹忘了删。
我在群里提了一句"要不要清掉几个"，回得最快的是「万一以后要用呢」。
这个理由听着敷衍，其实挺难反驳。跨会话记忆说不定下个季度就排上了，摘要压缩说不定换个模型就能用，rerank 服务也可能哪天迁回来。删掉只要一分钟，重新加回来得连着改配置、文档、部署脚本，还得有人记得当初那些取舍。
可留着的代价是慢慢累积的。新人接手看到十一个开关，第一反应是"这套系统好复杂"，然后花半天去问哪个能动；部署文档里得逐个解释，解释到第四个连写文档的人自己都开始含糊；每次改配置都得确认有没有漏掉某个默认 False 的分支，而那些分支里的代码从没在生产环境跑过一次——真哪天被打开，谁也不知道会炸成什么样。
我自己也没底气。提议删的人是我，四个没打开的开关里有两个是我加的。
商量半天的结果是加了注释，没删代码。每个没启用的开关上面标一行「未启用，原因见 xxx，重新启用前先确认依赖」。算是折中，也算是把决定往后推。
说实话这个结果我一点都不意外。前三批文章里写的那些事——改提示词加版本、给调用打 source、给降级加计数、把回复存进审计表——全是在给一个三个月前还只有二十行代码的功能加东西。加总是比删容易，而且每次加都有当时充分的理由。
真要说三个月下来最有用的一个判断，大概是最开始那个"AI 挂了不能影响送达"。它没体现在这十一个开关里，是一句写在 chat_send 里的顺序：先把用户消息存好，再去想 AI 那件事。后面所有的降级、熔断、演练、横幅，都是这句话的注脚。
VidDown 技术博客，前后三批 AI 文章都在这儿了。
那份配置我打印出来过一次，A4 一页，十一个开关占了大半张。边上有同事用铅笔圈了两个，写着"这俩是啥"。纸现在夹在显示器底下，圈还在。