ECHO Developer 开发准入

这页是 ECHO 官方开发协作的准入说明。它不是普通用户反馈入口，也不是公开 Issue 的礼貌模板。

仅通过 ECHO Developer 计划审核并获得协作权限的人，才可以参与 ECHO 官方开发、提交可合并实现、访问开发者仓库或使用内部开发资料。 普通用户可以反馈问题、提出建议、提交文档勘误或维护自己的 fork，但这不等于获得 ECHO 官方开发权限。

Developer 身份

这里的 Developer 指维护者确认过的 ECHO Developer，而不是以下任意一种身份：

• 只是拥有 ECHO Pro。
• 只是加了群或发过反馈。
• 只是能访问公开 GitHub 仓库。
• 只是 fork 了项目或本地能跑起来。
• 只是让 AI 生成了一段代码或一份 PR。

Developer 身份代表你已经说明了自己的能力、协作方向、风险意识和可维护性承诺。相关申请入口见 ECHO Developer 计划。

开发前必读

参与开发前至少先读这些内容：

• ECHO Next 开发规则
• ECHO Page 开发者指南
• ECHO 提问与排错指南
• 外部参考：《别像弱智一样提问》

最后一个外部链接标题很冲，但放在这里的原因很简单：开发协作不是猜谜。提需求、报 bug、问实现方案时，必须给目标、上下文、复现步骤、日志、已经尝试过的内容、风险和期望结果。

可以做什么

Developer 可以在权限范围内参与这些工作：

• 修复已确认的问题。
• 编写或改进文档、示例、插件和工具链。
• 改进桌面端、网站、构建、发布、更新源或诊断流程。
• 做小范围、可解释、可回滚的体验优化。
• 针对音频链路、曲库、元数据、远程源、插件系统等方向提交可验证的实现。

提交前要能说清楚三件事：为什么要改、改了哪里、怎么证明它没有破坏现有行为。

不可以做什么

Developer 也不能越过这些边界：

• 不要绕过授权、破解、伪造激活状态或削弱 ECHO Pro 校验边界。
• 不要传播内部仓库、测试包、私钥、授权信息、未发布内容或未确认路线。
• 不要把 ECHO 接口包装成盗链、下载、侵权来源、会员绕过、地区绕过或平台规则规避工具。
• 不要在没有维护者确认的情况下改动下载入口、自动更新、发布脚本、授权服务或公开导航。
• 不要把大范围重构、风格清理、顺手改名混进一个本来很小的修复里。

如果一个改动可能影响用户曲库、播放链路、下载、自动更新、授权状态、数据库迁移或远程服务，先说明风险再动手。

沟通格式

开发协作里不要只发一句“这里坏了”“这个能不能做”“AI 说可以这样改”。请至少给出：

目标：
现象或需求：
影响范围：
相关页面 / 文件 / 日志：
我已经确认或尝试过：
可能风险：
建议验证方式：

如果是 bug，请给复现步骤、版本、系统、日志和截图。如果是功能建议，请先讲真实使用场景，而不是只讲“加一个按钮”。

提交流程

1. 先确认自己是否有 Developer 权限和对应仓库权限。
2. 开工前检查工作区状态，避免覆盖别人或其它进程的改动。
3. 把改动范围压小，只处理当前目标需要的文件。
4. 高风险点先写清楚，再实现。
5. 做最小但有效的验证，不为形式跑低价值长测试。
6. PR 或交付说明里写清楚改动、验证、风险和回滚方式。

文档改动通常只需要检查 frontmatter、链接和页面路径；下载、更新源、授权、构建脚本、桌面端行为改动则必须做对应的 targeted 验证。

维护者可以直接拒绝的情况

以下情况即使代码能跑，也可能被直接拒绝：

• 不是 Developer，却提交官方开发实现。
• 没有目标、没有上下文、没有验证，只丢一大段代码。
• 试图绕过授权、安全边界或平台规则。
• 改动范围明显超过问题本身。
• 影响发布、下载、更新或授权，但没有风险说明。
• 引入难以维护的新框架、新依赖、新服务或复杂抽象。

ECHO 欢迎能长期维护、能解释风险、能证明结果的开发。开发权限不是奖励，也不是身份牌；它是一份对用户、项目和维护成本负责的承诺。