AI 让简单部分更简单，困难部分更困难
AI 让简单部分更简单，困难部分更困难一、新闻概述1. 标题AI 让简单部分更简单，困难部分更困难：对开发工作流的影响分析2. 发布时间2026 年 1 月 31 日3. 来源BlunderGOAT 技术博客（Matthew Hansen）二、核心内容1. 事件摘要A. 主要内容本文探讨 AI 在软件开发中的实际影响，指出虽然 AI 让代码编写变得更容易，但也让开发工作中更困难的部分变得更加困难。B. 核心观点写代码是开发工作中简单的部分困难的部分是调研、理解上下文、验证假设和知道为什么某个方案适合当前情况AI 可以帮忙编写代码，但不能替代开发者建立必要的上下文理解过度依赖 AI 可能导致代码质量下降和团队倦怠2. 关键信息A. 文章类型技术观察与开发实践反思B. 核心论点当开发者把简单的部分交给 AI 后，留下的工作会更困难。如果没有进行充分的调研就接受 AI 的答案，就没有足够的上下文来评估它给出的内容。C. 涉及主题AI 辅助开发、开发者体验、工程团队管理、代码质量三、详细报道1. AI 替代开发的误区A. 从 Google 到 AI 的转变开发者过去会通过 Google 搜索解决问题。阅读 StackOverflow 答案、技术文章或 GitHub issue，进行调研，结合自己的上下文进行验证，然后得出自己的结论。没有人会说 Google 帮他们写了代码，也不会说搜索结果排名第一就一定是正确的。B. AI 为我写的现在开始听到 AI 为我做了这个的说法。这要么是对发生事情的过度宣传，要么意味着开发者没有得出自己的结论。这两种情况都是问题。如果团队成员真的因为复制了 StackOverflow 答案就说 Google 写了他们的代码，会担心同样的问题：是否真正理解粘贴的内容？C. 氛围编码的局限氛围编码很有趣，起初确实如此。对于原型制作或低风险的个人项目，它很有用。但当风险真实存在时，每一行代码都有后果。在一个个人项目中，要求 AI 代理向特定文件添加测试。请求前文件有 500 行，请求后只剩下 100 行。询问为什么删除了其他内容，AI 说没有删除，然后又说文件之前不存在。展示 git 历史记录后，AI 道歉，表示应该先检查文件是否存在。想象这种情况发生在医疗保健代码库而不是副业项目中。AI 辅助可能比节省的时间花费更多时间。这听起来很反直觉，但确实发生了。在这个案例中，与 AI 代理争论并恢复文件花费的时间比自己编写测试还要长。2. 困难部分变得更困难A. 开发的本质大多数人忽略了 AI 辅助开发的这一点。编写代码是工作中简单的部分，一直都是。困难的部分是调研、理解上下文、验证假设，以及知道为什么特定方法适合当前情况。当把简单的部分交给 AI，留下的工作并不会减少。剩下的全是困难的工作。如果因为 AI 已经给出答案而跳过了调研，就没有足够的上下文来评估它提供的内容。B. 阅读与编写代码阅读和理解别人的代码比编写代码困难得多。AI 生成的代码是别人的代码。因此，拿走了开发者擅长的部分（编写），交给机器处理，留下的却是更困难的部分（阅读和审查），但缺乏通过自己编写代码通常会建立的上下文。graph LR A[传统开发流程] --> B[编写代码] B --> C[建立上下文理解] C --> D[验证代码] D --> E[完成功能] F[AI辅助开发流程] --> G[AI生成代码] G --> H[缺乏上下文] H --> I[审查困难] I --> J[风险增加]3. 速度期望与倦怠A. 冲刺陷阱朋友的论坛讨论提出了一个不断回到的观点：如果冲刺交付某样东西，期望就会变成永远保持冲刺。总是。疲惫的工程师会遗漏边缘情况、跳过测试、发布 bug。更多事故、更多压力、更多冲刺。这会自我强化。B. 管理问题这是一个管理问题，而不是工程问题。当领导层看到团队快速交付一次（可能借助 AI，也可能没有），这就会成为新的基准。对话从他们如何做到的转变为为什么不能每次都这样。C. 10 倍效率的真相当人们声称 AI 让他们的效率提高 10 倍时，也许是把他们从 0.1 倍效率的工程师变成了 1 倍。所以从技术上讲，确实提高了 10 倍。问题在于这是生产力提升还是暴露了之前有多少调研工作没有做。倦怠和发布劣质代码会吞噬 AI 带来的任何生产力收益。无法通过优化来解决人们过于疲惫而无法清晰思考的问题。graph TD A[AI辅助提高速度] --> B[管理层看到快速交付] B --> C[设定为新基准] C --> D[持续冲刺压力] D --> E[工程师疲惫] E --> F[遗漏边缘情况] F --> G[更多bug] G --> H[更多压力] H --> D4. 高级技能与初级信任A. AI 的特点使用高级技能、初级信任这个短语来解释 AI 编码代理的实际工作方式。它们在编写代码方面高度熟练，但我们必须像对待初级工程师一样信任它们的输出。代码看起来很好，可能也能工作，但应该更仔细地检查，因为它们缺乏经验。B. 缺乏上下文换个角度看：AI 编码代理就像一个阅读速度非常快的聪明人，刚从街上走进来。可以帮助调研，也可以写一些代码，但没有参加上周讨论重要背景和上下文的会议。5. 所有权依然重要A. 代码责任开发者需要对发布的每一行代码承担责任。不仅仅是自己编写的行，还包括 AI 生成的行。B. 长期影响如果因为有人设定了不切实际的速度目标而剪切粘贴 AI 输出，6 个月后当新团队成员试图理解代码在做什么时，就会遇到问题。或者在凌晨 2 点代码崩溃时，AI 写的这句话在任何情况下都帮不上忙。6. AI 如何让困难部分变得更容易A. 正确使用 AI有一天出现了生产 bug。用户在重大发布后几小时向服务团队发送了询问。存在边缘情况时区显示 bug。进行更改的开发人员在必须离开去上课前有 30 分钟，而时间已经晚到我已经在家。使用 AI 帮助调研，告诉它 bug 一定基于最近的更改，并解释如何重现。原来一些弃用的方法优先于当前支持时区的方法，所以时区从未正确转换。在 15 分钟内，找到了根本原因、解决方案的想法以及 GitHub issue 中的调研笔记。开发人员确认了修复，其他人测试并部署，然后下楼去拿 DoorDash 晚餐。B. 无压力的修复没有紧急演练，没有加班。AI 完成了调研的繁重工作，提供了上下文并验证，开发人员确认了解决方案。这就是 AI 帮助处理困难部分的方式。sequenceDiagram participant D as 开发者 participant AI as AI助手 participant GH as GitHub Issue participant T as 测试人员 D->>AI: 描述bug和上下文 AI->>AI: 代码调研分析 AI-->>D: 根本原因和解决方案 D->>GH: 记录调研笔记 D->>T: 提交修复方案 T->>T: 测试验证 T->>D: 部署上线四、影响分析1. 对开发实践的影响A. 调研技能的价值AI 辅助调研是一项被低估的技能，并不容易，需要练习才能知道 AI 什么时候是错的。使用 AI 生成的代码可能有效，但如果把更多简单的代码编写任务交给 AI，可能会陷入 AI 辅助成本高于节省时间的陷阱。B. 上下文理解的重要性作为调研工具使用 AI，而不是直接跳到 AI 作为解决方案提供者，这是有些人跳过的步骤。如果不先进行调研就接受 AI 的答案，就无法评估它提供的内容质量。2. 对团队管理的影响A. 生产力指标的陷阱管理层看到 AI 带来的速度提升后，往往会将其设定为新常态，导致持续的压力和倦怠循环。B. 质量与速度的平衡过度追求速度会导致代码质量下降，最终产生更多技术债务和返工成本。3. 技术趋势A. AI 作为工具而非替代AI 应该是开发者的辅助工具，而不是替代开发者思考和调研的捷径。B. 新的技能要求开发者需要学会如何有效地与 AI 协作，包括提供正确的上下文、验证 AI 的输出、以及知道何时使用 AI。graph LR subgraph 有效使用AI A[提供清晰上下文] --> B[验证输出结果] B --> C[理解解决方案] C --> D[承担责任] end subgraph 错误使用AI E[接受AI答案] --> F[跳过调研过程] F --> G[缺乏上下文理解] G --> H[质量风险增加] end五、各方反应1. 核心观点A. AI 的角色定位AI 是高级技能、初级信任。在编写代码方面非常熟练，但需要像审查初级工程师的代码一样审查其输出。B. 开发者的责任无论代码来源如何，开发者都需要对发布的每一行代码负责。2. 最佳实践建议A. 将 AI 用于调研而非直接生成使用 AI 帮助理解问题、探索解决方案，而不是直接剪切粘贴代码。B. 保持上下文理解即使使用 AI 生成代码，也要确保自己理解代码的工作原理和为什么这样写。C. 避免氛围编码对于原型和个人项目可以使用 AI 快速迭代，但对于生产代码需要更加谨慎。六、相关链接1. 原文链接AI Makes the Easy Part Easier and the Hard Part Harder for Developers2. 相关主题AI 工作流开发者体验工程团队管理参考资料AI Makes the Easy Part Easier and the Hard Part Harder for Developers - BlunderGOAT