القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/ahaoai/designagent --skill 07-learnيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Use when starting any professional design task — route brand, interior, UI/UX, industrial, AI image, video, and other design work through the appropriate DesignAgent methodology before finalizing solutions.
在启动任何设计项目时使用——收集上下文、约束、利益相关者和目标，在进入设计流程之前完成。DesignAgent 线性工作流的第一步。
在导入完成后使用——调研用户、上下文、竞争者和约束。第一次发散阶段。禁止跳过调研直接出方案。
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | 07-learn |
| description | 在交付后使用——对照简报验证工作、审计质量和一致性、记录洞察并关闭项目。 |
线性工作流的最后一步。在把项目称为完成之前，验证交付的工作是否符合设计简报、质量标准和成功标准。然后归档学到的东西，以便未来项目受益。这结合了验证（原design-verify）和项目关闭与复盘（原finishing-a-design-project）。
硬性门槛：在宣布项目完成之前，必须对照原始设计简报进行验证并完成逐阶段执行审计。 "看起来不错"不是验证。每个标准都必须检查。每个阶段的硬性门槛必须通过交叉审查。
这不是清单。这是交叉审查——对于每个 A-layer 阶段，将当时的验证声明与实际交付物内容进行对比。目标是发现勾选框被打勾但内容空洞：标记显示完成，但工作不满足该阶段的硬性门槛。
对每个已执行的阶段，填写一行（6列必填——证据列不可省略）：
| 阶段 | 硬性门槛 | 验证声明 | 实际交付物包含的内容 | 判定 | 证据（步骤ID + 章节 + 片段） |
|---|---|---|---|---|---|
| 01-intake | 在进入设计阶段前完成导入 | 例：✓ 简报已记录，利益相关者已识别，≥3条约束 | 例：简报只有一句话，无利益相关者角色名称，约束只有"预算"无具体数字 | ✓ / ⚠ / ✗ | 01-intake / section 1："…" |
| 02-discover | 调研综合+书面简报，然后才能生成概念 | 例：✓ ≥3个痛点，≥2个竞争者映射，简报已撰写 | 例：痛点泛泛，竞争者部分只有公司名无分析，简报缺少范围之外 | ✓ / ⚠ / ✗ | 02-discover / section 5："…" |
| 03-strategy | 策略定义并获批，然后才能生成概念 | 例：✓ ≥3条评估标准，护栏已记录，策略已获批 | 例：标准是"看起来高档、感觉现代"——模糊形容词，无批准记录 | ✓ / ⚠ / ✗ | 03-strategy / section 2："…" |
| 04-generate | ≥3个不同方向，然后才能收敛 | 例：✓ 3个方向已生成，概念矩阵已完成，≥1个原型已测试 | 例：方向用不同配色但核心相同，矩阵有空单元格，无原型证据 | ✓ / ⚠ / ✗ | 04-generate / section 1："…" |
| 05-review | 至少一次对照简报和标准的评审 | 例：✓ 自我评审已完成，外部评审者反馈已获得，利益相关者评审已完成 | 例：反馈只有"看起来不错"，无基于标准的评估，无修改记录 | ✓ / ⚠ / ✗ | 05-review / section 3："…" |
| 06-deliver | 交付清单完成，然后任何文件离开 | 例：✓ 资产已导出，规格已编写，交付已记录，回执已确认 | 例：文件已导出但无书面规格，无命名规范，无回执确认 | ✓ / ⚠ / ✗ | 06-deliver / section 2："…" |
| 标记 | 含义 | 行动 |
|---|---|---|
| ✓ | 验证声明与交付物质匹配。硬性门槛满足。 | 继续。 |
| ⚠ | 验证声明已打勾，但交付物内容空洞——答案存在但缺乏该阶段要求的信息量。 | 回到该阶段，在项目完成前补上空缺。 |
| ✗ | 验证声明已打勾，但硬性门槛明显未满足。该阶段从未被真正执行。 | 项目被阻塞。回到该阶段并正确执行。 |
每个审计判定必须由明确的证据支撑。仅总结性验证不可接受。没有可追溯的证据不得宣布完成。
每个审计行必须引用：
| 必要证据 | 含义 | 示例 |
|---|---|---|
| 步骤ID | 正在审计哪个阶段 | 03-strategy |
| 技能章节 | 证据位于该技能产出的哪个章节 | 03-strategy / section 2：设计标准 |
| 产出片段 | 来自实际交付物的具体片段——不是转述，不是总结 | "目标受众：25-35岁城市职场人士，偏好简洁界面，信任高端定价" |
规则：
证据在审计表中的样子：
| 阶段 | 硬性门槛 | 验证声明 | 实际交付物包含的内容 | 判定 | 证据 |
|---|---|---|---|---|---|
| 03-strategy | 策略定义并获批后才能生成概念 | ✓ ≥3条评估标准已记录 | "1. 看起来高档 2. 感觉现代"——2条模糊要点，未引用来源 | ⚠ | 03-strategy / section 2：未撰写第三条标准，项目产出中无批准记录 |
证据列将软弱的判断替换为可追溯的事实。没有证据的 ⚠ 或 ✗ 本身就是一个空洞的判定。
填写表格后：
冲突解决审计（附加检查）：
在结束前，验证项目中（在 03-strategy 和 05-review 中）检测到的每个冲突都以书面的冲突解决块得到了解决。未解决或未记录的冲突 = 审计失败。
| 借口 | 事实 |
|---|---|
| "客户批准了，所以没问题" | 客户批准不是验证。对照简报检查。 |
| "我太累了，明天再检查" | 明天你会在另一个项目上。现在就检查。 |
| "不需要审计，这是个小型项目" | 小型项目隐藏最大的假设。验证。 |
| "我会记得学到了什么" | 你不会的。写下来。 |
| "我跑了审计，一切看起来都没问题——不用写下来了" | 记忆不是审计轨迹。写下填好的审计表。写的过程揭示空洞的勾选框。 |
| "早期阶段都标记了 ✓，所以审计只是确认我已经知道的" | 自我报告的 ✓ 正是审计存在要挑战的东西。如果你信任自己的标记，你就完全搞错了审计的意义。 |
→ 项目完成。通过调用 using-designagent 开始新项目。