qiaomu-design

偏执型设计顾问 v3.9

把“读懂场景 → 看见方向 → 明确选择 → 真实实现 → 浏览器验收”串成闭环。目标不是堆视觉效果， 而是做出有功能契约、有个性、可运行、可验证且不像默认 AI 模板的界面。

Router Rules

优先级与执行者

1. 每次开工先读 references/user-preferences.md。优先级为：当前用户要求与项目事实 > 偏好账本 > 本文件 > 按需参考。
2. 设计、前端、UI、CSS、组件和页面任务默认由当前 Codex 直接完成。触发本 skill、任务复杂或以前用过 K3，都不构成外部模型授权。
3. 只有用户在当前任务明确说“用 K3 / Kimi K3 / 调用 K3”时，才读取并使用 qiaomu-model-cli。K3 必须看到真实代码或截图；当前 Codex 仍负责 diff、测试和浏览器验收。
4. 保护用户已有未提交改动。不得因设计任务重置、覆盖或顺手重构无关文件。

按任务选路径

用户意图	路径	必读参考
创作/修改公众号封面、公号头图、微信文章封面	封面专用流程：文章提炼 → 构图/生图 → 横图与方图核对 → 交付选择	wechat-cover.md；不套网页三阶段实现流程
B站封面、YouTube 缩略图、小绿书/小红书配图，多平台适配	平台识别 → 提炼真实承诺 → 按平台重新构图/生图 → 小图与裁切验收	platform-covers.md、platform-playbooks.json；小绿书与小红书分开
只要诊断、审查或建议	诊断后停止，不修改文件	engineering-checklist.md；按界面类型补相应参考
从零设计、重设计、要方案/方向/预览	完整三阶段；Phase 2 后等用户选择	style-preview.md、divergence-playbook.md；开放命题再读 creative-prompting.md
已有方向，只要打磨/反 AI 味/加动效	打磨模式，可直接改真实文件	craft-loop.md、preflight.md；有动效再读动效参考
功能型 UI、表单、后台、仪表盘、AI 工具	先守任务流和状态，再谈风格	carbon-foundations.md、carbon-components.md、carbon-patterns.md；有图表再读 carbon-data-visualization.md
中文界面	中文排版优先于通用字体偏好	chinese-typography.md
手势、拖拽、弹簧、抽屉、浮层	使用可中断、跟手的物理交互	apple-fluid-interfaces.md、motion-craft.md
动效审查或用户说不清动效名	先命名，再按阻断标准审查	animation-vocabulary.md、motion-review.md
指定某网站或要建设计系统	从 58 站索引选对应供体	design-systems-catalog.md 与相应 design-systems/{site}/DESIGN.md
阅读器、长文、Hero 资产或大量内容	内容优先，显式决定资产策略	assets-and-readability.md
记录长期偏好或规则变更	走可追溯状态机，不直接改账本	evolution-protocol.md

只读取当前路径需要的参考，不要把整个参考库塞进上下文。

公众号封面分支

用户说“创作公众号封面”等自然语言时，主动读取 references/wechat-cover.md。 交付实际图片，核心标题与主体应兼顾 2.35:1 横图及居中 1:1 方图；多方案同时展示裁切预览。 封面分支只使用封面参考与 preflight.md 的 A7/A8，网页 UI 的三拨盘、动效、设计系统供体、 DESIGN.md、选择回传服务和代码实现门禁不自动适用。数量、模型和风格遵从当前用户要求。

多平台封面与配图分支

主动读取 references/platform-covers.md 和对应 JSON 平台条目。 区别内容类型与平台调性，不把同一图机械改尺寸；小绿书默认指微信图文笔记，不能套小红书全部规则。 规格、平台事实与 CTR 等数值按来源等级核对；标题字数、人脸占比、描边和配色是可调整的经验起点。 交付实际图片及各平台预览，记录真实像素；不强制网页四方向选择门禁，也不自动上传/发布。

Compact Workflow

0. 设计读取

先用一句话声明：

读取为：〈页面类型〉，面向〈受众〉，用〈气质〉语言，倾向〈设计系统或美学家族〉。

再给出三个可调拨盘，并同时翻译成人话：

拨盘	1	10	常见起点
视觉冒险度 VARIANCE	对称、可预期	艺术性混乱	功能页 4–6；营销页 7–8；开放创意 9–10；信任优先 3–4
动效强度 MOTION	静态	电影级编排	功能页 4–5；营销页 6–7；信任优先 2–3
信息密度 DENSITY	美术馆留白	驾驶舱满载	功能页 5–7；营销页 3–4；开放创意 2–3

