跳到主要内容

GitHub Projects、Issues 与代码评审

Project 管理规划和状态视图；仓库 Issue/PR 负责具体工作的源头和代码评审。观察现有字段、自动化、权限和保护规则后再提出变更；标准文本不会自动配置这些设置。

看板状态和字段​

新项目可以先使用一个 Delivery Project，并通过 table、board 和 roadmap 视图呈现同一批工作。只有目的、受众、节奏或生命周期确实不同时，再添加 Roadmap、迁移或支持类 Project。每个额外 Project 说明负责人、纳入规则、用途和何时复核/归档。

先使用少量、含义稳定的字段：Status、Priority、Assignee；跨仓库交付需要时再加 Target outcome、Component、Iteration 或承诺日期。Assignee 表示对结果负责的人，AI 代理不能替代产品、代码或运营责任人。

推荐状态：

  • Backlog：已记录，但尚未准备开始。
  • Ready：结果、验收、受影响接口和依赖足够清楚。
  • In Progress：实际正在处理，不只是被分配。
  • In Review：实现和证据已达到评审条件。
  • Done：该任务的验收条件已满足。
  • Canceled：明确放弃，不能计作完成。

阻塞作为独立标记，附原因和下一步，不覆盖真实流程状态。控制个人正在进行的工作数量，并通过依赖链接明确阻塞关系。避免把所有路线图任务同时改成 In Progress。

Issue 和跨仓库交付​

常规 Issue 至少说明问题/结果、范围、可观察验收、依赖和设计链接。任务归实际负责变更的仓库。跨仓库工作在协调仓库创建一个统筹 Issue，并链接各仓库子任务、共用契约顺序和最终集成验收；使用 owner/repository#number 完整引用。

执行状态只有一个权威看板。设计文档维护长期决策，不复制一份手工状态表。跨仓库里程碑要链接各仓库任务；相同标题并不形成全局里程碑。自动化不会天然让多个 Project 自定义状态互相同步。

分支、Worktree 和 PR​

通常使用稳定集成分支和短期特性分支。并行分支适用时使用 worktree，并记录仓库、分支和共同文件的责任。共享 schema、迁移、依赖清单和组合入口需要清楚的集成所有者。

PR 写明问题、行为、设计/Issue、兼容影响、测试命令和结果、未验证范围，并指定负责集成的人员。高风险数据、访问控制、支付和契约改动重点评审失败路径；要求独立评审时由另一位有相应责任的人完成，AI 代理不能作为唯一批准者。低风险改动采用适当的人类评审与自动检查，不强制无法满足的审批配置。

CI 至少覆盖本次影响的构建、类型/格式/行为检查；有契约或跨仓库消费者时做对应验证。测试百分比不是目标本身。分支保护、Rulesets 和 CODEOWNERS 必须在平台设置中实际核实后才能称为强制规则。

AI 任务、并行工作与交接​

AI 任务的上下文、范围、授权和证据按 AI 参与开发工作流 记录；可复用 AI 任务契约。协作者和 AI 只能在用户授权及仓库规则范围内操作；任务标签或 AGENTS 示例不会自动授予发布、外部通信或数据破坏权限。

并行工作须为每个参与者指定边界；同一时间共享文件或接口变化须指定集成负责人。交接包含当前结果、分支/提交、改动、实际命令结果、未决风险和下一步；不要把秘密、私有数据或无关机器路径放入共享交接。