AI Coding企业落地实战

01

AICoding 企业落地

Q1：POC 究竟能验证什么？

ITPUB：POC 阶段可以挑选简单、干净的样本做演示，一旦推向全量生产，复杂业务、边角异常、历史脏数据全部涌现，效果可能断崖式下跌。很多企业把 POC 的成功率等同于规模化落地的能力。从实战视角看，POC 应该验证什么？哪些内容是 POC 根本验证不了、却可能决定项目生死的？

李渭宁：POC 的核心不是证明“AI 能不能写代码”，而是验证它在企业真实约束下，能否持续、稳定地产生价值。而以下几件事恰恰是 POC 验证不了、却决定项目生死的：

• 需求的工程化能力。以 SDD（规格驱动开发）为例：每个需求是否清楚定义了 Who、What、Why？验收标准是否可量化、可测试？需求本身有歧义，AI 只会更快地生成错误的结果。
• 持续质量体系。需求变化后，规格、代码、测试能否同步更新？这需要版本管理、自动化测试、安全扫描和质量门禁来保障，并把评测集（eval）纳入 CI——模型或 Prompt 一变即跑回归。POC 的短周期根本锻炼不到这套体系。
• 组织与治理。工程师是否养成复核 AI 产出的习惯？流程责任是否清晰？演示跑通靠核心人员的手工托举，规模化靠体系。

总结来说：POC 验证的是一个场景能否跑通；真正决定规模化落地的，是把需求、标准和治理机制转化为可执行、可测试、可追溯的工程体系。此外，POC 也不能只看单次演示效果，还要验证非功能项——评测通过阈值、Token 成本、权限与审计能否融入现有 SDLC。

Q2：Agent 的能力边界与权限边界如何取舍？

ITPUB：Agent 打通 Jira、代码库、测试平台后，拥有了读取需求、查看代码、生成用例甚至提交变更的能力。能力越强，风险越大。在金融强监管环境下，如何在“能力边界”和“权限边界”之间取舍？是否会为了安全主动砍掉部分诱人的能力？

李渭宁：这是规模化落地必须做的取舍：Agent 的能力边界不能由模型“能做什么”决定，而应由业务风险和治理要求决定。

基本原则是最小权限、分级授权、全程可追溯。读取需求、查询代码、生成建议，与修改代码、提交变更、操作生产环境属于不同风险等级，必须采用不同的权限策略。高风险操作不能因为技术上可以自动完成，就默认交给 Agent 自主执行，而应加入人工确认、审批流程和质量门禁。我们确实会主动砍掉部分能力——比如让 Agent 直接改生产配置、自主合并代码到主干，宁可牺牲效率也不开放。

• 账号设计：Agent 若复用员工个人账号，权限必须在 Agent 内部明确规定后再下发。这样每一次调用都能关联到具体 Agent、具体任务和具体发起人，满足金融审计“行为可归属”的要求。
• 四层安全防线：① Agent 层——权限分级与高风险操作的人工确认；② 沙箱层——Agent 的执行在隔离沙箱中进行，文件与网络访问受限；③ 网络层——网络隔离和出口管控，防止越权访问与数据外泄；④ 模型层——输入输出内容安全过滤、脱敏和幻觉防护。四层各司其职，任何一层失效仍有兜底。同时对 Agent 操作保留可回放的完整 trace，满足监管取证要求。

Q3：AI Coding 的风险增量会超过效率收益吗？

ITPUB：AI Coding 可能把错误的业务逻辑快速实现、快速上线，放大业务事故的发生速度与影响范围。内部是否评估过：风险增量是否可能超过效率收益？企业应用什么底层标尺来权衡？

李渭宁：我们对 AI Coding 的风险控制非常谨慎，但谨慎不等于不要风险，而是追求风险可控、可接受，与效率兼顾。

底层标尺是两个维度：业务复杂度 × 系统生命周期，据此把系统开发划分为四个象限，不同象限采用不同的 AI 参与深度：

表 1 四象限风险标尺与 AI 参与深度

