跳转到主要内容

​
概述

业务逻辑验证让您确认拉取请求是否实现了规范、文档或工单中描述的预期行为。Kody 分析 PR 差异，引入引用的业务上下文，并在合并之前标记不匹配。 使用业务逻辑验证的示例

​
前提条件

  • 如果您希望 Kody 自动获取任务上下文（来自 Jira、Linear、Notion、ClickUp 等工具），需要在工作区的插件页面中连接相应的插件。
  • 您共享的任何链接（Jira、Slack、Google Docs 等）必须可通过工作区中安装的插件访问。
  • 您始终可以内联提供规范而无需任何插件 — 只需在 PR 评论中直接粘贴需求即可。

​
启用业务逻辑验证

业务逻辑验证默认启用。您可以通过两种方式控制它： 通过 kodus-config.yml： 
reviewOptions:
  business_logic: true
通过 Web UI： 前往代码审查设置 → 代码库 → 通用 → 分析类型，然后切换业务逻辑。 启用后，Kody 在每次 PR 审查时自动运行业务逻辑验证，同时也支持按需命令。

​
按需运行

您也可以随时手动触发验证：
  1. 打开主 PR 评论框（在内联代码建议之外）。
  2. 提及 Kody 并添加验证命令：@kody -v business-logic ...。
  3. 内联提供规范内容或粘贴 Kody 可以通过可用插件获取的链接。
  4. 提交评论并在同一线程中等待 Kody 的响应。
该命令仅从主对话框触发；内联建议内的回复将被忽略。 您可以随时重新运行验证——只需在新评论中再次发布命令即可。后续操作必须是新命令；不支持直接在 Git UI 中回复 Kody 的消息。

​
示例

  • Jira 工单：@kody -v business-logic https://kodustech.atlassian.net/jira/software/c/projects/KC/boards/2?selectedIssue=KC-1292
  • Linear 问题：@kody -v business-logic https://linear.app/your-team/issue/TEAM-123
  • Notion 页面：@kody -v business-logic https://www.notion.so/your-workspace/Feature-Spec-abc123
  • Google 文档：@kody -v business-logic https://docs.google.com/document/d/1234567890/edit
  • Slack 对话：@kody -v business-logic https://kodustech.slack.com/archives/C070E5E97DE/p1727814000000000
  • 内联规范片段：@kody -v business-logic 规则 XYZ — 超过 $500 的订单必须发放返现积分。

​
Kody 做什么

  1. 获取 PR 差异和拉取请求元数据。
  2. 检索任务上下文 — 从链接的任务管理工具（Jira、Linear 等）或您提供的内联文本。
  3. 分类任务上下文质量 — 根据可用信息确定分析的深度。
  4. 将实现与需求进行比较 — 检查 PR 差异中的每个验收标准。
  5. 报告发现，包含严重性级别和需求追溯。
如果 Kody 无法访问资源或缺少权限，它会指出这一点，以便您可以调整访问权限或以其他方式提供信息。

​
任务上下文质量

Kody 在分析之前自动分类任务上下文的质量，这影响验证的深度：
质量描述分析行为
完整有标题、描述和验收标准逐条验收标准进行全面分析
部分有标题和描述但没有验收标准根据描述的业务行为尽力分析
最小仅有标题或非常简短的描述保守 — 仅标记明显的差距
空未找到有意义的任务上下文返回”需要任务信息”响应

​
理解输出

​
发现严重性

每个发现包含一个严重性级别：
  • MUST_FIX — 必需的业务规则未实现、不正确或与任务要求矛盾
  • SUGGESTION — 未涵盖相关的边缘情况、健壮性或可维护性要点
  • INFO — 不阻碍合规性的有用观察

​
有据可查的发现

每个发现都可以追溯到任务上下文中的特定需求。每个发现包含：
  • 需求 — 建立该需求的任务中的确切引用
  • 代码中缺失的 — PR 差异中缺失或错误的内容
  • 建议操作 — 具体的实现操作
Kody 不会发明需求。如果一个发现无法追溯到任务中的特定句子，则不会报告。

​
范围不匹配检测

如果 PR 差异似乎在与任务本身不同的领域工作，Kody 会检测到这是一个范围不匹配，并将其作为首要发现报告，而不是产生误导性的差距分析。

​
输出示例

## Business Rules Validation

**Task:** KC-1441 - Team-scoped Kody rules
**Task Link:** https://kodustech.atlassian.net/browse/KC-1441
**Status:** Issues Found
**Confidence:** high

### Findings

#### MUST_FIX: No evidence of team-scoped rule resolution in this PR diff
**Requirement:** "Rules must be resolved by organization and team
to avoid cross-workspace billing mismatch."
**Missing in code:** No evidence in this PR diff of adding `teamId`
to the relevant persistence or lookup path.
**Suggested action:** Add `teamId` to rule persistence and query filters.

#### SUGGESTION: No evidence of deterministic mixed-license handling
**Requirement:** "When teams have different subscription states,
behavior must remain deterministic."
**Missing in code:** No evidence in this PR diff of logic handling
mixed subscription states.
**Suggested action:** Add deterministic fallback and error handling
scoped to team.

### Requirements Verified
- AC #1: "Team-scoped reads/writes" — Implemented in `rules.service.ts:42`
- AC #2: "Multi-workspace billing path" — Implemented in `billing.service.ts:118`

---
*Analysis performed by Kodus AI Business Rules Validator*

​
提示

  • 将大型规范分解为多个部分并分别验证，以保持反馈的重点。
  • 共享私有链接时，请仔细检查所需的插件（例如，Jira、Slack、Google Drive）是否已为您的工作区安装和授权。
  • 解决发现的问题后，重新运行命令以确认 PR 现在与业务规则一致。
  • 在任务中提供验收标准以获得最全面的分析 — 具有明确标准的任务会获得逐条验证。