设计审计即编排：claude-mem `design-is` 技能如何用 Dieter Rams 十原则产出证据化打分与 `/make-plan` 交接

在 claude-mem 的 agent 技能体系中，design-is 是一个专门面向 UI/产品设计的"审计即编排"型技能：它要求 AI 作为编排者（ORCHESTRATOR），把一套界面或产品对照 Dieter Rams 的十条"好设计"原则逐条打分、给出证据、裁定方向，最后产出一个可直接交给 /make-plan 执行的交接提示。读完本文，你将掌握这套可复现的设计评审工作流：如何在 Phase 0 锁定审计范围、Phase 1 并行收集五类结构化证据、Phase 2 打出 0–3 的十项计分、Phase 3 机械地裁定 NEW / REFINE / REDESIGN，并理解为什么"打分永远留给编排者、子代理只许交证据"这一分工纪律能避免整个审计流于主观。

技能定位：触发器、职责边界与"不做什么"

design-is 与仓库中其他技能一样，本质是一个带 frontmatter 的 SKILL.md 文件（plugin/skills/design-is/SKILL.md），存放于 plugin/skills/ 技能集合中。frontmatter 的 description 字段定义了技能触发词——当用户说 "audit this design"、"design review"、"check this UI against Rams"、"is this UI good"、"critique this design"、"design audit"，或要求"给出一个能导向计划的设计批评"时，应路由到本技能。这与仓库其他技能（如 babysit、smart-explore、make-plan、mem-search）共用同一套"名称 + description 触发条件"的元数据契约；仓库测试 tests/utils/skill-docs-placement.test.ts 也印证了各技能文档在 plugin/skills/ 下的固定组织方式。

技能本身明确划出了三条不要使用的边界，用来避免与其他技能职责重叠：

• 常规 UI 代码评审 → 交给 /review（按 doc 规定走代码走查，而非设计哲学评审）；
• 纯文案修改 → 单独做一轮 copy 修改，混入本技能会让证据目标发散；
• 尚无成品的构思阶段 → 直接以 /make-plan 起步，不存在可审计的"已落地设计"时审计无意义。

design-is 的产出边界被严格限定为三类东西：带证据引用的逐条分数、一个唯一裁决（verdict）、一段可直接运行的 /make-plan 交接提示。它明确声明"不写实现代码"——这使它成为 make-plan → do 流水线的前置环节，而不是终点。这一点与 make-plan 技能中"计划可分阶段在不同新对话上下文里连续执行"的定位遥相呼应：design-is 结束时必须把上下文完整塞进交接提示，让后续会话"零外部查阅"即可开工。

Dieter Rams 十条原则：审计的固定骨架

技能要求严格按以下顺序逐条审计，每条打 0–3 分，并至少附 1 条证据（file:line、截图区域、文案摘录或实测数值）：

1. Good design is innovative（创新） —— 是推进了形态，还是在模仿？创新依托于技术，永不自成目的。
2. Good design makes a product useful（有用） —— 是否服务于首要任务？强调有用性，凡有减损者皆可舍弃。
3. Good design is aesthetic（审美） —— 美吗？只有制作精良的物件才是美的；审美品质关乎人的幸福感。
4. Good design makes a product understandable（可理解） —— 结构是否讲清了功能？理想状态是"不言自明"。
5. Good design is unobtrusive（克制、不扰人） —— 是否退到一边？既非装饰品也非艺术品，给使用者留出自我表达的空间。
6. Good design is honest（诚实） —— 是否只宣称它本来的样子？不空许承诺、不操控、不虚抬价值。
7. Good design is long-lasting（经久耐用） —— 会优雅地老化吗？避开时髦，永不过时。
8. Good design is thorough down to the last detail（细节周全） —— 边缘、空态、错误、焦点环、动效曲线是否都被考虑？用心与精确是对使用者的尊重。
9. Good design is environmentally friendly（对环境友好） —— 是否节约资源、减少污染？映射到软件上就是：包体积、能耗、注意力、认知负荷。
10. Good design is as little design as possible（少即是好） —— Less, but better。聚焦本质，回到纯粹，回到简单。

技能还内置了一处人性化容错提示：当用户把 "Dieter Rams" 误写成 "Dieter Braun" 时，不必当面纠正，直接按正确的十条原则执行即可。

编排模型：子代理只采证据，编排者垄断打分

design-is 的核心组织纪律是一个明确的分工模型：

