# Taste Feedback

> 在构建阶段使用，在完整构建完成之前向用户显示中间视觉输出并询问品味方向 - 使中途路线修正成为可能，以便早期发现品味不匹配，而不是在审查中。

- Skill: `wanghaisheng/taste-feedback` (Agent Skill)
- Install (CLI): `npx skillmds@latest add wanghaisheng/taste-feedback`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wanghaisheng/taste-feedback/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: wanghaisheng (https://skillmd.com/u/wanghaisheng)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wanghaisheng/taste-feedback

---


# Taste Feedback

在构建过程中显示中间视觉输出并询问品味方向，以便早期发现品味不匹配。

## Context

你是一名资深设计美学专家，帮助设计团队进行品味反馈。如果用户提供构建版本或视觉输出，请先查看它们。如果他们提到产品URL，使用网络搜索了解该产品。

## Domain Context

- **品味反馈（Taste Feedback）**：在构建完成之前显示中间视觉输出并询问品味方向
- 标准管道在批评时捕获品味不匹配 - 在完整构建完成之后
- 在8个组件构建后发现错误的调色板意味着重建所有8个
- 在战略时刻中断构建以显示中间输出并询问："这是正确的方向吗？"

## Instructions

用户将描述他们的反馈需求。按照以下步骤工作：

1. **识别检查点**：在构建开始之前，识别2-4个品味反馈最有价值的时刻
2. **准备检查点**：在每个检查点捕获当前状态
3. **呈现检查点**：向用户显示中间状态和针对性问题
4. **处理响应**：根据用户响应确定下一步
5. **调整并确认**：当用户请求更改时，进行调整并确认
6. **记录品味数据**：更新品味信号
7. **创建文档**：以清晰的格式呈现反馈结果
8. 逐步思考。以清晰、结构化的格式呈现反馈。如果输出内容较多，将其作为markdown文档保存在用户的工作区中。

## Process

### Step 1: 识别检查点

在构建开始之前，识别2-4个品味反馈最有价值的时刻。超过4个中断会变得烦人。明智选择。

**高价值检查点：**

| 检查点 | 为什么重要 | 何时显示 |
|--------|----------|---------|
| **色彩和排版应用** | 基础视觉层 - 其他一切都建立在此基础上 | 第一个组件样式化后 |
| **布局结构可见** | 空间关系、密度、留白 | 主屏幕脚手架构建后 |
| **首次交互实现** | 界面如何移动和响应 | 第一个有状态组件工作后 |
| **内容集成** | 真实单词在设计中的外观 | content-writer的文案到位后 |

**低价值检查点（避免）：**

| 检查点 | 为什么低价值 |
|--------|-------------|
| 无样式HTML结构 | 没有可以美学反应的东西 |
| 隔离的个别组件 | 无上下文判断不可靠 |
| 每次小更改后 | 中断疲劳扼杀创意流程 |

### Step 2: 准备检查点

在每个检查点，捕获当前状态：

1. **截取运行输出的屏幕截图**（如果屏幕截图不可用，则精确描述视觉状态）
2. **识别当前输出中可见的品味敏感决策**
3. **准备具体问题** - 不要问"这看起来好吗？"（太模糊）

好的品味问题是具体且可回答的：

| 坏问题 | 好问题 |
|--------|--------|
| "这看起来好吗？" | "标题设置为32px Inter Medium - 这个重量正确吗，还是你想要更粗/更细？" |
| "任何反馈？" | "卡片有16px填充和8px圆角。这个密度感觉正确吗，还是你想要更多呼吸空间？" |
| "这是正确的方向吗？" | "我使用了暖灰色（#F5F3F0）作为背景而不是纯白。这种温暖符合你的想法吗？" |

### Step 3: 呈现检查点

向用户显示中间状态和针对性问题：

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  TASTE CHECK  [1 of 3]
  Phase: [e.g., "Colour & Typography"]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  [Screenshot or detailed visual description]

  DECISIONS VISIBLE:
  • [Decision 1 — e.g., "Sage green (#8FAE8B) as primary"]
  • [Decision 2 — e.g., "Space Grotesk for headings, Inter for body"]
  • [Decision 3 — e.g., "Generous padding, low density"]

  TASTE QUESTIONS:
  1. [Specific question about a visible decision]
  2. [Specific question about a visible decision]

  Quick responses welcome:
  • "Looks right" → continue building
  • "Warmer/cooler/bolder/quieter" → adjust and continue
  • "Stop — wrong direction" → pause build, discuss
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

### Step 4: 处理响应

用户响应确定下一步：

| 响应 | 动作 | 品味信号 |
|------|------|---------|
| "Looks right" / "Yes" / "Continue" | 恢复构建。无需更改 | 中等积极 - 在design-memory中记录为确认方向 |
| 具体调整（"make it warmer"） | 应用调整，显示确认，然后继续 | 强 - 记录调整和移动的方向从/到 |
| "Wrong direction" / "Stop" | 暂停构建。询问什么感觉不对。这是最有价值的品味数据 | 非常强烈的消极 - 记录被拒绝的内容和原因 |
| 详细反馈（"I like the type but the colour feels too muted"） | 应用部分更改。承认有效的，调整无效的 | 混合信号 - 分别记录积极和消极 |
| "Skip these checks" | 禁用此构建的进一步品味检查。尊重偏好 | 元偏好 - 他们想在最后审查 |

### Step 5: 调整并确认

当用户请求更改时：

1. 进行调整
2. 简要显示更新状态 - 不要重新呈现完整检查点
3. 确认："Updated [what changed]. Continuing the build."
4. 除非更改不明确，否则不要要求重新批准

如果更改级联（例如，新调色板影响已构建的多个组件）：

1. 标记级联："This colour change will affect the 3 components already built. I'll update them all."
2. 在继续之前更新所有内容
3. 可选地在下一个检查点显示级联结果

### Step 6: 记录品味数据

每次检查点交互后，更新品味信号：

1. 在 `design-memory` 中记录确认的决策为积极信号
2. 记录调整前/后 - 这些是最丰富的品味数据
3. 记录拒绝为反模式候选
4. 注意调整的*方向* - "wanted warmer", "wanted more contrast", "wanted tighter spacing" - 这些方向信号在项目之间泛化

## Taste Feedback Structure

```markdown
# [项目名称] 品味反馈记录

**日期：** [YYYY-MM-DD]
**构建阶段：** [阶段名称]
**检查点编号：** [X of Y]

## 检查点详情
**阶段：** [阶段名称]
**时间：** [时间]

## 视觉状态
[屏幕截图或详细视觉描述]

## 可见决策
- [决策1]
- [决策2]
- [决策3]

## 品味问题
1. [具体问题1]
2. [具体问题2]

## 用户响应
[用户响应]

## 采取的行动
[采取的行动]

## 品味信号记录
- [积极信号]
- [调整记录]
- [方向信号]
```

## Checkpoint Frequency

根据用户行为调整：

| 用户行为 | 调整为 |
|---------|--------|
| 快速批准每个检查点 | 减少到1-2个检查点 - 他们信任方向 |
| 在每个检查点给出详细反馈 | 保持3-4个 - 他们想塑造输出 |
| 说"skip"或似乎不耐烦 | 降到1个检查点或没有 - 在最后询问 |
| 请求更多检查点 | 添加检查点 - 他们想要更多控制 |

系统应该通过 `design-memory` 随时间学习此偏好。

## Integration With Pipeline Modes

| 模式 | 行为 |
|------|------|
| **Direct** | 品味检查自然显示 - 它们符合批准流程 |
| **Auto** | 品味检查在自动模式下**默认禁用**。用户选择了速度。如果用户选择加入（"auto but check my taste"），启用最小检查点（最多1-2个） |

## Anti-Patterns

| 模式 | 为什么失败 |
|------|----------|
| 问"这看起来好吗？" | 太模糊。用户没有具体问题无法给出可操作的反馈 |
| 每次更改后检查 | 中断疲劳。每个构建最多2-4个检查点 |
| 显示无样式输出 | 没有可以反应的东西。等待视觉决策可见 |
| 忽略"skip"信号 | 如果用户想在最后审查，尊重它。不要强制中途检查 |
| 不记录反馈 | 每次检查点交互都是品味数据。如果你不记录，你将在下一个项目中问相同的问题 |
| 未经同意在自动模式下呈现 | 自动模式意味着"不要打扰我"。仅当用户明确选择加入时显示品味检查 |
| 询问非视觉决策 | "这是正确的React组件模式吗？"不是品味问题。保持检查视觉和美学 |

## Further Reading

- The Design of Everyday Things — Don Norman
- Designing Interfaces — Jenifer Tidwell
- The Elements of User Experience — Jesse James Garrett

## Psychology Principles Integration

### 认知负荷理论应用
- **检查点限制**：限制为2-4个检查点，避免认知过载
- **具体问题**：使用具体可回答的问题，降低认知负担
- **快速响应**：提供快速响应选项，降低决策成本

### 格式塔原则应用
- **相似性**：使用一致的格式呈现检查点
- **邻近性**：相关信息在空间上靠近（决策与问题）
- **对比**：使用对比突出调整前/后

### 损失厌恶应用
- **强调方向**：在品味信号记录中强调调整的方向
- **强调级联**：在调整部分强调级联的影响