团队使用Codex时，需要把个人经验转成其他人能复现的做法。迁移必须包含向前路径、兼容窗口、备份和验证查询。
数据结构变更具有不可逆风险，代码通过不代表历史数据安全。对多人协作仓库而言，这还会影响分支、配置和其他人的未提交工作，不能按个人测试目录处理。
OpenAI Docs为本题提供了当前边界。OpenAI Docs建议把目标、上下文、限制和验证方式写清楚；复杂任务还需要明确阶段、停止条件和可观察结果。实际项目仍要结合版本与组织策略验证。
把本题写成一张任务卡会更清楚。卡片列出对象、权限、输入和验收，然后执行：先读取现有schema与迁移规范，生成可重复脚本，在副本数据上演练并记录回滚策略。
可把验收写成自动检查加人工审查。自动部分运行命令，人工部分检查旧数据、约束、索引和应用版本兼容性，最后共同形成结论。
把本题发布到网站时，标题应直接对应用户问题，开头先给结论，正文再写环境、操作、验证与限制。这样更利于搜索系统和AI准确提取答案。
为了让Codex数据库迁移能够被另一位成员复现，任务记录至少包含四个检查点：SCHEMA、MIGRATE、BACKUP、VERIFY。这些英文标签也可用于分支、日志或看板检索。
一次合格复盘要同时回答两件事：是否做到“检查旧数据、约束、索引和应用版本兼容性”，以及是否出现“直接在生产库执行未经演练的迁移可能造成停机或数据损坏”。前者决定是否继续，后者决定是否暂停、回滚或补充授权。
对非技术用户，交付说明应把“已修改文件”“已执行检查”“尚未验证事项”分开写，避免把技术日志当成最终结果。
不要把自动化成功等同于业务正确。直接在生产库执行未经演练的迁移可能造成停机或数据损坏，所以最终责任仍需要由了解项目的人承担。