跳转到主要内容

​
大多数迭代工作流的差距

团队在 Jira、Linear 或 Notion 中跟踪需求。开发者在 PR 中实现它们。但没有人系统地检查 PR 是否实际覆盖了所有验收标准 — 直到 QA 在预发布环境中发现差距。 此 cookbook 通过自动根据任务需求验证 PR 来弥合这个差距。

​
工作流

创建任务（Jira/Linear/Notion）
    ↓
开发者实现 → 打开 PR
    ↓
Kodus 自动：
  1. 从关联工具获取任务上下文
  2. 将 PR 差异与验收标准进行比较
  3. 报告缺失/部分实现
    ↓
开发者解决发现 → 重新验证
    ↓
自信地合并

​
步骤 1 — 连接任务管理工具

前往设置 → 插件并连接您的工具：
  • Jira — 使用 Atlassian 的团队
  • Linear — 使用 Linear 的团队
  • Notion — 使用 Notion 作为任务跟踪器的团队
  • ClickUp — 使用 ClickUp 的团队
连接后，Kodus 可以在审查期间自动获取任务上下文。

​
步骤 2 — 启用业务逻辑验证

默认已启用，但请验证： 
reviewOptions:
  business_logic: true

​
步骤 3 — 编写好的验收标准

验证质量完全取决于任务描述的质量。Kodus 将任务上下文分类为：
质量含义建议
完整标题 + 描述 + 验收标准最佳效果 — 逐条验证
部分标题 + 描述，无标准尚可 — 基于行为的分析
最小仅标题较差 — 仅标记明显差距
Jira/Linear 任务模板： 
## 描述
关于需要更改的内容及原因的简要上下文。

## 验收标准
1. 角色为 "admin" 的用户可以删除任何评论
2. 用户只能在 24 小时内编辑自己的评论
3. 删除的评论显示 "[已删除]" 占位符
4. 审计日志记录谁删除了什么以及何时
5. API 对未授权的删除尝试返回 403

​
步骤 4 — 在开发过程中使用按需验证

在将 PR 标记为准备就绪之前，开发者可以自检： 
@kody -v business-logic https://kodustech.atlassian.net/browse/KC-1292
这在审查者查看 PR 之前就能捕获差距。

​
步骤 5 — 将迭代约定作为记忆教授

@kody remember: every PR must be linked to a Jira ticket.
PRs without a linked ticket should be flagged.

@kody remember: acceptance criteria marked as "out of scope"
in the ticket should not be flagged as missing.

​
步骤 6 — 创建 PR 要求规则

名称：PR 必须引用任务
范围：拉取请求
严重性：中等
说明：
  检查 pr_description 和 pr_title 中是否有任务引用
  （例如 KC-1234、TEAM-456 或 Jira/Linear/Notion 的 URL）。
  如果未找到任务引用，标记并要求开发者
  链接相关任务以进行业务逻辑验证。

​
结果

设置后，迭代中的每个 PR 都会获得：
  1. 代码质量审查 — 安全性、性能、风格（标准 Kodus）
  2. 业务逻辑验证 — 所有验收标准是否已实现？
  3. 范围不匹配检测 — 这个 PR 是否在处理正确的任务？
QA 发现更少的差距，迭代演示更顺畅，“我以为已经完成了”变得罕见。

​
提示

  • 鼓励团队编写编号的验收标准 — 它们获得最佳验证
  • 在开发过程中使用按需验证，而不仅仅在审查时
  • 如果 PR 有意不覆盖所有标准（分阶段交付），在 PR 描述中注明，以便 Kody 可以考虑
更多详情，请参阅业务逻辑验证。