深度实践：Spec-Coding，AI 独立完成复杂 UI 开发的可行性方案

核心协作流程图

graph TD %% 阶段 0: 启动与深度探测 Start[输入原型 URL / 新页面需求] --> HookB_Probe[激活 Hook B: 视觉协议桥接] subgraph MCP_Layer [MCP 感知层: AI 的五感] MCP_Nav[navigate_page: 访问原型] MCP_Snap[take_snapshot: DOM 审计] MCP_Shot[take_screenshot: 视觉采样] end HookB_Probe --> MCP_Nav MCP_Nav --> MCP_Snap MCP_Snap --> MCP_Shot %% 阶段 1: Spec 生成与动态校准 MCP_Shot --> Spec_Gen[生成结构化 Spec & Task.md] subgraph Dynamic_Alignment [动态校准闭环] Spec_Gen -->|循环采样探测| MCP_Snap MCP_Snap -->|特征反馈| Spec_Gen end %% 阶段 2: 规则注入 Spec_Gen --> Rules_Layer[Rules 注入: AI 驱动 UI 实现严格规范] subgraph Core_Rules [核心底线约束] R1[组件映射: FuncTable/DyForm] R2[视觉规范: Dark Mode/禁绿令] R3[架构模式: MVC 分离/i18n] end Rules_Layer -.-> R1 & R2 & R3 R1 & R2 & R3 -.->|微调任务细则| Spec_Gen %% 阶段 3: 增量任务执行 Spec_Gen --> Task_Anchor[配置环境锚点: 双网址锁定] Task_Anchor --> Task_Exec[原子任务执行: 阶段 1-4] %% 阶段 4: 执行中的 Hook 校验 subgraph Task_Hook [任务执行 UI Hook 闭环] T_Before[执行前: MCP 记录状态] T_Code[生成并应用代码] T_After[执行后: MCP 截图对比] T_Before --> T_Code --> T_After end Task_Exec --> T_Before T_After -->|存在偏差| T_Code T_After -->|校验一致| Delivery[高质量交付 & 代码合并] %% 样式定义 style MCP_Layer fill:#e1f5fe,stroke:#01579b style Core_Rules fill:#fff3e0,stroke:#e65100 style Task_Hook fill:#f3e5f5,stroke:#4a148c style Dynamic_Alignment stroke-dasharray: 5 5

一、为什么 Spec 实践是 AI 开发质量的终极保证？

在 AI 开发的早期，我们往往追求"一句话生成页面"。但回到真实的业务场景，这种方式产出的代码几乎不可用。AI 会产生严重的幻觉，或者为了追求视觉一致性而进行无意义的过度设计。

通过 Spec-Coding (规范驱动) 协议的实践，我们并不是在寻找一种"最聪明"的模型，而是构建一套质量与效率的确定性底线：

消除幻觉约束：Spec 为 AI 提供了清晰的操作边界，防止其随意引入非标库、手写原生 HTML 或滥用内联样式。
解决逻辑断层：通过预定义的架构协议，确保 AI 生成的代码逻辑自洽，而非一堆无法运行的 UI 占位符。
规模化交付的共性：当团队所有 AI 开发都遵循同一套 Spec，产出的代码在可维护性和一致性上能达到高度统一，避免了"千人千面"的代码污染。

二、核心架构：Rules, Hook & MCP 的协同链路

该方案的可行性核心在于将"人眼识别的规范"转化为"机器执行的自动化指令"。我们建立了一份**《AI 驱动：UI 实现与任务执行严格规范》**作为核心指导文档。其底层逻辑如下：

1. 协作流程图

