最近和身边程序员朋友聊天，发现大家对 AI 编程的态度特别分裂：有人觉得是 “生产力神器”，有人用了两次就放弃，吐槽 “生成的代码全是坑”。 现在AI编程是大势所趋，而且不少大模型厂商还在把很大投入放在这个赛道上，未来模型的表现肯定会更好。 很难说这是一件好事还是坏事，但是作为时代的一粒沙，我们能做的就是极力去适应它。
面相AI开发的主要挑战
正确率不高，最终导致效率提升不明显
一个功能要反复让 AI 改，甚至越改越乱，不仅没省时间，还特别打击信心。
长期项目可维护性差，项目逐渐失控
短期看 AI 写代码快，但长期项目很容易 “失控”—— 毕竟最后对项目负责的是我们自己，不能让 AI 写的 “零散代码” 毁了整个项目的结构。
面相AI的开发方式
摆正心态，AI开发优先
我自己是从小就会编程的人，我享受编码的感觉。但是AI编程正在剥夺我的一部分快乐。然而AI编程是大势所趋，必须从强迫自己从心底尽快接受这样的转变 所有开发任务都要优先考虑如何用AI来实现，只有这样我们才能尽快适应使用AI开发的方式
提高正确率
要提高生产的正确率要从两个方向入手：提供足够的上下文和增加生成约束
提供上下文
AI 不是你肚子里的蛔虫，你不给它足够的信息，它就只能 “瞎写”。
- 建立上下文文档库，我一般的习惯是在项目中创建一个context文件夹，项目各种上下文信息（包括需求，设计文档和开发规范）都以md文件的形式放在那里，方便未来随时引用
- 尽量选择比较主流的框架/库。大模型更熟悉主流的框架/库
- 总结项目的规范和最佳实践。可以让AI来整理，自己再补充
- 一些库已经支持了llm.txt，这里点名表扬vue
- 使用工具来给大模型检索文档，比如Context7
增加生成约束
光给信息还不够，还要给 AI 定 “规则”，避免它写出来的代码不符合预期。
- 写测试用例：（当然是让 AI 写，但你要 Review和补充），现在的AI编程工具都比较Agent化了，有了测试用例，你就可以让它形成闭环，跑通测试用例后再来向你报告。另外有了测试用例，未来重构也更有底气了。
- 约束方案关键设计：要么在提需求时直接提供API设计/数据结构的设计，要么让AI分步来做，先给出实现方案及执行计划，再来执行功能开发。
确保项目长期可维护
设计清晰且可扩展的开发框架
一般我开发新项目都要花上一些时间来实现好项目的框架，这包含了主要用哪些库、开发，测试，部署工作流、代码文件结构等。要让开发新业务功能变成一个照葫芦画瓢的过程，而AI特别擅长照葫芦画瓢。 开发框架应该易于重构，强化模块边界，重点Review模块间的接口设计。
Review所有AI生成的代码
过去我其实是挺烦Review代码的，但是不知道为什么，我对Review AI生成的代码接受度还蛮高的。可能Review人写的代码，我内心觉得是一个额外的功能。而Review AI生成的代码则是它帮我节省了很多时间，我需要花一些时间来检查它的工作。 另外Code Review还有助于我发现项目上下文中的不足，我会根据Review的情况来补充调整上下文。
结语
其实 AI 编程没有 “标准答案”，而随着时间的推移、工具的成熟最佳实践也在变迁中。我自己的感受在Claude Sonnet 4出来之后，AI生成代码的基本能力有了明显的提升，准确率有了很大的进步。而Coding Agent的出现则又把AI编程的体验提升了一个档次。
