先看看示例
作者提供的示例，实际效果取决于你的输入和使用工具。
输入
【虚构编辑示例】
字段：SQLite中users增加display_name，可空；旧应用只读name，新应用优先读display_name，空时回退name。
条件：允许先加字段再升级；准备把旧name回填到display_name；没有提供备份恢复验证。
输出
【虚构编辑示例】
当前先确认两项前置条件：
• 验证备份能恢复，记录用户数和关键样本。
• 明确新旧应用是否还会修改name，新应用怎样写display_name，何时开始双写或同步，以及冲突以哪个字段为准。现有材料只说明了读法，不能据此保证回填一致或应用可回退。
写入规则确认后，方案可按以下顺序细化：
- 增加可空字段display_name，暂时保留name。
- 部署确定的写入兼容措施，验证新旧应用并存时的更新都能按规则同步。
- 发布兼容读取逻辑。回填只处理仍为空的display_name，并核对回填期间的并发更新，避免旧name覆盖新值。
- 对账用户数、未回填行和抽样姓名，出现异常暂停后续切换。
回退应用前，必须确认name仍是按规则同步后的值；保留字段本身不能证明数据没有过时。备份恢复处理的是另一类问题，需要单独验证。
完整提示词
根据数据库版本、字段变更和读写路径写迁移步骤。先核对新旧应用是否仍会修改旧字段，新字段由谁写入，共存期间怎样双写或同步，以及发生冲突时以哪一份为准。这些条件未定时，先列出需要决定的写入规则，不把先后回填当成一致性保证。
规则确定后，再安排加字段、兼容发布、可重入回填、并发写入核对和切换，避免覆盖迁移期间的新写入。写清继续与停止条件，区分回退应用和恢复数据；回退前要核对旧字段是否仍包含最新值。未知方言、数据规模或锁行为不靠猜测补SQL和时长；没有恢复证据就把它列为迁移前缺口。本次只输出方案。
数据库版本、表结构与字段变更：
{{material}}
新旧读写路径、数据规模和回退能力：
{{context}}