从写代码到造流水线：100+ 业务 Skill 与 MCP 设计稿路由的 AI 工程化实践

一、“用 AI”和”AI 工程化”差在哪

刚开始团队也都在用 AI：谁遇到问题就开个对话，把报错贴进去问。这种用法的问题不在产出质量，而在不可复用、不可协作、不可审计：

• 同类问题每个人问一遍，提示词质量取决于个人水平；
• AI 产出直接进代码库，没有统一的风格与校验标准；
• 效果好的用法留在个人脑子里，人走了经验就没了。

AI 工程化要解决的就是这三件事：把个人经验变成团队资产，把随手生成变成标准流程，把结果质量从玄学变成可度量。落到具体载体上，就是 Skill 体系和 MCP 路由两块。

二、Skill 体系：100+ 业务场景怎么沉淀

2.1 什么样的场景值得做成 Skill

不是所有场景都值得。判断标准有三条，至少满足两条：

1. 重复出现——同类需求一个月出现两次以上（CRUD 生成、报表导出、导入导出、权限改造……）；
2. 有固定范式——产出有明确的结构或风格要求，人写会走样，AI 照着范式走不会；
3. 上下文稳定——场景的输入输出边界清楚，不需要每次大量人工补充上下文。

按这个标准筛下来，我们沉淀了 100+ Skill，覆盖了评估系统里绝大多数高频开发场景。反例是那些”看起来重复但每次业务规则都变”的需求——这类硬做成 Skill 反而要花大量精力维护提示词，不如直接对话解决。

2.2 Skill 的结构：不是提示词，是作业指导书

一个合格的 Skill 至少包含四层内容，它的形态更像 ISO 的作业指导书而不是一段提示词：

# skill: export-report
## 触发条件（何时用我）
用户要求导出 XX 报表 / 提到 Excel 导出
## 输入契约（我需要什么）
- 报表类型、字段清单（缺省从配置读取）
- 数据源服务名
## 执行步骤（怎么做）
1. 从 datasource.yaml 确认服务与表
2. 按模板 report-template.xlsx 生成列头
3. 数据量 > 1w 行走流式写出（POI SXSSF），禁止全量加载
4. 生成后自检：行数与 SQL count 一致、金额列合计正确
## 验收标准（怎么算做对了）
- 生成文件可正常打开、无样式丢失
- 与模板列头逐列比对通过
- 自检脚本 exit 0

执行步骤里的自检环节是灵魂。早期版本的 Skill 只描述”怎么做”，产出质量时好时坏；加上”做完必须自检 + 自检不通过必须修”之后，产出的稳定性才达到可交付水平。AI 会犯懒、会漏步骤，把验收标准写成机器可执行的检查，等于给流程加了一道自动化质检。

2.3 治理：Skill 也会腐烂

100+ Skill 不治理就会失控，我们定了三条规则：

• 命名与触发词统一注册，新增 Skill 必须登记触发条件和维护人，避免出现三个功能重复的”导出”Skill；
• 每个 Skill 有 owner，业务规则变更时 owner 负责更新，季度做一次失效清理；
• 错误案例回流——Skill 没覆盖到的坑，修完后回写进 Skill 的”已知陷阱”小节，让同一个坑只踩一次。

三、MCP 设计稿高还原路由

3.1 要解决的问题

评估系统页面多、设计稿改版频繁，前端还原设计稿是最耗时的环节之一。人工还原的问题是效率低、还原度看人；直接让 AI 看截图写页面，问题是布局细节（间距、层级、响应式）还原不稳，且每次都要重新描述项目约定。

3.2 路由机制的设计

MCP 的价值是把”项目上下文”和”设计稿信息”变成 AI 可稳定获取的结构化资源，而不是靠对话里贴图碰运气。我们搭的路由分四步：

设计稿（Figma/截图）→ MCP 设计稿资源
        ↓ ① 结构化提取：组件树、样式令牌、资源切图
路由层：按组件特征匹配项目内已有组件
        ↓ ② 命中已有组件 → 复用 + 填充数据（保证风格统一）
        ↓ ③ 未命中 → 按项目组件规范生成新组件
验收：④ 像素对照 + 交互自测（视口断点、hover 态、空态）

关键是②的”组件路由”：设计稿里的按钮、表单、表格先映射到项目组件库里的既有实现，AI 只负责组装和数据绑定，不负责重新发明按钮。这一条直接决定了产出的风格一致性——还原度问题的大头不是像素偏差，而是”AI 自由发挥写了个新样式”，路由层把自由发挥的空间关掉了。

3.3 效果与度量

上线后我们用三个指标度量：单页还原耗时（从人均半天降到 1 小时内）、设计走查问题数（首轮走查通过率 70% → 95%+）、组件复用率（新页面 80% 以上直接复用既有组件）。这套流程跑顺之后被组内确立为 UI/UX 标准流程——不是因为技术炫，而是因为它让”还原度”从主观印象变成了可检查的清单。

四、让团队真正用起来：三个关键决策

工具建好只是开始，推广过程里三个决策起了决定性作用：

决策一：先解决”最疼的活”，而不是最炫的活。第一批发 Skill 选的是团队抱怨最多的场景（报表导出、数据迁移、对接方联调工具），而不是技术上有趣的场景。信任是靠解决问题积累的。

决策二：产出物有验收清单才允许进主干。AI 生成的代码和人写的代码一视同仁走 code review，但 Skill 自带的验收清单让 review 的重点从”看有没有低级错误”转向”看业务规则对不对”，review 成本反而下降。

决策三：Skill 是资产，写进交接文档。人员流动是团队常态，Skill 体系让”这个需求以前怎么做的”不再依赖某个人在不在。这也是长期驻点维护的系统里特别现实的价值——系统要长期活，知识必须沉淀在系统里而不是人脑子里。

五、边界与反思

这套体系也有明确边界：业务规则模糊的需求、全新技术方向的探索、跨团队架构决策，AI 流水线的产出质量会明显下降——工程化放大的执行力，替代不了方向判断。我们踩过的坑还有 Skill 过度抽象（为了复用把 Skill 做成配置中心，结果没人会用）和对还原度的执念（个别页面花在像素对齐上的时间超过了人工）。

AI 工程化做到现在，我对它的定位是：把团队从重复劳动里解放出来的基础设施，以及把个人经验组织化的一套制度。模型能力会持续变强，但”识别重复场景 → 拆范式 → 沉淀 → 治理”这套组织能力，才是技术人可以长期积累的东西。