补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-13 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
工具调用一多，很多团队的第一反应都是把主流程先串起来：
流程能跑起来之后，大家才开始补“如果某一步失败怎么办”。
但我后来越来越确定，工具链一旦变长，回退策略就不该是上线后的补丁，而应该是设计阶段的主问题。
因为工具链越长，失败就越不是“有没有失败”，而是“会在哪里以什么方式失败”。你不先定义回退规则，系统迟早会在某个半成功状态里把你拖进返工。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-08 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多人会把长期写作失败理解成“内容问题”：
这些当然都有关，但我后来做博客系统和内容迁移时，一个感受越来越明显：长期写作能不能持续，往往先败在系统细节上。
这里我想说的“一个细节”，其实就是：草稿和已发布内容是不是走同一条安全的数据链。
如果一个站点里，草稿写到一半就可能：
那么写作者会天然变得保守。因为每多写一篇未完成文章，系统负担就多一点，心智负担也多一点。
现在大家做长任务系统，最容易把注意力放在“怎么规划得更聪明”上：
这些当然重要，但我后来在线上遇到更多真实事故后，结论越来越清楚：长任务真正先出问题的，通常不是规划，而是恢复。
因为只要任务跨分钟、跨系统、跨多个工具执行，失败就不是偶发事件，而是常态。你不可能要求：
这时候系统能不能继续跑下去，关键就不在“第一次计划得多漂亮”，而在“中途挂掉之后能不能从正确的位置接着干”。
这是一篇测试文章，用于验证我们刚刚实现的混合数据源方案是否能够正常工作。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-03 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
“给 AI 加记忆”这件事，从概念上特别诱人。因为只要系统记住更多，它看起来就会更像一个长期协作者。
但我这两年越做越明确的一件事是：很多记忆系统不是死于“不够多”，而是死于“什么都想记”。
用户偏好想记，最近对话想记，历史任务想记，工具执行结果想记，失败原因也想记。最后系统确实拥有了很多“记忆”，但它不知道哪些该短暂保留，哪些该长期沉淀，哪些根本不该写进去。
所以我现在做记忆系统，第一步不是选向量库，也不是先做召回，而是先把短期记忆和长期记忆的边界画出来。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-07-24 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
多 Agent 方案之所以特别容易让人兴奋，是因为它在演示里几乎总是成立：
界面一铺开，消息一串起来，整个系统会显得非常聪明，也很有“组织感”。但真正往生产环境里放，你很快就会发现它比单 Agent 或工作流系统更难稳住。
我后来总结下来，根本原因不是“多 Agent 不行”，而是很多团队把它当成能力叠加问题，实际上它首先是一个协作成本问题。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-07-21 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多团队第一次做 AI 成本复盘时，最先盯住的都是一个总数：这周花了多少钱，比上周多了还是少了。
这个数字当然重要，但它几乎永远不够解释问题。
我后来越来越相信，AI 成本看板如果只能回答“贵了没有”，那它对工程决策的帮助非常有限。真正有价值的是：这笔钱是被哪种请求、哪种失败路径、哪种系统漂移吃掉的。
前阵子我就碰到过一次很典型的情况：业务请求量几乎没变，但一周总成本突然涨了三成多。乍一看像是模型贵了，结果真正的问题根本不在模型单价。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-07-18 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
从 2025 年开始，几乎所有 AI 编程产品都在往“agentic coding”这个词靠。结果就是一个很现实的问题：大家都在说 Agent，但说的其实不是同一件事。
有人把“补全变聪明了”叫 agentic。 有人把“能一次改多个文件”叫 agentic。 也有人把“能接收目标、自己跑测试、自己收尾”才叫 agentic。
如果边界不先说清楚，团队在选工具、定规范、做试点的时候就会非常混乱。因为你以为你在评估“Agent 能力”，实际上你评估的可能只是一个更强的编辑器插件。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-07-11 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
如果只从管理角度看，“先买工具还是先定规范”很像一个顺序问题；但真正落地到团队里，我更愿意把它理解成一个失败概率问题。因为这两条路都会通向使用 AI 编程，但通向的方式完全不同：
我自己的结论越来越明确：工具当然要买，但规范应该先于工具成为团队共识。
不是因为规范比工具更重要，而是因为如果没有规范，工具会把团队原本就存在的差异和混乱放大得更快。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-07-02 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
我越来越觉得，AI 写代码最大的风险不是它会明显报错，而是它经常会生成一段“看起来特别像对的东西”。这种代码危险的地方就在于，它不会像语法错误那样立刻被发现，反而更容易一路混进 review、测试，最后在边角场景里才炸开。
我印象最深的一次，是一个缓存键生成函数。AI 给出的实现非常自然，变量名也不错，测试样例甚至都能过。但真正上线后我们才发现，它把两个不同参数集在某些顺序下算成了同一个 key，导致缓存串了。
这类问题最麻烦的，不是它难修，而是它在第一次看代码时太像“经验丰富的人写出来的东西”了。