taste-code-review 是一套用于评审智能体生成代码的结构化方法，核心观点是“能跑只是底线”，评审应按轮次进行，而不能凭直觉。
用途 它面向由 AI 智能体生成或辅助生成的代码变更，提供一套可重复执行的评审流程，避免“看起来不错”式的主观放行。
评审顺序（固定，不可颠倒）
- 行为：是否真正实现功能，包括空状态、错误路径、重复点击、离线等边界情况；只覆盖正常路径的功能等于穿着功能外衣的 bug。
- 结构：代码是否放在该放的位置，文件与组件边界、单一职责、避免超长函数、导入整洁、无死代码。
- 品味：命名、重复、与代码库既有约定的一致性。
- 安全：HTML/URL/SQL 注入、代码或日志中的密钥、每个变更操作上的授权、不可信输入边界。
- 性能：明显的算法浪费、N+1 查询、每次渲染重复计算、关键路径上的巨型负载。
- 可访问性：键盘路径、焦点状态、对比度、语义、屏幕阅读器名称。 顺序固定是因为结构性修改会让逐行评审失效，应先看形状再看细节。
问题记录方式 每条问题包含：严重程度（blocker / should-fix / nit）、位置（file:line）、一句话问题、一句话修复。没有位置或没有修复方案的不算评审，只是抱怨。blocker 包括行为错误、安全漏洞、数据丢失、破坏设计系统；should-fix 包括重复、死代码、命名漂移、缺失边界处理、性能隐患；nit 包括格式与命名偏好，只标记不阻塞。对不值得太多问题的 diff，问题数量不宜超过约 10 条。
diff 纪律 只评审最小的逻辑变更：把重命名、新功能、bug 修复混在一起的 PR 应拒绝其打包方式。把 diff 读成一系列决策而非一串改动，多问“为什么存在”。生成代码与手写代码同一标准，评审测试时也要注意只断言正常路径的测试不算有效测试。
收尾问题 签署前自问：如果这代码是我写的，我会合并吗？若否，用一句话说明原因；若是，则带着问题清单通过评审——不要求完美，但要求每个决定都是有意的。
检查清单（出现以下情况即评审不通过） 问题未按严重程度排序或缺少位置；未记录边界情况评审；以“只是个落地页”为由跳过安全评审；未检查代码是否符合仓库既有约定；变更行为缺少测试或只有正常路径测试；对生成代码的评审标准低于人工代码；评审只说“看起来不错”而背后没有分轮评审支撑。
适用场景与限制 适用于对 AI 生成代码进行系统化评审、制定团队代码评审规范、构建评审智能体或检查清单。资料未提供具体工具形态、安装方式、集成平台与收费信息。