补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-03 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
“给 AI 加记忆”这件事，从概念上特别诱人。因为只要系统记住更多，它看起来就会更像一个长期协作者。
但我这两年越做越明确的一件事是：很多记忆系统不是死于“不够多”，而是死于“什么都想记”。
用户偏好想记，最近对话想记，历史任务想记，工具执行结果想记，失败原因也想记。最后系统确实拥有了很多“记忆”，但它不知道哪些该短暂保留，哪些该长期沉淀，哪些根本不该写进去。
所以我现在做记忆系统，第一步不是选向量库，也不是先做召回，而是先把短期记忆和长期记忆的边界画出来。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-06 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
现在大家做长任务系统，最容易把注意力放在“怎么规划得更聪明”上：
这些当然重要，但我后来在线上遇到更多真实事故后，结论越来越清楚：长任务真正先出问题的，通常不是规划，而是恢复。
因为只要任务跨分钟、跨系统、跨多个工具执行，失败就不是偶发事件，而是常态。你不可能要求：
这时候系统能不能继续跑下去，关键就不在“第一次计划得多漂亮”，而在“中途挂掉之后能不能从正确的位置接着干”。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-08 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多人会把长期写作失败理解成“内容问题”：
这些当然都有关，但我后来做博客系统和内容迁移时，一个感受越来越明显：长期写作能不能持续，往往先败在系统细节上。
这里我想说的“一个细节”，其实就是：草稿和已发布内容是不是走同一条安全的数据链。
如果一个站点里，草稿写到一半就可能：
那么写作者会天然变得保守。因为每多写一篇未完成文章，系统负担就多一点，心智负担也多一点。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-13 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
工具调用一多，很多团队的第一反应都是把主流程先串起来：
流程能跑起来之后，大家才开始补“如果某一步失败怎么办”。
但我后来越来越确定，工具链一旦变长，回退策略就不该是上线后的补丁，而应该是设计阶段的主问题。
因为工具链越长，失败就越不是“有没有失败”，而是“会在哪里以什么方式失败”。你不先定义回退规则，系统迟早会在某个半成功状态里把你拖进返工。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-24 11:40。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多团队做 AI 应用时，最先花时间调的是模型和 Prompt，最晚补上的才是评测集。结果就是每次改完一版，大家只能靠感觉判断：
我后来基本不再接受这种“看起来顺一点”的判断方式。因为一旦系统要持续迭代，你迟早得回答一个很现实的问题：这次变更到底改善了什么，又伤害了什么。
所以我现在给 AI 应用搭第一版评测集，目标从来不是“做出一套完美 Benchmark”，而是先做出一套能指导下一次工程决策的小而准的样本集。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-30 10:20。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多人做 AI 服务优化时，一看到延迟上来，第一反应就是“加缓存”。这当然不是错，但问题在于：缓存并不是天然减延迟，它只是在某些命中条件下减延迟。
前阵子我就遇到过一次很典型的反效果。团队本来是想给一条 AI 处理链降一点时延，结果缓存加上去之后，p95 反而更高了。
后来排查下来，问题不是 Redis 慢，也不是代码写挂了，而是我们缓存错了层。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-31 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多团队一提到“评测”，脑子里其实混着三件完全不同的事：
它们都叫评测，但解决的问题并不一样。
如果边界没分清，团队就很容易出现两种典型混乱：
所以我现在会先把这三种方法当成不同阶段的不同工具，而不是互相替代的同一种东西。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-09-06 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多 AI 项目一旦进入评测阶段，最容易被一个数字绑架：准确率。
准确率当然重要，但我后来越来越少单独看它。因为在线上系统里，准确率高并不自动等于业务效果好。有时候它甚至会掩盖真正的问题。
一个最典型的例子，就是某类客服分流功能。离线看分类准确率挺高，团队一开始很满意。但上线后业务同学还是不买账，因为真正痛的地方并没有被解决：
也就是说，模型在“答题”这件事上可能不错，但业务在“运转”这件事上并没有变更好。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-09-10 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多团队把 AI 成本看板做成了另一种账单页面：
这些数字不是没用，但如果成本看板只能回答财务问题，它对产品和工程团队的帮助会非常有限。因为真正要做决策的人，通常更关心另外一些问题：
所以我现在越来越不把成本看板当“财务报表”，而把它看成一块产品控制面板。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-09-21 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多私有化部署项目，第一天讨论就会迅速滑向这些问题：
这些问题当然会谈，但如果第一天就直接冲进模型和机器，后面很容易越做越偏。
因为私有化部署项目最先决定成败的，往往不是“模型叫什么名字”，而是你到底在为哪个约束买单。
我现在几乎把“第一天谈什么”理解成一次边界对齐。
边界如果没对齐，后面所有技术决策都会漂：
所以私有化项目第一天，我更关心的是先把问题谈窄，而不是先把方案谈满。