Loading... # 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 生成的代码是别人的代码。因此，拿走了开发者擅长的部分（编写），交给机器处理，留下的却是更困难的部分（阅读和审查），但缺乏通过自己编写代码通常会建立的上下文。 ```mermaid 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 带来的任何生产力收益。无法通过优化来解决人们过于疲惫而无法清晰思考的问题。 ```mermaid graph TD A[AI辅助提高速度] --> B[管理层看到快速交付] B --> C[设定为新基准] C --> D[持续冲刺压力] D --> E[工程师疲惫] E --> F[遗漏边缘情况] F --> G[更多bug] G --> H[更多压力] H --> D ```  ## 4. 高级技能与初级信任 ### 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 帮助处理困难部分的方式。 ```mermaid 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。 ```mermaid 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 Developers](https://www.blundergoat.com/articles/ai-makes-the-easy-part-easier-and-the-hard-part-harder) ## 2. 相关主题 - AI 工作流 - 开发者体验 - 工程团队管理 *** ## 参考资料 1. [AI Makes the Easy Part Easier and the Hard Part Harder for Developers - BlunderGOAT](https://www.blundergoat.com/articles/ai-makes-the-easy-part-easier-and-the-hard-part-harder) 最后修改：2026 年 02 月 09 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