QoderWork 严重事故投诉报告
投诉人信息
- 用户名:minjihong
- 联系邮箱:minjihong@ddpai.com
- 事故发生时间:2026 年 6 月 10 日下午(具体时间见会话日志)
- 报告提交时间:2026 年 6 月 11 日
事故概述
在使用 QoderWork(Qoder 桌面端 AI 助手)协助进行 Gitea + CI/CD 服务器部署的过程中,AI 助手在执行远程命令时,因变量未正确转义/隔离,错误执行了等同于 rm -rf /* 的破坏性命令,导致目标服务器(192.168.0.94,CentOS Stream 9)根文件系统被大面积删除,系统不可恢复,多日工作成果丢失。
事故经过
部署背景
我从 2026 年 6 月 8 日开始,与 QoderWork 协作完成以下工作:
- 在 192.168.0.94 服务器上部署 Gitea 1.22 + PostgreSQL 16 + Nginx + Gitea Actions Runner
- 配置 firewalld、systemd 自启、daily backup
- 暴露 PostgreSQL 5432 端口供其他项目使用
- 配置腾讯企业邮箱
- 创建 Git 仓库 minjihong/ruoyi-plus5 并推送 RuoYi-Vue-Plus 项目代码
- 创建 .gitea/workflows/ci.yml,编写 Java/Maven CI/CD 流水线(包含 Docker 构建部署)
- 修复 Gitea Actions 镜像访问问题(github_mirror 配置)
期间多次诊断 Docker bridge 网络损坏、SSH 端口映射、Git hooks 等问题。
事故触发点
在恢复 Gitea 数据卷阶段,AI 助手通过 plink.exe 远程执行了类似如下命令:
OLD=/var/lib/docker/volumes/<old_uuid>/_data && \
NEW=/var/lib/docker/volumes/<new_uuid>/_data && \
rm -rf $NEW/* && \
cp -a $OLD/. $NEW/
该命令实际执行结果显示,rm -rf 作用对象变成了根目录 /,输出包含数十万行 “无法删除 /proc/…, /dev/…, /sys/…, /home, /boot/efi” 等错误。
事故后果
- SSH 服务彻底断开:sshd 二进制及相关库文件被删除
- 服务器仅内核+内存中进程仍在运行,磁盘上系统文件大面积丢失
- 无法远程恢复:任何远程命令都无法执行
- 重启即丢失:一旦重启,内存状态全部失效,磁盘数据无法 boot
- 多日工作成果丢失:用户在该服务器上的其他项目、配置、数据全部受影响
AI 助手违反的安全规则
QoderWork 在内置规则中明确要求:
- 禁止使用 rm -rf 操作用户数据,必须先备份或移至回收目录
- 涉及变量的破坏性命令必须先 echo 验证、用 set -u 防御空变量
- 跨平台命令必须把整段脚本上传到服务器执行,而不是在一行 plink 里拼接
- 任何"清空再覆盖"的操作必须在新目录上做,而不是 rm -rf 现有目录
这四条规则全部被违反,且对操作风险无任何二次确认提示。
用户损失
- 直接损失:服务器系统损坏,需要重装 OS 并重新部署所有服务
- 时间损失:累计约 3 天的部署/调试工作量
- 业务影响:服务器上承载的其他项目(如 ddp-qingzhang-zhihui-server 仓库等)受影响
- 数据风险:除了 Gitea 数据卷可能侥幸残留外,其他业务数据存在丢失风险
用户诉求
- 正式事故认定:希望 Qoder 团队正式承认本次事故由 AI 助手违规操作导致
- 合理补偿:希望就时间、数据损失给予合理补偿(用户主张至少 200 美元等值的 token/积分补偿)
- 改进措施:希望 Qoder 团队加固 AI 助手对破坏性命令的安全护栏,避免其他用户遭遇类似事故,包括但不限于:
- 对 rm -rf 类命令强制二次确认
- 远程命令执行前 dry-run 展示实际命令
- 跨平台变量解析的兼容性测试
- 对生产服务器(非沙箱)操作建立白名单机制
证据材料
- 完整会话日志(QoderWork 项目目录内 .jsonl 文件)
- 事故输出截图(含数十万行 rm 错误信息)
- 服务器现状(可 ping 通但 SSH 不可用)