用AI编程助手写点简单的小功能，谁不会？可一旦要动点“大手术”——比如新功能开发、系统集成——不少人就会陷入一种“我是不是智商税交多了”的无力感。

本来目标很明确，AI一开始也挺聪明，左看看右看看代码，问几个问题，甚至还给出点靠谱方案。可一到真动手写代码，画风突变：代码集成得四不像，边界条件忘得一干二净，AI还一本正经提出些能直接把系统搞崩的改动建议。

于是你发现，自己不是在写功能，而是在debug AI的迷之思路……

其实，问题不是AI不行，而是我们用错了方法。别把AI当实习生，什么都记得牢牢的。它们更像天赋异禀但记性极差的咨询顾问——短时记忆就那么点，还经常“跑题”。

明白这一点，开发流程就该升级了。

真正的难题：上下文越积越乱

和AI助手聊得越久，问题越大。每一次“走错路”，每一个被推翻的假设，每个查过的无关文件——对AI来说，都是不可磨灭的“历史遗留”。不像人类能自我总结、自动遗忘，AI只会越背越重，还全都塞在短期记忆里。

想象一下你专心写作时，有个人把你所有草稿、废话、删掉的段落都大声朗读一遍。信噪比越来越低，最后脑袋瓜子只剩“乱”。

这也是为什么有时候你和AI规划得头头是道，真到实现阶段却步步踩坑。AI虽然最后想明白了，但所有的歧路亡羊都还“留在脑子里”——一不小心就又走回老路。

解决办法不是少用AI，而是让你的开发流程更适合AI的“脑回路”。

双代理模式登场

最靠谱的做法很简单：一人（代理）负责探索，一人（代理）专职实现，各司其职，分工明确。

第一个AI代理，姑且叫“探索者”：它就像项目里的“侦查兵”，专注于搞清楚代码结构、问关键问题、梳理集成点，最后输出一份清晰明了的开发方案。这步的核心是“把问题想透、把方案写清”。

第二个AI代理，叫“实现者”：它啥都不带入，只接受探索者的成果文档，干净利落地写代码。没有历史包袱，没有莫名其妙的上下文污染。

其实，这不就是高级工程师和开发小组的惯用套路吗？架构师负责搞清楚全局、制定方案，开发同学根据方案实现。哪怕同一个人，方案和实现也是“两副面孔”——前半场思考，后半场执行。

第一阶段：带约束的探索

首先，你要清晰地描述清需求。别小看这一步，后面一切的质量都靠它打地基。

给探索者AI指明方向：要查什么模块，只看相关代码，别瞎溜达。比如要给用户认证系统加OAuth，就请它“专注查auth相关文件”，别让它在全仓库里迷路，把宝贵的上下文窗口全浪费在无关代码上。

还得加一句“魔法提示”：“如果你有任何不确定，先问清楚，别自己脑补。”

这句话的力量堪比“防脱发洗发水”——大模型如果不被约束，最喜欢自作聪明地瞎猜，但你明确要求它“有疑问就问”，它反而会提出不少专业、靠谱的问题。

这些问题要认真答，别怕麻烦。比如它问“软删除用户还能登陆吗”，你别只回答“不行”，而是把用户删除的整个生命周期讲透，顺带把相关联的系统规则都说清楚。

随着探索推进，AI会不断提问、查代码、细化理解。直到有一天，它自信地宣布：“我明白了，这就是完整方案。”

关键交接点

大部分人到这步就掉坑里了——一看到计划靠谱，立刻喊：“好，直接在这个对话里实现吧！”

千万别！这一步是分水岭。

你要让探索者AI不是写“操作指南”，而是写“开发文档”给另一个开发者看。二者差别大得很。

“操作指南”像是：“给User模型加个deleted_at字段，把UserService.get_active_users()方法改成排除已删除用户。”

“开发文档”则是：“models/user.py里的User模型，当前没有软删除机制，delete()方法会直接删除。要做软删除，可以加个deleted_at时间戳。services/user_service.py的UserService负责返回用户集合，这里需要过滤掉已删除用户。admin/users.py是管理后台用户列表，数据来源于UserService。”

前者是“照做”，后者是“指导思路”——既指出重点位置，又保留实现灵活性，方便后续开发者（AI）独立思考。

交接文档里最好有：

• 相关文件路径和大致内容
• 集成点以及原因
• 可能的实现方案和权衡
• 具体需求、业务约束
• 你的代码风格偏好

这就是“交接文档”。

第二阶段：清爽实现

新开个对话，把交接文档和最初的需求一起贴进去。

你会看到有趣的变化：

