更新 摩通电气-研发协同管理方案.md

ai-training.md

@@ -0,0 +1,716 @@
+# 深圳摩通电气有限公司 Codex 企业级深度应用与岗位工作流落地培训方案
+
+## 一、培训主题
+
+**从“会使用AI”到“用AI完成工作”——Codex企业级深度应用与岗位工作流落地实训**
+
+> 本次培训不是传统的AI概念普及，也不是简单教授员工如何编写提示词，而是结合摩通电气在电力仪器研发、试验检测、生产制造、招投标、销售服务和企业管理中的真实任务，帮助员工建立可复用、可验证、可持续优化的Codex岗位工作流。
+
+---
+
+## 二、项目背景
+
+随着人工智能快速发展，企业员工对AI的使用正在从“查询资料、撰写文案”进入“分析文件、执行任务、生成成果、辅助决策”的新阶段。
+
+摩通电气是一家集设计、研发、生产、销售和服务于一体的电力仪器仪表企业，业务涉及嵌入式软硬件研发、电力测试、产品试验、生产装配、技术文档、电网招投标、客户服务和企业管理。
+
+这些工作普遍具有以下特点：
+
+- 专业资料多，技术门槛高；
+- PDF、Word、Excel、代码和测试数据需要交叉处理；
+- 产品参数、标书条款和技术文档要求高度准确；
+- 大量工作依赖员工个人经验，难以标准化和复用；
+- 重复性资料整理占用了研发和业务人员大量时间；
+- AI使用停留在零散问答阶段，尚未转化为稳定生产力。
+
+Codex能够基于本地项目、企业文件、代码和任务规则开展持续工作，适合帮助摩通电气把员工经验、公司资料和标准流程转化为企业可复用的数字化工作能力。
+
+---
+
+## 三、培训定位
+
+本项目采用：
+
+> **3天集中实训＋4周岗位陪跑＋企业Codex工作规范＋部门工作流沉淀**
+
+培训围绕摩通电气真实岗位和业务资料展开，采用“现场操作、真实案例、成果交付、持续陪跑”的方式实施。
+
+培训结束后，不仅要求员工“听懂”，还要求各部门能够独立使用Codex完成至少一项真实工作，并沉淀为标准操作流程。
+
+---
+
+## 四、培训目标
+
+### 1. 全员能力目标
+
+帮助员工掌握：
+
+- Codex与普通聊天式AI的核心区别；
+- 本地项目、文件夹和任务的正确使用方式；
+- PDF、Word、Excel、代码和测试数据的协同分析；
+- 高质量任务描述和上下文组织方法；
+- AI结果验证、风险识别和人工复核方法；
+- 企业敏感资料的分级、脱敏和安全使用规范。
+
+### 2. 岗位能力目标
+
+帮助不同岗位建立适合自己的Codex工作方法：
+
+- 研发人员掌握代码分析、辅助开发、测试和技术资料处理；
+- 试验人员掌握测试数据分析、故障归类和报告生成；
+- 生产人员掌握SOP、工艺文件和异常问题整理；
+- 投标人员掌握招标条款提取、偏离表和一致性检查；
+- 销售人员掌握客户需求分析、产品匹配和方案生成；
+- 售后人员掌握故障排查、案例复用和服务报告生成；
+- 行政、人事和财务人员掌握制度、数据和文档辅助处理；
+- 管理人员掌握项目汇总、风险分析和经营简报生成。
+
+### 3. 企业落地目标
+
+培训与陪跑完成后，帮助摩通电气形成：
+
+- 企业级Codex安全使用规范；
+- 部门标准工作区；
+- 部门任务执行规则；
+- 岗位标准任务模板；
+- 核心岗位Codex技能包；
+- AI成果人工复核机制；
+- 可持续优化的企业AI应用体系。
+
+---
+
+## 五、适用对象
+
+### 管理与项目线
+
+- 公司管理层
+- 部门负责人
+- 研发项目负责人
+- 项目管理人员
+- 总经理助理
+
+### 技术研发线
+
+- 嵌入式软件工程师
+- 嵌入式硬件工程师
+- 算法工程师
+- 研发助理
+- 产品研发人员
+- 技术文档人员
+
+### 试验制造线
+
+- 试验人员
+- 质量人员
+- 工艺人员
+- 生产管理人员
+- 贴片、结构、机加工和装配相关骨干
+
+### 市场经营线
+
+- 招投标专员
+- 商务人员
+- 销售经理
+- 销售管培生
+- 电商及市场人员
+- 售后服务人员
+
+### 综合管理线
+
+- 人力资源人员
+- 行政人员
+- AI信息数据收集人员
+- 财务人员
+- 采购及供应链人员
+
+---
+
+## 六、培训方法
+
+本次培训采用“20%方法讲解＋30%案例演示＋50%现场实操”的方式。
+
+每个案例按照以下闭环完成：
+
+1. 明确业务目标；
+2. 准备真实脱敏资料；
+3. 建立部门工作区；
+4. 编写任务规则；
+5. 让Codex分析和执行；
+6. 检查来源与修改内容；
+7. 进行专业人员复核；
+8. 修正并形成正式成果；
+9. 沉淀为可重复使用的流程。
+
+---
+
+# 七、集中培训课程安排
+
+## 第一天：Codex核心能力与企业级工作方法
+
+### 上午：从AI问答到AI任务协作
+
+#### 模块一：理解Codex的企业应用价值
+
+- Codex与普通聊天式AI的区别；
+- 从“一问一答”到“分析、计划、执行、验证”；
+- Codex适合完成哪些工作；
+- Codex不适合直接决定哪些工作；
+- AI在电力、研发、招投标和制造场景中的应用边界；
+- 常见AI幻觉、信息缺失和错误推断问题。
+
+#### 模块二：Codex本地项目与文件协作
+
+- 如何为不同业务建立独立项目；
+- 如何让Codex理解一个或多个文件夹；
+- 如何组织PDF、Word、Excel、代码和图片资料；
+- 如何针对不同成果建立独立任务；
+- 如何避免资料过多造成上下文混乱；
+- 如何让Codex先阅读资料，再提出问题和执行任务。
+
+#### 模块三：高质量任务描述方法
+
+掌握企业任务六要素：
+
+1. 任务目标；
+2. 业务背景；
+3. 输入资料；
+4. 执行约束；
+5. 输出格式；
+6. 验收标准。
+
+现场练习：
+
+- 把模糊要求改写为可执行任务；
+- 让Codex主动识别缺失资料；
+- 要求Codex区分事实、推断和待确认项；
+- 要求Codex标注文件依据；
+- 要求Codex执行完成后进行自检。
+
+### 下午：企业文件处理与安全规范
+
+#### 模块四：跨文件分析与成果生成
+
+- 从长篇PDF中提取关键内容；
+- 对比招标规范和产品参数；
+- 分析Excel表格中的异常数据；
+- 根据历史模板生成新文档；
+- 检查多个文件中的参数一致性；
+- 根据修改意见更新已有文件；
+- 输出Word、Excel、Markdown和结构化清单。
+
+#### 模块五：企业资料安全与结果验证
+
+- 企业资料分级；
+- 代码、客户、财务和招投标资料的脱敏；
+- 不同部门之间的资料权限；
+- 禁止上传和禁止对外传播的内容；
+- AI生成结果的责任边界；
+- 高风险任务的人工确认机制；
+- 如何检查Codex修改了哪些文件；
+- 如何防止AI自行补造参数、资质和结论。
+
+#### 第一天实战成果
+
+全员使用摩通电气脱敏资料完成：
+
+> 根据产品资料、历史模板和客户需求，生成一份产品技术方案初稿，并输出信息来源、缺失资料、风险项和人工确认清单。
+
+---
+
+## 第二天：技术研发、试验质量与生产制造专场
+
+### 上午：研发中心Codex深度应用
+
+#### 模块一：Datasheet与技术规范精读
+
+- 快速定位引脚、寄存器和通信接口；
+- 提取电气参数、时序和限制条件；
+- 对比不同芯片或模块的参数；
+- 生成寄存器配置清单；
+- 形成硬件选型对比表；
+- 标记资料中未明确的内容；
+- 防止Codex自行推测硬件参数。
+
+#### 模块二：嵌入式代码辅助开发
+
+- 阅读和解释现有C/C++代码；
+- 梳理模块、函数和数据流；
+- 分析UART、IIC、SPI等接口代码；
+- 辅助生成初始化代码草稿；
+- 定位边界条件和潜在缺陷；
+- 重构重复代码；
+- 生成代码注释和开发文档；
+- 对修改范围进行影响分析。
+
+#### 模块三：代码验证与测试闭环
+
+- 代码修改前先制订计划；
+- 生成单元测试和测试用例；
+- 执行编译、静态检查和测试；
+- 分析编译错误和运行日志；
+- 对比修改前后的行为；
+- 形成代码审查清单；
+- 明确必须由研发人员确认的内容。
+
+#### 研发实战案例
+
+> 基于一份脱敏后的芯片Datasheet和现有嵌入式代码，提取关键寄存器与接口要求，生成初始化代码草稿、测试用例和研发人员待确认清单。
+
+### 下午：试验、质量、技术文档与生产制造
+
+#### 模块四：试验数据分析
+
+- 清洗和整理测试数据；
+- 识别缺失值、异常值和重复数据；
+- 生成数据统计与可视化脚本；
+- 对不同批次测试结果进行比较；
+- 对故障现象进行分类；
+- 输出测试结果摘要；
+- 自动形成测试报告初稿。
+
+#### 模块五：质量问题与故障分析
+
+- 将零散问题记录转化为结构化问题单；
+- 分析故障发生条件和重复模式；
+- 辅助进行原因假设和验证；
+- 生成8D报告、纠正措施和预防措施草稿；
+- 建立历史故障案例库；
+- 根据新问题匹配类似历史案例。
+
+#### 模块六：技术文档与产品资料
+
+- 从研发记录生成产品说明书；
+- 根据历史模板生成操作手册；
+- 统一产品名称、型号和专业术语；
+- 检查代码、参数表、测试报告和说明书的一致性；
+- 生成安装、操作、维护和故障排查章节；
+- 形成缺失信息和研发确认清单；
+- 辅助完成专业技术翻译。
+
+#### 模块七：生产工艺与作业指导
+
+- 根据产品资料生成SOP草稿；
+- 整理装配步骤和质量控制点；
+- 生成生产检查表；
+- 分析工程变更对BOM、工艺和文档的影响；
+- 将现场异常转化为标准案例；
+- 根据老师傅经验形成可传承的操作知识。
+
+#### 第二天实战成果
+
+各技术小组完成一项真实成果：
+
+- 嵌入式代码审查与测试报告；
+- 测试数据分析报告；
+- 产品说明书或操作手册；
+- 生产SOP或工程变更影响清单；
+- 质量问题8D分析初稿。
+
+---
+
+## 第三天：招投标、销售服务与企业管理专场
+
+### 上午：招投标与销售业务
+
+#### 模块一：招标文件智能解析
+
+- 快速识别资格条件；
+- 提取废标条款和否决条件；
+- 提取硬性技术指标；
+- 提取交付、质保和售后要求；
+- 提取签章、装订和附件要求；
+- 将招标要求转化为结构化检查表。
+
+#### 模块二：技术参数与证据矩阵
+
+- 对比招标参数与公司产品参数；
+- 建立逐条响应关系；
+- 生成技术偏离表草稿；
+- 标记满足、偏离、缺失和待确认项目；
+- 为每项响应匹配资质、报告和证明材料；
+- 防止AI编造不存在的资质和参数。
+
+#### 模块三：投标文件一致性检查
+
+- 检查项目名称和招标编号；
+- 检查产品型号和技术参数；
+- 检查报价、数量和交付日期；
+- 检查公司名称、人员姓名和证书有效期；
+- 检查正文与附件之间的冲突；
+- 输出明确风险、疑似风险和资料缺失三级清单。
+
+#### 模块四：销售与售前方案
+
+- 从客户沟通记录提取真实需求；
+- 根据应用场景匹配产品；
+- 形成客户需求澄清问题；
+- 对比自有产品与竞品差异；
+- 生成专业销售沟通话术；
+- 生成产品推荐方案和报价说明；
+- 根据不同客户形成定制化售前方案；
+- 将客户沟通纪要转化为后续行动清单。
+
+#### 招投标与销售实战案例
+
+> 对比一份电网招标技术规范和摩通产品参数，生成关键条款清单、证据矩阵、技术偏离表、风险清单和待技术负责人确认事项。
+
+### 下午：售后、人事行政、财务与管理层
+
+#### 模块五：售后服务与故障知识沉淀
+
+- 将客户故障描述转化为标准问题单；
+- 自动追问缺失的故障信息；
+- 根据历史案例生成排查路径；
+- 形成分步骤故障排查树；
+- 生成客户回复和服务报告；
+- 从售后记录提炼产品改进建议；
+- 建立产品FAQ和故障案例库。
+
+#### 模块六：人力资源与行政管理
+
+- 根据业务需求优化岗位JD；
+- 对简历进行结构化比较；
+- 生成岗位面试问题；
+- 制订新人培训计划；
+- 起草绩效指标和考核说明；
+- 对比制度与政策文件；
+- 生成制度修改意见；
+- 输出劳动关系风险待复核清单；
+- 明确招聘和员工管理中的人工决策责任。
+
+#### 模块七：行业与政策信息研究
+
+针对“AI信息数据收集”岗位开展专项训练：
+
+- 制订行业研究任务；
+- 搜索并筛选可靠信息来源；
+- 区分官方信息、媒体信息和营销内容；
+- 建立信息来源记录；
+- 对行业、产品、政策和竞争对手进行持续跟踪；
+- 生成带来源的研究报告；
+- 建立内部可查询的信息目录；
+- 防止研究报告引用虚假或过期信息。
+
+#### 模块八：财务、采购与供应链
+
+- 比较不同供应商的价格、交期和付款条件；
+- 形成供应商报价对比表；
+- 检查采购合同中的付款和开票条款；
+- 识别质保金、违约金和交付风险；
+- 整理研发费用归集材料；
+- 形成应收账款跟进清单；
+- 输出财务和采购人员待复核事项；
+- 明确AI不能替代会计、税务和法律专业判断。
+
+#### 模块九：管理层与项目管理
+
+- 汇总各部门周报和项目状态；
+- 生成项目里程碑和风险台账；
+- 从会议纪要中提取责任人和截止时间；
+- 分析项目延期原因；
+- 生成管理层经营简报；
+- 对多个研发或投标项目进行优先级比较；
+- 建立部门AI应用效果评价机制。
+
+#### 第三天成果汇报
+
+每个部门现场展示：
+
+1. 选择的真实业务任务；
+2. 使用的输入资料；
+3. Codex执行过程；
+4. 生成的业务成果；
+5. 发现的问题和风险；
+6. 人工复核方式；
+7. 后续可复用的标准流程。
+
+---
+
+# 八、部门Codex工作流建设
+
+培训期间及陪跑阶段，为各部门建立标准工作区。
+
+## 1. 研发中心工作区
+
+```text
+研发项目/
+├── 01_需求与技术规范
+├── 02_Datasheet
+├── 03_硬件资料
+├── 04_嵌入式代码
+├── 05_测试用例
+├── 06_测试数据
+├── 07_技术文档
+├── 08_Codex输出
+└── AGENTS.md
+```
+
+## 2. 招投标工作区
+
+```text
+投标项目/
+├── 01_招标公告
+├── 02_招标文件
+├── 03_技术规范
+├── 04_公司资质
+├── 05_产品参数
+├── 06_历史标书
+├── 07_本次投标文件
+├── 08_审核结果
+└── AGENTS.md
+```
+
+## 3. 销售与售后工作区
+
+```text
+客户项目/
+├── 01_客户背景
+├── 02_需求与沟通记录
+├── 03_产品资料
+├── 04_竞争信息
+├── 05_解决方案
+├── 06_报价与合同
+├── 07_售后记录
+├── 08_跟进计划
+└── AGENTS.md
+```
+
+## 4. 综合管理工作区
+
+```text
+综合管理/
+├── 01_公司制度
+├── 02_岗位与人员
+├── 03_培训与绩效
+├── 04_财务与采购模板
+├── 05_行业政策
+├── 06_会议与项目
+├── 07_标准输出模板
+└── AGENTS.md
+```
+
+---
+
+# 九、重点岗位Codex技能包
+
+培训与陪跑期间，建议优先沉淀以下技能包：
+
+## 1. 电网投标文件审查技能
+
+输入：
+
+- 招标文件
+- 技术规范
+- 公司资质
+- 产品参数
+- 投标文件
+
+输出：
+
+- 关键资格条件
+- 废标风险
+- 技术偏离表
+- 证据矩阵
+- 一致性问题
+- 待人工确认清单
+
+## 2. 嵌入式代码审查技能
+
+输入：
+
+- Datasheet
+- 原理说明
+- C/C++代码
+- 编译日志
+- 测试要求
+
+输出：
+
+- 代码结构说明
+- 潜在缺陷
+- 修改计划
+- 代码修改建议
+- 测试用例
+- 影响范围和复核清单
+
+## 3. 试验数据分析技能
+
+输入：
+
+- 原始测试数据
+- 测试标准
+- 合格范围
+- 历史测试结果
+
+输出：
+
+- 数据清洗结果
+- 异常数据
+- 图表
+- 批次对比
+- 结论草稿
+- 测试报告
+
+## 4. 产品文档生成与审查技能
+
+输入：
+
+- 产品参数
+- 研发记录
+- 测试报告
+- 历史说明书
+- 公司模板
+
+输出：
+
+- 产品说明书
+- 操作手册
+- 参数一致性报告
+- 缺失信息清单
+- 研发确认事项
+
+## 5. 售后故障分析技能
+
+输入：
+
+- 客户故障描述
+- 产品型号
+- 设备状态
+- 历史故障案例
+- 使用手册
+
+输出：
+
+- 信息补充问题
+- 故障原因假设
+- 分步骤排查路径
+- 客户回复草稿
+- 售后服务报告
+- 产品改进建议
+
+---
+
+# 十、四周岗位陪跑计划
+
+## 第一周：工作区与规则建立
+
+- 完成部门资料分类；
+- 建立标准目录；
+- 编写部门AGENTS.md规则；
+- 明确敏感资料边界；
+- 选择首批试点任务。
+
+## 第二周：核心场景跑通
+
+优先完成：
+
+- 研发代码与测试场景；
+- 招投标审查场景；
+- 修正任务规则和输出格式；
+- 建立人工复核标准。
+
+## 第三周：业务场景扩展
+
+完成：
+
+- 销售方案场景；
+- 试验或质量报告场景；
+- 售后服务场景；
+- 人事行政或行业研究场景。
+
+## 第四周：成果验收与能力沉淀
+
+- 验收各部门工作流；
+- 测量培训前后效率变化；
+- 优化岗位任务模板；
+- 固化核心技能包；
+- 形成下一阶段AI应用路线图。
+
+---
+
+# 十一、培训效果评估
+
+本项目不以“听课满意度”作为唯一标准，而是从实际工作效果进行评价。
+
+## 1. 员工能力指标
+
+- 能否独立建立正确的工作区；
+- 能否写出完整的任务要求；
+- 能否组织和引用企业资料；
+- 能否识别AI输出中的错误；
+- 能否按照流程完成结果复核；
+- 能否把一次任务沉淀为可复用模板。
+
+## 2. 业务效果指标
+
+- 招标文件关键条款提取覆盖率；
+- 投标参数不一致问题发现数量；
+- 测试数据整理和报告制作时间；
+- 研发代码编译及测试通过情况；
+- 产品文档参数错误和遗漏数量；
+- 销售方案初稿制作时间；
+- 售后问题首次响应时间；
+- 行业研究报告有效来源比例。
+
+## 3. 企业沉淀指标
+
+- 建立的部门工作区数量；
+- 形成的岗位任务模板数量；
+- 跑通的真实工作流数量；
+- 形成的Codex技能包数量；
+- 完成人工复核规则的业务场景数量；
+- 培训后持续使用Codex的员工比例。
+
+---
+
+# 十二、安全与风险控制
+
+所有培训案例必须遵守以下原则：
+
+- 使用真实但经过脱敏的企业资料；
+- 不上传国家秘密、客户机密和禁止外传资料；
+- 不允许AI编造技术参数、资质、案例和检测结论；
+- 研发代码必须通过编译、测试和人工评审；
+- 投标结果必须由投标负责人最终确认；
+- 财务、税务、合同和人事意见必须由专业人员复核；
+- AI不得直接作出招聘、处罚和重大经营决策；
+- 涉及外部发送、系统操作和高风险修改时必须人工确认；
+- 对关键业务保留输入资料、执行过程和复核记录。
+
+---
+
+# 十三、项目交付成果
+
+项目完成后交付：
+
+1. 《摩通电气Codex安全使用规范》
+2. 《摩通电气Codex全员操作手册》
+3. 企业级项目及文件目录规范
+4. 8套部门Codex工作区模板
+5. 8份部门AGENTS.md任务规则
+6. 5个核心岗位Codex技能包原型
+7. 10个真实岗位实战案例
+8. 部门标准任务模板合集
+9. 《AI生成结果人工复核清单》
+10. 《Codex岗位工作流标准操作手册》
+11. 培训前后能力及效率评估报告
+12. 四周陪跑与成果验收报告
+13. 摩通电气下一阶段AI应用路线图
+
+---
+
+# 十四、项目价值
+
+通过本次培训与陪跑，摩通电气将逐步形成以下能力：
+
+- 让研发人员减少重复编码和资料整理；
+- 让试验人员更快完成数据分析和测试报告；
+- 让技术文档与产品参数保持一致；
+- 让生产经验能够被整理、保存和复用；
+- 让招投标人员更系统地发现条款与参数风险；
+- 让销售人员快速形成专业、准确的客户方案；
+- 让售后经验从个人经验转化为企业知识；
+- 让人事、行政、财务和管理人员提高资料处理效率；
+- 让企业AI应用从零散个人行为升级为可管理、可验证、可复用的组织能力。
+
+> 最终目标不是让员工“学会一个AI工具”，而是帮助摩通电气建立一套覆盖研发、试验、生产、投标、销售、服务和管理的Codex企业工作体系。

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

