一句话看懂：一位开发者把 GitHub Copilot 的流量引导到自建的中间人代理后，实时观察到了模型路由、上下文拼接和历史记录检索的完整过程，并发现 Copilot 在补全时会从当前编辑文件之外的路径拉取上下文，有引入敏感文件（如 .env）的风险。
事件核心：发生了什么
这位开发者将 GitHub Copilot 的请求代理到自己的中间层，借此观测它在 VS Code 中的实际行为。通过流量分析，他看到了几个关键细节：第一，Copilot 的模型/能力发现和路由是动态发生的，整个过程可以在代理侧实时看到；第二，ghost completions（幽灵补全，即后台预生成的建议代码）发送时会携带拼接好的上下文，而最近编辑过的内容可能会把其他文件里的片段引入当前会话——包括常见的敏感文件 .env；第三，他发现 Copilot 的 Chronicle 历史记录功能背后是一个 SQLite 会话存储库，里面保留了过去的 prompts/responses，模型可以通过工具调用主动查询这些历史。
随后，他查看了 VS Code 源码，尝试把网络层观测到的行为与实现逻辑对应起来，确认了部分机制。整个过程没有涉及模型能力的横向评测，而是聚焦于 Copilot harness（外部接入层）的工程实现方式。这些细节发布后，在 Hacker News 上引发了不少开发者对 AI 编程插件隐私边界和上下文控制能力的讨论。
为什么重要
这次观测提供了少见的“接线层”视角：此前多数讨论集中在 Copilot 生成代码的质量上，很少有人在用户与模型之间把真实传输的数据摊开来看。它的意义在于两点。一是可观测性价值：说明 OpenAI 和 Microsoft 为 Copilot 搭建的这套系统高度动态化，路由选择、历史读取和上下文拼装都发生在云端或本地的逻辑层里，开发者很难从 VS Code 界面感知到数据被如何组织。二是安全面问题：因为最近编辑的文件可能触发跨文件上下文拉取，如果用户同时打开了 .env、密钥文件等敏感内容，这些内容有被拼入补全请求、进而发送给模型处理的可能性。目前公开信息显示，这种拉取是否会持久化或用于模型训练，观察者还无法从抓包数据中完全确定，但它的确揭示了 AI 编程工具在默认配置下缺乏显式的敏感内容过滤。
对用户/开发者/创作者的影响
对普通开发者，这次发现的实用提醒是：使用 Copilot 时，项目目录里最好避免存放明文密钥；如果涉及敏感仓库，应关闭 ghost completions 或通过代理层监控外发内容。对做内部工具或企业级 AI 编程平台的技术团队，这组观察提供了 harness 设计的参考样本——上下文拼接策略、历史存储结构、模型工具调用机制都是可以逆向学习的工程细节，同时也提示他们在自建类似产品时，需要把接入层的透明度和审计能力作为默认功能。对于企业采购者，如果团队在合规要求较高的行业里使用编程助手工具，应该回到 Copilot 的企业管理策略里检查是否有上下文裁剪、敏感文件忽略和审计日志选项。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
接下来可以关注几个方向：一是 Copilot 官方是否会针对“.env 等敏感文件被拉入上下文”的问题给出正式回应或产品层面的过滤开关；二是其他基于大模型的编程助手（如 Codeium、通义灵码等）是否也存在类似的跨文件上下文拼接行为；三是代理观测方式是否会被平台方限制——如果未来 Copilot 在协议层做证书固定或加密强化，类似的第三方中间层研究将更难复制。
来源：hackernews
