2025：AI Coding 的”成年礼”与 2026 的 DDAD 革命

前几天清理电脑，翻出了我去年初写的一份关于 GitHub Copilot 的测试笔记。看着那句“AI 只能帮忙补全代码”，我没忍住笑出声。这短短一年，AI 编程工具的变化就像是从自行车直接跳到了高铁。

我们团队最近在复盘，我发现大家不再讨论“AI 能不能写代码”了，而是每天在群里吵“怎么才能让 AI 别瞎改我的配置”。根据 Stack Overflow 年末的调查，有 72% 到 84% 的开发者已经试过 AI 编程工具。当工具普及到这个程度，问题就变了：AI 确实能写，但写出来的东西能用吗？

文档成了唯一的共识

我之前一直觉得写文档是件苦差事。代码写完能跑就行，补文档纯属应付差事。但自从我开始用 Claude Code 和 Cursor 这种能自己读文件、改文件的工具，我发现自己被打脸了。

上周我试图让 AI 帮我重构一个鉴权模块。我用嘴对着麦克风讲了五分钟需求，结果它给我整出了一套基于 Redux 的状态管理——而我们团队半年前就全员转 Zustand 了。我气得想砸键盘，后来冷静下来一想，它怎么知道我们的规矩？

后来我学乖了，在项目根目录建了个 CLAUDE.md，里面写清楚：“我们用 Zustand，严禁使用 Redux。所有 API 必须带上错误重试机制。”神奇的事情发生了，在那之后，AI 再也没有在这个问题上犯过错。

这让我意识到一件事：在 AI 时代，文档不再是给人看的附属品，而是 AI 的“操作系统”。

为什么是 CLI 工具？

我试过很多 IDE 插件，但最后发现，像 Claude Code 这种跑在终端里的命令行工具，反而更适合团队协作。

图形界面里的对话框是“阅后即焚”的，你今天教了 AI 怎么写某个组件，明天它又忘了。但在终端里，所有的配置都是文件。你写个 .clinerules，它就是整个项目的宪法。你的每一次架构决定、踩过的坑，全都可以写成 Markdown 存下来。

我甚至把我们团队审查 PR 的标准写成了一个 pr-review.md。每次让 AI 看代码前，它都会先去读这份标准，然后一条条对照着检查。这比口头交代靠谱太多了。

DDAD：写给 AI 看的文档

我跟朋友开玩笑说，以前我们是 TDD（测试驱动开发），现在得叫 DDAD——文档驱动 AI 开发（Document-Driven AI Development）。

逻辑很简单：你把需求和规范用人话写进 Markdown 里，AI 负责把它变成现实。

在这个模式下，我一天的日常变成了这样：早上花半小时把新支付流程的业务逻辑写清楚，重点标出哪些边界条件不能碰。然后交给 AI 去生成后端的 API 和前端的页面。中午吃完饭回来，我只需审查它提的 PR。如果发现它对某个异常处理得不好，我不直接改代码，而是去更新我们的知识库文档，告诉它下次遇到这种情况该怎么办。

这种感觉就像是在带一个不知疲倦但需要明确指令的实习生。

谁在用它？

我看了看身边的人，用 Copilot 的依然是最多的，毕竟老牌子稳。但 Cursor 的拥趸越来越狂热，他们最喜欢拿它一键重构跨文件逻辑来炫耀。至于我自己，我更偏爱那些支持 MCP（Model Context Protocol）协议的工具。

Anthropic 搞出的这个 MCP 协议有点像 AI 界的 USB-C 接口。以前不同工具互不搭理，现在只要支持 MCP，我的 AI 就能直接读我本地的数据库和团队的 Jira。

2026 年已经来了，我越来越觉得，以后最吃香的可能不是那种能手写红黑树的极客，而是那些能把文档写得清清楚楚，知道怎么指挥一群 AI 替自己干活的人。至于我自己？我打算今晚就把团队剩下的几个模块规范全写进 CLAUDE.md 里。