我如何把 BibleHome 演进为 xHalo-Holy 平台

发表于 分类于 Waline：
从 BibleHome 到 HolyHome，再到 xHalo-Holy 与 xhalo-ai-workflow，这是项目视角，对当前所有核心项目、架构演进、工程问题、解决方案和 AI 辅助编程经验做的一次阶段性复盘。

目录

一、复盘摘要

这次复盘的核心结论很明确：BibleHome → HolyHome → xHalo-Holy 不是一次简单改名，而是一个项目从单一产品愿景，逐步演进成多模块平台体系的过程。

最早我把 BibleHome 设想成一个多语言、多版本圣经阅读、对照与研读平台。这个阶段关注的是内容覆盖、阅读体验、语言版本、经文结构和未来的 AI 研读能力。后来项目改名 HolyHome，含义开始扩大：它不再只是一个 Bible Reader，而是开始承载账号系统、后台管理、AI 能力、语音能力、内容生产和未来社区能力。

再往后，项目进入 xHalo-Holy 阶段。这个阶段最重要的变化，不是 UI 或文案，而是工程边界开始被拆开：xhalo-auth 负责身份，xhalo-admin 负责管理，xhalo-bible-api 负责 Bible 服务层，xhalo-bible-data 负责 Bible 数据底座，xhalo-tts 负责语音能力，hexo-blog 保持现有博客发布，xhalo-blog 承担新内容平台方向，xhalo-ai-workflow 则把 AI 编程和工程执行能力抽象成独立中枢。

到当前阶段，xhalo-ai-workflow 初版已经上线。这是一个重要转折点：项目不再只是“用 AI 写代码”，而是开始把需求分析、任务拆分、模型路由、Runner 执行、测试、部署、日志、回滚和复盘组织成一套更可控的工程流程。

我的阶段性判断是：xHalo 当前真正的瓶颈不再是编码速度，而是边界治理、交付治理和运行治理。 AI 已经显著放大了代码生成速度，但如果没有清晰的模块边界、稳定的数据模型、统一的认证后台、可审计的部署链和可回滚的流程，项目会更快地产生技术债。

二、复盘边界与方法

这份文档基于我此前两次研究报告、项目长期沟通记录、当前 xHalo-Holy 项目记忆和已明确的项目现状重新整理而成。它的目标不是复述每一次小修小改，而是还原主干：项目为什么拆分、各模块承担什么职责、工程过程中暴露了哪些系统性问题、AI 编程如何改变了开发方式，以及下一阶段应该怎么收敛。

本文刻意忽略以下细枝末节：单个页面文案调整、局部颜色修复、按钮高度、个别落地页小组件、短期 UI 细节。这些内容虽然在实际开发中消耗时间，但不是本次复盘的主线。

本文重点关注以下问题：

  1. BibleHome、HolyHome、xHalo-Holy 的产品与架构演进。
  2. 各子项目的职责边界和相互关系。
  3. 开发过程中反复暴露的工程问题。
  4. 已采用或应该采用的解决方案。
  5. AI 智能编程在规划、编码、审查、部署、回滚中的经验。
  6. Cloudflare、Vercel、GitHub、VPS、AI Gateway、Runner、Workflow 之间的基础设施关系。

本文是阶段性架构复盘，不是 commit 级审计报告。GitHub commit、PR、Actions、Cloudflare 部署日志和 VPS 运行日志如果后续统一导出，可以再生成一版更精确的“开发过程审计报告”。本次文档不虚构具体 commit、PR 编号和部署时间戳，只保留已经明确的项目事实和可公开描述的架构判断。

三、主时间线：BibleHome 到 xHalo-Holy

flowchart LR
A["BibleHome"]
--> B["HolyHome"]
--> C["xHalo-Holy"]
--> D["子项目成型"]
--> E["AI Workflow 上线"]

从时间线看，我经历了五个主要阶段。

第一阶段是 BibleHome。这个阶段的关键词是“内容”和“阅读”。我关心的是多语言圣经、多版本对照、经文检索、注释、收藏、未来 RAG 问答和 AI 研读能力。它是整个项目的产品原点。

