鉴于自身经常使用三维软件，特别是节点式操作的交互界面，也是使用得比较多。所以打算尝试做个3D网页应用。深度体验solo的编程能力，文档能力，自主思考解决问题的能力。
测评记录和提示词完全手写，从人类视觉，看待普通人写的，和AI自主写的需求文档差距到底在哪。图片量有点大。
我本身工作上基本用不到Github，但是看到Solo有连接Github的功能，想尝试一下，所以先申请了个账号，从建仓开始，然后授权连接了Solo，直接让Solo从一个空白的仓库开始。这样更方便记录它的迭代过程。
然后开始直接让Solo开干，它拉取了仓库之后，就开始编写相关文档规划了，然后等我确认。
**这里有个细节的地方，那就是Solo貌似有超时机制，**如果我阅读确认的时间太长了，它就会自动帮我确认并且开始执行这个计划了。实时上，我阅读它的这几个文档，时间确实花了不少，前期还是要认真一点的。不过我感觉结构大体上应该没问题（绝不是我看不懂它的技术栈在写什么）。
这个任务看起来是有点复杂，然后它会把任务分配给一个个的subagent来单独完成每个任务。
一看到熟悉的光照，相机，几何体，材质，就感到安稳。
它工作的中途也会弹出一些预览窗口，但是看起来还是很粗糙的样子呢。左右被裁切了怎么回事。然后它似乎自己意识到了问题，把这个修复了一下。
毕竟还没跑完，先等它完全跑完之后再看。
这期间，我上个厕所，泡个咖啡，打开手机做做每日的手游任务。结果回来一看，我几个手游任务都做完了，它还在跑。果然是个孜孜不倦的牛马，连自己都愧对不如。
看它连续跑了一个小时十分钟，终于停下来了。我先验收一下初版的成果。它最后似乎甚至自动完成了推送到Github。
先让我看看效果是什么样。
嗯，看着有常规三维软件里面的，平移，旋转，缩放，还有三种灯光类型呢。资源库也能正确上传纹理。但是貌似控制台有些错误信息，虽然不知道是什么，先发给solo解决一下吧。
然后开始悲剧了，我感觉自己是不是聊得太随意了。Solo开始左右横跳。修一个旧的问题会带来一个新的问题。Solo后面将会数次在思考中用到的经典语录：**让我用更简单的方式去实现。**当solo在思考的过程中，出现这种想法的时候，你得特别小心一点。幸亏被我看到了。
后面修的几个问题，都开始出现：**让我用更简单的方式去实现。**然后纹理这个功能，就处于禁用，开启，禁用，开启。量子叠加态了。
这样可不行，我不能让solo一直处于这种左右摇摆的状态。我决定让它自己先写个修复计划吧。
让solo在修BUG之前，一定要先写文档，再执行。让它有个全局观，让它不要破坏设计意图（但是实际上还是会偶尔不听话）。然后折腾了半天的成果。灯光和材质贴图都能正常使用了。
然后，我发现场景导出和加载，也存在问题，这次我也同样要求它先写文档。同时我自己还补充了一些我自己的想法和细节。我平时是怎么操作三维软件的，三维软件的正确操作应该是什么样的，使用体验应该什么样的。基于我对这类软件的使用经验，三维软件也是有资源路径素材缺失的问题，solo似乎没有考虑到资源不存在的时候的情况的问题，导致直接画面就崩了。如果素材实在找不到，就替换成一个默认的空白贴图吧。
这个加载场景，单个修复任务它这次跑了半小时，倒是一次过（也可能这个任务比较简单），但是起码没有那么粗放了。
又折腾了半天，算是把基础的三维场景的交互问题解决了。我让它做下一个材质系统的任务。但是这个似乎对solo来说，是有点难度的，足足干崩了三次，毕竟这个系统，它跑一次就花了1小时。
最后终于还是出来了个初始版本的样子。但是这UI是怎么回事，看起来有点丑，而且层级有点混乱的样子。我决定让Solo把界面的布局重构一下。
做功能模块细化的时候，直接把solo哥干崩了三次。鉴于solo哥表示，我的需求有亿点点复杂，我决定再拆分一下，给solo哥吃上细槺。我表示再努力一下，再加亿一点点的功能，就能完成当前模块的开发了。
界面重构之后，终于有点对味了，我相信你可以的，solo哥加油。要不我们把这个节点系统也重构一下吧。鉴于我怕solo哥罢工，我决定把这个单独拉出去重新设计成新的系统，毕竟看起来还不够专业。要设计得更专业一点才行。
你的新界面怎么看起来有点小问题，没事，继续交给solo哥解决。
本来想继续细化下去的，但是一看时间，都快跑了俩天了，我也累了，是时候提桶跑路了（不是）。
还是先给这俩天的结果做个总结吧，后续的更新看心情了。
毫无疑问，大语言模型的文本能力确实是吊打大部分人类的，反正自己想要写出这么细致和复杂的需求，感觉思考半天也未必能写出这么严谨的。当然我们只需要关注自己真正想要的就行了，需求写得丑没关系，反正Ai会帮你美化。
solo对文本的阅读，理解，总结，查找能力很强，所以某个功能出现问题，它能够根据关键词，快速定位该模块所关联到的其他模块，以及哪些地方调用了它。观察它的思考过程，感觉也像是人类的方式，解决问题和查找问题的也看起来比较合理。
但solo有时候会为了让程序能正常跑通，修复错误，会采用临时禁用一些功能的策略，会破坏功能的完整性。甚至有时候会把用户体验相关的操作简化，也就是能跑了，但是用起来操作很别扭。也就是solo实际上是完全不知道什么是用户交互体验，它只是按照手册要求它怎么干的规则来的，如果手册本身就没描述清楚什么操作流程顺序，操作反馈的细节。那么它就会随意发挥，寻找最短路径去修复代码问题。即便文档是有详细描写操作方式，你依旧还是得自己去确认，毕竟solo没办法看到真实的操作过程，它对操作的理解其实还是停留在文档层面，以及代码的层面，它认为自己有这么做了，而且跑通了。
总结：文本处理能力，你可以相信solo。但是质量把关，你只能相信自己。
这里还有个小BUG:那就是solo给我打开预览网页的时候，我明明看到一大段的代码报错，初始化失败，也就是页面完全看不到东西，而是一堆代码的黑色背景（可惜这里没截到图）。但是它说运行没问题，而且又检查了一次，还说顺利编译。还是我把信息复制给它，它才意识到代码出现基本的语法错误了。
这次体验也展示出了solo跑长线任务的能力，在设计好每个任务规划之后，直接让solo跑。第一天是最顺利的，即便超过1小时的任务，中途并没有发生过中断的问题。第二天尝试跑几个超过1小时的任务，中途都出现过中断的问题。
任务怎么拆，拆成多小的颗粒度，取决于自己对业务面的理解。如果你想让Ai一口气输出达成你想要的最终效果，不大现实。比如我让solo跑了其中一个模块的内容，都足足跑了一个小时。而且错误可能会累加，所以最好每个阶段验收，并且纠正它，免得让它在错误的路上越跑越远。
是这样的，solo哥只需要写代码和总结文档就行了，而用户要思考怎么写提示词，怎么验收效果，怎么鞭策它，就需要考虑很多了。
关于Github仓库，目前提交的版本还有一些Bug没有修正，毕竟是48小时试验性质跑出来的，质量还是缺佳，特别是交互操作上面需要细化的还是太多了。但是里面包含了大量solo在任务执行过程所产生的文档产物，我觉得这才是最大的意义所在吧。经过这个仓库，你能清楚看到solo是怎么把我的任务分析拆解成更详细的文档，并且执行的，版本更新的总结信息也是solo自动编写的。