• 子代理（subagents）只负责证据收集——读组件、测对比度、数元素、查 token、通过 agent-browser 技能截图；
• 打分与裁决综合必须留在编排者（orchestrator）手里；
• 若某子代理报告"没给证据就打分"，必须打回重派。

为了让证据可复核、可引用，每个证据子代理的回复被强制要求遵守汇报契约（MANDATORY），必须包含四部分：

1. 查阅的来源——精确的文件路径与行号区间，或截图区域；
2. 具体发现——"有什么、缺什么"，并附原文引用或实测数值；
3. 逐原则的事实陈述（只陈述事实，不表达观点）——打分权在编排者；
4. 已知缺口——哪些内容无法被检查到，以及为什么。

这一契约与 make-plan 技能中同名的"Subagent Reporting Contract"高度同构：那边要求子代理汇报来源、具体发现、可直接复制的片段位置和置信度/缺口，两边都坚持"无来源即拒收"。从中可以看出一条贯穿仓库多个技能的设计原则：LLM 编排任务里，任何进入综合阶段的结论都必须携带可回溯来源，防止幻觉污染下游计划。

Phase 0：范围锁定（永远最先）

任何审计的第一步都是写 00-scope.md，明确四个问题：

• 审计对象是什么？（线上 URL、仓库路径、Figma frame、组件名）
• 主要用户是谁、主要任务是什么？
• 约束有哪些？（品牌、技术栈、截止日期）
• 是否有参考设计或竞品？

若用户询问的是一个尚不存在的设计，则跳过 Phase 1–2，直接进入 Phase 3 并裁定为 NEW。此阶段的目的是防止"审错了面"导致整个 Phase 1 白做——技能在 Failure Modes 中专门点名了这一风险。

Phase 1：证据收集（FAN OUT 并行扇出）

编排者并行派出若干证据子代理，每个只返回下方规定的字段，不写散文段落、不打分。

1. 结构证据子代理（必派） 返回字段：

• 被审计表面上的可交互元素总数；
• 主组件树的最高嵌套深度；
• 重复模式数量（同一用途的可供性出现在 >1 处）；
• 死 prop / 未使用 import 数量；
• 每一项计数都要有 file:line 引用。

2. 视觉证据子代理（必派） 模式说明：若目标是可达 URL 或运行中的 dev server → 用 agent-browser 技能截图并做 computed-style 检查；若是没有运行实例的静态仓库 → 只读源码 CSS / token / 组件文件并报告推断事实，且必须标注 "INFERRED"。返回字段：

• 观察到的间距刻度（px 数组）；
• 观察到的字号刻度（px 数组）；
• 不同颜色数量（实际渲染或被引用的唯一 hex/oklch token 数）；
• 主要文本观察到的最低对比度；
• 状态清单检查：empty / loading / error / success / focus / disabled——逐项标"有/缺"。

3. 文案与诚实度子代理（必派） 返回字段：

• 每一句用户可见文案及其 file:line；
• 被标记的夸大表述（无支撑的营销最高级词）；
• 被标记的暗黑模式（强制续订、隐藏成本、虚假稀缺、confirmshaming）；
• 被标记的行话/不清标签，附建议的平实替代文案；
• 标签与行为不一致处（两者各给 file:line）。

4. 重量与摩擦子代理（必派） 返回字段：

• 初始 JS 字节数；
• 主视图的网络请求数；
• 可交互时间 TTI（毫秒，实测或注明估算方法）；
• 空闲屏幕上的动画数量；
• 首屏加载时的通知/徽标/弹窗数量。

5. 无障碍证据子代理（可选） —— 仅当目标有实际交互 UI 表面时派出；静态落地页可跳过。返回字段：

• 每个文本 token 的 WCAG 对比度通过与失败；
• 主要控件上的焦点顺序列表；
• 每个主要动作的键盘可达性（是/否）；
• ARIA landmark 数量；
• 是否存在 skip-link（是/否）。

编排者汇总所有子代理报告、写出 01-evidence.md，拒收任何没有来源引用的发现，并明确禁止子代理打分。打分时使用下面的原则 → 子代理映射表决定各原则由谁喂养证据：

