提效约70%！去哪儿网AI Coding驱动大型系统重构实践

过去一段时间，AI Coding 已经逐渐进入日常研发流程。对于目标清晰、范围集中的小需求，AI 往往可以快速完成代码修改、测试补充和问题修复，研发同学也很容易通过几轮交互形成闭环。

但这次我们想讨论的不是一次普通的小需求开发，而是一次 15 万行高并发核心系统重构：主流程强依赖、链路复杂、对性能和稳定性要求极高，任何不可控改动都可能带来线上风险。

这篇文章尝试回答三个问题：

• AI Coding 能不能从“辅助写代码”，升级为“驱动大型重构的工程化执行系统”？

• 在长上下文、大影响面、高风险场景下，如何让 AI 的执行过程可控、可验证、可回滚？

• 一次大型重构真正可复用的经验，究竟是提示词、工具链，还是背s后的工程约束和质量闭环？

在这次实践中，我们最终拿到了一组结果：

相比结果本身，更值得讨论的是这套方法背后的工程化思路：先把大型重构变成目标可拆解、边界可约束、过程可验证、风险可回滚的执行系统，再让 AI 在这个系统里持续推进、反馈和沉淀证据。

小需求开发与大型系统重构的差异

小需求开发和大型系统重构的差异，不只是代码量从几十行变成几万行。更关键的变化，是目标从“局部功能交付”变成了“系统行为控制”。小需求只要改对一个功能点，并通过相对明确的测试路径，就能形成闭环；大型重构则必须证明一整条主链路在改造前后仍然行为一致，并且异常、性能、资源和副作用都在可控范围内。

这也是为什么大型重构不能简单套用小需求 AI Coding 的方式。两类任务看起来都是“让 AI 改代码”，但它们对上下文、验证和风险控制的要求完全不同。小需求里，AI 的局部理解偏差通常可以通过几轮交互快速修正；大型重构里，同样的偏差可能会被放大成系统级风险。

大型重构真正难的地方，不是某个类怎么改、某段逻辑怎么搬，而是重构完成后系统行为是否仍然可信。这个可信度来自对不确定性的持续消除。

• 行为不确定。重构前后的请求、响应、异常语义是否一致，是否会在边界场景、历史配置或特殊数据路径下出现隐性差异。

• 影响不确定。改动是否只影响目标链路，还是会误伤主流程、分支流程、缓存、配置逻辑或外部依赖。

• 验证不确定。靠人工测试和少量回归用例，是否足以覆盖线上真实流量里的复杂组合场景。

• 风险不确定。一旦线上出现差异，能否快速发现、定位、止损，并在必要时回滚到原流程。

如果这些不确定性没有被显式处理，AI 的执行就很容易变成“看起来完成了代码改造”，但团队无法判断它是否真的满足上线条件。大型重构最危险的不是 AI 不会写代码，而是在边界不清、验证不足时，它会用自己的隐含假设补齐缺失信息。

传统重构之所以成本高，也正是因为这些不确定性需要大量人工消化。工程师要靠经验梳理系统结构、调用链路和隐性风险，要靠人工测试判断核心功能是否正常，还要在推进过程中持续记录分析结论、改造记录和验证结果。

任何一个环节缺失，都会让重构进入“代码改完了，但没人能证明它真的安全”的状态。对于主流程核心系统来说，这种状态本身就是风险。

让 AI 完成系统重构前必须补齐的四个工程条件

所以，让 AI 参与大型重构的前提，不是给它更长的上下文，也不是让它一次性理解完整系统，而是先把这些不确定性转化成工程约束：目标可拆解、边界可限定、验证可自动化、失败可回滚。只有先把执行环境设计清楚，AI Coding 才可能从“写代码工具”升级为“可持续推进重构的执行系统”。

换句话说，大型重构要解决的不是“让 AI 多写代码”，而是让 AI 在长上下文、大范围、高风险下仍然可控。下一步要讨论的，就是这套可控执行环境应该如何设计。

第一章讨论的是大型重构为什么难：它面对的不是单点代码修改，而是系统级不确定性。要让 AI Coding 进入这种场景，核心不是给 AI 更大的自由度，而是先搭建一套可执行、可验证、可回滚的工程闭环。AI 在闭环里持续推进，人负责关键判断和风险控制。

Harness 负责约束边界，Loop 负责反馈推进

在这套方法里，最重要的两个关键词是 Harness 和 Loop。Harness 解决的是“AI 能在什么边界内行动”，Loop 解决的是“AI 每一轮执行后如何反馈和继续”。两者结合后，AI 才不是在开放空间里自由发挥，而是在目标、边界、工具、验证和停止条件都明确的环境中执行。

• Harness 是约束系统。它定义目标、边界、上下文、规则、可用工具和停止条件，决定 AI 可以做什么、不能做什么、遇到什么情况必须停下来。

