LobeHub deep-review 的 business-logic 维度：AI 代码评审中的设计级质量门禁
【免费下载链接】lobehub🤯 LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub
本篇指南基于 LobeHub 仓库内.agents/skills/deep-review技能下的 business-logic 维度规则文件，详解该代码评审维度的定位、五条快速检查清单、规则来源与四步核查方法，并结合 deep-review 技能总览 说明它如何嵌入"独立评审 → 对抗式验证 → 汇总"的整体评审流水线。读完后你能掌握一套可复用的"设计级评审"判据：如何区分"代码正确"与"方案称手"，如何避免框架滥用、自造复杂度和方案重量失配。
一、business-logic 是什么：设计判断，而非正确性审查
LobeHub 仓库把多智能体代码评审沉淀为一套可执行的技能：.agents/skills/deep-review/。它由若干"维度"（dimension）组成，每个维度一个规则文件，位于 references/dimensions/ 目录下，涵盖 logic、security、performance、compatibility 等 14 个方向。business-logic 是其中的一个维度，其规则文件头部的元数据为：
--- id_prefix: design verify: true skip_when: docs/lockfile-only diff ---三个字段各有含义：id_prefix: design表示该维度产出的问题 ID 以design-开头；verify: true表示该维度的候选发现必须经过独立的 verify 子智能体对抗式验证（见 verify-prompt.md）；skip_when说明只有纯文档/锁文件 diff 才会跳过本维度——在 SKILL.md 的 Pruning table 中，business-logic 与 logic、code-style 等维度同属"never（除 docs/lockfile-only 外永不裁剪）"一档，因为任何行为性改动都可能涉及设计判断。
规则文件开篇一句话定义了它的判据边界：对"这个改动如何解决需求"做设计级判断——是否按文档所述方式使用平台（框架/外部服务）、方案重量是否与问题规模匹配、是否避免了"自找的复杂度"。原文特别划了一条分界线：
代码是否正确（correct）属于 logic 维度；本维度问的是它是否构思良好（well-conceived）。
logic 维度自己也呼应了这条分界，其文件开篇明确写道："Design-level judgment (framework misuse, self-inflicted complexity) lives in the business-logic dimension." 即边界条件、空值、竞态、状态机等"bug 排查"归 logic；框架滥用与自造复杂度归 business-logic。两个维度互补但绝不重叠，评审报告中同一根因不会出现在两边。
二、五条快速检查清单：本维度的核心判据
规则文件的Quick checklist小节是 Light 模式评审唯一依据（Light 模式只派一个独立评审者，对照各维度的 Quick checklist 工作），共五条，逐条展开如下。
1. 框架滥用（Framework misuse）
与 Next.js/React/Drizzle 等框架"对抗"，而非使用其文档化的机制。检查方法中有一条硬要求：在假设"必须自己写"之前，先查官方文档。这一点针对的是 AI 编码的典型失误——模型"记得"某个框架需要手工处理某件事，而实际上框架早已内置文档化机制。
2. 自造复杂度（"没苦硬吃"）
框架、外部依赖或更简单的设计本来免费提供的能力，却被手写了一遍。规则文件同时划清了与相邻维度的管辖边界："External" 是本维度的边界——如果复用的是仓库内兄弟实现（in-repo sibling），那属于 reuse-architecture 维度，应报在那里或交给那个评审者处理，business-logic 不越界抢报。
3. 手搓外部平台原生提供的领域机制
这是五条中最具领域感的一条。当功能所运行的外部平台——支付服务商、认证服务、部署平台——本身内置了某能力时，却自造了一套领域机制（自定义的使用量计量、账单计算、发票生成、订阅生命周期、调度、webhook 重试），即属此条。文件给出经典失败案例：
没人知道支付服务商原生支持按量计费（metered billing），于是团队手搓了"使用量记录 + 收费计算 + 发票生成"三件套。
并附了一句针对评审者自身的警告：评审者和作者共享同一批盲区（Reviewers share the author's blind spots）——如果你的记忆里没有这个原生能力，作者的实现里大概率也没有。因此检查动作不是"凭记忆判断"，而是"查该平台的官方文档"。
4. 方案重量与需求规模失配（Solution weight mismatch）
失配有两个方向，文件同时点名：
- 过重：需求用直接实现就能满足，方案却引入了新的抽象层、配置系统或消息队列；
- 过轻（反向失配同样违规）：在需求明确标记为关键的路径（billing、auth、数据完整性）上使用了临时 hack。
5. 有据可查的最佳实践违规（Citable best-practice violations）
只报告"有可引用出处"的违规——出处限于官方文档、仓库内的 skill 文件、或仓库根的 DESIGN.md。个人品味（personal taste）不构成发现，这一条与 verify 阶段的校准规则 配套：无出处的品味偏好会在验证环节被以over-scrutiny:前缀判为false_positive。
三、规则来源（Rule sources）：评审前的"证据前置"
How to check之前的Rule sources (deep mode: read before reviewing)小节规定，Deep 模式的评审智能体在读 diff 之前必须先读取规则来源，共三类：
- 框架文档。当 diff 依赖框架行为时读框架文档，具体点名了
node_modules/next/dist/docs/（Next.js 的本地文档）。文件特别强调：本仓库锁定的 Next.js 版本含有破坏性变更，不要信任训练数据（do not trust training data）——这直接针对"大模型凭训练记忆引用旧版框架行为"的幻觉风险。 - 外部平台官方文档。diff 构建于其上的支付、认证、部署、消息平台，本地拿不到就联网搜索。该节给出的恒定问题是："这个平台是否已经原生支持这件事？"
- scope summary 中的需求背景。它是判断"方案重量"的标尺（yardstick）。scope summary 由 scoping.md 定义的 Step 0 产出：200 词以内，包含变更文件清单 + 需求/验收标准，随每个子智能体提示词分发——即评审者不是凭空评 diff，而是带着"这个改动本来要解决什么"来读 diff。
四、四步核查方法（How to check）
规则文件给出的操作程序共四步，与上面三类规则来源一一对应：
- 逐机制追问：对 diff 引入的每个非平凡机制问"框架或已有依赖是否已经提供这个？"——查文档，不靠假设。
- 领域机制定位外部平台：识别涉及的外部平台，检索其官方文档找原生方案。文件点出这是最昂贵的一类自造复杂度："我们不知道它存在"（we didn't know it existed），而且当评审者也依赖与作者相同的记忆时，它还能穿过评审存活下来。
- 重量对照：把方案重量与需求声明的范围和生命周期对照。原文示例：临时活动（temporary campaign）不需要配置系统；计费路径（billing path）不允许 quick hack。
- 出处约束：每个最佳实践发现都要能点名将写入
rule_source字段的出处——无可引用出处，就没有发现（no citable source, no finding）。
五、违规与非违规：判定边界的精确刻画
规则文件用两节把"报什么"与"不报什么"钉死，这是可执行性所在。
Violations（应报告）
- 自造机制重复了有文档记载的框架特性或外部平台原生能力——必须引用文档；
- 需求不能为方案的复杂度辩护，或在需求标记为关键的路径上走健壮性捷径。
Not violations（不应报告）
- 简单实现的简单需求——文件注明这是校准原则（calibration principle）：以代码库现有标准为准，不以理想化标准为准；
- 无可引用出处的个人品味偏好；
- 有声明理由的复杂度——代码注释或 PR 说明了逼出这种复杂度的约束。
第三条与 SKILL.md 的核心原则 4（"Calibrate to codebase and lifespan"）一脉相承：对声明为临时代码（限时活动、实验、一次性脚本），硬编码与低扩展性恰恰是"换得快"的预期代价，"到期删代码"是合法的下线机制，评审不应要求它具备可配置性；唯一豁免校准的是安全维度。verify 阶段同样落地了该校准：广泛存在且本 diff 未使其恶化的问题，判false_positive且 reason 以over-scrutiny:开头（见 verify-prompt.md 第 9 步）。
六、与相邻维度的管辖分界
business-logic 的可执行性很大程度来自它与邻居的清晰划界，规则文件中两处显式声明：
| 维度 | 与 business-logic 的边界 |
|---|---|
| logic | logic 管"正确性"（边缘输入、竞态、状态机、需求偏离）；business-logic 管"设计是否称手"。logic 文件明确把框架滥用与自造复杂度让给本维度 |
| reuse-architecture | 本维度管"与外部平台/框架能力的重复"；重复仓库内兄弟实现归 reuse-architecture，"report it there or leave it to that reviewer" |
| ai-coding-bad-habits | 后者管"局部合理但全局未完成"的机械性习惯（部分重构、防御性类型噪音等）；同一根因若已被 code-style 或 reuse-architecture 完整覆盖，就不在两边重复报告 |
配合 review-prompt.md 中的硬规则——评审者"只报告指派维度内的问题，即便看到别的"（Other dimensions are covered by other reviewers — do not report findings outside your assignment）——各维度文件之间的分界声明保证了并行评审时不重不漏。
七、嵌入整体评审流水线：从规则文件到报告
单看 business-logic.md 只是"一份规则"，放进 deep-review 的编排里才能看到它的运转方式（详见 SKILL.md）：
- 范围界定：按 scoping.md 的 Step 0 确定 diff 范围（三点 diff、排除锁文件与生成物）、产出 ≤200 词的 scope summary——这就是本维度"规则来源"第 3 条的输入。
- 维度裁剪：按 Pruning table 决定跑哪些维度；business-logic 除 docs/lockfile-only 外必跑。注意技能对"docs-only"的从严定义：
.agents/skills/**、AGENTS.md/CLAUDE.md、提示词模板这类"给 Agent 的可执行指令"在裁剪时按代码对待，触及其中的 diff 永远不算纯文档。 - 独立评审：Light 模式派一个独立评审者读各维度的完整 Quick checklist；Deep 模式按维度派评审子智能体，评审者须完整读取维度文件正文（含"什么不算违规"）。评审提示词模板统一为 review-prompt.md，其中 Calibration（硬规则）重申了本维度的"广泛存在且未恶化 → 不报告"约束，并要求每条发现落在 diff 的
+行上、附file:line证据。 - 对抗式验证：因元数据声明
verify: true，business-logic 的候选发现（design-*编号）由独立的 verify 子智能体逐条证伪，返回三选一裁决（confirmed/false_positive/need_more_context）；三向裁决优于置信度打分，因为"听起来很准的分数"不能作为硬过滤。 - 汇总与报告：全局去重合并后输出结构化报告，进入交互式修复流程。
技能文档还说明该规则集支持扩展包：外层仓库可在 skills 根目录放置deep-review-*目录，其中与内建同名的dimensions/*.md会叠加加载——也就是说 business-logic 的判定规则可以被部署方按私有平台扩展，而无需 fork 本技能。
八、要点小结
- 判据定位：business-logic 回答"方案是否 well-conceived"，与 logic 维度的"是否正确"严格分权，同根因不重复报告；
- 五条清单：框架滥用、自造复杂度（外部边界）、手搓平台原生领域机制（支付/认证/部署）、方案重量失配（过重与过轻双向）、有出处的最佳实践违规；
- 证据前置：Deep 模式评审前必读三类规则来源（框架本地文档、外部平台官方文档、scope summary 需求背景），核心动作永远是"查文档，不信任记忆"；
- 出处约束：无可引用出处（官方文档 / 仓库 skill / DESIGN.md）的发现不成立，个人品味在 verify 环节以
over-scrutiny:判伪； - 校准原则：以代码库现状与代码生命周期为标尺，临时代码不要求可配置性，安全维度豁免校准。
对使用 AI 编码代理的团队而言，这份维度文件的价值在于把"设计评审"从口头经验变成了可执行规则：它规定评审前读什么、逐条问什么、报什么、不报什么，并让每条设计类发现都必须携带可验证的文档出处——这正是对抗"作者与评审共享盲区"这一最昂贵失败模式的工程化手段。相关延伸阅读：deep-review 技能总览、评审提示词模板、范围界定规范、logic 维度、reuse-architecture 维度。
【免费下载链接】lobehub🤯 LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
