每一个资深开发者大概dou有过那种“kan着屎山代码想重写却又不敢动”的绝望时刻。尤其是当你面对一个Yi经运行了几年、逻辑盘根错节的项目时那种感觉就像是让你去拆解一座随时可Neng倒塌的积木塔。Zui近，我就接到了这样一个烫手山芋：对项目 Fread 进行大规模架构重构。

这可不是简单的修修补补。我们需要把底层的依赖注入框架从 kotlin-inject 整体迁移到 Koin，同时还要把导航组件从Yi经停止维护的 Voyager 替换成geng现代的 navigation3。这听起来是不是hen头大？geng别提这还是一个 Kotlin Multiplatform 项目，涉及 Android 和 iOS 双端的逻辑。Ru果按照传统的“人肉”模式，哪怕是我这样的老手，估计也得在这个坑里摸爬滚打一个多月。

但结果呢？在 Codex的强力辅助下我只用了几天就搞定了累计超过一万行的代码改动。今天我就不聊那些虚头巴脑的理论，直接把这次实战中的血泪经验、踩过的坑以及那些让 AI 乖乖干活的“驯兽技巧”分享给大家。

核心哲学：你是架构师，AI 是你的超级实习生

hen多人对 AI 编程有个误区，觉得只要把需求丢进去，它就Neng像变魔术一样吐出完美的代码。大错特错。Ru果你把 Codex 当成一个全知全Neng的神，那你离灾难就不远了。在这次重构中，我geng愿意把它定义为一个“速度极快但需要严格指导的初级工程师”。

为什么这么说？因为对于软件整体的理解、架构的演进方向，我依然比它要深刻得多。我知道代码为什么要这么写，知道未来的 点在哪里。所以我的策略非常明确：复杂的问题我先解决，剩下的重复性、机械性的工作全交给它。

这就是所谓的“Harness Engineering”理念。我们不是在取代自己，而是在把代码库“调教”成 Agent Nengkan懂、Neng自主产出高质量 PR 的状态。人类只负责Zui高层的决策，比如“我们要用 Koin”，而“怎么把这一百个类改成 Koin 的写法”，这种脏活累活，就放心大胆地交给 Codex 吧。

为什么是 Koin 和 Navigation3？技术选型的背后

在开始指挥 AI 之前，必须先明确目标。这次重构主要涉及两个大动作，每一个dou有其不得不Zuo的理由。

告别黑盒：从 kotlin-inject 到 Koin

原本的 kotlin-inject 虽然编译期检查hen安全，但它的注解处理器生成的代码实在太多了。对于一个大型项目来说这些生成的辅助类就像是一个个黑盒，你hen难直观地kan到依赖注入的流程。一旦出了问题，排查起来简直让人抓狂。

所以我决定转向 Koin。Koin 采用 DSL的方式来管理依赖，代码清晰直观，理解成本低得多。geng重要的是它没有那些侵入性的注解，也不需要生成一堆kan不见摸不着的类。对于这种涉及成百上千个类的依赖注入迁移，Koin 的 DSL 结构对 AI geng友好，Codex 模仿起来简直得心应手。

拥抱未来：从 Voyager 到 Navigation3

导航框架的选择geng没得纠结。Voyager Yi经一年多没geng新了基本上处于“半放弃”状态。而 navigation3 的设计非常优雅，不仅支持预测性返回，对 Shared Element的支持也相当棒。对于一个追求极致体验的阅读类 App 来说根本没有理由不换。

但是这个改动量是巨大的。基本上所有的页面dou要改，所有的路由跳转逻辑dou要重写。这恰恰是 Codex Zui擅长的领域——大规模的语法替换和模式迁移。

实战技巧一：提供Zui佳实践，让 AI 有样学样

Codex Zui强大的Neng力是什么？是模仿。

Ru果你直接扔给它一句“帮我把这个项目改成 Koin”，它大概率会给你一堆跑不通的代码，甚至会自己发明一些不存在的 API。但Ru果你先给它一个“标准答案”，情况就完全不同了。

在这次重构中，我针对每一种特定的变geng场景，dou会先人工编写一段完美的示例代码。比如如何将一个 `kotlin-inject` 的模块声明转换为 `Koin` 的 `module` 块。我会先写好：

// 人工编写的Zui佳实践示例
val commonModule = module {
    // 这里展示如何正确注册依赖
    factory { MyRepository) }
}

然后我会告诉 Codex：“照着这个样子，把剩下的几十个文件dou改了。” 这样Zuo的好处是代码geng加可控。因为至少我对于软件整体的理解比它要深入，我知道正确的演进方向。我发挥专长把复杂的问题解决掉，剩下大量的重复性工作再交给它。咱们各司其职，效率直接起飞。

实战技巧二：编写“SKILL”提示词，建立严格的规则边界

对于像导航框架迁移这种极其复杂的任务，单纯的模仿还不够。因为代码里充满了各种边缘情况，比如嵌套的 Navigator、带有参数的页面、特殊的返回结果处理等等。Ru果让 AI 自由发挥，它hen容易被绕晕，甚至把原本正常的代码改坏。

这时候，我们就需要编写详细的 SKILL。这不仅仅是一个指令，而是一份包含背景、任务、工作流程和绝对禁止事项的法律文档。

比如在处理 Voyager 到 Navigation3 的迁移时我写了这样一个 Prompt：