• Loop 是反馈系统。它让每次执行都经历计划、修改、验证、分析、记录和判断，决定下一步是继续推进、重试修复，还是升级给人工确认。

没有 Harness，AI 很容易在边界不清时自动补齐假设；没有 Loop，自动执行就容易变成失控的连续改动。大型重构需要的是二者共同工作：先把行动空间收敛，再让执行过程有反馈。

AI Coding 驱动系统重构的四阶段闭环

有了 Harness 和 Loop 之后，重构流程需要被组织成可持续推进的阶段闭环。我们把大型重构拆成规划、设计、执行、验收四个阶段，只有执行阶段真正进入高频 AI Coding，前面的规划和设计主要用来把目标、边界、方案和验证条件对齐清楚。

• 规划阶段。明确重构目标、扫描系统链路、建立指标基线，先回答“为什么改、改到什么程度算成功”。

• 设计阶段。完成技术方案、里程碑拆解、Phase / Task 规划和依赖关系梳理，先回答“怎么改、按什么顺序改”。

• 执行阶段。按照 Task 逐步执行 AI Coding，每次改动都要验证、记录和判断，失败后进入分析和修复流程。

• 验收阶段。汇总测试结果、Diff 结论、指标效果和发布证据，判断是否具备进入下一阶段或上线收口的条件。

这个流程的重点不是把步骤画得更复杂，而是让每一步都有明确输入、输出和判断标准。AI 可以承担大量高频执行，但它不能替代流程本身。

人负责方向与风险判断，AI 负责高频执行与沉淀

大型重构里，人和 AI 的分工必须清楚。AI 适合做信息整理、代码执行、测试反馈、Diff 分析和文档沉淀；人必须负责目标定义、边界判断、架构取舍、风险接受和上线决策。否则，AI 很容易在缺少判断标准的情况下，把执行效率变成风险放大器。

这意味着人的工作不是退到流程之外，也不是每一步都手写代码，而是在关键节点做判断、设边界、看证据。AI 的价值则体现在高频执行和沉淀上，把大量重复、细碎、可验证的工作持续推进下去。

从重构目标拆到 AI 可稳定执行的 Task

大型重构不能直接把“大目标”交给 AI。目标越大，隐含假设越多，AI 越容易在不确定的地方自行补齐。更稳妥的做法，是先把重构目标拆成里程碑，再拆成 Phase，最后拆到 AI 可稳定执行的 Task。

• 里程碑用于表达阶段性业务目标，例如先保证行为一致，再做性能优化，最后做灰度收口。

• Phase用于表达一组有共同验收目标的任务集合，便于阶段性 Go / No-Go 判断。

• Task是 AI 可稳定执行的最小工程单元，最好接近一次小需求改动，并且能独立验证、独立回滚。

一个合格的 Task 不能只有一句“实现某能力”。它至少要说明输入、输出、修改范围、不修改内容、验收标准、风险点和回滚方案。Task 越清楚，AI 的执行空间越稳定，后续验证和排障也越容易。

Task 文件必须定义执行输入、验证标准和风险出口

Task 是 AI 可稳定执行的最小工程单元。但要让 AI 稳定执行，Task 文件不能只写一句“实现某能力”。它必须提前定义执行输入、验证标准和风险出口，让 AI 知道该改什么、不能改什么、做到什么程度算完成，以及遇到什么情况必须停下来。

• 做什么。写清任务目标、业务背景、交付物和成功状态，避免 AI 只理解局部代码改动，却忽略这次改动服务的阶段目标。

• 改哪里。写清影响范围、涉及模块、代码改动清单、依赖关系和预期输出，让执行边界足够具体。

• 不改哪里。写清不能触碰的链路、接口语义、配置项、外部副作用和历史兼容逻辑，减少“顺手优化”带来的系统风险。

• 怎么验。写清编译、单测、自动化测试、Diff、回归和性能指标等验证标准，让 Task 是否通过有明确证据。

• 失败怎么办。写清回滚方案、失败策略、Human Gate 和停止条件，让 AI 不会在异常状态下继续扩大改动范围。

Task 文件的作用不是“给 AI 一段需求描述”，而是把一次改动约束成可执行、可验证、可恢复的小闭环。Task 写得越清楚，AI 的自由发挥空间越小，后续排障和复盘成本也越低。

产物沉淀：

Task 执行完成后，还必须沉淀执行证据。代码写完不代表 Task 完成，真正完成的标准是执行文档、执行记录、验证结果和判断结论都可以被后续任务复用。

项目总览文件是 AI 项目的执行入口和状态源

当 Task 数量变多后，单轮对话不可能承载全部上下文。大型 AI Coding 项目需要一个项目总览文件，作为文档导航页、状态页、上下文恢复入口和自动化执行入口。

