飞书主文档中心 + RAG 知识库 + AI 工程加速方案

周期: 2026-07-01 至 2027-06-30
目标: 以飞书作为公司主文档中心和知识入口，用 AI 加速产品方案、技术方案、Coding、CI/CD、验证、发布和复盘流程。

1. 总体目标

飞书不只作为“写文档的地方”，而应成为产品、研发、测试、生产、售后和管理的统一知识系统:

所有关键方案、决策、需求、设计、测试、发布、问题复盘都沉淀到飞书。
飞书文档、飞书多维表格、代码仓库、OpenAPI、CI 日志、测试报告、售后案例共同进入 RAG 知识库。
AI 能基于可信上下文生成方案、拆任务、写代码、补测试、分析 CI/CD 失败、生成验证报告和复盘。
人仍然负责业务判断、架构边界、安全审批和发布决策；AI 负责提速、检索、草拟、检查和自动化执行建议。

2. 当前代码资产

当前仓库已有飞书集成雏形:

能力	代码位置	当前用途	后续扩展
飞书 OpenAPI Client	`internal/infra/feishu/client.go`	tenant token、API 调用	文档同步、权限同步、多维表格同步
飞书 Wiki	`internal/infra/feishu/wiki.go`	OTA 版本记录写入 Wiki	主知识库同步、RAG 索引源
飞书多维表格	`internal/infra/feishu/bitable.go`	OTA 版本/任务同步	需求、任务、缺陷、验证矩阵、发布记录
飞书审批	`internal/infra/feishu/approval.go`	OTA 发布审批雏形	PRD/技术方案/发布/灰度审批
飞书 Webhook	`internal/infra/feishu/webhook.go`	通知群消息	AI 摘要、CI 失败、发布风险、质量预警

这说明技术上可以从“OTA 飞书通知”扩展为“公司级知识和流程中枢”。

3. 飞书信息架构

3.1 知识空间

建议建立以下飞书知识空间:

空间	内容	主要使用者
产品中心	PRD、用户故事、竞品、Roadmap、需求评审、版本范围	产品、设计、研发
技术中心	架构、ADR、接口、数据模型、模块设计、技术评审	后端、APP、算法、固件
工程中心	Coding 规范、CI/CD、发布 SOP、环境、故障处理	研发、DevOps、QA
研产测中心	图纸、BOM、MES、物料、证书、固件安全、测试 SOP	研发、生产、测试、质量
内容算法中心	刀路算法、模型管理、材料/刀具/工艺模板、算法评测	算法、产品、内容
售后质量中心	工单、故障码、诊断包、RMA、质量预警、复盘	售后、质量、研发
管理决策中心	周报、月报、指标、OKR、风险清单、决策记录	管理层、负责人

3.2 文档模板

所有关键文档必须模板化，便于 AI 检索和结构化抽取。

模板	必填字段
PRD	背景、目标用户、场景、范围、非范围、交互、接口依赖、验收标准、指标
技术方案	背景、现状、目标、方案、数据模型、接口、风险、兼容性、测试计划
ADR	决策、上下文、候选方案、取舍、影响范围、回滚策略
API 对接	路径、认证、请求、响应、错误码、幂等性、示例、OpenAPI 链接
测试方案	测试范围、环境、数据、用例、自动化脚本、通过标准、风险
发布计划	版本、变更、依赖、灰度、监控、回滚、负责人、审批
故障复盘	时间线、影响、根因、修复、预防、行动项、关联代码/日志
售后案例	用户、设备、版本、故障、诊断包、处理过程、结论、知识沉淀

4. RAG 知识库架构

4.1 数据源

数据源	类型	入库方式	用途
飞书文档/Wiki	非结构化	定时同步 + webhook 增量	产品、技术、售后、SOP 问答
飞书多维表格	结构化	OpenAPI 同步	需求、任务、测试、发布、质量指标
代码仓库	代码/文档	Git webhook + 定时索引	Coding、Review、影响分析
OpenAPI	结构化契约	CI 产物同步	接口问答、契约变更检查
CI/CD 日志	日志	Pipeline 结束后入库摘要	失败诊断、发布风险分析
测试报告	结构化/文本	自动上传	验证报告、质量趋势
设备日志/售后案例	日志/文本	脱敏后入库	售后诊断、质量预警
设计图纸/BOM/MES	结构化/附件	元数据入库，附件按权限索引	研产测追溯、故障归因

4.2 数据处理链路

flowchart LR
    Source["飞书 / 代码 / CI / 测试 / 售后"] --> Collector["采集器"]
    Collector --> ACL["权限与脱敏"]
    ACL --> Chunk["文档解析和分块"]
    Chunk --> Meta["元数据抽取"]
    Meta --> Embed["向量化"]
    Embed --> Store["向量库 + 元数据库"]
    Store --> Retrieve["RAG 检索"]
    Retrieve --> AI["AI 生成"]
    AI --> Writeback["飞书 / PR / CI / 看板回写"]

4.3 元数据标准

每个知识片段至少带以下元数据:

