AI编程很火，但是真的好用吗？我一直在思考，就我的实际体验来说，在小项目，或者一次性项目里氛围编程确实好用，但是，在稍大一点的项目，以及实际可能进入生产环境的项目，目前来说还有几个大的问题没有觉解。
- agent编程
- 效率翻倍的提高？ 对我来说从某个角度而言编程语言其实也是一种语言，编程其实很大程度上，和你用一门语言来写作或者表达某件事物是一样的，编程语言里的关键字可以看作语言的单词，语法就是语言的语法，所以直接用写代码来表达你的想法，和写好文档在发给AI来写代码，对稍懂编码的人来说其实是额外的负担，本来的流程是，根据需求写代码，加上AI后则是，根据需求，细化需求，查看AI的代码，提出修改，检查代码，整体上并没有很大的提升，而且代码的品味和偏好也是一个问题。 所以至少目前来说，agent 编程并不能完全带来质的提升。
实践
分享一些我使用fastapi开发经验和环境配置
使用chat bot部分
个人认为这部是开发过程中的上层代码设计，即决定做什么
需求
通过和gemini 讨论需求，并思考是否能实现想要的功能，并反复讨论确定需求，最终可以生成一份需求文档，检查并确认。需要深度网上查询可以使用grok或者chatgpt的深度研究。
概要设计
在需求讨论结束后，根据需求确定使用的技术，让gemini编写使用的技术栈和技术路线，方便用于下一步的编码agent开发指导。
核心功能验证
根据需求，设计核心功能是否能实现，可以直接让gemini编写代码验证核心功能是否能按预期运行。
ORM设计
web开发可以从实体类开始设计，根据需求文档设计ORM，检查并思考是否能满足需求，并修改。ORM决定CRUD，配合核心功能的验证，两者结合基本上决定了后端的功能实现。在这里基本上可以确定项目能不能实现。
抽象层设计（可选）
如果害怕在agent编码阶段出现模型任意发挥，可以让gemini设计一下抽象层，抽象层决定了因该做什么，从而限制模型的自由发挥，并提供业务流程提示。同时也方便进行用例测试。代价是在初期设计的抽象层很多时候，你并没有完全想清楚，导致后期修改的时候，需要同时修改实现类和抽象类与测试用例。
UI草稿（可选）
根据需求文档生成UI草图验证用户交互或者功能需求能否满足预期。
使用编码agent部分
这部分时我把他看作时开发过程中的怎么做，由ChatBot阶段讨论的结果和设计，实现扩展到一个更大更具体的设计和实现 使用gemini cli 使用gemini cli推荐编写GEMIN.md，可以由前面生成的技术栈来编写，省去每次指定技术和开发方式
CRUD
有了ORM可以让gemini cli生成所有的CRUD，实现持久化层的操作，我的经验是写一范例让gemini cli跟着抄，例如：自己手动的写一个用户登录注册的CRUD流程，和接口的数据验证，让gemini cli跟这个示例的风格生成其他所有的ORM，保证gemin cli生成的风格和实现符合你的预期和习惯。
编写测试用例（可选）
如果有抽象设计，可以通过抽象来编写测试，好处在与使用gemini cli编写代码的时候可以验证已有功能是符合你的业务需求的，例如：正确的参数输入，正确的输出，不会出现太大的偏离，同时给gemini的修改提供了修改方向。没有抽象层设计，可以直接让gemini cli生成测试用例，测试保证gemini cli在后续的修改中修改了原始的代码。不好的地方是，会浪费大量的时间，并且业务的修改需要同步修改测试。
界面开发
我的体验还是分成界面设计，接口对接两个阶段来开发，先确定界面的排版布局没有问题后，能正确路由到界面后再开始接口对接。
如果在ChatBot部分，有草图设计，可以让gemini cli根据草图来生成代码，没有草图代码的话，建议写一个界面设计文档，在文档里面单独为每个界面编写大致的界面设计。例如：登录注册界面因该是什么样的布局，方便后续改崩了可以快速在次修改。对接接口部分可以在gemini cli访问openapi的接口文档获取每个api接口的参数，依次对接。