PR 工作台 Agent 产品调研：痛点与功能

[SATA260]

文档说明

• 阶段：产品调研与形态定义
• 目标：识别用户在 Git、Issue、PR、Review 和团队协作中的真实痛点，梳理现有解决方式及其缺口
• 本文不包含：技术架构、MVP 范围、实现方案、开发优先级或交付计划

1. 产品假设

产品不是新的 Git 代码托管平台，也不试图替代 GitHub、GitLab 等既有平台。

产品假设是在现有平台之上增加一层面向个人和团队的协作工作台：聚合 Issue、代码变更、PR、团队规范和 Agent 上下文，让用户更容易理解、推进和审核研发工作。

GitHub、GitLab 等平台仍然承载代码仓库、Issue、PR、评论、Review 和 CI/CD 等原始事实。平台的价值在于把这些信息组织成一条更易理解的研发链路，并提供适合团队协作的操作辅助。

AI 能力的产品假设是：用户继续使用本机已安装、已授权的 Codex、Claude Code 等 Coding Agent；平台负责把 Issue、规范、Diff 和任务上下文组织好，再将结果呈现给用户。所有 AI 功能都应能够说明自己参考了哪些上下文。

当前更符合产品设想的运行形态是 Local-first：Git 操作、Worktree、本地测试和 Codex/Claude Code 由本机完成；团队协作、Issue、PR 和 CI 继续通过现有 Git 平台完成；团队规范随项目仓库一起版本化。

2. 用户与典型场景

用户	典型场景	当前困难
新手开发者	修改代码、提交 Commit、创建 PR、参与 Review	不理解 Git 状态、公司规范和术语，担心误操作或提交不合规内容
普通开发者	从 Issue 开始开发功能	需求、设计、分支、测试和 PR 信息分散
Reviewer	阅读复杂 PR 并给出意见	很难快速理解改动意图、模块背景和验收目标
Tech Lead	拆解工作、安排并行开发、把控质量	不易识别依赖、冲突风险和任务阻塞
团队成员 / 负责人	汇总当天进展并同步日报	需要手工翻找 Commit、PR、Issue 和 Agent 会话，难以区分完成与阻塞
团队管理员	建立项目和团队规范	模板和规则分散，新项目需要重复配置

3. 痛点、现有做法与功能机会

3.1 Git 操作复杂，用户不知道当前发生了什么

用户痛点

• 新手不理解 merge、rebase、cherry-pick、stash、reset 等操作的差异。
• 用户难以分清工作区、暂存区、本地分支、远程分支和 PR 之间的关系。
• 冲突信息面向 Git 实现细节，而不是面向用户正在完成的业务目标。
• Commit、push、rebase、删除分支和撤回操作都可能让用户担心丢失代码。
• 用户即使完成了操作，也不清楚对其他开发者和远程仓库的影响。

已有项目与解决方式

项目	主要解决方式	仍未解决的问题
Git CLI	提供最完整的 Git 操作能力，适合熟练用户和自动化脚本	术语和命令对新手不友好，操作影响需要用户自行判断
GitHub Desktop	用桌面界面展示修改、分支、Commit、Push 和 PR	降低了命令记忆成本，但对 merge/rebase/stash 的语义和风险解释有限
GitKraken	提供提交历史图、分支操作、冲突处理和多平台仓库接入	功能较完整，但仍偏 Git 工具视角，不会结合 Issue 目标解释操作
Sourcetree	提供本地仓库、提交历史、分支和冲突的图形化管理	主要解决操作入口问题，不负责研发上下文和团队流程引导
GitHub Pull Request	在远程平台查看 PR、Diff、Checks 和合并状态	关注远程协作结果，不覆盖本地 Worktree、暂存区和可恢复操作教学

现有做法的缺口

• 图形化工具降低了命令记忆成本，但没有消除 Git 状态和操作结果的理解成本。
• Git 平台通常展示对象和操作入口，较少解释“为什么要做这个操作”及“操作后会怎样”。
• 对新手而言，撤回、冲突处理和历史恢复依然缺少足够的引导。

功能机会

• 将当前仓库状态、分支关系和本地修改用可视化方式呈现。
• 将 Git 命令转译成业务语言，例如“将功能分支的改动整合到主分支”。
• 在操作前解释影响、风险和可恢复方式。
• 在冲突页面解释冲突来源、不同版本的业务含义和可选处理方式。
• 提供结合当前仓库上下文的 Ask，例如“我现在为什么不能合并”“刚才的操作能否撤回”。

3.2 Issue 到开发再到 PR 的上下文断裂

用户痛点

• Issue 经常只有一句需求，没有范围、验收标准、依赖或技术限制。
• 开发者需要自行把 Issue 转化成设计、任务、分支、Commit 和 PR。
• 代码改动完成后，难以判断是否真正满足了 Issue 的验收目标。
• Issue、Branch、Commit、PR、测试和 Review 之间的关联不完整或不一致。
• 项目设计文档和模块说明没有被持续带入开发与 Review 过程。

已有项目与解决方式

