写给第 1550 篇——AI 工程这两年，我最后悔没早点做的三件事
写给第 1550 篇——AI 工程这两年，我最后悔没早点做的三件事
这是第 1550 篇。
我不打算写什么感慨，不打算说"感谢陪伴"、"一路走来不容易"这类话。不是我矫情，是我觉得说那些没什么意思。
我想讲的是：这两年做 AI 工程，我犯的最大的三个错误。不是技术上的 bug，是判断上的失误——那种在当时觉得没问题、回头看觉得"这事要是早一年做就好了"的决策。
写下来，也许对你有用。
第一件事：太晚开始写技术文章
2022 年底，GPT-3.5 出来，我当时就判断这是范式级别的变化，开始认真学 AI 工程相关的东西。RAG、向量数据库、Prompt 工程、Agent 架构——我花了大量时间研究，做了不少原型，也在公司内部主导落地了几个项目。
但我开始写这个公众号，是 2024 年年初。
整整一年多，我把学到的东西全放在脑子里，偶尔在内部分享一下，然后就没了。
你知道这意味着什么吗？意味着我积累的东西，只有极少数人知道我做过这些。
我不是说"写作是为了涨粉"——虽然这也是结果之一。我想说的是更本质的一件事：
写作逼迫你把模糊的理解变成清晰的表达。
举个具体的例子。关于"多租户向量数据库隔离"，我在脑子里想过这个问题很多次，有一些直觉上的判断。但直到我真的要写一篇文章，要把"每租户独立 Collection"和"共享 Collection + Metadata Filter"的取舍说清楚，我才发现我对这件事的理解其实还有很多模糊的地方——哪些场景下一定要独立 Collection？阈值是什么？混合策略的具体触发条件？
写作逼我想清楚了这些问题。
更重要的是，我发现很多我以为"大家都知道"的东西，其实大多数人并不知道。我以为 Embedding 模型迁移是个常识问题，写出来之后发现很多人根本没想过这个坑。我以为向量库的并发控制是基础知识，写出来之后才知道大多数人没有遇到过真实事故、没有建立起这套思维框架。
如果我从 2023 年初就开始写，到今天会是什么状态？我不确定，但我知道一定不比现在差。
后悔程度：★★★★★
这是我最后悔的一件事。一年多的积累，没有留下任何公开的痕迹，无法被人找到、引用、评价，也无法逼迫我把每一个判断说清楚。
如果你现在有类似的处境——在一个你认为有价值的领域里积累了不少东西，但还没有开始写——我的建议是：不要等"想清楚了"再写，写作本身就是想清楚的过程。
第二件事：太晚做系统化的 AI 评估体系
这件事我要从一次失败说起。
2023 年中，我们上线了第一个知识库问答产品。用户可以上传文档，然后用自然语言问问题，AI 回答。
发布前，我们怎么评估质量的？
我和产品同事用了两个小时，手动测了 50 个问题，觉得回答挺好的，就上线了。
上线之后，我们收到了一堆用户反馈：
- "这个问题 AI 回答错了，它说的那个数字在文档里根本不存在"
- "问同一个问题，每次回答不一样，不知道该信哪个"
- "有些简单的问题回答特别准，但稍微复杂一点就完全跑偏了"
这些反馈说明了一个问题：我们根本不知道这个系统的真实质量在哪个水位上。50 个手工测试题，完全无法代表真实的使用场景。
我花了两周时间，建了一套评估体系，之后的每次迭代都要跑这套评估：
# 评估数据集结构
{
"test_cases": [
{
"id": "tc_001",
"category": "factual_recall", # 事实性召回
"difficulty": "easy",
"question": "公司的年假政策是多少天？",
"reference_answer": "根据员工手册第3章，试用期员工无年假，转正后第一年5天...",
"source_doc": "hr_policy_2024.pdf",
"expected_sources": ["hr_policy_2024.pdf"],
"evaluation_criteria": {
"factual_accuracy": True, # 数字和事实必须正确
"source_cited": True, # 必须引用来源
"completeness": 0.8 # 至少覆盖 80% 的关键信息
}
},
{
"id": "tc_002",
"category": "multi_doc_reasoning", # 跨文档推理
"difficulty": "hard",
# ...
}
]
}有了评估数据集之后，我才第一次对我们系统的真实状况有了数字上的认知：
评估结果（v1.0）：
- 事实性准确率：71%（当时觉得还好，后来意识到这非常低）
- 来源引用率：48%
- 幻觉率（AI 编造了文档中不存在的信息）：23%
- 复杂问题覆盖率：55%23% 的幻觉率——每 4 个问题里有 1 个 AI 在编故事。我当时看到这个数字，头皮发麻。我们居然就这样上线了。
建了评估体系之后，我们有了衡量进步的基准。之后每次改动——换 Embedding 模型、调整分块策略、优化 Prompt——都先跑评估，看数字是变好还是变差。
半年之后，幻觉率降到了 4%，事实性准确率到了 89%。
后悔在哪里？
我在上线后两周才开始建这个体系。如果我在上线前三个月就开始做，这两周里我本可以发现那个 23% 的幻觉问题，做一次针对性的优化，再上线。我们可能少收到几百条负面反馈，用户对产品的第一印象会好得多。
更深的后悔是：在 2023 年整整一年里，我对 AI 系统的评估就是"人工看一看感觉还行"。我没有把"建立评估体系"当成和"写代码"同等重要的工程任务。
这是认知上的偏差：很多工程师，包括我，习惯于"软件有没有 bug"这种二值判断，而不习惯"AI 系统的表现在哪个区间"这种分布判断。
后悔程度：★★★★☆
建评估体系不难，难的是意识到它的必要性。
第三件事：太长时间坚持用老框架
这件事稍微有点不同，我没有"后悔没早点用新框架"，我后悔的是在明明已经发现某个框架不适合当前场景的情况下，仍然坚持用了太久。
具体说：我们在 2023 年初开始用 LangChain（Python 版）构建 RAG 系统。当时 Spring AI 还没成熟，Java 生态的 AI 框架比较稀缺，LangChain 是最主流的选择。
大约半年之后，我就感觉到 LangChain 不对劲了：
问题一：抽象层太厚 LangChain 把很多东西封装成了 Chain、Agent、Tool 等抽象。理解一个行为为什么发生，要在三四层抽象里反复跳转，排查问题极其费劲。
问题二：升级频繁且破坏性强 LangChain 的版本迭代速度极快，而且经常是 breaking change。每隔一两个月就有 API 变更，升级一次要改不少代码。
问题三：调试体验差 流式输出、异步处理、中间步骤的 debug——LangChain 在这些方面的体验一直不好。
我大概在 2023 年 Q3 就有这些感受了。但我没有及时换方向，理由是"换框架成本高"、"现在项目比较忙"、"等 LangChain4j 或 Spring AI 更成熟"。
这样拖了将近一年，到 2024 年中才真正切到了更适合我们场景的方案（Spring AI + 自研的 RAG 核心逻辑）。
切换之后，我们的代码量减少了约 30%（因为不再需要适配 LangChain 的抽象层），排查问题的效率提升了一倍，新功能的开发速度也明显加快。
我后悔的不是选了 LangChain——在 2023 年初，LangChain 是合理的选择。
我后悔的是：已经发现它不适合了，还硬撑了一年。
这里面有一种心理机制在起作用，我叫它"已沉没成本的陷阱"——因为已经在这个框架上投入了很多时间，所以舍不得放弃，即使继续用的代价越来越大。
对框架要有这种态度：它是工具，不是信仰。发现不合适，就换。早换比晚换成本低。
后悔程度：★★★☆☆
三件事里程度最轻，因为后来我确实换了，损失是有限的。但如果当时能果断一点，能省下一年的时间成本。
补充一件没有后悔、但值得说的事：主动做技术选型评审
前面三件都是后悔的事，这里说一件我庆幸做了的事，顺便聊聊它和前面三件的关系。
2023 年年底，公司要上一个新的 AI 项目——自动化的财报分析系统。PM 最初的方案是"直接调 GPT-4，把财报 PDF 全部传进去"。
我当时拒绝了这个方案，主导做了一次完整的技术选型评审：
方案 A（PM 的方案）：直接把整个财报 PDF 传给 GPT-4，利用长上下文窗口（当时 GPT-4 Turbo 支持 128K token）。 方案 B（我的方案）：RAG 架构，向量化财报内容，按需检索相关片段再回答。
从纯技术角度，方案 A 实现简单，三天就能上线。方案 B 复杂得多，预计两周。
但我做了一个测试：用同一份 150 页的财报，分别跑方案 A 和方案 B，各问 30 个问题，比较准确率和成本。
结果：
- 方案 A：准确率 74%，每次问答费用约 $0.18（因为每次都要传全量 PDF）
- 方案 B：准确率 81%，每次问答费用约 $0.004（只传相关片段）
成本差了 45 倍。我们预计这个系统每天要处理 500 次问答，方案 A 的日成本是 $90，方案 B 是 $2。
方案 B 多花了两周开发时间，但节省的 API 成本，两个月就把这两周的开发成本赚回来了。
这件事为什么值得说？
因为它和前面三件后悔的事有一个共同的底层逻辑：在做决定之前，先花时间把问题想清楚、数据收集够，哪怕花一两周时间，长期来看都是合算的。
我后悔太晚写技术文章，本质是没有意识到"沉淀知识"的长期价值。 我后悔太晚建评估体系，本质是急着上线、没有认真衡量质量风险的成本。 我后悔太晚换框架，本质是不想承认"当时的选择已经不对了"。
这三个后悔，都是"短期省事、长期吃亏"的决策模式的产物。
而那次技术选型评审，是"短期多花时间、长期省下来"的反面例子。
关于"转型"这件事，我最近想到的
我的公众号叫"老张聊 AI 转型"，这里面有个词是"转型"。
很多人问我：AI 转型是什么意思？是指从传统程序员转成 AI 工程师吗？
我觉得"转型"这个词说的不只是技术栈的切换，更是思维方式的变化。
写了 1550 篇，我想把这个变化描述出来：
从确定性思维到概率性思维
传统软件工程里，一个功能要么对、要么错。单元测试通过，功能就是对的。
AI 系统里，没有"对或错"，只有"准确率多少、在哪些场景下失效"。一个 RAG 系统，在 90% 的问题上回答准确，在 10% 上回答错误，不能说"这个功能有 bug"，只能说"这个系统在某些场景下不够好"。
这个思维转变，不是换几个工具能完成的。它需要你真的在 AI 系统里吃过亏，被幻觉问题搞过，被评估指标打过脸。
从单点优化到系统权衡
传统开发：这个接口慢，优化这个接口。 AI 开发：RAG 召回质量提升了，但引入了 50ms 的向量检索延迟，Token 消耗增加了 30%——这个 trade-off 值不值？
没有简单的"对或错"，只有"在当前约束下，哪个取舍更合理"。
从"完成功能"到"量化效果"
传统开发：功能上线，没有新 bug，完成。 AI 开发：功能上线，但用户满意度提升了多少？任务完成率从多少到多少？这些问题如果回答不上来，功能"上线"的意义就存疑。
这三个思维转变，是我认为真正意义上的 AI 转型。技术栈可以在一年内切换，思维方式需要在真实项目里摔几跤才能真正改变。
如果你现在刚开始做 AI 工程，我会建议你什么
这部分不是"干货清单"，我不喜欢那种格式。我就说几句我觉得对我有用、但可能被大多数人忽视的事。
第一句：先找一个真实问题，再学技术。
很多人的路径是：先系统学 LangChain → 再学 RAG 理论 → 再学向量数据库 → 然后找个能用的场景试试。
这个路径学了很多，但真正动手做的时候还是会懵——因为没有问题驱动，学的知识没有挂钩的地方，很快就忘了。
我建议的路径是反的：先找一个你身边的真实问题（可以是公司的 FAQ 太难查、可以是文档太多记不住、可以是代码 review 太慢），然后带着这个问题去学。每学一个技术点，马上问"这个能帮我解决我的问题吗？怎么用？"
有了具体问题，技术学得更快，也记得更牢。
第二句：把踩过的坑写下来，不管写不写给别人看。
我写技术文章，最开始只是为了自己不要忘记。我会写"这个方案在某某场景下失败了，原因是 xxx，最终用了 yyy 解决"。
这类笔记，几个月之后回头看，价值极高。你会发现你踩过的坑，你的判断思路，形成了一种"肌肉记忆"——下次遇到类似问题，你会本能地想到"上次这里有个坑"。
没有写下来的经验，流失得非常快。特别是 AI 这个领域，变化太快，半年前的项目决策的来龙去脉，不写下来就完全记不住了。
第三句：找几个也在做 AI 工程的同行定期交流。
这件事的价值被严重低估。
我有一个五人的小群，都是做 AI 工程的，大约每周聊一次。每次聊的内容很随机：这周遇到了什么问题、试了什么方案、哪个工具最近有什么新功能值得关注。
这种交流的价值在于：你一个人研究，你的视野是有上限的。五个人交流，你能以极低的成本知道别人在用什么方案、踩了什么坑、哪些路走不通。
信息效率高出好几倍。
第四句：不要追着每个新模型跑，要追着自己的问题跑。
GPT-4、Claude 3.5、Gemini 1.5、Llama 3——模型出得比你换手机还快。
不是每个新模型都值得你立刻跟进。你应该问的问题是：这个新模型，在我的业务场景里，能不能解决我现有的某个痛点？
比如，如果你的 RAG 系统最大的问题是幻觉率太高，那你应该关注"哪个模型在指令遵循和事实性方面提升了"，而不是"哪个模型代码能力最强"。
目标驱动地关注技术进展，比泛泛地追热点要高效得多。
一些额外的话
写这篇文章，我想了很多。
这两年做 AI 工程，我见过很多人焦虑。焦虑 AI 会不会取代自己的工作，焦虑自己的技术路线选没选对，焦虑有没有跟上最新的技术进展。
我觉得大部分焦虑是没有必要的，或者说，焦虑指向了错误的方向。
真正值得焦虑的，不是"有没有用过最新的框架"，而是"有没有在真实项目里解决过真实的工程问题"。
框架会变，模型会换，但遇到真实问题时能从底层想清楚、能做出有依据的取舍判断——这个能力不会过期。
我写的那些文章——向量库并发控制、Embedding 模型迁移、多租户隔离——每一篇背后都有一个真实的事故或者一个真实的决策困境。我不是在讲理论，我是在讲"遇到这个问题的时候，我当时是怎么想的，最后怎么解的，踩了什么坑"。
这就是我能提供的东西：一个真实在用 AI 做工程的人的一手经验。
还有一件事我想说：
这 1550 篇文章，不是每篇都写得好。有些篇我回头看，觉得说的太浅，有些觉得代码示例不够完整，有些觉得开头不够吸引人。
但每一篇，我都是认真写的。
没有一篇是为了凑数。
这一点，我问心无愧。
接下来还会继续写。
有什么特别想了解的 AI 工程话题，欢迎在评论区留言。我记下来，下一批系列文章优先考虑。