用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润色。)