AI Coding 现在到底能干到什么程度 · 给老同行的几件真事

📚 《从 0 到 1·AI 程序员》· 共 5 篇 · 本篇 01

这个系列写给传统程序员（前端 / 后端 / 全栈），不想被营销号割韭菜的老同行。目的很朴素 —— 把"听说 AI 能写代码"落到"能稳定把它跑在生产里"这条路，用 5 篇讲清楚，不讲虚的。

本篇你将搞清楚：AI Coding 真实水位的 3 个参照点 · Vibe Coding 从 Copilot 到 Claude Code 的演进脉络 · AI 能做 / 不能做的边界 · 人机共创里你的角色。

追读地图：01 认知校准 → 02 Prompt 工程 → 03 工具全景 → 04 Harness 工程 → 05 转型路线图

一、先讲两件 2026 年真实发生的事

2026 年 1 月的一个周末，Aditya Agarwal —— Facebook 第 10 号员工、把 Dropbox 工程团队从 25 人扩到 1000 人的前 CTO —— 在 X 上发了一条话，在圈内炸开：

"We will never write code by hand again."（我们以后再也不会用手写代码了。）

他不是一时兴奋的调侃。他那个周末用 Claude 写的代码，超过了他过去 5 年手写的总和。

更扎心的是他社群里做的一个实验：同一道面试题，题目故意设计得长到手写做不完，时间一样，工具自选。结果是一把最干净的筛子——

天天用 AI 的工程师，产出是"只读过几篇文章但没动手"那批人的 10 倍。

不是多 10%，不是翻倍，是整整 10 倍。

同一个月另一件事：Google 负责 Gemini API 的 Jaana Dogan 公开承认，她的团队 2024 年一整年反复迭代的一个分布式 Agent 编排系统，Claude Code 一个小时给出了一个能跑的版本。

这不是发布会演示。这是 Google 一线工程师自己在社交媒体说出来的事。

听到这两件事，传统程序员大概率有两种反应：

• 一种是"那是硅谷大佬，和我没关系"
• 另一种是"这肯定是营销号放大了的故事，没那么夸张"

我要告诉你：两种反应都不对。

这两件事都发生在 2026 年 1 月，有公开的时间、公开的发言人、公开的成品。它们不是个例，是那段时间暴风眼里的两朵浪花——背后是一大批你叫得出名字的大厂工程师，在公司内部悄悄把自己的日常工作节奏改了。

但我也不会反过来告诉你"跟上就能变成下一个 Agarwal"——那是另一种营销。

现实是：AI 能放大好工程师的判断力，也会放大糟糕工程师的工程债。国内有团队分享过一个真实的对照——同一个项目用 Claude Code 做，前端部分 10 分钟搞定，后端 2 小时才出来；排查发现瓶颈不在 AI，在后端代码库自己命名混乱、概念模糊。AI 如实把你的工程质量暴露出来了。

这个系列要讲清楚的，就是从"听说 AI 能写代码"到"自己能稳定把它跑在生产里"的整条路径：

1. 它真实的能力水位在哪？哪些事它能独立干？哪些事它还差得远？

2. 你的工作重心会怎么变？哪些技能升值、哪些贬值？

3. 要把它用到位，你需要给它配什么样的工程化支撑？

不讲虚的。从可验证的三个水位参照点开始。

二、AI Coding 的三个水位参照点

朋友圈里关于 AI Coding 的说法两极分化：一边是「AI 已经能替代程序员」，一边是「AI 写的代码全是垃圾」。两边都不对。

真实水位在哪？我给你三个可以自己验证的参照点。

参照点 1：单文件纯功能实现

2022 年底的 ChatGPT：能写 50 行左右的小函数，但你得把需求描述得特别清楚，而且大概率要改一两轮才能跑。

2024 年中的 Claude 3.5 + Cursor：给它一个功能描述，它能写出 200-500 行的单文件代码，80% 的情况下第一次就能跑。

2026 年初的 Claude Opus 4.6 + Claude Code：500-1500 行的复杂单文件，基本都能一次跑通，而且会主动考虑边界情况、错误处理、日志。

这个维度上，AI 已经强于一个工作 1-2 年的初级开发者。

参照点 2：多文件协同开发