项目	主要解决方式	仍未解决的问题
GitHub Issues/Projects	管理 Issue、Label、Milestone、Assignee、Project 和 PR 关联	需求澄清、架构设计和验收标准到代码的连续上下文仍依赖人工维护
GitLab Issues	将 Issue、迭代、看板、Merge Request 和 CI 集成在同一平台	仍然需要用户手动把 Issue 转换成技术方案和代码任务
Linear	提供结构化 Issue、项目、Cycles、依赖和开发流程管理	与本地 Coding Agent、代码修改和 PR 验收的连接需要额外集成
OpenHands	可根据 GitHub Issue 启动 Agent 任务，并提供开发自动化	更偏自动编码和 Agent 控制中心，不专注 Issue 到 PR 的可视化关联和规范检查
SWE-agent	接收 GitHub Issue，尝试修改代码、运行测试并解决问题	主要是任务执行框架，缺少团队工作台和持续的 Issue/PR Review 上下文

现有做法的缺口

• 关联关系依赖人工习惯，容易遗漏或写错。
• Issue 的验收标准通常不会自动进入 PR Review 的判断依据。
• 需求、设计与代码之间缺少可追溯的阅读路径。

功能机会

• 将 Issue 作为研发链路的主上下文，关联 Branch、Commit、PR、测试和 Review。
• 在 Issue 中引导补充目标、范围、验收标准、依赖和风险。
• 让用户在开始开发前看到与该 Issue 有关的模块、历史 PR、设计文档和团队规范。
• 根据 Issue 生成方案、任务拆分或文档草稿，但由用户确认其内容。
• 在 PR 页面明确展示“该改动对应哪个 Issue、完成了哪些验收标准”。
• 将 Issue 设为一次开发任务的主对象，一个开发任务应有一个主 Issue，并允许关联其他 Issue。

3.3 多个 AI Coding Agent 并行运行时缺少任务与会话管理

用户痛点

• 用户已经会用 Codex、Claude Code 等工具，但 Agent 容易缺少项目约束、设计背景和当前任务边界。
• Agent 可能直接修改大量文件，用户不知道它为何这样做、改动范围是否合理。
• Agent 测试失败或卡住时，用户缺少状态、原因和接管入口。
• 用户在 Web 工作台中可能同时调用 Codex、Claude Code 等多个 Agent，原生终端或单会话界面不方便统一管理。
• 多个会话与任务之间缺少清晰的归属关系，用户难以判断某个会话服务哪个 Issue、分支、Worktree 或 PR。
• 同时运行多个 Agent 时，用户难以判断它们分别在做什么，是否互相影响，也不容易比较不同会话的结果。
• 同一个团队对 Agent 的要求不同，例如命名、模块边界、测试、文档和禁止修改的区域。

已有项目与解决方式

项目	主要解决方式	仍未解决的问题
OpenAI Codex CLI	在本地终端理解代码、修改文件、运行命令和测试	单个 Agent 的本地交互为主，多个任务、Worktree、Issue 和团队状态需要用户自行组织
Claude Code	在本地仓库中进行代码理解、规划、修改和测试	项目上下文可以通过规则文件提供，但团队任务和跨 Agent 协作视图较弱
OpenHands	提供 Web Agent 控制中心、自动化和多种 Agent 后端	更偏通用 Agent 平台，不专门解决本地 Git 操作和团队规范关联
pi	提供可扩展的 Agent Loop、工具调用、会话和模型适配能力	是 Agent runtime/编码 Agent 基座，不直接提供 Issue、PR 和团队研发工作台
pi-dispatch	提供任务队列、触发器、容器隔离、预算和运行面板	偏后台 Agent 运行基础设施，不负责交互式本地开发流程

现有做法的缺口

• Agent 的任务、执行状态、改动和结果散落在不同终端和本地目录；Web 工作台通常也以会话为中心，缺少任务级组织。
• 团队成员难以共享 Agent 运行过程和上下文。
• Agent 与 Issue、PR、Review 的关系通常需要开发者自行维护。
• 一个任务需要多次尝试、多个 Agent 或人工接管时，会话历史容易失去上下文。

功能机会

• 引入“任务栏/任务卡”作为组织多个 Agent 会话的一级对象：每个任务栏关联一个主 Issue，并可关联多个会话、分支、Worktree、测试和 PR。
• 支持在同一任务栏中启动 Codex、Claude Code 等不同 Agent 会话，清楚展示每个会话的 Agent 类型、状态、开始时间、修改范围和输出结果。
• 将会话按规划、编码、测试、Review、人工接管等阶段归档，并允许在同一任务上下文中继续、暂停、重试或新建会话。
• 提供任务栏总览和会话详情两个层级：总览用于判断任务是否阻塞，详情用于查看日志、Diff、测试和 Agent 依据。
• 展示 Agent 当前在规划、编码、测试、等待确认还是被阻塞。
• 将架构文档、模块设计、团队规则和 AGENTS.md 作为 Agent 可引用的项目上下文。
• 对 Agent 的修改范围、测试结果、失败原因和生成内容提供可读的记录。
• 让用户可以查看、暂停、接管或重新发起一个 Agent 工作项。

3.4 新手不了解公司研发规范，Commit、Branch、PR 与 Review 难以一致

用户痛点