如果探索者AI的文档写得够好，实现者AI通常会很快领会架构，认认真真看了相关文件后说：“我可以开始写啦。”

这句话其实是个“质量信号”：能顺利开工，说明文档清晰全面。如果还要追问一堆细节，说明探索阶段还差点火候。

此时实现者AI有如下优势：

• 上下文极为干净，只关注核心信息
• 没有探索阶段的“杂音记忆”
• 站在“局外人”的新视角，容易发现集成盲点
• 可以自主做实现决策

通常写出来的代码，更贴合现有架构，风格一致，集成自然。

为什么这招真管用？

大模型不像人类“选择性遗忘”，它会把上下文窗口里的每个token都平均权重地处理。你30条消息前的迷惑发言，和刚刚描述的需求影响力几乎一样大。

重置上下文，不只是省点token，更是把那些“误导信号”一锅端，避免影响实现。

这就像两种会议：

• 一种东拉西扯两小时，每条歪路都讨论一遍，最后还要带着一堆废话来做决策
• 一种是有人拿一页纸，清清楚楚总结了重点，大家直接讨论执行

后者的决策效率和质量，自然高出一大截。

实战举例

比如你要给数据平台做数据导出功能。系统里权限复杂，数据格式多，敏感信息边界一堆。

“探索者”AI就要：

• 仔细梳理权限系统，弄明白各项控制规则
• 查现有导出代码，保证风格一致
• 找出敏感数据的过滤点
• 问清导出需求：格式？大小？异步还是同步？
• 看看类似功能怎么做错误处理和日志
• 最后出一份覆盖数据流、权限、格式转换、异常处理的开发计划

交接文档可能会写：“services/reports.py里的报表生成用的是Celery异步任务，大数据集建议也用这个模式，防止请求超时。权限校验在服务层，不是在API层，参照ReportService.get_report()。数据脱敏统一用utils/sanitize.py。”

“实现者”AI看了文档和相关代码，照着现有架构写导出功能：用Celery做异步、在服务层校验权限、用统一的脱敏工具。

如果让同一个AI从头到尾搞，很容易出现风格错乱：权限校验位置不对、处理方式不统一、同步异步混用……这些细节虽然不致命，但积累多了，代码库就会越来越难维护。

什么时候适合用双代理？

不是所有需求都需要这么大阵仗。加个小工具函数、修个显眼bug，让AI单兵作战就够。

这套流程特别适合：

• 涉及多个系统模块的新功能
• 集成比“单点突破”更重要
• 需要新代码无缝融入既有体系
• 对架构理解有要求
• 你已经反复给AI补充上下文，依然沟通不畅

一个简单判断：如果你觉得“这活儿最好有高级工程师先审设计”，那就用双代理。

模式变种

有些团队更“花哨”——

• Architect（架构师）代理专门做方案评审
• Reviewer（评审员）代理专门挑刺
• Documenter（文档员）代理专门写用户文档

核心原则不变：每个代理只关心自己那一块，脑子越干净越好。

隐藏的好处

除了代码质量提升，这个模式还有个隐形福利：逼着你自己把需求想明白。

要写出合格的交接文档，自己必须先厘清思路。探索者AI问得越细，你越不能蒙混过关，反而提前发现了需求歧义和漏洞。

很多bug其实不是AI写得差，而是“设计阶段就没想明白”，这个流程刚好把问题提前暴露了。

实用建议

实际用的时候还有几点小窍门：

• 一开始就告诉探索者你的需求和相关目录，别让它全仓库乱跑
• 探索阶段AI问的问题一定要认真答，哪怕看起来“很傻”，有些问题其实暴露了隐含冲突
• 交接文档不用长，三四段就行，重在清晰，不必面面俱到
• 如果实现者AI还追问很多细节，说明探索阶段还欠火候，可以考虑补充
• 你的代码风格（格式、文档、命名）要明说，AI不会“耳濡目染”吸收

局限性

这套方法不是万能的。实现者AI照样可能写出bug，集成阶段也还是会有意外。代码评审依然必不可少。

但它至少解决了“上下文污染”这个大难题，让复杂功能开发变得可靠许多。

拓展思路：不只有编程

只要是复杂任务，AI都适合用这个分阶段流程：先调研/探索，产出清晰文档，再执行/实现。

领域不同，模式可变，但核心铁律不会变——认知清晰，远胜于“模型参数大”。一个“中等资质”模型，拿着干净简洁的上下文，往往能干掉“天赋型选手”却被上下文垃圾拖后腿的“天才”。

（本文由人类原创，并在部分环节借助AI润色。）