AI Coding 能力边界探索

2026-01-17

最近一段时间，我写代码的时候，几乎都会顺手开着一两个 coding agent。

有时候是在跑一个 demo，有时候是直接丢给它一个完整仓库，让它慢慢改。我自己在旁边干别的事情，隔一会儿切回来看看它现在在干嘛。久而久之，这事儿就有点像是在观察一个不太聪明、但手速很快、而且永远不嫌加班的同事。

慢慢地，我开始不太满足于“哇，这也能写”，而是开始问一个更工程化的问题：

现在这个阶段，AI 写代码的能力边界到底在哪里？

我不是想讨论那种“AI 会不会取代程序员”的宏大命题，那种话题太空了。对我来说，更重要的是一些非常具体的问题：

这个任务，我能不能把它交给 AI？
如果不能，是哪一步开始搞不定的，为什么？

下面这些例子，都是我这段时间真实跑过的。有成功得让我吃惊的，也有失败得让我意识到“哦，原来边界在这里”。

一个几乎满分的例子：C++ 服务器整体转 C

先说一个让我非常震惊的成功案例。

任务本身不复杂，代码量也不大：把一个用 C++ 写的网络服务器 demo，完整改写成 纯 C 语言实现。

原项目是这个：
https://github.com/yuesong-feng/30dayMakeCppServer

用的工具和模型是 kiro + opus 4.5，需求描述其实也很简单：

保留原有行为，把 C++ 的实现完整改成 C

然后我就基本没管它了。过了一会儿切回来看，发现事情已经做完了。更关键的是：不是那种“看起来差不多”，而是真的能用。

具体表现包括：

  • C++ 的 class 被完整拆成了 struct + 一组函数
  • 构造 / 析构逻辑被显式地翻成 init / free
  • socket、epoll、事件循环这些地方完全没乱
  • 没有偷偷混进 C++ 语法
  • 代码风格甚至还挺干净

我把代码拉下来直接编译，一把过。最终的结果在这里：
https://github.com/tiancaiamao/tcp_server/tree/main/src

这件事对我的冲击其实挺大的，因为它几乎是 0 人工干预。我只是定义了边界，它就把整个体力活干完了。这类任务我给 98 分，一点不夸张。

后来冷静想了一下，其实也能理解它为什么能干得这么好：

  • 网络服务器是非常高频的编程模式
  • 有完整、清晰的参考实现
  • 目标语言（C）和源语言（C++）都极其成熟
  • 项目规模不大，但结构完整

在这种条件下，AI 更像是一个极其熟练的“代码搬运 + 重构机器”。

IDE 里的代码补全：已经是基础设施了

这一类能力大家每天都在用，但已经不太会特意讨论了。

比如：

  • 写到一半的函数补全
  • for / if / error handling 的模板
  • 常见 API 的调用方式

VS Code、Zed 这些编辑器现在基本都自带 AI 功能。

对于补全这种场景，用户的心理预期本身就很低：

对了就 tab，不对就当没看见

所以模型只要别太离谱，体验就已经不错了。copilot-nano 之类的小模型，在这里都完全够用。90 分起步。

中等复杂度，但反馈完整：ad 编辑器的两个例子

接下来是我觉得非常有代表性的一类任务：

不只是补全，而是需要读项目、理解上下文、再改代码

我现在的主力编辑器，是我 fork 之后一直在用的这个项目：
https://github.com/sminez/ad

它不算成熟，时不时会冒出一些问题。好几次我干脆让 AI 直接参与真实开发。

例子一：实现一个小功能

ad 的键位设计更偏 Kakoune，而不是 vim。我平时是重度 vim 用户，所以有些地方用得非常别扭。

其中一个点就是屏幕滚动。在 vim 里有 ctrl-f / ctrl-b / ctrl-d / ctrl-u / ctrl-e 这一套，而 ad 里没有完全对齐。

下面这个 commit，基本就是 AI 直接完成的：
https://github.com/tiancaiamao/ad/commit/8332b513b7ce2c19b86efca8b581de850875b7dd

它需要做的事情其实不少：

  • 理解 ad 这个编辑器的整体结构
  • 搞清楚 buffer / window / view 之间的关系
  • 在现有设计约束下改代码，而不是随便 patch

这已经明显超过“写几行代码”了，但 AI 还是能完成。原因其实也很直接：

  • 用的是成熟语言（Rust）
  • 能直接编译
  • 能运行
  • 行为是不是对的，可以立刻验证

例子二：帮忙修 bug + resolve review comment

另一个我觉得更有意思的例子，是这个 PR：
https://github.com/sminez/ad/pull/173

背景是这样的：

  • 我自己先提了一个非常小的修复（基本就是一行代码）
  • 作者 review 之后指出：实现思路不太对

于是我干脆把整个 PR 链接丢给 AI，让它：

  • 抓 PR 页面
  • 读评论里的讨论
  • 理解 reviewer 真正想要的行为
  • 再回到代码里修

结果是：它真的能做。

不是一次就完美，但在几轮修改之后，它给出的方案是合理的，而且明显是“对着 review 意图来的”，不是瞎改。

我依然会自己过一遍代码，但它已经帮我省掉了大量“理解上下文 + 尝试实现”的时间。

开始失败的地方：小众语言 + 相对复杂的功能

让我真正意识到能力“边界”的，是我自己的编程语言项目 cora：
https://github.com/tiancaiamao/cora

这是一个 Lisp 方言，很多基础设施都是我自己写的。

前段时间我在博客里写了一篇文章，讨论接下来要怎么实现多核并发模型：
/cora-multicore-support-2.md