@@ -0,0 +1,245 @@
+# 摩通电气 · 研发管理方案说明
+
+> 面向：深圳摩通电气有限公司  
+> 文档目的：说明「代码怎么管、进度怎么看、结果怎么呈现在飞书」的整体架构，便于管理层与技术负责人理解与评审。  
+> 版本：演示版（基于已搭建的飞书多维表格「摩通电气-研发管理」）
+
+---
+
+## 1. 要解决什么问题
+
+摩通电气从事电网运行状态检测类仪器设备（核相测量、电缆探测、校验等），研发同时覆盖：
+
+- 嵌入式固件
+- 上位机 / 手持机软件
+- 硬件与试验相关资料
+- 版本发版与售后追溯
+
+技术人数较多时，常见痛点是：
+
+| 痛点 | 结果 |
+|------|------|
+| 代码与文档分散 | 找不到、难协作、难追溯 |
+| 进度只在口头/群聊 | 负责人看不到全局 |
+| 提交很多但看不出交付 | 无法判断是否按期发版 |
+| 固件版本与任务脱节 | 现场与售后难以追责 |
+
+本方案的目标一句话：
+
+**Gitea 管研发资产（代码与技术文档），飞书管协作与呈现（任务、排期、发版、统计）；中间由自动化能力把代码动态同步进飞书。**
+
+---
+
+## 2. 整体架构（先看这一张图）
+
+```mermaid
+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 三种看法（同一套数据，三种用途）
+
+```mermaid
+flowchart LR
+  T["研发任务表"] --> K["看板-按状态<br/>看流转"]
+  T --> G["甘特-按产品线<br/>看排期"]
+  T --> D["仪表盘-研发总览<br/>看结果"]
+  C["提交流水 / 合并请求 / 版本发布"] --> D
+```
+
+| 视图 | 回答的问题 | 主要给谁看 |
+|------|------------|------------|
+| 看板-按状态 | 现在卡在评审 / 开发 / 联调 / 测试 / 发布哪一环？ | 工程师、组长 |
+| 甘特-按产品线 | 什么时候开始、什么时候该完成？会不会撞期？ | 负责人、项目协调 |
+| 仪表盘-研发总览 | 在研多少、提交多少、PR 多少、发了几个版？ | 管理层、周会 |
+
+### 4.3 任务状态（看板列，统一语言）
+
+```
+待评审 → 待开发 → 开发中 → 联调中 → 待测试 → 待发布 → 已发布 → 已关闭
+```
+
+嵌入式场景保留 **联调中**，避免「写完代码就算完成」。
+
+### 4.4 仪表盘关键指标（研发总览）
+
+- 在研任务数  
+- 本周提交数  
+- 打开中的 PR 数  
+- 已发布版本数  
+- 任务按状态 / 按产品线分布  
+- 开发者提交活跃度  
+- PR 状态（可突出超时未审）  
+- 发版明细、阻塞任务明细  
+
+---
+
+## 5. 数据如何从 Gitea 到飞书
+
+```mermaid
+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/ |
+| 飞书载体 | 多维表格「摩通电气-研发管理」 |
+| 文档性质 | 架构与呈现说明（客户可读） |