Docs-as-Code over Feishu Publishing
这是一页架构判断页，负责说明为什么把发布层从飞书切换到 docs-as-code。 它不负责描述新架构的具体实现，那应以下列页面为准： Docs-as-Code 发布架构、GitHub、VitePress。 （注：原文写"Gitee"，后改用 GitHub，详见 GitHub 实体页。）
What It Is
这页解释一个架构决策：企业知识发布层不再是飞书，而是 GitHub + VitePress on ECS。
它取代 Feishu as Publishing Layer 中"飞书=发布层"的判断。
Core Answer
飞书在 markdown 渲染上存在三类不可消除的损耗，已通过 Slice 3 实证验证：
- frontmatter 被压成单行
<span class="wikilink-dead" title="未找到: wikilink" style="color:#c33;border-bottom:1px dashed #c33">wikilink</span>不渲染、不可点击- 多行 blockquote 被合并成一行
虽然可以用预处理器（slice3v2_preprocess.py）把视觉效果修正，但飞书内部不是 markdown-first 系统，markdown 始终是 lossy 的进出。一旦把飞书当作真相源，整个知识链就被这套有损管道绑死。
docs-as-code 把真相源放回纯 markdown 仓库，飞书可以保留作为可选浏览渠道，但不再决定知识的标准形态。
Why It Matters
| 维度 | 飞书发布层 | Docs-as-Code |
|---|---|---|
| 真相源 | 飞书云端 | GitHub git 仓（daishiyu1991-hub/wiki-vault） |
| markdown 保真 | lossy（需预处理） | 100% 无损 |
| Hermes 阅读方式 | 飞书 OpenAPI（限流、token） | 直接挂载文件系统（零延迟） |
| diff / 历史 / PR | 弱 | git 原生 |
| wikilink 支持 | 不渲染 | VitePress 插件原生支持 |
| 团队浏览 | 飞书 App | https://wiki.86lux.net |
| 离线可用 | 否 | 仓库可 clone 到本地 |
| 锁定供应商 | 飞书 | 无（git 是开放标准） |
Why It Doesn't Mean "Kill Feishu"
飞书在团队协作中仍承担：
- 即时通讯
- 文档评论与协作（非长期知识）
- 视频会议
它从"企业知识真相源"降格为"团队工作平台"。这是更准确的定位，不是淘汰。
What Triggers This Pivot
直接触发：Slice 3 验证发现飞书 markdown 渲染缺陷无法通过预处理器根治。
更深层原因：
- 团队的真实消费者除了人，还有 5 个 Hermes Agent
- Agent 优先需要"可机读、保真、稳定"的知识源
- 飞书优化的是人类阅读体验，不是 agent 消费
把飞书当发布层，相当于让 agent 也走一遍人类 UI，是错配。
Final Rule
企业知识的真相源必须是 markdown + git；任何其他形式（飞书、Notion、PDF）都只是这个真相源的渲染或导出。
Related Pages
- Docs-as-Code 发布架构
- GitHub — 当前真相源
- Gitee — 原选型，已 SUPERSEDED
- VitePress
- Git LFS — 二进制资产管理
- wikilink 插件 — wikilink 渲染机制
- vault-publish — 本地发布工作流
- 飞书知识库 — 已被本架构降格为可选浏览渠道
- Feishu as Publishing Layer — 已 superseded
- Wiki-first vs RAG-first Retrieval Strategy — 本判断使 wiki-first 更可行