2026-02 Agent Coding 体会

Posted recently Updated recently

By Airbo ZH

49~63 min read

引言：在后视镜中消失的“打字机”

站在 2026 年初的时间节点回望，仅仅在两年前，当我们谈论 GitHub Copilot 或早期的 IDE 插件时，感觉就像是在使用一台带有自动纠错功能的打字机。那是一个以“输入效率”为核心的生产力时代，编程的最小单位仍然是“行”。

然而，随着 Claude Code、Windsurf 和 Cursor Agent 的全面普及，我们正经历一场不可逆的迁移：编程的最小单位已从一行代码跃迁为一个功能块；交互模式从“我敲，你补”转变为“我说，你做”。这并非工具的简单升级，而是劳动分工的断层。Notion CEO Ivan Zhao 将 AI 比作“钢铁与蒸汽”——一种改变生产函数的时代材料。

当 CEO 与产品经理们为“无限生产力”的杠杆而欢呼时，在 IDE 深处的工程师们，正经历着一场关于系统掌控权的、脊背发凉的权力交接。

一、权力交接发生在回车键之前

在最近完成「提词器编辑与预览」模块时，我反复体验到一种令人脊背发凉的爽快感。

我只说了一句需求，Agent 自动理解了三个文件之间的隐含关联，横跨 UI、状态管理和数据结构，直接跑通了一个困扰多日的 Bug 修复。那一刻你会清楚地意识到：“写代码”这件事，已经不再是主要门槛。

但这种权力交接是有代价的，而且代价并不发生在“写”。我发现自己的角色正在系统性地转变：从 Author（作者），变成了 Supervisor（监制）。

我不再死磕语法、API 或实现细节，但我必须像写法律条文一样精准地描述规范。因为只要描述存在模糊空间，AI 就会选择完成速度最快、长期成本最高的路径：逻辑硬编码、引入不必要的全局状态、绕过既有抽象，甚至为了完成当前 Feature，悄然破坏原本为未来扩展保留的结构。AI 并非“偷懒”，它只是对模糊指令的最短路径响应器。我必须承认起初我也像许愿一样的对 Agent 提出我的需求，很快我得到了一块让我后续处理起来更麻烦的代码。

Agent 是局部最优的大师，却是全局优雅的矮子。它生成的模块在当前上下文中看起来完整、干净、可用；但当我下周试图加入其他功能时，才发现——它已经把路全部堵死了。问题不在于代码质量，而在于责任边界：Agent 只为“当前问题被解决”负责，却不会为“系统在未来三个月如何演化”负责。

这种权力交接，并不只发生在工程师与 Agent 之间。

AI 还在把“写代码的权力”横向扩散给整个组织。非研发同事和放弃思考的研发同学在 Agent 的加持下，他们确实能写：能起服务、能改逻辑、能一口气堆出几十个 commit，甚至能把一个看似完整的功能直接推到 PR 里。问题在于，代码是否能被生成，和代码是否值得被接收，是两件完全不同的事。

于是一个新的结构性负担出现了：工程师不再主要为“写得慢”付出代价，而是为“别人写得太快”付出代价。一次 PR 动辄几十个提交、上千行 diff，横跨多个业务域与抽象层，没有清晰的 Intent 描述，没有风险边界说明，也没有可验证的验收证据。Agent 可以跨文件补全上下文，但它不会告诉你：哪些改动是偶然拼出来的，哪些是假设叠加出来的，哪些一旦上线就会变成长期债务。

结果是，工程师被迫花大量时间做一件极其反直觉的事：为一个自己并未真正“写过”的系统，承担完整的理解、验证与背锅责任。表面上看，组织里“会写代码的人”变多了；实际上，真正能放行代码的人变少了，而且更累了。

在这一刻，所谓的“无限生产力”开始显露出它的阴影面：当 Transform 被极度放大、而 Accept 的责任仍然集中在少数人身上时，权力并没有消失，它只是换了一种方式压向工程一线。

二、同一个奇迹，两种体感

