一、那个惊魂时刻：3个月的代码，5分钟归零
哪怕现在敲下这些文字，我的手还在微微发抖。
事情发生在上个月。我正在使用AI调优一个项目，本意只是想让它帮我整理、重构几个核心模块的目录结构。
在规划阶段，它的表现几乎完美：
思路清晰、Prompt 逻辑严密，甚至还主动提示我——
“为了安全，我会先扫描目录。”
我选在代理模式自动执行后，就去干别的事情了。
等我回来时，代码已经消失了——
它还一脸“无辜”，在疯狂提示我找不到代码。
由于一个极其隐蔽的路径拼接幻觉，
它把原本应该操作的 ./sandbox 目录，错误地解析成了项目根目录。
而这个错误，在执行前没有任何提示。
接下来的5分钟里，它在“疯狂重构”的名义下，
把我写了3个月的代码，物理意义上地清空了。
那一刻我才意识到，标题里的“重开”，不是玩笑。
二、复盘：为什么 Prompt 根本救不了这类事故？
这次事故让我真正意识到一件事：
AI 的失败，往往不发生在“怎么想”，而发生在“怎么做”。
我们习惯把安全寄托在 Prompt 上，希望通过规则约束 AI 的行为，但现实是：
- 幻觉不可避免
即使 AI 在对话里承诺“不删文件”，在真正生成工具调用参数的那一瞬间，
一个微小的路径偏差，就足以造成灾难。 - 执行层是不可逆的
一旦 AI 拿到了文件系统或网络权限，每一次 Side Effect 都是真实发生的，
没有撤销、没有后悔。
如果执行阶段没有“物理保险丝”，
再聪明的模型，本质上也是在裸奔。
三、FailCore：不是造框架，加一道保险
说实话，我并不是想再造一个新框架。
FailCore 的出现，完全是由这样的事情逼出来的。
那一刻我意识到，不能没有任何限制的让AI操作电脑：
1. 运行时拦截（Execution-time Interception）
那次路径跑偏告诉我：
安全检查不能只发生在对话里，必须发生在执行之前。
FailCore 会在 Python 运行时层面钩住工具调用，
当 Agent 尝试触碰非授权目录或危险网络目标时，
在 Side Effect 发生前直接熔断。
2. “黑匣子”式审计
那5分钟里，我甚至不知道它具体在删什么。
所以我需要一份事后能回看的证据。
FailCore 会把执行过程整理成一份 HTML 审计报告，
清楚地记录：时间、参数、目标路径，以及失败原因。
3. 确定性回放（Deterministic Replay）
我不想为了复现一个事故，反复烧 Token。
FailCore 允许你基于记录下来的 Trace，
在本地 100% 复现那个出错的瞬间，
而不再真正执行危险操作。
四、拒绝“盲盒”：看得见的执行，才叫安全
下面这张是 FailCore 生成的 HTML 审计报告雏形
它的意义不只是“防事故”，而是把黑盒打开：
- 对开发者：出问题时，能回放、能定位
- 对团队或企业：每一次 AI 行为都有可审计的证据
- 对 AI 本身：给它戴上一副“手套”，而不是放任裸奔
五、写在最后
FailCore 目前已经开源。
它还很粗糙，也远称不上成熟，但至少让我敢继续把 AI 放在本地跑。
如果你也在让 AI 直接操作文件、网络，
或者你也担心某次“重构”会不会变成“重开”，
或许这个方向能给你一点参考。
项目地址：
👉 github.com/Zi-Ling/fai…
你会让 AI 直接操作你的本地文件吗？
或者，你遇到过哪些离谱的 AI “翻车”瞬间？
欢迎在评论区聊聊。
