夜雨聆风之前用 AI 工具写代码的时候，都写一个很详细的 spec，让 AI 工具严格按照 spec 来实现，有的时候 spec 很难描述清楚，就让 AI 工具先输出设计，然后再人工整理成完整的 spec。这种方式，AI 工具输出的代码质量还算是比较高的，需要调整的地方少了不少。但缺点就是编写 spec 设计比较费时间，就有点像指导小孩一样，需要手把手地教，一轮下来，人好像没有轻松多少，AI 工具也就是在写代码那个小环节比较高效。总体下来，感觉效率确实有些提升，但也不是很惊艳。
这次开发报表功能，就试验一下轻松一点的方式。那就是不写详细的 spec，而是把报表比较粗的规则写到 spec 里。不过有一点不同的地方就是，对编写有要求的地方，都会给一个参考例子。比如操作某个对象，如果不说明，AI 工具大概率会自己实现一个，这就不是期望看到的，所以就加上一个方法的路径，让 AI 工具参考里面的实现来操作对象。有些操作是比较复杂的，以前要说明这种操作，需要人工先把这些操作了解清楚，然后再把例子摘录出来，放到 spec 里要求 AI 工具参考。这个步骤就比较耗费时间，特别遇到一些耦合比较多的地方，要把例子看懂就不太容易，再要把它们摘录出来就更加困难了。之前这样做还有个原因，就是希望 spec 是一个比较完整的设计，不但是对 AI 工具的要求，也是希望维护的人能够看得懂。但实践下来，这个主要是有完美主义思想在作怪，这个 spec 后面基本也是没有什么用了的，因为相关的要求要么用代码、要么用注释的方式体现到了代码中了，而且后面的改动很可能会漏掉更新 spec，还是会回到维护文档的老问题上，还不如代码即文档，代码就是最新的文档。
用这种比较粗放的方式，反而更能发挥 AI 工具的一些“智能”。AI 工具能够很好地去参考所给的例子代码，虽然有些代码人工看起来比较复杂和耗费时间，但对 AI 工具来说，这反而是一件比较简单的事情。所以这块如果之前花的时间过多，反而是提升效率相对更加明显的地方。如果放到一个老系统，这个优势可能更加明显，比如一个功能的一些操作在老系统中根本不知道哪里有例子，那就直接让 AI 工具分析整个系统的代码，参考里面比较好的相关操作方式，做一份设计出来，通过确认就可以了解到哪里有相关的操作，看看 AI 工具选择的是否有问题。
当然，这个方式也不是完美的，AI 工具写出来的代码还是有运气成分在里面，有的时候一次性就搞定了，但也有不少时候代码是比较啰嗦或者用比较复杂的方式来生成的。由于之前提的要求是比较粗放的，当对细节有比较多要求的时候，可能后面就需要花不少时间来对细节进行校正。好处是范围缩小了，比较容易说清楚，调整起来也不难。缺点是总体的时间好像也没有少多少。需要摸索一些工程化的方式，让这些细节的要求能够让 AI 工具自动就遵守。
