AI编程tips
AI编程tips
为什么你的AI编程效果总不好？不妨试试这几个办法来优化。
把大块拆成小块
由于AI的上下文长度有限，AI在处理比较大的任务时很可能会因为超过上下文限制而被迫终止。
而且任务过大，AI在细节上就不可能处理很好，例如你跟AI说“帮我开发一个横版飞机大战游戏”，这样的任务只能生成一个很粗糙的版本，后续还要进行大量优化。
把任务拆小，到多小最合适？我觉得在系统用例这个维度就刚刚好。
一个系统用例表示一个完整的功能，可能要改动5-7个类，涉及1-2个聚合，用例开发完了还可以马上进行相应的单元测试。
如果这个用例生成不符合预期，说明AI编程的策略可能还要优化，可以立即开始调整，而不是在更大的范围让AI反复生成，浪费算力和资源。
在开发顺序上，由于用例间有依赖关系，可以让AI先开发二级用例，后开发一级用例，这样一级用例就可以直接复用二级用例的代码。
进行合理的分层Coding
之前我的课程说过，DDD每一层关注点都不一样。
应用服务层、领域层这两层主要承载业务，可以直接用UML时序图交给AI生成。
入口网关、出口网关更多负责协议转换、权限校验、缓存、接口对接、分库分表等偏技术的代码，这就不适合基于时序图生成。
我个人的经验，两个业务层的代码，用时序图来生成，并且基于用例来生成，这时不需要考虑基础设施层怎么实现，甚至可以让AI生成好单测用例，把基础设施层mock掉进行验证。
repository implement代码可以单独生成，这一层逻辑简单都差不多，可以一次性基于表结构生成全部代码。个别复杂SQL单独处理。
出口网关的代码，多数是字段转换，编解码等，用AI生成的意义不大还容易出错，这部分可以使用tab，AI写完了自己再复核一遍。
AI的反应很慢？
比如让AI“生成XXX接口的实现”，首先AI得找到XXX接口在哪里，读一下这个文件里的内容，看有没有必要读更多的内容来决策代码该怎么写，生成代码的时候还要进行一些逻辑决策、代码规范参考等。
如果你没有告诉AI接口在哪个目录下或在哪个jar包内，AI就要花很多时间去扫描代码来找到这个接口。
- 尽可能提供完整的信息，包括整个工程的代码结构说明
- 尽量打开IDE的文件索引功能
- 可以借助MCP来提供更多信息，例如表结构、接口定义等
- 复杂的逻辑决策，可以跟AI说“如果你短时间不能决策，先留一个TODO待我后续完善”
AI生成的代码不符合预期？
大概的原因：
- 是不是提示词中没有写好开发规范
- 是不是有些地方你自己也没有想清楚怎么做
- 是不是提供的信息模棱两可
如果AI不符合预期，特别是在刚接入使用AI时一定会出现的情况，这时需要详细分析原因，尝试做这些事：
- 建立代码规范，写进提示词里
- 把相对通用的实现封装成框架，向业务层提供标准API接口，并告诉AI这些标准接口怎么用，AI也就不用去感知技术细节（例如对缓存的封装）
- 完善详细设计，不要把不确定性留给AI去实现
- 告诉AI：如果不确定的不要随意发挥，请先向我确认
提示词越来越多怎么管理
一个字：拆
按我的习惯，提示词会拆分为这几个部分：
- 全局提示词。包括代码目录结构，全局的编程规范，要求说明等
- 领域层提示词。给出领域层的开发规范和要求
- 仓储层impl提示词。主要说明用什么框架，数据层规范，数据和领域模型如何转化
- 其他根据实际情况增减
因此代码的标准化就非常重要，否则处处都是特例，提示词会膨胀到无法维护
怎样在老代码上继续用AI去迭代开发
这个问题很难说，具体要看这个代码老到什么程度。
老代码多大程度能用上AI，取决于代码的标准化程度有多高、是否有统一的开发框架、架构风格是否有发生改变。
以我的包子铺为例，最开始的两个月开发完第一个版本以后，理论上这些代码都可以算做是“老代码”了，后续都是在这个基础上进行迭代。
例如最早包子铺只支持第三方支付和余额支付，后来新增了支持积分支付。
但是由于我的代码都是标准化的，也一直延续DDD的架构风格，后续不论怎样升级，都可以继续用AI进行迭代。
如果你的代码全是面向过程的，数据模型也都是贫血模型，学完我的课程后希望用DDD+AI在你的代码上进行迭代升级，这恐怕做不到。
但也不用过于悲观，全局做不到，在局部还是可以实现的。例如在客户运营系统里要新增一个“积分商城”，这个新增的部分就可以用上。
老代码怎么用AI编程来重构
如果直接跟老板这么说，我觉得大概率老板会问你：用AI进行重构升级的意义是什么？
老板并不太关心你的代码是不是用AI写的，只在乎你的代码能不能带来业务价值。如果重构以后没有带来增量价值，那就先别重构。
因此重构需要找一个时机，要不就是刚好有业务需求，要不就是确实代码积重难返，已经影响到了业务进一步发展，那就可以开始重构。
关于重构，重点不在于是否用AI，或许局部的代码优化还能做，但诸如代码写在哪个模块更合理？这个模型是否要拆分为两个子模型？这些问题AI回答不了。
所以重构是否成功的关键还是在于负责重构的人，AI只是帮助提效的工具。
我个人觉得，重构代码和写新代码的逻辑是大致一样的，用例分析、子域划分、领域模型、详细设计这些都要有。
只是重构需要多考虑一个兼容性问题：老代码怎么兼容新数据、新代码怎么兼容老数据，以及怎么保证能够平滑升级。这些后续有机会再分享。
写在最后
AI只是助力工具，能带来多大的价值，其实取决于使用者的个人能力：你的架构设计原则，你的编程审美，你对业务的理解... AI的出现并不是降低了对人的要求，相反对人的要求只会越来越高，我们都应当不断努力，跟上时代的步伐。