从“会用”到“驾驭”：AI Coding 进入生产环境的真实碰撞

AI摘要 AI Coding 正从单点辅助演进为具备任务拆解与自主执行能力的 Coding Agent，推动软件工程流程重构。三位一线技术负责人聚焦其在需求分析、代码审查与运维排障中的落地路径，强调质量保障范式向“SPEC+Testing”哑铃结构迁移。

AI 不替代开发者，而是加速业务交付；开发需承担端到端质量责任，转向风险分级审查与自动化门禁；代码质量重心前移至需求规格，后延至端到端测试验证。

适合资深研发工程师、DevOps 工程师、技术经理阅读。

过去几年，AI Coding 快速发展，从代码补全、代码生成，到现在具备任务拆解和自主执行能力的 Coding Agent，AI 正在越来越深入地参与软件研发流程。那么，如何让 AI Coding 从“个人外挂”变成团队生产力？如何保证代码质量，构建可控、可复用、可持续演进的 Agent 工程路径？

近日，InfoQ《极客有约》X AICon 直播栏目特别邀请 网易游戏高级技术经理林香鑫担任主持人 ，和 网龙网络资深技术总监陈洁、柏佳辰平凯数据库（TiDB） /智能研发中心负责人、汇丰科技内部开源负责人李渭宁 一起，在 AICon 全球人工智能开发与应用大会 2026 深圳站 即将召开之际，共同探讨 Coding Agent 如何重构需求分析、代码审查、运维排障等软件工程环节。

AI 来了并不是说需要减少人，而是可以更快地赋能业务，让产品和服务做得更好。

每个开发都变成 “QA”，关注 End2End。开发人员正在承担更多质量责任：不再把逐行人工审查作为默认方式，而以风险分级审查、自动化门禁和端到端验收为主，把需求、完成条件和最终结果讲清楚、验到位。

代码质量从最开始的纺锤形变成哑铃形，AI Coding agent 更像是自然语言的编译器，我们更在意的是前面的 SPEC 和后边的 testing。

在可逆、低爆炸半径且可追溯的隔离环境内，可以按任务范围给 Agent 完成任务所需的最小充分权限；数据库结构变更、生产环境操作、外部网络访问等高风险动作必须严格收紧权限或设置人工门禁。每个 Agent 都有身份标识，操作日志可追溯，新的安全风险也要持续纳入治理。

没有绝对的安全，没有安全能一劳永逸，都是发现问题快速亡羊补牢。

在 8 月 21-22 日将于深圳举办的 AICon 全球人工智能开发与应用大会 2026 深圳站上，我们特别设置了【 AI 原生新范式：Coding Agent 重构软件研发全流程 】专题。该专题将围绕 AI 原生研发的技术演进与工程实践展开，重点关注研发 Agent 的能力边界、工程化落地、质量与安全保障，以及 AI 驱动的软件生产方式如何提升研发效率、降低交付成本，并推动组织研发模式升级。

查看大会日程解锁更多精彩内容：https://aicon.infoq.cn/2026/shenzhen/track

以下内容基于直播速记整理，经 InfoQ 删减。

完整直播回放可查看： https://www.infoq.cn/video/8FaZW1Rx2ffsrru6QYdw?utm_source=home_video&utm_medium=article

林香鑫： 从大家目前的实践和观察来看，AI Coding 真正进入生产环境后，最大的变化是什么？

柏佳辰： 我们的 AI Coding 产品进入到实际的客户实践，尤其是金融客户实践比较多以后，发现两点。一是遗留代码改造比新功能开发需求更大；二是金融等行业既有企业客户对 AI Coding 流程自动化的适配性，和创业团队、互联网公司不太一样，他们往往有很多需要人去审批的不同阶段，不同的人需要去审批和 review，这对 AI Coding 的产品和范式都提出了更细致、更复杂的需求。第三，我们开发者和早期试用者对 AI Coding 范式亲和性很高，很多实际问题没暴露。但一旦落到金融等行业客户那，组织层面的协同问题就出来了，不同人对 AI 工具的适配性、熟练度、实践是否一致，都会通过产品层暴露出来。

