块状精修法
AI 辅助设计还原的核心迭代方法论：一次只改一个区域、一次只解决一种问题，通过分块逐段验收控制 AI 输出质量
简介
块状精修法是作者在用 Cursor + MasterGo MCP + Codex 还原后台 Dashboard 设计稿过程中总结出的实战方法论。核心原则是：不要让 AI 一次性优化整个页面，而是把页面拆成独立区块，逐块精修、逐段验收、逐步存档。 这个方法论的发现源于一个关键教训——AI 最怕的指令就是”请把整体再优化一下”，因为这种模糊指令会让 AI 把能动的地方都动一遍，导致”改好头部底部又乱、导航修好卡片又跑偏”的连锁崩溃。
关键信息
- 类型：方法论
- 领域：AI 辅助设计、Design-to-Code、前端开发
- 核心问题：AI 在整体优化时容易引发连锁破坏
- 解决思路：拆分问题域，缩小每次修改的范围
- 适用场景：AI 辅助页面还原、AI 代码迭代、复杂 UI 精修
核心特性
方法论三原则
原则一：一次只改一个区域
- 明确指定当前只修哪个区块（如”现在只修顶部导航”）
- 其他区域完全不动，改对 → 验收 → 存档后再进入下一个区域
- 避免”牵一发而动全身”的连锁破坏
原则二：一次只解决一种问题
- 每轮迭代只聚焦一类问题：标题层级、间距高度、图片路径、颜色色值等
- 不要在一个指令里混合多种修改需求
- 问题拆清楚了，AI 才开始真正变得好用
原则三：骨架优先于样式
- 还原顺序：先修骨架 → 再修模块关系 → 再修模块细节 → 最后整体检查
- 如果页面骨架错了（如布局方式不对），细节再美也是”无效化妆”
- 骨架正确后，细节修改才有意义
与真实项目管理的类比
块状精修法本质上是把真实项目中的设计评审逻辑应用到 AI 协作中：
- 设计评审中最怕的不是”标题换个字体""色调再柔一点”这类具体修改
- 最怕的是”不够高端大气，说不上来哪里不对，你再出 10 版”——这种模糊反馈对人和 AI 都是灾难
- 给 AI 的指令越具体、范围越小、目标越明确，输出质量越高
典型迭代节奏
第 1 轮：整体骨架（快速铺满，不追求完美）
第 2 轮：骨架修正（布局方式、模块关系）
第 3 轮：区域精修 — 头部导航
第 4 轮：区域精修 — 统计卡片（拆散资源、SVG icon、代码文字）
第 5 轮：区域精修 — 图表区域
第 N 轮：整体检查（微调间距、色值一致性）
每轮完成后 git commit 存档，确保可回退。
搭配工具链
块状精修法不是独立存在的，它需要配合以下工具链才能生效：
- MasterGo MCP：提供设计稿的精确参数，减少 AI “猜”参数的环节
- 本地参考截图：提供视觉直觉，与 MCP 互补
- Git 版本控制：每轮迭代后存档，AI 改崩时可回退
- Cursor / Codex：实际执行修改的 AI 工具
不同素材中的观点
- 2026-05-28-woshipm-ai-design-restoration-block-refinement：本文提出并详细论证了块状精修法。核心案例是还原后台 Dashboard 的 6 个统计卡片——看起来像”只是几张卡片”，实则叠加了文字+图标+装饰背景+数据。作者踩了三个坑：① 文字和图标一起切图导致缩放失真；② 背景图位置”乱跑”因为 AI 理解不了装饰图该往哪摆；③ 替换资源后页面没刷新。三个坑的共同解法就是”拆散实现”——文字用代码写、icon 切 SVG、背景单独切图、给出明确数值。作者将这个经验抽象为”块状精修法”，并用设计评审类比说明：模糊指令对人和 AI 都是灾难，具体指令才能产出好结果。
实用信息
- 适用场景：AI 辅助页面还原、AI 代码迭代、复杂 UI 精修、任何需要 AI 多轮迭代的精细任务
- 不适用场景：一次性生成概念验证原型（POC）、不需要还原精度的快速探索
- 核心技巧：
- 像严厉的监工，指着一个块对 AI 说”就改这里，别动其他的”
- 高度、间距、颜色等数值直接作为指令发送，越具体修改越准
- 资源替换时明确告诉 AI “替换哪张图片”，避免 AI 没有真正替换到位
- 每个区块改对后立即 git commit，防止后续迭代破坏已完成的工作