第二阶段是 HolyHome。这个阶段的关键词是“扩展”。项目从 BibleHome 改名为 HolyHome 后，含义不再局限于 Bible Reader，而是更接近一个以信仰内容为核心的综合平台。账号、后台、语音、AI、社区、内容生产开始进入同一张产品蓝图。

第三阶段是 xHalo-Holy。这个阶段的关键词是“统一”。BibleHome 和 HolyHome 的历史线被统一到 xHalo-Holy 语境下，项目不再以单体方式推进，而是开始围绕业务域和平台能力拆分。

第四阶段是多仓库模块化。xhalo-auth、xhalo-admin、xhalo-bible-api、xhalo-bible-data、xhalo-tts、xhalo-blog 等项目逐步出现。这个阶段解决的是单体耦合问题，但也带来了多仓库、多部署面、多上下文的治理问题。

第五阶段是 AI 工程流程化。xhalo-ai-workflow 初版上线之后，我开始把 AI 编程从“多次聊天生成代码”转向“可编排、可记录、可验证、可回滚的工程流程”。这是当前阶段最重要的工程方向。

四、项目顺序架构分析

4.1 BibleHome：产品原点

BibleHome 是整个项目的原点。它最早的价值主张是：提供多语言、多版本圣经阅读、对照和研读能力。

这个阶段的核心设想包括：

  • 多语言圣经内容覆盖；
  • 多版本 Bible 对照阅读；
  • 经文结构化存储；
  • 注释、收藏、标签、阅读进度；
  • 面向未来的 RAG 问答、AI 辅助研读、AI 语音朗读；
  • 未来社区和内容扩展能力。

从今天回看，BibleHome 最大的价值不是早期页面本身，而是它定义了后续所有模块的语义源头：数据要围绕 Bible 内容组织，搜索要服务经文语义，TTS 可以服务朗读和内容输出，Blog 可以服务内容分发，Auth/Admin 可以服务用户和运营管理。

BibleHome 阶段的问题也很典型：愿景很大，但工程边界还没有形成。如果继续在一个项目内同时推进阅读器、数据、AI、账号、后台、语音和内容系统，后期必然变成难以维护的复合单体。

4.2 HolyHome：品牌与平台愿景扩展

HolyHome 是 BibleHome 的品牌扩展阶段。改名之后，项目的含义变宽：不再只是 Bible Home，而是更接近一个以 Holy 内容、信仰学习和 AI 工具为核心的产品入口。

这一阶段最重要的变化是：我开始把产品从“阅读器”理解为“平台”。平台意味着它需要统一账号、统一数据、统一后台、统一内容生产、统一资产管理和统一 AI 能力接入。

HolyHome 阶段也带来一个后续反复出现的问题：命名迁移和工程迁移并不同步。品牌名变了，代码仓库、文档、邮件模板、域名、后台命名、部署项目名并不会自动跟着变。如果没有一份项目命名和归属表，AI 在后续对话中也容易把 BibleHome、HolyHome、xHalo-Holy、xhalo-bible 混在一起。

我现在对这段历史的判断是：HolyHome 不是废弃名，而是 BibleHome 到 xHalo-Holy 的中间平台化阶段。它解释了为什么后续会出现 auth、admin、tts、blog、ai-workflow 这些看似超出 Bible Reader 的模块。

4.3 xHalo-Holy：统一主项目语境

xHalo-Holy 是当前主项目语境。它把早期 BibleHome、后来的 HolyHome，以及当前 xHalo 系列模块统一到一条主线里。

我现在应该把 xHalo-Holy 理解成一个平台项目，而不是一个单独应用。它包含三类能力：

  1. 业务核心能力：Bible 内容、阅读、检索、研读、AI 增强。
  2. 平台控制能力：用户、权限、后台、日志、配额、邮件、预算。
  3. 输出与自动化能力：TTS、Blog、AI Workflow、内容生产、部署执行。

xHalo-Holy 的正确组织方式不是继续把所有东西塞回一个仓库，而是让每个子项目都有清楚职责，同时通过统一的控制平面和工作流重新连接。

这也是我当前最需要坚持的一条原则：拆分不是为了制造更多仓库，而是为了让每个职责都能独立演进、独立部署、独立审计，同时仍然能被统一治理。

