> ## Documentation Index
> Fetch the complete documentation index at: https://koharu.rs/llms.txt
> Use this file to discover all available pages before exploring further.

# 参与 Koharu 开发

> 准备范围清楚、便于审查并能长期维护的改动。

欢迎修复问题、完善文档、翻译、修正模型移植或提交聚焦的产品改进。可从[适合新贡献者的问题](https://github.com/koharu-rs/koharu/contribute)开始，搜索已有 [issue](https://github.com/koharu-rs/koharu/issues) 与 PR，或在 [Discord](https://discord.gg/mHvHkxGnUY)讨论范围。

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

  <Step title="遵循职责边界">
    阅读相关 crate 的 README 和仓库规则。API 或结构变化时更新所有仓库内使用方，不添加兼容别名。服务商默认行为归服务商自身，安全 API 与 unsafe FFI、动态加载分离。

    模型移植保留影响检查点的结构，并在相同输入上比较结构化输出。注释应解释职责、不变量、上游映射或有意差异。
  </Step>

  <Step title="验证修改">
    阅读完整 diff，运行一次最小相关 debug 检查或定向测试，格式化代码并运行 `git diff --check`。

    UI 变化附截图；性能变化提供设备、输入、基线、结果与正确性差异；模型移植提供结构化比较。注明无法执行的检查。
  </Step>

  <Step title="提交聚焦的 PR">
    说明问题、解决方法、重要行为或职责变化和验证。排除无关重构，准备根据反馈修改，不清楚的意见可以提问。
  </Step>
</Steps>

不要提交凭据、模型权重、数据集、生成输出、构建产物或机器专属文件。

## 如何评估提案

维护者考虑产品方向、用户价值与适用范围，以及 UX、架构、性能、安全、隐私、平台支持、测试、文档、依赖与运维复杂度。

提案可能被拒绝、延期、缩小、重新设计，或建议留在核心项目之外。合并后维护责任属于项目，因此即使贡献者后续无法参与，项目也必须能够持续支持。

## AI 辅助贡献

人类贡献者必须是提交的作者和负责人。AI 对设计或实现有实质帮助时，请披露范围与用途。常规补全、语法纠正和翻译无需详细披露。

提交前亲自审阅完整 diff，对照代码核实生成的主张，复现报告的问题，理解修改与边界情况，并能够继续修订。需要与其他贡献相同的验证和证据。

<Warning>
  不要提交自主生成或未经审阅的
  issue、PR、审查评论或安全报告。将生成内容视为草稿，提交说明和审查回复应体现自己的理解。
</Warning>

看似未经审阅、含猜测或捏造、贡献者无法解释或修改，或审查成本显著大于价值的提交，可能不经详细审阅就被关闭。不确定时请先询问。

接下来配置[开发环境](/zh/development/setup)。