所以风险增量和效率收益不是抽象对比，而是落到每个象限里具体衡量：AI放大的风险，必须由同象限内升级的验证手段（自动化测试、质量门禁、生产监控）来对冲。验证手段跟不上的象限，就降低AI的参与深度。

Q4：AI时代的效能评估体系

ITPUB：AI带来的效能提升很难用代码行数度量。你们建立了怎样的效能评估体系，以同时衡量效率、质量、风险和业务价值？

李渭宁：AI Coding应用于软件开发，就好比电力应用于产品制造——我们不会去度量“用了多少电”，而是看最终产出的产品怎么样。所以我们从最终交付产物出发来衡量

业界已有成熟的DevOps指标体系可以直接沿用：部署频率、变更前置时间、变更失败率、平均恢复时间（MTTR）等，天然同时覆盖效率、质量和风险三个维度，不需要为AI另造一套指标。

另外，指标只是一个数字，横向对比意义有限——各团队业务属性差异太大。我们更看重每个团队自己和自己比，看趋势是否持续改进。AI引入前后，同一个团队的部署频率、失败率、恢复时间的变化，才是真实的效能信号。

代码行数这类产出型指标我们基本不用，因为它衡量的是“生成量”而不是“价值量”。当然，AI建议采纳率、人工修改率、复核返工率这类AI专项过程指标可作为辅助信号，但始终以DORA这类产物指标为主。

02

Agent Skills：赋能SDLC全研发链路

Q5：如何防止Skill通过上线评审后“无声失效”？

ITPUB：一套Agent Skill依赖多层外部条件：MCP服务、工具接口、知识库切片、大模型基座版本、企业内部上下文数据。任意一层变化都会导致Skill行为漂移，但Skill本身代码/配置未改。如何建立持续有效性校验机制？

李渭宁：核心思路是：把Skill当作一个小App——一份版本化资产——来治理，而不是一段提示词片段。

具体做法是建立一个Skill内部市场：大家可以在上面贡献、评论和下载Skill，平台对每个Skill做自动化评估并维护排行榜。排行榜让优秀的Skill脱颖而出，用户反馈驱动持续迭代——投诉增多和评分下降，本身就是Skill“无声失效”的最早信号。

但所指出的风险确实存在且很隐蔽：Skill自身没有任何改动，却可能因为运行环境的变化而悄悄失效。因此，版本管理不能只覆盖Skill本身，还必须把模型基座版本、MCP服务、工具接口、知识库和上下文数据都视为Skill的运行时依赖，形成完整的版本基线和依赖清单——类似软件工程中的dependency lockfile。任何一层依赖变更，都应自动触发影响分析和回归验证：例如模型升级或MCP接口变更时，必须先跑通该Skill的评测集，通过后才放量上线。

由此形成两道防线的叠加：排行榜的评分趋势提供来自真实用户的持续失效感知；依赖变更触发的自动回归则在问题触达用户之前完成拦截。两者结合，基本可以实现Skill失效的“可感知、可定位”。

Q6：高风险Skill的质量评测体系

ITPUB：部分Skill参与代码风险识别、合规校验、评审意见输出、测试用例生成等高风险动作，其输出直接影响研发决策。现实中存在“理由正确但结论错误”或“理由错误碰巧结论正确”的真假阳性混杂。如何建立针对Skill本身的质量评测体系？用什么基准测试集做持续评估？

李渭宁：我们对Skill的质量评测体系和Agent的安全管控是一体设计的，概括为“四层安全管控+分级评测”。

四层安全管控：Agent层管权限分级与人工确认，沙箱层隔离执行环境，网络层做访问控制与防外泄，模型层做内容过滤、脱敏与幻觉防护。任何高风险Skill的产出都要经过这四层约束才能影响研发决策。