在 2026 年，关于编程的感官体验撕裂成了两种截然不同的叙事。

🔮 无限心智（CEO/PM 的叙事）

AI 的故事很容易令人兴奋：每个人拥有一个几乎不疲惫的“协作者”，能把信息变成文本、把意图变成代码、把原型变成产品。我们听到的版本往往是——知识工作将被重塑，组织结构也会随之改变：更小的团队能做更大的事，实验更便宜，迭代更快，生产力曲线被整体抬升。

在这个叙事里，AI 像蒸汽机、像钢铁、像电：一种时代材料，改变可行边界，倒逼组织形态升级。它强调的是“产能函数”的跃迁——单位人力可驱动更大的产出与试错。

这条线没有错。它甚至非常重要：因为方向、品味、约束和分发，将比纯粹的执行更稀缺。AI 让执行变廉价，组织自然会把注意力往更上层移动。

但问题是：宏大叙事把很多成本当成二阶项（战略近似），而工程世界里，它们常常是一阶主导项（可行性）。

🧠 有限注意力（工程一线的现实）

我在本月持续体验到一个反直觉的现象：AI 把“写”变快，却不一定把“交付”变快，甚至可能让交付更危险。

因为交付的瓶颈不总在打字，而是在：

读懂这坨东西在干什么（理解成本）
证明它不会在别处爆炸（验证成本）
让多人/多模块/多时间尺度保持一致（协调成本）

AI 极大压低了“生成成本”，但对“理解/验证/协调”的提升有限，甚至经常反向放大——尤其当它产生大规模 diff 时。写代码变得像“喷涂”，而工程变得更像“鉴定”。

于是我感受到一种新的职业疲劳：不是写不动，而是看不动；不是不会写，而是不能放行；不是没有方案，而是对实现的模糊。

这一切的核心约束，居然是一句朴素到难听的事实：人类注意力是稀缺资源。AI 让信息暴涨，于是稀缺更稀缺。

冲突在哪里

宏观叙事（想象）	微观现实（工程）
关心长期趋势、量级变化、结构重构。它会把很多“摩擦成本”当作暂时噪音——因为它在赌一个更大的曲线变化。	关心当下能不能跑、能不能上线、会不会炸、下周还能不能改。它必须把摩擦当成主导项——因为摩擦直接决定生死。
AI 让“执行”廉价，团队可以更小、更快、更敢试；产能上升，组织向更高层次的决策与创造迁移。	执行廉价 ≠ 交付廉价。代码文本变便宜后，理解/验证/协调成为主成本；大规模变更让 review、测试、回滚与事故成本上升。
Agent 能跨文件理解上下文，自动补齐模块，像“无限心智”。	Agent 更擅长“局部完成”，不擅长“全局一致”。它会把系统熵推高：重复发明、隐含耦合、架构冲突、接口漂移。你必须用脑力注入负熵。
每个人都能更像架构师/监制，把时间还给思考。	你确实更像监制，但这意味着责任更集中：你承担最终解释权与背锅权。你从“写代码的人”变成“系统质量的导演”。

三、那些不变的东西

1. 学习的重新定义：从“获取信息”到“形成自我”

在 AI 面前，人类如果把学习理解为“把信息装进脑子”，结局几乎注定是失败。模型的吞吐量与记忆容量是无限扩展的，而人的注意力、精力与寿命是刚性约束。

但这恰好暴露了一个误会：人类的学习从来不是信息量竞赛。人类学习真正发生在另一个层面——它不是“知道更多”，而是：在有限信息下形成可行动的世界模型，并愿意为它承担后果。这句话里最关键的是“后果”。AI 可以在统计意义上不断迭代、不断重置，但人类每一次重大决定都会在生命结构上留下不可逆的痕迹：时间、声誉、身体与心理状态、人际关系都无法回滚。于是，人类学习最深层的结果不是知识，而是身份：学到的东西会变成“我是谁”。当某种认知被你真正内化，它会变成你的行为底线：不是你“会”这么做，而是你“不这样做会难受”。这就是学习从“外置工具”变成“自我结构”的时刻。也正因为如此，人类的学习必然慢、必然带摩擦——它需要你承认过去的自己曾经错过，甚至需要你付出社会摩擦的成本。

