AI编程协作进阶：从补全到结对，构建高效人机协作流

1. AI下半场，编程协作到底变了什么

我最近在一个老项目里重构一段核心服务代码，顺手对比了一下自己这两年的工作方式，发现变化比想象中大得多。两年前我用AI主要是让IDE里的补全插件帮我少敲几个字母，生成个样板代码、写个DTO、补个单元测试骨架，本质上是“输入法增强”。但到了今天，AI编程工具已经从补全工具变成了那种坐在你隔壁、能跟你来回对话的结对程序员。我们能做的，不只是让它补全，而是把一整块模块设计、边界划分、异常路径梳理都交给它先出一版，然后我再拿着代码审查清单和架构约束去跟它“评审”。

所以我在聊“程序员如何与AI协作”这个主题时，最想强调的第一件事是：上半场我们是在用AI替代打字，下半场我们要学会用AI替代“试错”。这两者的区别在于，前者AI是工具，后者AI是协作者，但你这个“人”的角色并没有变轻松，反而从写代码的人变成了定方向、立规矩、做验收的人。

1.1 上半场拼的是补全，下半场拼的是“职责交接”

上半场最好用的那批AI工具，解决的核心痛点是“我脑子知道要写什么，但手懒得打完”。于是你敲一行注释，它帮你补一整段逻辑；你起了个函数名，它帮你把函数体写完。这个阶段，程序员是绝对的负责人，AI是给你打工的实习生，干得活还不能太复杂，稍微绕一点的业务逻辑它就容易跑偏。

下半场真正拉开差距的，是你能不能把一件相对完整的事交给AI去“先说想法再说方案再写代码”，并在每个环节设置检查点。比如你想给服务加一个限流能力，传统做法是自己动手搜框架、写注解、配参数、做压测验证。现在比较好的协作方式是：

1. 先把限流的需求拆成几个明确问题：是单机限流还是分布式限流？限流维度是接口、IP还是用户？超限后是排队、降级还是直接返回错误？
2. 把这些问题连同现有项目的技术栈、代码结构、历史约定一起交给AI，让它给出候选方案对比。
3. 让AI按选定方案生成代码草稿，但明确告诉它“生成代码之前，先列出你会改动哪些文件、新增哪些依赖、有没有兼容性风险”。
4. 你拿到草稿之后，再做代码审查和压测。

看出区别了吗？上半场是你给一句指令，AI给你一坨代码，然后你自己改；下半场是你给一堆上下文和约束，AI给你一个带推理过程的可评审方案，你更多在关键的决策点介入。它就是你的同事，不是打字员。这时候“职责交接”就出现了：你把“把方案变成代码”的职责交了出去，把“定义方案和验收结果”的职责留给自己。很多人用不好AI助手，问题恰恰出在交接不清，上下文给少了，约束不提，AI只能猜，猜错了你还嫌它笨。

1.2 协作的本质：把代码库上下文种进AI的短期记忆

为什么同一个AI，在不同人手里发挥的水平差别巨大？我观察下来的根本原因是上下文管理能力。再聪明的模型，如果你不给它足够的项目背景、代码结构、约定和限制条件，它也只能给你一个泛泛而谈的“标准答案”。但真实项目里不存在标准答案，你的项目有自己的历史包袱、命名习惯、异常处理约定，甚至有各种业务上的不可言说之谜。

所以协作的第一步，不是去学什么“魔法提示词”，而是学会给AI“喂上下文”。这里的上下文包括但不限于：

• 项目技术栈：Spring Boot 3.x + MyBatis Plus + Redis Cluster，还是 Go 1.22 + Gin + PostgreSQL？
• 涉及的文件与模块：你正在改的代码在哪个包、哪个类、哪个方法，被谁调用，依赖了哪些底层服务。
• 业务规则与边界：这个接口的输入输出约束、异常类型约定、是否需要做幂等，超时重试策略是什么。
• 现有代码风格：项目里用的是Lombok还是手写getter，全局异常处理器长什么样，数据库操作是走Mapper还是MyBatis-Plus的LambdaQuery。

这些信息你不给，它就不知道。你给得越完整，它产出的代码越贴近你的项目，后边你返工的成本越低。换句话说，AI协作高手和普通用户的分水岭，不在于会不会写花哨的提示词，而在于能不能把模型当成一个刚入职、能力强但啥上下文都没有的新人来看待。你会怎么给新人介绍项目，就怎么给AI介绍任务，再用自己日常沟通的耐心去引导它追问。