2023 年：多文件协同基本做不好，AI 会记不住它在别的文件里定义的函数签名，经常出现调用不匹配。

2024 年：Composer 这类多文件编辑能力出来后，5-10 个文件范围内的协同开发变得可行，但会出现「上下文越大越健忘」的现象，越到后面越容易改坏。

2026 年：Claude Code、Cursor Agent、OpenCode 这类带持久记忆和项目级上下文的工具，已经能稳定处理几十到上百个文件的中等复杂度项目。当然前提是项目结构清晰、规则文件配置到位。

这个维度上，AI 能独立完成中等复杂度的全栈小项目（记账工具、管理后台、官网、小程序、简单工具类 SaaS）。

参照点 3：架构级决策与大型系统

这是 AI 目前最大的短板。

什么叫架构级决策：比如你要做一个每天 500 万请求的服务，数据库选 PostgreSQL 还是 TiDB？缓存策略怎么设计？服务怎么拆？这些决策高度依赖业务预测、团队能力、历史包袱，不是单纯的技术最优解。

AI 在这里表现怎么样：它能给你一个「看起来很合理」的方案，但往往是中庸的、教科书式的。真正需要权衡的复杂决策，它做不了。

大型系统的另一个问题：上下文窗口再大也有上限。一个几十万行代码的成熟项目，AI 没办法「读懂整个系统」，它只能看你 feed 给它的那部分。

所以这个维度上，AI 还不能替代资深架构师。AI 在这里的定位是「高级陪练」：你拿方案给它，它帮你挑毛病、补盲点。

三个水位合在一起的结论

一句话总结：AI Coding 已经过了「玩具」阶段，进入了「生产工具」阶段，但还没进入「全面替代」阶段。

三、Vibe Coding 的演进脉络：从 Copilot 到 Claude Code

「Vibe Coding」这个词，最早是 Andrej Karpathy 在 X 上的一条推文带火的，意思是：你不再逐行写代码，而是「跟着感觉走」用自然语言描述你要什么，AI 把它变成代码。

但 Vibe Coding 不是一夜之间出现的，它经历了四个阶段。

阶段一：补全时代（2021 - 2023）

代表工具：GitHub Copilot

核心能力：你写代码，它猜下一行。

这个阶段 AI 是「副驾」，主驾还是你。Copilot 让人第一次感受到「AI 真的能写代码」，但本质还是高级的代码补全，离「对话开发」有距离。

局限：Copilot 看不到你项目的全貌，它只能基于当前文件和光标附近的内容做预测。复杂的业务逻辑写不了。

阶段二：对话时代（2023 - 2024）

代表工具：ChatGPT、Claude 聊天框

核心能力：你描述需求，它输出代码，你复制粘贴到 IDE。

这个阶段 AI 开始能「理解需求」，但开发流程很割裂：你要在聊天框和 IDE 之间来回切换，出了 bug 还得把错误信息复制回去让它改。

局限：文件系统不互通，上下文不持久。每次对话都像第一次见面。

阶段三：IDE 融合时代（2024 - 2025）

代表工具：Cursor、Trae、Windsurf

核心能力：AI 住进了 IDE，能直接读写文件、跑命令、看终端输出。

这是第一次真正意义上的 Vibe Coding：你在同一个界面里描述需求，AI 直接改你的项目，你实时看到变化。Composer 功能让它能一次改多个文件。

局限：主要面向有 GUI 的开发者。对复杂项目管理、CI/CD 集成不友好。

阶段四：Agent 时代（2025 - 2026）

代表工具：Claude Code、Cursor Agent、OpenCode、Codex CLI

核心能力：AI 变成「自主执行者」，你给一个高层次目标，它自己拆任务、自己写代码、自己跑测试、自己提交。

关键跃迁是两个：

1. 终端级 AI 工具的出现：Claude Code 把 AI 带进了终端，可以直接跑命令、操作文件系统，没有 GUI 束缚。

2. Agent 编排能力：主 Agent 能派生子 Agent 并行执行任务，像一个真的小团队。

到这里，Vibe Coding 才真正成为一种生产方式。你不再是「偶尔让 AI 帮忙」，而是「默认所有代码都先让 AI 写，你只做审视和调整」。