李渭宁： 第一个从需求方面，我们以为 AI 会取代人，但实际上，业务需求是大幅增加的，最近也在大规模招人。AI 来了并不是说需要减少人，而是可以更快地赋能业务，让产品和服务做得更好。

第二个从效率层面，我们一直以来衡量生产效率主要看 Dora Metrics，看每人每年发布了多少个 release，生产事故有多少。从去年前年引入 AI Coding，去年开始大规模应用，Dora Metrics 上看有所改善，但也没办法直接证明是 AI Coding 带来的。个人层面分化很明显：技术功底好、认知够、设计能力强的人，AI 来了之后真的是成倍增加效率，但有些同事用了 AI Coding 之后反而造成了很多混乱。

第三个从 token 的使用来说。去年 token 这件事还摆不上台面，以前 GitHub Copilot 都是订阅式的，按月收费。但从今年 6 月 1 号以后，全部转成了 token 消费，这个就突然浮现在台面上了。我们现在每人每月大概几百美金预算，只有少部分人用光了这部分预算。一个重要原因跟金融行业有关系，金融行业做软件都是做精修的，很少说重建一个系统、把原来东西推翻重新再来。金融系统往往希望建一个系统就能够持续迭代十几年，所以 token 的使用情况也反映了这一点。

第一种是我们已经给研发团队推广的一套 AI Coding 与 AI Testing 工作流。它围绕 Claude Code、CodeX 和 Gemini CLI 等 Coding Agent 工具，结合 Superpowers 与研发方法，覆盖需求设计、技术调研、架构设计、详细设计和实现的常规解决方案。大家普遍反馈流程规范，实施细节可以更多交给 Agent，但链路较长。这套方式更适合业务相对稳定、对 AI Coding 接受度仍在提升的团队，属于 Agent 协作、人工主控的模式。

第二种是我直接带的团队，更接近 YOLO Mode。 我们承担的职责更多是 Pilot Team，验证更激进的 AI Coding。我发现，在部分受控开发场景中，团队成员会主动从 Auto Mode 切换到 Bypass Permissions；这是团队的使用选择，不是产品权限模式的默认演进。若每个环节都依赖人工逐项审批，流程会很长，因此我们会先明确目标和边界，再让 Agent 持续执行。需要强调的是，Bypass Permissions 会跳过权限提示和安全检查，不能把它当作通用安全模式。按 Anthropic 当前官方说明，要达到其建议的安全边界，该模式只应在与主机、敏感数据和生产资源隔离、默认无互联网访问的容器、虚拟机或 dev container 中使用；联网、数据库结构变更、生产操作等高风险动作应退出该模式，并走权限控制或人工门禁。在这种迭代式 Agent 执行闭环（业内也称 Loop Engineering）中，我们不再把逐行审查作为默认方式，而是实行风险分级审查，并强化自动化门禁和端到端验收。开发人员也因此更多承担质量责任：把需求讲清楚，设计可验证的完成条件，再检查最终结果。过去端到端质量更多由 QA 兜底，现在开发人员必须补足测试设计能力。复杂场景还需要显式编排任务依赖、分支、并行执行和状态流转。

林香鑫：最近一年 MCP、Skills、Rules 这些概念非常火。但很多人也有疑问：这些东西只是增加了一套新工具体系，还是真正改变了 AI 和工程系统交互的方式？想请几位老师结合实践分享，这些能力在真实研发过程中解决了哪些问题？

这个问题在我们这里很有代表性。除推动 AI Coding 外，我们还在建设面向集团的 AI 能力中台，并在 AI Hub 中规划建设 Skill Hub：个人可以沉淀 Skill，也可以按治理规则发布共享，让同类场景能够复用。MCP 能以标准化方式连接既有技术资产，但协议本身并不替代认证、授权和数据治理；因此，我们还在建设 MCP Gateway 来统一控制访问边界。不同资产不能绕过网关直接互通，节点间传递还要进行敏感信息检测，避免数据在调用链路中不受控地外流。

