我是一名开发者，平时维护的是一个已经持续迭代一段时间的跨链、自托管交易平台。项目并不是一个简单的网页，而是由 Next.js Web、React Native Mobile、TypeScript 公共模块和 TradingView 图表等部分组成。
这类成熟项目的重构，难点通常不是“把某个函数改得更漂亮”，而是修改一处以后，Web、Mobile、公共状态、类型定义和数据链路都可能受到影响。尤其是交易相关代码，金额精度、链 ID、报价单位、缓存键或状态更新时序出现细小偏差，都可能造成真实的业务问题。
以前遇到这种范围的任务，我的第一反应通常是：需要多人分工，先花几天梳理，再分别修改和联调。这次我尝试把 Codex 当成一名可以阅读整个仓库、执行命令并持续验证的工程协作者。最后，一个人用了大约两天就完成了原本预计需要多人持续多天的重构。
一、我没有直接让 AI“帮我重构”
我发现，给 Codex 一句“帮我重构这个项目”，通常得不到稳定结果。大型项目里真正重要的是边界和约束，所以开始前我先在项目规则中写清楚几件事：
- 修改前必须阅读相关的上游和下游代码，不能只在报错位置打补丁。
- Web 与 Mobile 默认同步考虑，共享逻辑优先放进公共模块。
- 不允许为了简化代码而删除已有业务分支。
- 沿用项目现有组件、命名、类型和包管理方式。
- 每个阶段都要执行 TypeScript、ESLint 和自动化测试，最后再做双端人工验证。
这些规则的作用不是让 AI 写更多代码，而是让它知道什么不能做。对于成熟项目，明确“不允许破坏什么”往往比描述“想要什么”更重要。
二、先让 Codex 画地图，再让它动代码
我的实际流程分成了四步。
1. 只读分析
第一轮不允许修改代码，只让 Codex 寻找功能入口、调用链、类型来源、状态归属，以及 Web 和 Mobile 是否存在对应实现。它需要先回答：
- 当前行为由哪些模块共同完成？
- 哪些逻辑应该共享，哪些必须保留平台差异？
- 修改会影响哪些消费者？
- 哪些地方最容易产生回归？
这一步能避免一个常见问题：AI 很快修好了眼前文件，却在另一个端留下行为不一致。
2. 把大重构拆成小闭环
我没有让 Codex 一次改完，而是把工作拆成“公共类型与逻辑—Web 接入—Mobile 接入—测试与清理”几个闭环。每一步都保持改动尽量小，并在继续之前确认现有行为没有被改变。
这样做的好处是，一旦出错，可以立即知道问题属于哪一层，而不是面对几十个同时变化的文件反复猜测。
3. 让验证成为流程的一部分
每完成一段修改，就执行 TypeScript 类型检查、ESLint 和相关自动化测试。出现错误时，我不会只把最后一行错误发给 Codex，而是要求它结合调用链解释根因，并限定修复范围。
自动检查全部通过后，我又分别在 Web 和 Mobile 上做了人工体验，重点检查核心路径、状态切换和两端表现是否一致。
4. 人负责最后的业务判断
Codex 很擅长追踪引用、整理类型、迁移重复逻辑和补测试，但它不能替我判断交易业务是否合理。例如金额单位、报价方向、链上数据含义和异常状态，都必须由熟悉业务的人确认。
我的原则是：代码阅读和机械工作尽量交给 AI，业务取舍和最终验收由人负责。
三、我使用的脱敏提示词模板
下面是我整理后的通用版本，不包含项目内部信息：
这是一个成熟的跨端 TypeScript 项目，包含 Web、Mobile 和共享业务模块。请先只读分析，不要立即修改代码。找出目标功能的入口、上游数据来源、下游消费者、两端对应实现和现有测试，并列出可能的回归风险。方案必须优先复用共享逻辑，同时保留必要的平台差异。未经要求不要删除或简化已有业务分支。实施时拆成可独立验证的小步骤；每一步完成后执行类型检查、Lint 和相关测试。最后给出仍需人工验证的业务场景。
实际使用时，我会在后面补充具体任务、验收标准和不能改变的既有行为，而不是只提供一个文件路径。
四、结果为什么让我意外
这次重构原本预计需要多人协作、持续多天完成，最后由我一个人在 Codex 辅助下大约两天完成。类型检查、Lint、自动化测试以及 Web/Mobile 人工体验都通过了，没有发现明显问题。
我不会把这理解成“AI 写代码不会出错”。更准确的说法是，Codex 压缩了几个非常耗时间的环节：
- 在大量文件中追踪依赖和调用关系；
- 对照 Web、Mobile 与公共模块的实现差异；
- 完成重复但容易遗漏的类型和接口调整；
- 根据检查结果快速定位并修复问题；
- 把测试、代码规范和项目约束持续带进每一轮修改。
真正带来效率提升的，不是一次生成多少代码，而是“分析—小步修改—自动验证—人工检查”这个循环变快了。
五、我踩过的坑
坑一：提示词太宽泛
只说“重构得更优雅”，AI 会自行决定边界，结果可能看起来更简洁，却破坏原来的业务约束。最好明确目标、非目标和验收方式。
坑二：只修当前文件
跨端项目最怕局部正确。必须要求 AI 主动检查上游、下游和另一端实现，否则重复逻辑和行为差异会继续累积。
坑三：把自动检查当成业务正确
类型检查和测试通过只能说明一部分问题。交易项目中的精度、方向、时序和异常状态，仍然需要人工验证。
坑四：一次塞入太多任务
当上下文里同时存在多个目标时，AI 容易混淆优先级。我会把不相关问题拆开，每轮只完成一个可以验证的闭环。
六、给其他开发者的三条建议
- 先建立项目级规则，再开始让 AI 修改大型仓库。
- 把“先分析、再实施、最后验证”写进每次任务，而不是只描述最终效果。
- AI 可以扩大一个人的执行能力，但不要把业务判断和最终验收也外包出去。
这次经历让我感受到，Codex 最有价值的地方不是替开发者写几个函数，而是帮助一个人掌控原本需要多人协作的大型改动。前提是项目有明确规则、验证流程和愿意对结果负责的人。