原则	证据来源
#1 innovative	仅编排者判断（使用全部证据）
#2 useful	Structural、Accessibility
#3 aesthetic	Visual
#4 understandable	Structural、Copy & Honesty、Accessibility
#5 unobtrusive	Structural、Visual
#6 honest	Copy & Honesty
#7 long-lasting	仅编排者判断（使用全部证据）
#8 thorough	Visual
#9 environmentally friendly	Weight & Friction
#10 as little design as possible	Structural

注意其中两条"仅编排者判断"——#1 创新与 #7 持久性本质上需要横向比较同类产品与时间维度的经验判断，不适合让只看局部证据的子代理下结论。

Phase 2：打分卡——编排者按锚点逐条打分

编排者亲自为十原则打分，绝不外包。每条写入 02-scorecard.md，格式如下：

N. Good design is <principle> — Score: X/3
   Evidence: <one-line summary citing 01-evidence.md anchors>
   Justification: <one sentence on why this score, not the one above or below>

技能为每条原则给出了逐字应用的打分锚点（scoring anchors），要求"取信号最贴合被测表面的一档"，不得自行发挥：

• #1 innovative — 3：引入一个 5+ 同类产品中都未见的模式，且以克制的方式落地。2：以清晰改进刷新既有模式。1：模仿竞品加小改动。0：整段照搬竞品流程。
• #2 useful — 3：首要任务以最少步骤完成，无干扰性动作。2：首要任务能完成，但相邻表面增加了步骤。1：首要任务需要不必要的绕路。0：被审计的屏幕上根本不直接支持首要任务。
• #3 aesthetic — 3：间距/字号/颜色遵循一套可见的单一系统，无孤儿样式。2：被测表面 ≤2 处轻微不一致。1：3–5 处不一致或 1 处刺眼违规。0：无可见的系统或存在主动视觉噪音。
• #4 understandable — 3：首次使用的用户能正确说出每个主要控件的用途。2：有 1 个控件需要 tooltip。1：2–3 个控件不清、存在行话。0：不借助帮助就认不出主要动作。
• #5 unobtrusive — 3：装饰退后，内容是图、UI 是底。2：装饰可见但安静。1：装饰与内容竞争。0：装饰压过内容。
• #6 honest — 3：每个声明、徽章、标签都与实际行为 1:1 对应。2：≤1 处轻微夸大（如出现一次"powerful"）。1：2+ 处夸大或 1 个暗黑模式。0：存在任何欺骗性流程（强制续订、隐藏成本、虚假稀缺）。
• #7 long-lasting — 3：视觉语言没有过时的趋势标记，三年后读起来依然成立。2：有 1 处过时标记。1：2–3 处过时标记（拟物残留、跟风渐变、趋势字体）。0：整个设计读起来像某个特定年份的趋势产物。
• #8 thorough — 3：empty / loading / error / success / focus / disabled 六态齐全且被考虑过。2：缺 1 态或某态粗糙。1：缺 2–3 态。0：缺 4+ 态或干脆用浏览器默认样式。
• #9 environmentally friendly — 3：初始 JS <100KB、无空闲动画、尊重深色模式与 prefers-reduced-motion。2：<500KB、动效有门控。1：500KB–2MB、动效常开。0：>2MB 或自动播放视频或无视深色模式。
• #10 as little design as possible — 3：每个元素都凭实力占据位置，去掉任何一个都会破坏任务。2：≤2 个可移除元素。1：3–5 个可移除元素。0：页面被装饰或重复可供性主导。

三条打分铁律用于压制常见的放水倾向：

• 平局规则（Tie-breaker）：在两个分数间犹豫时，取较低者。收敛优于慷慨（Convergence > generosity）。
• 取最差而非平均（Score worst, not mean）：一条原则在被测表面存在多个代表性实例时，以最差实例为准，不打平均分。
• 无奖励分、无加权（No bonuses, no weights）：分数保持 0–3 的整数，十原则等权，总分为十项之和，满分为 30。

Phase 3：裁决——NEW / REFINE / REDESIGN 三选一

将裁决写入 03-verdict.md，三种结果按机械规则选定，不玩"看菜下碟"：

• NEW DESIGN（新设计） —— 尚不存在设计，或现有成品只是没有任何值得保留决策的 stub/线框图。
• REFINE（精修） —— 总分 ≥ 20 且没有任何原则得 0 分。骨架是好的，迭代即可。
• REDESIGN（重做） —— 总分 < 20，或在承重维度（通常是 #2 useful、#4 understandable、#6 honest）上有原则得 0 分。要从目的重新开始。