对个人而言，以前 CLAUDE.md 容易越写越长，把约束、Rules 和执行步骤全部塞进去。Anthropic 当前建议每个 CLAUDE.md 以少于 200 行为目标；任务型流程放到 Skills，其完整内容在使用时加载；路径相关约束放到带 paths 范围的 .claude/rules/。这里的 Rules 是模型上下文中的行为指引；必须强制执行的安全限制仍要落到 permissions、Hooks 或工程门禁。分层后还要按需加载，尽量给任务保留上下文空间。长程、多轮 Agent 任务尤其需要控制上下文噪声，以降低指令漂移风险。

李渭宁： 我们现在一直在尝试解决 AI 的两个问题，一个是动态可规划性，另一个是输出的可控性。为了保证质量，我们依赖原先的整个 SDLC，包括设计评审、代码扫描、自动化测试，这个流程本身没变。有了 MCP 和 Skill、Rules 之后，就想能不能让 AI 多理解我们的上下文和内部知识，在做动态规划的时候利用现有工作流或知识。

MCP 在去年的时候，我们甚至出了一套开发规范，有 12 点的技术标准，包括权限管理、调用限制、日志审计、错误处理。但实际上用的时候卡在数据权限控制，什么数据 AI 可以消费，哪些不能，卡得非常严格，导致 MCP 跟 AI 结合的效果跟原先预计的不太一样，进度比较缓慢，目前 MCP 只能处理一些内部知识和项目 ticket。

MCP 推出不久之后就有了 Skill。原来需要把很多 API 或者系统接口转成 MCP，有了 Skill 之后就不用搞接口转化了，可以把工作流和系统 API 嵌入到 Skill 里面。很多企业也都在做 Skill Hub，全员可以分享和下载。就我们来说，目前 Skill 主要集中在开发环节，每个团队把开发规范、工作流程、自动化东西包装成 Skill 让同事复用，新同事用 Skill 能更快融入团队。这方面做得不错。但除此之外，在其他环节我还没看到 Skill 有太大影响，因为 Skill 毕竟只是一个中间环节。我们更多希望的是一个设计好的 Agent，在可控的环境下、可控的流程里面，有一个比较稳定的输出。我们期待的是这个，而不是 MCP 或者 Skill。

Rules 是因为 Skill 或者 AI 有时候发挥不稳定，不得已用 Rules 去规范它，给它边界和控制规约，让 AI 输出有一些稳定性。除此之外，我们也大量使用传统方式验证 AI 生成的质量，比如基于规则的代码扫描、基于测试案例的最终结果验证。当然 AI 也做一部分代码评审，但更多我们是希望有确定性的东西来验证 AI 生成的效果。我期待未来除了这些小组件之外，是不是可以有一些更好的东西，能让 AI 基于内部知识去做动态规划的能力更强，同时输出的稳定性有一个可期待的效果。

林香鑫： 为什么这些东西会出现，确实是因为 agent 在工作表现和结果上存在不确定性，这些东西更多是为了约束 agent 朝着确定性的结果去。传统代码扫描技术不能丢，基于规则的东西更确定，我们实践里也在寻求基于规则和基于 agent 的中间平衡。

柏佳辰： 最早是大模型本身的 tool calling（工具调用），后来发现太固定了就加了 MCP。MCP 本质上是自建的一层 tool calling 机制，好处是功能非常明确，就是为了给 agent 接触外部世界的一双手。但问题在于 MCP tools 的范式很固定，启动时所有工具一次性载入上下文，工具不能太多，多了会对大模型能力提出很高要求，出现越堆越多、性能反而越差的问题。

后来 Anthropic 提出了 Skill 机制，本质上就是 lazy loading（惰性载入），先有 metadata（元数据） 进来再按需载入。但 Skill 的 lazy loading 随着实际使用，你会发现还是会出现治理问题。因为 Skill 大家都觉得很香，都在构建大量组合包。Superpowers、G-Stack、speckit，这三件套装到 agent 里可能就小 100 个 Skill 了，就算做 lazy loading 最后还是会出现使用混淆，Skill 是缺乏治理的。

