这两年，AI Coding 工具已从“尝鲜”阶段迈入“标配”行列。 Cursor、Claude Code、CodeX 几乎成为研发团队的核心工具组合。团队中“未使用过 AI Coding 工具”的工程师，反而成了少数。 观察发现，一个有趣的矛盾出现了：单个程序员的产出效率明显提升，但整个 APP 的迭代节奏几乎未变。大家反馈高度一致——AI Coding 的渗透率提升了，但需求吞吐量仅增长 10%-20%；发版周期、参与团队数量、跨部门评审量等指标基本没有变化。 直观感受是：过去一名工程师每天写 200 行有效代码，现在能写到 400-500 行。然而，整个团队从“接到需求”到“功能上线”的周期几乎未缩短。 ## 二、AI 写新项目可以，写大型系统不行 AI Coding 真正擅长的场景包括：新项目、编写 Demo、单一职责模块、补充单元测试、生成脚手架、编写迁移脚本。在这些场景中，AI 几乎能覆盖初级工程师 60%-80% 的工作量。 但若让它修改一个拥有五年历史的金融 APP 登录流程，通常第一次对话还能用，第二次就开始“失忆”： - **上下文丢失**：修改到第二个文件时，AI 已忘记第一个文件的命名约定；修改到第三个文件时，业务领域术语开始漂移。 - **跨层影响盲区**：修改了登录入口的一个参数校验，AI 无法预知这会影响下游的用户画像、风控反欺诈、合规审计三个系统的数据流。 - **灰度/回滚/兼容性判断缺位**：能否灰度发布？是否需要双写？老版本是否需保持兼容？这些判断 AI 无法给出，因为它缺乏“历史事故知识”。 - **审计不友好**：AI 编写的代码往往“能跑但难解释”，PR 评审时反复被挑战，拖慢了合版节奏。 这也解释了为何许多团队的 AI Coding 实际上被“圈养”在脚手架、单元测试、接口文档生成等局部任务中。目前 AI Coding 的价值仍停留在“帮单个程序员提效”层面；要想让 AI 帮助整个团队提效，还需对复杂 APP 进行解耦优化。

三、为什么复杂的 APP 难以通过 AI 整体加速