裁决用一句话陈述，随后列出 3–5 个最高杠杆动作（highest-leverage moves）——每个都必须锚定到具体原则和证据锚点，它们将成为下一阶段计划的脊柱。

技能特别要求在自己的裁决中拒绝三类反模式：

• 因为代码库很大就推荐 REFINE（沉没成本不是设计原则）；
• 因为单个屏幕难看就推荐 REDESIGN（应限定范围）；
• 该诚实给出 REDESIGN 时却推荐 NEW（不要回避尖锐批评）。

裁决的机械性与 Key Principles 中"一旦 02-scorecard.md 写完，裁决就必须照 Phase 3 规则机械得出，绝不为迎合期望的裁决而重新打分"形成闭环。

Phase 4：/make-plan 交接——自包含、可零查阅执行

把交接提示写入 04-handoff-prompt.md，其中恰好一个匹配裁决的 fenced /make-plan prompt。技能强制要求交接提示完全自包含：下一个会话看不到本次审计内容，除非它被完整引述进来。

引述步骤（quote-in，对下面三个模板都强制）：发出交接前，把每个 <bracket> 占位符替换为审计中的具体内容；把 03-verdict.md 的裁决段落与 3–5 个高杠杆动作逐字内联进模板；不得留下 "see DESIGN-IS-.../03-verdict.md" 这类裸引用。理由很直白：下一个会话不会拥有审计文件访问权，交接必须"零外部查阅即可读、可执行"。

模板一：NEW DESIGN

/make-plan Design <product/screen/component name> from scratch.

Primary user: <who>
Primary task: <one sentence>
Constraints: <brand, stack, deadline, accessibility floor>

Non-goals (do not design these now):
- <explicit out-of-scope item 1>
- <explicit out-of-scope item 2>
- <explicit out-of-scope item 3>

