Where Review Happens and How Bots Trigger It
Core Answer
企业版系统里，审批最适合发生在 Multica，而不是直接发生在 wiki 或飞书里。
同时：
bot 可以自动触发审批，但不应该默认自动批准审批。
Why Review Should Happen in Multica
Multica 已经天然具备这些对象：
- Issue
- Comment
- Chat
- Assignee
- Runtime
- Actor
所以它最适合承担：
- 候选知识任务的创建
- reviewer 指派
- 审批状态流转
- 审批记录留痕
换句话说：
wiki/适合存知识飞书适合发布和阅读Multica最适合承载审批工作流
Recommended Flow
text
Task output
-> candidate knowledge bundle
-> wiki-compile / review issue in Multica
-> human review
-> canonical wiki
-> Feishu publishWhat Bots Should Do
bot 应该自动做这些事：
- 识别高价值候选知识
- 创建
wiki-compileIssue - 生成审批摘要
- 指派 reviewer
- 根据审批结果执行下一步动作
What Bots Should Not Do by Default
bot 默认不应该自动做这些事：
- 自动批准长期知识
- 自动绕过 review gate
- 自动把草稿直接变成 canonical wiki
因为这样会破坏企业知识库的可信度。
Recommended Approval Outcomes
建议只保留 3 个审批结果：
- Approve — 进入 canonical wiki 并可发布到飞书
- Revise — 返回修改后重新提交
- Reject — 不进入 wiki，保留在 Chat / Comment /
mem0即可
Why This Matters
如果没有审批：
- 噪音会进入 wiki
- 草稿会变成正式知识
- 团队会慢慢不信任知识库
所以审批的价值不是“拖慢系统”，而是：
保护 canonical knowledge 的可信度。
Final Rule
bot 负责发现和路由候选知识，人类负责批准长期知识是否进入 canonical 层。