所以后面回到了比较针对性的规则。工程项目里或者说规约里，需要写清楚要做哪些、不要做哪些。本质上 Skill 是为 agent 铺路，Rules 是加上护栏。我们在客户那里发现，不同阶段有不同上下文需求，如果以单一 agent 把全流程 Skill 全灌进去，就会出现混淆和上下文爆炸问题。所以我们提出了 multi agent，给不同 agent 不同职责，前端做前端、后端做后端、需求做需求、review 做 review，把全链路 Skill 分而治之。每个 Agent 负责单独领域时质量更高、任务更明确，会自发构成调用次序和工作流，在客户落地中非常受欢迎。

林香鑫： 现在 Skills 开发成本太低了，非技术同学一天也能造十来个。这些东西经常占用上下文，叫“Token 刺客”，你都不知道它占用了你的上下文，Token 就哗啦啦花出去了。怎么应对 Token 刺客，需要随着 AI 应用深入，针对不同场景做更深度的治理。

林香鑫：AI Coding 一个明显优势是速度。但速度提升之后，也带来了新的问题。想请各位分享：AI Coding 时代，团队应该如何建立新的质量保障体系？

李渭宁： 质量体系，其实我们一直没变过。单元测试通过率、覆盖率，发布频次，P1/P2 生产事故数量，这些指标跟用什么工具不相关。AI 来了之后，我们只是在想怎么给 AI Coding 加上工程护栏，让它能符合我们一直沿用的质量体系。

主要从三方面着手。一是输入输出：需求通过 SPEC 生成代码时，我们以前写 user story 里面的 case、when、then 这些东西要继续沿用。代码规范不管用 Skill 还是 SPEC 都要描述出来，以前是人看文档，现在是让 AI 看 SPEC 去做代码生成。依赖管理也要严格，不能随便下载外部包，只能在内部仓库取，第三方组件有安全漏洞就被禁掉，要不断升级版本。二是怎么持续改进：就像 PDCA 一样，对着目标每次生成完去看差距在哪里，然后不断改进。

林香鑫：那你觉得现在 AI Coding 应用模式下，质量会出现比不上之前的情况吗？还是通过约束之后，仍然能达到原先的质量要求？

李渭宁： 质量要求是越来越高的，跟用什么工具不相关。不管用人、找外包还是用 AI，一定要达到那个指标。比如生产平均故障率有多少，发布次数有多少，不看生成多少行代码。这两个指标逐年增长之后现在趋于稳定了，跟工具本身是解绑的。只是有了 AI 之后需求变多了，怎么在需求变多的情况下依然保持较低的生产事故？所以我们把整个 SDLC 的生产流程管控得更严了，每一个地方都要有 checkpoint，过了之后才能往下一个地方走。比如单元测试覆盖率是功能开发覆盖率还是路径覆盖率，要求得很细，通过过程去管控最后的质量。

柏佳辰： AI Coding 时代来临了，每个人的平均生产力是指数级上升，但好像不太有人能拍着胸脯说工程质量也上升了。更多时候我们看到的是人突突突地往里面写了代码之后，整个工程质量变得更加糟糕了。

我们刚开始和客户交接的时候，最开始想的是两个，一个是 SDD（Spec Driven Development），一个是 TDD（Test Driven Development）。我们想的是，代码质量从最开始的纺锤形变成哑铃形。之前我们更多是把最大精力和注意力放在代码实现里边，前面的 SPEC 写作很无聊，后面的 testing 更多是为了覆盖率糊弄事。但到了 AI Coding 之后，AI Coding agent 更像是自然语言的编译器，我们更在意的是前面的 SPEC 和后边的 testing。前面的 SPEC 让人审查，后边的 testing 让 agent 去 harness。这个想法最开始是很丰满的。