第2364篇：从业务开发到AI工程的跨越——不只是换一套技术栈
第2364篇：从业务开发到AI工程的跨越——不只是换一套技术栈
适读人群：正在从传统业务开发转型AI工程的工程师 | 阅读时长：约14分钟 | 核心价值：转型AI工程不只是学新技术，更是思维方式的升级
我有一个真实经历，是我自己在转型初期犯的错，今天拿出来说。
2022年我开始尝试做AI工程，第一个项目是一个文档问答功能。我当时的思路完全是业务开发的路子：拿到需求，设计数据结构，写API，写前端，测试，上线。
上线之后，功能确实能用，但效果不稳定——有时候回答很准确，有时候答非所问，有时候瞎编。业务方来反馈问题，我看了一下，加了几条if-else处理特殊情况，上线，问题稍微好了一点。又来反馈，我又加几条逻辑……
我陷入了一个循环，每次修复一个问题，另一个问题出现了。我不知道效果改善了还是变差了，因为我没有系统的评估，完全是凭感觉。
大概三个月后，我意识到问题：我在用业务开发的方法做AI项目，但AI项目需要的是完全不同的工作方式。
业务开发思维 vs AI工程思维的本质差异
差异一：确定性 vs 概率性
业务开发的世界是确定性的：一个函数，给定输入，一定产生确定的输出。你可以通过单元测试来保证。
AI的世界是概率性的：同样的输入，LLM可能产生不同的输出；模型对某些输入的处理质量可能比其他的差；在你的评估集上好，不代表在所有情况下都好。
这意味着你不能用"写测试保证正确性"的思维来做AI工程，而要用"建立评估体系、持续监控、数据驱动改进"的思维。
差异二：功能完成 vs 效果达成
业务开发的成功标准是：功能实现了，测试通过了，上线了，没有报错。这是一个明确的二元判断。
AI工程的成功标准是：业务目标达成了吗？用户满意度如何？效果指标在什么水平？这些都是连续的度量，没有明确的及格线（或者说及格线需要你自己和业务方一起定义）。
差异三：代码改动 vs 系统改进
业务开发中，你遇到问题，改代码，问题解决。
AI工程中，遇到效果问题，可能需要改的不是代码，而是：prompt、文档分块策略、embedding模型、检索参数、后处理逻辑……改了一个地方，可能其他地方的效果变了，而且这种变化不是显而易见的，需要在评估集上系统地测试才能发现。
转型AI工程需要建立的新能力
新能力一：量化思维
业务开发工程师在评估系统质量时，主要靠：代码跑没跑通，测试通过了没，线上有没有报错。
AI工程师需要额外建立：用数字描述系统质量的习惯。
"感觉效果还不错"是没有意义的。"在200个测试用例上，准确率83%，比上一版本提升了7个百分点"才是有意义的。
这需要你养成以下习惯：
- 用评估集测试之前和之后的效果
- 记录每次改动对指标的影响（哪怕是小改动）
- 在做任何"效果优化"之前，先确定你在优化的指标是什么
新能力二：实验设计能力
改一个参数，效果是不是变好了？很多工程师的方法是：改了，感觉好一点，就上了。这不是实验，是直觉。
正确的实验设计：
- 明确假设：我认为[改动A]会[影响B]，因为[理由C]
- 设计验证方案：在[评估集]上，对比改动前后的[指标]
- 控制变量：一次只改一个东西
- 分析结果：结果是否支持假设？是否有意外的副作用？
这种实验设计思维，在业务开发里几乎不需要，但在AI工程里是核心能力。
新能力三：失败分析能力
在业务开发里，一个bug要么修好了，要么没修好，相对容易判断。
AI系统的"问题"往往是"在某些情况下效果不好"，而要改进效果，首先要理解失败发生在哪里、为什么发生。
RAG系统的失败分析框架
输入：用户问了一个问题，AI回答错了
↓
失败类型一：检索失败
├── 症状：相关文档根本没有被检索到
├── 可能原因：
│ ├── 分块策略不合理，答案被切断了
│ ├── embedding模型对这类语义的理解不准
│ └── 检索参数设置不合理（top-k太小，阈值太高）
└── 排查方法：看检索结果，检查有没有相关文档
失败类型二：检索正确但利用失败
├── 症状：检索到了相关文档，但LLM没有正确利用
├── 可能原因：
│ ├── 上下文太长，相关信息被淹没
│ ├── 文档内容和问题的表述方式差异太大
│ └── prompt没有正确引导模型关注相关部分
└── 排查方法：把检索结果直接给模型，看能不能回答正确
失败类型三：生成失败
├── 症状：文档里有答案，模型理解了，但回答有问题
├── 可能原因：模型幻觉、指令遵循不够好
└── 排查方法：换更强的模型对比这种结构化的失败分析，比"模型效果不好，我来改一改prompt"更有效。
转型路上的常见坑
坑一：把框架当能力
"我会用LangChain"不等于你有AI工程能力。框架是工具，能力是用工具解决问题的判断力。
有些转型中的工程师，花大量时间学习各种AI框架，但如果你问他"你怎么评估一个RAG系统的检索质量"，他答不上来。
技术能力的核心不在于会多少工具，而在于能独立分析和解决问题。
坑二：跳过评估直接优化
遇到效果问题，上来就改prompt，改完感觉好一点，就认为问题解决了。
但"感觉好一点"可能是因为你测试的几个case刚好改好了，而其他case可能变差了。
没有系统的评估，你不知道自己是在进步还是在原地打转。
坑三：忽视工程质量
很多从机器学习背景转过来的工程师，或者AI研究方向的同学，代码质量不高——没有测试，没有错误处理，服务稳定性差，在实验室里能跑就行。
AI工程是工程，不是实验。生产环境里需要稳定运行的系统，需要完善的错误处理、监控、降级策略。代码质量不能因为是"AI系统"就降低标准。
坑四：过度关注模型，忽视数据
很多工程师遇到效果问题，第一反应是换一个更强的模型。但很多时候，问题不在模型，而在数据——文档质量差、分块策略不合理、评估集不代表真实场景。
更强的模型处理更烂的数据，结果依然烂。先把数据问题解决，往往比换模型更有效。
转型AI工程的建议路径
graph LR
A["建立量化评估习惯\n（第1-2个月）"] --> B["系统学习核心技术\n（第2-4个月）"]
B --> C["完成一个有评估\n体系的完整项目\n（第4-6个月）"]
C --> D["深化某个技术方向\n积累差异化能力\n（6个月后）"]第一步建立量化评估习惯，是因为这是后续所有工作的基础。没有这个习惯，你做任何技术工作都是在"感觉"驱动，而不是数据驱动。
第三步特别强调"有评估体系的完整项目"——很多工程师做过很多AI"功能"，但没有做过一个从头到尾都严格对待效果评估的项目。这种经历是转型真正完成的标志。
转型AI工程不是一个技术升级，而是一个思维模式的切换。技术是可以学的，思维模式的切换才是真正的挑战，也是真正的价值所在。