有个变化挺明显：身边写业务代码的同事，开始陆续碰大模型项目了。不是转算法，也不是去训模型，而是把原有系统“接一层 AI 能力”。
这事儿没想象中玄乎，但也绝不是“调个 chat 接口”就结束。
从“写逻辑”到“管边界”
以前做功能：
产品说“按钮点了弹列表”→ 你写查询、拼参数、返前端。
现在做 AI 功能：
产品说“让用户问一句就能查订单”→ 你得想——
问题里有没有订单号？
没有订单号能不能查？
模型瞎编了订单内容怎么办？
查库失败怎么回？
回答格式前端怎么解析？
同样一个“查订单”，传统开发写 SQL 分支；大模型开发写 Prompt + 工具 + 校验。
DeepSeek 一位系统工程师之前写过类似感受：未来不是程序员没了，而是从“写算子”变成“指挥 Agent 的驾驶员”。
这话偏文艺，但方向是对的。
大模型应用岗到底写什么代码
拿公开 JD 举例：
接模型 API
写 Prompt 模板和输出解析
做 Tool Use（查接口、查库、发消息）
做 Memory（多轮上下文）
用 LangChain / LangGraph 编排流程
包成 FastAPI 服务
你看，还是后端活儿，只是“业务逻辑”有一部分交给模型跑，你负责兜底。
RAG 是企业项目里最常用的一块
纯靠模型记忆答企业问题，容易胡说。
实际做法一般是：
文档切块
向量化存 Milvus / Chroma
用户提问先检索
把相关片段塞进 Prompt
模型基于片段答，并标来源
像医院、工厂、金融机构的知识问答，基本都走这套。
小提醒：RAG 不是“接了向量库就准”，分块策略、检索召回、rerank、超时控制，全都要调。
Agent 也不是“自动万能”
现在很多文章把 Agent 说成全能员工，实际工程里更像是：
规划一步
调一个工具
看返回
再决定下一步
单个 Agent 容易上下文爆掉，复杂任务会拆成多个角色：路由、检索、执行、校验。
所以写 Agent 项目，重点不是“让它自由发挥”，而是把人类流程先理清。
转岗建议
如果你现在是后端 / 全栈：
Python 不熟先补 Python
用 FastAPI 包一个模型接口
接一次向量库（Chroma 最省事）
写个 Function Calling 工具：查时间、查库存、查订单
用 LangGraph 做个“先检索再回答”的小智能体
最后补日志、评测集、异常兜底
不用急着学 PyTorch 训练，应用层岗位先能把“模型+工具+业务”串起来更有用。
大模型应用开发不是“程序员升级成 AI 大神”，而是把原来写死的逻辑，改成「模型建议 + 工具执行 + 规则兜底」。
会写代码的人反而是优势方，前提是别只停留在“接个对话框”。
大模型应用/开发工程师 辉达 丁老师13522094648/马老师13391509126
