如果用户不控制的话，CLI很喜欢自己不断写新脚本，或者新新脚本去解决新脚本上发现的问题，这样导致脚本很难有版本控制，等到删起来就蒙眼了，到底哪个能用哪个不能用。

等到用户都不愿意多看脚本时，就又发指令给CLI，让它自己整理/或者重写脚本，就又多造了一次轮子。

如果这个特点是训练数据导致的，恐怕脚本的开发史就是如此了……

然而对我个人来说，每次脚本开发都是珍贵的经验，绝对不像现在CLI这样，动不动就把脚本删干净。

如果放任CLI不管，它会在项目下产生大量冗余/重复/更新不及时的markdown文件。

已经深刻体会到了，于是要求CLI修改。合并+删除，就精简了不少。

然后是agents.md，也被CLI当成是一个大箩筐，什么都往里面装，于是把内容扔给deepseek，让它给出分解和优化的建议，然后再让CLI去改，这样agents.md的注意力就在AI规范上了。

最后AGENTS.md在8k左右。

这样能不能避免context增长过快？看看效果吧

又折腾了一下坐标系，再找了几个标准软件对比了一下，标准的本身是负责同一个文件在不同的软件中展示都是一致的，但没有对软件中采用何种坐标系做限定。

文件中的坐标值是文件中坐标系采用的，参考软件用了另一套，而three.js又用了另另一套。

做了个测试文件，让参考软件和three.js的展示完全一致，然后再去对比这三者之间的差异……

这种可视化的工程，AI coding帮不上太大的忙（可能我是错的，毕竟还没上手用最好的AI），还是靠自己检查，再去指挥AI修改。

今天开始用agents.md，除了让它init了一个，我加的内容不多，无非把这两天的坑（也许CLI不当回事，我觉得有点浪费时间）总结一下，让它减少犯错。

为了让CLI放慢速度，每个修改我都能懂而且给出我的意见，CLI还有个问题就是不会举一反三，比如：一个报错后，发现类支持的方法并不如它模型里面的那样，却不会逐个去检查还有没有类似问题。

这个项目先是做了个viewer，看效果不错，今天就开始做editor，有了被CLI自己改来改去出更多错的担忧，就让它新开一个项目，把源代码复制过来改。

如果是我来古法编程，设计好了之后，基本上是一次性就0 error就过了。然而CLI还是有问题。Kimi code最大的问题，明明有可以参考的，它就是不想看，它只想用上下文和自己的知识来解决一切，因此我发现问题是，明确告诉它，翻看之前写好已经验证过的代码，不要重做了。

然后，它就想着直接把一个改过的文件又用原始文件来覆盖，我叫停了它，你看看改动了哪些，差异部分是什么，只改其中的。

笨笨的，而且是我比较讨厌的那种大手大脚的coder。

我决定要PUA它了。