用 AI 开发与运维 fichil.com：从 Markdown 到可审计的 Sites 发布

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

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

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

站点保留两层明确边界：

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

Hugo 仍用于内容结构和兼容构建；生产页面由 sites/ 下的 vinext 应用渲染。文章不会在应用目录里再复制一份，因此不会出现“Markdown 改了，但生产组件仍显示旧文案”的双重来源。

为什么保持开源和可审查

公开源码的价值不是让别人复制同一个个人站点，而是让每次修改都有可见边界：

• Git 记录内容、组件和配置的差异；
• AGENTS.md 约束 AI 可以修改什么、不能触碰什么；
• Pull Request 把需求、实现和检查结果放在同一个评审入口；
• CI 同时验证 Hugo 兼容构建与 Sites 应用；
• /version.json 暴露当前线上版本对应的完整提交 SHA。

这些信息让“已经发布”成为可核验事实，而不是依赖某次终端输出或口头判断。

AI 辅助流程如何保持责任边界

一次正常修改按照下面的顺序进行：

明确目标与公开边界
        ↓
从最新 main 建立隔离工作区
        ↓
AI 修改 Markdown / 配置 / 应用代码
        ↓
人工检查内容、隐私和业务表述
        ↓
Hugo 构建 + lint + Sites 完整测试
        ↓
Pull Request 与 CI
        ↓
人工合并

AI 可以加快查找、实现和重复验证，但不能替代内容所有者判断哪些事实可以公开，也不能把尚未完成的计划写成已经交付的结果。

发布内容必须对应一个准确提交

每次生产发布都必须对应一个已经合入 main 且通过检查的提交。构建产物、推送到 Sites 的源码状态和保存的 Sites 版本必须使用同一个完整 SHA，不能混用不同提交的源码和产物。

发布后会检查：

1. /version.json 是否返回目标提交；
2. 英文首页、中文首页和博客入口是否正常；
3. 核心文章、静态资源和语言切换是否可用；
4. 页面失败时是否能立即恢复上一已知正常版本。

回滚同样不依赖服务器登录，而是重新部署已经保存并验证过的 Sites 版本。这样发布和回退都有明确且一致的版本依据。

这套方式能证明什么

开源仓库不能证明所有工程能力，但它能公开证明几件重要的事：修改是否聚焦、检查是否完整、上线版本是否可追溯，以及出现问题时是否有明确回退路径。

这也是我希望客户从 fichil.com 看到的工作方式：先建立证据，再限制改动范围，最后用可以复查的结果完成交付。