Gitmore 发布 5 项新功能：从 AI 代码追踪到 MCP 服务

开发者报告工具 Gitmore 一次性上线了 5 项新功能，重心落在两件事上：让代码活动数据更容易被不同角色消费，以及更主动地暴露 AI 参与开发后带来的新风险。

这套更新的逻辑并不复杂——当 AI 编程助手开始批量提交 PR，「谁在什么时候改了什么」这件事变得比以前更难追踪，Gitmore 试图在这个缝隙里提供一层汇总和警报机制。

面向客户的门户与多语言报告

第一项功能是 Client Portals。开发团队可以生成带密码保护的客户门户，把项目进展直接分享给非技术受众，而不必每次手写更新邮件。

报告会按受众类型生成摘要，支持 8 种语言，并可导出为 PDF。这个设计针对的是一个长期存在的摩擦点：工程进度数据通常埋在 Git 提交和 Issue 里，客户或非技术干系人很难直接读懂，中间往往需要有人翻译一遍。Gitmore 把这层翻译自动化了。

主动警报：盯着 AI 写的代码

第二项 Proactive Alerts 是这次更新中信息量最大的部分。它会监控三类情况：停滞的 PR、不活跃的 AI agent PR，以及 AI 撰写代码占比的变化。

警报通过邮件或 Slack 推送。第三类尤其值得注意——「AI 生成代码比例的变化」作为一个可被监控的指标，说明团队开始把 AI 参与度当成一个需要观测的工程变量，而不是一个纯粹的效率工具。当这个比例突然上升或下降，可能意味着工作流出了问题，也可能意味着代码审查压力在积累。

「AI 撰写代码占比」作为一个工程指标，背后对应的是代码归属（code attribution）问题。当 AI 编程助手直接产出代码并提交 PR 时，Git 的 author 字段往往仍记录为触发它的人类开发者，导致传统的按作者统计无法区分「人写的」和「AI 写的」。要得到这个占比，通常需要在提交信息、PR 元数据或工具链层面做标记，再按行数或提交数做归集。

这个指标之所以值得监控，是因为它与代码审查成本和缺陷率存在关联假设：AI 生成代码的比例在短期内快速抬升，往往意味着 PR 吞吐量上升、单次审查的深度下降，潜在的技术债和缺陷可能被推迟暴露。因此把占比变化作为警报触发条件，本质上是把「审查压力」这个难以直接测量的量，用一个可采集的代理指标来近似观察。

打通 Notion、Linear、Jira 等任务系统

第三项是任务管理集成，支持 Notion、Linear、Jira、Asana、ClickUp 和 Trello 六个平台。

核心能力有两个：把 pull request 匹配到对应任务，以及 PR 合并后自动关闭任务。Gitmore 特别强调，任何写回操作都需要人工批准——这显然是为了避免自动化误操作污染任务系统。对同时使用多个任务工具的团队来说，PR 与任务之间的手动对齐是一件琐碎但容易出错的事，自动化匹配能省下不少时间。

API 与只读 MCP 服务器

第四项是 API 和 MCP（Model Context Protocol）支持。Gitmore 提供了一个只读的 MCP 服务器，包含 6 个工具，让 Claude 这类 AI 助手能够查询仓库活动数据。

此外也提供 API key，供编码 agent 调用。MCP 是 Anthropic 推动的协议标准，让 AI 助手以统一方式接入外部数据源。Gitmore 选择只读模式是个稳妥的决定——让 AI 查询开发洞察，但不给它修改数据的能力，风险面小得多。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底开源的协议标准，目的是解决 AI 助手接入外部工具与数据源时接口碎片化的问题。在没有统一协议之前，每让 AI 助手读取一个新系统（数据库、SaaS 平台、代码仓库），开发者都要为它单独写一套对接逻辑，工作量大且难以复用。MCP 的做法是把「数据源」抽象成 MCP Server，把「AI 应用」抽象成 MCP Client，双方按统一的消息格式通信。Server 对外暴露若干 tool（工具），每个 tool 有明确的名称、参数结构和返回格式，Client 端的模型据此决定调用哪个工具、传什么参数。

MCP 的关键设计在于权限边界由 Server 侧决定。Server 可以选择只实现查询类工具而不实现写入类工具，这样即便模型产生误判，也无法对外部系统造成破坏。Gitmore 提供的只读 MCP 服务器（6 个工具）正是这一思路的典型落地：让 Claude 这类助手能查仓库活动数据，但拿不到任何修改能力，从架构层面把风险面收窄。

报告历史保留一年

第五项是 Report History。所有发出的报告会保存一年，可以回溯查看当时发出的邮件或 Slack 消息原文。

一个细节值得注意：查看历史报告不会被计为邮件打开，因为展示前会先移除追踪像素。这个小设计对有合规或隐私要求的团队来说是个加分项。

邮件打开追踪像素（tracking pixel） 是指在 HTML 邮件中嵌入的一个不可见的 1×1 像素图片，其 URL 带有唯一标识。当收件人加载邮件时，客户端会向服务器请求这张图片，服务器据此记录「该邮件已被打开」以及打开的时间、次数和大致 IP 信息。营销和客户成功团队常用它来评估触达效果。

但追踪像素也会带来副作用：它会在收件人不知情的情况下回传信息，部分隐私法规和企业的安全策略会阻止或剥离这类图片。Gitmore 在展示历史报告前先移除追踪像素，意味着回看存档不会向任何人回传信号，也不会被统计成一次新的「打开」。对需要留存沟通记录用于审计、合规或客户争议举证的团队来说，这能保证存档内容与实际发送内容的语义一致，而不是让一次内部查阅意外地污染打开率数据。

这次更新说明了什么

把这 5 项功能放在一起看，Gitmore 的产品方向指向一个正在成形的问题：AI 参与软件开发之后，工程可观测性的对象变了。

以前需要追踪的是「人写了什么代码」，现在还需要追踪「AI 写了多少代码」「AI 提交的 PR 有没有人管」。Proactive Alerts 里针对 AI agent PR 的监控，以及 AI 代码占比的追踪，都是为这个新场景准备的。而 Client Portals 和任务集成解决的则是老问题——把工程数据翻译给非工程角色，以及减少工具之间的手动搬运。

所有功能已上线，免费计划可用。对于正在把 AI 编码工具引入工作流的团队，Gitmore 这套功能提供了一个值得关注的观测视角。