让编程智能体加功能时遵守现有设计

让 AI 给发票列表加个筛选条件，结果它顺手换了按钮形状、字号和强调色。功能做出来了，页面却像另一个产品。原文讨论的就是这种越界：普通功能需求，什么时候成了重新设计界面的许可？

作者给出的办法很具体：先确认项目已有的视觉系统，再决定复用什么、补充什么。这是 Design Decision Method（DDM）六步流程中的第 2 步。它值得借鉴的地方，是把「保持风格一致」变成了可以检查的开发约束。

加功能之前，先让 AI 认清项目用的是什么

原文的起点是：项目已有合适的设计系统，就保留并扩展它；没有，才按平台选择。

这里的「设计系统」不只是配色。它还包括设计令牌（tokens）、组件、字号层级、交互状态，以及项目实际支持的版本。设计令牌可以理解为界面样式的统一命名，例如某个颜色承担什么角色，而不是每个页面各写一个色值。

因此，让 AI 看一眼截图，再仿照着写，仍然不够。截图能展示按钮长什么样，却未必告诉它禁用状态如何处理、组件有哪些配置、项目安装的版本支持什么。

作者引用的检查材料包括 tokens、组件、截图和已安装依赖。这些都是调查线索，需要结合起来理解项目已经作出的视觉选择。

普通功能需求，不应被自动理解为重新设计的授权。

这条规则并不排斥改版。如果需求明确要求更换方向，就应先评估可访问性、平台限制、迁移范围，以及与现有系统的冲突，再决定怎么实施。

发票筛选案例的价值，在于给评审留下依据

作者用 example.com 上的一个小型发票产品举例：产品已有内部组件库、命名明确的颜色角色和字号规范，现在需要增加「查看未付款发票」的筛选功能。

这不是实测案例。作者明确说明，产品细节和示例说明都是虚构的，没有效果数据。

但这个例子提供了一种可直接借鉴的开工说明：

• 继续使用产品内部的设计系统，因为需求增加的是筛选能力。
• 复用现有按钮、选择器、文本样式和颜色角色，并检查它们的定义及支持状态。
• 交互需要支持选择发票状态和清除筛选；借鉴外部方案时，把行为适配到现有组件。
• 如果组件库缺少必要状态，明确指出缺口，并提出扩展方案。

最后一条尤其有用。组件库不完整时，AI 需要有一个明确出口，否则它可能为了完成当前页面，悄悄创建另一套按钮。

有了这份说明，评审就能检查实现有没有兑现约定：是否调用了现有组件？新增样式是在补足能力，还是未经解释地替换了旧规范？

一张漂亮截图回答不了这些问题。

借用筛选交互，不必连别人的品牌一起搬来

原文把两个容易混在一起的决定拆开了：选择视觉系统，以及借用交互模式。

例如，某个外部筛选方案能更好地组织选项，可以参考它的操作逻辑。但采用这种逻辑，不要求同时采用它的颜色、字体和品牌表达。

对程序员来说，这个区分很实用。研究参考页面时，应该先说明它解决了什么操作问题，再考虑如何用项目已有的组件表达出来。参考对象提供的是行为思路，视觉呈现仍然需要遵循当前产品的约定。

如果项目确实没有设计系统，DDM 才进入平台选择。针对没有现成系统的其他 Web 或跨平台工作，流程把 Material 3 列为兜底，并要求检查实现支持情况。

这个条件不能省略。它既不是设计系统排行榜，也不是要求已有项目迁移到 Material 3。原文还承认有文档支撑的定制设计或编辑式视觉方向，具体应采用哪一种，要看项目适用条件和技术栈支持。

我的判断

我认同它把视觉选择提前的做法。AI 编程里，「沿用现有风格」太抽象；要求它明确组件来源、样式定义和缺失状态，才有机会在代码评审时核对。

但这仍是一套经验性流程。原文没有提供对照实验，无法据此判断它能减少多少返工，也无法证明它比一份写得清楚的项目规范更有效。

它成立还有一个前提：现有系统足够合适，而且能被识别。如果组件库长期失修、同一功能已有多种样式，单纯要求「保留现状」并不能消除歧义。原文要求保留的是「合适的」系统，却没有展开说明复杂项目里如何判断这个条件。

相比只靠截图模仿，这套流程能暴露更多实现约束；相比直接指定一个成熟组件库，它更尊重已有产品的积累。不过，流程仍需靠实际检查执行，写一段「我会复用组件」的承诺并不等于完成了复用。

DDM 采用开放的 Agent Skills 格式，使用 MIT 许可，README 记录了 Claude Code、Cursor、Gemini CLI 和 Codex 的安装方式。接入形式是入口，真正有价值的是让设计决定变得可核查。

能拿来做什么

• 下次让 AI 修改现有前端页面时，要求它先列出识别到的设计系统、准备复用的组件，以及尚未确认的定义或版本，再开始提出新样式。
• 给功能需求补上交互边界，例如筛选必须支持哪些选项、如何清除条件，让 AI 围绕具体操作选择组件。
• 评审 AI 生成的界面时，除了看截图，也检查组件来源和新增样式的理由；发现组件库缺口，就要求它提出明确的扩展方案。
• 在没有设计系统的项目里，可以参考 DDM 的平台选择规则，但采用 Material 3 前，先确认当前技术栈具备所需的实现支持。