JetWave 组织协作 AI 应用 · 技术方案

项	内容
日期	2026-09-09
状态	长期蓝图（选型已定：组装，不自研平台，不整仓采用单一 GitHub 项目）
产品名（暂）	Calibra：组织级「主张校准」AI 应用
第一战场	扳机弹簧 CAPA / 寿命 / 1# 根因 / 2# 评审
后续战场	故障码口径、堵转案例、航行日志分析结论，凡是「数字必须可复算」的分析
近端配套	`COLLAB_CALIBRATION_CLOUD_PLAN.md`（本周最小动作，不冲突）

0. 先回答你的三个选项

选项	结论
用 GitHub 上的某个项目当产品？	不当产品。 Dify / FastGPT / OpenHands / n8n 都只覆盖一层通用能力。没有一个理解「锁定主张 + 脚本复算 + CAPA 审批」。整仓二次开发会把你们锁进别人的产品路线。
自己从零搞一套？	不搞平台。聊天、模型网关、工作流画布、编码沙箱、向量库都是已有商品。自研这些是 12–24 个月的平台团队，不是分析协作。
输出一套技术方案？	要。就是本文。长期正确做法是组装：商品层采用开源/云服务，领域层自己写薄，记忆层必须是你们的仓库。

一句话：GitHub 项目当零件，自己只造「主张 + 门禁 + 飞书入口」这层薄应用，记忆永远在 git。

近端（本周）仍然先把主张和合页搬进仓库。没有记忆层，上面任何 AI 应用都是聊天玩具。

1. 这个应用到底是什么

不是「把报告丢进知识库，大家问 AI」。
也不是「再做一个 Cursor」。
也不是航行日志生产平台（TLA / Calibrator 已有）。

它是一个 长期在线的组织操作系统，专门处理这一类工作：

有人（或 AI）提出一条技术主张 → 用脚本和证据复算 → 对口角色批准或驳回 → 合页和对外报告自动跟上 → 全程可审计。

1.1 必须成立的产品特性

特性	为什么是硬需求
多用户、浏览器即可	结构 / 品质 / 测试不能被要求每人都装 IDE
云端常驻	校准会、飞书追问、Agent 复算不绑某台电脑
单一事实源	93,000 / 4,027 只能有一份；飞书和 AI 都是投影
写操作可门禁	改锁定主张必须带脚本输出，否则拒绝
角色校准	品质只批根因格子，结构只批应力，测试只批台架
安全件审计	伤人 CAPA：谁改、何时改、依据哪次复算
可扩展到下一题	下一场分析不应再搭一套系统

1.2 明确不是什么

不是	已有归属
航行日志增量分析	`trajectory-log-analyzer`
轨迹字段校准服务	`trajectory-calibrator`（已有 HTTP / MCP）
IDE 里写代码	Cursor 桌面端继续用
公司知识库百科	飞书云文档 / wiki（只链主张，不抄数字）

2. 买、组装、自研：怎么切

┌─────────────────────────────────────────────────────────────┐
│  入口层（采用）  飞书机器人 · 已发布合页 · 可选 Dify 问答     │
├─────────────────────────────────────────────────────────────┤
│  领域层（自研，薄）  主张 · 证据 · 审批 · 数字对账 · 发布     │
├─────────────────────────────────────────────────────────────┤
│  工人层（采用）  编码 Agent：Cursor Cloud / OpenHands         │
│                 工作流：n8n 或飞书自动化                      │
├─────────────────────────────────────────────────────────────┤
│  记忆层（必须自持）  Git 仓：claims / scripts / reports / hub │
└─────────────────────────────────────────────────────────────┘

层	策略	自己写什么	严禁自己写什么
入口	采用	飞书卡片模板、合页 TOC	通用 Chat UI、模型市场
领域	自研	主张 schema、审批状态机、对账 CI、发布流水线	—
工人	采用	包装你们脚本的 MCP / Skill	Agent 框架、Docker 沙箱、SWE-bench 竞赛
记忆	自持	仓结构、权限、分支保护	用向量库当底稿

