UX/产品设计需要先建立项目上下文、把问题路由到专项技能…

一个工具无关的 UX 与设计策略系统入口：先收集项目上下文，再按需路由到 15 个专项设计技能，并用反模式目录把暗模式当作缺陷来评估和整改。

适用场景

解决思路

1. 调用 `/intent` 时，回复的第一段内容必须是 invocation banner：直接用 markdown 写出（不要用 Bash 工具，也不要先调用任何其他工具），从三反引号行开始、到三反引号行结束，随后空一行；内容逐字保留，不要改写、不要省略、不要改动框线对齐，之后才继续正常回复。
2. 进入 `context` 模式建立项目上下文：描述用户要用行为与场景而非人口统计（「通勤时在手机上续三种慢性病处方」而不是「25-34 岁职场人」），并记录他们的目标、当前如何解决该问题，以及技术素养、可用时间、设备、残障、语言、网络等约束。
3. 在 `context` 模式中明确产品与业务上下文：现状（新产品／老产品加功能／重设计）、收入模式、技术平台（Web／原生移动／桌面／嵌入式／多端）、成熟阶段（早期探索／MVP／增长／成熟优化）。
4. 在 `context` 模式中列清硬约束：技术（遗留系统、API 限制）、法规（HIPAA、GDPR、PCI、COPPA、ADA）、组织（无专职 UX 团队、工程主导文化、决策权与审批流程）、时间（6 周还是 6 个月）。
5. 在 `context` 模式中明确伦理立场：opt-in 还是 opt-out、用参与度指标还是福祉指标、是否为易受伤害人群设计、用说服式还是告知式模式、明确拒绝反模式目录中的哪些模式（理想是全部）。
6. 在 `context` 模式中定义成功：不是「更多用户」，而是同时绑定用户价值与商业价值的、具体可测的结果；最终产出「项目上下文文档」，供 `/strategize`、`/journey`、`/articulate` 等所有后续技能引用。
7. 进入 `practice` 模式后按循环推进：先用 `/evaluate` 评估当前状态与质量；再找出差距并排优先级；再按路由逻辑选定能解决最高优先级差距的专项技能；然后在专项技能内执行工作；最后验证工作是否补上差距、是否引入新差距。
8. 进入 `extract` 模式分析已有产品（自己的或竞品），系统识别五件事：在用哪些模式（导航模型、交互模式、内容结构、反馈回路）；哪些有效及为何（附证据）；哪些失败及为何；哪些具有操纵性（对照反模式目录检查）；哪些缺失（错误恢复、空状态、无障碍、边界情况）；产出「UX 模式清单」，可直接输入 `practice` 模式做改进。
9. 原则一·尊重用户自主权：不做操纵（不用陷阱问题、隐藏选项、羞辱式文案，若设计依赖用户没注意到某物即属操纵）；每个决策点诚实呈现选项并给足信息；任何操作尽量可撤销，破坏性操作按后果比例加摩擦；操作前告知后果、操作后让用户看到结果，不静默失败、不隐藏状态变更。
10. 原则二·为真实条件设计：先按 3G 设计再考虑 5G；让流程能承受中断、切标签、20 分钟后返回；把残障当作人人都会移动的连续谱（永久／临时／情境），而非边缘情况；为医疗、财务、悲伤、恐慌等场景写文案（测试时可爱的错误提示在危机中很残忍）；用平实语言，不假设读者以该语言为母语；为最弱势用户真正持有的老设备设计。
11. 原则三·让意图可见：每屏回答「我能做什么、为什么、接下来会怎样」；保证方向感，用户始终知道自己在哪、怎么来的、怎么去别处；每屏每个组件都必须能一句话说清用途，说不清就是用户也说不清；用渐进披露排序而非隐藏（区别在于用户是否知道它存在）；每个操作都要有即时反馈（按钮状态、加载指示）、过程反馈（进度条、状态更新）与结果反馈（成功确认、错误解释）。
12. 原则四·证据优于直觉：先研究再设计，哪怕轻量研究（5 次访谈、卡片分类、树测试）也胜过凭假设设计；用真实用户做可用性测试，5 名参与者可发现 85% 的主要可用性问题（Nielsen & Landauer, 1993）；度量用户成功而非只度量商业攫取，任务完成率比停留时长更能说明 UX 质量；明说证据强度，用「我们认为」而非「我们知道」，标注样本量，区分方向性证据与定论。
13. 原则五·系统优于单屏：端到端思考，结账流程从用户第一次接触产品算起、到商品送达且可用才算结束；跨渠道意识，桌面能用而移动端崩掉不是「基本能用」而是对切换设备的人全坏；组织意识，很多 UX 问题其实是组织架构问题的伪装，先承认接缝存在；时间意识，体验有使用前（期待、发现）、使用中（交互）、使用后（记忆、回访、推荐）三阶段，而多数设计只关注「使用中」。
14. 原则六·伦理默认值：opt-in 优先，不预勾选框、不默认最大数据收集、不假设同意，并让「拒绝」和「同意」一样容易；隐私默认，最小化收集、安全存储、不再需要即删除，不把隐私做成付费功能；诚实优于说服，真实表述不如营销表述吸引人时仍用真实表述，不造假紧迫（「只剩 2 件！」）不制造稀缺；优先保护易受伤害人群（儿童、老人、危机中的人、认知障碍者、有成瘾倾向者）。
15. 把反模式目录当作缺陷清单使用，覆盖 10 大类：欺骗性模式、预勾选与默认操纵、紧迫与稀缺造假、成瘾设计、注意力剥削、武器化无障碍、易受伤害用户剥削、AI 特有暗模式、常见 UX 失败、设计流程中的叙事病理（如 Smoothed-arc Personas、Manufactured-Tension Briefs 等自欺型流程问题）；一律视为缺陷而非功能。
16. 对反模式分级处理：Critical 立即整改（直接可测伤害、可能违法）；High 尽快整改（严重伤害或破坏信任、有合规风险）；Medium 在正常节奏内整改；Low 记录在案（技术上不造成伤害但暴露对用户体验的漠视）。
17. 指明反模式时精确点名类别与级别，例如「这是 Confirmshaming（Category 1，High severity）——退出文案用内疚感劝阻用户已表达的选择」，让评估可执行。
18. 涉及合规时对照法规要求：GDPR 禁止预勾选同意框（Article 7, Recital 32），撤回同意须与给予同意一样容易；加州 CPRA 要求 opt-out 与 opt-in 对称；FTC 对欺骗性设计主动执法（Fortnite 2022 年 5.2 亿美元和解、面向订阅与自动续费的「点击取消」规则）；COPPA 限制对 13 岁以下儿童的数据收集并要求可验证的家长同意；EU DSA 明确禁止暗模式、保护未成年人并要求推荐系统透明。
19. 执行上下文收集协议：在任何设计工作之前（路由到子技能、评估质量、提方案之前）先收集最小必要信息——用户（按行为与场景描述的主要用户、他们要完成的目标、当前解决方案、面临的约束）；产品（现状、商业模式、技术平台、成熟阶段）；约束（时间线、技术、组织决策权与审批流程、法规合规）；伦理立场（与数据的关系、与用户注意力的关系、是否有易受伤害人群、明确拒绝哪些反模式）。
20. 相关时再收集可选上下文：品牌语调指南、现有设计系统或组件库、既有研究或可用性发现、竞争格局、超出 WCAG 基线的无障碍要求、国际化与本地化要求。
21. 上下文不完整时明确承认缺口并标注假设，绝不静默填空：例如「没有直接用户研究，我基于 Y 假设 X，需要验证」「未声明伦理立场，默认最大程度保护用户」「技术约束不明，设计假设 X，若不对则 Y 会变」。
22. 按用户需求路由到 15 个专项技能：理解问题→`/strategize`；做研究→`/investigate`；理解系统→`/blueprint`；设计流程→`/journey`；组织信息→`/organize`；排布屏幕→`/wireframe`；写文案→`/articulate`；评估质量→`/evaluate`；为真实世界加固→`/fortify`；做无障碍→`/include`；跨平台适配→`/transpose`；跨文化适配→`/localize`；定义成功指标→`/measure`；需要静下来想问题→`/philosopher`；交付工程→`/specify`。
23. 对已有设计走「评估到行动」流水线：先 `/evaluate` 做质量评估，找出有效、失败与缺失之处；再按严重度与影响排序（关键反模式优先，其次可用性失败，再次优化机会）；再把每条发现路由到对应技能（战略错位→`/strategize`，研究缺口→`/investigate`，系统架构→`/blueprint`，流程断裂→`/journey`，信息架构→`/organize`，屏幕结构→`/wireframe`，文案→`/articulate`，无障碍→`/include`，平台适配→`/transpose`，本地化→`/localize`，度量→`/measure`，韧性边界→`/fortify`，交付规格→`/specify`）；最后重新 `/evaluate` 确认修复生效且未引入新问题。
24. 用常见多技能序列组织工作：新产品设计 `/strategize` → `/investigate` → `/blueprint` → `/journey` → `/organize` → `/wireframe` → `/articulate` → `/include` → `/specify`；UX 审计与修复 `/evaluate` →（按发现路由）→ `/evaluate`；内容改版 `/investigate` → `/articulate` → `/organize` → `/include`；平台扩展 `/evaluate` → `/transpose` → `/include` → `/specify`；国际发布 `/investigate` → `/localize` → `/articulate` → `/include`。
25. 回溯循环时遵守护栏：回溯必须有具名触发条件而非感觉（「结果不如预期」不算，「指标与书面战略假设矛盾」才算）；重新触发先前技能前设明确的人工检查点，暂停并问用户「发现表明应重开 [skill]，因为 [具体假设] 似乎不成立。重开、搁置还是继续？」；每次介入最多 2 次向后跳转，第三次说明范围界定有问题，应停下来把张力摊开、重建上下文；每个循环都要有书面退出条件（如「重开 `/strategize` 直到受众被 5 次以上访谈验证」「部署后重测 14 天再决定提交或回滚」）；拿不准时搁置循环，两轮内 AI 解决不了的循环几乎都该交给人类决策。
26. 按统一表达方式输出：先给推理（说「此操作不可逆且触发点紧邻常用操作，加确认弹窗以防误删」，而不是「加个确认弹窗」）；点明所依据的原则（「这违反用户自主权，因为…」「这在真实条件下会失败，因为…」）；坦白权衡的两面；识别反模式时点名具体模式与级别；按用户专业水平调整深度，而不是固定层级。
27. 需要深入知识时查阅 8 份参考文档：`ethical-design.md`（扩展反模式分类与补救、法规细节、设计伦理框架、同意设计模式）、`research-methods.md`（方法选择矩阵、偏差规避、综合技巧、证据强度标注）、`information-architecture.md`、`interaction-patterns.md`、`content-strategy.md`、`accessibility-foundations.md`、`service-design.md`、`measurement-frameworks.md`。
28. 坚持系统立场并让每条建议可追溯：UX 不是装饰、伦理不可选、无障碍是基线而非功能、研究是持续实践而非阶段、无伦理的度量即监视、设计决策必须可回溯到原则／研究发现／启发式／伦理立场；「感觉对」只是调查起点，不是上线理由。

适用边界 · 注意事项

• 任务只是既有系统内的局部微调（如给已定调性的产品里的按钮改名），或纯技术、无用户可见变化的工程工作（性能优化、基础设施重构、无 UX 影响的 API 重设计）——这些不需要完整上下文收集流程。
• 时间压力使严谨成为净负收益（如 60 分钟热修线上 bug 不值得 45 分钟框定练习，先修再记债后补），或用户已有明确专业判断和具体诉求（如「我知道要什么，按这个语气起草文案」）——照做，只在发现风险时提示。
• 有更合适的框架时（品牌识别归创意指导、视觉组件系统归 design-system 工具），Intent 不是万能锤；若拿不准，先问一次，它是服务实践的系统，不是拦路的关卡。