• 不同公司、团队和项目对 Commit Message、Branch 名、PR 标题和 PR 描述有不同规范。
• 新成员不知道 feat、fix、scope、Issue 编号和 Breaking Change 应如何填写，也不了解什么时候应该拆分 Commit、如何发起 PR、如何回应 Review。
• 一个 Commit 可能混入多项不相关改动，导致后续 Review、回滚和追溯困难。
• 团队规则散落在文档、口头约定、本地 Hook 和 CI 配置中。
• 规范即使写在文档里，也常常没有出现在用户实际提交、提 PR 和 Review 的操作节点上。

已有项目与解决方式

项目	主要解决方式	仍未解决的问题
Conventional Commits	约定 feat、fix、scope 等提交格式	只是规范，不提供与当前 Diff 和 Issue 相关的生成和解释能力
commitlint	通过 Hook 或 CI 校验 Commit Message	能发现格式错误，但不能帮助新手理解规则或生成合适内容
Commitizen	通过交互式提示帮助用户填写 Commit 字段	主要关注字段填写，不分析代码改动和 Issue 验收目标
GitHub Issue/PR Templates	统一 Issue 和 PR 的描述结构	模板不等于规范理解，无法保证 Commit、Branch 和 PR 内容彼此一致
Changesets	管理包版本变更和发布说明	面向发布版本管理，不覆盖通用团队 Commit 规范

现有做法的缺口

• 规则配置与实际填写界面脱节，用户仍然需要理解和记忆规则。
• 不同项目的模板复用、覆盖和版本管理不足。
• AI 生成 Commit 或 PR 文案时，往往没有团队规则和关联 Issue 作为依据。
• 新手缺少一条从“当前改动”到“合规 Commit、PR 和 Review”的逐步引导路径。

功能机会

• 项目启动时读取仓库内的规范配置，优先加载 .codedock/，并兼容 AGENTS.md、CLAUDE.md、.github/ 模板和现有 Hook/CI 规则。
• 将读取到的规则转化为当前项目的可执行检查和新手引导：告诉用户下一步该做什么、为什么这样做，以及不符合规范会有什么影响。
• 提供团队级和项目级的 Commit、Branch、Issue、PR、Label 模板中心。
• 根据 Diff、关联 Issue 和团队规范，由本地 Coding Agent 生成 Commit Message、PR 标题和描述草稿。
• 在创建 Commit 或 PR 前解释不符合规范的原因，并提供可编辑的修正建议。
• 在 Review 页面按项目规范生成检查清单，帮助新手理解如何阅读 Diff、验证测试和回应 Reviewer。
• 协助发现一个 Commit 中是否混入多个无关改动。
• 将团队规范与 AGENTS.md、架构文档和 Review 规则一起组织为可持续维护的项目知识。

3.5 PR Review 只看 Diff，难以判断是否完成需求

用户痛点

• 大型 PR 的改动意图和模块背景不容易从 Diff 中直接看出。
• Reviewer 需要在 Issue、PR、历史代码、设计文档和 CI 日志之间频繁切换。
• 新成员不熟悉模块，很难判断改动是否合理。
• 人工 Review 耗时，而纯自动 AI Review 可能产生大量泛化、低价值的评论。
• 很多自动 Review 工具主要围绕 Diff 分析，没有将关联 Issue 的目标和验收标准作为强制审查依据。

已有项目与解决方式

项目	主要解决方式	仍未解决的问题
GitHub Pull Request Review	提供 Diff、行级评论、审批、Request changes 和 CODEOWNERS	Reviewer 仍需自行在 Issue、设计文档和代码之间切换
CodeRabbit	对 PR 提供上下文分析、行级建议、总结和聊天	主要围绕 PR/Diff 工作，Issue 验收标准是否完成仍需额外配置或人工判断
PR-Agent	提供 /review、/describe、/improve、/ask 等 PR Agent 能力	可以读取 PR 上下文，但不是以“主 Issue 验收标准覆盖”作为强制 Review 结构
GitHub Copilot Code Review	在 GitHub PR 中生成代码审查意见	仍然以代码变更为核心，团队内部设计和 Issue 目标需要额外提供
Graphite	提供现代 PR 页面、Stacked PR 和 AI Review	强在 PR 流程和 Review 体验，不负责本地 Issue 驱动 Coding
reviewdog	将 Lint、静态分析和测试结果发布为行级 Review 评论	依赖外部检查工具，本身不理解业务 Issue 或实现目标

现有做法的缺口

• Review 结果可能无法回答“这个 PR 是否真正完成了关联 Issue”。
• Issue 关联经常是可选或隐式信息，而不是 Review 的核心输入。
• 自动评论通常缺少与架构、验收标准和历史决策的明确引用。

功能机会

• 提供“一键 Review”：以主 Issue、PR、Diff、Commit、CI、团队规则和相关文档为统一上下文。
• 在 Review 前提醒没有关联主 Issue 的 PR 补充关联。
• 将 Issue 验收标准逐项映射到代码、测试和文档，输出“已覆盖、部分覆盖、未覆盖、无法判断”。
• 检查是否存在超出 Issue 范围的改动，以及测试、文档和规范是否完整。
• 在 Diff 旁提供 Ask，让 Reviewer 询问代码职责、变更影响、风险来源和设计背景。
• 默认将 AI 结论和行级意见保存为草稿，由人决定是否发布、请求修改或批准。

3.6 并行开发中缺少 Worktree 和依赖视图

