最新

最近，我的雇主一直在大力推动在工程团队中采用大型语言模型（LLM），期望能够提高生产力。工程团队也随之而动，因此我收到了很多明显是由人工智能生成的拉取请求（PR）。这些请求的差异有时达到100行，而实际上可能只需要10行，遗漏了错误案例，违反了约定。这不仅仅是初级工程师的情况，现在常常也出现在其他高级工程师身上。 在我们的激励结构下，似乎没有好的方法来防止质量的下降。我很难量化“粗糙代码”为什么是坏事，但我的直觉是： 1. 代码库对人类工程师变得难以阅读。 2. 代码库中更多的糟糕示例会为未来的LLM变更创造一个负反馈循环。也许这已经成为新常态，但—— 3. 一旦有足够的糟糕代码进入，未来的事件/严重故障（SEVs）将变得越来越难以解决。 （3）似乎是唯一一个对业务有实际影响的原因。即使真的发生了，我也不知道是否能将响应缓慢/收入损失与AI生成的糟糕代码联系起来。 我看到其他帖子对“随意编码”的弊端表示遗憾，但在LLM时代，有没有具体的方法来证明代码质量的重要性？我认为，跟踪一些代码质量指标，比如圈复杂度，可能会有助于观察与回归之间的相关性，但这似乎有些薄弱（而且是事后诸葛）。

我想分享一些关于人工智能编码助手的想法，这些想法困扰了我一段时间，我认为“一个拿着信用卡的孩子”的比喻恰如其分地捕捉到了某些人所称的“氛围编码”的危险。至少在我们拥有真正的通用人工智能之前，这似乎是一个严重的问题。 在过去一年里，我密集使用Cursor，惊讶于它的速度之快。它可以在几秒钟内搭建整个功能、连接组件并编写复杂的逻辑。这样的感觉就像是驾驶手动挡和自动挡汽车之间的区别。或者更准确地说，就像是阅读详细文档与观看总结视频之间的区别。 这让我回想起我在2023年首次使用GitHub Copilot的时光。当时，它主要用于自动补全方法和提供上下文建议。那种程度的帮助感觉刚刚好。对于更复杂的问题，我会有意识地切换上下文，向像ChatGPT这样的网络AI提问。我仍然是驾驶者。 但像Cursor这样的工具彻底改变了这种动态。它们如此主动，以至于我逐渐失去了深入思考业务逻辑的习惯。这并不是说我失去了思考的能力，而是我正在失去这种根深蒂固的、潜意识的行为。我不再被迫将整个架构牢记于心。 这导致我对项目的归属感逐渐减弱。工作流程变成了： 告诉AI写一个函数。 调试并测试它。 告诉AI写下一个与之连接的函数。 反复进行。虽然速度很快，但我最终得到的是一系列我促使其存在的黑箱。我的角色从“我知道我在构建什么”转变为“我知道我想要什么”。这之间有一个微妙但至关重要的区别。我正在变成一个指导AI实习生的项目经理，而不是一个打造解决方案的工程师。 这对个人开发者和项目的长期健康都是有害的。如果团队中的每个人都采用这种工作流程，那么谁真正理解全局呢？ 这里有一个具体的例子，完美地说明了我的观点：编写git提交信息。 每次提交时，我都有一个个人规则：审查所有更改的文件，并用我自己的话写提交信息。这迫使我综合这些更改，并巩固我对项目在特定时间点状态的理解。这保持了我对项目的控制感。 如果让我让AI从差异中自动生成提交信息，我可能会节省几分钟。但一个月后回头看，我对那个提交将没有真正的记忆或上下文。它只会是一个在技术上准确但没有灵魂的日志条目。 我担心，通过优化短期速度，我们正在牺牲长期的理解和控制。 还有其他人感受到这种紧张吗？你们是如何在这些工具的强大功能与保持对自己代码库的掌控之间取得平衡的？