一篇写给工程师的落地笔记。
背景
这句话拆开就是三件事：接得上（技术）、跑得通（业务）、交得掉（交付）。下面把该会的东西按这三件事列清楚，你可以直接拿它当学习清单对自己。
一、先破两个误解
误解一：以为要先学会训模型。 绝大多数落地岗位不训模型，只用现成的。2026 年的模型能力已经高度商品化，企业缺的不是"更聪明的模型"，而是"能把模型接到自己系统里的人"。
误解二：以为会写 prompt 就够了。 会写 prompt 只是入门。真正卡人的是数据怎么拿、权限怎么控、结果怎么验、出错怎么退。这些才是企业愿意付钱的部分。
二、能力清单：三层结构
| 层级 | 能力 | 具体到什么程度算合格 |
|---|---|---|
| 底盘 | Python 与接口调用 | 能读文档调通 API，会处理超时、重试、限流；会写几十行的数据处理脚本 |
| 底盘 | 数据结构与 JSON | 能在嵌套 JSON 里取字段、做映射；理解结构化输出为什么比自由文本可靠 |
| 底盘 | Linux 与部署基础 | 会用命令行、看日志、配环境变量；能把脚本放到服务器上定时跑 |
| 核心 | 提示工程与结构化输出 | 能写出稳定返回 JSON 的提示，会做 few-shot、会设兜底分支 |
| 核心 | 检索增强（RAG） | 懂切分、向量化、召回、重排这条链路；知道什么时候用检索、什么时候该直接塞进上下文 |
| 核心 | 工作流编排 | 会把一个大任务拆成多步（分类 → 取数 → 生成 → 校验），而不是指望一次问答解决 |
| 核心 | 数据清洗与对齐 | 能把客户散在 Excel、ERP、聊天记录里的数据整理成模型能吃的格式 |
| 交付 | 需求翻译 | 能把老板说的"我要提效"翻译成一条可验收的流程和指标 |
| 交付 | 评测与验收 | 能搭一套小样本评测集，用数字说明改前改后差在哪 |
| 交付 | 沟通与文档 | 能写清楚交付说明、使用手册、边界与不适用场景 |
如果你只会表里第一列的"底盘"，那叫会写代码；把"核心"那一列打通，才叫能落地。
三、按阶段学，别一上来就啃难的
第 0–3 个月：把 API 调顺。 目标只有一个：能自己写一个脚本，读取一批业务数据，调用模型，输出一份可直接使用的表格或报告。这个阶段不要碰框架，就用最朴素的写法，把错误处理和数据清洗练熟。
第 3–6 个月：打通一条完整链路。 挑一个自己熟悉的场景（比如简历筛选、工单分类、合同要点提取），把它做成一个小产品：有输入界面、有中间处理、有结果存储、有失败兜底。做完整一次，比看十篇教程有用。
第 6–12 个月：做带检索和评测的系统。 加入知识库检索，搭一个二十到五十条的评测集，每次改动都跑一遍看指标变化。到这个阶段，你已经具备按项目收费的能力——因为你交付的不是"一个能演示的 demo"，而是"一套能被验收的系统"。
四、一个真实场景：给设备制造企业做售后知识问答
客户的诉求听起来很简单：售后工程师老是打电话问总部，想做个能查手册的机器人。
表面上是"接个大模型"，实际要做的是：
- 先盘数据——手册有 PDF、Word，还有一批只在老员工电脑里的经验笔记。这些不整理，模型答不准。
- 拆流程——把"回答问题"拆成"判断问题类型 → 检索对应章节 → 生成答案 → 附上出处"。加出处这一步，是让工程师肯用它的关键。
- 设边界——涉及电气安全的操作类问题，一律不给结论，只给手册原文和链接，让人来判断。
- 做验收——跟客户一起挑五十个真实问题，答对率从上线前的人工基线提上去多少，写进验收报告。
这套活里，模型只是中间一环。真正占时间的是数据、流程、边界和验收。这就是落地工程师吃香的原因：这些事算法岗不管，软件售后也不管。
五、怎么判断自己"能接活了"
给自己五道题，全过才算入门：
- 给你一份客户的混乱数据，你能在一天内说清楚它能不能用、还缺什么吗？
- 你能把"效果要好"翻译成三个可测的数字指标吗？
- 系统出错的概率是百分之几，你能说清并给出兜底方案吗？
- 交付完，客户的人能自己改提示词、加新文档吗？
- 你能书面写清这套方案的适用边界和不适用场景吗？
第 4 条尤其重要。项目交完，客户自己还能维护，这是衡量一次交付成不成功的一条硬标准，也是复购和转介绍的来源。
六、一句话总结
AI 落地工程师的核心竞争力不是"懂模型"，而是"懂怎么让模型在别人的业务流程里不出事地干活"。技术门槛不高，但综合要求很实；这也意味着它不是靠背知识点能速成的岗位，而是靠一个又一个真实项目喂出来的。
如果你正在考虑从别的岗位转过来，建议的顺序是：先用现有工作的场景练手，做出一个能拿给别人看的完整案例，再谈接活。手里有案例的人，和只会说"我在学 AI"的人，在客户眼里是两种人。
有什么更好的做法，欢迎评论区讨论。
