LobeHub deep-review Logic 维度详解一套可执行的逻辑正确性审查规则边界条件、并发、错误路径与需求偏差【免费下载链接】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 仓库中多智能体代码审查技能deep-review的 Logic Correctness 维度规则文件完整讲解这套逻辑正确性审查清单它检查哪些典型 bug 类别边界条件、文本解析、null 传播、竞态、错误路径、状态机、需求偏差、回归测试缺口每一步如何执行检查以及什么算违规、什么不算违规的校准边界。读完你能理解该维度在 LobeHub 的独立审查 → 独立验证 → 全局去重流水线中的位置并把这套清单迁移到自己项目的 code review 实践中。这个维度在 deep-review 技能中的定位LobeHub 把代码审查做成了一套可执行的规则体系审查质量不依赖更聪明的模型而是来自细粒度、可执行的维度规则文件每个维度单独一个 Markdown 文件告诉审查子代理怎么查、什么算违规、什么不算违规。规则统一放在references/dimensions/目录下共 14 个维度Logic Correctness 是其中之一其规则文件是 logic.md。该文件以 YAML frontmatter 声明了三条元信息这直接决定了它如何被流水线调度id_prefix: logic # 该维度产出的 finding 统一使用 logic-1、logic-2 这样的 id verify: true # 该维度的候选发现必须经过独立 verify 子代理证伪后才进报告 skip_when: docs/lockfile-only diff # 仅文档/lockfile 变更的 diff 跳过该维度结合 SKILL.md 中的维度总表可以确认三件事Logic 维度的 id 前缀是logic覆盖范围是edge cases, null, races, error handling, state machines, requirement deviation, test coverage且Verified?一列为yes——即它的每条候选发现都要被独立验证。剪枝pruning表规定ai-coding-bad-habits、code-style、logic、business-logic、reuse-architecture 五个维度neverskip仅 docs/lockfile-only diff 例外。也就是说任何包含代码变更的 diff逻辑正确性维度都必然被审查这是所有维度中覆盖面最广的一类。两种模式都复用同一批维度文件light 模式只读各文件的Quick checklist小节deep 模式则读完整文件加上适用的 rule sources 和被路由的参考文档。在流水线中Logic 维度处于找 bug 的经典战场classic bug hunt的角色它回答这次改动是否做了需求要求的事并在真实输入下站得住脚。而设计层面的判断框架误用、自己制造复杂度被明确划给 business-logic 维度两者的分工边界在 business-logic.md 开头有一句对照说明——whether the code iscorrectbelongs to the logic dimension; this dimension asks whether it iswell-conceived。Quick checklist完整审查清单逐项解析下面是规则文件Quick checklist的全部条目逐条展开。light 模式的独立审查员只读这一节deep 模式的审查员则连后面的 How to check、Violations、Not violations 一起读所以这一节是整个维度的执行核心。1. 边界条件Edge cases空数组/空字符串、零、边界索引、第一页/最后一页、单元素集合。这是最基础的枚举输入空间动作对每个被修改的函数问一句什么输入会弄坏它。2. 文本解析器/提取器系统性枚举而非抽查这是该维度里最有实战价值的一条针对 envelope、marker、delimiter 这类基于标记/分隔符做提取的解析函数要求系统性枚举输入空间而不是凭感觉抽查。枚举清单至少包括空 payload、只有 marker 的 payload、body 内部出现 delimiter/marker 字面量、截断/部分输入有一条重要的扩散规则一旦在函数中发现某处 delimiter 查找是脆弱的必须把同样的攻击应用到该函数里每一处indexOf/lastIndexOf/ 正则查找——不能只修被点名的那一处。这与 How to check 第 5 步呼应对文本解析函数先写出对抗性输入清单empty、marker-only、body-contains-delimiter、truncated再逐条对照代码——不允许想到哪补到哪。3. null/undefined 流入假设非空的代码典型 bug 类别上游返回了可选值下游按必达值处理。注意与 verify 阶段的反证优先配合——后面会讲到验证者被要求先找反例上游保证、早退、框架行为所以上报此类问题必须确认调用方真的可能传入空值。4. 竞态条件Race conditions并发变更、过期闭包stale closures、顺序有依赖但未 await 的 Promise。5. 错误处理Error handling失败路径留下半改状态half-mutated state或 UI 卡死的场景。检查动作是把每条错误路径追踪到终态用户收到了什么反馈、状态是否回滚、日志是否落盘。6. 状态机State machines本次改动之后是否存在不可达/未处理的状态。7. 需求偏差Requirement deviation——本维度最有特色的一条规则原文的核心论断是即使代码内部完全自洽只要 diff 与需求/验收标准/PR、issue、对话中记录的关键决策相矛盾也要上报。理由是审查者无法区分实现中途的合理调整和决策被遗忘上下文丢失、压缩。因此修复永远是二选一的让实现对齐已记录的决策或者更新记录并说明决策为何改变。这一条把逻辑正确从代码自洽扩展到了与需求记录一致是纯静态审查工具难以覆盖的角度。8. 回归测试要求Bug fix 必须附带一个覆盖被修复场景的回归测试——注意第 4 步检查要求ls同目录__tests__/确认被修复的场景真的被覆盖而不是随便动了某个测试纯样式/CSS 修复是唯一豁免项因为它的实际断言往往只能是样式表源字符串匹配不构成值得发布的回归测试此豁免引用 testing SKILL.md 的核心原则第 5 条After fixing a bug, add a regression test that fails before the fix and passes after以及同条的 style/CSS skip 说明新的 service / store action / utility 需要测试覆盖新的数据库 Model/Repository 必须在同一个 PR里带上同目录的__tests__/name.test.ts且包含 user isolation 测试。这一条同样来自 testing SKILL.mdevery new file underpackages/database/src/models/**orsrc/repositories/**ships with a sibling__tests__/name.test.tsin the same PR仓库中确实大量存在这类测试例如packages/database/src/models/__tests__/agent.test.ts等。Rule sources 与 How to check 五步法deep 模式的审查员在审 diff 前必须先读两份规则源rule sources审查 prompt 中 scope summary 里的需求背景——它是判断需求偏差的主要标尺primary yardstick.agents/skills/testing/SKILL.md——回答什么需要测试、这里的测试如何组织。随后的检查流程被固定为 5 步可以照抄为自己的 review 操作手册逐行读 diff带着副作用的视角对每个被改函数问什么输入会弄坏它追踪每条错误路径到终态用户反馈、状态回滚、日志三处都要落到。行为对照 scope summary即使代码内部自洽偏差也是 finding。对修复类改动ls同目录__tests__/确认被修复的场景确实被覆盖而不是任何测试被碰过即可。对文本解析函数先写对抗性输入清单empty、marker-only、body-contains-delimiter、truncated再逐项对照代码读——不要随想随评ad hoc。Violations 与 Not violations校准边界这套清单同时定义了什么必须报和什么禁止报后者与 SKILL.md 的核心原则 4Calibrate to codebase and lifespan一脉相承。Violations必须报告存在具体的输入/状态序列能产生错误结果、崩溃、UI 卡死或半提交状态改动相对需求静默收窄或放宽了行为bug fix 没有附带本可以抓到原 bug的测试纯样式/CSS 修复除外。Not violations禁止报告系统根本无法产生的假想输入——上报前必须对照调用方核实无逻辑的平凡胶水代码缺测试简单需求的简单实现——不要要求防御性编程去覆盖上游代码已保证不可能的状态。原文给出的例子是现有代码库刻意保持乐观更新optimistic updates的简单风格审查要匹配这个基准而不是要求穷举边界处理calibration principle。禁止报这一侧的存在是这套规则能降低误报率的关键它把审查基准锚定在代码库已达到的标准而不是理想化标准上。源码纵深Logic 维度的输出如何在流水线中被消费与校验以下实现证据说明该维度文件不是孤立文档而是被 prompt 模板和输出校验器严格消费的规则契约。Finding 的 JSON 契约logic-1示例恰好是本维度的空输入场景review-prompt.md 是所有审查子代理的统一 prompt 模板要求输出严格的单 JSON 对象每条 issue 必含id、dimension、issue_type、nature、severity、likelihood、location、summary、core_problem、fix_cost、fix_options、need_test等字段。模板里给出的范例 finding 正是 Logic 维度的产物且与前面 Quick checklist 第 1 条空输入直接对应{ id: logic-1, dimension: logic, issue_type: empty input, nature: introduced, severity: p1, likelihood: high, location: src/api/user.ts:87, summary: Batch delete accepts an empty id list and builds invalid SQL., core_problem: Because empty input is not rejected, submitting an empty selection returns a server error., scenario: The bulk-action UI submits after the final selected row is deselected., fix_cost: low, fix_options: [Require at least one id in the input schema], need_test: true }这里的core_problem有固定文风要求一句话 Because 〈缺失什么〉, when 〈谁做 X〉, 〈后果〉——把根因 触发条件 后果压缩成一句可复述的因果链。severity 只表达影响面p0 生产事故 / p1 本次必须修 / p2 可延后likelihood 独立表达真实生产路径上的触发频率high/medium/low且likelihood: low时scenario字段必须写出完整的前置条件链。独立验证三值判定取代置信度frontmatter 的verify: true对应 verify-prompt.md 定义的独立验证环节验证子代理与审查子代理永不共用同一个 agent且返回confirmed/false_positive/need_more_context三值判定而不用置信度百分比SKILL.md 反幻觉原则 1 的解释是听起来经过校准的分数作为硬过滤并不可靠。验证程序对每条 finding 要求 10 步固定动作其中与 Logic 维度最相关的是第 3 步先找反例找上游保证、早退、框架行为等阻止该场景存在的证据——这正是对 Not violations 第 1 条假想输入的程序化落实第 9 步应用代码库/生命周期校准广泛存在且本次未恶化 → 判false_positivereason 以over-scrutiny:开头confirmed 判定必须给出 file-and-line 证据不确定性只能落为need_more_context禁止猜测式确认。Zod 校验器把清单规则变成机器可查的硬约束scripts/validate-output.ts 用 Zod 定义了审查输出的 schema并作为 CLI 入口validate-output.ts review|verify|consolidate [input-file]从文件读取或 stdin 读取自动提取json围栏内容。其中superRefine写下的条件校验正是把 Logic 维度的清单规则翻译成了硬错误likelihood low但缺少scenario→ low-likelihood findings require scenarionature exposed_legacy但缺少exposure/scenario→ 报错要求给出改动前触达不到、改动后能被触发的前后对照nature introduced却带了exposure字段 → 报错issue id 全局唯一性校验。也就是说low 可能性必须写出完整前置条件链这类审查纪律不依赖模型自觉而是由这段可执行 schema 在流水线中强制拦截。回归测试豁免的判定路径Light 模式下审查员按 light-review-prompt.md 只读Quick checklist小节执行同样清单而清单中bug fix 必须带回归测试的判定依据全部锚定在 testing/SKILL.md 的可验证内容上回归测试必须修复前失败、修复后通过style/CSS 修复selector、hover、mask、spacing、color若唯一可行断言是样式表源字符串匹配则豁免数据库 Model/Repository 的测试走getTestDB()集成风格、BM25/全文搜索块用describe.skipIf(!isServerDB)保护、且必须测 user isolation。如何把这套维度规则落到自己的项目LobeHub 的做法给出一个可复用的结构一个维度文件 frontmatter 元信息id 前缀、是否验证、剪枝条件 Quick checklist两种模式共用的最小清单 Rule sources规则依据的可读文件 How to check固定步骤 Violations必须报 Not violations禁止报锚定代码库现有基准。其中对逻辑正确性审查最值钱的三点设计需求偏差与代码自洽分开判定——代码没 bug 但和记录的需求矛盾单独成立为 finding修复方式二选一对齐实现 / 更新决策记录文本解析检查先枚举后读码——对抗性输入清单前置且一处 delimiter 查找脆弱就同构攻击全部indexOf/lastIndexOf/正则查找报告纪律机器化——把low 可能性必须附场景链遗留代码必须给前后触发的对照等规则写进 Zod schema让格式违规在流水线里被自动拒绝而不是靠审查者自觉。对于 LobeHub 仓库的使用者这套文件是只读的规则资产可以直接阅读各维度文件对照自己项目的 review 习惯做校准或在 fork/包装仓库中按 SKILL.md Extension packs 一节描述的机制deep-review-*同名维度文件扩展、新名称维度叠加为自己的部署补充 Logic 维度的项目级细则而不需要改动本仓库。【免费下载链接】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），仅供参考