Macroscope

Macroscope 站内给自己的一句话是「指挥你自己的软件工厂」，落点在研发流程里的三件事：合并前的审查、变更的说明、以及跨仓库的状态汇总。它不替代编辑器，而是在代码进入主干之前多设一道自动检查，并把「这段时间到底改了什么、为什么改」讲清楚。

核心能力

• 代码审查：官方描述为在变更落地之前，逐次检查正确性、安全性、测试覆盖与回归风险，属于合并前的拦截而不是线上出事后的补救，面向的是每次提交而非整包代码。
• 自动 PR 描述：官方称可自动撰写拉取请求说明，把改动内容和意图写成可读的摘要，让评审者先看懂意图再看代码，减少作者手写描述的时间。
• 状态总览：官方描述为看清每个仓库、每个团队改了什么、为什么改、哪里需要关注，服务对象是负责人而不是单人开发者。
• 按仓库与团队切分：Status 强调覆盖每个仓库与每个团队，可按其中任一维度分开看，负责人只看自己那一块，不必翻全量。
• Murmur 云端 Agent：站内标注为 beta，官方称可编排在隔离沙箱中写代码并自行验证结果的云端智能体，属于比审查更进一步的动作。
• 接入现有流程：官网提供免费起步与预约演示两条路径，说明它按接入既有研发流程设计，不要求团队换一套工作方式。

适合谁

• 多仓库、多小组并行开发的研发团队，需要一个统一视角看变更。
• 技术负责人与团队 leader，要快速回答这周进展到哪、哪里卡住。
• 审查人力紧张的团队，把基础的正确性与安全问题先过一遍机器。
• 开源维护者，面对外部提交需要先做一轮初筛，避免被低质量提交淹没。
• 平台与基础设施团队，改一处影响多个服务，需要跨仓库看回归风险。

使用建议

• 先用只读方式接一个仓库跑两周，看审查意见的命中率，再决定是否设为合并门禁。
• 审查规则按团队实际风险排序：安全与回归优先，风格类意见容易淹没真正的问题。
• 自动生成的 PR 描述建议人工过一眼再发，涉及对外沟通的仓库尤其如此。
• Murmur 仍标为 beta，先在隔离沙箱与非核心仓库验证，别直接放到主干分支上。
• 每月抽查几个线上问题，回看审查阶段是否提过；代码会进第三方服务，接入前确认留存与权限，规则可能调整，签约前再核一次。