## 任务背景
目前项目使用 Voyager，需替换为 navigation3。
## 任务内容
将继承自 Screen 的类改为 NavKey + Composable 函数。
## 工作流程
1. 找到所有符合条件的 Screen。
2. 逐个重构，创建对应的 NavKey。
3. 注册到 NavEntryProvider。
4. 修改跳转处的引用。
## 绝对禁止
- 禁止修改包含嵌套 Navigator 的页面。
- 禁止修改Yi经使用 navigation3 的页面。
- 禁止改动 navigationResult 相关逻辑。
- 遇到特殊情况直接忽略，不要自作聪明。

你kan，这里面Zui关键的不是告诉它“要Zuo什么”，而是明确“不要Zuo什么”。我在 SKILL 里列了一堆“绝对禁止”的规则，其实就是在规避特殊情况。hen多时候，特殊情况我们自己只需要几行代码或者hen短的时间就Neng解决，但是 AI 则需要考虑hen长时间，复杂度成倍增加。通过这些禁止项，我Ke以极大地降低 Codex 面临的问题复杂度，它只需要模仿我的代码，按部就班地解决剩下的问题即可。

实战技巧三：拆分任务与上下文管理

AI 也是会“断片”的。Codex 的上下文窗口有限，Ru果你在一个对话里塞入太多信息，或者让它连续工作太久，它就会逐渐丧失初心，甚至开始自圆其说产生一些奇怪的幻觉。

Zui开始我直接让 Codex 重构依赖注入时它先跑了好几个小时不仅耗光了好几轮的 Context，也耗光了五小时的用量，问题依然没有被解决。因为依赖关系实在是hen复杂，它也被绕晕了。

吸取教训后我改变了策略：小步快跑，频繁重置。

我会把大任务拆解成一个个独立的子任务。比如先处理“通用模块”的依赖注入，再处理“Android 平台层”的。每完成一个小任务，我就创建一个 Git 提交。然后创建一个新的对话任务 来 Review 这个提交。

为什么要新建 Threads？就是为了丢掉原本的 Context，把代码作为一个全新的任务交给 AI。否则，它可Neng会带着之前的错误记忆继续工作。这种“需求 - 实现 - 测试 - 提交”的闭环流程，让开发过程变得异常稳健。回滚代码时也geng省 Token，心理负担也小得多。

实战技巧四：KMP 项目的特殊处理

Fread 是一个跨平台项目，这给重构带来了额外的挑战。依赖注入不涉及通用代码层，还存在hen多平台实现层，这些情况叠加在一起问题变得geng加复杂。

Codex 一方面对于 KMP 项目了解的不多，另一方面对于平台实现层如何正确处理也不Neng提供一个hen好的解决方案。对于这种特殊情况，我的解决办法仍然是逐步解决问题。

具体来说我会先人工编写部分“脚手架”代码。比如在 `commonMain` 中声明一个 `expect` 函数：

expect fun Module.createPlatformModule

然后在 Android/iOS 平台创建具体的实现：

actual fun Module.createPlatformModule {
    // 平台特定的注册逻辑
}

Zuo完这一步后问题就简单多了。我只需要指导 Codex 把 `kotlin-inject` 模块中的声明同步到这个 Koin 的平台级模块内即可。这样的事情，Codex Ke以完成得非常出色。它不再需要去理解跨平台的底层原理，只需要Zuo简单的“搬运工”工作。

代码审查：人类Zui后的防线

虽然据不可靠统计，这次重构差不多有 70% 的代码dou是由 Codex 完成的，但这并不意味着我Ke以当甩手掌柜。

AI 生成的代码，我个人习惯是一定会全部 review 之后再 accept。Ru果不Zuo任务拆分，那 review 的任务量就太大了我的大脑怕是也难以承受。但正是因为我们Zuo了任务拆分，每次 review 的范围douhen小，我Ke以非常仔细地检查每一个细节。

在修复 bug 或进行重构时工程师经常要求 Codex 建议Neng够覆盖边缘案例或潜在失败路径的测试。虽然这次 Fread 的重构涉及hen多 UI 代码，单测比较麻烦没Zuo，但在逻辑层，我们依然保持了警惕。OpenAI 的工程师也透露，其内部团队Yi将 Codex 用于重构部分基础服务，代码审查通过率提升至 92%。这剩下的 8%，就是我们需要人类经验去填补的鸿沟。

与 AI 共舞的新时代

这次重构累计改动超过一万行代码，若手动完成可Neng需要持续一个多月，但在 AI 的辅助下几天内便完成了核心工作。这不仅仅是效率的提升，geng是工作模式的根本性转变。

我们不再是孤独的代码搬运工，而是指挥千军万马的指挥官。我们定义规则，提供Zui佳实践，处理异常情况；AI 则负责那些繁琐、重复、耗时的细节。

当然这并不意味着编程变简单了。相反，它对开发者的要求geng高了。你需要懂得如何拆解问题，如何编写高质量的 Prompt，如何快速判断 AI 生成的代码优劣。但一旦你掌握了这套“驾驭工程”的方法论，你会发现，那个曾经让你望而生畏的“上万行代码重构”，也不过如此。

所以别再犹豫了。打开你的 IDE，叫上你的 AI 伙伴，开始清理你项目里的那些技术债吧。毕竟未来的软件工程，属于那些懂得如何与 AI 协作的人。

---