在 AI 时代，学习的目标随之改变：不是为了在“变换”上追赶 AI，而是为了把自己的意图与验收能力提升到可以驾驭无限变换的层级。

2. 一个更底层的框架：Intent – Transform – Accept

如果把前面的讨论再向下挖一层，其实我们已经在无意中使用了一个比“工程方法论”更基础的模型。它不是来自 AI，也不是来自软件工程，而是来自对“人是谁”的定义。

我是谁？ 我相信的人生模型是什么？ 我愿意为哪些判断负责？

一旦把“我”定义清楚，工作的结构就会自然浮现。我会把它压缩成三个阶段：

意图（Intent）：我想要什么

这是人类不可外包的部分，它包含：

目标是什么
价值判断是什么
为什么要做，而不是不做
做到什么程度算“好”，什么算“错”

这不是需求文档，而是信仰与选择的集合。

变换（Transform）：把想法变成东西

这是可以被替代、被外包、被压缩的部分。

不论是人、AI、Agent、脚本做的都是同一件事：在给定约束下，把意图映射为某种可运行的形态。

从这个视角看，变换是否高效，本身不是最需要被证明的事情。

验收（Accept）：这是不是对的 / 好的

这是责任最终落点。

验收意味着：

是否符合最初意图
是否破坏了隐含不变量
是否引入了不可接受的风险
如果出事，谁来承担解释权与后果

这一层，责任永远在“我”这里，AI 不能替你验收，因为 AI 不承担后果。

3. 重新理解“宏观叙事 vs 微观现实”

一旦引入 Intent–Transform–Accept 这个三段式模型，

前面所有看似混乱的冲突，都会自动对齐。

为什么 CEO / PM 的“宏观叙事”成立？

因为他们的视角，本质上是：

Intent + Accept 是人的事，Transform 可以被极度压缩

在这个尺度上，确实可以忽略实现过程。

于是他们看到的是：

执行廉价
团队变小
实验成本下降
决策与创造的权重上升

这是一个“把 Transform 近似为 0 成本”的世界。

这个近似在战略层面是有价值的，否则组织不会前进。

为什么工程一线会“痛感拉满”？

因为工程师活在另一个现实里：

Transform 的成本下降了，但 Accept 的成本急剧上升了

代码文本变便宜之后，真正吃人的变成了：

我是否真的理解它在干什么？
我能否证明它没炸？
我能否在下周、下个月继续演化它？

也就是说：

执行廉价 ≠ 交付廉价 因为交付 = Transform + Accept

Accept 这一层的成本，从来没有消失，

只是被更大规模、更高频率地触发了。

不会变的部分，其实就是 Accept 层的硬约束

前面列出的那些“不会变”，本质上全部属于验收层的不可外包约束：

注意力仍然是瓶颈 → Accept 需要人类注意力，信息越多，验证越难
责任不会外包 → 生产事故不接受“这是 agent 写的”
复杂性仍然存在 → Accept 面对的是系统整体，而不是局部完成度
Conway 定律仍然生效 → Accept 的边界，来自组织的沟通结构

这不是工程保守主义，这是责任结构的物理极限。

4. 学习—效率悖论

另一个残酷的不变量是人类的学习规律。Anthropic 的研究揭示了“学习—效率悖论”：依赖 AI 的初级开发者在概念理解和调试能力上平均比手写者低 17%。认知努力和“痛苦的卡壳”是建立心智模型的必经之路。如果我们只将 AI 当作代工厂而非助教，我们可能会在获得效率的同时，失去验证和修复复杂系统的底层能力。

