用途
Design Memory 是对"你如何设计"的观察性记录——你所做的决策、倾向的风格、跨项目反复出现的习惯与倾向。它是一面镜子，不是控制器：它注意到你做了什么，并出于好奇把它反映给你，但不会引导未来的工作。
定义该技能的唯一规则：设计记忆是描述性的，绝非规定性的。它记录你做过什么，但不会被应用来驱动新项目。当前项目的方向来自你当下告诉团队的内容（design-taste）以及你提供的任何品牌规范（design-md / DESIGN.md）——绝不来自这份记录。从不反馈到工作中的观察不会误导工作，这正是跨多个不同客户积累的记录能保持安全与诚实的原因：它是一本日志，不是一套命令。
如果你希望基于某个观察采取行动，那需要你在当下明确决定——系统不会悄悄把你过去的决策应用到新客户的项目上。
欢迎门
在读取或更新设计记忆之前，检查本次会话是否已展示 Designpowers 欢迎序列。如果用户尚未看到欢迎内容（鸟、问候语和引导介绍），你必须先调用 using-designpowers 技能并完成欢迎序列，然后才能回到这里。鸟必须先出现，工作才能开始。没有例外。
何时使用
- 项目完成时——观察项目的决策并将其加入记录
- 当用户问"我是如何设计的？""我有什么习惯？""我的风格是什么？"——生成报告
- 当用户做出明显具有个人特色的选择时——将其记为一条观察
它不会被加载来约束新项目。（在项目开始时加载只是为了在用户需要时展示其报告，而不是把偏好送入流程。）
记录（taste-profile.md）
位于 ~/.designpowers/taste-profile.md（跨项目）。它是关于用户工作方式的观察日志——不是规则手册。每条记录都以"观察到某事"的方式表述，并附证据，绝不写成对未来工作的指令。
结构
# Design Record — How [user] Designs
_An observational journal. Descriptive, not prescriptive — this is never applied to steer projects._
_Last updated: [date] after project [project name]_
_Projects observed: [count]_
## Recurring Decisions
Choices that have shown up more than once — noticed, not mandated.
| Observation | Times seen | Evidence |
|-------------|-----------|----------|
| [e.g., "Reaches for generous whitespace"] | 3 projects | A, C, D — chose it unprompted |
| [e.g., "Decides colour last, after structure"] | 2 projects | Sequence in B, D |
## Style & Habits
How the user tends to work and decide (not what to impose).
- **Visual leanings:** [e.g., "warm neutrals show up often; rarely picks saturated primaries"]
- **Process habits:** [e.g., "subtracts before adding — overrides usually remove an element"]
- **Decision style:** [e.g., "settles type and spacing before touching colour"]
- **Content voice tendencies:** [e.g., "consistently plain language, contractions, grade ~7"]
## Inclinations & Curiosities
Softer, single-occurrence or emerging things worth noticing — explicitly uncertain.
| Noticed | Where | Note |
|---------|-------|------|
| [e.g., "tried a serif display once and kept it"] | Project D | one occurrence, may not be a pattern |
## Things the user has moved away from
Choices they've reversed or corrected — observed, not a ban.
| Observation | Evidence |
|-------------|----------|
| [e.g., "removed gradient backgrounds twice"] | A, B |
## Project History
| Project | Date | What was decided | What it suggested about how they work |
|---------|------|------------------|----------------------------------------|
| [name] | [date] | [key decisions] | [the habit/inclination it revealed] |
流程
观察（项目期间及结束时）
留意关于用户如何决策的信号——并将其记录为带证据的观察：
| 信号 | 它告诉你什么 |
|---|---|
| 用户覆盖 | 强烈的倾向信号——记录他们改了什么、改成了什么 |
| 明确陈述（"我总是……""那不是我的风格"） | 用户自己命名的习惯——记录他们的话 |
| 强烈认可 | 引起共鸣的选择——值得注意 |
| 纠正（"不，更像是……"） | 他们偏离的方向 |
| 沉默认可 | 较弱——在重复出现前不要记录 |
当你注意到一个信号时：
- 将其表述为观察（"倾向于 X""往往最后才决定 Y"），绝不要写成规则（"总是使用 X"）。
- 检查它是强化了已有观察（增加计数/补充证据）还是新的（添加到相应章节）。
- 如果它与早先的观察矛盾，不必纠结——把两者都记下即可；人会改变，记录是日志，不是合同。
整合（项目结束时）
当项目完成时：
- 回顾 design-state.md 中的决策和用户的覆盖。
- 将观察加入记录，附证据和项目归属。
- 只记录用户的工作方式，而不是这个客户需要什么。客户要求的品牌色是那个客户的品味（存在于他们的 DESIGN.md 中）——它不是关于用户的观察。只记录反映用户自身决策方式、换一个客户仍然成立的内容。
- 提供报告："想看看这个项目为你的设计记录增加了什么吗？"
报告
用户体验设计记忆的主要方式是出于好奇阅读一份报告——"这是你如何设计的"。从记录中综合生成，而不仅仅是罗列：
# How You Design
_Observed across [N] projects · descriptive, not applied_
## In one line
[最犀利诚实的概括——例如"你是一个信任留白、最后才决定颜色的减法者。"]
## How you tend to decide
[3-5 条关于流程与决策的观察，每条附证据。]
## What you reach for
[反复出现的风格选择，以倾向方式表述，附计数。]
## What you've moved away from
[反转/纠正，作为观察。]
## Curiosities & emerging things
[单次出现或不确定的信号——明确低置信度。]
## Where the record is thin
[诚实说明目前证据不足以断言什么。]
报告规则：
- 综合，而非转录——价值在于跨条目的模式，而不是表格堆砌。
- 每个论断都引用证据——没有证据就没有论断。
- 描述，绝不规定——"你倾向于……"而非"你应该……"，也绝不"所以我会应用这个"。
- 对置信度诚实——把证据充分的习惯与一次性好奇分开。
- 它是一面出于好奇提供的镜子——目标是自我认知，不是评分，也不是指令。
设计记忆不做什么
- 它不会把偏好作为约束传给 design-lead、design-strategist 或任何智能体。
- 它不会门控或引导构建。流程依据简报、人物角色、design-taste（你为本项目提供的实时方向）以及任何 DESIGN.md 运行。
- 它不会覆盖甚至轻微影响项目决策。如果过去的习惯相关，由用户提出；系统不会悄悄应用它。
这是刻意的设计：由于从不反馈，记录可以跨截然不同的客户积累，而不会污染新项目。观察之所以安全，正因为它是不起作用的。
集成
- 被调用方：using-designpowers（可能提供报告）、design-state/design-retrospective（项目结束时，用于添加观察）
- 读取自：design-state.md、交接链、用户覆盖——用于观察，而非提取约束
- 写入到：~/.designpowers/taste-profile.md（观察记录）
- 不告知：智能体或构建——这是设计使然
- 区别于：design-taste（你当前项目的实时美学方向，会被应用）和 design-md（客户的品牌规范，会被应用）。设计记忆只观察。
反模式
| 模式 | 为何失败 |
|---|---|
| 把记录作为约束反馈到构建中 | 这是旧的规定性模型。记录是描述性的——悄悄应用它正是我们要避免的污染 |
| 把客户的品牌要求记录为用户品味 | 客户的 DESIGN.md 是那个客户的，不是用户的工作方式。只记录关于用户如何决策的可迁移观察 |
| 把观察表述为规则（"总是使用 X"） | 它是日志，不是规则手册。"倾向于 X（3 个项目）"是诚实的；"总是使用 X"是系统不应发出的指令 |
| 记录每一个决策 | 大多数选择是情境性的。只记那些揭示用户工作方式的内容 |
| 把记录当作评分 | 它是出于好奇提供的镜子，不是记分卡 |