ECHO Developer 开发准入

想参与 ECHO 官方开发？先读这页。

官方开发的准入边界、沟通格式、提交流程和验证原则。不是普通用户反馈入口，也不是公开 Issue 的礼貌模板。

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

Developer 身份

这里的 Developer，是维护者确认过的 ECHO Developer。下面这些不算：

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

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

开发前必读

动手前，至少先读这些：

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

最后一个链接标题很冲，但道理简单：开发协作不是猜谜。提需求、报 bug、问实现时，得给目标、上下文、复现步骤、日志、已尝试过的内容、风险和期望结果。

可以做什么

Developer 在权限范围内可以做这些：

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

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

不可以做什么

下面这些红线不能踩。

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

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

沟通格式

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

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

报 bug 就给复现步骤、版本、系统、日志和截图。提功能建议就先讲真实使用场景，别只说「加一个按钮」。

提交流程

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

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

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

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

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

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