graph TD A[原型输入 URL/链接] --> B{是否有 Figma 设计稿?} B -- 无 Figma / 只有原型 --> C[激活 Hook B: 深度探测] B -- 有 Figma --> D[DLS 变量映射 & 截图还原] C --> E[MCP Chrome DevTools] E --> F[核心意图识别] F --> G[生成结构化 Spec & Task.md] G -.->|不断调用 MCP 采样校验| E G --> H[Rules 约束注入: UI 实现严格规范] H -.->|根据规范微调任务细则| G H --> I[原子任务执行] I --> J[Hook A: 合规性自检] J --> K[MCP 循环校验] K -- 视觉/代码偏差 --> I K -- 校验通过 --> L[高质量交付]

2. 三大支柱的职责分工

Rules (规则层) ：以《AI 驱动：UI 实现与任务执行严格规范》为准则，定义了视觉底线、组件映射规则（如强制复用标准表格/表单组件）以及架构模式（如 MVC 分离），确保 AI 输出不偏离团队基建。
Hook (钩子层) ：作为"拦截器"，在代码写入前校验组件复用、样式原子化及请求模式，并负责从视觉信号到开发任务的翻译。
MCP (能力层) ：赋予 AI "五感"。通过 Chrome DevTools MCP，让 AI 能够实时感知浏览器真实的运行环境，解决"盲目编码"带来的视觉与逻辑偏差。

三、深度实践中的难点与破解之道

在跑通这一链路的过程中，我们重点攻克了几个令开发者头疼的工程难题：

1. 解决 UI 还原与组件抽象的冲突

难点：AI 倾向于通过堆砌 CSS 实现像素级还原，这往往导致嵌套极深、难以维护。
解决：利用 MCP 视觉审计，将页面拆解为组件树。AI 必须先确认布局重心，再应用 Rules 进行组件映射。这意味着 AI 会优先思考"这里该用哪个公共组件"，而不是"这里该写哪个 CSS 属性"。

2. 规避代码不可用与逻辑空洞

难点：生成的代码往往缺失 Loading、Error 处理或 API 链路不通。
解决：实施 "环境锚点"强制化。在 Task 顶部锁定预览地址，AI 在生成每一阶段逻辑后，必须通过 MCP 回访页面验证交互是否闭环，而非一次性"盲写"到底。

3. 处理"只有原型，没有设计稿"的极端情况

这是最能体现方案可行性的场景。当手中只有一个运行中的 Web 原型 URL 时，通过 Hook B 驱动 MCP 探测，AI 能自动提取 DOM 结构和交互链路，生成高度还原的 Spec。这在老旧项目重构或竞品分析场景下极大地降低了 UI 逆向工程的成本。

四、两种实践路径的体验总结

场景 A：无 Figma，只有 Web 原型 (对齐模式)

在这种场景下，我们通过 Chrome DevTools MCP 强行补齐了信息差。AI 通过"观察"原型的 Spacing 节奏和交互反馈，实现了高保真的代码重构。虽然过程涉及多轮 Hook 校验，但产出的代码健壮性远超人工手动临摹。

场景 B：基于 Figma (MCP 驱动模式)

当拥有 Figma 时，通过Figma MCP 的DLS (Design Language System) 变量 与截图，还原度可直接达到 95% 以上。此时 AI 的工作重心不再是像素，而是转向 Rules 合规性，重点确保 API 请求模式、控制器逻辑完全符合团队的工程标准。

五、总结：AI 开发的本质是协议的胜利

通过本次实践，我们发现：如果说大模型的能力决定了生成的上限，那么严密的协议则决定了交付的下限。协议的作用，是让 AI 在处理复杂业务时，从随机的灵感闪现 转化为稳定的工程输出。

折腾完这一整套体系后，最直观的感受是：AI 编程终于从'抽卡撞运气'变成了'照方抓药'。当模型能力（智商）足够强时，这套 Spec 就像是一条工业传送带，把 AI 那些天马行空的幻觉收拢进工程规范里。毕竟对我们业务开发来说，一个听话、稳定、不乱写代码的 AI，远比一个偶尔能写出'神来之笔'但大多时候在挖坑的 AI 要靠谱得多