• 为每类Skill建立带标注的基准测试集。例如代码风险识别类Skill，用历史上真实出现过的漏洞和误报样本做基准；合规校验类Skill，用监管规则的正反案例做基准。
• 持续评估关注三个指标：准确率——结论对不对；理由一致性——结论与推理是否自洽，专门识别“碰巧对”的情况；稳定性——同一输入多次运行的结果波动。理由和结论分开评，是识别真假阳性混杂的关键。
• 评测嵌入持续流水线：Skill版本变更、依赖变更、定期（如每月）都会重跑基准集，结果回馈到内部市场的排行榜上，评测退化的Skill会被降权或下架。
• 人工抽样校准：用抽样结果反过来修订基准集，形成闭环。

Q7：多Skill编排的可观测性与审计

ITPUB：多个Skill相互调用编排形成工作流后，故障可能沿调用链传导，上游微小偏差被逐级放大。金融环境下需要什么样的可观测性？需要记录哪些链路信息，才能满足故障排查与监管审计要求？

李渭宁：先在架构上降低误差传导的概率，再谈可观测性。

• Skill设计：单一职责+有限依赖深度。Skill可以类比软件时代的功能模块，设计上坚持单一职责；需要协作时，依赖层次控制在1–2层以内。以系统开发为例：UI Skill、后台开发Skill、单元测试Skill、自动化回归测试Skill各司其职，后台开发Skill可以依赖单元测试Skill，但不再向更深层嵌套。依赖越深，链路越长，误差逐层放大的风险就越高。
• 编排方式：Agent + SubAgent分层校验。对更复杂的工作流，采用Agent + SubAgent的编排模式（与Anthropic的Orchestrator-Worker、Plan-Execute模式一致）：主Agent负责规划，SubAgent在独立上下文中执行，天然实现误差隔离。每个Agent拥有独立的上下文与输入/输出schema校验（gate）——这等价于微服务架构中的契约测试，可以有效拦截“上游漂移”，并可独立运行与测试。

之所以必须这样做，是因为误差是连乘衰减的：0.99×0.99×0.99十步之后只剩约90%，链路越长可靠性越差。用带校验的Agent边界把长链切成短段，是控制误差放大最有效的手段——错误不会无声传递，而是在最近的边界被拦截。

• 运行时防护：置信度监控与升级机制。对多步工作流，记录每一步的置信度或校验结果；一旦偏差超过预设阈值，立即中断执行并升级人工处理，避免错误继续向下游传播。
• 可观测性：可回放的完整执行记录。我们把每一次编排视为一次可回放的执行，完整记录：调用链（哪个Agent调用了哪个Skill、依赖了哪个MCP服务）；每一步的输入与输出快照；模型版本与工具版本（保证可复现性）；人工确认节点与最终决策依据。故障排查时可以逐层回放，精确定位偏差在哪一层引入；监管审计时可以完整还原“谁在什么上下文中、基于什么信息、做出了什么决策”。

03

内部开源驱动下的研发效能重构

Q8：灰度复用与风险熔断

ITPUB：内部开源会放大“错误扩散效应”：一份有隐蔽缺陷的Agent Skill被全公司大量复用，缺陷批量复制到多条业务线。是否需要类似“灰度复用、风险熔断”的机制？现实推行最大阻力是什么？

李渭宁：内部开源的核心理念是开放协同——通过内部协同共同开发新功能。而开放协同有一个重要前提：技术和质量的标准化、统一化。我们把这一理念延续到了AI Coding时代：用内部开源的方式运营Skill分享平台，并配套技术框架、API、数据库、认证、UI和自动化测试等一整套标准。正因为有这套标准化底座，即便开发人员不断流动、新feature持续增加，产品演进的速度和质量也始终守得住。

所以对“错误扩散”，我们的答案是：需要治理，而且机制是现成的。