• 项目定义。记录背景、目标、范围边界、关键约束和最终验收标准。

• 过程产物链接。聚合方案、架构、任务拆解、Task graph、验证文档和部署记录。

• 执行状态。记录每个里程碑、Phase、Task 的进度、通过情况、阻塞原因和下一步动作。

• 上下文恢复。让 AI 在新会话里能快速定位当前项目状态，而不是重新从头理解整套系统。

自动化执行不是让 AI 一直跑，而是让 AI 按项目总览和 Task graph 找到下一个可执行任务，进入 Harness + Loop 执行；完成后，再把执行记录、验证结果和产物链接回写到总览文件。这样项目即使跨会话、跨阶段，也能持续推进。

项目总览文件本质上是大型 AI Coding 项目的状态源。它把“人脑记住的项目进度”变成“机器可读取、团队可复查、任务可接续”的工程资产。

Task 通过不等于可以直接全量上线。Task 级验证只能证明单次改动在局部范围内可控，发布级验证要证明新流程在真实流量下行为一致、指标稳定、异常可回退。

• 影子双跑。新旧流程同时运行，用 Diff 对比核心结果，先在不影响线上行为的情况下收集差异。

• 灰度切流。逐步提高新流程真实流量占比，避免一次性全量切换带来的不可控风险。

• 监控放量。持续观察成功率、耗时、错误率、资源消耗和核心业务指标，判断是否满足继续放量条件。

• 异常止损。指标超过阈值时自动切回原流程，并保留排障证据，保证问题可定位、可恢复。

发布级质量控制把“开发正确”推进到“生产可控”。只有当真实流量下的行为一致性、性能指标和回退能力都满足要求，大型重构才具备上线收口条件。

第二章讨论的是工程闭环本身：如何用 Harness 约束边界，用 Loop 推动执行，用 Task 和项目总览文件承载上下文。第三章进入真实案例，看这套方法如何落到一次主流程核心系统重构中。

这不是一次边缘工具改造，而是一次涉及搜索和填单页链路的核心系统重构。它的关键挑战不只是代码量大，而是必须在高并发、强依赖、性能敏感的真实生产环境里证明行为一致、指标稳定、异常可回退。

AI Coding 模型：业界主流Coding大模型

近15w代码、高并发系统重构。

这个风险等级决定了后续写法：我们不能只讲“AI 写了多少代码”，而要先交代系统复杂度、业务痛点、重构目标和验证条件。只有把这些背景说清楚，后面的里程碑拆解和发布控制才有上下文。

本次重构涉及多个主流程核心应用。系统经历了长期业务迭代，承担了更多业务支持的关键能力，既有历史逻辑复杂，也有高 QPS 和性能约束。

系统当前存在的问题：

系统问题也不是单一维度的“代码老化”。不同业务方在系统中各自维护数据源，数据口径容易分散；原本独立的系统随着业务演进逐渐形成强耦合，跨系统调用带来维护和测试成本；计算量与报文量持续增长，也让远程调用链路暴露出性能瓶颈。

重构目标：

• 合并搜索核心链路系统；

• 三方数据源统一，解跨系统业务口径策略不一致问题；

• 整体规划流程系统性能优化，搜索P50耗时190ms->120ms, 节省30%服务器资源。

重构里程碑划分

确定目标和边界后，下一步不是立刻写代码，而是决定推进顺序。大型重构的拆解顺序，不能只按“哪个模块好改”来排，而要按“风险能否逐步收敛”来排。

这个顺序背后的原则是：先保证行为一致，再优化结构和性能，最后灰度收口。也就是说，收益不是第一优先级，先让系统行为可信，才有资格继续推进性能优化和旧链路退场。

在整体里程碑中，我们先展开 M1。M1 的目标不是一次性完成全部系统合并，而是先让选举系统具备本地包装能力，并通过一致性验证证明新旧链路行为可对齐。

目标明确之后，更重要的是边界明确。大型重构不是让 AI 自由改系统，而是先限定可改路径、不可改代码和验收证据，再把可执行部分交给 AI。

• 修改范围护栏。只改 相关链路和实现承接，其他搜索、缓存、选举流程代码不动。

• 行为语义护栏。请求、响应、异常语义保持不变，核心链路差异必须通过 Diff 收敛。

• 运行安全护栏。通过影子双跑、灰度切流和自动止损控制发布风险，不做一次性全量替换。

• 副作用护栏。影子链路不写 MQ、Redis 或外部系统，新增验证不能影响主流程稳定性。

M1 被拆成 9 个 Phase、34 个 Task，按依赖关系逐步推进

在 M1 内部，我们继续把工作拆成 9 个 Phase、34 个 Task。这里不直接平铺 34 个 Task，而是在 Task 之上增加 Phase，是为了让路线更容易理解，也便于按阶段设定验收条件。

