Lark / 飞书使用边界
目的
定义 Lark/飞书在工程操作系统中的适用位置。
Lark 适合作为一体化协作套件：聊天、文档、知识库、会议、审批、多维表格流程和机器人。它不应该成为代码、CI、生产指标或密钥的事实来源。
推荐使用场景
| 工程操作系统领域 | 能否用 Lark | 推荐 Lark 能力 | 说明 |
|---|---|---|---|
| 日常协作 | 可以 | Messenger 群聊 | 如果组织统一使用 Lark，可替代 Slack。 |
| 会议纪要 | 可以 | Lark Docs | 适合 planning、demo、retro 纪要。 |
| 工程手册 | 可以 | Lark Wiki | 适合团队级 handbook；代码邻近文档仍建议放 repo。 |
| 工作入口 | 可以，但有限制 | Lark Base 表单 / Workflow / Approval | 适合 intake 表单；被接受的工作要同步到 Linear/Jira/GitHub Issues。 |
| 轻量审批 | 可以 | Lark Approval | 适合产品、发布、权限、事故审批记录。 |
| 发布通知 | 可以 | Lark bot / 交互卡片 | GitHub Actions 或发布服务推送到 Lark。 |
| 事故房间 | 可以 | 专用 Lark 群 + 置顶文档 | 事故事实还要沉淀为 postmortem 和 action items。 |
| 告警通知 | 可以 | 自定义机器人 webhook | 可观测性事实仍在 Sentry/Grafana/Datadog。 |
| 状态看板 | 部分可以 | Base 表格 / Docs summary | 适合人工摘要，不是 metrics backend。 |
| 自动化触发 | 可以 | Base Workflow / webhook trigger | 适合低风险流程路由。 |
| Bot 命令入口 | 可以 | Lark Open Platform bot | 适合 /release status、/incident open、/task intake。 |
| 源码管理 | 不建议 | 使用 GitHub/GitLab | 不要用 Lark 保存代码事实。 |
| CI/CD | 不建议 | 使用 GitHub Actions/GitLab CI/Buildkite | Lark 只接收通知。 |
| 生产可观测性 | 不建议 | 使用 Sentry/Grafana/Datadog | Lark 是通知和协作表面。 |
| 密钥管理 | 不建议 | 使用 1Password/Vault/cloud secret manager | 不要把真实 secret 粘贴到 Lark 文档或群聊。 |
| 审计事实来源 | 部分可以 | 审批记录和群聊记录 | 关键审计应写入系统日志和 DB audit table。 |
推荐 Lark 流程
1. 工作入口
Lark Base 表单
-> triage owner 评审
-> 接受后创建 Linear/Jira/GitHub issue
-> 工程工作进入正式 tracker
适合：
- 客户 bug 反馈；
- 内部功能请求；
- 运维请求；
三角色在 Lark 中怎么用
| 角色 | Lark 适合承载 | 不应该只留在 Lark |
|---|---|---|
| 产品负责人 | 需求讨论、验收通知、用户反馈摘要 | 最终需求字段和验收结论 |
| 技术负责人 | 风险提醒、review 请求、发布通知 | PR approval、CI 结果、架构决策 |
| 平台 / 资深工程师 | 告警通知、发布卡片、排障协作 | 监控事实、日志、secret、审计记录 |
- 权限请求；
- 事故 action 收集。
不要让只存在于 Base 里的记录变成工程工作。
2. 发布通知
GitHub Actions release job
-> webhook 到内部服务或 Lark bot
-> Lark 发布群收到卡片：
version、owner、commit、PRs、migration status、rollback、dashboard links
Lark 展示发布状态，但不判断 CI 是否通过。GitHub Actions 仍然是 CI 事实来源。
3. 事故管理
Sentry/Grafana 告警触发
-> Lark 事故群创建或通知
-> 置顶 Lark Doc 记录 timeline
-> 缓解后创建 Linear/Jira action items
-> postmortem 存入文档系统并链接到 issue tracker
Lark 很适合实时协作。长期事故记录不能只留在聊天里。
4. 审批流
适合用 Lark Approval 的表单：
- 生产发布审批；
- 数据库 migration 审批；
- 客户数据导出审批；
- 临时生产访问；
- 安全例外；
- 采购或新增工具。
对技术变更，Lark Approval 只能补充，不能替代：
- GitHub PR approval；
- CODEOWNERS；
- CI required checks；
- migration review。
5. 后续 Agent 协作平台通知
这一节在人类通知、审批和事实来源边界稳定后再看。
Agent 协作平台可以把 Lark 作为人类通知和命令入口：
TaskRun started
TaskRun blocked
Approval requested
Artifact ready
PR created
Run failed
Budget threshold reached
有用的 Lark bot 动作：
- approve / reject 低风险动作；
- 打开 run room；
- 指派 reviewer；
- 请求 retry；
- 从失败发布创建 incident。
风险动作应该跳回 Agent 协作平台或 GitHub 查看完整 evidence。
Lark 不应该负责什么
不要把 Lark 当作这些系统的主事实来源：
- Git history。
- Pull request review truth。
- CI status。
- 生产 metrics 和 traces。
- Secret storage。
- Database audit logs。
- 自动化或 Agent runtime logs。
- 长期 artifact / 产物存储。
规则：
Lark 可以通知、协作、审批、汇总。
事实来源仍应留在专门系统。
集成模式
推荐架构：
GitHub / CI / Observability / 后续 Agent control plane
-> internal webhook router
-> Lark bot message or card
-> user action in Lark
-> internal API verifies permission
-> source-of-truth system updates
不要把真实生产凭证直接放进随机自动化 workflow。用内部代理或 integration service 持有 scoped credentials，并写审计。
实用设置
| 需要 | Lark 设置 |
|---|---|
| Bot 通知 | 群里的自定义机器人 webhook |
| 富交互 | Lark Open Platform app bot |
| Intake 表单 | Lark Base 或 Approval |
| Workflow 触发 | Base Workflow 接收 Lark 消息或 webhook |
| 文档 | Lark Docs/Wiki space |
| 事故房间 | 带 bot 和置顶文档的事故群模板 |
后续 Agent 就绪要求
在 Lark 中暴露 Agent 或协作平台动作前：
- 每个动作必须映射到真实 backend API。
- Backend API 必须重新校验权限。
- Lark 用户身份必须映射到内部用户身份。
- Approval 动作必须包含 evidence 链接。
- 风险动作必须要求二次确认，或使用签名审批流。
- Bot 消息必须避免 secret 和敏感日志。
- 所有动作必须写入 audit log。
下一步阅读
读完或填完这份文档后，通常继续看：
- 14-任务联动-task-linkage.md：明确飞书边界后，继续看正式事实如何联动。