技术观察 on Zampo Blog

AI Coding 正在淘汰的，不是程序员，是只会写代码的人

Wed, 20 May 2026 10:05:00 +0800

有人在 V2EX 上写了一段很真实的 Claude Code 体验：

“我一行代码没写，但是提示词写了不少，调试也花了很多功夫。”

这句话比很多 AI 编程报告都更接近现场。

不是“一键生成一个产品”。也不是“程序员马上没饭吃”。

更像是：代码确实被 AI 写了很多，但需求、上下文、调试、判断、验收，还是一个都没少。

这才是 AI Coding 对程序员真正的冲击。

它不是简单把程序员替换掉，而是在重新定价程序员的能力。

过去，一个程序员的显性价值很大一部分来自“我能把需求翻译成代码”。现在，Claude Code、Cursor、GitHub Copilot agent mode 这类工具，正在把“写出代码”这件事变得越来越便宜。

但便宜的从来不是软件本身。

代码正在变便宜，判断正在变贵。

AI Coding 已经不是自动补全了

很多人对 AI 编程的印象还停在 Copilot 早期：你写半行，它补半行；你写一个函数名，它猜一段实现。

那是 autocomplete 时代。

现在的工具已经变成另一种形态。

Claude Code 官方文档把它描述成一个能理解整个代码库、跨文件工作、编辑文件、运行命令、完成开发任务的 coding assistant。GitHub 在 2025 年发布 Copilot agent mode 时，也强调它可以迭代自己的输出、识别错误、建议终端命令，并把任务拆成更多子任务去完成。

这不是“补全一行代码”。

这是一个能读项目、能改文件、能跑命令、能看错误、能继续修的执行者。

对开发者来说，最大的变化不是“少敲几行”。而是你的工作姿势变了。

以前你亲手写代码，AI 站在旁边补句子。

现在你更像在给一个 Agent 派活：

先告诉它目标是什么；
再告诉它项目约束在哪里；
接着让它探索代码库；
要求它给计划；
放它执行；
最后你看 diff、跑测试、决定能不能合并。

这套流程里，敲键盘的动作少了，但程序员的责任没有少。

甚至更重。

因为一旦 Agent 做错，它不会替你背锅。线上故障、脏数据、安全漏洞、错误架构，最后还是落回人身上。

TypeScript 押注 Go：10 倍提速背后，不是语言胜负，是工程约束

Tue, 19 May 2026 20:30:00 +0800

TypeScript 的 10 倍提速，最容易被讲歪。

一歪成“Go 打赢 Rust”。

再歪成“以后 TypeScript 业务代码快 10 倍”。

这两个说法都抓人，也都危险。前者把工程决策讲成语言饭圈，后者直接把性能场景讲错了。

真正有意思的地方不是 Go 有多神，也不是 Rust 或 C# 有多不行，而是 TypeScript 团队这次面对的目标非常特殊：他们不是要从零设计一个新编译器，而是要把一个成熟、庞大、被整个前端生态依赖的工具链，迁到 native 实现里。

这件事一旦说清楚，Go 为什么胜出，就没那么玄学了。

10 倍提速，先别理解错

官方博客里的 10 倍，不是说你写出来的 JavaScript 业务代码运行快 10 倍。

TypeScript 最后还是编译成 JavaScript，线上跑得快不快，主要看 JS 引擎、业务逻辑、网络、渲染、数据结构和运行时环境。TypeScript 这次提速，发生在开发期工具链：tsc、类型检查、项目加载、语言服务、编辑器响应。

这区别很重要。

因为一个错的期待，会毁掉一个本来很有价值的技术升级。

官方 benchmark 里，VS Code 代码库的 tsc 检查从 77.8 秒降到 7.5 秒，Playwright 从 11.1 秒降到 1.1 秒，TypeORM 从 17.5 秒降到 1.3 秒。编辑器加载 VS Code 项目，也从约 9.6 秒降到约 1.2 秒。

Agent 越会写代码，你越需要一块看板

Wed, 13 May 2026 12:25:00 +0800

你创建了 5 张 Agent 任务卡，以为系统会自动开干。

结果过了十分钟，什么也没发生。

不是模型不行，也不是任务拆得不够细。问题更尴尬：卡片创建，不等于任务执行。

这就是我这两天把文案线从 TASK_BOARD.md + inbox/active/done 文件流迁到 Hermes Kanban 时，最直接的体感。

以前我们用 Markdown 看板管 researcher、writer、coder。任务从 inbox 移到 active，再从 active 移到 done。听起来很朴素，也确实能跑。但一旦任务变多，问题马上冒出来：状态同步靠人记，交付物路径靠人写，谁能开始、谁在等审核、谁依赖谁，经常要翻半天聊天记录。

换成 Kanban 以后，事情并没有神奇地全自动。恰恰相反，我更清楚地看到一个事实：

Agent 越会干活，越需要一套严肃的任务面板。

多 Agent 的难点，已经不只是“让它写代码”。而是它写完之后，谁来审？失败之后，谁来接？上游没交齐素材，下游凭什么开工？任务卡完成了，交付物有没有真的落盘？

这才是 2026 年 Agent 工具真正开始分化的地方。

瓶颈换地方了

Vibe Kanban 的 README 里有一句话很准：Your Engineering Bottleneck Has Shifted。

过去，工程瓶颈在编码速度。

你有一个需求，开发者理解、写代码、调试、提 PR。AI 编码工具出现后，很多环节被加速了。Claude Code、Codex、Cursor Agent、Gemini CLI 这类工具，已经能承担相当一部分实现工作。

但加速之后，新的瓶颈露出来了。

不是没人写代码，而是没人稳定地规划、分发、审查、合并、回滚。

这也是为什么 Vibe Kanban 这种工具会火。它不是又一个聊天框，而是把编码 Agent 放进任务面板里：一个 issue 可以启动一个 agent workspace，配 git worktree、终端、预览和 diff review。人不再守着一个对话框等回答，而是像管理一组实习生一样管理 Agent。