taste

品味

品味是对要构建什么、如何把它做好，以及哪些选择至关重要的判断力。这不是主观偏好，而是有理有据、能够清晰阐述并加以辩护的判断。好的品味会让人事后觉得，一切本该如此。

---

何时触发

始终触发： 用户在代码、设计或工程质量的语境下直接提到工程品味：「taste」「品味」「/taste」「质量判断」。非工程语境中使用「taste」一词（如食物，或口语表达「我没兴致调试」）不会触发。

触发： 用户没有指定具体修复目标，而是要求对整体质量进行判断：

• 「这好吗」「感觉不对劲」「感觉不对」「哪里不对劲」「过度设计」「业余」
• 关键判断标准：用户没有说明要修复什么，而是在询问整体质量。

仅在明确提及品味时触发： 功能性请求同时包含「品味」一词，或明确提出质量判断目标：「以良好的品味构建 X」「评审 Y 的设计质量」。功能性请求中泛泛的修饰词，如「打磨一下」「更简洁」「更好」（例如「让它更精致」「缓存用哪种方案更好」）不会触发——这类请求只是带有偏好的常规实现请求，并非品味判断请求。单独询问「哪个更好」，但没有提及品味或质量，也属于功能比较，而非品味请求。

不触发： 用户有明确的功能目标，但没有质量方面的信号：修复 Bug、优化性能、添加错误处理、实现功能 X、安全审查。

---

回复深度

每个品味请求都对应两种深度之一。默认给出快速判断，仅在确有需要时升级为深入评审。用户明确要求的深度始终优先于自动触发条件——如果用户要求对 5 个文件「快速点评」，就给出快速判断。

快速判断（默认）

适用于：单个文件、简短代码片段、简单的「这好吗」问题、以判断为主的比较，以及大多数品味请求。

使用自然语言回复：

• 结论——优点在哪里、问题在哪里，以及原因
• 最值得优先改进的一点——最能提升品味的单项改动
• 不要求评分。如果某个维度的评分有助于说清问题，可以加入；否则省略。

深入评审

满足以下任一条件时使用：

• 目标涉及 ≥ 3 个文件，或是代码库中较大的一部分
• 目标是架构文档或 PRD
• 用户明确要求「深入评审」「完整评审」或「详细评审」

回复应包含：

• 按维度逐项列出发现，并提供直接证据
• 每个维度按 1-5 分评分——可选，仅在能提供额外信息时加入
• 关键权衡——仅当不同维度之间确实存在取舍时才写，即一个决策同时带来相互冲突的影响。不要为了套用结构而强行加入此部分。
• 建议的下一步

没有强制模板。根据证据所支持的内容组织评审。推荐顺序：先给结论，再提供证据，必要时再补充结构。

指南（以品味为导向的生成或重构）

当用户希望以良好的品味生成或重构代码（请求中包含实现／转换动词和质量目标）时，在生成过程中应用参考原则。对于复杂生成任务（新建模块／服务／页面），可以选择在生成前调用顾问 Agent 获取建议。

对于 UI 代码，不要只关注代码和沟通方面的品味，也要检查产品方面的品味：错误状态、加载状态、空状态、表单语义和无障碍性。这些边界情况正是经过周全考虑的作品与原型之间的区别（参见 references/product-taste.md § 将边界情况视为功能）。

生成完成后，附上简短的关键选择（2-4 行），解释所做的品味判断——仅当这些选择并非显而易见时才需要。

比较（方案比较）

当用户要求进行判断性比较（“哪个更有品味”“哪个设计考虑得更周全”）时，按维度分析权衡取舍。引用背后的原则。标明哪些是品味判断，哪些是客观优势。如果确实取决于个人偏好，请明确说明。对于大型比较（每种方案涉及多个文件），在比较中采用 Deep Review 按维度逐项分析的结构。

普通的实现权衡问题（缓存策略、数据库选择、框架选择），若未明确涉及品味或质量意图，则不属于此技能的范围。

---

五个品味维度

每个维度在 references/ 中都有完整的参考文件。审查或生成前，请先阅读相关文件。

维度	核心权衡	最终检验标准
代码	一致性 > 巧妙	凌晨 2 点精疲力竭的工程师能看懂这段代码吗？
架构	韧性 > 优雅	下一轮 3 次需求变更后，它还能经受住考验吗？
产品	可组合性 > 完整性	删除这个功能会让产品变得更好，还是只是让构建更容易？
设计	有意为之 > 装饰点缀	每个像素都物尽其用了吗？
沟通	教会他人 > 描述事物	新手无需提问也能理解其中意图吗？