当 AI 将“变换（Transform）”压缩得过快时，学习会被直接跳帧：意图尚未被充分澄清，结果已经出现；验收尚未真正发生，系统却已经“看起来能用”。于是，开发者获得了完成感，却失去了因果感——知道它能跑，却不知道为什么能跑、什么时候会炸。从 Intent–Transform–Accept 的视角看，问题本质上并不在于 AI 变强，而在于人类把 Accept 层也一并外包了。当验证、解释、风险判断被模型“代答”，人的心智模型就不再被迫更新，理解能力自然停滞甚至退化。

这并不是在警告我们拒绝 AI，而是在提示一条边界：AI 可以替你完成变换，但不能替你形成理解；可以替你试错，但不能替你内化。如果我们把效率当成终点，学习会悄然消失；只有当学习被视为形成自我的过程，效率才真正成为杠杆。

四、如何共存？从现实走向理想

前面的分析已经足够残酷：AI 把 Transform 的成本压到接近零，却把 Accept 的成本推到了人类注意力的极限；宏观叙事在赌曲线，而工程一线在承受摩擦。问题因此变得非常具体：如果理想是“无限生产力”，而现实是“有限注意力”，我们中间到底靠什么过桥？

答案不是新的工具，也不是更强的模型，而是一组让现实可被逐步拉向理想的结构性手段。这些手段的共同点只有一个：它们不试图消除约束，而是把约束变成可利用的形状。以下是想到的一些可能的方法：

接口先行：先写约束，再让 AI 填实现

当 Agent 可以自由跨文件、跨模块“完成任务”时，最危险的不是它写错代码，而是它替你做了价值判断。于是第一条原则并不来自工程技巧，而来自责任结构：先把意图冻结成边界，再允许任何形式的变换发生。接口、协议、约束，在 AI 时代不再是实现细节，而是意图的最低可执行表达：

数据契约：哪些字段存在，哪些永远不该出现
错误语义：哪些失败是可恢复的，哪些是系统级事故
不变量：哪些状态一旦被破坏，系统就不再“是它自己”
权限边界：谁可以做什么，谁永远不能越界

这些不是为了“指导实现”，而是为了防止实现替你做选择。一旦围栏立住，AI 的优势才开始变成正资产：它可以在围栏内高速试错，而不是在系统地基上打洞。

测试优先：把意图写成可验收的合同

如果说接口是在保护 Intent，那么测试就是在结构化 Accept。在 AI 驱动的工程里，测试的地位发生了反转：它不再是“实现完成后的检查项”，而是实现之前的世界定义。测试真正回答的不是“有没有 bug”，而是一个更底层的问题：这个系统，是否仍然符合我当初想要的那个世界？

当实现可以被无限生成时，唯一值得被人类亲手写下的，反而是验收标准。

什么情况下这是“正确的行为”
什么情况下这是“不可接受的偏移”
哪些回归意味着系统已经失去身份

测试因此不只是工程工具，而是一种责任声明：“如果这些条件不成立，这个系统就不应该存在。”

Review 升级为“读证据”

当 diff 的规模被 AI 放大后，传统 Code Review 已经事实上破产。不是人变懒了，而是注意力物理上不够用了。于是 Review 必须升级目标：不再试图理解全部实现，而是验证三件事是否成立。

每一个 AI 驱动的变更，必须明确回答：

你想改变什么？（Intent 是否清晰）
风险集中在哪里？（Accept 的视角）
你凭什么认为它是安全的？（证据）

证据可以是测试、约束、实验结果、回滚路径，但不能是“模型说它应该没问题”。没有证据，不合并。

自动化守门员：强制架构一致性

Accept 层之所以痛苦，是因为它常常在和系统规模正面对抗。减少不必要的注意力消耗。自动化在这里承担的角色非常明确：不是替你判断“好不好”，而是提前拦截那些根本不该进入验收视野的变化。

依赖方向检查，防止层级倒置
模块边界校验，阻止隐性耦合
API 破坏检测，让不兼容变化显性化
迁移脚本验证，避免“上线即不可逆”

建立“分区治理”的防火墙

不是所有地方都值得同等治理。成熟的系统，必须承认风险是非均匀分布的，于是治理也必须分区：

