生码率冲到 30%，交付却没提前：福建企业上 AI 编码前先算清这 7% 的账
一、先说结论
11 月 9 日，InfoQ 刊出阿里云智能集团副总裁、CIO 蒋林泉的三年 AI 实践复盘（厂商高管自述，媒体口径）。最扎心的不是"提效多少倍"：2024 年底全员用上 AI 编码工具，生码率很快上到 30% 多，端到端交付一个需求所消耗的人力没有变化。
对福建正给研发、IT 部门配 AI 编码助手的中小企业，三条结论：
- 工具上了，不等于项目提前交付。 真正写代码只占需求全周期约 20%（官方披露/媒体口径）。
- 理论上限只有 7%。 20% × 35% ≈ 7%，即便 AI 把最易生成的代码耗时压到零、其他环节不动，端到端最多省 7%，还是理论值；业界实际提效约 3%~5%（媒体口径）。
- 不改流程和组织，可能越用越慢。 骨干被 AI 批量产出的代码"像被 DDoS 了一样"，Review 和线上责任全压在少数人身上，全链路更堵。
不是工具不行，是账算错了。要补的不是更强的模型，而是需求、测试、口径、权限这四张表。
二、这次到底变了什么
变化不在模型，在"效率该在哪儿量"。该团队把一个需求从提出到上线拆开（官方披露/媒体口径）：
| 环节 | 占端到端耗时 | AI 能帮多少 |
|---|---|---|
| 需求设计、评审和修改 | 约 20% | 有限，靠人对齐 |
| 交互视觉设计、评审和修改 | 约 10% | 部分 |
| 技术方案设计和评审 | 约 15% | 有限 |
| 编码开发 | 约 20% | 最显眼，但只占 1/5 |
| 前后端联调和集成 | 约 15% | 受存量系统制约 |
| 测试和 Bugfix | 约 20% | 写测试、补 Case 是强项 |
再拆那 20%：要动存量核心系统、和老系统融合的核心代码，量不大却吃掉 65% 以上编码时间，恰是 AI 帮助最有限的部分；增删改查、前端 UI、测试代码占了大部分代码量，只消耗不到 35% 编码时间（官方披露/媒体口径）。于是 20% × 35% ≈ 7%：AI 最容易生成的代码，原本就没花多少时间。
其余口径同属该厂商三年复盘，别直接套用：2024.12–2026.3 交付效率约 2~3 倍、"人月"降到 1/2~1/3（建立在组织改造之上）。做汇报尤其别把"通用智能体调用量 4 个月增长 1000 倍"当成效——原文明确说，调用量不等于业务效能。
三、福建企业真正能用在哪
结合本地以制造、鞋服、外贸、水产食品、跨境电商为主，普遍"老系统 + 少量 IT 人员"的现实：
- ERP、进销存、MES 二次开发排期。 定制需求多卡在"要动存量核心系统"，正对应那 65% 的硬骨头。AI 生成外围页面、报表确实快，但别据此把工期压缩三成，先按 7% 上限重排。
- 需求评审从 PRD 改成 Live Demo。 业务方和 IT 常在"这不是我要的"上返工。原文两条规矩可照搬：评审一律用可操作原型；测试和可观测由研发在左侧完成。一页纸 PR/FAQ（目标客户、真实问题、预期结果）能挡掉低价值需求。
- "客户"口径统一。 销售系统里客户是联系人、财务里是付款主体、服务里是使用者、报表里是统计口径，多套系统并存必然撞上。做 BI、AI 问数前先定"概念字典"，否则 AI 会"看到同一概念有两种说法就乱猜，甚至编出第三个"。
- 别让智能体用浏览器硬爬业务系统。 原文列四个现象：成功率低、Token 消耗大、DDoS 式负载（并发重试打爆系统）、数据流向与审计难统一。IT 只有两三人的企业，让智能体去"点"ERP 页面比补接口更危险。
- 开放系统前先补权限和审计。 原文强调"开放平台 4A"（账号、认证、授权、审计），智能体代办必须沿用员工原有权限——"100% 能力开放，不等于突破员工自身的权限边界"。做过等保、有客户数据的企业尤其关键。
四、可照做的四步
第一步：量一次自己的耗时结构。 挑最近 3~5 个已上线需求，按上表六环节估工时占比，算出自己的"编码占比 × 常规代码占比"。别直接套厂商的 20%、35%，那是别人的账；半天就能做完，不花钱。
第二步：测试和观测左移。 写测试、补 Case、做日志和 Tracing 是 AI 强项（原文称这类任务效率可提升十倍甚至百倍，官方披露/媒体口径）。让改代码的人自己写测试、自己看线上结果，比追"生码率"实在。
第三步：立两张表——概念字典与接口契约。 把跨系统高频概念（客户、订单、SKU、单据状态）写清定义与口径，落到 API 契约和数据结构；前端或外包用 Mock API、Mock Data 做 Demo，演示前先"握手"，落地前再真实联调。这是后续所有 AI 接入的地基。
第四步：高频先行，再谈全量开放。 原文节奏三步：先覆盖 80% 高频场景，再补齐重点专项领域能力，最后迈向 100% 业务系统开放（官方披露/媒体口径，该团队 2026 年 5 月正式向内部通用智能体开放）。缩成一句：先选 2~3 个高频、可度量、数据干净的场景跑通。
另加一道闸：上线前用 PR/FAQ 说清目标客户、真实问题、预期结果，说不清如何验证就不上；上线后看渗透率、做回访，没人用就承认失败。
五、三个坑
坑一：把局部指标当全局指标。 生码率、Token 用量、调用量都是"局部更快"，原文反复讲"局部更快、整体不快"。立项 KPI 直接写端到端交付周期或业务渗透率。
坑二：绕过治理直接开接口。 原文有个场景：某产品商业化配置原要两个月，但"直接交给 Agent 可能永远也配不好，因为它会把混乱加剧"。正确顺序自下而上四层——主数据层、业务语义层、MCP 接口层（只暴露受治理的语义）、Agent 层；治理做完，一个 Skill 大致半天到一天（原文口径，"60 倍提效"不能脱离治理单独归因于 AI）。跳过前两层，只会叠加错误规模化、信任透支、反馈回路被污染。
坑三：以为系统开放了 IT 就没事了。 原文把智能体接入后炸出的历史欠债归为三类：流程缺口（关键作业仍在线下）、数据缺口（分散在不同系统、标识口径不一）、规则缺口（判断靠个人经验，没沉淀成可复用规则）。这些不是 AI 带来的，但会被一次性引爆。常见情形：业务来要"给某某系统开个智能体"，排查发现流程根本没上线。
六、什么时候上、什么时候别上
可以上： 需求清晰、重复执行的语言类知识任务（文档翻译、报表说明、客服话术、单据初筛）；数据已线上化且口径统一；有渗透率、准确率可度量回访；有能拍板的架构负责人守"概念完整性"。
先别上： 存量核心系统概念混乱、主数据没治理；关键流程还在线下；权限与审计日志不健全；没人能承担 Review 和线上责任；或纯粹为"减人而提效"——原文说得很直白："如果一个组织，有价值的事情已经饱和，再提效就失去意义。"
AI 把"做出来"变便宜了，把"判断该做什么"变贵了——福建企业先把概念、流程、权限这三张表补齐，再谈让智能体进系统，才不算白忙一场。
（事实与数据引自 InfoQ 2026-11-09《Agent 越用越多，企业为何仍不够 AI Native？》，属厂商高管复盘与媒体口径，仅作方法参考。）