用户痛点

• AI 时代可以同时运行多个开发任务，但开发者往往仍按瀑布方式推进。
• 多个任务在同一工作目录下运行会相互覆盖、抢占状态或污染环境。
• 多个 Branch 和 Worktree 容易失去对应的 Issue、Agent 和 PR 信息。
• 即使不同任务使用不同 Worktree，仍可能修改同一文件、依赖同一服务或占用同一端口。
• 任务阻塞后，不容易判断哪些后续任务受影响。

已有项目与解决方式

项目	主要解决方式	仍未解决的问题
Git Worktree	为同一个仓库创建多个独立工作目录，支持并行 Branch	只提供底层命令，不管理 Issue、Agent、任务依赖和资源冲突
GitHub Projects	用看板、表格和 Roadmap 管理 Issue/PR 状态	看不到本地 Worktree、Agent 进程、文件重叠和测试环境
Linear	提供任务依赖、项目和团队协作视图	任务视图与本地 Branch、Worktree 和 Coding Agent 之间不是默认关联
Bottleneck	面向 AI 原生团队提供 PR 工作台、批量操作和后台 Agent PR 查看	重点是 PR Review，Worktree 生命周期和 Issue 依赖管理不是核心能力
OpenHands Agent Canvas	管理多个 Agent 后端和自动化任务	更关注 Agent 运行和自动化，缺少面向本地 Worktree 的专门管理视图

现有做法的缺口

• Git Worktree 解决了本地目录隔离，但没有提供任务、Agent、依赖和冲突风险的协同视图。
• 看板可以描述任务状态，却通常不知道实际修改了哪些文件和分支。
• 多 Agent 工作缺少一处可查看、暂停和清理的入口。

功能机会

• 用可视化方式管理 Worktree 与 Issue、Agent、Branch、测试和 PR 的关系。
• 帮助用户判断哪些任务可以并行，哪些存在依赖。
• 显示 Worktree 的修改状态、关联任务、运行中的 Agent 和资源占用。
• 提前提示文件重叠、端口冲突、依赖冲突和集成风险。
• 在任务完成或 PR 合并后提醒用户处理不再需要的 Worktree，避免本地环境失控。

3.7 多个会话完成后，研发日报仍依赖人工整理

用户痛点

• 团队需要日报来同步当天完成的工作、进行中的任务、阻塞事项和下一步计划，但成员通常要手工翻找 Commit、PR、Issue 和聊天记录。
• 同一个任务可能由多个 Agent 会话和人工操作共同完成，仅按 Commit 列表生成日报会丢失任务目标、过程和结果。
• 自动生成的日报容易变成流水账，无法区分已完成、部分完成、失败和待确认的工作。
• 公司可能有固定的日报格式，个人还希望补充当天的背景、风险或明日计划。

现有做法的缺口

• Git 平台能提供 Commit、PR 和 Issue 数据，但不会自动把它们整理成面向团队阅读的日报。
• 通用 AI 总结通常缺少当天仓库活动和任务上下文，容易遗漏或虚构进展。
• 现有日报机器人往往只能套用固定模板，不能结合项目规范和用户补充提示词。

功能机会

• 根据用户选择的项目、分支或任务栏，读取当天的 Commit、PR、Issue、Review、CI 结果和 Agent 会话事件，生成日报草稿。
• 以任务为单位汇总多个 Commit 和会话，明确展示完成内容、验证结果、阻塞原因、风险和下一步，而不是简单罗列提交记录。
• 支持用户在生成前追加提示词或填写补充信息，例如“突出线上问题”“按项目 A/B 分组”“补充明天计划”。
• 提供可配置的公司日报模板和字段，并保留来源链接，让用户可以逐项核对和编辑后再发布。
• 支持将日报复制、导出或发布到团队使用的协作工具；默认由用户确认后执行，避免自动发布错误信息。

3.8 CI/CD 配置和失败日志难以理解

用户痛点

• 新项目需要配置测试、Lint、构建、部署等流程，但 YAML 和环境配置复杂。
• CI 失败时，开发者难以从长日志中判断根因。
• 用户无法快速区分是代码、依赖、环境、权限还是配置导致失败。
• 团队担心 AI 在不了解风险的情况下直接修改部署和生产配置。

已有项目与解决方式

项目	主要解决方式	仍未解决的问题
GitHub Actions	在仓库事件触发测试、构建、发布和自定义自动化	配置和失败日志仍偏工程实现，Issue 和业务验收上下文不一定完整
GitLab CI/CD	提供 Pipeline、Job、Artifact 和部署流程	能力完整，但新手仍需理解 YAML、Runner、变量和环境
act	在本地使用 Docker 运行 GitHub Actions	解决本地复现问题，但不负责解释失败原因或修改配置
reviewdog	将 Lint 和静态分析结果反馈到 PR	需要外部工具提供诊断，无法独立理解项目目标和 CI 根因
Renovate	自动创建依赖升级 PR 并运行检查	聚焦依赖更新，不是通用 CI/CD 配置和失败诊断助手

现有做法的缺口

• CI 配置模板通常不能解释为什么这样配置。
• 失败日志与 Issue、PR、代码变更和团队规范没有在一个上下文中呈现。
• 对新手而言，修复建议缺少风险说明和验证路径。

