本文整理自 Hermes AI 助手长期记忆中沉淀的实战教训，覆盖模型配置、定时任务、静态博客、云盘对接、脚本安全等高频踩坑场景。每条都来自真实事故，附根因与正确做法。
一、模型与配置
1. 熔断链第一级不该与主模型相同
主模型挂了，同 provider 同模型的兜底必然也挂——白白浪费一次重试时间。熔断链应从真正不同的模型开始。
2. 定时任务模型要显式固定，不随主模型漂移
主模型切换后，未 pin 的 cron job 会因模型快照不匹配而静默失败。所有定时任务必须显式指定模型（如 sensenova-6.7-flash-lite / glm-5.2），与主模型解耦。
3. 读取密钥必须用原始字节，防止工具脱敏误判
sed/grep 读取 .env 中的 API Key 时，输出可能被上层工具脱敏成 ***，导致误判”key 缺失”并触发无谓的配置回退。正确做法：用 xxd 或 wc -c 读取原始字节确认。
二、定时任务
4. Cron 的 prompt 路径与部署脚本路径必须一致
一次典型事故：cron prompt 里写的是旧工程路径 /root/hexo-blog，部署脚本却已更新为 /root/blog5。结果真实新闻被写进旧工程，新工程找不到文件只生成”骨架占位文章”。修改工程路径时，cron prompt、部署脚本、推送链接三处必须同步。
5. 每日累加内容用日期命名文件，幂等不覆盖
每日生成的文章用 ai-news-YYYY-MM-DD.md 独立命名；脚本 if [[ ! -f ]] 判断同天已存在则跳过生成，历史文章永久保留。cron prompt 中还要明确”禁止覆盖已存在文件”。
6. 主题排序字段要摸清：Stellar 按 updated 排序
Hexo Stellar 主题 order_by: -updated，不是按 date 排序。新文章如果只有 date 没有 updated，排序会错乱。所有文章必须同时写 date 和 updated，且时间精确到时分秒。
三、静态博客
7. Caddy 的 ProtectHome 会挡住 /root 下的站点文件
systemd 加固 ProtectHome=true 会让 caddy 用户读不到 /root 下的文件（403）。站点文件必须放在 /var/www/ 标准目录，构建产物用 rsync -a --delete 同步过去并设 755/644 权限。
8. 换主题前先确认用户要的”结构”而非”颜值”
用户从 Clean Blog 一路换到 Stellar，最终满意不是因为某个主题多好看，而是 Stellar 原生支持”专栏-文章”结构（topic 系统）。先问清信息架构需求，再选主题。
9. 全局改名要 grep 全站，配置、模板、内容三处都可能残留
站点改名只改 _config.yml 远远不够——侧边栏 logo（_config.stellar.yml）、欢迎语（widgets.yml）、关于页（about/index.md）都可能残留旧名。改名后必须 grep -rl 全站验证零残留。
四、云盘与脚本
10. 百度网盘授权码 5 分钟过期，bdpan 不在 PATH
- 授权码有效期极短，生成链接后要立即让用户完成授权
- cron 等非登录 shell 环境下
bdpan不在 PATH，脚本必须写全路径/root/.local/bin/bdpan - 网盘删除权限仅限
/apps/bdpan/授权目录，其他目录”搜得到删不了”
11. 微云调用必须禁代理
微云 MCP 走代理会 i/o 超时，所有调用需 env -u HTTP_PROXY -u HTTPS_PROXY 前缀。
12. 清理脚本的扫描根目录要指向真实下载目录
一次审计发现清理脚本 SCAN_ROOTS 指向 3 个不存在的目录，媒体清理实际空转。修复为指向工作流真实下载目录 /tmp/link-work/，并对临时目录走独立清理逻辑（避免 video.mp4 泛名与网盘同名文件误删）。
总结：多数事故的根因是”配置分散多处、改了一处忘了另一处”。把路径、模型、权限这类强约束写进 checklist，或沉淀为 skill，能避免 80% 的重复踩坑。