中级开发者这个词，这几年越来越尴尬。招聘软件上写着三年经验，打开需求一看，不问业务不问架构，劈头就问会不会大模型。可你真去问十个自称会用大模型的开发者，九个的回答是我调过接口，还有一个说自己会写提示词。这不能全怪开发者，因为“AI 能力”本身太含糊了，它既像一门新语言，又像一个新框架，还像一类新业务。你很难说清楚，自己到底在学什么，学到什么程度才算过关。
我给中级开发者的 AI 能力升级路线图，出发点只有一个：把 AI 能力从玄学变成工程。不是让你去复现一篇论文，也不是逼你背一堆术语，而是围绕“怎么把一个 AI 能力稳定、可控、低成本地放进真实产品”这件事，把该练的肌肉练出来。这套路线我在项目里反复用过，带团队教过，自己也踩过不少坑，下面拆开讲。
1. 先搞懂“AI 能力”到底分几层
中级开发者最容易犯的错，是把“AI 能力”当成一个开关。好像雇一个会用接口的人，或者买一个智能体的 VIP 账号，产品就自动智能了。真实情况远不是这样。我习惯把 AI 能力拆成三层，每一层的目标、工具、考核方式都不一样。
1.1 第一层：会用，能完成单点任务
这一层的核心是“把大模型当成一个能对话的函数”。你能够注册云平台、申请密钥、发起请求、解析返回结果，并且通过调整提示词让输出更符合需求。能做到这一步，说明已经具备了最基本的动手能力。
但这一层远远不够。因为单点调用解决的是“模型能不能回答”，而不是“这个回答能不能进业务”。比如让模型总结一段代码、给一段文案润色、把非结构化文本抽成结构化字段，这些都是单点任务。任务跑通了，不等于功能做完了。真正的工程问题是从下一个问题开始的：输出不稳定怎么办，答案是错的怎么办，一个月要花多少钱，用户量上来延迟怎么控。
1.2 第二层：会集成，能设计完整 AI 功能
第二层要求你从“调接口”升级到“做功能”。一个 AI 功能通常包含输入端的数据处理、模型调用前的内容组装、调用后的结果校验、降级策略，以及数据回流。
举个例子，一个“合同关键信息抽取”功能，表面上就是调一次模型。实际要处理的却远不止这些：上传的 PDF 要先转文本，不同扫描件有不同清晰度，要么丢给模型要么先做 OCR 预处理；字段存在重复和歧义，比如两个“签订日期”，到底以哪个为准；模型偶尔漏字段怎么办，要不要二次追问；用户改了结果，能不能存下来形成微调数据。
“会集成”考查的正是这些边界问题。你能不能在模型之外搭好一套机制，让它在一个不是 100% 可靠的引擎之上，仍然给用户一个可用功能。
1.3 为什么这份规划叫路线图，而不是工具清单
因为能力升级不是背下来几个框架术语就能完成的。你需要一条有顺序、有反馈、有验收标准的学习路径。
工具清单解决的是“见过没有”，路线图解决的是“会用没有”。见过二十种框架，不如端到端跑通一个真实场景。所以我后面的内容不会说“去把市面上所有大模型都看一遍”，而是建议你找一个具体业务场景，从上下文工程出发，把评估、检索、验证一路做进去。这样三个月后你拿出来的不是一个 Demo，而是一套方法论。
2. 三大核心能力支点：上下文工程、评估意识、检索增强
要说中级开发者和初级调包侠的分水岭，我认为就三个词：上下文工程、评估意识、检索增强。这三个点练扎实了，大部分 AI 相关需求都能接得住。
2.1 上下文工程：输入信息取舍是第一个分水岭
我对上下文工程的定义是：你输入模型的所有东西，统称上下文。包括系统指令、用户提问、历史记录、检索回来的资料、表结构定义、输出格式要求，甚至包括你故意不给它的那些信息。
很多人以为上下文工程就是写提示词。其实写提示词只是最直觉的那部分。真正的上下文工程，是在有限的上下文窗口里做信息取舍。你要决定哪些信息必须给，哪些给了反而干扰，哪些需要压缩，哪些要放在离问题最近的位置。
我见过一个典型反例。有团队想做一个“基于历史工单的回答系统”，为了怕模型漏信息，把用户一年内的工单全部塞进 prompt，一次请求进来就带了两万字。结果有三重问题：费用接近翻倍，响应时间显著上升，回答质量反而下降，因为真正相关的内容被淹没在无关工单里。
正确做法是先做一层信息筛选。查询来了之后，先用关键词或向量召回最相关的 3 到 5 条历史工单，再拼上工单对应产品的固定说明，最后才组装成 prompt。这个顺序不能反。上下文工程的关键，不是塞得越多越好，而是让模型“该看的都看到，不该看的一律不出现”。
另一个容易忽略的点是输出约束。不要让模型自由发挥格式，最好给一段可解析的 JSON 示例，并在系统指令里写明字段含义和取值规则。格式约束越具体，后面做程序化校验就越省心。
2.2 评估意识：没有评估集，一切优化都是感觉
如果你问一个 AI 功能“效果怎么样”，对方回答“还行”“看着不错”，基本可以判断这个项目还没有工程化。工程化的事，全部要建立在可衡量的基础上。
我在带内部项目时，会要求先建评估集。什么是评估集？把过去一段时间真实出现的输入收集下来，人工标好理想输出。少则一两百条，多则上千条。有了这个东西，你才能回答一个问题：这次改动到底变好了还是变坏了。
评估集不需要很复杂。你可以按场景分层：
| 场景类型 | 数量 | 用途 |
|---|---|---|
| 正常输入 | 100 条左右 | 测主路径正确率 |
| 边界输入 | 30 条左右 | 测格式异常、字段缺失 |
| 明显不该回答的输入 | 20 条左右 | 测拒答能力和安全边界 |
有了评估集之后，每次改 prompt、换模型、调整策略，都跑同一批数据，然后算出准确率、格式合规率、拒答率、平均耗时。没有评估集的人，优化凭感觉；有评估集的人，优化靠对比。这个习惯值得花两周时间去养成，后期能省掉大量反复沟通。
实际跑评估时，也不要只看一个数字。我建议至少盯三件事：结果是否准确、格式是否合规、关键字段是否齐全。有些场景还要看引用是否正确，比如模型答了一句话，它引用的标准文件编号到底存不存在。这一步必须单独验证，不能假设大模型说真话。
2.3 检索增强：不是向量检索，而是知识闭环
很多人一听到检索增强，第一反应就是向量数据库。实际上，一次稳定的知识问答，靠的不只是向量召回，而是整条知识链路。
说白了，你要让模型基于“你们公司自己的文档、代码、流程”回答，而不是靠它训练时的记忆。这条链路至少包含四段：文档接入、切片、召回、重排。
文档接入阶段，要处理 PDF、Word、Markdown、扫描件，格式不一样，解析方式完全不同。切片阶段的粒度很关键，按固定长度硬切最容易把语义切断；更好的做法是按章节标题、代码块、表格结构感知地切。召回阶段，小于几百条的知识库用关键词搜索往往就够了，几千条以上再上向量检索。重排阶段，把召回的 Top 20 结果重新打分，挑出 Top 5 再喂给模型，这一步对最终质量提升非常明显，却经常被省略。
我建议你在第一个项目里，不要把检索做得太重。可以先从“关键词匹配 + 规则过滤”起步，跑通之后再引入向量化。原因很简单：规则方案出了问题好排查，向量方案一出问题，你根本不知道是模型的问题、数据的问题，还是相似度阈值调得不对。工程上有一个原则，先能解释，再求智能。
3. 模拟项目 X：从 0 到 1 做一个 AI 辅助代码审查工具
路线图必须落到实战。这里我以一个反复用过的“模拟项目 X”为例：AI 辅助代码审查工具。项目不大，但覆盖了前面讲的三项核心能力，非常适合作为中级开发者的训练场。
3.1 项目要解决什么问题
团队日常开发中，代码审查非常依赖老手个人经验。新人看不出潜在问题，老手又没时间逐行看。模拟项目 X 的定位是：在 Merge Request 提交时，自动跑一遍审查，输出疑似问题清单，供开发者二次确认。
你需要的输入包括：变更文件列表、代码 diff、提交说明。输出建议包含五类信息：疑似缺陷、性能隐患、安全风险、可读性问题、改进建议。每条问题后面，最好还附上严重级别和建议修改位置。
这个项目最大的好处是反馈闭环非常清楚。模型说得对不对，开发者一眼就能判断。不像有些 AI 功能，给出一个模糊结论，你要花半天时间验证。代码审查场景天然适合开发团队内部练手。
3.2 架构选型背后的取舍
我自己在实现时采用了一种比较保守的流水线结构，而不是把所有事都丢给一个 Agent 自由发挥。
流水线大概分四段。第一段是预处理模块，负责解析 diff、按文件类型过滤、提取新增函数列表和关键变更统计。第二段是知识模块，维护一份团队的历史问题规则，根据文件路径和变更内容做规则匹配。第三段是生成模块，把 diff、相关规则和必要的项目说明组装成 prompt，调用大模型输出结构化结果。第四段是校验模块，检查返回结果是否是合法 JSON，字段是否齐全，缺陷位置是否真的命中变更行，通过后再展示给用户。
我见过有人用复杂的 Agent 方案，让模型自己决定“要不要读文件”“要不要查 Git 历史”，结果现场经常出现工具调用失败、循环重试的问题。不是 Agent 不能做，而是对这个项目来说，可预测性优先。固定的流水线结构，每个环节都能单独测试，出现问题也容易定位。
3.3 落地实施五步走
第一步，准备数据。从你的仓库里导出最近一到三个月的 Merge Request，先不急着把全量数据交给模型。人工挑选大约 50 个 diff，标注出真实问题，作为第一版评估集。
第二步，跑基线。不写任何检索和规则，直接把 diff 塞给大模型，让它输出审查意见。记录准确率和格式合规率。这个阶段的目的，是搞清楚“原生模型到底能做成什么样”。
第三步，做上下文工程。把历史问题规则和团队常用的项目约定写进 prompt，再规定好输出 JSON 的字段和取值范围，重新跑评估集。你会发现，这一步完成后，格式合规率会明显上升，但准确率可能还在原地打转。
第四步，加检索增强。把历史 Review 记录和项目文档切片入库，在生成之前先召回类似的历史问题，作为参考信息注入。这一步通常能把“漏报”率压下来不少。
第五步，做校验和闭环。写一个结果校验函数，把所有模型输出再过滤一遍，不满足条件就触发一次修复式重试，重试不通过就丢进人工队列。经过这五步，你交付的就不再是一个“能用”的调用脚本，而是一个真正可控的功能。
4. 路线推进中的高频问题与排查心得
实操过程中，你会反复遇到几类问题。这些问题不解决，项目就会卡在“Demo 能跑，上线不敢用”的尴尬状态。我按出现频率从高到低整理一下。
4.1 高置信度错误比编程错误更难缠
最常见的现象是模型给出一个观点非常明确的结论，比如“这里可导致内存泄漏，建议改为延迟初始化”，但实际上是错的。普通程序员看到这种答案，会下意识认为“模型说得这么专业，应该没错”。这是最危险的场景，高置信度错误的杀伤力比什么都不说还要大。
我的排查经验是：把模型的输出分成事实断言和建议两个部分，分开验证。事实断言比如“这个函数没有释放锁”“这个接口没有超时设置”，要能定位到具体代码位置；建议部分比如“建议改为某某写法”，作为参考意见，不直接执行。同时要求模型在输出时给每条问题附上“依据”，哪怕是“依据某行代码”“依据团队规则第几条”。如果没有依据，宁可降低这条结果的置信度。
4.2 结果时好时坏，先别急着换模型
“昨天还正常，今天就不对”是调查最多的场面。大部分人第一反应是换更贵的模型，但问题通常出在中间件，而不是模型本身。
排查顺序应该固定下来：先查上游数据，看输入是不是多了一段乱码，格式是不是变了；再查下游解析，看输出格式微调导致 JSON 解析失败；最后查中间缓存，看历史版本是否被意外命中。这三类问题先排除，再考虑是不是要做模型切换。切换模型前，记得先拿评估集跑一遍新模型的分数，不然你就是在用感觉换方案。
4.3 成本预算往往被严重低估
很多团队第一版 AI 功能上线后，月底账单出来才发现比预估贵一倍以上。原因是只算了模型调用费用，没算失败重试、并发重试和输出长度放大。
我的做法是在需求阶段就给一个三维预算：平均每次请求消耗多少输入 Token、输出 Token，计划日调用量预估多少，以及预留 30% 到 50% 的重试缓冲。同时做好省钱习惯：能压缩的上下文就压缩，能用小模型处理的简单问题不调用大模型，能缓存相似问题结果就上缓存。这些听起来不性感，但在实际项目里就是利润和打水漂的区别。
4.4 评估集被污染会带来虚假信心
一个隐蔽问题：大家为了提高分数，不断把“发现的问题”加进评估集，反复调 prompt 让模型“记住答案”。最后分数从 60 分一路爬到 95 分，上线却发现效果完全不是那么回事。这就是评估集污染。
正确的做法是让评估集保持相对稳定，并且按时间切片。训练用数据来自某个时间段，验证用数据来自之后的一段时间，这样能模仿真实上线后的分布变化。每轮迭代只准改 prompt 和策略，不准为了让某条数据过评估而悄悄改标签。评估集的目的是暴露问题，不是证明你很行。
5. 90 天行动版路线图：每天到底干什么
前面讲了理念和方法，这一节给出可以直接照做的节奏。我把整个能力升级周期压到三个月，每两周一个阶段，每个阶段都有明确的交付物。
5.1 第 1 至 2 周：搭建评估闭环
这段时间的核心目标是建立“可衡量的基线”。找一个小而明确的场景，比如“从对话记录中提取用户诉求”，手工整理 100 条评估数据。然后用最朴素的方式调用大模型跑一遍，把准确率、格式合规率、失败率记录下来。
一周时间足以把评估脚本写熟。脚本的逻辑可以很朴素：输入一个案例、调用模型、校验输出、计算分数。别追求界面好看，先追求能反复跑。第二周再扩展边界案例。这两周的唯一验收标准是：任何一次模型改动，你都能在十分钟内知道分数变好还是变坏。
5.2 第 3 至 4 周：跑通最小可用闭环
第二阶段的重点是端到端。建议直接选一个内部工具型场景，比如文档问答、工单分类、代码审查辅助。从零开始做一个最小版本：一个输入页面、一段预处理、一次模型调用、一个结果展示。
这半个月不追求效果完美，追求链路完整。你会在这个过程中遇到很多实际问题：文件解析有问题、接口超时、结果展示不友好。每一类问题都是有价值的经验。这个阶段结束后，你应该能回答“整个 AI 功能一共经历了哪些环节”“哪个环节最容易出问题”。
5.3 第 5 至 8 周：做真实功能迭代
第三阶段是拉高效果。此时你已经有了评估集和端到端链路，可以开始迭代了。先做上下文工程优化，再做检索增强，最后做校验兜底。
每周给自己定一个单项指标。第一周只提升格式合规率，第二周只提升召回完整度，第三周只压响应耗时，第四周只压成本。你会发现单一指标优化起来容易，合在一起不冲突才是真本事。期间请真实用户过来试用，观察他们在什么场景下点“不信任”“不采纳”，这些反馈比模型分数更有价值。
5.4 第 9 至 12 周：沉淀方法论并复用
第四阶段是拔高境界。把做完的项目复盘成几个模块：可复用的数据处理流程、可复用的评估集模板、可复用的 prompt 模式、可复用的校验规则。整理成团队内部文档，下一个 AI 场景直接复用，速度快很多。
同时做一个动作：把整套流程反向讲给团队听一次。能讲清楚“我为什么选这个架构”“哪些问题不再用 AI 解决”“评估脚本怎么用”，说明你真的掌握了。讲不清楚的地方，大概率是你还没吃透。
6. 写在最后：一点个人体会
很多中级开发者在学习 AI 时，总想先学完再动手。但以我的经验，最有效的路径是反过来的：先选定一个真实场景，把功能做到 60 分，再在补齐 40 分的过程中补齐自己的知识盲区。
第一次做 AI 功能时，我的系统也是漏洞百出，幻觉没控好，评估集也建得粗糙。但正因为不完美，才逼着我去想清楚哪些地方是模型该负责的，哪些地方是我该兜底的。做完整的两个项目之后，我再去看各种新技术，速度和理解力都比当初快得多。
路线图能给方向，重复练习才给肌肉。哪怕你现在还没有项目，用周末时间从一个小场景开始，跑通一个带评估的完整闭环。三个月之后再回头看，你会发现，所谓的 AI 能力升级，并不是学会了某个神秘技能，而是把“不确定”变成了可测量、可修正、可复制的工程过程。
