昨天发布的 inBox 版本中，大概有 90% 的代码由 AI 帮我写 这个比例算是很高了。
很多时候，我更习惯于让 AI 写功能，比如昨天版本中的自动提取第一行为标题的功能，也就是保存笔记时，如果第一行文字较短，少于 20 个字，就会自动截取第一段作为标题，并且要在设置页面增加一个开关，用来控制这个功能的开启与否。
这个功能逻辑很清晰，我描述清楚了逻辑，并告诉了相关的代码位置，然后让 AI 先给我一个方案设计，我看方案没有问题，就让它开始实现。
实现后，倒也不是一次能成，有一些代码导入等问题，我自己看着就修了，这可能也是 Trae 可能要继续优化的地方。
但整体下来，一遍就能把这个功能实现了，后面我自己调试后，会发现一些体验问题，然后会继续让它改，比如说，用户的笔记只有一段，那么就不自动提取，告诉 AI 后，它很快就实现了，这样下来，整个功能开发的很快，到这，都只是常规操作。
后来准备测试图文混排功能时，发现了一个大 bug，图文混排跟原来图文分离以及 Markdown 模式有冲突，主要是图片插入跟图片上传，这块的逻辑称得上是灾难，之前逻辑就复杂，inBox 的图片支持上传到 memos、三方图床、webdav、S3 四个地方，大家平时用的时候大都用一个，但是实现的时候四个都要支持，加上图片的展示可能在笔记中，也可能独立展示，逻辑有点混乱，当时的问题是，编辑之前的图文分离笔记时，如果开启了图文混排的开关，只要保存，图片就丢了。
后来检查后，发现不过解决，改动挺多，对于这个问题可能重构更合适，但之前都是让 AI 写功能，让它重构代码，我是没把握的，抱着试一试的心态，我把自己的困惑，告诉了 AI，让它阅读了之前的逻辑，它开始帮我重构，我看了它的重构方案，还挺靠谱，那就让它来搞吧，实在不行，我就回退。
重构完毕后，挺好，能用，解决了问题，不过后来我还是人工又发现了几个问题，但是整体它采用的设计已经算是高级程序员的水平，并且重构完还提供了重构说明文档以及测试代码，这个应该是 Trae 最近做的优化，之前都不支持。
不过看到它的重构代码，我还是不安，因为自己的项目，不想有自己不理解的代码，自己还是 Review 了一遍，了解了整体思路才继续使用。
\—-
昨天上线图文混排后，因为改动多，所以还是有一些 bug，后面继续优化一下，比如删除笔记时，如果笔记中有图片，本地的图片没有及时删除，以及 memos 图片貌似同步又有问题了。
\—-
一个想法：功能并非越克制越好，只要产品和技术架构合理，功能只需要契合软件定位，多少并不是问题。图文混排的痛点是之前代码设计和产品冗杂有点多，所以后面看让 AI 继续提供一些整体设计方面的思路。