2025：回忆我实践AI编程的一年

2025 年对很多开发者来说是编程方式彻底革新的一年， 从最初的AI Tab补全代码，到现在通过编码Agent完成完整功能，并自动构建和测试. 编程这件事已经从“亲自动手写代码”转变成指挥若干个Agent进行功能迭代。但这趟旅程并不是单纯的效率提升，它也暴露出新的瓶颈和新的责任。这里记录下一年来的经历和思考，既是给自己的备忘，也是与同行分享。

一、从 Tab 补全到多 Agent：写代码已不再稀缺

曾几何时，编程是一项门槛极高的智力活动, 我们做好一个功能需要精准的需求分析、对齐上下游依赖、在不同组件间反复权衡，还得在Stack Overflow 和文档里寻找线索和方案。

后来我们有了AI智能补全，模型帮我把函数名字和参数猜了个八九不离十，这个阶段模型补全的效果还不是特别好，经常会”脑补”一些函数和方法，但是在类似CRUD等固定模式的场景下, Tab自动补全的确能让我少写很多代码。但是到了2025年的下半年, ChatGPT 5.1 /Gemini 3/Claude 4.5 等大模型相继发布,配合Claude Code等工具，AI对需求的完成度有了很大的提升, 我不需要与AI反复拉扯, 大多数功能一次就能让我满意。写代码这件事本身，已经从“稀缺资源”变成了“供过于求”。代码井喷之后，我才发现真正的挑战转移到了别处。

二、真正的瓶颈：Review 代码比写代码更累

代码生成的速度越快，等着我去 review 的代码就越多。以前一个需求做几天算大迭代，现在 Agent 跑一天就能攒下几千行代码。 尤其是多个需求一起处理的时候，没有及时Review的代码越来越多, 这会产生两个问题: 首先AI可能会误解需求，产生了一堆屎山代码, 需要返工重写。第二则是代码变更太多，review的时候压力非常大，毕竟理解别人的代码是比写代码更痛苦的事情。

这种落差让我得出一个结论, AI 可以帮你写代码， 但是让AI写”正确的代码”，却需要我们来”教”, 我们需要给AI适当的约束与指引,而不是无脑的接受AI生成的代码.

三、从测试驱动开发 (TDD) 到规范驱动开发(SDD)

为了提升AI生成代码的正确率，在新的项目中，我借鉴了测试驱动开发（TDD）的思想。其核心转变在于：将完善的测试用例，作为对AI行为的强约束与验收标准。 让AI在每次修改后自动运行测试，能有效引导其产出符合预期的代码。

同时，AI的应用也大幅降低了我们编写测试用例的成本。以往构造复杂的Mock对象和测试数据令人头痛，现在只需描述案例的场景，AI便能快速生成对应的测试用例。对于单元测试，直接让AI根据函数逻辑生成即可。集成测试会更加复杂，我的做法是让AI基于需求文档和技术方案，构建场景化的测试用例。这里存在一个关键问题：如何保证测试用例本身的正确性？ 我目前的一种尝试是“双重校验”：让另一个AI模型对生成的测试用例进行评审，在此基础上再人工复审,进行测试用例的微调，以确保核心场景得到覆盖。最终再让AI根据场景化的描述内容,生成完整的测试用例.

但问题并未彻底解决——AI对我的需求理解仍时常出现理解偏差,尤其是在我偷懒给一句话需求的时候. 直到某天我接触到“规范驱动开发”（Spec-Driven Development) 其核心是提供给AI完整清晰且可验证的的需求规范. 明确功能边界、输入输出格式、业务规则等细节，从源头避免AI“天马行空”的错误发挥。

那我们在实践中是要用TDD还是SDD呢? 我觉得这不冲突, SDD着眼于更高维度、更前期的精确意图定义，而TDD则侧重于后期质量保障与行为约束, 主要目的是通过测试用例验证“AI做得对不对”。从某种哲学视角看，TDD可被视为SDD在“验证”这一环节的具体实践延伸。

