去年我们内部启动了一个用 AI 改造业务研发流程的项目名字就叫“ai-engineering-from-scratch”。动机很简单团队里每个人都用过 ChatGPT、Cursor 这类工具但各自用得深浅不一有的是靠 AI 写点脚本有的干脆只用它翻译报错信息。真正到了项目里想让 AI 稳定地产出可用的、符合我们架构规范的代码、测试和文档大家反而发现无从下手。我当时接到这个任务时手里的资源只有几个人几台开发机和一个已经跑了三年的老业务系统。这篇内容就是我从零搭建一整套 AI 工程实践的全过程复盘包括我最初踩过的坑、后来沉淀下来的方法和一些可以直接照抄的工程配置。如果你正准备在团队里系统化地推动 AI 落地或者自己想在真实项目里把 AI 用明白这篇应该能帮你省下不少弯路。先说说我最终做出来的东西长什么样。整个体系分成三层底层是模型与上下文管理中间是 Agent 编排与工具调用上层是质量验证与反馈闭环。这三个层次不是一次建成的而是我分别在最开始、中期和最后遇到瓶颈时一个一个补上去的。下面我按实际推进的时间线来讲每个阶段我都会说清楚当时遇到的具体问题、背后的原因以及我最后采用的解决方案。1. 起步阶段我对“AI 工程”最初的三个误判1.1 误判一以为会写提示词就算入门我最早犯的错是把 prompt engineering 当成了整个 AI 工程的核心。项目刚启动的时候我花了两周时间去研究各种提示词技巧什么角色设定、思维链、少样本示例我都有整理成内部文档。效果如何呢单看某一轮对话确实惊艳模型能按照我给的模板生成非常漂亮的代码。但一旦场景变化比如从生成一个工具类变成生成一个带数据库事务的 Service原来那套提示词就失效了输出的代码开始出现各种风格混乱、错误处理缺失、甚至完全跑不起来的逻辑。这个问题的本质其实不在于提示词写得不够好而是我把“和模型对话”误当成了“做工程”。真正的 AI 工程核心是要处理一个模型永远记不住全局、永远会产生随机性偏差的产物。提示词只是跟模型沟通的界面就像 API 文档不等于整个服务端架构一样。我后来才意识到想让 AI 稳定输出最关键的是要管理好它看到的上下文而不是反复琢磨“该怎么问”。1.2 误判二把模型能力顶配当成工程成功的关键项目刚开始我们调研了一圈模型最后选了一个当时评分最高、参数最大的模型来跑所有任务。结果一测确实生成质量很高但两个问题立刻暴露出来第一是速度。我们想让 AI 自动帮研发团队生成代码评审意见一次评审要过十几个文件直接调用大模型的话单个文件处理要十几秒客户等待超时不说研发人员的耐心也扛不住。第二是成本。一个月下来光 API 费用就是几万块在内部演示的时候老板脸色很不好看。后来我做了一个很关键的调整——在管理面控制模型分级。简单的任务比如生成 commit message、做代码格式规整、写单元测试的骨架我会用一个小模型只有真正需要深度推理的任务比如分析业务逻辑缺陷、生成复杂的迁移方案才会路由到大模型。这个决策的经济逻辑其实很简单AI 工程和所有工程一样要先算清投入产出比。用顶配模型处理所有事情就像开着一辆跑车去便利店买瓶水不是不行是划不来。1.3 误判三忽略了上下文本身就是一种资源这个误区藏得很深直到我做了两个月才真正想明白。一开始我认为 AI 的记忆窗口是天然的优势什么东西都可以往里面塞。于是我们的第一版工具会一次性把整个项目的需求文档、接口文档、数据库表结构、历史代码全部拼进提示词里。结果非常糟糕——模型的输出开始变得飘忽不定。有时候明明问的是订单模块的问题它回答里却混进了商品模块的逻辑有时候它为了回应我们塞进去的大量信息会自作主张地“补充”一些代码片段而这些代码跟项目里的真实代码库没有任何关联纯属幻觉。这个问题的根源在于模型的注意力是有限的。就像一个人面前摆了五十份文件他不可能每一份都读得仔细。你塞进去的内容越多关键信息被稀释得越厉害。真正的上下文工程不是“尽量多塞”而是“精准投放”。从那之后我们做的第一件事就是严格控制送入模型的文本量每个任务只携带那部分必要的信息。这个改动后面让输出质量有了一个非常明显的提升。2. 上下文工程实践让同一个模型“突然好用”的临界点2.1 为什么同样的提示词在不同项目里效果天差地别在踩完前面几个坑之后我开始把精力集中在一个方向上——上下文构建。这时候我发现一个很有意思的现象同样一个模型用同样的提示词模板在 A 项目里生成的质量可以打 90 分在 B 项目里直接不及格。原因在于两个项目的上下文根本不一样。A 项目是我自己维护的代码结构干净模块划分清晰接口文档完善注释也写得明白所以模型拿到的都是高质量信息自然产出好B 项目是接手的老系统代码堆在一起文档早就过期了模型从这样的上下文里根本提炼不出有效的逻辑。从此我才真正明白AI 工程的核心不是让模型变聪明而是让我们喂给它的信息变干净。2.2 我是怎么搭出一个可复用的“上下文资产库”的意识到这一点之后我立刻动手做了一件事——为项目建立一份结构化的上下文资产库。所谓资产库就是把项目里那些 AI 必须知道的信息提前用一套固定格式沉淀下来供每次任务调用。我拿我们那个老业务系统做了第一次尝试结构长这样项目概览一句话说清系统是干嘛的、核心业务是什么、主要用户是谁。技术栈清单包括语言、框架、数据库、ORM、消息队列、部署方式等全部列清楚。模块地图用树状结构把系统分成几个大模块标注每个模块的核心类和入口。编码规范包括命名风格、异常处理策略、日志要求、分层架构约定。常用代码模式把系统里最典型的 Controller-Service-Mapper 三段式代码抽出来一份作为样板。已知约束比如“支付接口必须幂等”“所有对外接口有多语言需求”这类规则。这份资产库的作用是当我需要让 AI 生成一个新的接口时我不需要从头跟它解释这个系统长什么样只需要把对应的模块信息和编码规范拉出来拼进提示词模型就能在一个真实约束边界内生成代码幻觉率下降得极其明显。这个经验后来被我带到别的项目里也都复现出了同样的效果。2.3 上下文压缩与检索容量不够时的出路资产库信息多了以后又遇到新问题——有的模块说明写得很长单次任务根本放不下全部信息。我又补了一个检索层简单说就是用向量检索把最相关的上下文片段找出来再拼进提示词。这个方案的细节比较多但思路其实很简单先把项目文档、代码注释、接口说明这些信息做 embeddings存到向量数据库里。每次发起 AI 任务之前先根据任务的关键词做相似度检索取回相关度最高的几个片段再连同任务描述一起交给模型。这里有一个工具就是要小心检索结果的质量决定了生成质量所以你需要在索引上做文章比如把“订单模块的优惠券计算逻辑”这类高频词单独建索引而不是只按整篇文章切片。提示上下文不是越多越好而是越精准越好。宁可只给模型 2000 字的高质量上下文也不要硬塞 20000 字的完整字段说明。我在实际操作中把大部分任务的上下文压缩到了原来的三分之一模型输出的可用率反而提升了一半以上。这段极简的上下文工程实践让我第一次感觉到“AI 工程”和“随便用用 AI”之间隔着一条真正的分水岭——分水岭在于你是否把 AI 当作一个需要认真对待资源的系统而不是一个有问必答的玩具。3. 让 AI 真正干活从单轮到 Agent 编排的实战跃迁3.1 单轮问答和 Agent 之间的本质区别上下文工程解决的是“单次生成质量”的问题但我在实际推进中很快发现业务场景根本不是单次生成能覆盖的。举个例子我们要让 AI 帮忙把一沓旧的 SQL 迁移脚本改写成新版 ORM 的调用代码。这个事情拆开来看有几步第一步读取 SQL 脚本分析它查询了哪些表、用了什么关联;第二步根据表结构生成 ORM 的实体类;第三步生成查询逻辑;第四步做本地验证。如果每次都用单轮问答我就要人工做中间的数据传递和衔接这不叫工程化只是给 AI 当秘书。于是我开始转向 Agent 架构。Agent 和单轮问答最大的区别在于Agent 有记忆、能规划、会调用工具还能根据外部反馈调整自己的行为。简单说单轮模型是一个“思考器”Agent 是一个“行动者”。我构建的第一个 Agent 做的事就是把上面那个 SQL 改写流程自动化它先把 SQL 解析成结构化的元数据再根据元数据去查资产库里的表结构文档然后生成代码最后调用本地的编译器做语法检查报错了就自己改改完再检查直到通过。3.2 任务分解、工具调用与循环反馈Agent 的三根支柱做 Agent 的时候我踩过一个特别典型的坑一开始直接把一个大任务甩给 Agent结果它懵了输出一段前言不搭后语的内容。后来我才意识到不是模型能力不行而是我没有帮它做任务分解。Agent 的聪明程度依赖系统设计的颗粒度你让它“完成整个模块开发”它会迷失你让它“先完成实体类再写 Mapper 接口再做 Service 层”它就能一步一步执行。我在实际落地中把 Agent 拆成了三个核心机制任务分解器把用户输入的目标拆成可执行的任务列表每一项都是独立的、有明确输出的原子任务。工具调用器Agent 在执行每项任务时需要调用外部工具来获取信息或验证结果包括读文件、查数据库、执行测试等。循环反馈器每完成一步Agent 都会获取一个结果再根据结果修正下一步计划。这个循环反馈是 Agent 能稳定工作的核心某种意义上你也可以把它理解成 loop engineering 的精髓——不断循环直到达成目标。其中最关键的其实是循环反馈机制。实现上不复杂就是在代码里做一个 while 循环每次执行完毕检查结果是否符合预设条件不符合就带着失败原因重新调用模型。这个循环有两点要注意一是必须设置最大重试次数防止 Agent 在某个错误分支上无限打转二是每次重试时要把上一次的错误信息完整拼到上下文里否则模型无从判断哪里错了。3.3 多 Agent 协作从单兵作战到流水线作业单 Agent 跑通之后我很快遇到了性能瓶颈。还是那个 SQL 改写项目一个 Agent 要串行完成四五个步骤每一步都要调用一次模型有时候一个任务跑下来要两三分钟而且中间任何一步出错都得整体重来。为了提速我把单 Agent 拆成了多 Agent 协作的流水线——每个 Agent 专职负责一个环节Agent 之间通过消息队列传递任务产物。这个多 Agent 架构设计成三个阶段解析 Agent负责把输入的 SQL 脚本解析成结构化任务产出描述文件。生成 Agent读取解析结果生成 ORM 实体、Mapper 接口和 Service 代码。验证 Agent执行编译、检查代码风格把问题反馈给生成 Agent 做修正。这个架构跑通之后吞吐量提升了将近 4 倍。而且我发现多 Agent 协作还有另一个好处因为每个 Agent 的职责单一上下文可以做得非常精简模型的注意力集中单个环节的输出质量反而比一个全才 Agent 更好。这个发现也让我笃定了一条原则宁可多拆几个细小 Agent也不要试图让一个 Agent 干所有事。4. 质量验证体系AI 生成的代码怎么保证不出事4.1 AI 生成走进研发流后测试的“图景”彻底变了当 AI 生成的代码量开始占总代码量的三成以上时质量验证就成了整个体系里最要命的环节。传统测试思路是“人写代码人写测试人执行验证”这套流程在 AI 时代有一个致命缺陷——AI 生成的代码往往自己写测试也自己验证容易陷入“自己夸自己”的循环。比如让 AI 生成一个函数再让同一个 AI 写对应的单测很可能因为同一个逻辑盲区测试通过但实现其实是错的。我一开始也栽在这个坑里。让我们的 AI 工具自动生成了一段日期换算逻辑单测跑得全绿结果上线后发现在跨年场景下计算出错。原因很简单AI 在生成代码和生成测试时脑子里用的是同一套错误假设测试自然给它背书了。从那之后我把质量体系彻底换了一遍思路。4.2 我搭的“三层验证”方案现在我的验证体系分三层每一层盯不同的问题静态规则检查用 SonarQube 这类工具做代码规范、安全漏洞的扫描这一层跟 AI 无关但必须放在 AI 生成之后第一个执行因为规则是确定的机器能快速筛掉低级的风格问题。行为测试与边界测试这里不是让 AI 自己写测试而是让人工设计好边界条件集合再让 AI 基于边界条件生成测试用例。我通常会列举 10 到 20 个刁钻输入比如空值、超长字符串、极端日期、并发访问这些交给 AI 生成测试代码来覆盖这些边界确保代码种的处理不会挂掉。双模型交叉验证这是我自己摸索出来的一个偏方也非常实用。AI 生成的代码拿给另一个独立的模型去审查让它从反方向找问题比如“这个实现有没有可能在大数据量下超时”“这段逻辑有没有并发安全问题”。因为两个模型的训练数据和先验偏见有差异交叉验证的盲区重叠度会小很多就是那种“你是写代码的他是找茬的”模拟了现实中结对编程的效果。这三层跑下来AI 生成的代码上线率从最初的 40% 左右提升到了接近 80%剩下的 20% 基本都是业务需求本身理解偏差靠验证是兜不住的需要人工确认。4.3 评估集比测试用例更难维护的东西还有一个地方我要专门提醒当你把 AI 工程化的程度加深之后你会发现最需要长期维护的不是代码不是提示词而是评估集。所谓评估集就是一组固定的输入和对应的期望输出用来衡量每次修改提示词、编排逻辑、换模型之后整体系统的能力有没有下降。我维护了两类评估集核心回归集大约 50 条覆盖系统最核心的业务逻辑场景每次修改系统后必须跑一遍保证核心能力不退化。边缘挑战集大约 30 条专门放一些刁钻的边界场景用来检测新改动会不会引入幻觉或逻辑漏洞。这 80 条评估集是我整个 AI 工程体系里唯一不敢偷懒的部分。每次我改一版提示词感觉改得更精细了跑一遍评估集结果可能下降了 10 个点那就得立刻回滚。这个习惯救了我很多次比如有一次我优化了上下文压缩策略短期看单次生成效率提高了但跑评估集发现涉及复杂业务逻辑的任务全部跑偏原因是我压缩策略把关键的业务约束给过滤掉了。没有评估集这种问题要等到用户反馈才能发现。5. 从个人工具到团队基建AI 原生研发范式的日常化5.1 让 AI 成为“团队的一等公民”需要什么样基础上面讲的这些说到底是建立一个 AI 工具链的能力。但说实话真正让我觉得这个项目“从 scratch 到体系”跑通的标志是这套东西从我一个人使用变成了整个研发团队的日常基础设施。要做到这一点我做了三件很关键的事。第一件事是把模型从“黑盒 API”变成“带路由的服务”。团队里所有人的 AI 请求统一走一个网关由网关根据任务类型路由到合适的模型同时统计每个团队成员的 Token 消耗和自己的任务成功率。这个网关让我们可以从全局视角审视 AI 的使用效果再基于数据调整策略。第二件事是给 AI 的全部操作加上日志。每一步任务分解、工具调用、生成结果、验证反馈都会留下痕迹。团队后来排查一个问题时发现 AI 在某一步把字段名弄错了顺着日志一下子就定位到了是上下文资产库里的字段说明写错了然后直接修复资产库问题彻底解决。没有日志这种问题定位起来如同大海捞针。第三件事是建立了一个 AI 产物的 review 流程。AI 生成的代码纳入代码评审但评审的标准跟人工代码不完全一样重点看两点一是是否有模型幻觉产生的不合理实现二是是否有上下文中未提及但其实是隐式需求的业务场景。这个流程听起来简单但能挡住很多后期事故。5.2 团队落地时真正遇到的人的问题技术问题解决之后最大的困难反而在人。团队里有人非常拥抱 AI有人非常抵触有人嘴上说用但实际阳奉阴违。后来我做了一次内部访谈发现抵触者的核心担忧不是怕丢工作而是怕背锅——“AI 生成的代码上线出了问题算谁的”。这是非常合理的顾虑。我的解法是定了一个规矩AI 生成的代码自动署名 AIreview 通过后由 reviewer 签字。这样权责从制度上就分清楚了团队成员不再把 AI 当对手而是当同事。另外一个很有效的做法是鼓励每个人用 AI 做自己的“私活”——比如处理那些长期以来没人愿意干的重复性工作从 SQL 转写、接口文档同步、测试数据生成开始。一旦成员用顺手了他们自然会往更深的方向推进。5.3 一些同样重要的基础配置建议最后把我整个体系里最值得背下来的几条工程配置整理出来模型路由策略简单任务用小模型复杂推理用大模型成本和质量要用数据说话。上下文白名单机制不是所有文档都能进提示词只有通过评估的资产才能进。自动重试上限单个 Agent 任务最多重试 3 次超过就要人工介入防止无限循环产生垃圾。全链路日志AI 任务的每个环节都留痕这是排查问题的唯一线索。评估集门槛任何修改只要核心回归集掉超过 5 个点一律回滚。这些配置看起来琐碎但少了任何一个整个体系都会变得不稳定。尤其是评估集必须从一开始就建不要等系统复杂了再补——越早建回退保底的能力就越强。现在我们的团队日常的开发流程已经和 AI 深度耦合。以前一个 SQL 改写任务人工要做半小时现在 Agent 流水线几分钟搞定人只需要做关键节点的抽查以前写单测是大家最不情愿的活现在让 AI 生成初版、测试工程师做边界补充覆盖率反而更高了。当然过程中还是不断有新的问题冒出来比如多 Agent 协作时的 token 浪费、长任务的状态一致性、模型升级后评估集的适配调整这些都是接下来要慢慢磨的。如果让我用一句话总结这段从零搭建的历程我会说AI 工程真正的门槛不在模型而在你对上下文、反馈和验证这三个环节的控制深度。把这些地基打牢后续往上加任何能力都会很顺。