难绷，太相信 ai 了😭

不搞 git 不提交就是这样的

感觉豆包 agent 和 workbuddy 都喜欢把假设性提问当目的或事实。

程序员都不用 git ？

哈哈哈哈哈哈或，难绷。😂 你没做大版本备份吗？

不对，应该是 workbuddy + hy3 的 harness 这么差的么，随便一个其他家的 harness+主流模型都会主动 commit 的

遇到过。。。提交 git 还可以给你删了

用混元的人不是我们的兄弟，是我们的财产。

codex 似乎也必须依赖 git 来进行回滚。 但是 claude code 不用。

小改可以，大改不行，可以加一个默认配置，要求禁止删除文件，不用的文件移动到指定目录 backup 里。要求每次修改提交单独的分支管理，方便倒回。

trae 还可以撤销代码，wk 难用

我记得有个帖子叫《混元，混尼玛》

@Perry #3 就是给博客施个工，来回就改了 3 个文件，还没改到我心里的预期，我提交啥 git ？

@pldxx #4 大版本有，我是在做界面优化，一直没到预期，我想着先让 ai 跑个性能测试没啥问题，结果跑完就直接面目全非

@maolon #5 我没让他没让他在这个项目上面自动 commithttps://raw.githubusercontent.com/guozhigq/emoji_storage/main/coolapk/coolapk_emotion_52_hejiu.png ，是设置好的

@raptqhoiu9527 #10 这个功能有时候也有点 bug ，他的判断逻辑好像是根据你每个轮次代码变动差异，如果你在这轮对话自己改了一些，他也会给你撤销😂

@thinkm #11 那是真被气坏了

@YaakovZiv #9 这个有权限管理，不过手动 backup 没有设成记忆，我跑回退的时候还看到混元在思考说 workBuddy 有沙箱限制，为了做什么事情，改一个参数来绕过限制

@CHTRCT #2 好像是，有时候感觉挺有用，有时候又感觉坑自己

我现在代码都开一个 webstorm ，让 ai 修改，不和意的还可以用 webstorm 的历史版本还原

workbuddy 没有每次请求的配置文件吗？或者危险命令的操作设置点么？

之前刷到类似的帖子之后，就在配置文件里面写了，每次修改完代码之后就必须 git push 一次，然后就是删除的命令必须申请，自己目前用的 pi ，所以专门写了一个命令的权限插件来实现的这个功能。

参考我之前回复过另外一个帖子： https://v2ex.com/t/1238217#r_18031865

针对 zcode 的配置，workbuddy 应该也差不多：
https://www.verybin.com/?f705fbd1227bfa46#A56RV+bNfD3geE9oI7Zn+qAliaE1Utl9TddzCFqdZCQ=

尊敬的用户，您好！
非常抱歉给您带来不好的体验，已关注到您反馈的 WorkBuddy Hy3 模型问题，我们高度重视每一位用户的使用感受。
受大模型技术本身的局限性影响，AI 辅助处理工作时，输出结果会受提示词、上下文等多重因素影响，存在一定随机性与不确定性。为保障您的数据安全，建议日常对重要文件提前做好备份。
针对您遇到页面错乱文件被删除无法回退情况，我们将提交产品团队排查，探索相关能力改进。如您方便，可将本次操作详细情况、原文链接、及相关日志发送至 [email protected] ，便于我们进一步复盘分析。再次感谢您的反馈支持与理解。

日志与 UID 获取指引：
a.UID 获取：在 WorkBuddy 界面左下角点击头像 -> 点击昵称旁边的“复制”按钮。
b.日志获取：
○打开 WorkBuddy 应用。
○点击左上角菜单栏中的“帮助”选项。
○选择“Open Logs Folder”（打开日志文件夹）。
○系统会自动打开本地日志文件夹，找到当天的日志 zip 压缩包即可。

这里也有腾讯云啊。你怎么不用 git ，任何项目再做之前先建项目仓库在干

@yungo8 用了 git 也可能出问题...我有个 agent 合并不成功直接强制 push 了，幸好其他机器还有提交历史。

道歉还很诚恳 hhhh

@kukuos123 #23 那我问你，如果你的代码只有这一个功能正在修改，还没改好，是个半成品，你会选择提交还是不提交

@Alwaysonline #25 https://raw.githubusercontent.com/guozhigq/emoji_storage/main/coolapk/coolapk_emotion_1020.png

代码相关的还是要 git

@TimerBomb #26 你都去午睡了，那当然得要求他频繁提交了。
你坐在电脑前和他对线的时候我倒是可以理解不提交，因为你会经常改变他的方向。
我现在 Codex 在跑一个长任务，连续跑了 6 个小时了还在跑，我都是要求每次迭代必须提交的。

一个需求一个 commit 这不是必须的么。

@msg7086 #29 但是我只要求他跑性能，seo 这些测试，以前都是这样的，没遇到问题，因为这个跑起来时间很长，所以我也就去睡觉没管了

@TimerBomb #31 而且这个并不是大型项目，就只是 3 个文件的改动，还是半成品，我也就没想要去提交，我恢复，也是想恢复成我的半成品状态，把前几轮对话的改动恢复回来继续改

@zejiang89 #30 功能未完成的，比如现在要写一个使用 md5 算法计算的，然后只写了调用算法转换 16 位，还有其他的没写，这个也要提交？我是觉得没什么价值。而我现在是在调博客 UI 的细节优化，我就更不可能是改动一个细节就提交一个 commit 了