4.4 xhalo-auth：身份与安全边界

xhalo-auth 是统一身份系统。它承担的不是单个站点登录，而是整个 xHalo-Holy 平台的身份基础设施。

它应该负责：

  • 用户注册、登录、退出；
  • 邮箱密码登录；
  • OAuth 登录；
  • Session / Cookie / Token 策略；
  • 用户状态、禁用、删除、恢复；
  • 邮箱验证、重置密码；
  • 登录日志与安全日志；
  • 后续跨业务模块的权限基础。

在早期架构里，认证逻辑如果和主应用、后台、TTS 或 Blog 混在一起，会导致每个模块都复制一套登录和用户状态判断。拆出 xhalo-auth 的意义，是把身份变成平台能力。

这个模块的关键不是“能不能登录”，而是它能否提供稳定契约。比如：用户 ID 是否全局唯一，角色和权限如何表达，跨子域 Cookie 是否启用，前端如何调用 auth 服务，后台如何校验管理员权限，TTS 和 Blog 如何使用同一套用户身份。

我之前已经明确过安全约束：生产环境不应随意放大跨子域 Cookie 的作用域，源站要防止绕过 Cloudflare，只有确认请求来自 Cloudflare 后才信任 cf-connecting-ip。这些约束应该沉淀为 auth 项目的正式安全策略，而不是留在对话记忆里。

4.5 xhalo-admin：平台控制面

xhalo-admin 是 xHalo-Holy 的管理控制面。它最初从用户管理开始，但它不应该停留在 CRUD 后台。

当前 admin 应该承担这些主线能力：

  • 用户管理：注册用户增删禁改查；
  • 数据看板：用户总数、登录、注册、重置密码、邮件发送等核心数据；
  • 邮件管理：默认发送账户配置、邮件模板、邮件日志；
  • AI 管理：模型渠道、模型参数、AI Gateway 路由、调用日志、预算告警；
  • TTS 管理：额度、兑换码、生成任务、资产、分享页；
  • Blog / 内容管理：未来内容生产、发布记录、同步状态；
  • 部署与运行审计：关键发布记录、失败记录、回滚点。

xhalo-admin 的核心价值是把分散在 Cloudflare、Vercel、GitHub、VPS、AI Gateway、邮件服务、数据库里的运行状态统一到一个可见的后台面板里。

如果没有 admin 这个控制面，项目会长期依赖“我记得某个配置在哪儿”“某次部署好像成功了”“某个模型额度应该还够”这类不可靠记忆。后续规模变大后，这会成为比代码 bug 更严重的问题。

4.6 xhalo-bible-api：Bible 服务层

xhalo-bible-api 是 Bible 核心域的服务层。它应该负责把 Bible 数据、语言、版本、章节、经文、搜索、注释、AI 增强能力以稳定接口暴露给前端和其他模块。

它的职责不是简单读取文件，而是表达业务语义：

  • 某个语言有哪些可用版本；
  • 某个版本的章节结构如何；
  • 经文查询如何按 book/chapter/verse 定位；
  • 多版本对照如何返回；
  • 搜索和语义检索如何组合；
  • 用户注释、收藏、历史阅读如何接入；
  • AI 解释和 RAG 结果如何与原文区分；
  • 数据缓存和版本更新如何控制。

xhalo-bible-api 的长期质量取决于接口是否稳定，而不是短期能不能把某个页面跑起来。Bible 内容一旦被多个前端、TTS、AI Workflow、Blog 内容生产复用，API 的契约就会成为整个平台的基础。

4.7 xhalo-bible-data：Bible 数据底座

xhalo-bible-data 是 Bible 内容资产层。它的意义很大：把数据从应用代码中拆出来，变成可版本化、可独立构建、可校验、可发布的静态或半静态数据资源。

这个项目应该重点处理：

  • Bible 原始文本；
  • 语言元数据；
  • 版本元数据；
  • book/chapter/verse 结构；
  • 数据规范化；
  • 静态导出；
  • 搜索索引；
  • 向量化数据；
  • 数据完整性校验；
  • 数据版本升级记录。

