| name | code-taste-review |
| description | 代码品味提炼工作流。系统性地审查项目代码，按业务重要度、复杂度、可扩展性、性能要求 四个维度分优先级分组，引导用户 review 后提炼出个人代码品味和编程偏好。 当用户提到"代码品味"、"code taste"、"提炼品味"、"review代码品味"、 "梳理代码理念"、"总结编码偏好"、"记录代码审美"时触发。 即使用户只是说"帮我 review 一下代码质量"或"看看这代码写得怎么样"， 如果语境偏向品味和偏好而非找 bug，也应使用此技能。
|
代码品味提炼
通过多轮 review 会话，逐步提炼用户在编码风格、架构选择、抽象层次等方面的个人品味。
品味不是一次性产出的——每次 review 沉淀一小部分，最终积累成完整的编码哲学。
目录结构
~/.codetaste/
├── essence.md # 跨语言根本原则（四条元原则）
├── <lang>/
│ ├── taste.md # 按语言沉淀的品味索引（原则/偏好/反模式）
│ ├── principles.md # 原则详细描述
│ ├── preferences.md # 偏好详细描述
│ ├── anti-patterns.md # 反模式详细描述
│ └── lint/ # 自动化检查脚本
│ ├── check.sh # 总入口
│ ├── init-lint.sh # 项目集成脚本
│ └── rules/ # 具体规则脚本
├── review/
│ └── <yyyy-MM-dd>/ # 每次会话一个目录
│ ├── session.json # 会话元数据
│ ├── file_inventory.md # 项目文件清单 + review 状态
│ ├── groups.md # TOP 3 分组索引
│ ├── my_review.md # 用户 review 记录（用户填写）
│ └── taste_extracted.md # 本次提炼结果
└── bin/ # 工具脚本
├── update-inventory.sh # 从 session.json 更新 file_inventory.md
└── migrate.sh # 旧路径迁移工具
模板文件
以下模板位于 skill 目录下的 templates/ 中，创建新会话时参照：
入口判断
用户触发此技能时，先判断当前处于哪个阶段：
- 阶段一（步骤 1-4）：用户说"开始 review"、"提炼代码品味"、"开始品味 review"
- 阶段二（步骤 5）：展示分组，等待用户写
my_review.md
- 阶段三（步骤 6-9）：用户说"提炼品味"、"我写完了 review"、"帮我整理品味"
- 进度查询：用户说"review 进度"、"还剩多少文件"
阶段一：启动 Review
步骤 1：扫描项目文件
扫描当前项目目录的所有源代码文件。
包含：src/、lib/、app/、internal/、cmd/、pkg/ 等业务代码目录下的源文件。
排除：node_modules/、dist/、build/、vendor/、.git/、__pycache__/、测试 fixture、生成的代码（如 *.generated.*、*.pb.go）、锁文件、配置文件（如 webpack.config.*）。
对每个文件记录：相对路径、语言、行数（大致）。
步骤 2：检查 Review 历史
扫描 ~/.codetaste/review/ 下所有已有目录，读取每个 session.json 和 file_inventory.md，汇总哪些文件已被 review 过以及最后 review 日期。
日期冲突处理：如果今天日期的目录已存在，追加序号 -2、-3。
步骤 3：创建 Review 会话
创建 review 目录，参照 session.json 模板 写入 session.json。
参照 file_inventory.md 模板 生成文件清单。
步骤 4：分组排序
对 未 review 的文件 按 4 个维度评分（1-5 分）：
| 维度 | 权重 | 评估依据 |
|---|
| 业务重要程度 | 0.3 | 模块在核心请求链路中的位置、被依赖的数量 |
| 代码复杂程度 | 0.2 | 逻辑分支密度、函数长度、嵌套深度 |
| 可扩展性要求 | 0.3 | 未来变更的可能性、配置化程度、接口抽象度 |
| 性能要求 | 0.2 | I/O 密集度、数据处理量、延迟敏感度 |
综合得分 = Σ(维度分数 × 权重)，按得分降序排列。
选出 TOP 3 分组，每组 4-5 个文件。分组时考虑文件的逻辑关联性（同模块、同层的文件归为一组），而非单纯按分数切割。
参照 groups.md 模板 写入。
完成步骤 4 后，进入阶段二。
阶段二：等待用户 Review
步骤 5：展示分组并等待
将 groups.md 的内容呈现给用户。告知用户：
- review 目录的位置
- 建议按分组顺序 review
- 在 review 目录下创建或编辑
my_review.md，写入 review 意见
Review 文件路径约定：用户可以逐组写 review，也可以全部写在一个文件中。支持的写法：
- 全部写在一个
my_review.md 中
- 按分组写
group1.md、group2.md、group3.md，再加上 my_review.md（额外 review 的文件）
- 直接在对话中口述 review 意见
my_review.md 是自由格式的文档。用户可以写任何想说的，例如：
- 对代码结构的赞赏或批评
- 命名风格的偏好
- 错误处理模式的看法
- 对抽象层次的判断
- 性能与可读性的权衡观点
- 具体的代码片段引用和点评
等待用户明确表示"写完了"、"提炼品味"后再进入阶段三。
阶段三：提炼品味
步骤 6：提取品味
- 读取所有 review 文件（
my_review.md、group*.md 等）
- 读取 review 中提及的源代码文件（需要对照原文理解用户的评价）
- 提取品味要素，按以下维度归类：
| 品味维度 | 关注点 |
|---|
| 结构与组织 | 文件组织、模块划分、依赖方向、层次分离 |
| 命名品味 | 变量、函数、类的命名风格，语义表达力 |
| 错误处理哲学 | 异常策略、错误传播、降级方案、日志记录 |
| 抽象层次 | 何时抽象、抽象粒度、接口设计 |
| 性能意识 | 在何处关注性能、如何权衡性能与可读性 |
| 可读性标准 | 注释风格、代码密度、表达力、一致性 |
| 测试态度 | 测试策略、覆盖偏好、mock 与真实的选择 |
-
按三级分类组织：
- 原则（不可违背）— 用户用强烈语气表达的要求
- 偏好（推荐风格）— 用户倾向但认可有例外的情况
- 反模式（明确否定）— 用户明确不认可的做法
-
标注理由和来源
步骤 6b：去重检查
读取 ~/.codetaste/<lang>/taste.md（以及 principles.md、preferences.md、anti-patterns.md），将提取结果与已有条目交叉比对：
- 完全重复的条目：不重复写入，可选更新描述
- 部分重叠的条目：合并描述，保留更丰富的表述
- 全新条目：标记为新增
在 taste_extracted.md 底部增加去重检查表，记录每条提取结果与已有品味的对比。
参照 taste_extracted.md 模板。
步骤 7：essence.md 交叉验证
读取 ~/.codetaste/essence.md，验证本次提取的所有品味条目能否归入已有的元原则（通常为四条）。
四条元原则：
- 显式优于隐式
- 一条路径一个关注点
- 信任止于边界
- 反馈不破坏系统
对每条品味条目：
- 如果能归入某条元原则：标注对应关系
- 如果无法归入：思考是否需要新增元原则（需要非常强的理由）
将验证结果追加到 taste_extracted.md。
同步更新 essence.md：
- 为新增条目在对应元原则下补充语言特定的表述
- 补充量化标准（如果有新的可量化阈值被提炼出来）
- 更新自动化能力分析表
步骤 8：合并沉淀
将去重后的新品味合并到 ~/.codetaste/<lang>/ 下的对应文件：
taste.md — 更新索引（添加新条目，更新 Lint 列链接）principles.md — 新增原则preferences.md — 新增偏好anti-patterns.md — 新增反模式
品味文档格式：
# <Language> 代码品味
> 最后更新：yyyy-MM-dd | 累计 review 次数：N
## 原则
### [P1: 原则名称]
**来源**: review/<date> | **强度**: 不可违背
<原则描述>
**正例**: <代码片段>
**反例**: <代码片段>（如果有）
## 偏好
### [B1: 偏好名称]
**来源**: review/<date> | **强度**: 推荐
<偏好描述>
**注意**: <例外情况>（如果有）
## 反模式
### [A1: 反模式名称]
**来源**: review/<date> | **强度**: 避免
<反模式描述>
**反面示例**: <代码片段>
步骤 9：Lint 生成（自动化项）
对本次提炼的品味条目，评估自动化可行性。可自动化项的标准：
- 有明确的量化阈值
- 可通过静态分析检测
- 判定规则无歧义
对可自动化项：
- 在
~/.codetaste/<lang>/lint/rules/ 下创建对应检测脚本
- 更新
~/.codetaste/<lang>/lint/check.sh 总入口，添加新规则
- 在
taste.md 的对应条目中添加 Lint 列，链接到脚本
脚本要求：
set -euo pipefail + export LC_ALL=C（确保 macOS 正则兼容）- 使用
变量=$((变量 + 1)) 而非 ((变量++))（避免 set -e 误杀）
- 支持
--warn / --error 阈值参数
- 输出格式：
LEVEL: file:line message
更新 session.json
提炼完成后更新状态：
{
"status": "completed",
"files_reviewed": ["src/proxy/openai.ts", "..."]
}
运行 bash ~/.codetaste/bin/update-inventory.sh <review目录> 自动更新 file_inventory.md。
进度查询
当用户问进度时：
- 读取所有
~/.codetaste/review/*/session.json
- 读取最新项目的
file_inventory.md
- 汇报：
- 总文件数 / 已 review / 未 review
- 已完成的 review 会话列表
- 已沉淀的品味条目数（按语言统计）
- 已有的 lint 规则数
- 建议下次从哪里继续
