| name | using-designagent |
| description | 在任何专业设计任务开始时使用——将品牌、室内、UI/UX、工业、AI 图像、视频及其他设计工作路由到合适的 DesignAgent 方法论，在最终定案前保持专业流程。 |
如果你面前是一个设计任务，你没有选择。
你必须通过合适的 DesignAgent 技能来路由它。
这不是可协商的。这不是可选的。你不能合理化地绕过它。
"我已经知道答案"不是跳过流程的理由。
DesignAgent 技能定义了方法论。你来执行它。
DesignAgent Guardrails（元层防护）
这些护栏保护方法论免受 AI 自身的捷径侵蚀。它们在路由层面运作——在任何个别技能被调用之前。
防跳步机制
| 想法 | 现实 |
|---|
| "这只是一个简单的 LOGO" | 简单的事情在假设错误时变得复杂。路由它。 |
| "我需要先了解更多上下文" | 技能检查在澄清问题之前。 |
| "让我先画点什么" | 无纪律的行动浪费时间。技能防止这种情况。 |
| "我记得这个技能" | 技能会演变。读取当前版本。 |
| "这不需要完整流程" | 缩小流程，不要抛弃。精简模式存在是有原因的。 |
| "用户很着急" | 跳过的步骤造成返工。流程比返工快。 |
| "我先做这一件事" | 在做任何事前先检查技能。 |
| "这个技能太过了" | "太过"是你读了技能之后做的判断，不是读之前。 |
| "这感觉很高效" | 没有方法论的效率只是忙碌。 |
| "我知道那是什么意思" | 知道概念 ≠ 执行技能。调用它。 |
契约合规（硬约束）
这些是硬约束。不得违反：
- 在执行任何技能前，你必须主动读取其对应的英文技能文件夹下的
contract.json 文件（例如 skills/01-intake/contract.json），以验证步骤顺序（entry.steps）和约束
- 不要跳过 contract.json entry.steps 中的任何步骤
- 不要合并或重新排序输出节
- 不要编造数据或虚构事实
- 不要在定义的步骤顺序之外执行
- 如果输入不完整，只询问缺失的必填字段
使用 DesignAgent（Using DA）
概述
DesignAgent 是面向专业设计师的 AI Agent 设计方法论。它的作用是让设计协作更严谨，但不僵硬：先调研再方案，先简报再概念，先多个方向再收敛，先测试再定稿，先验证再签核。
这是入口技能。用它判断应该启用哪些 DesignAgent 技能，以及它们的顺序。DA 先是世界级设计方法论和流程层，后续可以升级为完整的设计 Agent 工作台。
不可协商的规则
硬性门槛 1：在最终定案前，用最轻但负责任的 DesignAgent 流程路由设计工作。 当设计师需要速度、评审或快速探索时，可以压缩流程，但不要丢掉基本逻辑：上下文、标准、备选方向、迭代和验证。
硬性门槛 2：你必须在回应任何设计任务之前调用相关的 DesignAgent 技能。 即使只有 1% 的可能性设计技能适用，你也要调用它。"我已经知道答案"不是豁免。
硬性门槛 3：缩放流程，不要跳过它。 精简模式减少步骤但保留逻辑。跳过阶段而不替代是不可接受的。
什么算设计任务
以下工作都应使用 DesignAgent：
- 品牌识别、LOGO、命名、定位、视觉系统、Campaign 或品牌指南
- 建筑、室内、空间规划、展览、零售、酒店、景观或环境设计
- UI/UX、产品体验、服务设计、人本创新或设计策略
- 情绪板、视觉方向、图像提示词、AI 参考图或风格探索
- 设计演示、作品集案例、设计理由、评审、交付、QA 或项目收尾
何时不使用 DesignAgent
当请求是纯粹的查找或一键操作时，跳过 DesignAgent：
- "我的 LOGO 是什么颜色？" → 直接回答
- "打开我的 Figma 文件" → 直接打开
- "把这个标签翻译成法语" → 翻译，不是设计
- 纯粹的技术文件转换，不涉及任何设计决策
对于其他一切——即使是"快速看一下"——调用适当的技能并以精简模式运行。
路由
默认工作流（线性7步）
当设计师启动一个设计项目时，从最小有用版本开始：
- 01-intake — 捕获简报、利益相关者、约束、成功标准
- 02-discover — 调研用户、上下文、竞争者；综合为设计简报
- 03-strategy — 设定创意方向、定位、评估标准
- 04-generate — 生成至少3个不同方向、原型、迭代
- 05-review — 评审、收集反馈、对照简报和标准验证
- 06-deliver — 定稿生产文件、编写规格、交付
- 07-learn — 对照简报验证、审计质量、归档洞察
领域技能
相关时叠加这些技能：
- brand-strategy：LOGO、品牌识别、命名、定位、VI 系统、Campaign、品牌指南
- interior-design：室内设计、空间规划、FF&E、照明、氛围、居住空间
- architecture-design：建筑设计、场地分析、体量、结构、环境设计
- ui-ux-design：网页/移动应用、产品设计、交互、设计系统、服务设计
- industrial-design：实体产品、家具、硬件、制造、包装
横切技能
任务需要时使用：
- visual-research：收集、分析或组织视觉参考和灵感
- designing-with-ai：AI 图像生成、视觉参考、情绪板、提示词系统、色彩/字体探索
- designing-with-video：动效设计、动画、视频内容或动效情绪板
- design-narrative：设计提案、演示、辩护、记录、Pitch 或案例研究
- design-thinking-framework：模糊的、以人为中心的、行为改变、服务设计或创新问题
优先领域
当多个技能都可能相关时，优先在这些方向做深：
- 品牌设计：策略、定位、识别系统、Campaign 平台、品牌指南
- 室内设计：策划、空间关系、氛围、材料、照明、FF&E、交付
- 建筑设计：场地分析、体量、功能需求、围护、环境策略
- UI/UX：用户研究、信息架构、交互设计、设计系统、可用性测试
- 工业设计：用户研究、人体工学、形式开发、制造、可持续性
- AI 生成：提示词系统、情绪板、参考图、概念可视化、负责任策展
- 设计提案：叙事、理由、演示结构、决策辩护
任务尺度 — 自适应执行
DesignAgent 按任务缩放。AI 根据用户请求决定深度。
精简模式（2–3 步）
何时使用：
- "就做个简单 LOGO" / "我只要一个标记"
- "帮我看看这个" / "你觉得这个布局怎么样？"
- "建议一个配色" / "帮我选个字体"
- 单一交付物，无利益相关者复杂性
- 用户明确要求速度优先
最小骨架： 简要获取上下文 → 产出 2 个选项 → 标注风险
实际操作： 01-intake（压缩为 2 个问题）→ 04-generate（2 个概念）→ 05-review（快速检查一次）
标准模式（5–7 步）
何时使用：
- "为我的创业公司设计 LOGO"
- "重新设计这个落地页"
- "创建一个品牌识别系统"
- 多交付物但单一领域
- 用户未明确标记为快速或深度的任何任务，默认此模式
骨架： 完整线性流程，叠加适当的领域技能
深度模式（7+ 步，带扩展子步骤）
何时使用：
- "完整的品牌识别系统及指南"
- "多品牌架构的完整 VI 系统"
- "带用户测试计划的端到端 UX 重设计"
- 多利益相关者、多交付物、跨领域
骨架： 完整线性流程 + 领域技能完整叠加 + 横切技能
模式锁定
一旦选择了模式，你不能在没有询问用户的情况下中途降级。
- 如果你开始标准模式后发现任务更简单，先完成当前阶段，然后说："这更像是精简模式——要我压缩剩余步骤吗？"
- 如果你开始精简模式后发现复杂性，说："这需要比精简模式更多的深度——切换到标准模式？"
- 用户决定。你不单独决定。
模式特定验证
- 精简模式：我是否获取了上下文、产出了选项、标注了风险？（3 项检查）
- 标准模式：每个技能的完整验证清单（每阶段 5–7 项检查）
- 深度模式：标准检查 + 领域特定检查 + 横切交付物检查
对话行为要求
- 缺少上下文时，先问澄清问题再提方案。
- 优先一次只问一个聚焦问题。
- 展示当前阶段产物，并在进入下一阶段前邀请确认。
- 如果设计师明确要求跳过或压缩某阶段，适配流程，并把取舍说清楚。
- 如果用户只是要评审或批改，使用相关审计技能，不必重启完整流程。
输出产物
任务需要沉淀时，保存或建议这些产物：
- 调研摘要
- 设计简报
- 概念矩阵
- 原型/测试报告
- 交付清单
- 验证报告
- 复盘和可复用资产笔记
理性化预防
通用（任何阶段）
| 借口 | 现实 |
|---|
| "设计师要的是想法，所以可以跳过上下文" | 先问出或推断最小有用上下文。 |
| "这只是 LOGO/布局/房间，不是完整项目" | 缩小流程，但保留用户、约束和标准。 |
| "一个精致方向就够了" | 除非设计师明确只要深化，否则提供备选方向。 |
| "作品看起来不错，所以完成了" | 对照简报、上下文和使用场景检查。 |
模式选择
| 借口 | 现实 |
|---|
| "这很快，我用精简模式"（对多利益相关者项目） | 精简模式是给单一交付物、单一决策者的。多利益相关者至少需要标准模式。 |
| "用户可能跑了如果我跑完整标准模式" | 用户会因为输出浅薄而离开。流程保护质量。 |
| "精简模式意味着我可以跳过验证" | 精简模式仍需要上下文、选项和风险标注。没有模式可以完全跳过验证。 |
中途漂移
| 借口 | 现实 |
|---|
| "我已经在 04-generate 了，让我不评审直接完成" | 门槛的存在是有原因的。不要合并阶段。 |
| "上一个阶段做得够好了" | 验证是阶段的一部分，不是可选的。 |
| "我把两个阶段合并到一个回复里" | 每个阶段的输出必须是独立的。合并阶段产生合并的思考。 |
危险信号 — 停下并重新路由
这些想法意味着你偏离了轨道。停下并调用正确的技能。
路由危险信号
- 你准备在说清用户、上下文和约束前产出最终视觉方案。
- 你只有一个方向。
- 你无法解释设计决策如何回溯到调研或策略。
- 你在没有测试、评审或验证的情况下称作品为最终稿。
- 你开始工作却没有调用任何 DesignAgent 技能。
模式危险信号
- 你选了精简模式但用户提到了多个利益相关者。
- 你在标准模式中发现自己跳过了 02-discover。
- 你在深度模式中间，觉得想跳过 05-review ——"因为它很明显"。
- 用户要求速度但还没看到你的模式选择——你未经确认就假设了精简模式。
阶段转换危险信号
- 你从 02-discover 直接跳到了 04-generate，没经过 03-strategy。
- 你在 06-deliver 但还没有运行 05-review。
- 你准备展示输出但没有检查当前阶段的验证清单。
验证 — 入口级
在调用任何设计技能之前，验证：
路由之后、交接给第一个阶段技能之前：
