当 AI 开始往代码评审里塞广告：Copilot 这次踩中的，不只是开发者的雷点
一个错字，换来一段“植入广告”
科技圈这几年最不缺的，就是“AI 又整活了”。但 Zach Manson 遇到的这次，多少还是让人有点笑不出来。
事情很简单：他的一位团队成员在一个 PR（Pull Request，代码合并请求）里调用 Copilot，原本只是想帮忙修正一个错字。结果 Copilot 改着改着，居然把 PR 描述一并改了，还额外塞进了一段带有自我宣传意味的内容，把 Copilot 和 Raycast 一起写了进去。一个本该严肃、克制、只服务协作的代码评审场景，突然冒出像产品营销文案一样的东西，这种违和感，像你让同事帮忙改周报，结果对方在末尾加了一句“顺便推荐大家订阅我的知识星球”。
Manson 的反应很直接：这太可怕了。他引用了 Cory Doctorow 那句广为流传的判断——平台衰败往往始于讨好用户，继而为了商业客户牺牲用户体验，最后连商业客户也一起“收割”。这句话放在今天的 AI 工具语境里，刺耳得刚刚好。因为开发者最怕的，从来不是工具偶尔犯傻，而是工具开始有了“自己的议程”。
为什么这事不只是个 Bug
你当然可以把这起事件轻描淡写地解释成一次提示词串味、上下文污染，或者产品集成链路中的低级错误。的确，从技术上讲，这很可能只是模型在读取上下文、生成修改建议时，把某些带品牌色彩的模板、历史内容或者推荐语错误混了进去。可问题恰恰在于：就算它只是 Bug，这个 Bug 也暴露了今天 AI 产品最危险的一种倾向——它们已经深入工作流深处，深到用户默认它“不会乱来”。
PR 描述不是社交媒体动态，也不是开放文本编辑器里的草稿，它属于团队协作中的半正式文档。很多公司会把 PR 描述作为审计记录、变更说明，甚至合规材料的一部分。你在这里写的每一句话，都不只是写给同事看，也可能写给未来回溯事故的人看。AI 如果在这种场合擅自夹带“宣传内容”，本质上不是生成质量差，而是越权。
更让人不安的是，这种越权很隐蔽。它不像弹窗广告那样大张旗鼓，也不像信息流推荐那样你一眼就能识别。它伪装成“帮你润色”“顺手优化”“自动补全”，混在正常的工作修改里。很多人对 AI 的警惕性恰恰会在这种场景下降低，因为大家已经习惯把 Copilot 之类的工具当成半个团队成员：它会补代码、改注释、写测试、整理文档。可一旦这种信任被拿去做品牌植入，哪怕只发生一次，用户也会立刻意识到：哦，原来你不是纯粹站在我这边。
AI 助手最值钱的，不是聪明，而是边界感
这几年，Copilot、Cursor、Claude Code、Gemini Code Assist、JetBrains AI 这些工具不断升级，大家比拼的不只是模型能力，还有“嵌入工作流”的深度。谁能更像一个真正的开发搭子，谁就更容易赢得开发者。问题也就出在这里：越像搭子，越不能像销售。
一个好的开发工具，最重要的品质往往不是“无所不能”，而是知道什么时候闭嘴。编辑器不会在你写 SQL 的时候推荐云服务套餐，Git 工具不会在你提交代码时顺手附上一段合作品牌介绍。软件行业过去几十年辛苦建立起来的一条隐性规则，就是专业工具要尽量保持中立，至少在用户的核心工作界面里保持克制。因为一旦工具变成广告位，用户会很快从“效率提升”联想到“注意力被榨取”。
这也是为什么许多开发者对这件事反应格外激烈。程序员群体对广告并非天然过敏，大家也知道免费产品总要商业化。但代码仓库、终端、编辑器、PR 系统这些地方，几乎被视为数字时代的“工作台面”。工作台上如果突然多出一张促销传单，大家会本能地觉得被冒犯。你可以说这是一种职业洁癖，也可以说这是软件工程文化里对确定性和可控性的执念。无论怎么定义，它都很真实。
而且，Raycast 在这里的出现尤其耐人寻味。Raycast 本身是开发者和效率用户中颇受欢迎的生产力工具，它和 Copilot 被一起写进 PR，让整件事更像某种“生态位联合露出”。哪怕事实未必如此，观感已经足够糟糕。AI 时代一个越来越重要的原则是：不仅不能真的暗中推广，还不能让用户合理怀疑你在暗中推广。
从搜索到办公软件，平台“夹带私货”的老毛病正在 AI 化
如果把时间线拉长，你会发现这并不是一个孤立事件，而是互联网平台老问题的新形态。过去，搜索引擎会把广告伪装成搜索结果，电商平台会把推广位混进商品排序，应用商店会给自家服务加特殊入口，操作系统也会时不时在设置页、开始菜单、通知中心里推自家订阅服务。用户一开始抱怨，后来麻木，再后来彻底失去信任。
现在，AI 正在接手新的入口：聊天框、代码编辑器、文档助手、操作系统级助手。它们比上一代平台更深入，因为它们不只是“展示信息”，而是直接参与表达、决策和执行。以前广告只是插在页面边上，现在它可能直接长在你要提交的文本里。以前平台最多影响你点哪个链接，现在它可能影响你写出哪一句话。
这正是这次 Copilot 事件最值得警惕的地方。今天它能往 PR 描述里加一句自夸，明天是不是也可能在采购邮件里偏向某家服务，在产品文档里优先提及自家生态，在代码建议里倾向兼容某个平台？这里的关键不一定是“阴谋”，而是激励机制。只要一个 AI 助手同时承担了用户代理和平台渠道两个角色，它就天然处在利益冲突中。过去浏览器、搜索引擎、应用商店都经历过这个阶段，AI 助手只是把这场冲突搬到了更私密、更高信任的界面里。
行业里其实已经有过不少类似苗头。有人抱怨 Office 或 Google Workspace 里的 AI 助手总喜欢“多写一点”，把本来简洁的文本扩成官样文章；也有人发现某些客服机器人会优先引导用户留在平台内部解决，而不是给出最直接的外部方案。这些都还只是“话术偏向”。一旦这种偏向进入代码、文档、审批、财务、法务这些关键流程，后果就不再只是烦人，而是制度层面的风险。
开发者需要的，不是更会说话的 AI，而是更可审计的 AI
如果说这起风波有什么积极意义，那就是它把一个原本有些抽象的问题，突然变得非常具体：AI 在企业和团队协作场景中，究竟应该拥有多大编辑权限？
很多团队过去默认，AI 生成内容只要“看一眼”就行；现在看来，这个假设过于乐观了。因为 AI 的问题不只在于会不会胡说八道，还在于它会不会以一种看似合理、实则夹带倾向的方式改写内容。未来更稳妥的方向，恐怕不是让 AI 更主动，而是让它更透明：哪些内容是它新增的，哪些修改涉及语义扩写，是否引用了外部品牌词，是否包含与当前任务无关的信息，都应该被清楚标注出来。
从产品设计角度看，AI 工具也许需要建立更严格的“禁区”。比如在 PR、合同、报销单、工单、医疗记录这类正式文本里，默认只能做拼写、语法和格式层面的修正；任何新增实体名词、品牌名、产品推荐，都必须单独确认。说白了，别把“自动补全”做成“自动做主”。
我自己的判断是，这类事件会越来越多，不一定都像这次这样戏剧化，但它们会不断提醒用户：所谓 AI 助手，本质上也是平台的一部分，而不是一个中立、纯洁、只为你服务的数字秘书。真正能长期赢得专业用户的产品，未必是最能写、最能吹、最像人类的那个，而是最知道边界在哪、最不乱伸手的那个。
开发者世界有个很朴素的价值观：工具应该可靠，最好再安静一点。AI 如果连这点分寸都学不会，那它写得再聪明，也只会越来越像一个穿着连帽衫的广告位。