2. 提示词是你和AI之间的接口协议，不是咒语

网上关于提示词的讨论很多，动不动就“这是某某领域的黄金提示词”，好像背下来就能解锁AI的全部能力。我自己试过一堆之后，越来越觉得提示词更像是一个“接口协议”：定义输入输出的格式、约束、期望结果，你按协议传参，AI按协议返回。它不需要玄学，但需要结构化。

2.1 一个有用的提示词模板：四要素结构

我现在给AI布置开发任务时，基本都会按四要素来组织，这比我早期那种“帮我写个查询接口”的模糊指令靠谱得多。四要素分别是：

• 角色与目标：你现在是熟悉Java/Spring Boot的资深后端工程师，请帮我完成一个订单超时自动关闭的功能设计。
• 上下文与约束：项目使用xx框架，订单表结构字段如下xxx，超时状态流转规则是xxx，不能使用额外中间件，处理逻辑需要支持幂等。
• 输出格式：请先输出方案设计，说明改动涉及的文件和风险点，再给出核心代码片段，最后附上需要补充的测试清单。
• 验收标准：代码需要符合项目现有的异常处理规范，方法命名遵循现有风格，单测覆盖率不低于80%。

这条提示词看起来不够“魔法”，但实际效果很好。因为四要素把AI最容易犯的错提前堵住了：它不会一上来就写代码（因为要求先出方案），不会引入项目里不存在的依赖（因为有约束），不会写完就完事（因为有验收标准）。

举一个具体例子。我之前让AI生成一个大批量数据导出的异步任务，早期我给的是“写一个异步导出功能”，结果它给我返回了一个直接用Java线程池在Web请求里跑导出任务的方案，完全没考虑进程重启丢任务、导出文件存储、失败重试这些点。后来我改成四要素结构，把“必须用消息队列解耦”“进度要落库”“失败要支持手动/自动重试”“导出文件要上传OSS”这些约束写清楚，它给出的设计立刻专业了很多。所以不是AI变强了，而是我给的协议完整了。

2.2 让AI问问题，而不是瞎猜

我见过太多人跟AI协作时，一口气把所有需求全部说完，然后等着AI一次性给个完美结果。这在实际项目里几乎不可能，因为你自己都没想清楚的细节，AI只会替你做一堆假设。比如你提了一句“对列表数据做分页查询”，分页参数用什么字段名，排序规则是什么，是否需要返回总数，这些你没说，它就会按最通用的方式猜。猜错了，你还要花时间去改，本质上是在帮AI擦屁股。

更好的做法是在提示词里加一句：“如果我的需求描述里有信息缺失，请先列出你需要的额外信息，再开始处理”。这句话能让AI在理解不到位时主动跟你确认，而不是强行输出一个表面上完整、实际上跑偏的结果。当然你不能指望它像真人一样追着你问十来个问题，所以更稳妥的做法是自己先检查一遍需求描述，把那些“你自己都知道但忘了说”的约束主动补充进去。

另外我也建议你在关键任务上让AI输出“它自己的理解”，也就是把你给的需求用它的语言复述一遍，或者让它列出改动的文件清单再动手。这个操作看起来很傻，但能提前发现大量理解偏差。有一次我让AI重构一个工具类的异常处理逻辑，它复述的时候说“会把检查异常转换为运行时异常”，但我本来是想让它保留原有的异常声明，让调用方继续感知。如果没让它先复述，直接让它改，改完就是一次伤筋动骨的回滚。

2.3 给AI“脚手架”：把大任务拆成小单子

再聪明的AI，也不擅长一口气把一个涉及多模块、多表、多条业务规则的大型需求写成完整代码。这既受限于它的上下文窗口，也受限于它的注意力分布——任务一长，后半段的质量就明显下降，甚至会出现前面定义了变量后面忘掉的幻觉。所以我把“拆任务”当成协作的基础功。

怎么拆？按“可独立验证”的粒度拆。比如做一个用户积分系统，不要直接让AI“实现一个完整的积分功能”，而是拆成下面几个子任务：

1. 设计积分账户表结构，并给出建表SQL。
2. 实现积分变动记录的核心Service接口和抽象类。
3. 实现某个具体积分类别（比如签到积分）的发放逻辑。
4. 实现积分余额查询接口的Controller层。

