技术岗怎么补 AI：四项底层能力

技术岗补 AI，最容易掉进的循环是追框架：学完一个又出一个，永远追不完。框架每个月都在换，可迁移的能力只有几项：工程、评测、成本、架构。把这四项补扎实，换什么框架都是半个月的事；只追工具，两年后简历上还是只有框架名。

工程能力是能不能上线的分水岭

把模型接进系统，会遇到一堆和写业务代码不同的工程问题：并发下的调用排队、失败后的重试策略、超时怎么降级、流式输出怎么对接前端。这些问题的答案不随框架变化——重试要带指数退避、失败要有兜底路径、日志要能回放请求，这些思路在哪个技术栈里都成立。一个实用的练法是给自己立规矩：任何一次调用都要有超时上限和失败兜底，没有这两样的代码不进仓库。判断一个人能不能把大模型应用做到上线，看的往往就是这段工程功力，模型能力反而是现成的。

评测能力让调优告别凭感觉

没有评测集，每次改提示都是在赌。补评测能力包括三件事：设计一份几十条的评测集，覆盖正常输入和边界输入；对失败案例分类，找出是理解错了、检索错了还是格式错了；改完一处后跑一遍旧用例，确认没有改坏别处。这套做法和写单元测试的思路相通，技术岗学起来有先天优势，缺的只是把它搬到大模型输出这件事上。评测集不用追求精致，三十条能稳定复现问题的，比三百条随手拼的更有用。

评测还能用来对冲外部信息的干扰。各家榜单的排名每个月都在变，看懂榜单迭代背后的信号就够了，自己的场景好不好用，用自己那几十条评测集说话，比排名可靠。

成本意识的账和写代码不一样

AI 应用的成本结构和技术栈熟悉的完全不同：单次调用的费用看着便宜，乘上调用量、重试次数、上下文长度之后，总账经常超预期。补成本意识包括：知道什么时候该用缓存、什么时候该换更小的模型、重试上限设多少合适。会用更省的方案本身就是竞争力——同样的功能，你的方案成本只有别人的零头，这在立项时比多写两行优雅代码值钱。把上个月的调用账单拉出来看一次分布，比看任何教程都直观。

平时留意价格战报道里的补贴与成本逻辑，能帮你看懂厂商定价的底层思路，判断当前的价格环境能撑多久，再决定要不要把架构绑死在某一个价位上。

架构与信息输入的取舍

架构能力指系统怎么分层：模型调用、业务逻辑、数据存储各自独立，换模型不动业务代码。这项能力技术岗本来就有，只需要把「模型是一层可替换的实现」这个观念装进去。信息输入则要有取舍：芯片制程、算力格局这类行业新闻值得看懂框架，但不必逐条追，看懂制程、算力与生态三条主线即可，省下的时间留给评测集和工程实践。

四项能力的学习路径对照

这张表按行推进，一行做扎实再开下一行，比四项同时开头的进度快。

技术岗补 AI 速查

• 先补工程与评测，再谈框架
• 评测集从 50 条起步，改前改后都跑
• 重试、缓存、降级三件套决定成本
• 换模型不动业务代码才算架构合格

转型路上的三问三答

转型期该接什么样的项目练手？选一个真实存在但没人愿意做的内部小工具，比如日志摘要或工单分类。真实数据里的脏输入，比教程里的干净示例练出的工程能力多得多。

没有 GPU 资源能练这些能力吗？四项能力里没有一项要求自己训练模型。调 API 做工程与评测，用免费额度就能把 50 条评测集的流程跑通，瓶颈在练习量，不在算力。

算法基础需要补到什么程度？补到能读懂技术报告的关键章节即可：输入输出是什么、训练数据大概什么规模、在哪方面有明显短板。能复述这三点，选型讨论就不会被带偏。报告读多了会发现，多数分歧都出在这三点的口径上。