> 品味 = 在选项出现之前就知道什么值得存在的预判能力。
> 来源：杨振宁/博杰/Paul Graham/Sarah Guo/Mio
品味如何 research <选题描述> — 研究选题审计（完整）品味如何 product <功能/方向> — 产品决策审计（完整）品味如何 quick research <选题描述> — 研究选题审计（快速，仅底座+核心门红黄绿+每道存疑门1条反诘）品味如何 quick product <功能/方向> — 产品决策审计（快速，同上）品味如何 calibrate — 定期品味校准| 维度 | 快速模式 (quick) | 完整模式（默认） |
|---|---|---|
| ------ | ------------------- | ---------------- |
| 底座扫描 | ✅ 4 条 | ✅ 4 条 + 详注 |
| 核心门 | ✅ 红黄绿 + 每道存疑门 1 条反诘 | ✅ 逐道详审 + 2-3 条反诘 |
| 辅助预警 | ❌ | ✅ |
| 末尾追问 | ❌ | ✅ |
| 交叉检测 | ❌ | ✅ |
| 结果落盘 | ✅ | ✅ |
| 适用场景 | 实时决策中的快速品味校准 | 深度复盘 / 重大决策前 |
规则：quick 模式下，底座扫描每条 ≤ 1 句话。输出控制在 15 行以内。不列辅助预警，不追问末尾——直接给判决和存疑项的反诘。
> ⚠️ 待实战验证（V1.4）：quick 模式在三次完整审计中一次未用。下次实时决策时主动用 quick 模式验证——15 行内能否给出有用结论？还是必须回退完整模式？
> 权重决定了黄灯时的处理方式。致命级黄灯 → 整体黄灯；警告级和打磨级黄灯 → 单独标注，整体可以绿。
| 门 | 权重 | 含义 |
|---|---|---|
| ---- | ------ | ------ |
| R1 Lead vs Follow | 🔴 致命级 | 方向错了全错 |
| R2 Novelty 可学性 | 🟡 警告级 | 不够新但方向可能对 |
| R3 别人做不了 | 🔴 致命级 | 谁都能做 = 没壁垒 |
| R4 更美更简单 | 🟡 警告级 | 丑但可能有效 |
| R5 愿景驱动 | 🔴 致命级 | 跟风 vs 愿景是方向性问题 |
| 门 | 权重 | 含义 |
|---|---|---|
| ---- | ------ | ------ |
| P1 值得存在 | 🔴 致命级 | 不该存在的东西直接否决 |
| P2 有代价 | 🟡 警告级 | 品味深浅问题，非存在问题 |
| P3 减法 | ⚪ 打磨级 | 粗糙但可能有用 |
| P4 细节 | ⚪ 打磨级 | 能用但不够精致 |
| P5 统一原则 | 🟡 警告级 | 拼盘感但可能逐步统一 |
有致命级红灯 → 🔴 整体红灯（不准继续）
有致命级黄灯 → 🟡 整体黄灯（必须关注）
仅有警告级/打磨级黄灯 → 🟢 整体绿灯 + 标注存疑项
全部绿灯 → 🟢
> 5 道门对不同阶段的项目应有不同权重。早期项目 P2-P4 降级为「建议过」，成熟项目恢复完整判定。
审计开始时，根据可用信息判断项目阶段：
| 信号 | 阶段 | 说明 |
|---|---|---|
| ------ | ------ | ------ |
| 无 CHANGELOG / 无设计文档 / DAY 标注 < 5 | 🟢 早期 | 刚启动，没机会付出代价 |
| CHANGELOG 存在且 < 30 天历史 | 🟡 中期 | 已有迭代，应该开始有取舍 |
| CHANGELOG > 30 天 / 版本号 > 3.x | 🔴 成熟 | 该付的代价应该已经付过了 |
无法判断时，默认按成熟阶段审计（宁严勿宽）。
| 阶段 | P1 值得存在 | P2 有代价 | P3 减法 | P4 细节 | P5 统一原则 |
|---|---|---|---|---|---|
| ------ | :-----------: | :---------: | :-------: | :-------: | :----------: |
| 早期 | 必须过 | 建议过 | 建议过 | 建议过 | 应该过 |
| 中期 | 必须过 | 应该过 | 应该过 | 应该过 | 必须过 |
| 成熟 | 必须过 | 必须过 | 必须过 | 必须过 | 必须过 |
规则：「建议过」→ 黄灯不计入整体判决，单独标注即可。「应该过」→ 黄灯计入警告级。「必须过」→ 原权重判定不变。
| 阶段 | R1 Lead/Follow | R2 Novelty | R3 别人做不了 | R4 以美启真 | R5 愿景驱动 |
|---|---|---|---|---|---|
| ------ | :--------------: | :----------: | :------------: | :----------: | :----------: |
| 早期 | 必须过 | 建议过 | 必须过 | 建议过 | 必须过 |
| 中期 | 必须过 | 应该过 | 必须过 | 应该过 | 必须过 |
| 成熟 | 必须过 | 必须过 | 必须过 | 必须过 | 必须过 |
> P3（减法/加法）判黄灯前，必须先查阅 CHANGELOG 或版本历史。P3 需要时间轴——只看当前状态会误判「一直在加」的项目。
| 文件结构 | 说明 |
|---|---|
| ------ | ------ |
| SKILL.md | 主文件 |
| CHANGELOG.md | 版本变更记录 |
| README.md | 项目说明 |
| DESIGN.md | 设计决策记录 |
| PRINCIPLES.md | 核心原则 |
| .consistency.yml | 自定义一致性规则 |
| references/ | 引用文档 |
| scripts/ | 脚本目录 |
> 底座 = 快速直觉扫描。仅作预警标注，最终裁决以核心门为准。 底座与核心门矛盾时，核心门胜出。
>
> 审计时在核心门前作为一个独立简短段落输出底座扫描结果。底座不单独触发反诘——反诘由核心门驱动。
审计前先快速过：
| # | 问题 |
|---|---|
| --- | ------ |
| G1 | 有没有更简单的方案还没被思考过？ |
| G2 | 是不是在勤奋但用错了方向？（在解决正确的问题吗？） |
| G3 | 有没有在修正一个众人视而不见的丑陋？够大胆吗？ |
| G4 | 这个方案是否带有某种不可名状的 "对"？（怪异=极致求真的副产品） |
输出格式：底座扫描以 4 行小表呈现（每行 ✅/⚠️），放在核心门仪表盘之前。示例：
| G1 更简单方案 | ✅ |
| G2 正确问题 | ✅ |
| G3 修正丑陋 | ⚠️ |
| G4 不可名状的对 | ✅ |
完整模式下每行可加半句注解；quick 模式下仅 ✅/⚠️ 标记。
输入 → 预处理（<20字反问）→ 交叉检测 → 底座扫描 → 仪表盘 → 逐道详审 → 辅助预警 → 判决 → 末尾追问+元审计
如果输入少于 20 字或不包含具体技术描述，先反问，不跑审计：
> "能不能用三句话描述：①你要解决什么问题 ②现在的方案为什么不够 ③你的方法有什么不同？"
核心门审计前，扫描输入是否包含产品特征信号。输入中含以下词汇 ≥ 3 个时，在核心门前标注提示（不阻止审计）：
> 用户 / 功能 / 界面 / 交互 / 插件 / 按钮 / 入口 / 体验 / 页面 / 前端 / UI / UX
标注格式：⚠️ 此输入包含产品特征，可能需要 product 模式审计。
| # | 门 | 问题 | 权重 | 来源 |
|---|---|---|---|---|
| --- | ----- | ------ | ------ | ------ |
| R1 | Lead vs Follow | 这个领域是萌芽期还是成熟期？你是第一个做的人之一，还是在追热点？ | 🔴 致命 | 博杰 |
| R2 | Novelty 可学性 | Reviewer 能不能从这篇工作中学到新东西？还是只在做性能提升？ | 🟡 警告 | 博杰 |
| R3 | 别人做不了 | 这个问题别人是不是根本没想到/做不了？还是任何人都能做只是还没人做？ | 🔴 致命 | 博杰/Peter Thiel |
| R4 | 更美更简单 | 有没有更简单/更美的路径？不美的方案大概率方向偏了。（杨振宁/狄拉克：以美启真） | 🟡 警告 | 杨振宁/PG#1 |
| R5 | 愿景驱动 | 选题是从愿景出发的（"实现愿景缺什么技术"），还是从热点出发的（"最近什么热"）？ | 🔴 致命 | 博杰/Elon Musk |
| # | 信号 |
|---|---|
| --- | ------ |
| R6 | 身边人的研究方向是什么级别的品味？（好品味成群出现） |
| R7 | 5 年后回头看，这个问题还重要吗？ |
底座扫描后，必须先输出核心门仪表盘（一张表，不含散文分析），再逐道详审。
仪表盘格式：
## 核心门仪表盘
| 门 | 权重 | 结果 |
|----|------|------|
| <门名> | <权重> | <🟢/🟡/🔴> |
🟢/🟡/🔴 <一句话判决>
仪表盘之后，逐道详审（散文格式，每道门一段分析 + 反诘（如有））。
判决格式：
项目阶段：<早期/中期/成熟>｜校准：<X 门降级为建议过>
quick 模式下仅输出仪表盘 + 判决行 + 存疑门各 1 条反诘，跳过逐道详审。
审计结束后，不管红黄绿，追加：
> 最小验证追问：你有没有用最小版本测试过用户反应？如果有，用户说了什么你没想到的？
追加元审计：
> 元审计：本次审计的标准是否适合这个项目的阶段？有没有哪个门在此时应降级？本次判断中哪些假设依赖推断而非事实？（列出 1-2 条）
输入 → 预处理（<20字反问）→ 交叉检测 → 底座扫描 → 仪表盘 → 逐道详审 → 辅助预警 → 判决 → 末尾追问+元审计
如果输入少于 20 字或不包含具体功能描述，先反问，不跑审计：
> "能不能用三句话描述：①这个功能解决什么问题 ②用户现在的替代方案是什么 ③为什么你的方案更好？"
核心门审计前，扫描输入是否包含研究特征信号。输入中含以下词汇 ≥ 3 个时，在核心门前标注提示（不阻止审计）：
> 模型 / 算法 / benchmark / 实验 / novelty / 理论 / 数学 / 论文 / 证明 / 数据集 / 指标 / 性能提升
标注格式：⚠️ 此输入包含研究特征，可能需要 research 模式审计。
| # | 门 | 问题 | 权重 | 来源 |
|---|---|---|---|---|
| --- | ----- | ------ | ------ | ------ |
| P1 | 值得存在吗 | 这个功能/产品值得存在吗？在"哪个更好"之前，先问"哪个值得存在"。大部分功能根本不值得存在。 | 🔴 致命 | Mio/Sarah Guo |
| P2 | 有代价吗 | 这个决策让你付出了什么代价？没代价的品味只是个人偏好。（代价 = 拒绝客户/砍掉已做的/选择更难的路线） | 🟡 警告 | Sarah Guo |
| P3 | 减法还是加法 | 这个决策是在加功能还是在砍功能？加法是本能，减法是修行。好品味团队的核心工作是大量删除。 | ⚪ 打磨 | Sarah Guo/Mio |
| P4 | 细节经得起放大镜吗 | 错误提示、加载状态、空状态、边缘情况——这些"用户永远不会感谢你"的地方做到位了吗？ | ⚪ 打磨 | Sarah Guo |
| P5 | 统一原则 | 能不能用一个原则解释这个产品所有的取舍？如果解释不清"为什么有A而没有B"，品味有问题。 | 🟡 警告 | PG#2/#3 |
| # | 信号 |
|---|---|
| --- | ------ |
| P6 | 模仿者是在复制功能，还是在永远抄不走？（品味 = 不可复制的壁垒） |
| P7 | 有没有追踪"愉悦债务"？（粗糙的动画/空状态/错误提示 = 债务在累积） |
| P8 | 团队自己是不是这个产品的日常用户？（不自用 = 不可能有品味） |
底座扫描后，必须先输出核心门仪表盘（一张表，不含散文分析），再逐道详审。
仪表盘格式：
## 核心门仪表盘
| 门 | 权重 | 结果 |
|----|------|------|
| <门名> | <权重> | <🟢/🟡/🔴> |
🟢/🟡/🔴 <一句话判决>
仪表盘之后，逐道详审（散文格式，每道门一段分析 + 反诘（如有））。
判决格式：
项目阶段：<早期/中期/成熟>｜校准：<X 门降级为建议过>
quick 模式下仅输出仪表盘 + 判决行 + 存疑门各 1 条反诘，跳过逐道详审。
审计结束后，不管红黄绿，追加：
> 迭代追问：这是第几版？你丢弃过几次？第一版几乎一定是错的。
追加元审计：
> 元审计：本次审计的标准是否适合这个项目的阶段？有没有哪个门在此时应降级？本次判断中哪些假设依赖推断而非事实？（列出 1-2 条）
每 1-2 周或每次重要决策后。
品味指数：⬆️ 上升 / ➡️ 持平 / ⬇️ 下降
关键信号：一句话。
本周最值得保留的品味决策：一个。
本周最危险的品味妥协：一个。
⚠️ 可疑模式：<择一>
- "无"（无异常）
- 全正向报告 → 可能不是品质好，是审计深度不够
- 数字过于精确 → 真实的品味判断通常是模糊的
audit-trail/ 目录。如果用户未显式指定项目，则写入当前 workbuddy workspace 的 .workbuddy/memory/ 下。格式：YYYY-MM-DD_taste-check.md。内容：日期、模式、对象、底座扫描摘要、核心门红黄绿结果、一句话判决、使用的反诘（如有）。落盘发生在审计输出之后、回复用户之前。目录不存在则创建之。> 当某道核心门失败/存疑时，从对应条目中选取 2~3 条反诘追加输出。
> 原则：不给答案，只把对方推向盲区。
| 门 | 失败信号 | 反诘 |
|---|---|---|
| ---- | --------- | ------ |
| R1 Lead vs Follow | 成熟期追热点 | 2 年前是谁先嗅到这个方向的？他们做了什么？/ 如果你在这个领域只能问一个别人还没意识到是问题的问题，那会是什么？/ 你和前人的本质区别是什么——方法？问题定义？假设？ |
| R2 Novelty | Reviewer 学不到新东西 | 如果用一句话告诉一个同行你发现了什么，他会说"哦"还是"哇"？/ 最有可能被 Reviewer 评为"incremental"的点是哪个？你认同这个评价吗？/ 如果必须删掉所有工程优化，剩下那一个 idea 是什么？ |
| R3 别人做不了 | 谁都能做 | 如果有人现在就复制你的方法，他卡在哪一步？/ 你拥有的什么（数据/洞察/能力/假设）是别人没有的？/ 如果这个问题明天被大厂用 10 倍资源攻克，你唯一的护城河是什么？ |
| R4 以美启真 | 方案丑陋/笨拙 | 用一个比喻描述你的方案——是"大刀阔斧"还是"精雕细琢"？哪一种更接近你内心的感觉？/ 一个外行凭直觉判断你的方案，会觉得优雅还是笨拙？/ 如果狄拉克看你的核心方程/方案，他会皱眉还是微笑？ |
| R5 愿景驱动 | 跟风热点 | 如果把当前热点全部删掉，这个方向还站得住吗？/ 10 年后你希望别人引用你这篇工作时，说的是什么？/ 这个选题和你相信的"终极问题"之间有什么连线？ |
| 门 | 失败信号 | 反诘 |
|---|---|---|
| ---- | --------- | ------ |
| P1 值得存在 | 功能无意义地存在 | 如果这个功能明天消失了，用户会主动来找你吗？/ 你是在解决一个"问题"，还是在填补一个"空白"？/ 这个功能是你想做的，还是用户真正需要的？区别在哪里？ |
| P2 有代价 | 没付出任何代价 | 你最近一次因为品味而拒绝的事情是什么？/ 如果不需要付出任何代价就能做对，是不是"对"的标准设得太低了？/ 这个决策如果错了，代价是什么？你准备好承担了吗？ |
| P3 减法 | 在加而非砍 | 如果这个产品只能做一件事、其他全砍掉，留下的那一件是什么？/ 过去一个月你砍掉的功能比加上的多吗？/ 最近一个被你删掉的"还不错"的功能是什么？ |
| P4 细节 | 粗糙的边缘 | 用一个没见过这个产品的人——他第一次用的时候最可能皱眉的三个瞬间是什么？/ 你上一次花超过一小时改一个用户可能注意不到的细节，是什么时候？/ 错误提示、加载状态、空状态——这三个里面哪个最差？ |
| P5 统一原则 | 功能拼盘 | 如果一个新成员问"为什么有A而没有B"，你能用一句话回答吗？/ 如果竞争对手复制了你的所有功能，还能复制什么？/ 有没有一个功能，放在你的产品里让你觉得"别扭"？ |
共 2 个版本