GitWhy

GitWhy 是什么？

GitWhy 是 Git 的“上下文层”，用于保存并分享 AI 生成代码背后的推理依据，并直接与产生该代码的提交关联。目标是让提示词、决策和权衡方案可与代码变更一同审查，而不是仅留存在聊天窗口中。

它捕获结构化上下文（例如原始提示词、推理、决策、被拒绝的备选方案），并将该上下文链接到提交。然后，产品会在 pull request 中呈现保存的推理，让审阅者了解变更原因，而非仅看 diff。

主要特性

• 结构化“推理”上下文：存储固定格式，包括提示词、推理、决策、被拒绝的备选方案、文件和提交，确保多次运行输出一致。
• 链接到提交（git 原生溯源）：每个保存的上下文与产生它的确切提交绑定，确保文档始终锚定在代码历史中。
• 通过 gitwhy-bot 在 PR 中呈现：将完整推理推送到 pull request 作为 PR 评论，在代码审查期间提供审查上下文。
• 云同步与分享：将保存的上下文同步到云端，便于团队跨组织分享。
• 跨保存上下文搜索：允许用户按关键词、领域或主题搜索保存的推理，快速找到以往决策。
• 兼容 MCP 代理：专为任何 MCP 兼容代理设计（页面明确提及 Claude Code、Cursor、Windsurf 和 Cline）。
• 终端 UI 管理：提供交互式终端界面，用于浏览、搜索和管理上下文，无需浏览器。

如何使用 GitWhy

1. 使用 MCP 兼容代理生成代码，确保代理输出你想捕获的推理。
2. 保存推理上下文，GitWhy 记录结构化项目（提示词、推理、决策、被拒绝的备选方案、文件和提交），并链接到相关提交。
3. 同步到云端（用于团队分享），然后打开 pull request。
4. 在 PR 中审查：GitWhy 的 bot 将保存的推理发布到 pull request，审阅者可阅读底层决策和权衡。

使用场景

• AI 辅助变更的 PR 审查：AI 生成代码时，审阅者可在 PR 评论中阅读存储的推理和决策，而非从 diff 推断意图。
• 团队知识捕获重复设计选择：认证、数据库和 API 设计决策可存储在按领域/主题组织的上下文树中，帮助团队复用以往依据。
• 审计特定提交背后的“为什么”：由于每个上下文链接到产生它的提交，开发者可追溯决策起源至确切代码变更。
• 新工作中更快检索：从终端、代理或团队仪表板按关键词、领域或主题搜索保存上下文，快速找到相关依据。
• 多代理工作流：使用不同 MCP 兼容代理的团队可在统一位置捕获和管理推理，而非依赖单一聊天界面。

常见问题

• GitWhy 为每个上下文存储哪些信息？ 页面描述了一种结构化格式，包括提示词、推理、决策、被拒绝的备选方案、文件和提交。

• GitWhy 如何将推理连接到代码？ 它将每个保存的上下文链接到产生它的确切提交。

• 审阅者在何处看到推理？ GitWhy 的 bot 将完整推理发布到 pull request 作为 PR 评论。

• 无需浏览器也能使用吗？ 是的。产品包含交互式终端 UI，用于浏览、搜索和管理上下文。

• 支持哪些代理？ 站点表示它兼容任何 MCP 代理，并特别提及 Claude Code、Cursor、Windsurf 和 Cline。

替代方案

• 普通的 PR 描述或评论：团队可以手动将推理依据粘贴到 PR 文本中，但这无法自动保存结构化的、与提交关联的变更原因历史记录。
• 外部文档系统（wiki/知识库）：团队可以单独维护决策文档，但这些文档并非天然与提交关联，也不会自动在 PR 中呈现。
• 本地日志/聊天历史审查：阅读先前的聊天日志可提供上下文，但搜索性较差，且通常与仓库历史中的提交无关联。
• 通用代码审查工具的注解功能：能注解 diff 的工具可解释变更，但此处源文本强调结构化的、与提交关联的推理依据及通过 gitwhy-bot 发布到 PR，这可能并非通用审查工具所能覆盖。