每个子任务做完，你都可以立刻审查、编译、测试，通过后再进入下一个。这就像给AI搭脚手架，它每走一步都踩在稳固平台上，你也能在早期发现问题，而不是到最后攒一个巨大的烂摊子。实测下来，拆完任务后的AI产出质量，比一次性生成整块业务的可用率高了不止一倍，返工量会少很多。

3. 在IDE里搭建一套可复用的AI协作工作流

工具聊再多，最终都要落到IDE里每天的手感上。现在大家都爱讨论该用哪款AI编程插件，我用过不少，Fitten Code是其中比较典型的一款：它把代码补全、对话问答、代码解释这些能力都塞进了IDE侧边栏，属于那种装完就不折腾、日常用起来很顺手的工具。不过我想聊的重点不是做工具横评，而是给你一套能直接搭起来的工作流，不管你用的是哪款插件，思路都一样。

3.1 用AI做“代码考古”，比用它写新代码更值

新代码生成吸引眼球，但我在真实项目里用得最多的场景，其实是“代码考古”：接手一个老模块，明明运行得好好的，但没人说得清楚它为什么这么做。以前遇到这种代码，只能自己一行行读，读完画流程图，再推断设计意图，效率很低。现在我会直接把选中的代码块丢给AI，让它做三件事：

1. 用通俗的语言解释这段代码的业务意图和实现思路。
2. 指出其中值得注意的边界条件和隐含假设。
3. 搜索项目里的其他相关代码，把调用链和依赖关系梳理出来。

AI做这种事特别擅长，因为它读代码的速度比你快，上下文容量也够大，而且不会被“这代码是我写的”这种心理包袱影响。我有一次接手一个库存扣减模块，里面的代码逻辑绕了好几层，还用了很多不规范的位运算。我让AI先解释，它直接指出了这段代码实际上是为了“在并发场景下通过位标志位合并多个库存状态”，并且提醒我某个位移操作必须保持低位对齐，否则会覆盖掉其他状态位。这个提示让我少读了两天代码，也避免了一次潜在的线上Bug。

代码考古还有一个变体：让AI做“影响面分析”。你打算改某个公共工具方法，先让AI搜一下这个方法被多少个地方调用，调用方的使用方式有什么区别，有没有人绕过了异常处理直接用了底层逻辑。这个分析做得越充分，你改代码的时候就越有底气。

3.2 从测试出发：让AI先补测试用例

很多程序员拿到AI之后，第一件事是让它写业务代码，但我反其道而行之，喜欢让AI先写测试。原因很简单：测试本质上是需求的精确表达，你把测试写清楚，就等于把需求边界定义清楚了，再让AI生成实现代码时，它有了一组可以自我验证的标尺。

具体操作是：当你准备实现一个新接口时，先列出一组重要的业务场景，比如正常路径、参数校验失败、依赖超时、重复提交、权限不足，然后让AI基于这些场景生成一组单测骨架。注意，这时候你还没写业务代码，AI生成的单测会编译失败，但没有关系，你要的是那个“预期行为描述”。拿到单测后，你再让AI补充实现，直至测试通过。这个流程看着多绕一步，实际上能把最终代码的质量拔高一大截，也让你的需求实现过程变得可追踪。

还有一个小技巧：让AI生成“负面测试用例”，就是那些验证系统不会做不该做的事的用例。比如“用户余额不足时不能扣款成负数”“删除一个不存在的数据时应返回错误而不是静默成功”“上传文件超过大小限制时应被拒绝”。AI对这类边界条件的补全能力非常强，而人恰恰容易漏掉这些场景。每次让AI补完这些测试，我都能发现自己原本设计里的少量漏洞。

3.3 调试时把错误栈和期望结果一起交代清楚

用AI调试，最大的坑是把错误堆栈丢给它就完事。错误堆栈只是现象，不是原因，AI没有你的业务上下文，只能根据通用知识猜“可能的原因”。真正高效的调试提示词，应该包含下面几部分：

• 完整的错误堆栈或错误信息。
• 你正在做的业务操作和触发条件。
• 你期望发生的结果与实际结果的差异。
• 相关代码片段或文件路径。
• 你目前已经排查过哪几条路（避免AI重复建议）。

举个例子，我之前遇到一个诡异的线上偶发超时问题，错误堆栈指向一个数据库连接池等待超时。我把堆栈丢给AI，它给我列了一堆“可能原因”：慢查询、连接池太小、锁等待……都对，但没用。后来我补充了上下文：“这是在新版本上线后出现的，之前没有，调用量没有明显上涨，被压测的接口才发布两天”，AI立刻调整了分析方向，把注意力集中到“新代码里新增的某个嵌套事务是否占用了更多连接”上，然后真的一下就定位到了问题。

