把 GitHub 项目接到 Codex 云端后，我怎样安排协作
把 GitHub 仓库关联到 Codex 云环境，只是协作的起点。更重要的是：需求有没有说清楚，改动有没有经过验证，以及合并以后会发生什么。我把整个过程分成四步：准备环境、说明需求、检查实现、确认发布。
一、先把环境准备好
按目前的流程，新环境在网页或桌面端创建，选择 GitHub 仓库，准备工具和依赖，检查后发布。手机可以选择已经发布的环境发起任务。
这里的“发布环境”是让配置可用于云任务，并不等于产品上线。每个任务有独立工作区；环境更新并重新发布后，已有任务仍保留自己的状态，要使用新配置，应启动新任务。
Flutter 项目尤其要提前准备与 CI 一致的 SDK，检查依赖下载需要的网络权限，并遵循项目的锁文件。工具没装好或依赖下载失败时，先解决环境问题，不能把“代码改完了”当作验证完成。
二、需求可以边做边调整，但变化要同步
“把页面做漂亮一点”很难验收。我会说明当前问题、期望效果和修改范围，再附参考图，指出要参考的是布局、颜色还是交互。
还要列出不能动的部分，例如接口、登录规则和数据结构。是否允许新增依赖、提交代码、创建 PR、合并或部署，也应分别说清楚。
需求不必一次写到完美。看到初版后可以继续调整，但要明确哪些新要求替代旧要求，并及时同步，避免不同任务按照不同版本继续做。
三、看结果，也看验证证据
收到完成报告后，先看改动范围和 PR，再检查对应最新提交的 CI。
格式检查、静态分析和测试解决的问题不同。页面截图有助于检查视觉效果，但不能证明按钮、网络请求和异常流程都正常。
涉及原生 App，还应区分模拟器和真机验证。没有运行条件时，要写明哪些没测、为什么没测、在哪里补测，不能笼统地说“全部通过”。
四、合并之前，先看发布链路
合并 PR 可能触发自动部署。涉及后端或数据库时，要先确认迁移与应用发布顺序、旧版本兼容性，以及失败后的处理办法。
如果网站和原生 App 共用后端，也要分别确认发布状态。网站更新不会自动把新版本安装到用户手机上；后端调整也要考虑尚未升级的客户端。
一个可以直接修改的需求模板
目标：让用户更容易找到文章收藏入口。
现状：入口在二级菜单，首次使用不容易发现。
范围：只调整文章详情页，暂不修改列表页。
参考：附截图，参考按钮位置与间距，颜色沿用现有主题。
约束：保持收藏接口、登录规则和数据结构不变。
授权：允许修改代码并创建 PR；不要合并或部署。新增依赖先说明理由。
验收：已收藏、未收藏、未登录和请求失败状态都能正确处理；窄屏不遮挡正文。
交付：说明改动、提供截图，列出执行过的检查及结果，明确未完成的验证。
我希望云端协作留下的不只是代码，还有可核对的过程：改了什么、为什么这样改、验证到了哪一步。范围清楚、反馈及时、验收具体，才能减少下一轮沟通中的猜测。
本文按当前官方文档整理，产品入口和功能可能变化，实际使用时请以最新说明为准：