不过SDD的概念实在有点抽象, github上有一个仓库 https://github.com/github/spec-kit 可以让大家深入了解SDD

四、Plan模式：将模糊意图转化为清晰蓝图

感谢卷起来的大模型厂商和IDE厂商, 现在多数AI IDE/Agent都提供了Plan模式, 在Plan模式下，我提供初始版本的需求描述, Agent便会主动搜索代码获取必要的上下文之后, 最后就需求中的模糊点对我发起提问，我再逐个澄清,补充细节. 经过多轮交互，将那些隐藏的假设与细节一一阐明后，智能体最终会生成一份结构化的“可执行任务清单”。这本质上是一个将人类模糊意图，通过对话逐步固化为机器可执行蓝图的“对齐”过程。实践反复证明：在规划阶段多投入的一小时，往往能在后期节省数小时的调试与返工时间，它直接决定了最终成果的质量上限。

下面就是我使用Agent的Plan模式的几个截图. 可以看到相比写Spec规范,Plan模式非常方便

Claude Code的Plan模式

## 五、多 Agent 协作

最后再说一下, 要想充分利用赛博程序员的价值,多智能体并行编程少不了. 多个智能体并行工作，我暂时分两种模式。

1. 第一种是职责清晰的，可以使用多个不同角色的Agent进行开发。 例如我在调度系统运营平台重构中, 后端的Agent负责完成接口和业务逻辑开发， 前端的Agent则根据接口文档完成页面功能重构。 这种方式的并行开发需要先确定文档，定义好接口, 再分头执行。就像一个真实的团队一样.

2. 第二种是同一个服务的多分支开发： 这里我们要充分利用 git worktree 的特性. 把不同分支映射到机器上的独立目录，每个 Agent 在自己的目录里跑任务，相互隔离, 互不影响, 完成开发之后再通过正常的MR流程合并代码就可以了.

下面我列出了常用的 git worktree 相关的命令:

# 查看所有工作树
git worktree list

# 创建新分支并关联
git worktree add -b <新分支名> <路径>

# 创建并关联到现有分支
git worktree add <路径> <分支名>

六、流程与沉淀：让 AI 拿到足够的上下文

在互联网公司工作的这些年里,我们一直强调敏捷开发. 小步快跑,快速迭代上线. 像我所在的团队一直保持较小的团队规模，一般的需求沟通完就能快速开干,开发过程中遇到问题, 转个背讨论一下,很快就解决。 但是当AI Agent成为我们的队友. 因为有太多的”暗知识” 隐藏在团队的成员之间, 这些”暗知识”可能是特殊的业务规则、一些历史包袱、奇怪依赖、默认约定、甚至是“没有文档但大家都知道”的框架。然而AI只能基于我们明确给予的上下文工作,我也在思考和探索如何让AI学习到更多的”暗知识”. 在构思这篇文章的时候, 我想接下来的一个尝试方向就是让AI竟可能的融入我所有工作流程中, 让AI做为参与者与记录者, 通过AI将会议纪要、讨论要点转化为结构化的文档，让隐藏在个体经验中的暗知识，转化为团队可复用的公共资产

七、最后一道护城河：有人要对结果负责

不久前我和同事开玩笑地说了一句：“放心，AI还不会取代你们, 线上事故还需要你们背锅。” AI现在能够帮我们开发需求,完成测试，但是真正上线涉及的风险,故障与恢复策略都要有人拍板。AI不会为失误承担责任， 而我们每一个开发者, 每一个决策都关联着系统的稳定、用户的体验, 也关乎着我们的职业生涯。这份责任和敬畏之心，是现在AI还无法承接的.

最后我想说的是:在AI极大拉平“木桶”短板的今天，传统的“木桶效应”或许已然淡化。个人的价值，将更取决于你最长的那块木板能触及何种高度—比如对业务的深度理解、对复杂问题的拆解能力、对技术风险的预判能力。 这，或许是人机协同编程时代，留给我们最深刻的人文命题。