用AI写代码的一次实践

近期想用开源组件Activiti编写一个工作流的例子，功能比较简单，先提前准备一个BPMN规范的XML文件，里面就三个节点：开始节点、用户任务节点、结束节点。编写两个方法，一个是加载XML文件里的节点启动工作流，另外一个是用户手工完成任务后调用的方法触发工作流完成。这种比较独立的功能，正好使用AI工具来编写，使用的是字节发布的Trae工具。

写了一个Markdown文档，先描述环境，用什么编译工具、什么JDK版本等，再列一些规范，比如在哪些目录放置哪些文件、哪些文件修改前要确认之类的，最后把上面的需求列出3个功能。

发命令给Trae，让它仔细阅读Markdown文档，按上面的要求生成代码。这次生成的代码编译不通过，提示一个TaskService不存在，这是工作流里面初始化的一个任务服务。Trae为了解决这个问题，不停变换解决方案，尝试打印更多的日志，通过日志判断错误原因，再规划下一步。但折腾了一个多小时，也没有解决这个问题，一直卡在了这个问题上，但代码已经复杂得没法看了。

这次用 Trae 生成代码不算成功，就用手工的方式先把代码改对，看看正确版本应该是怎样的。从感觉上，和Trae第一版生成的代码相差的并不多，差几行代码的样子。根据这个经验修改了Markdown文档，在里面增加了一些内容。比如规范上增加要使用BPMN2.0规范，不要使用1.0规范，这样可以规避XML文件的部署问题。比如增加一个需求，对Activiti组件进行初始化，避免出现TaskService不存在的问题。

再用Trae去生成代码的时候，上面那两个重点问题仍没有解决。即使规范里面有说明需要用BPMN 2.0的规范和对Activiti组件进行初始化的要求，但它执行起来好像没有看到这些信息似的。这两个问题会导致它会有各种复杂的操作，比如降低依赖包的版本、对XML文件里面的内容调来调去、在代码里面加上各种各样的调试语句和日志等，使得代码从第一版的十来行变成了几百行。定位问题的时候并没有找到关键点，所以一直在尝试却一直解决不了这个问题。如果过这个过程不阻止它，那么它会把整个代码都改得面目全非，根本就没法看了，这种代码后面也没有办法进行维护。

想了想自己是怎么解决这些问题的，一个关键步骤是查了官方文档才解决的，所以在出现这些问题，尝试了两三次之后解决不了的时候，就停止它正在规划的操作，提示它参考官方帮助文档进行修改。这样的方式能让它往正确的方向走一步，更好的方式就是直接指出问题所在，比如上面BPMN规范的问题，让加上2.0版本相关的前缀，这个问题就很快解决了。同样对 Activiti 初始化的问题，告诉它那个TaskService应该从工作流实例里面取出来，有了这个提示也能够很快解决问题。

感觉现在这种开发工具已经具备一定的程序员思维，当遇到问题的时候，就会根据问题提示的信息规划方案进行尝试，一个方案不行就尝试另外一个。但还缺乏一个思维，就是当发现这个方法不靠谱的时候，要能及时终止，思考这些问题的可能原因，从积累的经验重新开始。而不是一直往错误的方向走，反而离正确的方案越来越远。