docs/摩通电气-研发协同管理方案.md

摩通电气 · 研发管理方案说明

面向：深圳摩通电气有限公司
文档目的：说明「代码怎么管、进度怎么看、结果怎么呈现在飞书」的整体架构，便于管理层与技术负责人理解与评审。
版本：演示版（基于已搭建的飞书多维表格「摩通电气-研发管理」）

---

1. 要解决什么问题

摩通电气从事电网运行状态检测类仪器设备（核相测量、电缆探测、校验等），研发同时覆盖：

• 嵌入式固件
• 上位机 / 手持机软件
• 硬件与试验相关资料
• 版本发版与售后追溯

技术人数较多时，常见痛点是：

痛点	结果
代码与文档分散	找不到、难协作、难追溯
进度只在口头/群聊	负责人看不到全局
提交很多但看不出交付	无法判断是否按期发版
固件版本与任务脱节	现场与售后难以追责

本方案的目标一句话：

Gitea 管研发资产（代码与技术文档），飞书管协作与呈现（任务、排期、发版、统计）；中间由自动化能力把代码动态同步进飞书。

---

2. 整体架构（先看这一张图）

flowchart TB
  subgraph Dev["研发侧 · 真相源"]
    Gitea["Gitea<br/>代码 / 文档 / PR / Release"]
  end

  subgraph Sync["同步层 · 匠厂平台技能"]
    Skill["RPA / API 技能<br/>读取 Gitea 事件与数据"]
  end

  subgraph Feishu["飞书 · 协作与呈现"]
    Base["多维表格：摩通电气-研发管理"]
    Board["看板 · 按状态"]
    Gantt["甘特 · 按产品线"]
    Dash["仪表盘 · 研发总览"]
  end

  subgraph People["使用角色"]
    Eng["技术工程师"]
    Lead["组长 / 负责人"]
    Boss["管理层"]
  end

  Gitea --> Skill
  Skill --> Base
  Base --> Board
  Base --> Gantt
  Base --> Dash

  Eng --> Gitea
  Eng --> Board
  Lead --> Board
  Lead --> Gantt
  Lead --> Dash
  Boss --> Dash

三层分工（务必记住）

层级	用什么	干什么	不干什么
资产层	Gitea	存代码、技术文档、合并请求、发版包	不承担公司级进度汇报
同步层	匠厂技能（RPA/API）	把提交、PR、发版等写入飞书	不替代项目管理决策
呈现层	飞书多维表格	任务流转、排期、发版台账、管理看板	不替代 Git 作为代码仓库

---

3. 和摩通业务怎么对齐

官网产品线大致分为：核相测量、电缆探测、校验系列（另有公共平台与代理类）。
飞书里的「产品线」按此划分，任务、仓库、发版都用同一套口径，避免各说各话。

示例对应关系：

产品线	典型型号（示例）	常见研发对象
核相测量	MT-870、INPUT-6600	固件 + 手持/上位 + 授时/通信
电缆探测	K-90、K-73 等	固件 + 探测算法 + 地图/定位相关
校验系列	开关柜校验类设备	固件 + 试验验证
公共平台	BSP、协议库等	跨产品复用组件

---

4. 飞书里建了什么（客户可直接打开看）

飞书多维表格名称：摩通电气-研发管理

4.1 六张数据表

表名	作用	演示时怎么讲
研发任务表	任务主表：谁做、做到哪、何时完成	「日常工作入口」
仓库台账表	有哪些 Gitea 仓库、归属哪条产品线	「代码资产目录」
人员档案表	人员 ↔ Gitea 账号映射、团队与角色	「人和账号对齐」
版本发布表	固件/软件发版记录、适用型号、测试结论	「发版可追溯」
提交流水表	从 Gitea 同步的 commit 明细	「代码活跃证据」
合并请求表	从 Gitea 同步的 PR 状态与超时未审	「评审与风险」

说明：表与表之间的深度关联（双向关联）可按实施节奏逐步加强；当前演示版以「字段对齐 + 同一套仓库名/任务编号」保证能讲清楚闭环。

4.2 三种看法（同一套数据，三种用途）

flowchart LR
  T["研发任务表"] --> K["看板-按状态<br/>看流转"]
  T --> G["甘特-按产品线<br/>看排期"]
  T --> D["仪表盘-研发总览<br/>看结果"]
  C["提交流水 / 合并请求 / 版本发布"] --> D