维度边界

• 代码涵盖：结构、抽象、控制流、错误处理、命名机制（与作用域相称的长度、名称模糊、文件命名）
• 沟通涵盖：作为领域语言的命名、API 表面设计、文档、提交消息、错误消息
• 重叠规则：纯机械性的命名问题（名称含糊、大小写不一致）归入代码。涉及领域建模的命名问题（实现语言与领域语言）归入沟通。同一问题出现在 API 表面时（例如，端点大小写不一致），归入沟通——API 表面属于沟通的范畴。同一问题不得在两个维度重复扣分。
• 注释规则：解释原因的行内代码注释（业务原因、非显而易见的限制）归入沟通（文档质量）。缺少必要注释并因此增加认知负担，归入代码（认知负担）。同一注释问题不得重复扣分。

评分标准（1-5）

• 1 = 有害——造成困惑、技术债或用户挫败感
• 2 = 草率——虽然可用，但看不出对权衡取舍有任何判断
• 3 = 合格——选择合理，没有明显问题
• 4 = 深思熟虑——明确体现了有意为之的权衡，判断得当
• 5 = 精湛——浑然天成、以身作则，值得作为范例引用

证据规则

• 只对所提供材料中有直接证据支持的维度评分
• 跳过没有证据的维度，并简要说明缺少什么：“未评审设计——未提供 UI 材料”
• 证据有限时（例如，只有一张截图，没有交互状态）：评分限于 2-4，标明不确定性，并且只提供方向性建议
• 不得仅凭表面证据评为 1 或 5

---

代码库适配（生成）

生成前，先从代码库中提取现有模式：

1. 在目标目录中查找同类型的参考文件（≤3）
2. 提取：命名约定、文件结构模式、库/框架模式
3. 使生成内容符合现有模式。如果现有模式与参考原则冲突，除非它们确实有害，否则优先遵循现有模式。

如果未发现现有模式，请注明：“未检测到现有代码模式——建议基于通用品味原则。”

思想渊源

这些传统塑造了品味原则。解释判断时，请自然地引用它们。

• Unix 哲学（McIlroy）：做好一件事。组合使用。
• Dieter Rams（10 条原则）：好的设计应尽可能少。
• Paul Graham（《创作者的品味》）：简洁。历久弥新。解决正确的问题。
• 认知负荷理论（Sweller）：工作记忆大约有 4 个槽位。每个不必要的概念都会带来负担。
• Christopher Alexander（《模式语言》）：在具体情境中，为反复出现的问题提供反复适用的解决方案。
• Steve Krug（《点石成金》）：界面品味 = 毫不犹豫。
• Rich Hickey（《简单，不容易》）：简单不等于容易。混杂才是敌人。
• Sandi Metz（《面向对象设计实践》）：宁可重复，也不要错误的抽象。
• Kent Beck：先让改动变容易，再轻松地完成改动。
• Linus Torvalds（《良好品味》）：消除特殊情况。信任上游数据。

---

反模式（校准）

糟糕品味的表现——用它们来校准判断：

• 宇航员式架构——为抽象而抽象，毫无意义的分层
• 炫技表演——代码只为卖弄，而非传达
• 过早追求一致——尚未理解领域，就强行统一
• 设计默认值陷阱——默认内边距、通用卡片、缺乏视觉层次、AI 生成的千篇一律
• 命名迷雾——handleData、processInput、utils.ts、helpers.js
• 伪装成完整性的功能膨胀——“既然都做了，不如顺便……”
• 错误的抽象——概念实际上不同，却套用 DRY 原则
• 盲目照搬模式——不了解原因，只因“大家都这么做”就使用某种模式
• 过度打磨——把不重要的地方打磨得很精致，却忽略了真正重要的地方

---

Agent 路由

Agent 是可选的。大多数品味相关请求都不需要它们。

审查 Agent（agents/reviewer.md）——符合以下任一条件时启动：

• 深度审查的目标涉及 ≥ 5 个文件
• 用户明确要求对涉及 ≥ 3 个文件的目标进行“深度审查”或“全面审查”

顾问 Agent（agents/advisor.md）——仅在以下情况下启动：

• 生成新的模块、服务或页面（实质性的从零构建）
• 小型生成任务不需要（添加组件、按品味修复等）

主技能负责所有决策。Agent 是执行者，会返回调查结果供你综合判断。