它擅长什么
样板代码与模板：写一个标准的 CRUD 接口、配置文件、数据转换函数，AI 能快速生成，省去查阅文档和敲键盘的时间。
解释与学习：遇到不熟悉的库、框架或代码，让 AI 解释它的工作方式是高效的。
补全与续写：在编写重复性模式的代码时，代码补全能显著减少输入量。
重构与转换：把一个函数改成另一种风格、把同步代码改成异步、补充类型注解。
调试辅助：粘贴错误信息，让 AI 分析可能的原因。
生成测试：为已有代码编写单元测试的初稿。
它不擅长什么
理解完整的业务上下文：AI 看到的是你给它的代码片段，不了解整个系统的架构约束、历史包袱和隐含约定。
判断架构决策：该用什么模式、模块怎么划分、这个改动会影响哪些下游系统——这些需要全局视角和责任承担。
保证正确性：AI 生成的代码可能看起来很对、能编译，但存在逻辑错误、边界处理缺失、或者用了已废弃的 API。
处理非功能性需求：性能、安全、可维护性、合规性，这些往往是代码评审中最重要的部分，恰恰也是 AI 最容易忽略的。
一个关键风险
虚假的完成感。AI 生成的代码通常结构完整、命名规范、注释清晰，看起来像"完成了"。
但这种"看起来对"会让人放松警惕，跳过仔细审查。而恰恰是那些"看起来对但有微妙错误"的代码，最难在评审中被发现。
实际的使用方式
比较务实的做法是把 AI 定位为加速器而非替代者：
- 用它生成初稿，然后自己逐行审查；
- 用它探索不熟悉的领域，但用官方文档验证；
- 用它做重复性工作，把精力留给设计判断；
- 对生成的代码保持默认不信任，尤其是涉及安全、并发、边界条件、错误处理的部分。
效率提升的真实分布
经验上，AI 编程助手的效率提升不均衡：
- 对熟练开发者做熟悉领域的任务，提升有限；
- 对不熟悉的领域、需要频繁查文档的"胶水代码"，提升明显；
- 对复杂的设计问题，几乎无帮助。
一个常被提到的观察：真正的瓶颈往往不是"写代码的速度"，而是弄清楚该写什么——需求澄清、方案设计、沟通协调。AI 目前对这些环节的帮助有限。
一个建议
把 AI 生成的代码当成"同事刚提交的 PR"来评审，而不是"标准答案"。
说明：本文为 AI 辅助开发实践的分析。