@TimerBomb 远端建需求分支，先本地提交，调整的差不多了再 push 远端分支

@TimerBomb ↑ 一般来说要不要提交取决于重做价值。如果恢复上一个提交再花个十分钟就能重做出来那确实是无所谓。如果是调了半小时一小时的东西，那肯定要交的。

@msg7086 #35 10 分钟差不多，按照记忆恢复就行，只是不能直接通过文件恢复，不过刚才想了想，如果直接放暂存区🤔，ai 只要不操作 git ，其实也不会有我这个问题

codebuddy cli + hy4 preview ，让他读了 spec ，帮我找指定功能的代码都能给我找歪来。用 glm5.3 flash 都比 hy4 靠谱，hy3 更是拉的不行 😂

@TimerBomb #33 git 多提交很方便呀。有改动就提交，现在提交 message 也都让 AI 写，一点都不费事。后面的改动如果只是改进，就 commit --amend 直接并入前一个提交。开发分支合并到主分支时，如果提交多，也让 AI 给重新整理一下，把相近的 commit squash 成一个，让主要改动突出的同时避免历史太杂乱。

这个是你自己没有一开始就约定好 AGENTS.md 啊，你哪怕招个人干活，你不也是有一系列要求吗，你怎么就能确保 AI 一开始就懂这些要求和规则呢？ 我觉得很多人在使用 AI 的时候，还是要学习下基本操作规范的，如果你说别的模型怎么就没有遇到，那只能说运气好而且，国内外御三家这种事没少干，自己做好约束才是最重要的

最近让 codex 写安卓 app kotlin 语言
经常出编译错误
然而写 java 后端基本没有编译错误了

hy3/4 都是垃圾,而且不清楚是人为还是不小心,有时候明显降智,试过就不想用了
默认也会勾上"使用你的数据用于训练"这个条款,记得勾掉

靠，上次想着给我的七彩虹主板更新一下 bios ，问了 gemini 一步一步操作的，结果给我变砖了。最后还是到处找，在 b 站某一个 up 分享的 bios 更新教程的评论区里一个热评找到的原因，然后又结合官网提供的工具给救回来了，折腾了大半天

忍不住了。。。

@DinnyXu 约定好,也怕上下文污染,仓内文档语义矛盾或模糊..我写 agent 吃了两次亏了..

@zuokanyunqishi 那就写成 rule codex 或者 cursor 都能自定义 rule ，这个是强制要求的

“感觉不比其他模型弱”

git 的本质是保留某个未来你可能要用的版本, 而不是只记录最终版本

@zhw2590582 #46 当时感觉确实，用着很爽

hy3 和 hy4 在我这工作结果都不错，三四个文件改动的话在上下文范围内也能撤回。不过每次指令我都会写“注意保持最小改动，尽量避免引入新的变量或函数，编程语法风格与现有代码一致”

边界没有设定好会很麻烦，我之前的项目，后来发现日志它没有做脱敏，有些涉及账户密码的，它打明文。。
坑死了

别杠了 不提交的结果就是你现在这样 你不提交未来这样的事还有的是

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

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

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

deepseek ，我扔了一张早年 DNF loading 图让他帮我看看是什么版本，他愣是给我往绝区零和漫威争锋上面套，想爆粗话。

我印象也是这样，HY3 刚开始免费的时候好用，就是好几次免费延长之后就特别特别蠢，就直接不用了。到那个 HY4 更是特别蠢，我让他调研一下，他会自己给我编口令，就一直 调研的很好，然后继续下一步继续。着魔了，特别垃圾

全部国产大模型都不适合完全自主开发，因为任务偏离非常大，不是上下文问题，是推理能力不足，只适合对着计划具体工程。

在 agents.md 里强制要求只要修改了就要 commit

不提交的话暂存就好了

绷不住，刚说 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 元数据。

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

workbuddy 的混元 3 是吗? 都没用过, 不过记住了. 谢谢

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

@DinnyXu rule 本身也是文档,也会腐烂的.需求和设计自己完全门清,文档不腐烂,门禁和漂移检测多个手段尽量避免

只能拔 ai 的插头来解恨了

@thinkm #11 https://www.v2ex.com/t/1201399

ai 拿什么“负全责”

@TimerBomb #12 现在交学费也不晚😀

真的能接受 AI 的道歉吗。。。。
那可是秒秒钟生成的一个道歉。。。。

@coolcoffee antigravity 也不用，直接撤回消息瞬间还原

Claude 的 worktree 就很好，先不动主目录，改好了再合并，也不需要 commit

ai 现在好像对 git 操作很热衷，并且没有克制行为，他是真敢自己提交 git 啊

我也一直在白嫖，用户多了之后估计调参数了，发现 hy3 还是差很多，很多功能改几遍都有问题，还是 ds flash 好点

@frankilla #53 deepseek 好像不是多模态吧？

@frankilla #53 之前提交图片给我说不能解析图片

@xuejianxianzun #52 😂没办法，我是倾向手动提交的，git 提交是有规范，但每个人也有自己的偏好，模型误删文件我还是第一次遇到，很难说是 Agent 的问题还是应用的问题

@MX0kLK #54 对，免费推广的时候我都感觉不需要总别的模型

@prosgtsr #56 这个可以，之前一直没注意这个文件，应该不同项目个性化一些

@jackOff #70 我自己在家用 workbuddy 多一些，我工作用的 trae ，但没看到这个自动提交过 git