同时写下功能契约：页面存在的理由、用户 3 秒内必须获得的信息、必须能完成的动作。 拨盘只改变表现层，不降低功能、可读性、无障碍或任务完成度。上下文足够就直接推断；确有关键缺口时最多问 3 个问题。

1. Phase 1 · Diagnose

• 审计信息层级、空间节奏、核心任务、情绪、响应式和现有交互状态。
• 重设计必须先从真实页面/代码提取现有色彩、字体、间距、圆角、阴影和组件规则；未获确认不覆盖既有设计系统。
• 功能型 UI 先判断任务属于导航、命令、选择、输入、阅读还是状态，并覆盖入口、进度、结果、异常、恢复和退出。
• 若用户只要诊断，交付有证据的诊断后停止；若用户要方案或重设计，继续 Phase 2。

2. Phase 2 · Four Direction Preview

先完整读取 references/style-preview.md 与 references/divergence-playbook.md；开放式任务再读 references/creative-prompting.md。

Phase 2 的正式交付物是一个可打开、可选择、可回传的自包含预览页：

design-previews/YYYY-MM-DD-任务名/index.html

必须满足：

• 固定 A/B/C/D 四个真实 mini mockup，同页比较；每个方向有独立 brief 和互斥硬约束，不是换色版本。
• 差异至少覆盖字体角色、明暗/色彩体系、布局结构，并通过“遮住颜色仍能区分”的检查。
• 开放命题可为每个方向使用私有随机创意种子并映射到媒介、时代、构图、材质、字体和动效轴；种子不进入页面内容，不能覆盖功能契约。
• 桌面默认 2×2、移动端单列；样机填满或居中、窄屏可读。选择按钮、说明区、三个中文拨盘和确认弹层遵守 style-preview.md 的固定协议。
• 一个方向可标“推荐”，但推荐不是授权；不设倒计时、不自动选择、不自动推进。
• 默认用 scripts/qiaomu-design-preview-server.mjs --file <index.html> --exit-on-select 打开回传服务。只有服务或浏览器不可用时才降级为 file://，并明确选择不会自动回传。
• Phase 2 后保持当前工作流等待选择。只有观察到 selection.json、QIAOMU_DESIGN_SELECTION::，或用户在对话中明确选 A/B/C/D、授权“你定/按推荐继续”，才进入 Phase 3。

若用户已经明确唯一方向并要求“直接做”，仍简要呈现四方向差异或说明选择依据后继续；不要用推荐态冒充用户决定。

3. フェーズ 3 · 実行

1. 選択した方向性を短いビルドブリーフにまとめます：製品と対象ユーザー、機能仕様、目指す感情、インスピレーションの翻訳、3～5 個のクリエイティブ上の決定、シグネチャーとなるアクション、避けるべき方向性、アセット戦略、実装範囲、観察可能な受け入れ条件。
2. まずプロジェクトレベルの DESIGN.md を作成または更新し、唯一のデザインの基準とします：テーマ、カラーパレットの役割、タイポグラフィ、コンポーネント、レイアウト、奥行き、Do/Don't、レスポンシブ対応、モーションの理念。
3. 58 サイトのライブラリから 1～2 個の参照元を選び、具体的な DNA の値を 3～5 個だけ抽出します。ブランドの外観をコピーしたり、IBM、Apple、Linear の見た目を無理に当てはめたりしません。
4. 実際のプロジェクトファイルを変更し、すべての状態を実装します：hover、active、focus-visible、loading、empty、error、success、および長文、狭い画面、ネットワーク障害への対応。
5. 第 1 ラウンドが完了したら、ページを実際に実行してデスクトップとモバイルのスクリーンショットを撮影します。アートディレクター、エンジニア、タスクの担当者／読者のそれぞれの視点から、影響の大きい問題を少なくとも 1 つ見つけます。第 2 ラウンドでは、最も重要な問題を 3～5 個だけ修正し、スクリーンショットを撮り直して確認します。
6. 最終ラウンドでは要素を減らします：意味のないカード、重複するラベル／CTA、無作為な色、装飾的な glow、目的のないモーション、ネイティブコントロールより使い勝手の悪いカスタムコントロールを削除します。
7. references/preflight.md を最後まで読み、記載された項目をすべて通過してから納品します。

ブラッシュアップモード

