研发转产品团队手册

GitHub 把 Copilot 从 GitHub Next（研究团队，专注 horizon 2/3，即 3-5 年时间尺度的"moonshot"）过渡到 EPD（Engineering/Product/Design 正式产品团队）的具体做法和原则：

1. 转移触发条件是信号，不是时间表：当研究团队的想法已经连接到一批有真实需求的代表性客户、且有中等以上置信度证明"这个方案能以新颖的方式解决问题"时（例如开发者反馈"这做到了我自己做不到的神奇的事"），才开始把原型放到更多客户面前做"市场测试"（并非正式流程，只是逐步验证）。
2. 过渡期让研究者本人先加入新产品小队，做知识转移的"种子"：不是简单把项目移交给一个全新团队，而是把原 Next 团队的部分研究员，在一个有限期限内，转入新组建的 EPD 小队，确保知识和产品直觉不断层。
3. 研究员归队的标准是"岗位有人接替"，不是日历时间：即"能不能找到具备了全部必要技能、能顶替这个岗位的人"，只有在继任者到位、连续性得到保障之后，研究员才能回到 Next 团队继续做下一个 moonshot。
4. 产品路线图的所有权必须留在产品团队手里，不能外包给 R&D 团队：负责维护产品、和终端客户反馈循环最紧密的团队，才应该真正拥有和掌控路线图；R&D 团队的角色是提供想法的种子，而不是持续遥控路线图。
5. 工程基本盘（安全、隐私、可用性、可访问性等）是区分"实验"和"正式产品"的合同条款：研究阶段可以不背负这些约束，但一旦过渡到 EPD，就必须补齐这些工程基本盘，这对研究员而言会显得"有点不自然"，需要专门的变革管理去帮助他们适应角色转变。团队里需要同时有擅长"维护服务"的工程师和擅长"定义新想法/新用例"的研究型工程师的组合。