判断标准只有一条：这层会不会随 LLM 产品半年改一次？
会 → 采用。
是你们业务不变的（主张、复算、审批）→ 自研。

3. GitHub / 开源项目地图

只列和本产品有关的。星多不代表能当底座。

3.1 采用（当零件）

项目	地址	在本产品里干什么	不干什么
Dify	langgenius/dify	Phase 2：给非研发做「只读问答」和简单工作流，接国内模型	不当事实源；不让它改 93,000
n8n	n8n-io/n8n	飞书事件 → 调领域 API → 通知对口人	不在节点里口算应力
Cursor 桌面 + 云效 MCP	云效 MCP	国内主工人：本机改仓、创 Codeup 分支 / MR	对话不当记忆
OpenHands（阿里云自托管）	OpenHands	Phase 2 云端工人，打内网 Codeup	不当知识库
Cursor Cloud Agent	文档	海外备选，国内主路不用	对话不当记忆
飞书开放平台	官方	组织入口、身份、日历、审批通知	文档不当底稿

Dify 社区活跃、可自托管或云，适合「从原型到内部问答」。它解决的是 LLM 应用运营，不是安全件主张治理。
OpenHands 1.0（2026-09）把编码 Agent 做成可自托管的 GUI/CLI/SDK，适合「工人层备胎」，不适合当组织入口。

3.2 只借鉴接口，不部署当底座

项目	借鉴什么	为什么不当底座
FastGPT / RAGFlow	文档切片、引用溯源	RAG 会把 1,982 和 4,027 一起检出来，模型选错数；底稿必须是主张 JSON
LangGraph / CrewAI	图状编排、人在环	库不是产品；自研编排会变成第二平台
Continue	IDE 内 Agent	解决不了品质同事的浏览器校准
Plane / Linear 开源	Issue 状态机	12 条主张用 git + 一张表就够，上看板是以后的事
EDDI 等「企业编排器」	审计、OIDC	重，且不懂复算门禁；权限用飞书即可

3.3 明确不要整仓二次开发

不要 Fork Dify 往里塞 CAPA 状态机。升级即冲突。
不要用「全公司一个 RAG」替代脚本复算。
不要为了用 GitHub Actions 生态而把 TLA 生产仓 迁走；生产和协作可以两个远程。

3.4 代码托管：国内团队不定 GitLab.com / GitHub.com

gitlab.com、GitHub.com 都不作为主协作仓。 宿主在海外：访问不稳、账号和账单不在国内、伤人 CAPA 出镜要过合规。极狐 GitLab 是国内发行版，Cursor 官方不对接，不能当成「Cloud Agent + GitLab」。阿里云 Codeup 长得像 GitLab，也不是 Cursor 能 OAuth 的 GitLab 实例。

因此：不要为了用 Cursor Cloud Agent，把记忆层迁到海外 Git。 Cloud Agent 是海外工人，不是国内组织协作的前提。

国内主拓扑：

Codeup 私有仓     记忆：主张 / 脚本 / 报告 / 合页
飞书              人的入口：链接、审批、催办
OSS / 内网合页    阅读面
Cursor 桌面       工人（本机，走国内网 git push Codeup）
云效 DevOps MCP   可选：桌面 Agent 创分支、提 MR（官方支持接 Cursor）
阿里云 OpenHands  Phase 2 才上的云端工人，打内网 Codeup

组合	国内是否合适
Codeup + 飞书 + Cursor 桌面	主路
Codeup + 云效 MCP + Cursor 桌面	主路加强，仍不把数字交给海外 VM
Codeup + 阿里云自托管 OpenHands	Phase 2 云端工人
Cursor Cloud Agent + GitHub / gitlab.com	放弃主路；网络和数据都在海外
Cursor Cloud Agent + Codeup	接不上
Cursor Cloud Agent + 极狐	接不上

本周把分析报告推进现有 Codeup 即可。不要把 .env、OSS 密钥、原始 8,904 条曲线推进协作仓。