调试时的另一个经验是：把AI当成“排查搭档”，让它先给排查计划，再按计划逐步执行。你不要指望它一步到位找出Bug，但让它帮你列出排除清单、设计验证实验、分析日志片段，会大大加快你的定位速度。这本质上是在用人脑做决策、用AI做搜索和整理。

4. AI Agent正在把“协作”升级成“委托”

聊完了日常IDE协作，再往深走一步，就是现在话题度极高的AI Agent。如果说前面的协作方式还停留在“人发指令、AI给结果”的问答模式，那AI Agent带来的变化是：你能把一件相对独立的事情整个委托给它，让它自己规划步骤、调用工具、检查结果，遇到问题还能自主调整策略。

4.1 代理式编码：什么时候可以放手

先说结论：不是所有任务都适合交给Agent，判断标准是“任务边界是否清晰、失败代价是否可控”。适合委托的任务通常有几个特征：

• 流程明确且有固定套路，比如批量格式化代码、补充Javadoc、生成Mapper SQL、整理CHANGELOG。
• 可以在沙箱或隔离环境中完成，比如生成代码后只改动工作区里的文件，不直接触碰生产配置。
• 结果可以通过自动化手段验证，比如编译是否通过、单测是否全绿、代码风格检查是否通过。

我用AI Agent用得最顺手的天天场景是“提交信息与PR描述生成”。以前提交代码时要写提交信息，写PR描述要列改动点、影响范围、测试验证方法，这些事又琐碎又容易忘。现在我会把这几个步骤交给Agent：先让它读取git diff、分析改动内容、结合项目里的PR模板，生成一份结构完整的PR描述草稿，然后再由我来审查和调整事实细节。这个事先交代的模板其实很关键，你让Agent“看着办”，不如直接告诉它“PR描述要包含背景、改动清单、影响范围、测试验证、风险点”，它就产出得像模像样。

再比如“重构变量命名”。老项目里总有一堆foo、data、temp之类的变量名，你一条条改很费劲，又容易漏。这种任务就很适合Agent：给它划定一个文件范围，告诉它“在保留行为不变的前提下，把语义不清的变量名改成能表达业务含义的名字，并同步更新引用处”，然后让它跑完自己检查编译和测试。你最后再做一次diff review，确认没有引入行为变化。注意，这类任务最好限制在单文件或单个模块，别让Agent自己决定跨几十个文件大动，规模一大，它的自我验证能力就跟不上，容易翻车。

4.2 把AI Agent接进PR流程：自动做代码审查

代码审查是质量防线，但也是团队里最容易被时间挤压的一环。我现在会在自己的项目里加一道“AI预审”流程：每次提交PR之前，先让Agent对diff做一轮自动代码审查，重点检查以下几类问题：

• 是否有明显的逻辑漏洞：空指针、数组越界、资源未关闭、并发安全问题。
• 是否违反项目规范：命名风格、日志格式、异常处理方式。
• 是否存在明显的性能隐患：循环里查数据库、大对象未释放、无索引查询。
• 是否遗漏了配套改动：新增接口没有更新文档、新加字段没有补测试、依赖配置没有同步。

这个“AI预审”跑完，我再决定哪些建议要采纳，哪些要忽略。经验是，AI对“规范性”和“感性问题”的发现能力极强，但对“业务是否正确”几乎没有判断力。所以你千万别把AI预审当成评审结论，它最大的价值是帮你把低级错误提前筛掉，把宝贵的人类评审时间留给真正需要业务判断的地方。

如果你团队用的代码托管平台支持Webhook，甚至可以把AI预审做成自动化机器人：PR创建后，机器人自动拉取diff、跑一轮AI审查、把评论贴在PR下面。我试过之后发现一个非常有意思的副作用：团队里的开发同学开始更认真地自查代码了，因为知道有双“AI眼睛”盯着，谁都不想在PR里出现那种明显的低级错误。工具本身没有多神奇，但它改变了人处理代码的心态。

4.3 多AI协作：不同模型各干各的活

“多AI协作”这个词最近很热，它不是什么科幻概念，在我日常工作中其实就表现为“让不同模型、不同工具各自干自己最擅长的事”。比如我经常同时开着三类AI工具各司其职：

