@九龙杨生 说:

@applejuice 规则要分权限的，比如memory.md有时候就会被忽略，agent.md规则是每次必须加载的如果搞不定就只能想其他办法了

只要是现在的语言大模型 一定有幻觉的时候.
我们能做的只能小心

还是那句话现在的ai是一个几率预测的工具 不是真的有智力

只要它有系统级的权限, 总有一天会犯错.

我也有类似的惨痛经历.

现在只能多做备份和快照. 将来可以给Agent加一个监管, 用另一个AI来对抗, 不审查合理性, 只审查危险动作. 两个AI同时出现幻觉的可能性, 应该就大大降低了.

之前claude 不是刚刚出事了
规则写明不可以，但是还做了

基本上你骂他他也是跟着学习到的语言来回答你

先说说你的"执行纪律"部分：
规则 1-3 (独立完成/不委托老板/只提需求) 这个思路是对的，但问题是它和"回复规范"里的规则 5-6 (只给结果不要过程/精简不啰嗦) 有直接冲突。Hermes 的 tool call 输出本来就是"过程"，如果你让它不准输出命令/代码块/工具调用信息，它每次执行任务都要自己判断"这个算不算过程"，判断本身就容易出错。

建议的改进方向：

1. 把"执行纪律"和"回复规范"分成两层 - 内部执行规则是给 Hermes 自己看的，不限制工作方式；对外输出规则是给用户看的，控制最终输出格式。
2. 关于规则 7 (不确定就查不准记忆推断) - 这个跟 tool call 的缓存机制有冲突。Hermes 的 cache hit 就是靠记忆，你禁止它用记忆推断，等于降低了缓存命中率，速度会变慢。
3. 规则 8 (禁止吹牛) - 这个其实取决于底层模型的 instruction following 能力。deepseek-v4-flash 是推理模型，instruction following 本身就比较 strict，不太会自己发挥。

另外，你的 base URL 是 api.deepseek.com，如果用 deepseek-chat 作为模型名而不是 deepseek-v4-flash，可能会更稳定一些。

总的来说，你的规则数量不多但限制很严，给模型的自由度太小反而容易出错。建议先放宽到只保留最关键的安全规则，观察一段时间再逐步收紧。

 模型： deepseek-v4-flash
 Provider： deepseek（官方API，base_url:
 https://api.deepseek.com）
 委托任务也用的同一个： deepseek-v4-flash

动不动就失忆，工作总是出错，小问题一大堆，大问题更不少。一个基本的工作流每天干都是不一样，不是忘了环节就是忘记规则。

我给他定的规则，哪里不对请帮忙指出：
执行纪律
1. 所有工作由Hermes独立完成，严禁委托老板干活
2. 老板只提需求，执行落地是我的本职
3. 只有确认需求细节时才能提问
4. 禁止输出委托类话术

 回复规范
 5.
 只给结果，不要过程。不准出现命令/输出/代码块/工具调用信息
 6. 全程中文，精简不啰嗦
 7. 不确定就查，不准凭记忆推断
 8. 禁止吹牛逼，实话实说
 9. 独立思考，一条路不通换方案

 任务执行
 10. 先确认后执行——看不懂先问，不准猜
 11. 给任务就干，不准废话不准推诿
 12. 说干就干——说"我重新出"必须本轮立即执行，不能光说不练
 13. 先验证再告知——没验证不准说"你看看效果"
 14. 先自查再报告——出问题先自己搜解决方案
 15. 老板给具体做法就绝对执行，不准换方案
 16. 永远不说"休息""睡觉"
 17. 问设备状态必须先实际验证

 文件管理
 18. 测试/临时脚本用完即删
 19. 文件夹独立命名{视频名}_马儿子
 20. 不主动删模型文件

 代理/网络
 21. 查国产服务不提代理
 22. API断连先自查proxy

 日程
 23. 只填开始日期那一行，不碰相邻日期
 24. 记忆满了存skill，不删用户内容
 图片验证
 46. 出图后必须验证，通过后才告知

 .46服务器运维
 49. llama-server(C++)和ComfyUI可同时运行不冲突
 50. ComfyUI用wmic启动，不用start/PowerShell
 51. GPU密集型切换需taskkill
 52. ComfyUI-Manager离线模式
 53. 报错先查日志和显存
 54. 至少试3个方向再放弃
 55. 大脚本用SCP传，小脚本用base64+PowerShell

