开发者品味：从抽象到可沉淀
灵犀的记忆系统有一条硬约束：所有写入记忆库的内容，必须先经过 taste-recognition。
本文讲清楚三件事：我们如何理解「品味」、为什么要把品味拆成若干可操作类型、以及这套拆解如何让 AI 真正「按你的方式做事」。读者将理解「品味」的可操作定义、九类可沉淀内容的设计动机，以及 taste-recognition 在识别、升维与契约上的职责边界。
一、品味为何重要，又为何难以「直接记住」
在 AI 协作里，长期质量往往不取决于模型会不会写代码，而取决于它是否贯彻你的判断：在多种方案里选哪个、在什么场景下坚持什么原则、哪些事不要做。
这些判断很少以完整条文出现，更多散落在对话里——一句「别那样写」、一次方案选择、一次纠正。若不做提炼就塞进记忆，要么随会话消失，要么变成难以检索的噪音。
因此，我们不能把「品味」当成笼统标签，而要追问：究竟哪些种类的判断值得被记住、且能被稳定识别与复用？ 答案不可能是一句「所有你觉得重要的东西」——那会带来识别不准、写入随意、检索失效。我们需要一套可枚举、可识别的沉淀范围，让「品味」从抽象感受变成可操作的记忆类型。下一节先给出统一的表达形态，再在第三节展开类型拆解。
二、品味的可操作定义：场景 + 原则候选 + 实际选择
在灵犀里，品味有一个统一的结构，无论具体属于哪一类内容：
- 场景：在某个情境下（何时、何类）
- 原则候选：一组可能适用甚至冲突的选项
- 实际选择：用户采用的选择与权衡（可含理由或证据）
简写为：场景 + 原则候选 + 实际选择。
这样设计的原因：
- 场景决定「什么时候这条记忆该被加载」；没有场景，检索就难以命中。
- 原则候选 + 实际选择表达「在哪些选项里选了啥」，而不是孤立的结论；既保留对比（未来可类比），又便于治理时判断 merge/replace。
因此，taste-recognition 的识别目标始终是：从用户输入中抽出「场景 + 原则候选 + 实际选择」，必要时补上证据（用户原文），再经模式靠拢与升维判定，产出唯一合法的扩展 payload。
但「可沉淀」涵盖的范围很宽。要提升识别准确率，并让不同内容在检索与治理中有据可依，就必须对沉淀范围做类型拆解。下一节展开这份拆解。
三、品味的具象化：我们沉淀哪几类内容
「品味」在日常语感里很宽：偏好、经验、知识、禁忌……若不做拆解，识别阶段就难以区分「这是一次性吐槽」和「这是一条可复用的原则」。
灵犀将可沉淀内容收敛为九类，每类有明确边界、对应的记忆形态（Note Kind）及典型用户信号。目的不是给用户增加分类负担，而是让系统（及负责识别的 Agent）知道：在听到什么时该往哪一类靠；在写入与检索时，不同类型可以有不同的策略。
3.1 九类可沉淀内容
| 类型 | 含义 | 为何单独成类 |
|---|---|---|
| 偏好 | 在特定情境下「要/不要」的稳定选择（风格、工具、表述、流程），可无深层理由。 | 出现频率高、常无显式备选；需与「决策」区分，避免把随口偏好当成重大取舍。 |
| 决策经验 | 在若干选项中做过取舍，且带有情境、理由、备选与结果（或预期）。 | 有 alternatives 和理由，对未来类似决策参考价值大；升维时对 D1/D2 有单独指引。 |
| 领域知识 | 某领域的术语、概念、约定、最佳实践、常见坑与排障路径（可验证、可复用）。 | 偏事实与规则，强调可验证性（D3）；检索时关键词路径权重要足。 |
| 产品/业务知识 | 产品语义、业务规则、验收标准、边界条件。 | 与需求、验收、边界讨论强绑定；常需与 task/review 的验收标准协同。 |
| 行业/组织经验 | 行业惯例、合规约束、组织内约定、协作方式。 | 常跨项目复用，适合写入 share；信号上多带「我们公司/团队」。 |
| 启发式 | 「在 X 情况下通常 Y」「遇到 A 先看 B」等可复用规则，未必有严格证明。 | 介于偏好与模式之间；可经 pattern-catalog 的「经验法则」做模式靠拢并提升 D2。 |
| 模式 | 可命名的设计/工程/协作模式及其适用场景。 | 已有 pattern-catalog；匹配后填写 patternHint，When to load 可沿用目录表述。 |
| 反例与约束 | 明确「不要」「这里不用」「例外」的禁止与边界。 | 用 Counter-signals 与 One-liner 表达禁止；检索时需高情境匹配，避免误用。 |
| 排障与根因 | 某类问题的典型表现、排查顺序、根因与可复现步骤。 | 须可复现、可迁移到同类问题；D4 稳定性高时更适合沉淀。 |
3.2 类型与实现的对应关系
九类在实现上不新增 payload 字段，而是通过 Kind、When to load、One-liner、Context/Decision 等约定区分。识别时按类型匹配用户信号（如「选了 X 因为」「不要…」「遇到 X 就先看 Y」），升维时按类型做评分指引（如决策经验看 alternatives，领域/排障侧重 D3/D4）。
于是，「品味」不再是一个模糊集合，而是可枚举的类型 + 统一结构（场景 + 原则候选 + 实际选择）：既保留思想的开放性，又让识别与检索有据可依。有了类型拆解，taste-recognition 的管道就可以按类型做识别与升维——下一节说明这条管道如何工作。
四、taste-recognition 的管道：识别、升维与契约
taste-recognition 不写入记忆库，也不做冲突治理（merge/replace 由下游 lingxi-memory-write 负责）。它只做一件事：判断当前输入里有没有可沉淀的品味；若有，则产出符合契约的 payload；若无或判定不写，则静默。
内部是一条固定管道，共四步：
1. 识别
依据用户消息（及必要时最近 1～2 轮上下文），按内容类型判断是否存在可沉淀信号。九类各有典型表述，例如：偏好（「喜欢/习惯/不要」）、决策经验（「选了 X 因为」）、行业/组织（「我们团队一律」）等。
无可沉淀 → 静默返回，不产出 payload，不调用 lingxi-memory-write。
2. 模式靠拢
对可沉淀条目标抽 scene、principles、choice、evidence，再对照设计模式目录（策略模式、约定优于配置、分层架构、经验法则等）尝试映射。若匹配，则用模式名或「模式名 + 约束」改写 principles/choice，并填写 patternHint、patternConfidence；收敛到模式后更易被检索，且升维时 D2 至少为 1。
3. 价值判定（升维）
对内容做升维判定（D1 决策增益、D2 可复用/可触发、D3 可验证性、D4 稳定性），并按内容类型做评分指引（如决策经验有 alternatives 时 D1/D2 至少 1，领域/排障侧重 D3/D4）。
T ≤ 3 或触犯例外 → 不写该条：不产出该条 payload，不加入 payloads 数组。只有 T ≥ 4 且未触犯例外的条目才进入下一步。
4. 产出
对判定为写的条目标注 layer（L0/L1/L0+L1）、可选 l0OneLiner/l1OneLiner，产出符合扩展 payload 规范的 JSON；同一轮多条组成 payloads 数组。仅当 payloads 非空时，主 Agent 才会把 payloads 数组传给 lingxi-memory-write。
小结：识别（按类型）→ 模式靠拢 → 升维判定（按类型指引）→ 仅对「值得写」的产出 payload；不写则整条管道静默，记忆库不受影响。
五、多入口，同一契约
taste-recognition 并不只在 /remember 时工作；所有「可能写入记忆」的路径都会经过它：
| 触发点 | 输入来源 | payload.source |
|---|---|---|
/remember | 当前轮用户输入或用户指定的「要记住的内容」 | remember |
| 自动会话提炼 | 已完结会话的完整对话（新会话时若距上次提炼 >30 分钟自动入队，由后台子代理获取） | heartbeat |
/init 写入 | 用户确认后的初始化草稿 | init |
| 工作流品味嗅探 | task / plan / build / review 等环节经 ask-questions 收集到的选择（详见 品味嗅探） | choice |
无论从哪个入口进入，都走同一套类型识别与升维逻辑，输出同一套扩展 payload 契约。这样记忆库里的每条笔记形态一致，治理（TopK、merge/replace/veto）和检索才能稳定生效。不同类型在检索阶段可做差异化策略（如偏好/反例求高精度，领域/排障求高召回）；当前实现仍为统一双路径，策略约定见 记忆系统 与主仓 memory-retrieve 文档。
六、输出形态与下游边界
下游 lingxi-memory-write 只接受 payloads 数组（元素为扩展 payload）；不产候选，也不接受原始对话。
单条 payload 的必填与可选字段见主仓 taste-recognition SKILL。与「品味」直接相关的主要字段如下：
| 字段 | 含义 |
|---|---|
| scene / principles / choice | 对应「场景 + 原则候选 + 实际选择」；principles 与 choice 共同表达「在哪些候选中选了啥」。 |
| evidence | 可选的一句用户原文，用于可验证性与 L0 事实层。 |
| layer | 由本 Skill 在升维判定中填写（L0 / L1 / L0+L1），表示该写成事实层、原则层还是双层。 |
| l0OneLiner / l1OneLiner | 可选，供下游直接写入 note，便于检索与注入。 |
升维（写/不写、L0/L1）全部在 taste-recognition 内完成；lingxi-memory-write 不执行识别、不执行评分或升维，只按 payload 映射、治理与门控后写入。
职责边界：能不能进记忆库、以什么形态进，由 taste-recognition 决定；进到哪条 note、是否合并/替换、是否弹门控，由 lingxi-memory-write 决定；何时触发执行义务（pre/post/both）由 note 的 TriggerTiming 与检索时序（步骤 C / 步骤 D）决定。
七、小结：品味即可复用的判断结构
把「品味」具象化为九类可沉淀内容，不是为了限制你能记什么，而是为了达成三件事，与开篇呼应：
让隐性判断变成可检索的决策结构
只沉淀「场景 + 原则候选 + 实际选择」形态的内容，并明确每一类对应的 Kind 与书写约定，记忆库才能在未来对话里被稳定命中、按你的方式复用。在入口就做价值过滤
通过类型识别与升维判定，低价值或一次性内容不会产出 payload，也就不会进入记忆库，从源头控制噪音。为识别与检索提供同一套「地图」
类型表既是识别时的信号指引，也是写入时 Kind/When to load 的约定，未来还可支撑按类型差异化的检索策略；同一套类型体系贯穿识别、写入与检索。
因此，「品味识别」不是给对话打标签，而是为记忆系统提供唯一合法的输入形态，并只放行值得长期复用的判断与原则；「品味的类型拆解」则把这份输入形态从模糊的「重要的事」收敛为可枚举、可识别的九类，让心有灵犀真正可操作。
相关链接
- 记忆系统 — 记忆写入、检索与治理的整体流程
- 记忆治理与写入 —
lingxi-memory-write的职责与治理逻辑 - 主仓 taste-recognition SKILL — 完整 payload 规范与 References
- 主仓 content-types — 九类定义、与 Kind 映射及格式约定