Skip to main content
欢迎修复问题、完善文档、翻译、修正模型移植或提交聚焦的产品改进。可从适合新贡献者的问题开始，搜索已有 issue 与 PR，或在 Discord讨论范围。
1

明确问题与范围

小型修复和文档改进通常可以直接提交。新功能、重大 UI 变化、模型、服务商、平台集成、依赖、公共 API、数据结构或架构重构，应先通过 issue 讨论问题和方向。已有 issue、可用实现或方向共识都不保证最终被接受。
2

遵循职责边界

阅读相关 crate 的 README 和仓库规则。API 或结构变化时更新所有仓库内使用方，不添加兼容别名。服务商默认行为归服务商自身，安全 API 与 unsafe FFI、动态加载分离。模型移植保留影响检查点的结构，并在相同输入上比较结构化输出。注释应解释职责、不变量、上游映射或有意差异。
3

验证修改

阅读完整 diff，运行一次最小相关 debug 检查或定向测试，格式化代码并运行 git diff --check。UI 变化附截图；性能变化提供设备、输入、基线、结果与正确性差异；模型移植提供结构化比较。注明无法执行的检查。
4

提交聚焦的 PR

说明问题、解决方法、重要行为或职责变化和验证。排除无关重构，准备根据反馈修改，不清楚的意见可以提问。
不要提交凭据、模型权重、数据集、生成输出、构建产物或机器专属文件。

​
如何评估提案

维护者考虑产品方向、用户价值与适用范围，以及 UX、架构、性能、安全、隐私、平台支持、测试、文档、依赖与运维复杂度。 提案可能被拒绝、延期、缩小、重新设计，或建议留在核心项目之外。合并后维护责任属于项目，因此即使贡献者后续无法参与，项目也必须能够持续支持。

​
AI 辅助贡献

人类贡献者必须是提交的作者和负责人。AI 对设计或实现有实质帮助时，请披露范围与用途。常规补全、语法纠正和翻译无需详细披露。 提交前亲自审阅完整 diff，对照代码核实生成的主张，复现报告的问题，理解修改与边界情况，并能够继续修订。需要与其他贡献相同的验证和证据。
不要提交自主生成或未经审阅的 issue、PR、审查评论或安全报告。将生成内容视为草稿，提交说明和审查回复应体现自己的理解。
看似未经审阅、含猜测或捏造、贡献者无法解释或修改，或审查成本显著大于价值的提交，可能不经详细审阅就被关闭。不确定时请先询问。 接下来配置开发环境。