• IDE内的补全型AI：实时感知光标位置，补全代码片段、生成DTO、跳转自动生成的样板代码，主打快和顺手。
• 对话型AI：做设计讨论、代码解释、技术选型分析，主打深和全，适合处理大上下文和模糊问题。
• Agent型工具：执行多步骤的自动化任务，比如代码重构、批量修改、测试生成、PR描述整理，主打稳和独立。

这三类工具我并不是同时用同一个模型，而是看场景切换。有一次做跨端接口联调，移动端和前端同时对接口格式有不同期望，我就用两个对话窗口分别挂着不同偏好的模型，让它们各自站在自己服务的调用方视角分析同一个接口定义，然后把两边的意见汇总起来，再定一个折中方案。这个玩法看起来像是“左脚踩右脚”，但实际上很实用——不同的模型预训练的数据分布、推理习惯不一样，面对同一份需求，它们提出的边界条件和风险点往往有差异，交叉验证之后能帮你看到更多盲区。

当然，多AI协作也会带来一个新问题：你得更清楚每个模型的能力边界。同一款模型，写SQL行，但做架构设计弱；另一个模型写文档很牛，但代码逻辑稳定性一般。用多了你心里自然会有一张“哪个模型擅长干什么”的清单，就像团队里你知道谁的SQL强、谁的运维熟一样。这种“AI资源调度能力”，会慢慢变成程序员的一项新软技能。

5. 守住边界：AI协作的护栏和不信任清单

跟AI协作越深，我越强调一个问题：AI的产出都是“可能性”，不是“事实”。它给你的答案看起来头头是道，但那只是基于概率生成的文本组合，可能对，也可能错得离谱。所以真正的协作高手，不是信任AI更多，而是设计了更多“不信任机制”。

5.1 幻觉分两类，处理方式完全不同

我踩过很多AI幻觉的坑，总结下来幻觉大致分两类：

一类是“事实性幻觉”：AI给你编造不存在的API、版本号、依赖名、类名。你按它写的去配环境，跑都跑不起来。这种幻觉的解决方式最简单：让它给“可验证的出处”，比如官方文档链接、GitHub Releases页面、或者是项目里已有的用法。没有出处的结果，一律当建议，不当结论。

另一类是“结构性幻觉”：AI把代码写得看起来逻辑通顺，但真的放进项目里，会在边界条件下出错。比如它生成了一段缓存更新逻辑，正常情况下没问题，但缓存失效并发穿透时就有Bug；或者它生成的事务代码里，catch块里吞掉了异常，导致回滚没有触发。这种幻觉比第一种更危险，因为它藏在代码深处。对付它只能靠“测试兜底+人工审查”，没有捷径。

所以我的原则是：AI生成代码之前就要求它列出“关键假设”，凡是它主动假设的点，我在审查时都必须逐一验证。比如它会说“这里默认userId不为空”，我就去看调用方是不是真的保证了这一点；它说“此处使用Redis分布式锁防止并发重复提交”，我就去查锁的过期时间和续期机制是否合理。

5.2 安全视角：权限最小化和代码验证

用AI写代码，还要注意安全层面的问题。AI不会主动生产恶意代码，但它很容易在生产环境的安全边界上犯迷糊。比如生成一个文件上传接口时，它可能漏掉文件类型校验、大小限制、路径穿越防护；生成一个SQL查询时，它可能天然使用字符串拼接导致注入风险；生成一个外部接口调用时，它可能不关注SSRF之类的问题。

我的做法是给AI立“安全规矩”，在提示词里显式要求：

• 涉及用户输入的地方，必须做白名单校验和参数化查询。
• 涉及文件读写的地方，必须校验路径和文件类型，防止路径穿越。
• 涉及外部请求的地方，必须限制目标地址范围并设置超时。
• 涉及敏感数据的地方，日志里不能打印明文。

这些安全要求每次写提示词时都带上，而不是靠AI自觉。另外很重要的一点是：AI生成代码一定要在受控环境里验证。你可以在本地或CI流水线里跑单元测试、静态扫描、依赖漏洞检查，而不是直接上了线再观察。我见过有同事让AI生成K8s部署配置，结果缺了资源限制和探针配置，差点把测试环境打崩。这类配置代码，AI生成完之后必须人工对照最佳实践模板逐项核对。

5.3 什么时候该把AI关掉

最后聊一个反共识的观点：不是所有时候都该开着AI。有些任务，AI的参与反而会拖后腿，甚至污染你的思考。

