北京
一项追踪顶级编程模型推荐行为的内部测试，暴露了一个被大多数开发者忽略的现象。同样的需求场景，向不同模型发出相同的请求，返回的第三方工具建议可以天差地别；即便同一个模型，在不同时刻询问，结果也可能摇摆不定。这个发现让很多习惯把“调研”外包给AI的程序员，开始重新审视自己项目中依赖决策的真正来源。
参与测试的作者反复用同一套提示词去问ChatGPT、Claude、Gemini等主流编程代理，覆盖的应用数据库、托管平台、特性实验工具等常见类别。他发现，模型经常会给出一个看似周全的方案，语气笃定，附带一份行文整洁的Markdown实施计划。开发者往往扫一眼，觉得“看起来挺合理”，就点了头，代理随即开始写代码。但那份笃定背后，并不一定是技术社区公认的最优选。
这种心态的变化，其实只有短短两三年。以前，在团队里考虑引入一个外部依赖，流程要冗长得多。开发者会先进行网页搜索，在聊天群里请教同行，列出候选方案，挨个审查其维护状况、开源许可证、社区活跃度。随后，一份申请评议文档可能出现，或者至少有一位资深同事凭直觉给出“不过关”的评价。那时的依赖选择，多双眼睛看过，决策要慢上好几个量级。
如今，情况被完全颠倒。即使AI代理已经分担了大部分编码工作，仍有团队保留着那套重研究的流程，但主流工具本身并不鼓励这么做。事实上的通行做法，就是文章开头描述的那个特性标记故事：问一句代理，拿到推荐，立刻开工。整个依赖决策，就这样被悄然“让渡”了出去。
这并非全无道理。既然你相信代理能规划并编写出整个应用的代码，那么信任它在附属选项上的判断，似乎也顺理成章。何况，工程师仍然可以事后审查代理给出的代码，并提出替代方案。只不过，越来越多的开发者对代码的审查，也降级为对实施文档的粗略一扫——那种程度的扫描，和当初看推荐方案时的“挺合理”没啥两样。
在最近的AI工程师世界博览会上，甚至有好几场演讲要么直接宣告“代码审查已死”，要么扬言要彻底消灭它。当人类审查成了瓶颈，工程师们自然转向可以信赖的自动化审查方案。正如大会主题演讲中埃里克·梅耶尔可能暗示的那样，多数组织最终需要的是一种极为稳健的证明方式，也许是接近数学证明级别的可靠性。只是在那一天到来之前，依赖项正在代码库之外悄悄生长出审查流程根本无法完整覆盖的生命轨迹。
作者的研究仍在持续，所有测试结果都已经在llmran公开。每一轮追踪都在提醒人们：当你下一次对AI代理抛出一个“帮我加上这个功能”的指令时，那个带着十足信心蹦出来的推荐名，可能只是模型训练数据里的“心头好”，而非经过多方权衡的集体智慧。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
