贡献指南
本项目欢迎广大开发者体验并参与贡献，在参与社区贡献之前。请参见cann-community了解行为准则，进行CLA协议签署，了解源码仓的贡献流程。
开发者准备本地代码与提交PR时需要重点关注如下几点：
- 提交PR时，请按照PR模板仔细填写本次PR的业务背景、目的、方案等信息。
- 若您的修改不是简单的bug修复，而是涉及到新增特性、新增接口、新增配置参数或者修改代码流程等，请务必先通过Issue进行方案讨论，以避免您的代码被拒绝合入。若您不确定本次修改是否可被归为“简单的bug修复”，亦可通过提交Issue进行方案讨论。
开发者贡献场景主要包括：
- 反馈BUG
- 建议特性
- 改进文档
- 修复问题
- 新增样例
代码风格
请使用pre-commit工具确保代码满足基本要求，安装后会在git commit时自动检查当前提交的代码规范问题。
pip install pre-commit
pre-commit install
新增样例要求
感谢您参与样例建设，为cann-recipes注入更多价值！为了让您的贡献过程更顺畅、方案能更好地契合社区需求，以下是详细的操作指引，供您参考：
提交 RFC，达成方案共识
在正式开发前，建议您先提交一份RFC（请求评议文档，通过创建ISSUE的方式提交），方便与其他开发者充分交流方案细节、达成共识。RFC中辛苦您至少包含以下内容：
- 样例的背景和动机：比如该样例解决了什么场景下的需求、能为其他开发者提供哪些参考价值；
- 核心设计方案：简要说明样例的技术思路、关键模块设计（如模型选型、流程架构等）；
- 预期达成的功能性能目标：例如样例需实现的核心功能、预期的精度指标或性能表现；
- 预计完成时间：方便社区了解开发进度，也便于后续协同支持。
提交PR，完善交付内容
当方案共识达成后，您可以提交对应的PR，并记得关联到之前的RFC。为确保样例质量和可复用性，PR中辛苦您至少包含以下内容：
- 样例代码：请确保代码风格符合社区基本要求，且能通过流水线的code check，让后续开发者更容易理解和使用；
- 优化文档：麻烦您详细说明样例在功能适配、性能优化过程中的重点内容，比如“为什么要做这个优化点”、“用了什么方法实现”、“优化后带来了哪些具体收益（如性能提升X%）”；
- README文档：这是帮助其他开发者快速上手的关键，需要包含两部分：
- 简述：当前样例的核心内容，比如用到的模型、支持的执行设备、已验证的精度/性能信息等；
- 操作步骤：请尽量详细地描述从环境准备到执行样例的全流程，确保其他开发者能顺利复现结果。
一些小提醒，让贡献更顺利
为了避免后续合入时的小波折，还有几个小细节想跟您同步：
- 除了README或文档中需要的配图，合入的代码里请不要包含二进制文件；
- 如果样例涉及第三方数据集的使用，只需在文档中说明数据集的下载方式、使用方法即可，无需直接提供数据集；
- 如果您的修改涉及公共代码（非仅样例内部代码），需要确保能通过CI样例的验证；
- 如果样例开发过程中涉及算子的新增或修改，麻烦先将对应的算子变更合入到算子仓，再推进样例合入。
- 请检查您样例所使用的LICENSE是否合规，建议使用Apache 2.0或MIT等协议，并按照实际情况标注版权信息
样例目录结构参考
本仓库按照具身智能常用组件进行划分来组织目录结构，您可以参考以下结构组织您的代码和文档（样例名建议全部小写，多个单词之间用短中划线连接，比如qwen3-moe）：
├── manipulation # 感知操作类模型样例目录
| ├── sample1 # 您的样例名（如qwen3-moe）
| | ├── train # 训练样例
| | | ├── doc # doc目录：存放优化文档、配图等
| | | ├── src # src目录：存放样例代码
| | | ├── README.md # 上述提到的README文档
| | | └── ... # 其他必要文件（如环境配置文件等）
| | ├── infer_with_torch # 裸torch推理样例，或其他带框架推理样例
| | | └── ...
| | ├── infer_with_om # om模型离线推理样例
| | | └── ...
| | └── ... # 其他必要文件（如环境配置文件等）
| ├── sample2
│ └── ...
├── whole-body-control # 规划控制类模型样例目录
├── navigation # 导航类模型样例目录
├── frameworks # 训推部署公共框架和组件目录
如果在贡献过程中有任何疑问，随时欢迎在社区中交流；再次感谢您的支持，期待您的精彩样例！