功能机会

• 从项目、PR 和 CI 日志的上下文中解释失败原因。
• 帮助用户理解一条 CI 流程包含哪些步骤、每一步的目的和风险。
• 根据团队模板生成或补全 CI 配置草稿。
• 将修复建议与对应日志、代码变更和测试结果关联呈现。

4. 当前解决方案格局

领域	已有解决方案	已解决的问题	仍然存在的缺口
Git 操作	Git CLI、GitHub Desktop、SourceTree、GitKraken、IDE Git 面板	提供命令或图形化入口	Git 语义、风险、冲突和恢复仍难理解
Issue 与项目管理	GitHub Issues/Projects、GitLab Issues、Jira、Linear	记录需求和任务状态	与代码、Agent、PR 验收之间的上下文不连续
AI Coding	Codex、Claude Code 等本地 Coding Agent	生成代码、运行命令、修改项目	缺少团队级过程视图、规范和任务关联
AI Review	CodeRabbit、PR-Agent、GitHub Copilot Code Review	自动发现部分代码问题、生成评论	往往以 Diff 为中心，Issue 验收标准不是强制上下文
代码规范	Conventional Commits、commitlint、Git Hook、PR Template	约束格式和基本流程	配置分散，不易让人和 Agent 在填写时理解并遵守
并行开发与 Agent 任务	Branch、git worktree、GitHub Projects、Linear、OpenHands	隔离代码目录、管理任务或运行 Agent	缺少任务栏、会话、Worktree、依赖、资源和冲突的统一视图
研发日报	GitHub/GitLab 活动记录、日报机器人、通用 AI 总结	提供 Commit、PR 或活动摘要	缺少基于任务上下文的自动汇总、来源核对和公司模板适配
CI/CD	GitHub Actions、GitLab CI、模板仓库	自动化检查、构建和部署	配置和失败日志对新手仍然复杂

5. 现有项目实践案例

本节整理已经调研到的项目做法，用于理解市场上不同工具解决了哪些问题，以及它们与本产品设想的差异。项目名称、命令名和官方文件名保留原样。

5.1 GitHub CLI

• 项目简介：GitHub CLI 是 GitHub 的官方命令行工具。
• 核心做法：通过 gh issue、gh pr、gh project、gh workflow、gh run、gh label 和 gh repo 操作 GitHub 对象；通过 gh api 补充 REST 和 GraphQL 能力。
• 解决的问题：让用户在本地终端中完成 Issue、PR、Review、Project、Actions 和仓库操作，并复用本地认证状态。
• 可借鉴之处：本地执行、命令能力完整、与用户现有 GitHub 权限和仓库环境结合紧密。
• 差异和缺口：它提供操作能力，但不负责 Git/Worktree 可视化、Issue 上下文串联、新手引导或 Agent 任务编排。

5.2 OpenHands Agent Canvas

• 项目简介：OpenHands 的 Agent Canvas 是面向开发 Agent 的自托管控制中心。
• 核心做法：通过统一界面连接本地、Docker、虚拟机或云端 Agent，并支持 GitHub、Slack 等外部服务和自动化任务。
• 解决的问题：集中管理 Agent 会话、后台任务和自动化工作流。
• 可借鉴之处：Agent 任务统一管理、多种执行后端和外部服务连接。
• 差异和缺口：它更偏通用 Agent 控制中心，不以本地 Git/Worktree 管理和“Issue 到 PR”闭环为核心。

5.3 Bottleneck

• 项目简介：Bottleneck 是面向 AI 原生团队的 PR Review 桌面工具。
• 核心做法：提供快速 PR 导航、Diff 查看、PR 分组、批量操作、本地缓存和 Monaco 编辑器，并针对后台 Agent 产生的大量 PR 优化体验。
• 解决的问题：帮助团队更快浏览、比较和处理多个 Agent 生成的 PR。
• 可借鉴之处：高密度 PR 工作台、批量操作和面向并行 Agent 的 Review 体验。
• 差异和缺口：它偏向桌面 PR 工具，不负责 Issue 驱动 Coding、Worktree 生命周期或团队规范编排。

5.4 PR-Agent

• 项目简介：PR-Agent 是开源的 AI PR Review 项目。
• 核心做法：提供 /review、/describe、/improve、/ask 等 PR 工具，支持 GitHub、GitLab、Bitbucket、Azure DevOps 和 Gitea 等平台。
• 解决的问题：自动生成 PR 描述、审查意见、改进建议和代码问答。
• 可借鉴之处：Review 能力完整、命令化程度高、可自托管并支持多平台。
• 差异和缺口：主要围绕 PR/Diff 工作，关联 Issue 的验收标准不是默认的强制 Review 结构。

5.5 CodeRabbit

• 项目简介：CodeRabbit 是商业化的 AI Code Review 产品。
• 核心做法：在 PR 中提供上下文分析、行级建议、总结和聊天能力。
• 解决的问题：让 Reviewer 在熟悉的 PR 页面内获得自动反馈和代码解释。
• 可借鉴之处：把 AI 反馈放进 Reviewer 的工作位置，并提供连续追问。
• 差异和缺口：主要聚焦 Review，不覆盖本地 Git、Worktree、Issue 驱动 Coding 和本地 Coding Agent 编排。