• 灰度复用：Skill市场自带评分排行和自动化评估。新Skill先小范围试用，评分和评测达标后才放量推荐——扩散之前先过过滤层。
• 风险熔断：评测跌破阈值或出现集中投诉，即自动降权、下架。Skill定义了生命周期状态（draft / trial / certified / deprecated），只有certified状态可被生产流程引用，deprecated会自动通知消费方迁移。市场下架只是治理面，运行面同样有技术抓手——对certified Skill做调用侧健康检查，错误率突增自动告警，实现“先止血、再下架”。
• 标准即防御：复用度高本身就是双刃剑——一个坏Skill被复用得越广，影响面就越大，这正是要用灰度和熔断把住入口与出口的原因。统一的标准和评测，让问题在扩散之前就能被识别、拦截，而不是等它长距离扩散后再逐个排查。

推行中最大的阻力不在技术，而在激励。贡献方团队要多背评测、答疑和维护的成本，却没有对应的绩效认领；消费方则倾向“拿来即用”，不愿主动反馈问题。因此关键的一步是把Skill的贡献与维护纳入研发效能的绩效口径——让“维护公共资产”和“交付业务功能”一样被考核看见。这才是这套机制能长期运转的根本。

Q9：“上游提效、下游堵点”的结构性失衡

ITPUB：AI编码提升产出速度，叠加内部开源大量复用Skill，但评审、测试、合规校验的人力没有同步扩张。是否遇到过“上游提效、下游堵点”？研发效能体系应如何应对？

李渭宁：遇到过，而且我们很早就明确了一个立场：我们追求的是高质量的软件快速交付，而不是单纯的速度。

评审环节我们自己经历了三个阶段：刚开始是一个人评审，后来扩展成多人交叉评审，现在已经演进到多个Agent自动评审为主、人工把关为辅

我一直有个比喻：AI让coding这个引擎更强劲了，但评审、测试和合规校验是汽车的转向、刹车和轮胎——引擎再强，如果转向和刹车不升级，只会更快地撞墙。要想又快又安全地到达目的地，整个工程体系必须同步迭代。

我们的应对是下游同步智能化、自动化

• 评审智能化：AI预审+人工终审。AI负责规范、安全、风格类问题的初筛，人工聚焦业务逻辑和架构决策。
• 测试自动化：测试用例的设计、编写、运行更多地由AI生成和自动维护，让测试资产跟上代码的产出节奏。
• 验证体系升级：上线前的自动合规检查；上线前最后一道关走内部开源社区众测——让更大范围的真实使用者在发布前把问题暴露出来；然后小流量灰度发布，再全量上线；运行时配合实时监控和生产事故快速处理。

本质上这是一个约束理论（TOC）问题：系统的吞吐由最慢的瓶颈决定。上游提速后如果不升级下游，瓶颈只是从coding挪到了评审和验证，整体效能并没有提升。所以效能体系的正确打开方式是：持续识别当前瓶颈，把自动化和AI投到瓶颈上，循环往复——瓶颈会不断转移，但对瓶颈的持续治理本身就是效能体系的日常。

Q10：社区级技术债务的治理

ITPUB：工程师大量基于社区Skill二次开发后，技术债务从单个项目扩散为社区级技术债务，分散在公共资产和各个Fork分支中。这种债务与传统项目内技术债务有什么本质区别？治理手段要做哪些改变？

李渭宁：社区级技术债务与传统债务的本质区别有两点：

• 责任主体模糊。项目内债务有明确的owner；而散布在公共资产和各Fork中的债务，人人受影响，却无人认领。
• 清偿机制失效。项目内债务可以随迭代重构逐步消化；社区级债务则需要跨团队协调，成本高、动力弱，往往长期滞留。

我们的治理思路是：把内部开源按开放风险分为三种模式，每种模式的债务边界截然不同：

表2三种内部开放模式的债务归属

三种模式的规律是：模式越保守，债务越集中可控；模式越开放，越要事先约定债务归属。因此，传统“事后重构”的治理思路在社区级债务上不成立——必须把债务归属前置到复用协议中。

同时，我们通过Skill的分类和下载排行，让优秀的Skill脱颖而出。

04

金融的数字化转型

Q11：AI会不会成为技术债务的放大器？

