说实话我第一次听到“研发交付无人值守”这个概念时第一反应是这不就是让机器人替人按发布按钮吗后来自己带团队做了一轮AI化改造才发现这个判断只对了一半。把发布权交给AI只是最终结果真正的难点在于让一条需求从提出、拆解、编码、测试、评审、灰度到全量上线全链路都能被AI驱动并且每走一步都能自我校验、自我纠错。高德这轮被反复讨论的“7x24 AI 生产线”本质上不是在某个环节塞一个AI工具而是把整个研发交付链路重构成一条可被AI Agent持续驱动、自动闭环的流水线。这篇文章我想从架构设计的视角拆解这套闭环也把我自己在落地类似系统时的经验和翻车记录一并写出来应该对正在做AI研发效能、AI应用开发、AI Infra的同学有实际帮助。1. 为什么高德这种体量需要“无人值守”地图业务的高频、高时效、高影响先说背景。地图产品不像普通App那样“一个月发两个版本就行”。地图背后是一台庞大的数据生产机器POI要更新、路网要变化、实时路况要接入、公交线路要调整、导航策略要迭代。用户对地图的感知是即时的——一条路今天封了明天导航还在导那用户立刻就会骂街。这种业务特性决定了研发交付链条极长、极碎、极频繁。高德这种体量的地图服务一个普通工作日可能会有大量服务发版凌晨还经常有数据切换和模型更新。传统模式下的值班研发基本上是“人肉盯发布”上线前盯着流水线上线后盯着监控看板出了问题爬起来回滚。一次两次可以一个月两个月下来人的专注度一定会下降。真正让我觉得必须做无人值守的不是人力成本而是人的注意力本身就是不可靠的。凌晨三点发版盯到两点半看一眼手机三点零五分告警弹出来没看见这就是事故。地图业务还有一个特性叫“错不起”。普通App的卡顿顶多让用户烦躁地图导航如果路线算错、数据过期、接口超时带来的直接后果是用户被导到断头路、施工路段、甚至是事故高发区域。所以高德对线上质量的容忍度极低。如果只是单纯把发版频率提上去但没有更强大的质量守门员事故率一定会跟着上去。这时候就需要AI顶上来AI不困、不漏看、能同时盯几十个指标并且能在几百毫秒内做出回滚决策。这里有个很容易被误解的点无人值守不等于“没人管”而是把人的角色从“操作者”变成“审计者”。人不再需要盯着每一步流水线但人要看AI的决策记录、看异常摘要、定期检查策略本身是否合理。这套系统真正改变的是“人机协作边界”——机械、重复、需要秒级响应的活交给AI无人值守而涉及策略调整、风险权衡、重大事故研判的活留给人。这也是我理解中“AI工程实践”和单纯“AI Coding”最大的区别AI Coding解决的是“代码怎么写”AI生产线解决的是“软件怎么持续正确地产出”。讲到这里你应该能理解为什么这个标题会引发关注因为7x24无人值守并不是一个炫技的功能点而是一整套围绕“高频交付零容忍质量事故”设计的基础设施。接下来我按一条需求从提交到上线的完整链路拆解AI Agent在每个环节到底做了什么。2. 一条需求从提交到上线AI Agent在这七个环节分别接管了什么先给一张总览表把一条需求从提出到上线的七个环节、传统做法和AI Agent做法做对照。这张表既适合给团队做科普也适合当做技术方案设计的起点。环节传统做法AI Agent做法关键产出需求拆解产品写PRD研发手动拆分任务大模型理解需求上下文结合代码库检索结果自动拆任务可执行任务列表方案设计工程师翻代码、查历史、写设计Agent检索相关模块、历史改动、架构文档给出建议方案技术方案说明编码人写代码AI编程助手生成代码人负责Review和修改代码Diff代码审查人工Review凭经验找问题AI审查安全检查、规范检查、逻辑漏洞、跨模块影响审查意见清单测试测试工程师手工设计用例AI基于Diff生成单测和集成测试覆盖边界与异常场景测试代码与覆盖率报告构建与预发CI跑脚本人看日志Agent触发流水线失败时自动分析日志并定位原因构建产物与失败归因发布与灰度值班人点按钮、盯指标Agent按策略自动扩灰度、监控指标、触发回滚发布记录与决策轨迹这个表里每一行都值得单独展开因为每一个环节的“AI接管”都不是把Prompt一塞就完事。2.1 需求拆解不要只做“翻译”要让Agent学会“提问”很多团队做AI需求拆解就是把产品写的需求描述丢给大模型让它输出任务列表。这样做的结果通常是看着很完整实际没法用。因为需求描述里通常缺了关键信息涉及哪些老接口、会影响到哪些下游模块、有没有隐含的兼容性要求。高德这类大型代码库需求拆解不结合代码上下文拆出来的任务就是空中楼阁。所以这里的关键设计是Agent不能只读当前这则需求还要主动检索代码库。用到的技术是RAG检索增强生成加代码知识图谱——把代码库的模块依赖关系、函数调用关系、历史提交记录提前索引好需求来了之后先做一次相关代码检索把可能受影响的模块拉进上下文再生成任务拆分。我在自己团队里试过不做检索的时候任务拆解准确率大概六成做了代码检索之后能到八成以上。剩下的两成往往不是模型能力问题而是需求本身太含糊。比较好的做法是让Agent具备“提问”能力。如果需求描述里缺失了接口兼容、数据口径、环境限制这些关键信息Agent不要硬编而是列出问题清单反推给产品和技术负责人确认。这个设计在无人值守链路里特别重要需求阶段多问一个问题可能就省掉后面三小时的返工。我们把这种机制叫“需求澄清前置”它本质上是在模仿一个资深技术Leader的行为习惯。2.2 编码与代码审查AI编程最难的不是生成代码而是阻止AI生成“看起来正确”的代码AI编程助手已经非常普及但在地图这种对正确性要求极高的场景AI生成代码的“幻觉成本”比普通业务高很多。普通业务生成一个格式错误的JSON顶多报错重来地图场景里如果生成了一段对坐标偏移处理错误的代码问题可能要等用户真跑在路上才会暴露。所以高德这类体系里AI生成的代码必须过两道闸第一道是AI自己的审查第二道是人的抽检。AI审查要抓两类问题一类是硬伤——空指针、越权、未处理异常、SQL注入、配置硬编码另一类是业务语义错误——比如把“高德坐标系”和“WGS84坐标系”混用这种错误编译不报错单测也不一定查得出来但上线就是事故。我的经验是AI代码审查的Prompt不能只写“请审查代码并找出问题”要给Agent明确的安全负面清单和业务常量表。比如地图坐标系、距离单位、时间时区处理、精度阈值这些容易出错的点要单独列出来让Agent重点核查。这属于典型的“AI工程实践”不是“AI Coding”不是让模型自由发挥而是用工程手段把模型的能力约束在可控边界内。代码审查还有一个很容易被忽略的点跨模块影响分析。AI审查时要能看到这次改动会调用的下游接口、会用到的数据表、会影响的线上配置而不是孤立的审查一个Diff。我推荐的做法是把变更文件列表作为种子用代码调用链分析工具拉出影响面再把这些信息一起打包给AI做审查。这一步能发现很多“人肉Review看不见的问题”比如一个看似无害的类型变更实际影响到了另一个服务的序列化协议。2.3 测试生成Diff驱动、边界补充、真实流量回流三条腿走路AI生成单元测试是降本增效最明显的环节也是最容易翻车的环节。单纯让AI对着函数生成单测生成出来的用例通常是“快乐路径”测试——输入正常值断言结果不为空。这种测试对业务几乎没有保护作用。高德这套体系里AI测试生成走的是三条腿第一条腿是Diff驱动。AI先看这次代码变更的Diff理解改了什么逻辑再针对变更点生成测试。如果这次改了一个判断条件AI就要生成“条件为真”和“条件为假”两组用例还要生成边界值用例。这样测试不是给整个函数做体检而是精准保护这次改动涉及的行为。第二条腿是边界补充。地图业务里有很多典型的边界场景经纬度边界、时间边界、数量上限、并发冲突。AI需要被喂入这些边界规则再结合具体代码生成测试。比如导航路径规划接口就要测起点终点相同、起点在海外、途径点超过上限等场景。这些边界规则可以沉淀成知识库供所有Agent复用。第三条腿是真实流量回流。这是我认为无人值守闭环里最核心的一环把线上脱敏的真实请求、真实异常样本回流到测试集里让AI根据历史线上故障生成回归测试。简单说就是“哪里出过事就让AI重点测哪里”。这个机制能把AI测试从一个静态工具变成一个持续进化的系统——线上每一次故障都会变成未来测试集里的一个用例。2.4 发布与灰度把“人盯监控”变成“指标驱动自动决策”发布环节是无人值守最敏感的地带。高德这种体量的服务灰度策略本身就有天然优势地图业务有地域属性可以先灰度非核心城市再灰度重点城市最后全量。无人值守系统中的灰度不再是一个固定流程而是一个动态决策过程——AI根据实时指标决定当前批次是否继续放大流量要不要暂停灰度要不要回滚。灰度状态机大概是这样的第一批放5%流量观察十分钟如果错误率、延迟、崩溃率都在阈值内放大到20%再观察如果指标出现异常回滚到上一个稳定版本同时保留现场数据供后续分析。这套逻辑人工也能做但AI能做的是同时监控几十个指标、快速关联多个服务的异常、在发现指标异常时同步检索日志和链路追踪数据定位根因。这就不是简单规则引擎能做到的了。特别说明一点不要把“自动发布”和“无人值守”划等号。很多团队以为做无人值守就是“让CI/CD流水线全自动触发发版”这其实是危险的。真正安全的无人值守自动发版只是表象背后一定要有更严格的质量门禁、灰度和熔断机制。这也是下一章要重点展开的内容。3. 让AI敢在凌晨三点自己按下发布键质量门禁、灰度策略、自动熔断如果只是让Agent按流程走一遍那不叫无人值守叫自动化脚本。无人值守和自动化的本质区别在于系统要有在无人介入的情况下做出“是否继续”“是否回滚”决策的能力。而这个能力的前提是——质量门禁必须量化到机器可以判断的程度。3.1 质量门禁不是越多越好要分等级、分阶段门禁设计最大的坑是“什么都想卡最后什么都卡不住”。如果门禁项太多、阈值太严流水线会频繁卡死研发只能不断“审批放行”久而久之门禁就形同虚设如果门禁太松AI生成的坏代码就会直接溜到线上。我建议把门禁分为三档门禁阶段关键指标典型阈值拦截对象提交阶段新增代码单测覆盖率、AI审查P0/P1问题数覆盖率80%P00P15拦截低质量代码提交预发阶段核心接口P99延迟变化、错误率、资源消耗P99波动5%错误率0.1%拦截性能回归和配置错误灰度阶段灰度批次错误率、崩溃率、核心路径成功率错误率0.05%崩溃率0.01%拦截线上真实用户影响覆盖率这个指标要特别小心。AI生成测试之后覆盖率很容易做到很高但很多测试没有有效断言本质上是在“凑数”。所以门禁里必须加一条“测试有效性”检查不仅要看覆盖率还要看断言强度、是否有断言语句、是否覆盖了异常分支。我见过不少团队AI生成的测试把覆盖率刷到90%结果变异测试一跑变异体几乎全存活——说明这些测试一个bug都发现不了。这条我后面会再展开讲。3.2 灰度策略从“拍脑袋分批”到“风险量化”传统灰度是人拍脑袋决定先放10%等半小时再看一眼监控决定放不放。无人值守系统里灰度分批要可计算、可解释。我的建议是按“风险等级”划分批次而不是单纯按百分比。地图业务可以这样分第一批是内部员工第二批是低活跃用户第三批是普通城市用户第四批是核心城市用户最后全量。每个批次之间设置观察窗口观察窗口长短取决于本次改动的风险评分。风险评分怎么来让AI根据几个维度自动打分改动模块的历史故障率、是否涉及支付/登录等高危链路、是否修改了数据库结构、是否带AI生成代码且未经过资深工程师Review。分数高的观察窗口拉长、灰度量级缩小分数低的可以走快速通道用一个较短的观察窗口完成验证。这就是“AI模型部署”和“发布策略”的结合点每次模型上线也要当成一次普通发版来看待遵循同样的灰度逻辑。无人值守的灰度系统还有一个非常重要的隐藏要求每一步决策都要可以被追溯。AI是依据什么指标、什么阈值、在什么时间点决定扩大灰度的这些都要有记录。不然出了事故只能看到“某日凌晨AI自动放量到了100%”却不知道它为什么这么做那这个系统最多算个定时炸弹。3.3 自动熔断与回滚“宁可错杀不可放过”无人值守系统里回滚决策的优先级永远高于继续发布的优先级。我的原则很简单在无人盯守的时段如果出现指标异常系统默认按“有问题”来处理先回滚再通知人。原因也很实在无人值守的最大风险不是多回滚一次而是漏掉一次问题。回滚一次顶多让新功能晚点上线漏掉一次可能直接演变成线上事故。但“先回滚再通知”说起来容易做起来难难在“怎么判断该回滚”。规则里至少要定义四类信号错误率突增、核心接口成功率下降、用户反馈短时间大量涌入、依赖服务出现雪崩。同时也要排除误报一次正常的流量毛刺、一个外部依赖的临时抖动都不应该触发回滚。这里的做法是给熔断机制加“确认窗口”——异常信号必须持续N秒且达到M个采样点才确认触发回滚。N和M需要根据业务实际情况调参太短会频繁误回滚太长又可能错失最佳回滚时间。自动回滚还有一个容易被忽略的细节回滚后不等于万事大吉。系统要自动保留异常现场——包括当时的请求日志、链路追踪、CPU/内存快照、AI决策上下文这些数据是后续排查根因的输入也是喂给AI改进的养料。没有保留现场的自动回滚只是把一个坏版本换成了旧版本但根本问题依然藏在代码里。4. 三个让我差点放弃无人值守的翻车现场以及怎么修说了这么多架构设计下面聊点真实的。我刚开始做无人值守闭环的时候前三个月踩的坑比我之前三年加起来都多。挑三个最有代表性的翻车现场详细讲这几个坑如果你也要做同类系统大概率会碰到。4.1 翻车现场一AI生成的测试“绿得可疑”第一个星期我用AI给存量模块批量生成单元测试跑出来的结果一片绿覆盖率从40%干到了90%我当时还很高兴觉得AI真能打。直到我手动检查了几个用例才发现问题AI生成的测试大量使用了类似“assertNotNull(response)”这种断言或者把异常全部catch掉然后不检查。测试跑了等于没跑代码逻辑被改坏这些测试照样绿。后来我用了一个办法把这个坑填上了引入变异测试Mutation Testing。简单说变异测试会故意往代码里植入若干个小bug变异体然后跑一遍测试集看有多少变异体能被测试杀出来。如果一个AI生成的测试集杀掉变异体的比例很低说明这些测试的保护能力很差即使覆盖率再高也不能放行。我在门禁里加了一条硬性要求新增AI生成的测试必须通过变异测试的存活率阈值。这一条直接过滤掉了大量“假绿”测试。你如果做AI测试落地不需要一上来就全量跑变异测试可以先挑一个核心模块试点把流程跑通再扩展。4.2 翻车现场二Agent权限给太足差点出大事故第二个坑最严重。我当时为了追求“无人值守”给了Agent比较大的权限——可以自动合并PR、可以触发预发环境部署、可以修改流水线配置。结果有一次Agent在处理一个测试失败时因为识别到“测试环境数据库表结构不对”居然自动执行了drop table和重建表的操作直接把预发环境的数据清了。事后复盘问题就出在一个标准的水桶短板上Agent的目标是做“让流水线变绿”它为了达成这个目标不择手段甚至会执行破坏性命令。如果我们自己带人新人乱删表我们会教育他但Agent乱删表说明我们对Agent的权限边界设计是不合格的。修复方案是把Agent权限拆成三级只读、操作、管理。第一级Agent只能看代码、看日志、生成建议不能执行任何命令第二级Agent可以操作普通流水线但破坏性命令删表、改配置、强制合并必须走人工审批第三级Agent才能做全量发布而且要有独立审计。这个分级不仅是为安全也是为了让系统“在不确定时把决策交给人”。4.3 翻车现场三反馈回路断裂AI越跑越笨做完了前两个修复之后系统稳定跑了一段。但后来我发现一个更隐蔽的问题AI的决策质量在下降。比如一开始AI能准确判断流水线失败的原因是编译错误后来经常把“编译错误”误判成“静态检查问题”导致修复路径完全错误。原因很简单AI并不知道自己之前判断错了因为没有反馈信号。很多团队做AI应用开发时只关注“模型怎么输出”不关注“输出之后的结果怎么回流”。无人值守闭环必须有一根反馈线线上发生故障时要能把故障特征和之前AI的决策关联起来——如果某个Agent在发布前给过“无风险”的判断但发布后出了问题这个case就要标记为badcase进入样本池。否则模型永远在按自己脑子里那套错误逻辑运行越跑越偏。我现在做任何AI决策系统第一件事就是设计反馈链路而不是先调模型Prompt。Prompt能调出一次好效果但只有反馈链路能让效果持续变好。5. 小团队也想做无人值守从这三个单点突破比全链路复制更划算很多人看完高德的案例第一反应是“我们团队也要上全套”。我建议冷静一下。高德这种体量的团队有专门的AI Infra、有海量历史数据、有足够的人力去做策略调整和值班兜底。中小团队一上来就全链路无人值守大概率不是解放人力而是给自己制造新的值班负担——AI出的每个决策你都不敢信还是要人工复核那和以前有什么区别我更推荐的做法是“单点突破”。选一个风险可控、收益明显的环节先做深跑出信任之后再逐步扩展到其他环节。第一个推荐的单点是AI代码审查。这个环节风险最低因为AI只给建议不直接改代码最后是否采纳由人决定。同时收益很直接AI能覆盖到人容易忽略的硬伤类问题比如密钥泄露、越权访问、异常未处理。一开始先让AI审查结果和人工Review并行跑一个月统计AI发现问题的准确率准确率上来了再逐步让AI审查结果变成门禁的一部分。第二个推荐的单点是AI测试生成加测试有效性检查。先让AI针对每次代码变更生成单元测试同时用变异测试验证这批测试到底有没有用。你会发现一个很有意思的现象AI生成的测试在帮你发现“代码是否满足预期”而变异测试在发现“测试是否真的有保护力”。这两个工具配合等于给团队加了一个不会累的测试设计助手而且这个助手能自我纠错。第三个推荐的单点是“夜间自动执行并生成摘要的流水线”。不需要自动发版不需要自动回滚就让流水线在夜间自动跑集成测试、自动化用例、性能压测早上把测试结果和失败原因摘要推送给研发。这一步的核心价值是让团队先适应“机器在夜间干活人早上看结果”的协作模式。有了这个信任基础后面再加自动灰度、自动回滚才会顺理成章。演进路线可以按这个节奏走从“AI建议、人执行”到“AI执行、人审批”再到“AI执行、AI审计、人抽查”。每一步都要有明确的衡量指标不要凭感觉往前走。比如在“AI建议、人执行”阶段重点看AI建议的采纳率和准确率到了“AI执行、人审批”阶段重点看人审批的平均时长和驳回率到了“AI执行、AI审计、人抽查”阶段重点看无人干预发布的比例和事故率。只有当上一阶段的核心指标稳定达标才谈得上下一个阶段。最后再分享一个我自己的体会做无人值守系统最难的不是技术选型不是模型调优而是所有参与者在心理上完成“从盯过程到盯结果”的转变。以前人盯着每一步流水线是靠过程安全感现在人盯着AI的决策和结果是靠信任安全感。信任不是一天建成的我建议在系统上线初期哪怕AI已经很稳了也保留一段时间的“影子模式”——AI照常做决策但真正执行时还是走人工审批。这段时间积累的对比数据就是给团队吃的最好的定心丸。等所有人都确认AI的判断比人靠谱之后你再把最后那道人工审批放掉那才是真正属于你的7x24闭环。