一个定时自动化把恢复状态保存在 Git 中。长任务运行期间，它会向专用分支提交租约心跳、检查点和回读结果。这些写入有明确用途：进程中断后，接手者可以重建所有权并安全恢复。

仓库的持续集成工作流却把每次状态写入都当成代码变化。打开 Pull Request 后，同一提交可能同时触发分支 push 和 pull_request 两条运行。测试夹具出现真实错误时，状态分支持续前进，相同失败便被反复通知。一个缺陷最终看起来像几十起新事故。

稳定处理方式是让 CI 跟随审查边界。状态提交继续保留审计能力；完整验证只在代码进入审查，以及审查结果进入默认分支时执行。

先把通知、运行和提交对齐

修改工作流前， …

fichil.com 不只是一个放文章的页面，它也是我公开展示工作方法的工程项目：内容、应用代码、发布规则和线上版本都能追溯到同一个 Git 提交。

这里的“AI 开发与运维”并不表示把生产权限交给模型。AI 负责阅读上下文、提出修改、实现和执行验证；人负责确认需求、评审差异、合并代码和决定是否发布。

当前架构：内容源与生产应用分开

站点保留两层明确边界：

content/en + content/zh-cn
        ↓
Hugo Markdown（唯一文章源）
        ↓
内容生成与双语一致性检查
        ↓
vinext / React Sites 应用 …