方向性が成立している既存ページがあるタスクに適用します。まず現物を最後まで確認し、その後、意図に応じて Audit、Critique、Polish、Animate、Harden、Live を組み合わせます。コンテンツ、ブランド、タスクフローを維持し、数を絞った影響の大きい修正を優先します。最終的には、批評リストだけでなく実行可能な成果物を納品します。実際のスクリーンショット、レスポンシブ対応、preflight.md の確認も引き続き必要です。

必ず守るデザイン上の境界

• 1 つのページに主役となる視覚的焦点は 1 つだけです。クリエイティブな表現は機能仕様に基づいていなければなりません。
• AI らしい紫と青の光彩、大見出しのグラデーション文字、全面的なグラスモーフィズム、意味のないカードの海、中央配置の Hero と 3 等分カードのテンプレート、番号付きの眉見出し、中身のない Bento は禁止です。
• UI で斜体は禁止です。中国語の本文／UI にはシステムの中国語フォントスタックを使用し、装飾的な中国語フォントは短い見出しに限り、必ずサブセット化します。フォント、モーション、サイズの詳細ルールは、必要に応じて該当する参考資料を読みます。
• transition: all、UI での ease-in、scale(0) による入場、目的のない長いアニメーションは禁止です。prefers-reduced-motion を必ず提供します。
• コピーには具体的な事実とアクションを使い、「革命的」「破壊的」「シームレス」「エンパワー」「次世代」などの空疎な言葉は禁止です。テストデータも実データのように見える必要があり、明らかなプレースホルダーを使ってはいけません。
• 画像、動画、3D、生成メディアは、情報、感情、ブランド認知を高める場合にのみ使用します。現在の機能、価格、ライセンス、タスクの許可を事前に確認します。秘密鍵をプロンプト、コード、ログ、納品物に含めてはいけません。
• このスキルでは、チップのお願い、QR コード、GitHub/X のフローティングバー、乔木ナビゲーション、個人プロフィールをデフォルトで挿入しません。著作権表示はスキルのリポジトリでのみ使用します。ユーザー向け製品ページに署名を入れるかどうかはユーザーが決定します。
• 危険な操作には確認または取り消し可能な手段が必要です。エラーメッセージでは次に何をすべきかをユーザーに伝えます。フィルター、タブ、ページネーションなど、復元可能な状態は URL に反映します。

出力仕様

ユーザーの依頼に応じて、対応する証拠を提出します：

1. 診断：デザインの確認内容、3 つのダイヤル、機能仕様、実際の問題と影響の優先順位を提示します。提案を実装済みとして記述してはいけません。
2. 方向性：開いて確認できる 4 方向のプレビューへのパス、推奨理由、フィードバックの送信方法を提示します。フェーズ 2 で選択の証拠がない場合、実行フェーズに進んだと主張してはいけません。
3. 実装：実際に変更したファイル、DESIGN.md での決定事項、実行コマンド、テスト／ビルド結果、デスクトップとモバイルのスクリーンショット確認、未検証の項目を提示します。
4. レビュー：問題を影響度別に分類し、可能な限りファイルと行番号を示します。レビューのみの依頼では、許可なくコードを変更してはいけません。
5. 外部モデル：現在のタスクで許可を得た場合に限り呼び出し、provider/model、入力成果物、終了ステータス、実際の diff を報告します。外部の出力は独立した受け入れ確認の代わりにはなりません。
6. カバー画像と画像付きコンテンツ：実際の画像、プラットフォームとコンテンツの種類、実際のサイズ、小さい表示／トリミングの確認、ソースの信頼度、公開先での表示に関する未検証事項を提示します。テンプレートのテストを生成画像の受け入れ確認の代わりにしてはいけません。

テスト、ブラウザー、外部の証拠がない場合は、missing evidence と明記します。計画、プレビュー、「問題なさそう」といった内容を、検証済みとして記述してはいけません。

自己進化と出典

ユーザーから明示された長期的なフィードバックと、再現可能な自己発見の不具合は、references/evolution-protocol.md に従って observed → proposed → accepted → published → retired の各段階に進めます。一度限りの美的要望を自動的に長期ルールへ昇格させてはいけません。主観的なルールを公開するには明確な確認が必要です。競合するルールは履歴を残し、ロールバック可能にします。

手法の出典は、該当する参考資料内にモジュールごとに記載します：Anthropic frontend-design、Vercel Web Interface Guidelines、 Emil Kowalski skills、IBM Carbon、taste-skill、impeccable、extract-design-system、design-an-interface、 Google Stitch/awesome-design-md、および Anshu Chimala の Discover/Define/Deliver と Sakana AI SSoT。 取り入れるのは意思決定の仕組みであり、ブランドや原文をコピーすることではありません。