我对 xhalo-bible-data 的判断是：它不是普通资源仓库，而是 Bible 核心域的内容基础设施。后续任何 API、阅读器、AI 检索、TTS 朗读、内容引用，都要依赖它的数据质量。

这个项目最需要避免的错误，是把数据处理逻辑散落在多个应用里。正确做法是：数据清洗、结构化、导出、校验和版本记录都尽量在 xhalo-bible-data 内完成，再由 xhalo-bible-api 或前端按稳定格式消费。

4.8 xhalo-blog：新内容平台方向

xhalo-blog 是我从传统 Hexo 博客向 Cloudflare 全家桶内容平台迁移的目标承载体。

它的长期目标不只是“换一个博客框架”，而是构建一个更自动化的内容系统：

  • 在线编辑与发布；
  • Markdown / 数据库存储混合；
  • 自动同步社交平台；
  • 评论、统计、搜索；
  • AI 生成新闻、技术文章、总结；
  • 定时内容生产；
  • GitHub 归档；
  • Cloudflare Pages / Workers / D1 / R2 / Queues 接入。

之前在 xhalo-blog 迁移过程中，多次出现 Next 界面、compat shell、路由、静态导出、部署回滚等问题。这类问题的本质不是某一个组件写错，而是新旧架构过渡期边界不够稳定：哪些逻辑还属于 Hexo，哪些应该进入新平台，哪些应该作为兼容层保留，哪些应该彻底删除。

我现在更合理的策略是：hexo-blog 保持稳定发布，不急着替代；xhalo-blog 作为新内容平台逐步承接在线编辑、AI 生产、社交同步和 Cloudflare 化能力。

4.9 hexo-blog：现有稳定发布面

hexo-blog 是当前可稳定使用的博客发布面。它的价值是成熟、简单、可控，尤其适合发布这种长篇项目复盘文章。

本次交付包严格按照 Hexo 文章组织方式处理：

  • Markdown 主文件使用日期前缀命名；
  • 图片放在与文章同名的资源目录内；
  • front matter 包含标题、日期、标签、分类、封面图；
  • 文章顶部包含封面图嵌入和脚本标签；
  • 配图采用本地相对资源，不再引用 sandbox: 或外部临时链接；
  • Mermaid 图以代码块形式保留，同时提供 PNG/SVG 静态图。

对我来说，hexo-blog 现在不应该承担过多动态能力。它最适合继续作为稳定发布出口，而不是在里面硬塞在线编辑、AI Agent、评论系统和复杂后台。动态能力应该逐步交给 xhalo-blog 或其他模块。

4.10 xhalo-tts：语音能力服务

xhalo-tts 最早可以看作一个独立语音生成工具，但现在它已经更接近一个可复用的语音能力服务。

它当前已经围绕这些方向演进：

  • 单人、双人、多人语音生成；
  • 上传文本，按分行或角色生成；
  • 多语言、多音色、语速、风格选择；
  • 默认 Edge TTS；
  • 超额或付费用户可接 Azure TTS；
  • 未来接入语音克隆、官方内容、科技新闻、公开经典作品；
  • 额度、兑换码、分享页、广场展示；
  • 账号、权限、资产、互动模块化复用。

xhalo-tts 暴露出来的关键工程问题是：语音生成天然是长耗时任务，不适合长期依赖同步请求链。它应该被设计成任务系统：文本切分、队列、状态、失败重试、资产存储、配额扣减、日志记录、分享页生成都要进入统一流程。

从平台角度看，TTS 不只是 tts.xhalo.co 的功能。它可以服务 HolyHome 的经文朗读，服务 Blog 的文章音频，服务 AI Workflow 的内容生成，也可以成为后续付费能力的一部分。

4.11 xhalo-ai-workflow：AI 工程执行层

xhalo-ai-workflow 是当前阶段最重要的新模块。它初版已经上线，标志着我开始把 AI 辅助开发从“对话式提需求”升级为“工程化执行系统”。

