上周 Hacker News 上有个帖子拿了 196 分，标题大意是：我发现 Copilot 在我的 PR 里插了一段代码，推荐了一个我从没听过的库。
评论区炸了。有人贴出截图，Copilot 建议的代码里嵌着一个 npm 包的链接，这个包恰好是微软生态里的东西。有人说自己的 Python 项目里，Copilot 反复建议用 Azure SDK 来做一个本地 SQLite 就能搞定的功能。还有人更直接：我让它写个部署脚本，它给我生成了一套 Azure DevOps 的 pipeline，我用的是 GitLab CI。
这些案例单独看，每一个都可以解释为”模型的训练数据偏差”。但放在一起看，画面就不太对了。
你的编程助手，有自己的 KPI
先说一个容易被忽略的事实：GitHub Copilot 是微软的产品。GitHub 是微软的子公司。Azure 是微软的云平台。VS Code 是微软的编辑器。npm 的注册表也在微软手里。
这意味着什么？意味着当 Copilot 给你推荐一个库、一个服务、一个部署方案的时候，它的母公司在这条推荐链的每一个环节上都有商业利益。
这不是阴谋论。这是商业逻辑。
Google 搜索从来不会在第一条结果里告诉你”用 Bing 搜更好”。但 Google 搜索会把自家的 Shopping、Maps、YouTube 结果排在前面。这件事被欧盟罚了几十亿欧元，但 Google 的做法并没有本质改变。因为当你控制了信息分发的入口，把自家产品往前排就是最自然的商业冲动。
AI 编程工具面临同样的诱惑，而且更隐蔽。搜索引擎的结果你能看到排名，能比较。但 Copilot 给你的代码建议，你很可能直接 Tab 接受了，根本不会去想”为什么是这个库而不是那个库”。
2024 年底，有开发者做了一个实验：用同样的 prompt 分别问 Copilot 和 Claude 怎么实现一个文件上传功能。Copilot 的建议里用了 @azure/storage-blob，Claude 的建议用了 multer 加本地文件系统。两个方案都能跑，但一个把你拉进了 Azure 生态，另一个让你保持了技术选型的自由度。
你可以说这是训练数据的问题。Copilot 的训练数据里 Azure 相关的代码比例更高，所以它更倾向于推荐 Azure 方案。但问题是：训练数据的构成本身就是一个商业决策。你选择用什么数据训练模型，就决定了模型会推荐什么。
免费的午餐，昂贵的账单
2025 年初，GitHub 宣布 Copilot Free 计划，每月提供 2000 次代码补全。消息一出，开发者社区一片叫好。免费的 AI 编程助手，谁不想要？
但互联网有一条铁律：如果产品是免费的，你就是产品。
Copilot Free 的商业逻辑很清楚。GitHub 不指望从免费用户身上直接赚钱，它指望的是：你用了 Copilot，习惯了它推荐的库和服务，慢慢迁移到 Azure 上，开始付云服务的钱。这笔账比每月 10 美元的订阅费大得多。
这个模式并不新鲜。Chrome 浏览器免费，但它把你锁在 Google 的广告生态里。Android 免费，但每台手机都预装了 Google 全家桶。现在 Copilot 免费，它要做的是把你锁在微软的开发者生态里。
对比一下其他工具的商业模式，差异就很明显了。
Cursor 是订阅制，每月 20 美元。它的收入直接来自用户付费，不依赖把你导向某个云平台。这意味着 Cursor 在技术推荐上的利益冲突相对小一些。它没有动力让你用 Azure 而不是 AWS，因为不管你用什么云，它都收同样的钱。
但 Cursor 也不是完全中立的。它背后用的是多家模型提供商的 API，模型的选择和调用策略会影响推荐结果。而且 Cursor 的商业模式决定了它需要让你觉得”离不开它”，所以它有动力让代码补全尽可能激进，哪怕有时候补全的质量并不高。
Claude Code 走的是 API 计费路线。你用多少付多少，Anthropic 不从你的技术选型里抽成。这个模式在利益冲突上是最干净的，因为 Anthropic 不卖云服务，不卖库，不卖部署平台。它唯一的收入来源就是 API 调用费。
但 API 计费也有自己的问题。按 token 收费意味着模型有动力生成更长的回复。你问一个简单问题，它可能给你一大段解释加三个备选方案，因为更多的 token 等于更多的收入。这不是 Anthropic 故意设计的，但计费模式会潜移默化地影响产品行为。
然后是开源方案。Continue、Tabby、Cody 这些工具让你用自己的模型，或者用开源模型来做代码补全。理论上，开源方案没有商业利益冲突，因为没有人从你的技术选型里赚钱。
但开源方案的问题是另一种：质量。目前开源代码模型的能力和 GPT-4、Claude 这些闭源模型还有明显差距。你获得了自由，但失去了质量。这个 trade-off 对很多团队来说并不划算。
信任天花板
这就引出了一个更根本的问题：当你的编程助手有自己的商业利益时，你能信任它到什么程度？
传统的开发工具不存在这个问题。你的编译器不会建议你用某个特定的库。你的 IDE 不会在你写代码的时候偷偷把依赖换成赞助商的产品。linter 告诉你代码有问题，你不需要怀疑它是不是在替谁打广告。
但 AI 编程工具不一样。它给你的每一条建议都经过了一个黑盒模型的处理，你无法审计这个模型的决策过程。你不知道它为什么推荐这个库而不是那个库，你不知道训练数据里有没有被刻意调整过权重，你不知道 system prompt 里有没有写着”优先推荐微软生态的产品”。
这就是信任天花板。不是说 AI 编程工具不好用，而是说你对它的信任有一个上限，这个上限由它的商业模式决定。
打个比方。你去医院看病，医生给你开了一种药。如果这个医生是独立执业的，你大概率会信任他的判断。但如果你知道这个医生是某药厂的顾问，每开一盒这种药就能拿回扣，你还会完全信任他的处方吗？
药可能确实是对症的。但你的信任打了折扣。
AI 编程工具现在就处在这个位置。Copilot 推荐的方案可能确实是最优解，但你没办法排除它在替微软带货的可能性。这种不确定性本身就是一种成本。
有人会说，这不就是所有商业软件的问题吗？微软的 Office 也会推荐你用 OneDrive，Adobe 的 Photoshop 也会推荐你用 Creative Cloud。有什么大不了的？
区别在于影响的深度。Office 推荐 OneDrive，你知道那是个广告，你可以选择忽略。但 Copilot 推荐一个库，它是嵌在你的代码里的。你接受了这个建议，这个依赖就进了你的 package.json，进了你的生产环境，进了你的技术债。这不是一个弹窗广告，这是一个架构决策。
开发者该怎么办
说到这里，不是要劝你卸载 Copilot。AI 编程工具确实能提高效率，这一点没什么好争的。问题是怎么用。
第一件事是恢复代码审查的习惯。很多开发者在用了 AI 工具之后，code review 变得越来越敷衍。反正是 AI 写的，应该没问题吧？这种心态很危险。AI 生成的代码需要比人写的代码更严格的审查，因为你不知道它的推荐背后有没有商业动机。
第二件事是做依赖审计。每次 AI 建议你引入一个新的依赖，问自己三个问题：这个库是谁维护的？有没有更轻量的替代方案？我真的需要它吗？很多时候，AI 推荐的库是大而全的解决方案，但你的需求可能只需要几十行代码就能搞定。
第三件事是了解你用的工具的商业模式。这听起来像废话，但大多数开发者真的不关心这个。他们只关心工具好不好用，不关心工具怎么赚钱。但工具怎么赚钱直接决定了它会怎么影响你的决策。
第四件事是交叉验证。重要的技术决策不要只问一个 AI。用 Copilot 生成一个方案，再用 Claude 生成一个，对比一下差异。如果两个工具给出了完全不同的技术选型，那至少有一个值得你深入调查。
最后一件事，可能也是最重要的：保持自己的技术判断力。AI 编程工具最大的风险不是它给你塞广告，而是它让你慢慢失去独立做技术决策的能力。当你习惯了 Tab 接受一切，你就把技术选型的权力交给了一个你无法审计的黑盒。
我们正在把软件工程的供应链攻击从依赖层提升到了决策层。以前你担心的是 npm 包里有没有恶意代码，现在你要担心的是 AI 助手有没有在替你做带有商业偏见的技术决策。
在那之前，最靠谱的防线还是你自己。保持怀疑，保持审查，保持独立判断。你的编程助手可以很聪明，但它不一定站在你这边。