四、诚实讲局限：哪些 AI 还不行

我说了它能做什么，也得说它不能做什么。否则就是在卖课。

1. 它不能替你想清楚你要什么

AI 能把你想清楚的事批量干出来，但它不能替你想。

你如果说「给我做一个好用的产品」，它只能给你一个「看起来像好用产品」的平均值。真正的产品洞察，来自你对用户、场景、竞品的理解，AI 没有这些。

对你的要求：你必须具备清晰表达需求的能力。这个能力恰恰是大多数传统程序员的短板（因为过去有产品经理帮你翻译）。

2. 它不擅长处理「状态复杂的长流程」

举个例子：一个电商下单流程，涉及库存扣减、优惠券核销、积分扣除、分账、通知、退款回滚……这种跨多个服务、跨多种状态的长事务，AI 写出来的代码看起来对，但容易在边角情况出错。

这类场景你必须亲自把关状态机设计和事务边界。

3. 它会「一本正经地胡说」

AI 有时候会引用一个不存在的库函数，或者给你一个 API 签名但其实这个 API 已经在两年前被废弃了。行内的说法叫「幻觉」（Hallucination）。

应对办法：跑一下。代码跑不通、库安装不了、就是在骗你。别看它说得多自信。

4. 它不知道你的「团队默契」

你们团队约定变量用驼峰还是下划线？接口返回统一用什么格式？异常怎么分级？这些 AI 不知道，除非你把这些规则写进「规则文件」里告诉它。

这也是下一篇要重点讲的 Prompt 工程和规则文件的意义。

五、「人机共创」到底意味着什么

看到这里你应该明白了：AI Coding 不是「AI 替代你」，而是「你的工作重心变了」。

过去你 80% 时间在写代码，20% 时间在想需求。现在反过来——80% 时间在想需求、拆任务、审代码，20% 时间在手动微调。

具体说，你的工作重心变成：

1. 需求澄清（Requirement Clarification）

把模糊的业务需求拆成 AI 能执行的清晰指令。这需要你同时懂业务和懂技术约束。

2. 任务拆解（Task Decomposition）

大任务拆小，分清依赖关系，决定什么可以并行、什么必须串行。这需要你有架构思维。

3. 上下文管理（Context Management）

决定 AI 当前这一轮「应该看到什么」「不应该看到什么」。上下文塞太多它会变笨，塞太少它会乱。

4. 成果审视（Output Review）

AI 写完一段代码，你判断：能不能跑？有没有隐藏 bug？是不是最优解？是否符合项目规范？这是传统 Code Review 的升级版。

5. 持续调优（Prompt Tuning）

发现 AI 总在某类问题上出错，你回去改你的 Prompt、改你的规则文件、改你的任务拆解方式。这是新时代的「工程化」工作。

这 5 项能力，任何一项都不是传统程序员熟悉的舒适区。

这也是为什么这个转型对很多人来说比想象中难——不是工具难学，而是工作方式要换。

六、你现在该做什么

读到这里，你应该完成了第一次「认知校准」：

• AI Coding 真实水位大致清楚了
• Vibe Coding 的演进脉络清楚了
• 哪些能哪些不能清楚了
• 你自己在里面的角色清楚了

下一步，该动手了。

但动手前，你得先会「说」——把脑子里的想法清晰、无歧义地喂给 AI。这个能力叫 Prompt 工程，是传统程序员转型最大的短板，也是这个系列真正差异化的核心。

下一篇「第 02 篇：从『写代码』到『说代码』」，我会讲透需求拆解三层模型、上下文管理的 4 个实战技巧、Bug 描述的标准结构，以及新手 Prompt 和高手 Prompt 的真实产出差异。

学完它，你发给 AI 的每一句话都会直接提升产出质量。

下一篇预告 → [02 Prompt 工程不是玄学 · 一个程序员的结构化沟通指南]

如果这篇帮你校准了对 AI Coding 的认知，公众号「阿锦AI」后台回复「认知」领取 《AI 能力水位自评表》（5 个维度 10 分钟，定位你当前在哪个水位、下一步该补什么）。末篇还有抽 4 张智谱 Coding 7 天体验卡的福利，一篇不落追到最后。

下一篇见。