它应该承担这些职责：

  • 管理不同业务中的模型配置；
  • 管理模型参数、渠道、价格、预算；
  • 统一通过 Cloudflare AI Gateway 接入模型；
  • 编排 Agent 和 Skill；
  • 调度 Codex、Claude、Gemini、本地 CLI、VPS Runner；
  • 生成开发计划；
  • 执行代码修改；
  • 触发 build/test/lint；
  • 触发 Wrangler / Vercel / GitHub Actions 部署；
  • 汇总日志；
  • 提供人工确认点；
  • 支持失败回滚和复盘归档。

我对这个模块的判断是：它不应该只是一个“AI 调用代理”，而应该成为整个 xHalo 工程体系的执行中枢。未来所有项目的复杂变更，都应该通过类似下面的流程进入：

flowchart LR
R[需求输入] --> P[方案与边界确认]
P --> C[AI 编码或重构]
C --> T[测试与构建]
T --> D[部署预览]
D --> G[人工 Gate]
G --> S[生产发布]
S --> L[日志归档]
L --> B[复盘与回滚点]

这套流程的目标不是让 AI 完全自动替代人，而是让 AI 的执行速度被工程边界、预算、日志、验证和回滚约束住。

五、基础设施与交付架构

当前 xHalo-Holy 的基础设施已经不是单一平台，而是多平台组合：

  • Cloudflare：Workers、Pages、D1、R2、Queues、Vectorize、AI Gateway、Workflows、Turnstile、Access、Tunnel；
  • GitHub：仓库、PR、Issues、Actions、私有项目、自动部署；
  • Vercel：部分前端预览、AI Gateway Custom Providers 补充模型入口；
  • Oracle ARM VPS：Runner、辅助服务、部分源站能力、运维脚本；
  • Hexo/GitHub Pages：现有博客发布面；
  • Cloudflare Email：邮件发送和后续邮件管理方向。

这套组合的优点是灵活，缺点是边界复杂。如果没有一张“平台职责矩阵”，后续会不断出现以下问题：

  • 哪些服务应该放 Cloudflare Workers，哪些还应该留在 VPS；
  • 哪些页面应该 Pages 静态导出，哪些需要动态函数；
  • 哪些数据适合 D1，哪些适合 PostgreSQL，哪些适合 R2；
  • 哪些任务需要 Queues / Workflows，哪些可以同步处理；
  • 哪些部署走 GitHub Actions，哪些走 Wrangler，哪些走 Vercel；
  • 哪些后台入口必须 Access/Tunnel 保护；
  • 哪些预算和配额要进入 admin。

我现在需要把基础设施从“能跑”升级为“能解释、能审计、能回滚”。每个生产项目都应该有一份部署台账，至少包含：代码仓库、生产域名、预览域名、构建命令、部署方式、环境变量、绑定资源、日志入口、回滚方式、负责人和最近一次验证记录。

六、开发阶段问题、解决方案与反思

6.1 问题一：项目命名和边界迁移不同步

BibleHome、HolyHome、xHalo-Holy、xhalo-bible 之间的关系如果只靠记忆维持，后续一定会混乱。命名迁移不只是改 logo 或标题，而是要同步仓库、README、部署项目、域名、邮件模板、后台菜单和 AI 项目记忆。

解决方案是建立《xHalo 项目命名与归属表》。每个项目必须明确：历史名称、当前名称、仓库名、生产域名、部署平台、所属业务域、是否仍维护、是否被替代。

6.2 问题二：早期单体愿景过宽

BibleHome 的愿景一开始就包含阅读、数据、AI、语音、社区、后台和内容生产。如果不拆分，很快就会变成一个过宽的单体项目。

解决方案是按职责拆分，而不是按页面拆分。xhalo-bible-data 负责数据，xhalo-bible-api 负责服务，xhalo-auth 负责身份，xhalo-admin 负责治理，xhalo-tts 负责语音，xhalo-blog 负责内容平台，xhalo-ai-workflow 负责 AI 执行。

6.3 问题三：AI 改代码速度过快，复盘证据不足

AI 智能编程让计划、代码、重构、文档生成速度显著提升，但也放大了一个问题：如果没有强制记录 diff 范围、测试结果、部署输出和回滚点，很快就会出现“改了很多，但不知道哪一步真正造成问题”的状态。

