GitHub 让智能体理解团队开发习惯

每次让 AI 接手任务，都要重新解释测试怎么跑、PR 怎么写、跨仓库代码去哪里找，这些重复沟通正在成为 AI 编程的隐性成本。GitHub intelligence 想把团队已经积累的知识带进下一次会话，让 Agent 接着已有经验工作。

它把这件事拆成三部分：Memory 保存经验，Dreaming 更新经验，Code Search 寻找当前任务需要的代码。方向很实用，但三者的可用范围、权限和费用各有条件，公布的数据也需要放回具体样本里看。

Memory 能记住什么，效果该怎么看

GitHub 将 intelligence 定义为来自 GitHub 数据关系的上下文与学习层。这里的「关系」可以理解成代码、开发历史与团队工作方式之间的联系。例如，一个边界情况为什么要特殊处理，又由哪个测试覆盖。

Copilot Memory 目前已向付费 Copilot 套餐正式开放，可以跨会话、跨客户端记住个人偏好和仓库约定。原文列出的记忆创建入口包括 Copilot app、Copilot CLI、VS Code、Copilot cloud agent、Copilot code review、Slack、Teams 和 GitHub Mobile。

个人偏好可以是「PR 描述先写 TL;DR」，仓库记忆则可以保存正确的测试命令，以及团队要求 Copilot 如何检查自己的修改。除了用户主动要求记住，Copilot 会话也会自主生成和整理记忆。

这解决的是指导反复丢失的问题。测试命令写过一次，下一次任务仍能取用，才有机会减少重复解释。

原文给了两组数据：公开预览期间，在被审查且使用了 Memory 的 Copilot CLI 会话中，93% 更好地遵循了开发者偏好，42% 的工作流程因上下文里的记忆而更高效。

这两组数字反映的是特定会话样本，不能直接理解成所有用户的普遍收益。

原文没有交代样本量、对照方式，以及「更高效」如何衡量，也没有说 42% 是耗时减少了 42%。它说的是这部分会话出现了效率改善。

用户可以在 Copilot app、Copilot CLI 和 VS Code 中与记忆交互，也可以在 Copilot settings 中查看或删除个人记忆。

记忆会过时，Dreaming 怎么处理

只保存经验还不够。测试入口会换，团队规范会调整，过去合理的约定也可能失效。Copilot dreaming 尝试通过回顾过去的工作，改善后续 Agent 会话，目前处于公开预览。

它提供三种整理方向：

• Personal memory curation 根据 Agent 对话更新个人偏好。
• Repository customization 管理仓库记忆，并为已有 skills 和自定义指令文件提出改进。
• Code review customization 把反复出现、且被接受的评审反馈转成 Copilot code review 的指导。

这里有一个关键区别：Dreaming 可以直接新增、更新和删除个人及仓库记忆；对于已经提交到仓库的 skills 和指令文件，修改会通过 pull request 提出，交给团队审查。

这种分工有道理。记忆适合持续整理，进入版本管理的团队规则则需要可审查的变更记录。不过，原文没有说明它如何判断旧规则失效，也没有给出错误归纳的评估数据。

启用方式也有区别。个人订阅者需要分别在 Copilot settings 和各仓库设置中开启对应能力。组织和企业由管理员通过 Copilot policies 控制，企业管理员可以把选择权交给组织管理员；用户仍需自行启用个人 dreaming。仓库 dreaming 的覆盖范围受 Copilot Memory 仓库访问设置约束。

另外，dream runs 会消耗 AI credits。原文没有列出具体单次成本，不能把持续整理上下文当成免费的后台功能。

跨仓库搜索，为什么比多塞几份文件更有用

Memory 保存「过去知道什么」，Code Search 负责寻找「这次还需要知道什么」。

很多问题无法在当前 checkout 里解释完整。原文用支付重试举例：支付服务、共享库和后台 worker 都可能参与重试，只看一个仓库，容易漏掉重复触发的路径。

GitHub code search 让 Copilot 无须先在本地克隆相关仓库，就能查找代码、配置、schema 和文档。它支持精确文本、符号、正则表达式，以及按仓库、路径、语言缩小范围；语义搜索还能按功能描述找代码，例如查找「失败支付的重试逻辑」，不必提前知道函数名。

原文给出的入口是 /research。用户可以让 Copilot 调查这些组件如何重试扣款，以及哪些地方可能重复重试，再根据实现和调用方理解系统。

这也适用于跨仓库 API 迁移：先找实现与调用方，再规划各服务要改什么，最后检查哪些项目仍在使用旧 API。另一个用途是查找组织已有模式，帮助 Agent 在陌生仓库里遵循团队习惯。

它减少了人工拼接上下文的工作，但原文没有给出搜索完整率，也没证明一次调查能找全所有调用关系。调查结果仍需要结合具体代码核对。

我的判断

我认可这套拆分。保存经验、修订经验、检索当前事实，分别处理了 AI 编程里不同的上下文问题，比笼统地要求 Agent「多了解项目」更具体。

真正有价值的不是记住更多，而是经验能更新，关键规则能审查。

和手工维护仓库指令相比，Memory 更方便承接零散偏好；Dreaming 则试图减少人工整理成本。但自动归纳仍有前提：一次对话里的临时要求，未必适合成为长期约定；反复被接受的评审意见，也未必适用于所有模块。原文没有说明这些边界如何识别。

对于稳定的测试步骤、架构限制和团队规范，我仍倾向保留版本化指令，把 Memory 用作补充。至于效率提升，目前有特定样本的观察结果，缺少充分对照数据，还不足以支持普遍结论。

能拿来做什么

• 把反复输入的 PR 格式、测试命令和修改后检查要求整理出来，分别放入个人偏好与仓库约定，并核对保存内容是否准确。
• 在试用 Dreaming 时，把它提出的 skills、指令文件 PR 当成规范变更审查，重点检查是否把临时需求写成了长期规则，同时关注 AI credits 消耗。
• 做跨仓库 API 迁移或排查共享库问题前，先用 /research 查实现、调用方和旧 API 使用位置，再据此确定修改范围，人工核对关键代码引用。