字段	说明
`source_type`	feishu_doc / bitable / code / openapi / ci_log / test_report / support_case
`source_id`	飞书文档 ID、表格记录 ID、commit SHA、CI run ID
`title`	文档或记录标题
`owner`	负责人
`domain`	identity / device / ota / content / support / infra / app / cam
`product_area`	用户中心、研产测、内容中心、售后体系等
`version`	文档版本、软件版本、固件版本或算法版本
`created_at` / `updated_at`	创建和更新时间
`visibility`	public / internal / confidential / restricted
`acl`	可访问用户、部门、角色
`links`	关联 PR、接口、测试、发布、工单

4.4 权限原则

RAG 必须遵循“原文档权限即 AI 权限”:

用户不能通过 AI 看到自己无权访问的飞书文档、代码、BOM、图纸、工单或日志。
机密内容只进入受限索引，不进入通用知识库。
设备日志、售后案例、用户信息入库前必须脱敏。
AI 回答必须带引用来源，不能只给无来源结论。
高风险操作只能生成建议，不自动执行，例如发布、回滚、删除数据、修改证书。

5. AI 加速流程设计

5.1 产品方案加速

阶段	AI 能力	输出
需求输入	汇总飞书反馈、售后工单、社区评论、Roadmap	需求池、痛点聚类
PRD 草拟	基于模板生成背景、用户故事、范围、非范围	PRD 初稿
方案评审	检索历史方案、竞品、技术限制、售后案例	风险清单、待确认问题
任务拆解	从 PRD 生成后端、APP、固件、算法、QA 任务	多维表格任务列表
验收标准	从用户场景生成验收标准和指标	AC、指标口径

5.2 技术方案加速

阶段	AI 能力	输出
现状理解	检索代码、现有 DESIGN.md、OpenAPI、ADR	现状摘要
方案生成	基于模块边界生成技术方案	技术方案初稿
影响分析	找出涉及模块、接口、数据表、配置、测试	影响面清单
风险识别	检查安全、兼容、性能、运维、数据迁移风险	风险与缓解
ADR 生成	从评审结论生成 ADR	决策记录

5.3 Coding 加速

阶段	AI 能力	输出
开发前	根据技术方案生成实现计划和文件清单	任务分解
编码	参考现有代码模式生成代码修改建议	Patch / PR
测试	根据变更生成单测、集成测试和回归脚本	测试用例
Review	检查安全、边界、i18n、OpenAPI、模块依赖	Review findings
文档同步	根据代码 diff 更新飞书文档、OpenAPI、README	文档 PR

Coding 阶段必须遵循仓库已有规则:

用户可见消息走 i18n。
internal/backend 对外接口变化同步 OpenAPI。
store 错误不能直接暴露给客户端。
模块拆分遵循 DESIGN.md、README.md 和边界测试。

5.4 CI/CD 加速

阶段	AI 能力	输出
CI 失败诊断	读取日志、测试失败、最近 diff	根因候选、修复建议
覆盖率分析	识别缺失测试和高风险路径	补测建议
发布前检查	汇总 PR、OpenAPI、测试、风险、回滚方案	发布检查单
灰度监控	分析错误率、延迟、OTA 成功率、售后异常	灰度建议
回滚决策	基于指标和变更影响生成建议	回滚/继续灰度建议

5.5 验证加速

阶段	AI 能力	输出
测试设计	从 PRD/技术方案生成测试矩阵	用例表
自动化生成	生成 API、MQTT、WS、OTA、Pipeline 测试脚本草案	测试脚本
设备验证	汇总设备日志、遥测、OTA 结果	验证报告
售后回归	从历史工单生成回归场景	回归清单
质量复盘	聚合故障、版本、BOM、物料、区域	质量报告

6. 人机协作闭环

建议采用以下流程:

flowchart LR
    A["飞书提出需求"] --> B["AI 生成 PRD 初稿"]
    B --> C["产品评审并定稿"]
    C --> D["AI 生成技术方案初稿"]
    D --> E["研发评审并定稿"]
    E --> F["AI 拆任务到飞书多维表格"]
    F --> G["AI / Codex 辅助 Coding"]
    G --> H["CI / CD 自动验证"]
    H --> I["AI 诊断失败并建议修复"]
    I --> J["QA 验证和发布审批"]
    J --> K["飞书自动沉淀发布记录"]
    K --> L["售后 / 质量数据回流 RAG"]
    L -. 知识更新 .-> A

关键原则:

AI 初稿不等于结论，必须有负责人确认。
飞书文档是主记录，代码仓库是实现记录，CI/CD 是验证记录。
每个需求必须能追溯到 PRD、技术方案、任务、PR、测试、发布和复盘。
所有 AI 输出要保留来源、版本和生成时间，便于审计。

7. 飞书多维表格设计

建议建立以下核心表:

