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.mdskip_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 authors 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 didnt know it existed而且当评审者也依赖与作者相同的记忆时它还能穿过评审存活下来。重量对照把方案重量与需求声明的范围和生命周期对照。原文示例临时活动temporary campaign不需要配置系统计费路径billing path不允许 quick hack。出处约束每个最佳实践发现都要能点名将写入rule_source字段的出处——无可引用出处就没有发现no citable source, no finding。五、违规与非违规判定边界的精确刻画规则文件用两节把报什么与不报什么钉死这是可执行性所在。Violations应报告自造机制重复了有文档记载的框架特性或外部平台原生能力——必须引用文档需求不能为方案的复杂度辩护或在需求标记为关键的路径上走健壮性捷径。Not violations不应报告简单实现的简单需求——文件注明这是校准原则calibration principle以代码库现有标准为准不以理想化标准为准无可引用出处的个人品味偏好有声明理由的复杂度——代码注释或 PR 说明了逼出这种复杂度的约束。第三条与 SKILL.md 的核心原则 4Calibrate to codebase and lifespan一脉相承对声明为临时代码限时活动、实验、一次性脚本硬编码与低扩展性恰恰是换得快的预期代价到期删代码是合法的下线机制评审不应要求它具备可配置性唯一豁免校准的是安全维度。verify 阶段同样落地了该校准广泛存在且本 diff 未使其恶化的问题判false_positive且 reason 以over-scrutiny:开头见 verify-prompt.md 第 9 步。六、与相邻维度的管辖分界business-logic 的可执行性很大程度来自它与邻居的清晰划界规则文件中两处显式声明维度与 business-logic 的边界logiclogic 管正确性边缘输入、竞态、状态机、需求偏离business-logic 管设计是否称手。logic 文件明确把框架滥用与自造复杂度让给本维度reuse-architecture本维度管与外部平台/框架能力的重复重复仓库内兄弟实现归 reuse-architecturereport it there or leave it to that reviewerai-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 checklistDeep 模式按维度派评审子智能体评审者须完整读取维度文件正文含什么不算违规。评审提示词模板统一为 review-prompt.md其中 Calibration硬规则重申了本维度的广泛存在且未恶化 → 不报告约束并要求每条发现落在 diff 的行上、附file:line证据。对抗式验证因元数据声明verify: truebusiness-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），仅供参考
LobeHub deep-review 的 business-logic 维度：AI 代码评审中的设计级质量门禁
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.mdskip_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 authors 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 didnt know it existed而且当评审者也依赖与作者相同的记忆时它还能穿过评审存活下来。重量对照把方案重量与需求声明的范围和生命周期对照。原文示例临时活动temporary campaign不需要配置系统计费路径billing path不允许 quick hack。出处约束每个最佳实践发现都要能点名将写入rule_source字段的出处——无可引用出处就没有发现no citable source, no finding。五、违规与非违规判定边界的精确刻画规则文件用两节把报什么与不报什么钉死这是可执行性所在。Violations应报告自造机制重复了有文档记载的框架特性或外部平台原生能力——必须引用文档需求不能为方案的复杂度辩护或在需求标记为关键的路径上走健壮性捷径。Not violations不应报告简单实现的简单需求——文件注明这是校准原则calibration principle以代码库现有标准为准不以理想化标准为准无可引用出处的个人品味偏好有声明理由的复杂度——代码注释或 PR 说明了逼出这种复杂度的约束。第三条与 SKILL.md 的核心原则 4Calibrate to codebase and lifespan一脉相承对声明为临时代码限时活动、实验、一次性脚本硬编码与低扩展性恰恰是换得快的预期代价到期删代码是合法的下线机制评审不应要求它具备可配置性唯一豁免校准的是安全维度。verify 阶段同样落地了该校准广泛存在且本 diff 未使其恶化的问题判false_positive且 reason 以over-scrutiny:开头见 verify-prompt.md 第 9 步。六、与相邻维度的管辖分界business-logic 的可执行性很大程度来自它与邻居的清晰划界规则文件中两处显式声明维度与 business-logic 的边界logiclogic 管正确性边缘输入、竞态、状态机、需求偏离business-logic 管设计是否称手。logic 文件明确把框架滥用与自造复杂度让给本维度reuse-architecture本维度管与外部平台/框架能力的重复重复仓库内兄弟实现归 reuse-architecturereport it there or leave it to that reviewerai-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 checklistDeep 模式按维度派评审子智能体评审者须完整读取维度文件正文含什么不算违规。评审提示词模板统一为 review-prompt.md其中 Calibration硬规则重申了本维度的广泛存在且未恶化 → 不报告约束并要求每条发现落在 diff 的行上、附file:line证据。对抗式验证因元数据声明verify: truebusiness-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），仅供参考