视图	回答的问题	主要给谁看
看板-按状态	现在卡在评审 / 开发 / 联调 / 测试 / 发布哪一环？	工程师、组长
甘特-按产品线	什么时候开始、什么时候该完成？会不会撞期？	负责人、项目协调
仪表盘-研发总览	在研多少、提交多少、PR 多少、发了几个版？	管理层、周会

4.3 任务状态（看板列，统一语言）

待评审 → 待开发 → 开发中 → 联调中 → 待测试 → 待发布 → 已发布 → 已关闭

嵌入式场景保留 联调中，避免「写完代码就算完成」。

4.4 仪表盘关键指标（研发总览）

• 在研任务数
• 本周提交数
• 打开中的 PR 数
• 已发布版本数
• 任务按状态 / 按产品线分布
• 开发者提交活跃度
• PR 状态（可突出超时未审）
• 发版明细、阻塞任务明细

---

5. 数据如何从 Gitea 到飞书

sequenceDiagram
  participant Dev as 工程师
  participant Gitea as Gitea
  participant Skill as 匠厂同步技能
  participant FS as 飞书多维表格

  Dev->>Gitea: Push / 提PR / 发Release
  Gitea-->>Skill: Webhook 或 API 拉取
  Skill->>Skill: 账号映射、仓库归属、字段清洗
  Skill->>FS: 写入提交流水 / 合并请求 / 版本发布等
  Note over FS: 任务看板仍以人工维护状态为主<br/>代码动态自动进表作证

原则：

1. 任务状态以飞书为准（人要确认是否联调完、是否可测、是否可发）。
2. 代码事实以 Gitea 为准（提交了什么、PR 是否合并、发了哪个 Tag）。
3. 同步层只搬运与对齐，不在飞书里「发明」第二套代码库。

---

6. 推荐使用方式（落地后怎么干活）

角色	每天/每周怎么用
工程师	代码提交到 Gitea；在飞书任务看板更新自己的任务状态；阻塞打勾并注明原因
组长	看看板堵点；看 PR 是否超时未审；看甘特是否撞期
负责人	看甘特产品线排期；看版本发布表是否按计划出包
管理层	打开「研发总览」仪表盘；周会只看数字与风险，不翻聊天记录

---

7. 为什么这样设计（给决策用）

1. 客户已在飞书：学习成本低，看板/甘特/仪表盘都在熟悉环境里。
2. Gitea 适合内网研发资产：权限可控，符合电力行业对代码与资料的管理习惯。
3. 不把「提交次数」当唯一考核：仪表盘里的活跃度只作参考；真正交付看任务完成与发版。
4. 按产品线（核相/电缆/校验）组织：贴合摩通实际销售与研发布局，而不是抽象「项目编号」。

---

8. 实施节奏建议

阶段	内容	结果
已完成（演示版）	飞书六表 + 看板 + 甘特 + 仪表盘 + 模拟数据	可对外讲清架构与呈现
下一阶段	正式 Gitea 仓库规范 + 账号映射 + 同步技能接通	流水/PR/发版变为真实数据
加强阶段	任务与仓库/PR/发版深度关联、权限分级、周报自动化	周会与售后追溯更省力

---

9. 演示时建议打开的页面顺序

1. 架构说明（本文档 / 口述三层分工）
2. 看板-按状态 → 任务怎么流转
3. 甘特-按产品线 → 排期怎么看
4. 提交流水 / 合并请求 → 代码动态如何进飞书
5. 版本发布表 → 固件版本如何追溯
6. 研发总览仪表盘 → 给管理层的一页纸

---

10. 总结

本方案不是「再买一套项目管理软件」，而是：

用 Gitea 把摩通的研发资产收拢，用飞书把进度与结果讲清楚，用同步技能把两边连起来。

当前飞书「摩通电气-研发管理」已具备可演示的完整呈现骨架；接入真实 Gitea 与同步技能后，即可从演示版升级为日常生产用法。

---

附录 A · 表职责一览（速查）

表	一行代表什么
研发任务表	一个可交付研发任务
仓库台账表	一个 Gitea 仓库
人员档案表	一个研发人员及其账号映射
版本发布表	一次发版（Tag/Release）
提交流水表	一次代码提交
合并请求表	一个 PR

附录 B · 文档信息

项	内容
方案对象	深圳摩通电气有限公司
参考官网	http://www.szmtdq.cn/
飞书载体	多维表格「摩通电气-研发管理」
文档性质	架构与呈现说明（客户可读）