• Phase 表达一组有共同目标的任务集合，可以作为阶段性推进和验收单元。

• Task 表达 AI 可稳定执行的最小工程单元，每个 Task 都有独立目标、边界、验收和回滚方式。

• Task 类型区分为 MANUAL、CODE、CONFIG、VERIFY，其中 CODE 是主要进入 AI Coding 的部分，MANUAL 和关键 VERIFY 需要人工判断。

• 执行顺序按 Task 依赖关系推进，而不是让 AI 随机挑选任务执行。

这样拆解后，AI 执行的不再是一个模糊的大型重构目标，而是一系列接近小需求粒度、可以逐步验证的小闭环。项目总览文件负责记录当前进度、任务依赖和执行状态，自动化执行则按总览文件找到下一个可执行 Task。

项目总览文件汇总背景目标、方案产物、Phase / Task 进度和执行状态

路线图只能说明“任务怎么拆”，项目总览文件负责说明“项目跑到哪里”。它把仓库、背景目标、方案产物、Phase / Task 状态和执行记录汇总在一起，成为跨会话恢复上下文的入口；而到单个 Task 层面，还需要继续沉淀执行记录，避免代码改动和验证证据散落在不同会话里。

Task 执行记录沉淀代码变更、测试结果、部署信息和风险判断

线上 Diff 进入拉取日志、聚类分析、问题定位、修复方案和人工确认闭环

在这个项目里，Diff 不是问题结论，而是下一轮修复的输入。影子双跑可以把新旧流程放到真实流量下对比，但 Diff 出现之后，真正重要的是让差异进入“聚类、定位、修复、复验”的闭环。

• 拉取 Diff 日志。根据 traceId、时间、环境补足上下文，避免只看单条差异就下结论；

• 聚集性分析。把相似差异归类，识别高频异常和集中出现的场景；

• 问题定位。结合模块、配置和代码路径判断可能根因；

• 生成修复方案。由 AI 辅助给出改动建议和补充验证建议；

• 人工确认后执行。是否采用、如何灰度、是否回滚必须由人确认，再交给 AI Coding 进入下一轮修复。

这也是 AI Coding 在大型重构里的另一个价值：它不只写代码，也能参与线上差异分析和修复方案生成。但排障边界必须清楚，AI 可以辅助聚类、定位和建议，关键风险判断仍然由人拍板。

最终结果需要回到证据本身。大型重构的收益不能只看交付速度，还要同时看行为一致、发布可控、性能改善和资源收敛。

这些结果成立的前提，是前面的行为一致性验证和发布级质量控制。效率、性能和资源收益只有在系统行为可信、线上风险可控的前提下，才真正有工程价值。

回到这次重构本身，AI Coding 真正带来的变化，不只是让 AI 多写了一些代码，而是把一个高风险、长周期、强依赖验证的系统工程，拆进了可以持续推进的工程闭环里。

对于大型系统重构来说，最难的部分往往不是某一段代码怎么改，而是这些问题能不能被持续控制住：目标是否清楚，边界是否明确；任务是否能拆成可执行、可验收的单元；每次修改是否有自动化验证和执行证据；线上风险是否能通过 Diff、灰度、监控和回滚机制收敛。

在这个过程中，AI 更适合承担高频、重复、上下文明确的执行工作，例如代码迁移、接口适配、测试补充、日志分析和文档沉淀；而人仍然需要负责目标判断、方案取舍、风险识别和最终确认。

这也是大型重构中比较重要的一点：不是把决策完全交给 AI，而是让 AI 在清晰的工程约束里工作。约束越清楚，AI 的产出越稳定；验证越充分，团队对自动化执行的信任越容易建立。

从实践看，Task 是 AI Coding 能否稳定运行的关键单元。一个好的 Task 不只是“要改什么”，还应该说明为什么改、改到哪里、如何验证、风险是什么、完成后留下什么证据。

当 Task 足够清楚时，AI 的执行就不再依赖某一次对话里的临场发挥，而是依赖结构化输入、自动化验证和持续沉淀。对于大型重构，这比单次生成代码更重要。

一次重构结束后，真正值得保留下来的不只是代码本身，还包括任务拆解方式、项目总览文件、验证脚本、Diff 分析流程、发布检查项和风险处理经验。

这些资产沉淀下来之后，下一次面对类似的大型改造，团队就不需要从零开始摸索，而是可以复用一套更成熟的工作方式：先把不确定性变成工程约束，再把工程约束交给 AI 和自动化流程反复执行、验证和修正。

因此，AI Coding 在大型系统重构中的价值，可以概括为一句话：它不是替代工程治理，而是把工程治理变得更细、更连续、更容易被执行。