解决方案是把 AI 开发改成工单式流程：每次只允许明确范围的变更；每次变更要有验收标准；每次部署要记录输出；每次失败要保留失败原因；每次回滚要写明回滚点。

6.4 问题四：反复小修导致架构主线被打断

过去在 UI、兼容层、Next 静态导出、浅色主题、路由兼容等问题上，有过多轮“修复—失败—回滚—再修复”。这些问题表面是代码问题，本质是架构边界没有冻结。

解决方案是：在进入开发前先冻结架构目标。比如明确是否保留 compat shell，是否迁移 Next，是否静态导出，是否删除历史单页兼容路由。架构没有冻结前，AI 不应该跨文件大范围修改。

6.5 问题五：控制平面出现得偏晚

Auth 和 Admin 是平台项目的控制面，如果出现太晚，其他模块会先各自实现用户、配置、日志和额度，后续再统一会成本更高。

解决方案是把 admin 的范围从用户管理扩展为平台治理：用户、邮件、模型、配额、预算、日志、部署、TTS 资产、AI 调用都应该进入统一视图。

6.6 问题六：异步任务和长任务治理不足

TTS 生成、AI 内容生产、新闻汇总、批量数据处理、部署验证，都不是简单同步请求。它们需要任务状态、队列、重试、超时、日志和失败恢复。

解决方案是把长任务纳入 Queues / Workflows / Runner 体系。尤其是 xhalo-ai-workflow，必须把人工确认、预算检查和回滚点作为流程节点，而不是事后补救。

七、AI 智能编程经验总结

这段时间最大的经验是：AI 编程不是让模型无限写代码，而是让模型在我定义好的边界内做高强度执行。

我在不同阶段使用 AI 的方式可以分成几类：

7.1 ChatGPT 更适合做长期记忆、架构复盘和方案整理

ChatGPT 在这个项目中的价值主要是：恢复长期上下文、整理架构关系、生成 Codex Prompt、做阶段复盘、比较方案、总结经验。它适合承担“项目大脑”和“文档分析层”，但不应该被当成直接掌握 GitHub 事实的工具。项目真实状态仍然要回到代码、PR 和部署日志。

7.2 Codex 更适合执行明确边界的开发任务

Codex 的价值在于实际改代码，但前提是任务边界必须清楚。给 Codex 的提示词不能只是“优化一下”，而应该包含：目标、禁止改动范围、文件路径、验收标准、测试命令、失败时停止条件、不得引入的兼容层、是否允许迁移架构。

我过去反复遇到的小版本返工，很多不是模型能力不足，而是提示词没有严格限制改动范围，或者任务本身混合了架构迁移、UI 调整、兼容清理和部署修复。

7.3 Claude / Gemini 更适合辅助长文档、审查和替代视角

Claude 和 Gemini 在长文档、代码审查、方案对比和多轮整理上有价值。它们适合做第二意见，尤其适合在 Codex 执行前检查方案是否过宽、是否混入多目标、是否会破坏现有架构。

7.4 AI Gateway 应成为模型接入统一入口

当前实际情况是：模型主要通过 Cloudflare AI Gateway 统一接入，Vercel 的 Custom Providers 只是补充。这个方向是对的。未来不应该让各个业务模块直接散装调用模型，而应该把模型渠道、模型名、价格、限额、fallback、日志和预算都放到 xhalo-ai-workflow 和 xhalo-admin 中管理。

7.5 AI 开发流程必须有人工 Gate

我现在最明确的经验是：AI 可以加速计划和执行，但生产发布不能完全自动。至少以下节点必须保留人工确认：

  • 架构边界变更；
  • 数据库迁移；
  • 认证和权限修改；
  • 生产环境变量变更；
  • Cloudflare / Vercel / VPS 生产部署；
  • 删除兼容代码；
  • 预算和模型路由变更；
  • 大规模重构。

AI 编程真正成熟的标志，不是“无人值守自动改完”，而是“每一步都有边界、证据和回滚”。

八、下一阶段路线图

8.1 短期：先做项目事实归档

短期最重要的是把项目记忆固化成项目事实。需要为所有核心仓库建立统一表格：