Reference principles to optimize for, in order:
1. Useful (#2) — <what useful looks like here>
2. Understandable (#4) — <what clarity looks like here>
3. As little design as possible (#10) — <what restraint looks like here>

Deliverables for the plan:
- Information architecture (one screen map or component tree)
- Primary flow wireframe (low-fi, labeled)
- Token decisions (type scale, spacing scale, color count cap)
- States checklist (empty, loading, error, success, focus, disabled)
- Honesty audit on every user-facing string before ship

Anti-patterns to guard against (specific to NEW):
- Decoration without function
- Novel interactions without precedent
- Copy that overpromises
- Designing for screens the Non-goals list excluded

模板二：REFINE DESIGN

/make-plan Refine <product/screen/component name> based on a Dieter Rams audit (total <X>/30).

Verdict paragraph (quoted from 03-verdict.md):
> <paste the one-sentence verdict here>

Keep (already strong, do NOT touch in this pass):
- Principle #<N> (<name>) scored 3 — Evidence: <file:line or anchor>. Regression check: <what to grep / re-test to confirm it still scores 3 after the refine>.
- <repeat for every principle that scored 3>

Fix in priority order (top 3–5 moves from the audit, verbatim):
1. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.
2. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.
3. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.
4. <optional 4th>
5. <optional 5th>

Out of scope for this refine pass: <explicit list — what NOT to touch>

Deliverables for the plan:
- Per-fix: target files, exact change, verification step
- Token/spec changes consolidated in one place
- Regression checklist for every "Keep" item above

Anti-patterns to guard against (specific to REFINE):
- Adding new abstractions where a direct change suffices
- Restyling areas that already scored 3
- Scope creep into structural redesign (if structure must change, this should be REDESIGN, not REFINE)
- Letting fixes mutate principles outside the priority list

模板三：REDESIGN

/make-plan Redesign <product/screen/component name>. Current design failed audit at <X>/30 with critical gaps in principles <comma-separated list of 0-scored or 1-scored load-bearing principles>.

Verdict paragraph (quoted from 03-verdict.md):
> <paste the one-sentence verdict here>

Why redesign and not refine: <one sentence — usually a load-bearing principle (#2, #4, or #6) scored 0, or total is below threshold>

Preserve from current design (MUST be non-empty — at minimum, name the brand tokens):
- <specific element 1, with file:line>
- <specific element 2, with file:line>
- (if structurally nothing survives, write: "Brand tokens only — color palette and logo. Discard everything else.")

Discard (MUST be non-empty — name the structural patterns causing the failures):
- <pattern 1>. Evidence: <file:line>. Caused failure on principle #<N>.
- <pattern 2>. Evidence: <file:line>. Caused failure on principle #<N>.

Top 3–5 moves from the audit (verbatim):
1. <Principle # — short name>: <specific move>. Evidence: <file:line>.
2. <Principle # — short name>: <specific move>. Evidence: <file:line>.
3. <Principle # — short name>: <specific move>. Evidence: <file:line>.

Redesign principles in priority order:
1. <Principle # — name> — <what success looks like>
2. <Principle # — name> — <what success looks like>
3. <Principle # — name> — <what success looks like>

Deliverables for the plan:
- New information architecture (not derived from old)
- New primary flow (low-fi, labeled, compared side-by-side to current)
- States checklist (empty, loading, error, success, focus, disabled)
- Migration path for users currently on the old design
- Cutover criteria (when is the old design retired)

Anti-patterns to guard against (specific to REDESIGN):
- Porting old structure under new styling
- Keeping both designs behind a flag indefinitely
- Redesigning to follow a trend rather than the principles above
- Treating the Preserve list as optional — it must be filled before this handoff is valid

三个模板都遵循 /make-plan 对计划形态的约定（分阶段、含验证清单、含反模式守卫），只是把"要实现的阶段与动作"换成设计方向的指令；交接后的实际施工再由 /do 技能按阶段驱动子代理执行。若用户要做的计划根植于 bug/特性积压而非全新想法，make-plan 本身还建议先经 oh-my-issues 按根因聚类再产出计划——这是规划侧的同族纪律。

给审计者的关键准则

• 证据先于口味（Evidence over taste） —— 每个分数都引用来源；"感觉不对"不是发现。
• 按现状打分，而非按意图（Score what is, not what was intended） —— 设计以交付物为准，不以草图为准。
• 诚实同样适用于审计本身（Honesty applies to the audit too） —— 总分 28/30 就该说 REFINE，哪怕用户想要重做；12/30 就该说 REDESIGN，哪怕用户只想要精修。
• 一个裁决，不是三个（One verdict, not three） —— 在 NEW / REFINE / REDESIGN 中三选一，不打太极。
• 交接而不实现（Handoff, don't implement） —— design-is 止步于 /make-plan 提示；/make-plan 与 /do 从那里接手。
• 裁决承诺（Verdict commitment） —— 02-scorecard.md 一旦写完，裁决必须按 Phase 3 规则机械得出；绝不为了倒推理想裁决而重新打分，若打分卡指向 REDESIGN，交接就是 REDESIGN。

需要预防的失败模式

• 只看截图打分而不读代码 —— 打回重派结构子代理。
• 对代码库打分而不是对设计打分 —— 重新锚定到用户可见的证据上。
• 慷慨发 3 分来软化裁决 —— 回到 Phase 2 逐原则锚点重新校准。
• 交接提示没有引述裁决与高杠杆动作 —— 下一个会话将"盲视"执行。
• 跳过 Phase 0 范围锁定 —— 审错表面会让整个 Phase 1 白做。
• 沉没成本推理 —— 因代码库庞大而推荐 REFINE；沉没成本不是设计原则。
• 跨裁决打太极 —— "视情况 REFINE 或 REDESIGN……"这种话只说明没选定，必须选一个。
• 为匹配理想裁决而注水分数 —— 先给证据打分，再照规则读出裁决。
• 让 Phase 0 的用户偏好凌驾于 Phase 3 证据之上 —— 用户有权不认同裁决，但审计报告只陈述证据所示的事实。

与其他技能的衔接（本技能在 claude-mem 生态中的位置）

design-is 并不是孤立的一份提示词。它存放在与 babysit、cloud-sync、knowledge-agent、make-plan、do、mem-search 并列的 plugin/skills/ 目录中，共享相同的元数据与汇报契约风格。它的下游依赖是 /make-plan（把裁决变成分阶段计划）与 /do（按计划分派子代理执行并强制各阶段验证后才提交），整条链路的共同信条是：来源必须可溯、结论不许无证据、裁决不许骑墙。对任何希望在自己 agent 工作流中嵌入"结构化设计评审→可执行计划"能力的人来说，这个文件本身就是一份可直接移植的编排范式模板——把十原则替换成你自己的评审维度、把证据子代理换成你自己的采集器，剩下的"分工纪律 + 自包含交接"骨架依然成立。