5.6 pi-dispatch

• 项目简介：pi-dispatch 是面向 pi Coding Agent 的自托管任务调度服务。
• 核心做法：提供任务队列、Cron 和 GitHub/GitLab 事件触发、容器隔离、预算限制、运行历史和管理面板。
• 解决的问题：让 Agent 能够在后台持续运行，并控制并发、成本和执行边界。
• 可借鉴之处：Agent 任务生命周期、队列管理、并发控制、成本统计和安全隔离。
• 差异和缺口：它偏 Agent 运行基础设施，不是面向开发者的本地 Git 工作台。

5.7 SWE-agent 与 OpenHands

• 项目简介：SWE-agent 和 OpenHands 都支持让 Agent 根据 Issue 或任务理解代码库、修改代码并运行测试。
• 核心做法：将 Issue 或任务转换为 Agent 的执行目标，再由 Agent 操作代码和工具完成任务。
• 解决的问题：减少从问题描述到代码修改之间的人工编码工作。
• 可借鉴之处：Issue 驱动的自动编码流程，以及让 Agent 在真实代码库中执行任务的方式。
• 差异和缺口：它们不是面向新手的 Git 操作教学工具，也没有把 Worktree、团队规范和持续的 Issue/PR Review 上下文作为统一工作台的核心。

5.8 Graphite

• 项目简介：Graphite 是面向 GitHub 团队的代码 Review 和 Stacked PR 产品。
• 核心做法：通过 Stacked PR、优化后的 PR 页面和 AI Review 帮助团队拆分和推进变更。
• 解决的问题：降低大型变更的 Review 成本，支持并行推进和更快的反馈循环。
• 可借鉴之处：Stacked PR、分层 Review 和团队 Review 流程设计。
• 差异和缺口：强在 PR 流程和 Review 体验，不负责本地 Agent 执行、Worktree 管理或 Issue 到 Coding 的过程编排。

5.9 reviewdog

• 项目简介：reviewdog 是一个将代码检查结果接入 Review 流程的工具。
• 核心做法：读取 Lint、静态分析和测试工具的输出，将与 Diff 相关的问题发布为 GitHub/GitLab 行级评论或 Check。
• 解决的问题：把现有代码质量工具的结果集中反馈到 PR 中。
• 可借鉴之处：将自动化检查结果放回开发者正在进行 Review 的位置。
• 差异和缺口：它依赖外部检查工具，本身不是 Coding Agent，也不理解 Issue 的业务目标。

5.10 案例对比与产品启发

能力	GitHub CLI	OpenHands	Bottleneck	PR-Agent	pi-dispatch	本产品机会
GitHub 操作	强	中	中	中	中	统一可视化
Issue 驱动 Coding	弱	强	弱	弱	中	让 Issue 上下文贯穿全流程
PR Review	弱	中	强	强	弱	基于 Issue 验收标准 Review
Worktree 管理	弱	中	中	弱	中	面向用户和 Agent 的 Worktree 工作台
本地 Agent	强	可选	弱	可选	可选	Codex/Claude Code 加自有 Go Agent
团队规范	弱	中	弱	中	中	仓库内 .codedock/ 规范
任务编排与会话管理	弱	强	弱	弱	强	任务栏关联多个 Agent 会话、Worktree、Issue 和 PR
研发日报	弱	中	弱	弱	中	基于 Commit、任务和会话生成可核对的日报

这些案例带来的调研结论是：现有项目通常只解决 Git、Coding、Review 或 Agent 调度中的一个切片。GitHub CLI 适合作为本地操作入口，但无法提供完整的产品体验；Issue 到 Coding 再到 PR 的上下文连续性，以及任务栏、会话、Worktree、任务依赖和冲突风险的统一视图，仍然存在明显缺口。AI Review 的差异化重点也不应只是发现代码问题，还应判断 PR 是否完成了 Issue 的目标和验收标准。

6. 值得验证的产品形态

6.1 Issue -> Coding -> PR -> Review 核心闭环

这是产品最值得优先验证的完整使用场景：

1. 用户在平台中选择一个 Issue，点击“开始解决”。
2. 平台先帮助用户确认 Issue 的目标、范围、验收标准和必要上下文。
3. 用户选择使用本机的 Codex 或 Claude Code 来处理该 Issue。
4. Agent 先给出对 Issue 的理解、实施计划和待确认问题；用户确认后再开始 Coding。
5. Agent 在与该 Issue 绑定的开发环境中修改代码、运行测试并生成 Commit。
6. 平台展示 Agent 的执行状态、变更文件、测试结果和待处理问题。
7. 用户确认结果后，平台帮助创建一个关联该 Issue 的 Draft PR。
8. 用户点击“一键 Review”，系统使用同一个 Issue、验收标准、设计文档、团队规范和 PR Diff 作为 Review 上下文。
9. Agent 输出验收标准覆盖情况、风险、缺失测试和行级 Review 草稿。
10. Reviewer 在平台中理解、追问、修改并确认 Review 结果，最终将操作回写到 GitHub 或其他原平台。

这个闭环的核心不是“把 Issue 文本发送给 Coding Agent”，而是保持同一个 Issue 上下文在整个研发过程中的连续性：