于是我尝试了一件现在看来有点天真的事情：

  • 把那篇博客描述丢给 AI
  • 把代码仓库也丢给 AI
  • 要求它按照博客里的设计，把并发框架实现出来

一开始，一切看起来都还不错。

它能理解博客在讲什么，也能照着改代码，甚至改出来的代码乍一看好像那么回事。

但很快问题就暴露出来了。cora 这种小众东西，实在太不成熟：

  • 没有调试器
  • 报错信息非常原始
  • 有些错误可能直接卡死，而不是返回错误
  • 出了问题，很多时候只能靠我自己在脑子里跑

这些东西，AI 完全接不上。

它习惯的工作方式是：

写代码 → 编译 → 看报错 → 再改

而在 cora 这里，这条反馈链路当前是断的。它不知道该怎么定位问题，于是只能不停地产生看起来合理、但根本没法工作的代码，然后反过来向用户要更多描述。

另一个失败案例：跨 TiDB / client-go / TiKV 的小 PR

还有一个失败得非常典型的例子，是工作里的这个 TiKV PR：
https://github.com/tikv/tikv/pull/19166

这个例子有意思的地方在于：问题并不复杂。

逻辑上只是协议层有变化，需要从 TiDB → client-go → TiKV，从上到下把相关的地方都改一点点。

但 AI 在这里的表现是：

  • 能看懂“局部”
  • 能改某一个 repo 里的某一段
  • 但对整个链路的语义负责起来就比较困难

你让它在单个仓库里修一个点，它是能修的；
但你让它理解「为什么上游这么设计，下游必须那样实现」，它就开始搞不定了。

一个几乎不可能的任务：大型开源游戏

我还试过把一个大型开源游戏项目直接丢给 AI：
https://github.com/opendarkeden/client

这是一个几十年前的 MMORPG，代码量是百万行级别，依赖关系极其混乱，编译环境是 Windows + DirectX + VC6。

这种项目，如果没有 AI，我以前连想都不敢想。因为保守估计都是全职一年起步的工作量。

有了 AI 之后，情况发生了一点变化。反正烧的是 token，而不是我自己的时间，心理负担小很多。

第一次尝试：从边缘做 demo

我一开始的策略很保守：

  • 让 AI 从资源解析开始
  • 比如动画、地图格式
  • 用 SDL 渲染出来
  • 做一个小 demo，让角色能在地图上走

到这一步为止，一切都非常顺利，AI 做得也很漂亮。

接着我让它开始动 UI 相关的代码，重写、移植用到的库，也还能跑 demo。

但一旦进入「真实整合原始素材 + 还原原始执行逻辑」这一步，就开始不行了。

这个项目的依赖写得非常糟糕：

  • 抽象层不完整
  • 上层代码直接引用 DirectDraw API
  • 本来应该层层封装的地方，全都糊在一起

AI 很快就卡住了。它会试图 stub 掉一些东西来完成我描述的任务，但一旦不 stub，原始依赖又解决不了，直接编译不过。

到这里，总是需要人的介入。

第二次尝试：先强行造一层抽象

后来我换了一种方式。

不再从 demo 一点点往上扩，而是：

  • 先在某一层封装好统一的 API
  • 下层可以用不同实现
  • 这层向上完全屏蔽细节
  • 上层代码尽量不动

这个方式对人类来说不那么平滑，但有一个巨大好处：反馈非常明确。

AI 可以不停地：

改代码 → 编译 → 报错 → 再改

在这种模式下，它居然真的一点点把事情推进了。

在烧掉了 1,034,292,253 token 之后，它真的把这条链路跑通了。

一条非常清晰的分界线：反馈循环

回头看这些成功和失败的例子，我现在觉得真正的分水岭只有一条：

AI 能不能拿到真实、快速、明确的反馈？

只要有：

  • 编译
  • 运行
  • 报错
  • 测试结果

哪怕任务不算小，AI 都能靠疯狂试错硬推进度。

而一旦：

  • 没法运行
  • 没法观察状态
  • 错误语义不清晰

AI 就会迅速退化成一个“看起来很懂”的文本生成器。

从早期 Cursor 那种“人主导、AI 辅助”，到现在的 agentic coding，除了模型本身更聪明，一个更重要的变化是：AI 学会用工具、并且能形成反馈闭环。

AI 作为大脑，agent 负责调用各种工具：读文件、访问网站、遍历目录、编译、跑脚本……一旦闭环跑起来，自动化 coding 的能力几乎是被突然解锁的。

有一次在做游戏 demo 的时候，我只告诉它「某个按钮点了没反应」。它居然自己：

  • 在代码里推断程序大概运行到多少帧
  • 主动加 debug
  • 模拟点击
  • 在事件处理处加 log
  • 跑程序观察 log

那一刻我是真的被惊到了。

现在它还不太会用调试器，但一旦这些工具也被掌握，效果会完全不一样。这件事我觉得只是时间问题。

最后一点个人感受

2025 年明显是一个 vibe coding 从概念走向落地的年份，而 2026 年，AI 的 coding 能力只会更强。

以前写代码，是设计、拆任务、一点点写，预估一个月的工作量。现在很多事情，丢给 AI，一天以内就能看到结果。

而且这个变化来得非常快。一个月前做不到的事，一个月后可能已经是完全不同的故事。

我用自己前不久发的一条朋友圈作结：

从纸带，到汇编，到高级编程语言，再到 AI 问世；
从 vibe coding 的概念，到它真的开始普及……
时代的车轮滚滚向前，我们大概是最后一代经历“古法编程”的程序员了。

2026 年，见证历史。

AI