飞书发布同步机制

状态：SUPERSEDED（2026-04-17 起） 本页描述的"canonical wiki → 飞书"发布链路已被 Docs-as-Code 发布架构 取代。 飞书在新架构中降格为可选浏览渠道，不再是企业知识的发布真相源。 替换原因见 Docs-as-Code over Feishu Publishing。 本页保留作为历史对照与回滚参考，不再作为活动制度。

这是一页发布机制页，原本负责定义 canonical wiki 如何进入飞书发布层。
它不负责证明飞书为什么应该是发布层；该判断应以下列页面为准： Feishu as Publishing Layer（已 superseded）、飞书知识库。

核心问题

既然企业团队真正共享的是飞书知识库，就需要定义：

canonical wiki 里的页面，如何被稳定地发布和同步到飞书。

正确关系

推荐关系是：

raw source
-> llm-wiki compile
-> canonical wiki
-> review gate
-> Feishu publish

也就是说：

• wiki/ 是编译层 canonical
• 飞书知识库是发布层

同步时机

1. 首次发布

当某页第一次通过 review gate 后，发布到飞书。

2. 增量更新

当 canonical wiki 页有结构性更新时，再同步到飞书。

3. 不发布的情况

以下内容不应该直接同步：

• 草稿页
• 被 reject 的候选页
• 仅供内部编译参考的 source summary
• 纯治理页（如某些 lint 中间结果）

推荐同步策略

Strategy A：手动审批后发布

最稳，最适合企业早期。

Strategy B：部分自动同步

适合已经稳定的知识类型：

• SOP
• 决策页
• 稳定规则页

Strategy C：全自动同步

不推荐作为初始方案。
因为一旦 canonical 页质量不稳，会把噪音同步到飞书。

发布页建议类型

优先同步这些页：

• SOP
• 决策
• 协作规则
• 系统说明
• 团队方法论

最终规则

飞书是企业版知识的发布层，只有通过 review gate 的 canonical 页，才应该被同步进去。

关联

• Docs-as-Code 发布架构 — 取代本页的活动发布架构
• Docs-as-Code over Feishu Publishing — 替换原因
• 企业版Review Gate机制
• 企业版自动化运行架构
• Feishu as Publishing Layer — 已 superseded