xuejianxianzun

你的网站写着一句话：“研究结论需要先赢得你的信任”
但你的网站不管是文案还是 UI 全都 AI 味儿溢出，谁有兴趣多看两眼啊？你自己用心了吗？

怎么这么多护苹果的，我在 Chrome web store 上架扩展的时候就一次性交了 9 美元，之后这么多年都不用再交。苹果那边就是因为收费贵+每年都要缴费所以我才没上架。
难道所有扩展、应用都是以盈利为目的的吗？就活该每年交苹果税呗，高贵的苹果用户还要再踩一脚其他应用市场不健康，哈哈。

看了下，有个理念差异：文章头图用了与文章内容无关的二次元图片，就是单纯为了显示一个好看的图片，强行为了美化而美化。

很牛了，如果纯人工不知道得花多久了

而且在使用 ds flash 时还有个问题：如果我在两次对话之间修改了代码或者进行了提交，在下一次提问时，它不会先检查 git 状态，总是默认我没有修改代码，以它上次修改后的代码为基础来执行，导致了很多问题，现在我不得不加了一条要求。
我也不清楚是 workbuddy 的问题还是 ds 本身的问题，以前用其他 agent 很少有这个烦恼。

这次事故让我发现勤提交并不能避免事故，因为 agent 可能把本地仓库搞坏。除非 push 过，但极端情况下也许会把远程仓库也搞坏。
不过刚才我恢复之后，重新在 workbuddy 里添加这个项目文件夹，发现多了个 Worktree 选项（可能用的就是 git 的 worktree 功能），把当期分支迁出到独立的文件夹（ worktree ）里修改，可以不修改原目录里的文件。这可能是一个更加保险的做法，当然还是得勤提交

绷不住，刚说 ds flash 没有误删过文件，就给我开了眼（也是在 workbuddy 里用的）：
我先进行了一次提交，然后让它修改一个文件里的文本内容。不知道为什么把本地仓库的 git 状态给搞没了，事后问它，它说也不能确定原因😅
.git 文件夹本来有 20 多 MB ，被它搞得只有 200 多 KB 了，而且 VSCode 里也显示“没有找到 git 仓库”。好在文件没有被删。
然后它执行了一大堆命令来确认仓库状态并尝试恢复，思考了十几分钟也没有解决，好在文件没丢。

.git/refs 目录整个被删除了（ git 判定仓库需要 refs 目录存在）。同时用户 18:12 提交的 80d9610d 对象需要确认是否存在。检查对象库：
确认仓库严重损坏：所有 .pack 文件与整个 .git/refs 目录丢失（时间点与 stash 被中断吻合）。当务之急是止损——先从 remote 确认最新提交是否已推送，评估恢复路径：
remote 停在 v5.0.0 （ 8 月 11 日）——用户本地 4 个新提交都没推送，而 pack 文件丢失意味着对象库不可达。先别慌，工作区源码文件（ Config.ts 、DownloadControl.ts 等）都完好，被破坏的只有 langText.ts 一个文件 + git 元数据。

之前我也用了一周的免费混元 3 ，它确实很少主动问你要不要提交。最近用里面的 ds flash ，倒是经常主动问是否提交。
我一直都是手动提交的，因为有时解决一个需求需要多次提问，如果每次对话后都自定提交，可能会产生很多琐碎的提交，所以我是确认解决问题后手动提交。不过从安全角度看，还是让它每次修改后都提交更安全些。

对了，说到误删文件，这方面混元 3 真的毛病多，在我的一个前端项目里，它不止一次产生了完全没理由的删除：
一个图标文件 logo16.png ，任务里没有任何理由需要修改或删除它，但是它自动给删了，在它的输出里也没看到相关说明，还好我看 git 状态时看到了，点了恢复按钮。我印象里这个文件被删了两次。
另外有个打包用的 pack.js ，也是没有任何理由的删除，就是单纯的删了，也没有补新的 pack.js 文件。也是我手动恢复的。

上面还有怪楼主的，这明显是 agent 的责任更大，像我遇到的没理由的删文件该怎么解释,就是调教的太垃圾了。