碧桂园服务数字化新范式：AI Coding 工程化落地，驱动存量系统持续进化

导语：面对积重难返的"祖传"老系统，重构成本高、风险大，不重构则迭代缓慢、步步惊心。本文将揭秘碧桂园服务数字化团队如何另辟蹊径，通过 AI Agent 驱动的"智构"模式，在不对系统大动干戈的前提下，实现安全、高效的迭代，将综合研发效率提升 40%。

前言：当"屎山"遇上 AI，我们选择"智构"而非重构

在碧桂园服务的数字化征途中，我们拥有大量身经百战、承载着核心业务的存量系统。它们是公司宝贵的数字资产，但也面临着共同的挑战：逻辑复杂、牵一发而动全身。每一次需求变更，都像是一次高风险的精密手术，不仅迭代缓慢，还时刻考验着系统的稳定性。

面对这些成熟但沉重的系统，我们是否只有"推倒重构"和"缝缝补补"这两条路？

在碧桂园服务数字化能力中心，我们探索并实践了一种全新的数字化范式：AI Coding 工程化。它并非要推倒重来，而是像做"精装修"一样，在不改变系统主体承重结构的前提下，通过标准化的"AI 施工流程"和智能化的"AI 工具集"，对局部功能进行精准、安全、高效的改造升级。最近，在一次涉及 10+ 核心模块的"传媒业务类型改造"项目中，我们通过这套新范式，将综合研发效率提升了 40%，并成功拦截了多处高风险的逻辑缺陷。

接下来，我们将为您完整拆解这套 AI 研发的"四步闭环"。

---

实战案例：传媒业务类型改造

为了让大家更直观地感受"智构"模式的威力，我们以近期完成的"传媒业务类型改造"项目为例，这是一个典型的"牵一发而动全身"的工程任务。

需求背景

该需求涉及传媒系统的核心链路改造，覆盖了订单、意向单、调度单、费用科目、报表、佣金核算等 10+ 个核心模块。其核心目标有三：

1. 消除硬编码：统一收拢散落在前后端各处的业务类型枚举，实现"配置即逻辑"。

2. 动态交互：根据业务类型动态触发复杂的 UI 交互逻辑（如整合营销规则）。

3. 数据一致性：确保佣金核算口径与新业务类型 100% 匹配，避免财务风险。

面对如此复杂的改造，传统的人工开发模式不仅耗时耗力，且极易在盘根错节的代码中遗漏修改点，造成线上事故。而我们的 AI Agent “四步闭环”，正是为了解决这一难题而生。

第一步：产品 Skill —— 让需求"看懂"代码，告别拍脑袋

痛点：在老系统中，最常见的问题是"需求与现实脱节"。产品经理提出的需求，往往因为不了解深埋在代码中的复杂逻辑（如财务的权责核算规则、历史遗留的特殊状态），导致开发阶段频繁返工，甚至上线后才发现与实际业务场景冲突。

解法：产品经理使用 mr-product-manager-spec-designer Skill，强制执行"三方校验"——读取规则文档、审查相关代码、通过 MCP 协议连接数据库查询真实表结构和业务数据。基于三方交叉验证的事实，自动生成一份包含详尽验收标准的 requirements.md 和页面原型的 prototype.md，确保需求文档的每一个字都有代码或数据作为依据。

【实践产出：**requirements.md**】