表	关键字段
需求池	需求 ID、来源、优先级、负责人、状态、关联 PRD、关联工单
技术方案	方案 ID、模块、负责人、评审状态、关联 ADR、关联 PR
开发任务	任务 ID、Epic、模块、负责人、分支、PR、状态、风险
测试矩阵	用例 ID、需求 ID、模块、自动化脚本、结果、报告链接
发布计划	版本、范围、灰度策略、审批、监控指标、回滚方案
CI/CD 记录	run ID、commit、失败阶段、根因、修复 PR、耗时
售后质量	case ID、设备、固件、BOM、物料、故障码、根因、闭环状态
知识索引	文档 ID、领域、可见范围、最近同步、RAG 状态、质量评分

8. 系统建设建议

8.1 服务组件

组件	职责
Feishu Connector	同步飞书 Wiki、文档、多维表格、审批和评论
Code Connector	同步 Git diff、PR、commit、README、DESIGN、OpenAPI
CI Connector	同步 CI 日志、测试报告、发布记录
Knowledge Pipeline	分块、脱敏、权限、向量化、元数据入库
RAG Service	检索、重排、引用、上下文组装
AI Workflow Orchestrator	产品/技术/Coding/CI/验证工作流编排
Feishu Bot	飞书内问答、摘要、任务生成、审批提醒
Audit Service	记录 AI 输入、输出、引用、操作者和审批

8.2 技术栈建议

层	建议
文档源	飞书 Wiki、飞书文档、飞书多维表格
元数据存储	MySQL/Postgres
向量库	Milvus、pgvector、OpenSearch Vector 或云厂商向量库
对象存储	MinIO/S3，保存附件、报告、日志、快照
模型网关	统一封装模型供应商、额度、审计、降级
权限	同步飞书 ACL + 内部 RBAC
触发	飞书 webhook、Git webhook、CI webhook、定时任务

9. 落地阶段

阶段	时间	目标	交付
P0	0-1 个月	文档标准化	飞书空间、模板、多维表格、命名规范、权限分层
P1	1-2 个月	RAG MVP	飞书文档 + 仓库 docs + OpenAPI 入库，支持带引用问答
P2	2-3 个月	产品/技术方案助手	PRD/技术方案/ADR 生成和评审清单
P3	3-5 个月	Coding/CI 助手	diff 影响分析、测试建议、CI 失败诊断、飞书通知
P4	5-8 个月	验证/发布助手	测试矩阵、发布检查单、灰度分析、回滚建议
P5	8-12 个月	质量/售后闭环	售后案例 RAG、质量预警、故障复盘自动生成

10. 近期 60 天行动清单

建立飞书主空间和模板: PRD、技术方案、ADR、测试方案、发布计划、故障复盘、售后案例。
用飞书多维表格建立需求池、开发任务、测试矩阵、发布计划和售后质量表。
把当前仓库核心文档映射到飞书目录: docs/project, docs/api-guides, internal/*/DESIGN.md, internal/*/README.md。
扩展现有 internal/infra/feishu，从 OTA 专项通知扩展为通用文档/表格/审批/机器人能力。
建立 RAG MVP: 飞书文档 + 仓库 docs + OpenAPI，支持按权限检索和来源引用。
接入 CI 结果摘要: 失败时自动发飞书消息，并给出 AI 根因候选和修复建议。
选一个真实项目试点: 例如“设备激活服务”或“Pipeline 任务归属改造”，跑通 PRD -> 技术方案 -> Coding -> CI -> 验证 -> 发布复盘。

11. 验收指标

指标	目标
文档覆盖率	关键需求、技术方案、发布、复盘 100% 有飞书主记录
可追溯率	需求到 PR/测试/发布/复盘链路 >= 90%
AI 引用率	AI 回答中带有效来源引用 >= 95%
CI 诊断效率	常见 CI 失败 10 分钟内生成根因候选
方案生成效率	PRD/技术方案初稿时间降低 50%
验证准备效率	测试矩阵和回归清单准备时间降低 40%
知识复用	售后/质量问题复用 Wiki 或历史案例比例逐月提升

12. 风险与控制

风险	影响	控制
飞书文档不标准	RAG 检索质量差	强制模板、元数据、负责人和审核状态
权限泄漏	机密图纸/BOM/工单外泄	ACL 同步、脱敏、受限索引、审计
AI 幻觉	错误方案或错误代码建议	强制引用、置信度、人工审批、高风险禁止自动执行
知识过期	AI 引用旧方案	文档过期提醒、版本字段、最近更新时间排序
流程复杂	团队不愿使用	先做飞书入口和自动化摘要，减少人工填表
工具碎片化	飞书、Git、CI、工单割裂	统一 ID 和链接回写，飞书做主入口

13. 决策建议

飞书作为主文档中心，不替代代码仓库和 CI/CD，而是把它们串成可追溯知识链。
RAG 第一阶段不要追求“全公司所有数据”，先覆盖飞书文档、仓库 docs、OpenAPI、CI 失败日志和售后案例。
AI 先做低风险高频任务: 摘要、草稿、清单、检索、诊断建议；发布、回滚、证书、数据删除等高风险操作必须人工审批。
每个 AI 工作流都要回写飞书，形成持续变好的知识资产。