4. 目标架构

4.1 逻辑视图

品质/结构/测试          你 / 研发                 Agent
    │                      │                      │
    ▼                      ▼                      ▼
飞书机器人/卡片      Cursor 桌面 + Codeup MR     阿里云 OpenHands（Phase 2）
    │                      │                      │
    └──────────┬───────────┴──────────┬───────────┘
               ▼                      ▼
        领域服务 Calibra API     编码工人（只开 PR）
               │                      │
               ▼                      ▼
        claims 状态机            复算脚本 + 重生 HTML
               │                      │
               └──────────┬───────────┘
                          ▼
                 Git（主张 / 证据 / 报告 / 合页）
                          │
                          ▼
                 静态发布 TRIGGER_SPRING_HUB

4.2 领域服务（唯一必须自研的后端）

一个小服务即可，建议独立小仓或本仓 services/calibra/。语言不关键：团队熟 Python 就 FastAPI。

模块	职责
`claims`	主张 CRUD；状态 `open / proposed / locked / disputed`
`evidence`	登记脚本输出 JSON、材质书、KISSsoft PDF 的 git 路径与哈希
`proposals`	一次提案 = 旧值 + 新值 + 复算 job id + 证据
`reviews`	按角色必批；锁定主张需对口人
`ledger`	对账：报告/合页里的锁定数字 == claims JSON
`publish`	合入后触发合页静态发布
`audit`	谁在何时批准了哪条主张

不存第二份数字。 主张的权威文件在 git；API 读仓或读 CI 产物。数据库只存工作流状态、评论、飞书 message id。

4.3 主张 schema（第一版就写死）

{
  "id": "CLAIM-A1",
  "title": "A 档型式试验",
  "value": "93000",
  "unit": "cycles",
  "status": "locked",
  "owner": "test",
  "recompute": "analysis/tools/spring_warranty.py",
  "evidence": ["analysis/reports/remote_lifetime/spring_warranty_summary.json"],
  "surfaces": ["EF01_TRIGGER_LIFETIME_CAPA.md#2.3", "TRIGGER_SPRING_HUB.html#capa/s7"]
}

规则：改 value 必须带一次成功的 recompute 运行记录。没有记录，API 返回 409，Agent 同样被拒。

4.4 工人怎么接（不要自研 Agent 环）

Phase 1 首选 Cursor 桌面（本机跑脚本，推 Codeup，开 MR）。可加云效 DevOps MCP 让 Agent 自己创分支、提合并请求。
任务提示词例如：

对 CLAIM-S1 用 spring_rc2000_rca.py 复算，禁止改其它锁定主张，开 Codeup MR。

Phase 2 云端工人：阿里云自托管 OpenHands，同一套提示词，打内网 Codeup。
再往后：飞书里「@校准助手复算 1#」→ n8n → Calibra API → 桌面任务或 OpenHands。

Cursor Cloud Agent / SDK 不作为国内主路；没有海外 Git 仓就不要接。

4.5 对账门禁（比再做一个前端更重要）

CI（Codeup Pipeline）每条 MR 跑：