**架构层：模块耦合太重，AI 修改吃力。** 存量 APP 多为单体或模块化单体，模块间的边界在文档中清晰，在代码中却模糊。AI 修改一处就会牵动全身——改一个按钮样式，可能需要重新跑一遍主流程回归；改一个字段，需协调前端、后端、数据、监控四个团队的代码合并。AI 无法判断哪些改动是“局部”的、哪些是“全 APP”的，只能逐文件阅读、逐函数修改，缺乏对架构边界的整体判断。 **流程层：协作关节太多，AI 再快也跑不起来。** 一次发版通常需要 5-8 个团队签字——需求评审、UI 走查、合版测试、灰度审批、安全 review、运营对接——任何一个环节卡住，整个节奏就卡住。这些流程并非因“程序员写代码慢”而存在，而是因“改动的影响面不可控”而存在。AI 加快了单个程序员的产出，但合版、回归、灰度等“协作工序”的瓶颈并未改变。 **治理层：权限、审计、隔离都按 APP 维度进行，AI 写出的新能力要先过“老城门”。** 权限开通要走 OA、合规审计需补材料、数据隔离需走安全 review——所有这些流程均按“全 APP 安全”设计，不会因某个新能力是 AI 编写、由业务人员提出，就降低标准。结果就是：AI Coding 让单个功能的开发时间从一周压缩到三天，但治理流程依然需要两周。 在 APP 中增加一个新功能，治理难度往往大于技术难度。 ## 四、将 APP 拆成“宿主+小程序”，让 AI Coding 真正发挥效能 一种在金融、零售、出行多个行业中被验证的做法，是将过去耦合的 APP 拆分为“宿主 APP + N 个独立小程序 + 管理平台”的三层结构。 把交付颗粒变小，把治理颗粒也变小——AI Coding 才能从个人层面走向团队层面。 - **宿主 APP（壳）**：负责启动、路由、容器、用户体系、基础 SDK、登录、推送、监控等“底盘”能力。宿主保持精简，自身不再承载具体业务功能，迭代频率按季度或半年计算。 - **小程序（业务能力）**：每个小程序对应一个独立业务能力，例如“ETF 专区”“信用卡还款”“保险理赔”“直播购物”。每个小程序拥有独立仓库、独立开发节奏、独立测试用例、独立上下架机制，迭代频率按周计算。 - **小程序管理平台（中台）**：负责小程序的注册、审核、灰度发布、版本管理、上下架、权限矩阵、运营统计、审计留痕。这是整个架构的治理中心，所有跨小程序的治理动作均在此收口。 宿主不关心业务，业务不关心底盘，平台将治理和编排统一管理。宿主好比商场，小程序是入驻的店铺，管理平台则是商场物业。店铺自行决定卖什么、如何装修，商场负责消防、安保、统一收银。 ### 为什么 AI Coding 在新结构下变得更强 AI Coding 变强，关键在于颗粒变小。颗粒小，AI 才能跟得上。 每个小程序控制在 5-50 个文件、单一职责、独立仓库，AI Coding 工具的上下文窗口足够使用，跨文件推断的成本被压到最低。**业务人员描述需求 → AI 生成 → 业务验收**，这条链路便可顺畅运行。 更进一步，AI Coding 在新结构下还能完成几件过去在大 APP 中难以做到的事： - **自动生成测试用例**：每个小程序有明确边界，AI 可基于接口契约自动生成覆盖正常/异常/边界的测试用例。 - **自动生成宿主 API 适配层**：AI 根据权限矩阵自动生成调用宿主能力的封装代码，业务无需关心底层协议。 - **自动检查权限声明完整性**：AI 扫描小程序代码，自动识别其实际使用了哪些宿主能力、是否在权限矩阵中声明完整，缺失部分自动补充。 - **自动根据运营数据建议灰度比例**：AI 根据历史相似小程序的发布数据，建议当前灰度比例和观察指标。 这些事过去需要人工编写脚本、制定规范、定期 review，现在可以让 AI 直接嵌入 CI 流水线——AI Coding 不仅编写代码，也开始参与治理。 ### 业务自助的边界 让业务人员自行编写代码、自行发布功能，听上去很美好，但前提是“可控自助”——而且并非所有功能都适合拆成小程序。 适合拆成小程序的功能具有以下特点： - 业务边界清晰，可独立交付、独立验收。 - 数据和权限的依赖相对简单，不涉及核心账务、风控、合规。 - 迭代频率高（周/月级别），不适合塞进季度发版节奏。 - 失败影响可控：出现问题可快速下架，不会直接导致监管事件。 以下功能不适合拆分： - 涉及核心交易、支付、清算等关键环节（拆分后治理成本远大于收益）。 - 涉及客户资金、隐私数据的核心模块（监管要求高，自助发布风险大）。 - 与宿主深度耦合、改动会影响其他业务的能力（拆分等于返工）。

五、沙箱与安全：把“业务自助”做成“可控自助”

业务自助开发、自助上下架听起来效率极高，但背后仍需做好强约束： - **沙箱隔离**：防止“程序 bug / 攻击扩散”。每个小程序的 JS 引擎、内存、网络、文件、API 调用均与宿主及其他小程序隔离。一个小程序崩溃、跑飞、被攻击，不会波及宿主和其他小程序。隔离的实现细节可以是双进程、双 WebView、双 JS 引擎，但核心思路只有一个：让每个小程序在“自己的房间”内运行。 - **权限矩阵**：防止“超范围调用”。每个小程序在管理平台上声明自己需要哪些宿主能力（用户信息、支付、定位、推送等），宿主按白名单调用，未声明的能力一律禁止访问。这相当于给每个房间安装了门禁：能进入哪些门，权限矩阵说了算；强行开启未登记的门，沙箱直接拦截。 - **审计与回收**：防止“出了事找不到人 / 收不了场”。每一次上下架、每一次 API 调用、每一次数据访问均留痕；出现问题时，平台可一键下架某个小程序，将损失控制在最小范围。这相当于每个房间安装了监控和应急按钮：行为可追溯，风险可熔断。 三道防线共同保障“业务可以自助”与“自助不等于放纵”同时成立。 ## 六、收尾：杠杆点不在 AI，而在解耦 AI Coding 能降低 APP 维护成本的程度如下： - **新功能上线周期**：从“季度/月度”压缩到“周/天”。 - **一次发版涉及团队数**：从 5-8 个减少到 1-2 个。 - **跨部门协作沟通成本**：下降一个档次（具体幅度因企业而异）。 - **业务自助发布占比**：从 0 提升到 30%-50%（金融、零售、出行行业的成熟实践区间）。 AI Coding 工具还会不断变化形态，但对 APP 进行解耦优化，沉淀下来的将是企业自身可治理、可扩展的架构体系。