后端转型大模型应用开发如何走

#ai大模型# #大模型应用开发# 

一天一个AI岗位介绍，今天要解读的JD岗位是——AI应用研发（直播类）。在所有 AI 应用场景里，直播可能是最“极端”的一个：高并发、强实时、强互动、强转化。如果一个 AI Agent 能在直播场景稳定跑起来，那基本说明——工程能力是过关的。一句话概括它的核心工作：在高并发直播场景里，把 AI Agent 从“概念”变成可规模化运行的系统。不是做 Demo，不是写论文，而是——让 Agent 真正在流量洪峰里活下来。一、这个岗位到底在做什么？它可以拆成两条主线：基建 + 应用落地。1️⃣ AI Agent 框架基建（偏工程核心）JD里提到 MCP 标准、微服务集成、低延迟、安全集成。翻译一下就...

工程类偏多🏀1. dpo 和 sft 的区别，先 dpo 后 sft 可以么2. 如果把 DPO 用在“第一轮对话”，你会怎么做数据集？prompt、chosen/rejected 你打算怎么来3. 多轮对话的数据分布你会怎么设计：单轮和多轮各占多少，为什么这么配4. 具体到 DPO 数据，多轮样本你会怎么采样/怎么配比（有没有什么坑）5. reward hacking 你怎么看？一般怎么防，怎么兜底⭕如果你现在：- 春招/秋招没方向- 简历没人看- 面试总挂- 不知道怎么准备，想求职算法岗的同学，需要进行高质量项目辅导，提升面试能力，☎欢迎后台联系。

前些天看了 Clawdbot 创始人的采访——这哥们单日提交 1.3k commits，一个月 6600+ 次提交，有的代码自己一句都没看过，非常恐怖。所以在不久的将来，当 AI 已经完全具备写代码的能力，人类程序员的操作空间还能剩多少？最近在实习，做大模型微调，新鲜期过了，发现不过是机械劳动，造数据 → 训模型 → 看 badcase → 然后再造数据，循环往复...这不就是Agent的ReAct范式么? (坏了，我成智能体了) 需求明确的情况下，Claude-3.5/3.6 也完全可以独立完成造数据 pipeline 的开发，偶尔会留下一些语法错误，在两三轮尝试之内也能自己修正过来......这里非要人来完成的环节并不多，只能用人来完成的理由，好像只剩人比较便宜了...？ 但 AI infra、推理加速也在飞速发展，这种相对的便宜，又能持续多久呢？Clawdbot已经火到到处都在讨论，尽管目前在国内的适配有限，(门槛高是一方面，还很重要的一点是比较烧钱...)不过它对人类劳动力的节省是没办法忽视的。目前同事们普遍认为这玩意儿现在只能接入飞书写写文档，但你也知道，“目前”而已。GPT-4 推出的那年或许看上去还有点呆，但短短几年，拥有 skills 和 function call 的大模型已经可以帮你完成打开应用、查看消息、撰写文档这种复合任务——写代码又能比写飞书文档复杂多少呢？不过是接入不同的软件，阅读不同的文本，调用不同的修改命令，底层是一样的，现在 Copilot 已经做得有模有样，更别说 Clawdbot 这种具有自我进化能力的 Agent，只要 token 多，Clawdbot 完全可以给自己装一堆功能，能量超乎你想象。有人说了，我做的项目大着呢，全是屎山代码，我不信 AI 能看完，这说的其实是长上下文问题，我个人不认为是一个无法解决的问题，随着上下文窗口的扩展和长期记忆管理的研究工作不断发展，AI 总能找到方法把你的超长文本压缩成一个一个的小块，然后逐个击破（虽然目前 GPT-5.2 Codex 改我的代码还是会改着改着一片红...）有句话说得好，你怕被 AI 替代，是因为你太像 AI。你的工作流程高度标准化、可预测、可复现——接需求、看文档、查 API、写代码、测试、提交。每一步都有明确的输入输出，每一步都能被拆解成清晰的指令。这种工作方式，恰好是 AI 最擅长的。如果你的价值体现在“把业务逻辑翻译成代码”，那 AI 确实可以做得更快、更稳定、更便宜。它不会写错大小写，不会忘记边界条件，不会因为昨晚没睡好就漏掉一个判断。要想不被替代，就得做那些 AI 做不了的事，比如和产品经理撕逼，解释为什么这个需求做不了；看着三个技术方案，权衡性能、成本、开发周期，最后拍板选一个；跨部门开会，听运营讲了半天业务痛点，翻译成技术语言，还得判断她说的是真需求还是伪需求。这些事情需要判断、需要博弈、需要对人的理解， AI 暂时还做不来。但问题是，这些事情需要多少人来干？以前一个项目可能需要十个程序员，现在有了 AI，也许三个人就够了,剩下那七个人上哪去？......也许他们会转型，在行业找到新位置，也许是去卖炒粉了，说不好。但有一点感觉很明显：AI 在拉高门槛。以前你会写代码就能找到工作，现在得会“用 AI 写代码 + 理解业务 + 做技术决策”。这个组合技能，不是每个人都能凑齐的。工具会进化，但人怎么不被工具定义，可能是我们未来一段时间需要长期思考的问题。