ITPUB：金融存量系统架构老旧、业务逻辑盘根错节，大模型能把新功能写得很快，却看不懂几十年沉淀的遗留业务逻辑。AI Coding会不会只是放大原有技术债务？如何避免AI变成“加速负债”的放大器？

李渭宁：这个担忧非常现实，我们对老旧系统是分类施策的：

• 业务核心的老旧系统：进行升级或替换。在新的架构下，让AI结合业务文档和代码进行系统功能分析、测试案例设计，再用AI Coding加速老旧系统的升级替换——AI在这里恰恰是还债的工具，而不是负债的放大器。
• 仍需维持现状的老旧系统：AI Coding只在部分环节做“手术刀式”的改动：保持现有系统架构、技术框架、代码规范和测试标准不变。

要避免AI加速债务，关键就一句话：维持现有标准和质量门不变，升级自动化验证的手段。标准不降、门禁不撤，AI的速度红利才会转化为安全的价值；反之，如果因为AI快就放松验证，AI生成得越快，债务累积得越快。所以问题的本质从来不是AI会不会放大债务，而是门禁体系有没有跟上生成速度

Q12：MCP是解药还是又一层技术包装？

ITPUB：MCP被寄予很高期待，希望靠一套协议打通所有工具实现Agent自由编排。但金融企业内部系统错综复杂，老系统没有标准化接口。MCP是真能解决企业Agent集成难题，还是又一层技术包装？在金融真实环境下，MCP存在哪些绕不开的硬局限？

答：坦白说，我们现在的MCP集成案例并不多，主要集中在Jira、Confluence以及一些内部高频使用的工具上，并不是每个系统都做了MCP。不做全量MCP化，主要有三个现实约束：

• 权限管理机制需要完善——MCP的认证、密钥管理、数据权限粒度都还跟不上金融的要求；
• 调用频率问题——要避免Agent并发把现有系统打挂，老系统没有为高并发机器调用设计过；
• Token成本——MCP的工具定义会占用大量token，工具一多，上下文成本和选择精度都会劣化。

更深一层的原因是，Agent要在deterministic（确定性）和dynamic（动态性）之间找平衡。正因为Agent有动态规划能力，我们才要特别谨慎地处理MCP的认证与密钥管理、权限管理、数据权限和沙箱配置。像API密钥这类敏感信息，我们都放在沙箱之外，API权限沿用现有的权限管理机制，而不是交给Agent自由持有。

所以对比较确定的工作流——比如根据漏洞库分析并修复代码漏洞——我们更倾向用Agent + Skill + API集成的方式处理，确定性环节走确定性的API调用。

MCP是个好协议，但它解决的是工具接入的标准化问题，不解决权限、容量、成本这些企业级硬约束。协议是必要条件，不是充分条件。

Q13：给资源有限团队的三条忠告

ITPUB：如果只能给资源有限、预算紧张、正在推进数字化转型并计划引入AI Coding的金融科技团队三条忠告，你会给哪三条？哪些事情可以暂时放一放？

答：三条忠告归结为一句话：要做工程师，而不是程序员。工程师需要具备三种能力：洞察力、执行力、判断力。

• 洞察力。主动发现你的业务场景中哪些地方最适合AI Coding落地——无论是需求分析、系统设计，还是生产事故处理。从价值最高、风险可控的场景切入，而不是跟着工具热度走。
• 执行力。找到落地场景后，要制定方案、做PoC验证、说服相关方批准实施。AI落地是一个工程改造项目，不是装个插件那么简单，需要具备推动组织变革的能力。
• 判断力。AI Coding的执行速度很快，但如果无法判断AI做得对不对，速度反而会成为负担。因此必须在开跑之前建立质量标准、自动化测试和验证方法。判断标准先于生成速度，才能实现整体效率的提升。

最后，有几件事可以先放一放：不必急于全流程铺开Agent平台，不必急于把所有系统MCP化，也不必急于追逐最新模型。先把一个场景的“生成—验证—度量”闭环跑扎实，比铺摊子的价值大得多。建议把“每个场景先配好测试与度量再开跑”写进团队AI落地的准入清单。