Issue 目标
  -> Agent 方案
  -> 代码变更
  -> Commit
  -> PR
  -> Issue 验收标准 Review

平台负责组织上下文、呈现过程和请求确认；本地 Codex/Claude Code 负责理解和修改代码；GitHub/GitLab 负责保存最终的代码、Issue、PR 和 Review 记录。

6.2 这个闭环要验证的价值

• 用户是否愿意先建立 Issue，再通过 Issue 启动 Coding，而不是直接在终端给 Agent 下任务。
• Issue 的验收标准是否足以帮助 Agent 和 Reviewer 判断“是否完成”。
• 用户是否认为 Agent 的计划确认环节能减少错误修改。
• 用户是否愿意让同一个 Issue 上下文同时服务 Coding 和 PR Review。
• Review 结果是否比只看 Diff 的自动 Review 更有帮助。
• 从 Issue 到 Draft PR 的过程是否明显减少了手工复制、切换和补充信息的工作。

6.3 本地优先与仓库内团队规范

这是一个需要继续验证的产品形态假设：

• 用户在本机运行产品，产品可以直接访问本地 Git 仓库、Worktree、测试环境和已登录的 Coding Agent。
• GitHub、GitLab 等远程平台继续保存 Issue、PR、Review 和 CI 等团队协作记录。
• 团队规范放在项目 Git 仓库中，随着代码一起版本管理，并通过正常的 PR 流程修改。
• 产品启动项目时扫描并读取仓库内的规范配置，使用一个项目级隐藏目录保存规范和 Agent 上下文，目录名暂定为 .codedock/。
• .codedock/ 应成为团队可审阅的项目配置，而不是存放 Token、模型 Key 或个人隐私数据。
• 个人偏好和本机配置应与仓库规范分开，避免把个人设置提交给团队。

.codedock/ 可以承载以下类型的项目内容：

• 项目开发规则和禁止事项。
• 架构、模块和业务设计文档索引。
• Commit、Branch、Issue 和 PR 模板。
• Review 检查项和 Issue 验收规则。
• Agent 角色、任务流程和上下文入口。
• CI/CD 说明、环境要求和常见故障知识。

需要重点验证的是规范的来源和兼容方式：

• .codedock/ 是否作为平台的规范源，还是仅作为已有 AGENTS.md、CLAUDE.md 和 .github/ 配置的聚合入口。
• Codex、Claude Code 等不同 Agent 是否都能稳定理解同一套项目规范。
• 是否需要由 .codedock/ 生成或引用 AGENTS.md、CLAUDE.md 等 Agent 原生规则文件。
• 多仓库、Monorepo 和组织级规范如何继承、覆盖和冲突处理。
• 团队成员是否愿意通过 PR 审阅和修改规范目录。

这个方向的核心价值是：团队规则不再只存在于平台设置、聊天记录或个人 Prompt 中，而是成为项目的一部分，可以被开发者、Reviewer 和本地 Agent 共同读取。

6.4 任务栏与多 Agent 会话工作台

这是对 Web 多 Agent 使用场景的核心形态假设：用户管理的基本单位不是孤立的会话，而是一个可以持续推进的研发任务。

• 每个任务栏代表一个研发任务，至少关联一个主 Issue，并可关联多个 Branch、Worktree、PR 和测试环境。
• 一个任务栏可以同时挂载 Codex、Claude Code 等多个 Agent 会话；会话可以并行执行，也可以接续前一个会话的结果。
• 任务栏展示目标、当前状态、阻塞原因、最新变更和下一步；会话详情展示完整日志、Diff、测试结果、引用的规范和用户确认记录。
• 用户可以在任务栏内新建会话、切换 Agent、暂停或接管会话，并比较不同会话的计划和结果。
• 任务完成后，任务栏保留会话与 Commit、PR、Review 的关联，作为后续日报和问题追溯的来源。

需要验证的是：用户更习惯按 Issue、项目阶段还是个人目标组织任务；一个任务应允许多少并行会话；以及会话日志、代码片段和状态哪些适合共享给团队成员。

6.5 基于 Commit 和任务上下文的研发日报

日报不是独立的聊天总结功能，而是任务工作台的一个输出视图：

1. 用户选择日期、项目、任务栏或成员范围。
2. 系统读取当天的 Commit、PR、Issue、Review、CI 结果和相关 Agent 会话事件。
3. 系统按任务汇总完成内容、验证结果、阻塞事项和下一步，并为每条结论保留来源链接。
4. 用户追加提示词或手工补充背景，选择公司日报模板，编辑并确认草稿。
5. 用户将日报复制、导出或发布到团队协作工具。

日报生成需要明确区分“代码事实”和“用户补充”：前者必须可以回溯到 Commit、PR、Issue 或会话记录，后者应标记为人工输入，避免把推测当成进展。

6.6 第一版产品形态假设

第一版不追求覆盖完整研发流程，而是先验证一个最基础、最频繁的本地开发闭环：

查看 Git 状态
  -> 创建和管理 Worktree
  -> 选择 Codex 或 Claude Code
  -> 处理一个 Issue
  -> 生成规范化 Commit 信息

第一版最需要验证的功能集中在以下五个方面：