跑相关 analysis/tools/*.py（或校验提交的 JSON 哈希）
扫描 analysis/reports/*.md 与合页 HTML，锁定数字必须出现且一致
若 PR 改了 claims/*.json 的 locked 项，必须带 proposals 元数据或指定标签

失败即不能合。这是安全件的真正护栏，比选哪个 Chat UI 重要。

5. 三个入口，一种记忆

入口	给谁	允许	禁止
合页 URL	全员阅读、校准会投影	跳章节、看叙事	浏览器里改数字
飞书机器人	品质 / 结构 / 测试	看主张卡、批/驳、追问「为什么 4,027」	在话题里定新指标
IDE / Agent	你和少数研发	改脚本、重生报告、开 PR	直推主干、无复算改 locked

飞书卡片只渲染主张 ID、现值、状态、证据链接、批准按钮。按钮打到 Calibra API，不写飞书多维表格当底稿。

6. 安全与权限

域	放哪	谁能看
伤人结论、材质书、KISSsoft	私有协作仓	结构 / 品质 / 指定研发
聚合 JSON（直方图、寿命摘要）	同仓	同上
原始 8,904 条曲线、OSS	现有数据域，只读接口	分析任务账号
`.env`、DB 密码	不上协作仓	运维
对外合页	内网或签名 URL	默认不公开到公网

Agent 的云主机只给：克隆协作仓、跑指定脚本、推分支。不给生产库写权限。

7. 分期

Phase 0 · 本周（无新应用）

与 COLLAB_CALIBRATION_CLOUD_PLAN.md 相同：仓、合页 URL、12 条主张 JSON、Skill、飞书只发链接。

验收： 同事不装 Cursor 能看同一份合页；换电脑数字还在。

Phase 1 · 30–60 天 · 应用最小闭环

分析协作进现有 Codeup（不必新开海外仓）
analysis/claims/ + 对账脚本进 Codeup Pipeline
飞书：列出主张、推 MR 链接、记录批准（可先用群卡片）
指定 1 人用 Cursor 桌面 跑脚本、开 Codeup MR（可加云效 MCP）
合页发到 OSS / 内网固定 URL

验收： 改一条锁定主张，不跑脚本合不进去；飞书里能完成一次 lock。

Phase 2 · 60–120 天 · 组织能自己用

Calibra API（claims / proposals / reviews）
飞书「@助手」只读问答（Dify 或自写，检索范围=主张+合页，禁止改数）
n8n：争议主张超时催办
第二战场接入（例如故障码口径主张）

验收： 品质不进 IDE，能在飞书完成一次校准闭环。

Phase 3 · 6–12 月 · 平台化（人多了再做）

主张墙 UI（若卡片超过 ~30 且跨项目）
OpenHands 自托管作工人备胎（降低对单一 IDE 厂商依赖）
SSO、更细审计、多仓库工作区
仍然不自研 模型网关和通用工作流画布

8. 团队与成本（量级，供拍板）

角色	Phase 0–1	Phase 2
你 / 架构	主张建模、Skill、CI	API 与飞书协议
1 名兼职后端	可暂缓	FastAPI + 飞书事件
品质 / 结构 / 测试	只参加校准会	飞书批主张
平台研发团队	不需要	不需要

外部成本：Cursor 桌面席位、飞书已有、Codeup 已有、合页 OSS；Phase 2 可选一台阿里云 4C8G 跑 OpenHands。不买 gitlab.com Premium，也不把 Cloud Agent 当前提。
自己从零做「组织 AI 平台」通常要 3–5 人年；本方案领域层 Phase 2 是 数周到两个月的兼职后端，前提是 Phase 0 记忆层先在。

9. 风险与否决项

风险	对策
飞书文档抄数字，系统外分叉	约定 + 机器人只发主张 ID；发现手抄数视为事故
Agent 口算改指标	CI 对账；locked 无复算记录即 409
用 1# 的 4,027 外推 2# σbw	Skill 与主张注释写死禁止；评审清单打勾
国内访问不了 gitlab.com / GitHub	记忆留 Codeup；工人用桌面 Cursor 或阿里云 OpenHands
做成第二个 Dify	领域服务不提供「任意 Prompt 工作流」
做成第二个 TLA	不读原始轨迹、不写 analysis 表

否决：任何方案把向量检索结果当作可发布数字。

10. 现在怎么选

长期产品形态按本文：组装 Calibra，不整仓采用、不自研平台。
本周执行仍按 COLLAB_CALIBRATION_CLOUD_PLAN.md，否则应用没有记忆。
不要现在部署 Dify / OpenHands / 自建 API——那是 Phase 1–2。
国内团队：协作仓就留 Codeup。工人用 Cursor 桌面（可加云效 MCP）。Cursor Cloud Agent 不作为主路。

拍板只需回一句：

Phase 1 飞书入口要不要做（要则排兼职后端；不要则 Codeup MR + 合页也能校准）？