典型场景是“深度设计与复杂调试”。当你需要在一个高耦合的遗留系统里梳理前因后果，或者设计一个跨模块的折中方案时，AI给的“流畅答案”往往是一种陷阱：它让你有一种“这个方案已经有人想过了”的错觉，从而停止进一步思考。这时候我建议你先关掉AI，自己画图、列约束、写方案，等有初步结论了，再打开AI，让它帮你挑战这个方案的弱点和盲区。

还有一个场景是代码评审时。如果你依赖AI做最终评审，你会在潜意识里降低自己的审查标准，“AI都说没问题了，我再看一遍也差不多。”这是危险的。AI没有业务责任感，它不会为上线的Bug负责。最终的验收者必须是你，是你对业务的理解和对质量的判断。所以我会把AI的输出定位成“第一轮扫描”，第二轮、第三轮永远是自己的代码审查加上同事的交叉评审。

6. 我从实际项目里沉淀的协作套路（也许最值得你看）

前面聊了这么多理念和思路，最后我想分享几个我自己在真实项目里反复使用的、可复制的协作套路。这些套路不一定适合每个人，但大概率能帮你少走一些弯路。

6.1 团队提示词库：把个人经验变组织资产

团队里每个人用AI的水平参差不齐，老手写出的提示词效果好，新手抄过去直接也能用。我建议你可以在团队内部建一个“提示词库”，但注意别把它当成一个堆字符串的仓库，要按场景分类并持续迭代。比如我们团队现在维护的提示词库大概分这几类：

这个提示词库真正值钱的地方不在模板文本，而在于里面沉淀了团队的项目背景和踩坑记录。比如我们有一条提示词模板专门用于“从老代码中抽取可复用逻辑”，里面就写清楚了“必须先列出所有调用方再动手，避免破坏现有行为”，这就是一次线上事故换来的教训。新人来了之后，通过这个提示词库能快速了解项目里的坑，AI也能更快进入状态。这也是我理解的“AI协作”真正的团队形态，不只是个人用AI，而是整个团队有一套和AI打交道的基础设施。

6.2 我的“AI in loop”检查清单

我在代码提交前会再过一遍自己的AI协作检查清单，几乎成了肌肉记忆。这里分享出来，大家可以对照着用：

• 需求是否拆成了可独立验证的小任务？还是一个大而全的Prompt？
• 上下文是否完整？技术栈、文件路径、业务约束、代码风格是否都交代清楚了？
• 是否要求AI先输出理解或方案，再开始写代码？
• 代码生成后，你有没有做逐行审查，特别是异常路径和边界条件？
• 有没有要求AI补充测试用例，特别是负面用例？
• 涉及安全、权限、敏感数据的逻辑，是否人工复核过？
• 引用到的第三方库、API是否存在，版本号是否真实？
• 你是在让AI帮你干活，还是在用AI替代你思考？

最后一条是我最经常拿出来自我提醒的。AI工具的价值是放大你的生产力，而不是取代你的判断力。真正危险的从来不是AI不够聪明，而是人在协作中逐渐放弃了思考的责任。

6.3 下一步：让AI参与架构评审和遗留系统改造

往更长远的看，我觉得程序员和AI的协作还会进一步深水区演进。现在已经有很多团队把AI用在架构评审环节：让AI阅读一份架构设计文档，列出潜在的性能瓶颈、单点故障、扩展性问题，再让架构师逐条评估。这个玩法比我前面说的“代码审查”更进一步，因为它考验的是AI对系统级问题的抽象能力，而不是局部代码的规范性。

我自己比较感兴趣的另一个方向，是让AI参与遗留系统改造。老系统最大的问题是“文档缺失、依赖复杂、不敢乱动”。如果用传统方式改造，光是摸清现状就要花掉一半时间。而AI比较擅长做“反编译人类记忆”的工作：把老代码的结构、调用关系、隐式约定一页页读出来，整理成结构化文档和建议改造顺序。这件事的产出，不一定是直接改好的代码，而是一份高价值的“现状地图”。有了地图，怎么走，还是你这个人来决定。

说白了，AI下半场，程序员的竞争力已经不是敲代码速度，而是“定义问题、管理上下文、验证结果”的能力。工具会越来越强，但把工具用好、用对、用出边界感的人，才是真正不可替代的。我自己还在持续摸索这些协作方式，每隔一段时间回头看看，都会发现又有新的套路可以优化。如果你也在天天跟AI打交道，希望这篇文章里的一些思路能给你提供一点参考。