1. Git 操作可视化：让用户理解当前仓库状态、分支、修改、冲突和操作影响。
2. Worktree 管理：让用户为不同 Issue 或 Agent 创建、查看、切换和安全清理独立工作区。
3. Codex/Claude Code 兼容：让用户使用自己已经安装和信任的本地 Coding Agent 来处理任务。
4. Commit 信息生成：根据 Issue、Diff、团队规范和 Commit 历史生成 Commit Message 草稿，并让用户确认。
5. 任务栏与会话关联：让一个任务统一承载多个 Agent 会话，并能追踪各自的状态和结果。

Issue、Branch、Worktree、Agent 和 Commit 应在第一版中建立关联；日报自动生成、完整的 PR Review、CI/CD 和多平台支持可以作为后续产品形态继续验证。

6.7 自有 Agent：用 Go 实现的类 pi Agent 运行时

自有 Agent 不直接依赖现有 pi 项目，而是使用 Go 参考 pi 的核心思想和交互模式，复刻一个适合本产品的 Agent runtime。它的产品角色需要与 Codex、Claude Code 区分：

• Codex、Claude Code：负责实际的代码理解、代码修改、测试和技术文案生成。
• 自有 Go Agent：负责理解平台任务、组织 Issue 上下文、管理任务状态、协调 Worktree、请求用户确认和统一不同 Coding Agent 的结果。
• 平台界面：负责呈现 Git 状态、Worktree、Agent 过程和 Commit 草稿。

第一阶段自有 Go Agent 可以参考 pi 的以下能力形态：

• Agent Loop：接收任务、组织上下文、调用工具、处理结果、继续或结束任务。
• Tool Calling：统一调用 Git、Worktree、文件、测试和外部 Coding Agent 工具。
• Session State：保存任务过程、事件、用户确认和 Agent 输出。
• 可中断和可恢复：支持暂停、继续、取消和人工接管。
• Adapter：用统一接口连接 Codex、Claude Code 等本地 Coding Agent。

这样，自有 Agent 的差异化不在于重新做一个与 Codex/Claude Code 竞争的 Coding Agent，而在于成为 Git 和团队研发流程中的协调 Agent。

当前约束是：Go Agent 本身不直接连接云端模型 API；需要 AI 理解或生成时，通过本地 Codex、Claude Code 等 CLI Adapter 完成。未来如果要让 Go Agent 直接使用模型 API，应作为单独的产品决策，而不是默认行为。

基于以上调研，值得继续验证的不是“做一个新的 GitHub”，而是以下组合是否能给用户创造足够价值：

1. 一个围绕“Issue -> Coding -> PR -> Review”全链路的工作台，而非孤立的 Git 客户端或单点 AI Bot。
2. 一个以关联 Issue 和验收标准为核心依据的 PR Review 体验，而非只分析 Diff 的自动评论工具。
3. 一个将本地 Codex、Claude Code 等 Agent 的工作过程与项目、任务、Worktree、测试和 PR 关联起来的协作层。
4. 一个能把 Commit、Branch、PR、Label、Issue Template、AGENTS.md 等团队规范统一管理和解释的入口。
5. 一个帮助用户理解、而不是替用户黑盒执行的 Git、Review 和 CI 助手。
6. 一个本地优先的项目工作台：本地负责代码和 Agent，仓库负责团队规范，GitHub/GitLab 负责协作记录。
7. 一个用 Go 参考 pi 复刻的流程协调 Agent，而不是另一个与 Codex/Claude Code 重复的 Coding Agent。

7. 下一步调研问题

在定义具体功能和实现方式之前，建议通过访谈、观察和原型验证以下问题：

1. 目标用户首先是 Git 新手、独立开发者、小团队，还是已有成熟流程的企业团队？
2. 用户当前最耗时、最容易出错的环节，是 Git 操作、Issue 澄清、编码、Review、CI 还是并行协作？
3. 团队是否真的要求每个 PR 关联 Issue？关联是否包含明确的验收标准？
4. Reviewer 最希望 AI 解释什么：代码职责、变更影响、架构背景、测试覆盖还是业务规则？
5. 用户是否愿意把本机 Codex、Claude Code 的执行状态展示在团队工作台中？哪些日志或代码片段不能共享？
6. 团队是否已经使用 Worktree？如果没有，他们愿意为了并行 Agent 工作接受这一概念吗？
7. Commit、PR、Issue 和 Label 规范在团队中最常见的失效点是什么？
8. 用户希望平台只生成建议和草稿，还是愿意在人工确认后把结果写回 GitHub/GitLab？
9. 用户是否接受在每个项目中维护 .codedock/ 这样的规范目录？
10. 团队当前使用 AGENTS.md、CLAUDE.md 或其他规则文件时，是否希望统一入口，还是保持各 Agent 的原生文件？
11. 哪些规范应该进入仓库版本管理，哪些设置必须只保留在本机？
12. 用户是否愿意让一个用 Go 实现的 pi-like 协调 Agent 管理 Codex、Claude Code 和 Worktree，而不是直接与某个 Agent 单独交互？
13. Commit Message 和日报生成是由用户选择的 Codex/Claude Code 完成，还是由自有 pi Agent 负责协调后再调用对应后端？
14. 用户在一个任务中通常需要几个并行会话，哪些任务状态和会话内容需要共享给团队？