一篇写给工程师的落地笔记。
背景
下面把这件事拆开讲清楚。
一、先分清两类岗位：造模型和用模型
很多人一听到「AI 工程师」，脑子里浮现的是算法研究员：数学功底、顶会论文、训练大模型。那是造模型的路子，门槛确实高，对转行的人不友好。
但企业里真正缺的是另一类人：用模型的人。客户有一个业务问题——比如客服回复慢、合同审核靠人工、内部资料没人查得到——你要做的是把现成的大模型接进来，配上知识库、工具调用和工作流，让它在这个具体场景里跑起来。这类岗位的叫法很多：AI 应用工程师、AI 落地工程师、大模型应用开发，本质都是同一件事：模型是买来的，价值靠你来落地。
造模型需要几年数学和研究的积累；用模型需要的是工程判断力——知道什么时候该检索、什么时候该微调、什么时候一个清晰的提示词就能解决。前者转行难，后者转行完全可行。
二、需要会写代码的部分，到底有多少
以我自己的经验，日常真正要动手写的代码集中在几块：
1. 调 API。 把大模型服务接到你的程序里，本质就是发请求、收结果、处理异常。这类代码结构固定，写熟了就是复制粘贴改参数的水平。
2. 写提示词和流程编排。 这是 AI 应用里真正的「业务逻辑」：把一个复杂任务拆成几步，每步给模型什么上下文、要求什么输出格式、中间结果怎么校验。这部分更像写文档和写规则，而不是传统意义的编程。
3. 数据处理。 知识库要把企业文档切分、清洗、入库，这些脚本通常百来行 Python 就够。难点不在语法，在于你对文档结构的理解。
4. 排查问题。 模型答非所问、检索不准、输出格式崩了——定位这些问题需要看日志、做对比实验。这个能力比「会写代码」重要得多。
粗略说：Python 基础语法 + 会读别人的项目代码 + 会用几个常见框架，就够开工了。零基础的人认真学两三个月，能覆盖大部分日常场景。真正的分水岭不是代码量，而是你能不能把一个模糊的业务需求翻译成可执行的技术方案——这是思维层面的东西，也是转行的人拉开差距的地方。
三、一个真实的例子
之前接过一个中小企业的活：他们的售后团队每天要翻几百页的产品手册回答客户问题，新人上手要背一个月资料。
做这件事用到的「代码」是什么量级？文档切分入库几十行脚本，检索接口几十行，提示词模板写了两版。真正的功夫花在别处：把手册按故障类型重新组织结构、给常见问题设计兜底话术、拿真实客服对话反复测试。最后这套东西跑起来，新人问一个故障现象，几秒钟就能拿到对应章节和标准处理流程。
这个项目里，写代码可能只占两成时间。剩下八成是理解业务、设计方案、测试迭代。这也是为什么我说「会不会写代码」不是这个岗位的核心门槛。
四、给想转行的人一个务实的路径
如果你现在的状态是「想做但不知道从哪开始」，我的建议按顺序是：
第一步，先把一个完整的小项目跑通。 不用先系统学完 Python 再动手——那样学到一半就放弃了。直接找一个你熟悉的场景（比如把自己整理的资料做成问答机器人），边做边补知识，卡在哪补哪。
第二步，补最小必需的代码底子。 做完第一步你会发现缺什么：可能是文件读写，可能是请求库的用法。带着问题去学，效率比按教材刷高很多。
第三步，找真实的业务问题练手。 给自己虚构需求，永远练不出工程判断力。可以帮身边的小店、朋友的团队做一个真正会被用起来的小工具，踩过一次「需求变更」和「模型不按预期输出」的坑，比看十篇教程有用。
第四步，把它变成可展示的东西。 转行找工作时，一个能演示的项目、一段讲清楚「为什么这么设计」的话术，比任何证书都有说服力。
五、写在最后
转行这件事，卡住大多数人的从来不是「不会写代码」，而是不知道这个岗位每天到底在干什么、需要什么。把预期校准了，路径其实不复杂：模型能力已经摆在那里，企业缺的是把它接进业务里的人——这个位置，留给愿意动手、愿意理解业务的人。
我自己就是从传统行业转过来的，踩过的坑整理成了一套完整的实战路径。如果你也在考虑这条路，欢迎关注公众号「无夜之境」，里面有更多 AI 落地的一线记录，帮你少走弯路。
有什么更好的做法，欢迎评论区讨论。