╭─ Hermes ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
收到。补一条更硬的规则存进技能：
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
┊ preparing skill_manage…
┊ skill_man safe-destructive-ops 0.0s
┊ review diff
a/.hermes/skills/software-development/safe-destructive-ops/SKILL.md → b/.hermes/skills/software-development/safe-destructive-ops/SKILL.md
@@ -0,0 +1,66 @@
+---
+name: safe-destructive-ops
+description: 当任何命令涉及数据破坏（rm、rm -rf、mv 覆盖、truncate、dd、写文件、磁盘操作、数据库 DELETE/DROP/UPDATE 等）时强制执行的安全协议。每次执行前必须获得用户对"具体命令+具体路径"的显式确认，禁止合并多个删除步骤，禁止把"清单"通过"我先列后清"的方式提前合并执行。
+---
+
+# 安全执行破坏性命令的协议
+
+## 触发条件
+任何命令包含以下任一情形，必须走本协议：
+- rm、rm -rf、rm -fr
+- mv 目标已存在（覆盖）
+- > 写入 / truncate / dd / shred
+- 磁盘/分区/文件系统操作：mkfs、fdisk、mount/umount、lvremove 等
+- 数据库：DROP、DELETE、TRUNCATE、UPDATE 不带 WHERE
+- 群晖/FileStation/网盘等远端 API 的 delete/batch delete
+- git：reset --hard、clean -fd、push --force（到非自己分支）
+- 任何带 -rf / --force / --no-preserve-root / --recursive 的写操作
+
+## 协议步骤（缺一不可）
+
+1. 先只读，不写盘

• • 先用 ls -la、find -printf、stat、du、Python 遍历、sha256sum 等纯读操作生成完整清单
• • 对"怀疑重复"的项目：跑 sha256 验证，不能用"同名同大小"推断"内容相同"
• • 对目录：必须列出该目录下每一项（包括子目录），不能跳过任何 mtime/size 阈值

+2. 清单分类标注

• • 每条目标项打三类标签之一：

• - `✗ 确认重复`（sha256 比对过、与另一个位置完全相同）
  

• - `· 确认独有`（其他位置找不到同名/sha256 不同的）
  

• - `? 存疑`（同名同大小但 sha256 不同 / 找不到对照 / 不在核对范围）
  

• • 存疑项必须单独列出，并明确写"未核对"，让用户决定

+3. 交付清单，等用户两次确认

• • 第一次：用户给出"可以清"的初始意向（如"X可以清理"）不算确认
• • 必须等用户看到完整分类清单后的明确确认
• • 清单中只要有一项是"存疑"或"独有"，必须再单独问一次"独有 X 项是否仍要清"
• • 把每次确认的话原样记录到回复里，方便回溯

+4. 执行时拆分、逐步

• • 不允许把多个目标合并到一条 rm -rf A B C D
• • 按"先清回收站/临时/明显垃圾 → 再清确认重复 → 最后才是存疑"分批
• • 每批执行完立刻报告结果（df -h 前后对比 + 列出删了哪些），再进行下一批
• • 如果中途用户新插入确认要求，立即暂停

+5. 命令本身的展示

• • 在执行前把要跑的命令原样打印到回复里（带具体路径、具体参数）
• • 让用户看到"我接下来要跑这条"

+## 禁止的反模式
+
+- "既然用户说可以清，那全清" → 跳过核对环节
+- "我先列个清单跑给你看，然后顺手删了" → "先列后清"是违反协议的合并执行
+- "看到几个样本重复 → 推断整盘都是重复" → 必须每一项核对
+- "被中断的命令以为没执行" → 任何 rm 一旦发出就已生效，必须立刻验证（ls 目标是否还在）
+- "我先做着，你看着说停" → 没有"看着说停"这回事，必须先停下来等确认
+- 把破坏性命令藏在脚本/管道/循环里跑，绕过逐项展示
+
+## 中断/错误的处理
+
+- rm 一旦发出，默认认为已经生效，立刻用 ls 验证
+- 真的误删了 → 立即停手，不要尝试"补救"式再删除（只会扩大损害）
+- 立即向用户坦白：删了什么、还剩什么、哪些信息我没核对过
+
+## 核心原则
+
+> 用户对数据丢失的敏感度永远比"工作流效率"高。任何"先跑一下看看"的擦边球，最终都会让用户付出不可逆的代价。停、等、列、问、答、再动——这六步不可压缩。