使用人工智能（AI）辅助开发带来了双重影响：它能让简单的编码任务变得更简单，但同时也可能让真正困难的开发工作变得更难。过度依赖 AI 生成代码会损害代码质量和工程师的责任感，因为开发者可能并未真正理解其工作内容。不切实际的生产力期望还会导致团队倦怠。因此，应将 AI 视为一个“技能高超但经验不足”的初级开发者，其产出必须经过严格审查。最终，开发者必须对所有代码负责，明智地利用 AI 辅助解决复杂的调查和分析问题，而不是盲目地将其作为编码的替代品。
“AI 帮我做的”是一个危险信号
过去，开发者通过搜索信息、阅读文档和分析他人经验来解决问题。这是一个主动研究和验证的过程，没有人会说“是谷歌帮我写的代码”。
现在，“AI 帮我做的” 这种说法开始出现。这要么是夸大其词，要么意味着开发者没有经过自己的思考和判断就接受了结果。两种情况都很糟糕。如果你团队的成员复制粘贴了 AI 生成的代码，你必须问一个核心问题：
- 你真的理解你粘贴的这些代码是做什么的吗？
“感觉式编程”有其上限
在原型设计或低风险的个人项目中，凭感觉快速编程很有趣。但当项目涉及真实的用户和后果时，每一行代码都很重要。AI 可能会在没有充分理解上下文的情况下做出破坏性修改，比如无故删除大量代码。
AI 辅助有时花费的时间比节省的还要多。与 AI 争论和修复它造成的错误，可能比自己从头开始编写代码更耗时。
一个常被忽略的步骤是，将 AI 用作 调查工具，而不是直接的解决方案提供者。利用 AI 辅助调查是一项需要练习的技能，关键在于学会判断 AI 何时会出错。
难的部分变得更难
编程工作中，写代码 通常是比较简单的部分。真正的难点在于：
- 调查问题
- 理解上下文
- 验证假设
- 选择正确的解决方案
当你把简单的编码工作交给 AI，你剩下的就只有这些困难的工作。如果你因为 AI 直接给了答案而跳过了调查阶段，你就失去了评估这个答案是否正确所需的上下文。
阅读和理解别人的代码远比自己写代码要难。AI 生成的代码就是别人的代码。我们把开发者擅长的部分（编写）交给了机器，却给自己留下了更难的部分（阅读和审查），并且还缺乏了自己动手编写过程中本应建立的背景知识。
不切实际的期望与倦怠
管理层很容易陷入一个误区：一旦团队在 AI 的帮助下快速交付了一次，这个速度就成了新的标准。这种持续的压力会导致恶性循环：
- 管理层施压，要求保持冲刺速度。
- 疲惫的工程师 开始忽略边界情况、跳过测试、发布有缺陷的代码。
- 线上事故增多，导致团队需要花更多时间救火。
- 压力进一步加大，倦怠加剧。
有人声称 AI 让他们效率提升了 10 倍，但这可能只是把一个 0.1 倍效率的工程师变成了 1 倍效率的工程师。这究竟是生产力的提升，还是暴露了他们之前根本没有做足调查工作？
倦怠和低质量的代码会吞噬 AI 带来的任何生产力收益。你无法通过优化流程来解决因人员过度疲劳而无法清晰思考的问题。
高级技能，初级信任
我们可以用一个简单的原则来理解如何与 AI 协作：“高级技能，初级信任”。
- 高级技能: AI 像一个经验丰富的工程师，拥有强大的编码能力。
- 初级信任: 我们必须像对待一个初级工程师的产出一样审查它的代码。代码可能看起来不错，甚至能运行，但因为它缺乏对项目背景和历史决策的理解，所以需要格外仔细地检查。
AI 就像一个刚走进办公室、一无所知的聪明人。它可以帮助调查，但它没有参加上周的关键会议，不了解那些不成文的规则和背景。
最终所有权仍然属于开发者
开发者需要为他们提交的每一行代码负起责任，无论这些代码是自己写的还是 AI 生成的。当半年后新同事试图理解这段代码时，或者当它在凌晨两点引发故障时，“这是 AI 写的”并不能成为借口。
正确的做法是让 AI 帮助处理困难的部分。例如，在调查一个复杂的生产环境缺陷时，开发者可以向 AI 提供复现步骤、相关代码变更等上下文信息，让 AI 辅助进行根本原因分析。AI 负责繁琐的调查工作，开发者负责提供背景知识和验证结论。这才是真正能让困难工作变轻松的协作方式。