项目 当前角色 历史关系 仓库 部署平台 状态
BibleHome 历史产品原点 已演进为 HolyHome / xHalo-Holy 历史仓库或文档归档 归档 历史阶段
HolyHome 中间品牌与平台愿景 已并入 xHalo-Holy 主语境 历史仓库或旧模块 归档 / 迁移 过渡阶段
xHalo-Holy 当前主项目语境 继承 BibleHome / HolyHome 主项目仓库 Cloudflare / GitHub 当前主线
xhalo-auth 身份系统 从主平台拆分 独立仓库 VPS / Worker 视当前实现 当前主线
xhalo-admin 管理后台 从主平台拆分 独立仓库 Cloudflare / GitHub 当前主线
xhalo-bible-api Bible 服务层 从 Bible/Holy 核心拆分 独立仓库 Cloudflare / API 服务 当前主线
xhalo-bible-data Bible 数据底座 从 Bible/Holy 核心拆分 独立仓库 Cloudflare / GitHub 当前主线
hexo-blog 现有博客发布面 存量发布系统 独立仓库 GitHub Pages / Cloudflare 视当前配置 稳定发布面
xhalo-blog 新内容平台 Hexo 之后的目标平台 独立仓库 Cloudflare 全家桶方向 演进中
xhalo-tts 语音能力服务 从工具演进为能力模块 独立仓库 Cloudflare Worker / Pages 当前业务模块
xhalo-ai-workflow AI 工程执行层 新增平台中枢 独立仓库 Cloudflare / Runner 初版已上线

8.2 中期：收敛控制平面

中期目标是让 xhalo-auth 和 xhalo-admin 真正成为控制平面。所有业务模块都应接入统一用户、权限、配额、日志、预算和模型配置。

具体包括：

  • 统一用户 ID 和角色模型；
  • 统一管理员权限；
  • 统一邮件模板和邮件日志；
  • 统一 AI 模型配置；
  • 统一 TTS 配额和资产管理；
  • 统一部署日志和操作审计；
  • 统一预算告警和用量看板。

8.3 长期：让 xhalo-ai-workflow 成为工程中枢

长期目标是把 xhalo-ai-workflow 做成真正的工程执行中枢。它不仅要能调用模型，还要能驱动完整开发链路：

flowchart TD
A[需求进入] --> B[项目识别]
B --> C[读取项目契约]
C --> D[生成开发计划]
D --> E[人工确认]
E --> F[AI/Codex/Runner 执行]
F --> G[测试与构建]
G --> H[预览部署]
H --> I[人工验收]
I --> J[生产发布]
J --> K[日志归档]
K --> L[复盘与知识沉淀]

未来我真正要优化的不是“让 AI 更快写代码”，而是让 AI 的速度始终受项目契约、预算、验证和回滚机制约束。

九、结语

这次复盘让我更清楚地看到，xHalo-Holy 的主线已经不再是一个 Bible Reader，也不只是几个工具项目。它正在变成一个由内容、账号、后台、语音、博客、AI Workflow 和基础设施组成的平台体系。

过去的问题也很清楚：愿景扩展很快，AI 编码也很快，但边界、证据、部署台账、预算治理和回滚机制没有同等速度跟上。这个矛盾如果不解决，项目越往后越容易陷入“功能很多、上下文很散、修复反复、上线不稳”的状态。

我下一阶段要坚持三条原则：

  1. 先定义边界，再写代码。 任何跨项目变更必须先明确项目职责和禁止修改范围。
  2. 先建立证据，再判断完成。 不能只靠“任务完成”的对话结论，必须有测试、构建、部署和日志证据。
  3. 先收敛控制面，再扩张业务面。 Auth、Admin、AI Workflow、预算、日志和回滚要先稳定，业务模块再继续扩展。

如果把整个阶段压缩成一句话，我会这样总结：

xHalo-Holy 当前真正要建设的，不是更多单点功能，而是一套能支撑长期迭代的工程操作系统。

附录：参考资料与发布包说明

A. 官方资料参考

以下资料用于核对平台能力和发布规范，具体项目状态仍以我自己的 GitHub 仓库、Cloudflare 部署、VPS 日志和后台数据为准。