导语｜硬件开源靠规范，不靠情绪
china-langhui-ego 组织下的 E2／E6 等仓库，面向的是真实设备、真实固件与真实采集现场。Issue 与 PR 若缺少版本、日志与复现，维护者只能猜测；若缺少许可与安全边界，生态会受伤。本文给出硬件开源协作规范，让反馈能回流到 README 与交付包。
Issue 最小完备性
标题含机型、现象、是否阻断。正文含提交号、交付包版本、系统、步骤、期望与实际、日志、是否可公开。
缺日志先补齐再排期。
安全问题走私下披露，不公开利用细节。
模板化 Issue 能提升信号质量。
PR 范围与测试说明
单一主题：文档、示例、构建或小工具。
写清是否需真机。
破坏性变更要迁移说明。
巨型重构另开设计讨论。
文档与边界同步
改能力边界必须同步官网与支持话术责任人。
中英文策略写入指南。
链接变更同步资料台账。
文档测试同样需要审查。
许可与第三方代码
引入第三方需声明许可兼容。
机密配置不得进入公网 fork。
贡献者协议按组织要求执行。
干净树是长期信任。
审查与拒绝的专业方式
拒绝时给原因与替代路径，例如定制评估。
月度纪要公开合并与未排期项。
对重复问题链向 FAQ。
专业拒绝也是生态建设。
协作检查表
提交前用检查表自审，减少来回。
- 标题与模板字段完整
- 日志与版本齐备
- 安全问题走正确渠道
- PR 主题单一且可测
- 文档边界变更已同步
- 许可与机密检查通过
从反馈到交付包
高频 Issue 应驱动 README 与交付包更新，而不是只在聊天解决。
回归测试覆盖已修缺陷。
发布说明写清影响面。
闭环可见，贡献者才愿意再来。
社区与商业边界
开源支持与项目服务等级分开。
商业客户仍被鼓励把可公开部分回馈社区。
边界清晰，冲突更少。
规范是硬件开源可持续的基础设施。
工程深挖、现场门禁、问答与附录要求
围绕「Issue 模板」，建议在项目周报单列进展与风险：已验证的事实、未验证的假设、下一步实验各写一句。这样开源集成不会停在感觉良好，而会停在可检查的证据。对外部协作方，也可以用同一格式同步，减少会议空转。
在涉及「安全披露」的变更窗口，冻结并行大改：先完成小范围回归，再放开多人提交。硬件开源最怕多变量同时动。回归包应包含最短路径的成功样例与已知失败样例，保证失败可重复。
把「单一主题 PR」写入新人首周任务：不是阅读口号，而是亲手完成一次操作并提交记录截图或日志摘要。通过率低说明文档缺口，而不是只说明新人能力。文档缺口要回流到仓库或资料台账。
针对「真机测试说明」建立反例库：正确做法旁必须放错误做法与后果。现场人员对反例的记忆深于对条文的记忆。反例库每个季度删增一次，保持与当前固件和工具链同步。
若指标与「边界同步」相关出现漂移，先做分层诊断：设备、主机、网络、规程、人因。禁止直接跳到改模型或改硬件选型。分层诊断记录保留九十天，供审计与复盘。
对外演示「中英文」时，优先展示门禁与日志，而不是只展示最终画面。决策者更信任可重复过程。演示脚本版本化，避免每次临场发挥造成承诺不一致。
与「第三方许可」相关的责任人必须有明确的否决权与升级路径。没有否决权的质量角色等于装饰。升级路径写到支持手册，节假日也能执行。
度量「机密过滤」不要只用二元是否成功，而要保留分布：百分之五十、百分之九十五分位与极端尾部。尾部决定生产痛苦。分布图进周会，比平均值更能推动资源分配。
当「专业拒绝」需要跨团队协作时，先写一页接口：输入、输出、超时、失败码、所有者。接口比共识会议便宜。接口变更走短评审，避免私聊决定影响全局。
回顾「月度纪要」的历史事故时，使用统一模板：现象、影响会话、根因、修复、是否需要重采。模板强制区分偶发与系统性。系统性必须回流到固件、文档或规程，而不是靠个人英雄。
在预算讨论里，把「FAQ 链接」的成本拆成工具时间、人因时间、返工时间。只看工具采购价会低估总拥有成本。拆分后的数字更能支持开源治理投资。
保持「回归缺陷」相关的最小可运行样例永远可运行：样例损坏等于文档损坏。持续集成夜间跑样例，失败即阻断合并。样例也是客户 onboarding 的最快路径。
围绕「发布说明」，建议在项目周报单列进展与风险：已验证的事实、未验证的假设、下一步实验各写一句。这样开源集成不会停在感觉良好，而会停在可检查的证据。对外部协作方，也可以用同一格式同步，减少会议空转。
在涉及「服务等级分流」的变更窗口，冻结并行大改：先完成小范围回归，再放开多人提交。硬件开源最怕多变量同时动。回归包应包含最短路径的成功样例与已知失败样例，保证失败可重复。
把「回馈社区」写入新人首周任务：不是阅读口号，而是亲手完成一次操作并提交记录截图或日志摘要。通过率低说明文档缺口，而不是只说明新人能力。文档缺口要回流到仓库或资料台账。
针对「标签分流」建立反例库：正确做法旁必须放错误做法与后果。现场人员对反例的记忆深于对条文的记忆。反例库每个季度删增一次，保持与当前固件和工具链同步。
若指标与「复现步骤」相关出现漂移，先做分层诊断：设备、主机、网络、规程、人因。禁止直接跳到改模型或改硬件选型。分层诊断记录保留九十天，供审计与复盘。
对外演示「脱敏日志」时，优先展示门禁与日志，而不是只展示最终画面。决策者更信任可重复过程。演示脚本版本化，避免每次临场发挥造成承诺不一致。
Issue 标题应含机型、现象、是否阻断录制。标题党与情绪化表述会降低响应质量。
正文最小集：仓库提交号、交付包版本、主机系统、复现步骤、期望与实际、日志附件、是否可公开。缺日志的 Issue 可先要求补齐再排期。
安全漏洞走私下披露渠道，不在公开 Issue 贴利用细节。硬件开源同样遵循负责任披露。
PR 应聚焦单一主题：文档、示例、构建修复或小型工具。巨型重构难以审查，也难以回溯。
文档 PR 若改能力边界，必须同步销售与支持话术责任人，避免文档与官网短暂分裂。
测试说明要写清是否需要真机。纯文档变更与真机相关变更的审查深度不同。
许可与第三方代码引入要单独声明。干净的开源树是长期协作的信任基础。
中文与英文文档同步策略写进贡献指南，避免只更新一种语言造成国际贡献者误读。
拒绝时说明原因与替代路径，例如走定制评估。冷漠关闭会伤害生态。
用月度纪要公开已合并与未排期项，让硬件团队看到反馈闭环，而不是黑洞邮箱。
贡献指南首页放“最小 Issue 示例”与“糟糕 Issue 示例”对照，教学效果最好。
安全披露邮箱与响应时限写清，建立信任。
文档 PR 的预览环境若难建，至少要求前后截图或渲染片段。
标签体系：机型、组件、文档、安全、好第一期。标签滥用等于无标签。
拒绝模板含：原因、证据缺口、建议下一步、是否欢迎重开。
月度纪要同步到讨论区，让沉默贡献者看见进展。
代码风格与构建脚本变更单开 PR，避免与功能混杂。
要求贡献者声明是否在真机验证，避免纸上正确。
对重复贡献者给予维护候选路径，硬件开源更需要长期同伴。
商业泄露风险：截图中的客户产线要教贡献者打码。
把 FAQ 与 Issue 自动提示联动，降低重复劳动。
主版本发行由指定维护者切，避免权限过散。
中文社区与国际社区的冲突用英文技术事实仲裁，保持专业。
贡献统计不以行数论英雄，而以缺陷关闭与文档清晰度论。
规范本身也接受 PR，让社区共建治理。
问：没有日志的 Issue？ 答：先补齐再排期。
问：安全问题公开贴吗？ 答：不，走私下披露。
问：PR 能否又大又全？ 答：不，单一主题。
问：是否需真机？ 答：要在说明里写清。
问：改边界只改仓库？ 答：不够，同步官网话术。
问：拒绝会伤害社区吗？ 答：专业拒绝含替代路径。
问：月度纪要有用吗？ 答：让沉默贡献者看见闭环。
问：行数是贡献吗？ 答：不是，看缺陷关闭与文档清晰。
问：截图含产线？ 答：打码。
问：标签很多？ 答：控制集合，防滥用。
问：中英冲突听谁？ 答：技术事实，保持专业。
问：商业客户要开源支持？ 答：可，但服务等级分开。
问：FAQ 联动？ 答：减少重复 Issue。
问：谁切主版本？ 答：指定维护者。
问：构建与功能混 PR？ 答：拆开。
问：纸上正确真机未测？ 答：声明清楚，审查降权。
问：治理文档可 PR 吗？ 答：可以，共建规范。
问：重复问题？ 答：链 FAQ。
问：机密配置进 fork？ 答：禁止。
问：第三方许可？ 答：声明兼容。
问：好第一期标签？ 答：欢迎新人小任务。
问：预览环境没有？ 答：至少前后片段。
问：情绪化标题？ 答：改成机型加现象。
问：长期贡献者？ 答：给维护候选路径。
问：发布说明写什么？ 答：影响面与迁移。
问：回归谁跑？ 答：维护者或自动化。
问：中文社区如何协作？ 答：模板双语，事实优先。
问：规范目的？ 答：让反馈回流 README 与交付包。
在落地「contribute」相关能力时，好坏 Issue 对照放指南首页。同时，安全邮箱与时限公开。建议把上述要求写进当周检查表，并在下周站会复核是否执行到位，未执行则记为流程缺陷而不是个人态度问题。对外协作也可共享同一检查表，减少双方对“已经说过”的记忆偏差，让开源集成与交付验收始终有据可查。
在落地「contribute」相关能力时，文档 PR 附前后片段。同时，标签集合受控。建议把上述要求写进当周检查表，并在下周站会复核是否执行到位，未执行则记为流程缺陷而不是个人态度问题。对外协作也可共享同一检查表，减少双方对“已经说过”的记忆偏差，让开源集成与交付验收始终有据可查。
在落地「contribute」相关能力时，拒绝模板四要素齐全。同时，纪要同步讨论区。建议把上述要求写进当周检查表，并在下周站会复核是否执行到位，未执行则记为流程缺陷而不是个人态度问题。对外协作也可共享同一检查表，减少双方对“已经说过”的记忆偏差，让开源集成与交付验收始终有据可查。
在落地「contribute」相关能力时，风格变更单独 PR。同时，真机验证声明强制。建议把上述要求写进当周检查表，并在下周站会复核是否执行到位，未执行则记为流程缺陷而不是个人态度问题。对外协作也可共享同一检查表，减少双方对“已经说过”的记忆偏差，让开源集成与交付验收始终有据可查。
在落地「contribute」相关能力时，维护候选路径透明。同时，产线截图打码培训。建议把上述要求写进当周检查表，并在下周站会复核是否执行到位，未执行则记为流程缺陷而不是个人态度问题。对外协作也可共享同一检查表，减少双方对“已经说过”的记忆偏差，让开源集成与交付验收始终有据可查。
在落地「contribute」相关能力时，FAQ 自动提示联动。同时，主版本权限集中。建议把上述要求写进当周检查表，并在下周站会复核是否执行到位，未执行则记为流程缺陷而不是个人态度问题。对外协作也可共享同一检查表，减少双方对“已经说过”的记忆偏差，让开源集成与交付验收始终有据可查。
在落地「contribute」相关能力时，冲突用技术事实仲裁。同时，贡献评价看清晰度。建议把上述要求写进当周检查表，并在下周站会复核是否执行到位，未执行则记为流程缺陷而不是个人态度问题。对外协作也可共享同一检查表，减少双方对“已经说过”的记忆偏差，让开源集成与交付验收始终有据可查。
在落地「contribute」相关能力时，治理文档可被 PR。同时，重复问题链向 FAQ。建议把上述要求写进当周检查表，并在下周站会复核是否执行到位，未执行则记为流程缺陷而不是个人态度问题。对外协作也可共享同一检查表，减少双方对“已经说过”的记忆偏差，让开源集成与交付验收始终有据可查。
在落地「contribute」相关能力时，机密配置扫描进 CI。同时，第三方许可检查表。建议把上述要求写进当周检查表，并在下周站会复核是否执行到位，未执行则记为流程缺陷而不是个人态度问题。对外协作也可共享同一检查表，减少双方对“已经说过”的记忆偏差，让开源集成与交付验收始终有据可查。
在落地「contribute」相关能力时，好第一期任务池维护。同时，发布说明含迁移步骤。建议把上述要求写进当周检查表，并在下周站会复核是否执行到位，未执行则记为流程缺陷而不是个人态度问题。对外协作也可共享同一检查表，减少双方对“已经说过”的记忆偏差，让开源集成与交付验收始终有据可查。
补充要求：好坏 Issue 对照放指南首页。标签集合受控。真机验证声明强制。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：安全邮箱与时限公开。拒绝模板四要素齐全。维护候选路径透明。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：文档 PR 附前后片段。纪要同步讨论区。产线截图打码培训。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：标签集合受控。风格变更单独 PR。FAQ 自动提示联动。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：拒绝模板四要素齐全。真机验证声明强制。主版本权限集中。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：纪要同步讨论区。维护候选路径透明。冲突用技术事实仲裁。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：风格变更单独 PR。产线截图打码培训。贡献评价看清晰度。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：真机验证声明强制。FAQ 自动提示联动。治理文档可被 PR。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：维护候选路径透明。主版本权限集中。重复问题链向 FAQ。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：产线截图打码培训。冲突用技术事实仲裁。机密配置扫描进 CI。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：FAQ 自动提示联动。贡献评价看清晰度。第三方许可检查表。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：主版本权限集中。治理文档可被 PR。好第一期任务池维护。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：冲突用技术事实仲裁。重复问题链向 FAQ。发布说明含迁移步骤。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：贡献评价看清晰度。机密配置扫描进 CI。好坏 Issue 对照放指南首页。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：治理文档可被 PR。第三方许可检查表。安全邮箱与时限公开。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：重复问题链向 FAQ。好第一期任务池维护。文档 PR 附前后片段。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：机密配置扫描进 CI。发布说明含迁移步骤。标签集合受控。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：第三方许可检查表。好坏 Issue 对照放指南首页。拒绝模板四要素齐全。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：好第一期任务池维护。安全邮箱与时限公开。纪要同步讨论区。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
补充要求：发布说明含迁移步骤。文档 PR 附前后片段。风格变更单独 PR。若执行中发现冲突，以书面规格与当前冻结版本为准，并在二十四小时内提出文档修订，避免现场靠口头临时解释长期运行。
下一步：从开源 SDK 进入可验收联调
若你的团队正在评估china-langhui-ego 开源协作规范，请先以 GitHub README 与交付包为准完成克隆、资料包核对与主机侧联调，再把同步、上传、标定与许可边界写进项目验收附件。开源仓库帮助你快速起步；书面规格决定交付范围。
前往 开发者文档 · E2／E6 Device SDK 获取克隆命令、Drive／百度资料与 Linux 对接说明，或直接 联系技术接入 对齐版本、样例与验收字段。