核心区（高风险） 人类主导设计，AI 辅助填充，强约束、强测试、强证据
边缘区（低风险） 允许 AI 高自由度生成，追求极致交付速度

治理的目标不是压制 AI，而是保护系统的长期可演化性。

上面说的这些，只是在框架范围内的一些可能的尝试，并不局限于此，甚至只是随机想到的一些可能的方法。具体的方法肯定还需要大家在实践和探索过程中慢慢去发掘。

五、关于未来共存的哲学思考

AI 改变了“变换”的性价比，但它无法触及编程的内核。我们该如何与这种“无限心智”共存？

这并非是关于“用不用 AI”的辩论，而是关于“你站在哪一层”的抉择。真正的共存，要求工程师从繁琐的实现逻辑中抽身，去承担更沉重的责任：定义边界、保护系统熵值、提供逻辑证据。在理想的目标下，我们从当前的工程现状出发，通过增强意图的清晰度和验收的结构化，逐步逼近那个“无限生产力”的彼岸。

“边界 + 逼近”

上面的方法似乎就定义了一些边界，然后再用一些逻辑去逼近。先承认不可改变的硬约束，再在约束之内做渐进优化。像进化论：随机试探、局部成功、保留有效变异，系统在迭代中螺旋前进。

AI 极大增强了“变换自由度”，而自由度上升会导致系统熵增：跨边界改动变得太容易，短期局部最优会不断侵蚀长期可演化性。于是我们需要一种“反熵增”的工程哲学：

边界：把意图冻结为约束，把系统切分为可治理的模块
逼近：不追求一次性完美，而是用证据驱动的改进逐步接近理想

我们承认未来的工作是持续性的：每一次进步都是在边界内多逼近一步。

共存的工程责任：从写实现到写围栏、写证据

如果把 AI 看作一台极强的“变换器”，那么工程师的职责会发生迁移：从“多写实现”迁移到“让实现可控”。 把“意图—验收”变成不可绕过的主链，把变换限制在可控范围内。

无限心智时代，工程师的意义在哪里

如果把“学习”的讨论收束回来，我们会得到一个很清醒的定位：

AI 擅长在既定目标函数内进行变换与优化
人类的不可替代性不在于变换速度，而在于：选择什么值得发生，以及如何证明它发生得对

这是一种更重的责任，但也更真实：它不是“背锅”，而是对不可逆人生的负责——你愿意成为那个做出选择的人，愿意让因果链回到自己身上。于是，“共存”就不再是工具层面的争论，而是层级的迁移：从实现者迁移为“边界与验收的设计者”，从写代码迁移为写约束、写证据、写治理。

在理想的目标下，我们从当前工程现状出发，通过增强意图的清晰度和验收的结构化，逐步逼近那个“无限生产力”的彼岸。真正的未来不是 AI 替代人类，而是：AI 负责无限变换，人类负责方向与证明；AI 提供速度，人类提供秩序。

尾巴

AI 让执行变得廉价，也让“品味”与“责任”变得前所未有的昂贵。我们不再是打字机前的操作员，而是这场名为“创造”的交响乐中的指挥——决定主题、划定边界、要求证据，并为最终的落地后果签字。

这篇文章同样如此：正文大多由 AI 生成，我提供体会、观点与取舍。我设计大纲，安排双线叙事，试图从学习、创造这些最底层的原理出发，找到 AI 时代仍然不变的几条硬约束，再围绕它们搭起一套解释框架。写作本身也构成了一个 Intent – Transform – Accept 的闭环：我给出意图，AI 完成变换，最后的文章由我来验收。

因为 AI 的进化速度太快，我们不能看到一个新工具就兴奋地补一条经验、看到另一个新模型又推翻一套想法。更可靠的做法是：先从理想到现实，建立框架；在框架里先承认哪些东西不能被改变、不能被绕过——注意力的瓶颈、责任的回流、复杂性的惯性、组织与系统的同构——然后在这些硬约束之内，一步步把现实往理想方向推。工具会更迭，叙事会翻新，但能把“无限变换”驯化为“可验证的创造”的，仍然是人。