起因
昨晚由于帮好朋友请假需要fake一张检查单，检查单包含了大量的中文，我使用cherry studio生成的图片分辨率是默认的1K，经常会出现汉字笔画断联的情况。
之前刷到过相关帖子，nano banana pro的汉字生成会在4k等高分辨率图片上得到改善。于是乎我便钻研起了如何配置cherry studio自定义生成图片。先放效果图。
.png)
曲折的过程
具体的解决方案放在L站了，本文讲一讲没有在L站帖子中写到的曲折过程。以及一些浅浅的思考。
由于我在大学阶段学习过前后端，也曾用过electron和tarui进行应用开发。因此我在定位到发现是cherry studio的软件BUG并提了issue后的第一想法是尝试去修复他然后提交Pull/Request，想成为cherry项目的一个contributor。
当我实际去用F12开发者工具去观察整个请求的发起流程时，我还是被震惊到了，因为cherry聚合了不同厂商（主要是Openai、Anthropic、Gemini）这几种不同的协议规范，同时还聚合了很多复杂的功能，比如MCP、tool use、Web search等等。导致背后的逻辑处理极其复杂，而且为了后续开发的方便，要考虑到对于模块的尽可能复用，以及不同协议之间的解耦和错误处理…
听着就头大，此时我犯了另一个错误，对于web调试来说，应当是clone项目自己在本地运行，观测源代码运行的结果。而我是在构建后的发布版本上进行F12调试，虽然没有复杂的代码混淆，但是定位到编译之后代码的问题无法对应到源代码中的位置。在这里我浪费了很多时间。
此时，我重新点开了我提交的issue，我发现项目成员已经指定给了Copilot去修复这个问题，和我花了接近3个小时分析出来的原因可能差不多。（此时差不多晚上23点半）
.png)
至于最终结果，当我第二天基于源代码修改bug时，Copilot提交的pull/request已经通过了项目成员的review并合并到了主分支。而此时的我还没完全读懂cherry的运行逻辑和整体流程。（此时差不多第二天中午12点）
些许的思考
-
AI时代vibe coding革新了代码创作的方式，但是也引入了更大的不稳定性，很多时候AI创作的代码对于复杂项目的影响是未知的，很多时候存在修复bug的最小解，而Vibe coding则是引入更多的形式，更复杂的逻辑来解决bug。这样的项目看起来欣欣向荣，但往往暗藏危机。
-
开源项目的复杂程度远超想象，上百人的团队，数百个issue并行处理，复杂的协议，以天为单位发布的新模型，不可预知的错误处理。这些在规范的大厂项目中可能不会出现，但是对于cherry studio来说，这些是项目维护最大的问题，solute！也希望有朝一日所有的模型接口能够统一规范。
-
关于AI时代的黄金：一个Linux.do用户的idea，利用nano banana pro模型一键生成小红书文案和图片，效果很好，我相信这个创意一定会火（事实不到一天涨了700个star），后续一定会有内容公司跟进这个idea做产品。AI模型的商业价值是散落在沙漠里面的黄金，用不一样的跳脱惯性的视野去看待模型就会带来不一样的落地形式，也许就是下一个微信之于邮件的黄金。
.png)