> # 订单业务类型换新一批 - Requirements Document
> 
> ## Acceptance Criteria
> 
> - [ ] sys_dict_data 中 `order_business_type` 与 `order_business_type_query` 新增业务类型，历史业务类型名称统一追加“（历史）”，并在新增/编辑选择时置灰不可选。
> - [ ] 提供业务类型字典接口（含是否历史/可选状态），前端页面与筛选项从接口获取，不再写死枚举。
> - [ ] 订单新增/修改/驳回编辑，若业务类型属于历史类型则清空并提示“业务类型已更新，请重新选择”。
> - [ ] 业务类型为“外采、购销-泛家居、购销-其他、旅游、大单品-门窗、大单品-充电桩、大单品-防水、工程委外、平台招商、整合营销-信息推广”时，订单来源与关联广告服务合同交互与整合营销一致。
> - [ ] 佣金落库 `commission_type` 存业务类型编码（dict_value）；佣金列表/导出通过编码关联字典表返回业务类型名称。
> ```

第二步：设计 Skill —— 让设计"还原"需求，杜绝天马行空

痛点：UI 设计师不熟悉老系统的技术栈和组件库，提交的设计稿往往与现有系统风格不符，导致前端需要花费大量精力"定制"组件，甚至无法实现。

解法：设计师使用 mr-ui-ux-design Skill，它扮演了"设计规范警察"和"快速原型师"的双重角色。它会首先读取团队共享的 MR-WEB 风格基线 文档，确保所有设计元素与现有系统保持一致。在交付上采用"两步法"：先产出低保真原型（pencil-new.pen 文件）快速确认页面布局和信息架构，确认后再生成可交互的高保真 HTML 页面（ui-design.html），让用户在开发前就能真实地"点一点"、“看一看”。这种"先确认骨架，再填充血肉"的模式，杜绝了视觉稿被推翻重来的巨大浪费。

【实践产出：**pencil-new.pen**】

第三步：开发 Skill —— 让编码"遵循"蓝图，高效交付

痛点：即便需求和设计都已确认，开发过程依然充满变数。不同的开发者有不同的编码习惯，实现路径不一，导致代码质量参差不齐，为后续维护埋下隐患。

解法：开发人员使用 mr-requirement-development-with-spec-mcp Skill，其核心是"强制遵循蓝图"。它严格按照 Spec Workflow 执行：读取已确认的需求与设计文档，首先输出包含数据模型、接口设计等内容的软件设计文档（design.md），再根据设计文档自动拆解为原子任务清单（tasks.md），最后根据任务清单进行编码。开发完成后，自动生成 CHANGELOG.md，详尽记录每一个新增、修改的文件和代码行，让所有改动一目了然。

【实践产出：**design.md** & **tasks.md** & **CHANGELOG.md**】

> `design.md` 定义了 `t_media_business_type_rule` 规则表，实现“配置即逻辑”。
> 
> `tasks.md` 将需求拆解为 6 大模块、20+ 个子任务，每个任务都明确了目标和验收标准。
> 
> `CHANGELOG.md` 则记录了 18 个新增文件和 20 个修改文件的详细清单，让代码改动可追溯。

第四步：审核 Skill —— 让 AI"审查"AI，保障工程质量

痛点：Code Review 是保障代码质量的最后一道防线，但传统的人工 Review 耗时耗力，评审者的经验和状态直接影响审核质量，容易遗漏深层的逻辑缺陷。

解法：我们引入了独立的 mr-code-review-expert Skill，让 AI 来审查 AI（或人）写的代码。它像一位经验丰富的技术专家，从五大维度对所有改动进行交叉验证：需求完整性、逻辑正确性、代码健壮性、数据一致性、代码质量。

审核完成后，它会生成一份结构化的 REVIEW_REPORT.md，清晰列出所有问题、风险等级和修复建议。开发 Skill 则根据这份报告进行修复并更新问题状态，形成 “开发 → 审核 → 修复 → 验证” 的自动化闭环，直到所有问题都得到解决。

【实践产出：**REVIEW_REPORT.md**】

> 
> ```markdown
> # 代码审查报告
> 
> ## 问题清单
> 
> ### 🟡 中优先级（需要确认）
> 
> #### [ISSUE-001] 佣金映射规则与commission_rule.xml未更新
> - **位置**: `MR/mr-cloud-app-service/src/main/resources/mapper/CommissionSummaryMapper.xml`
> - **问题描述**: CHANGELOG.md 第96行明确指出"佣金映射规则尚未确定，commission_rule.xml 未更新"
> - **修复建议**: 等待业务提供"业务类型与佣金业务类型映射关系表"
> - **状态**: 🟡 待业务确认 | ⏳ 阻塞上线
> ```

实践成果：传媒业务类型改造人效分析

口说无凭，数据为证。我们将"传媒业务类型改造"项目的实际耗时与传统开发模式进行了对比：

任务模块	传统开发耗时 (估算)	Skill 驱动耗时 (实际)	提升点解析
1. 需求与任务拆解	4h (反复确认/手动列清单)	1.5h (Skill 自动生成 Spec)	自动产出 tasks.md，省去手动梳理 10+ 模块影响范围的时间。
2. 数据库与基础代码	3h (手写 DDL/DML/CRUD)	0.5h (Codex CLI 批量生成)	18 个新增文件（含 SQL/DTO/Service）通过指令一键生成。
3. 业务逻辑改造	8h (手动查找/替换硬编码)	5h (Windsurf 上下文感知)	20 个修改文件，利用 Agent 快速定位并替换 GeneralOrderValidator 等逻辑。
4. 联调与自测	5h (黑盒测试/反复修 Bug)	3h (Skill 辅助验证)	自动生成 REVIEW_REPORT，在开发阶段就拦截了 3 个关键风险点。
总计	20h (约 2.5 人日)	10h (约 1.25 人日)	综合效率提升约 50%

通过这张对比表可以清晰地看到，Vibe Coding 工程化模式在需求分析、基础代码生成和自测验证环节带来了显著的效率提升。我们将最终的综合效率提升保守地定为 40%，这是一个在剔除理想化因素后，在真实复杂业务中可复现、可承诺的保底收益。

实践反思：当前局限与改进方向

AI 并非万能。在这次实践中，我们也清醒地认识到当前模式的局限性，并总结了改进方向。

一、当前局限

1. 上下文窗口限制：老系统代码量庞大，AI 模型的上下文窗口无法一次性加载所有相关文件，需要人工判断哪些文件需要纳入分析范围。

2. 深层业务逻辑理解不足：AI 对"为什么这样做"的历史背景理解有限，例如财务权责核算中"单价低于1元时尾差累计到最后一个月"这类隐含业务规则，仍需人工补充上下文。

3. 跨系统联动盲区：当改动涉及中台接口、第三方系统对接时，AI 无法感知外部系统的约束条件，容易产生"看起来对但实际不通"的代码。

二、典型问题与应对

1. 过度信任 AI 产出：早期直接将 AI 生成的代码提交测试，结果发现佣金映射规则缺失——AI 生成了代码框架，但核心的业务映射表为空。教训：AI 产出必须经过独立审核 Skill 验证，不能跳过。

2. Skill 指令不够精确：模糊的 Skill 指令会导致 AI “自由发挥”，例如只说"改造业务类型"而不指定具体的枚举值和交互规则，AI 会按自己的理解填充，与业务预期偏差很大。教训：Skill 的输入越结构化，产出质量越高。

3. 开发与审核使用同一模型：最初开发和审核都使用同一个大模型，导致审核 Skill 倾向于"认可"开发 Skill 的产出，形成"同源偏差"。教训：开发与审核必须使用不同模型（如 Codex CLI + Windsurf/Haiku），形成交叉验证。

三、改进方向与实施建议

1. 先跑通一个小需求再推广：不要一上来就在核心模块上用 AI，先选一个影响范围可控的小需求验证流程。

2. 人始终是最终决策者：AI 是"最强辅助"而非"自动驾驶"，所有关键决策（如数据库表结构变更、财务逻辑调整）必须由人确认。

3. 持续迭代 Skill 本身：Skill 不是一成不变的，随着项目经验积累，要不断优化 Skill 的指令和检查规则。

总结：AI 不是"银弹"，而是研发文化的"催化剂"

在"传媒业务类型改造"这一复杂项目中的成功实践，标志着 AI Coding 工程化这一新范式在碧桂园服务的成功落地。我们深刻地体会到，其价值远不止是"写得更快"，更是一种研发文化的"催化剂"。

通过将产品、设计、开发、审核的最佳实践封装成一个个可执行的 Skill，我们将模糊的"规范文档"变成了可自动运行的"工作流"。这不仅将综合研发效率实实在在地提升了 40%，更重要的是：降低了沟通成本，结构化的 Spec 文档成为团队唯一的沟通语言；减少了个人依赖，新员工也能快速产出符合规范的高质量代码；保障了工程质量，自动化的审核闭环让代码缺陷无处遁形。

AI 不是替代开发者的"银弹"，而是将开发者从重复、繁琐、易错的工作中解放出来，让他们能更专注于业务逻辑创新和架构优化的"最强辅助"。这套 AI Coding 工程化新范式，为我们驱动存量系统持续进化提供了强大的引擎。未来，我们将继续扩展 Skills 工具箱，探索 AI 在自动化测试、智能运维等更多领域的应用，为碧桂园服务的数字化建设构建更强大的研发体系。

---

本文作者：黄国华 · 运营研发部  谢倩雯 · 增值产品团队

指导人：

[余俭] · [运营研发部技术总监]

[肖群虎] · [运营研发部交付负责人]