这是 2026 年的第 42 篇文章
（本文阅读时间：约 20 分钟）
01 失传的大马士革钢
公元前 5 世纪，印度工匠用坩埚炼出“乌兹”钢锭，经中东铁匠锻打成冷兵器巅峰——大马士革刀。然而到了 18 世纪，这门传承千年的技艺在几十年间彻底失传。铁匠们严守祖传口诀，动作分毫不差，却再也无法复现昔日的锋芒。
直到 20 世纪末，现代冶金学才揭示真相：其卓越性能源自特定矿脉中微量钒、钼杂质在锻打中析出的碳化物纳米结构。致命的缺陷在于，历代工匠从未真正理解其“为何”出众。他们拥有完整的流程和炉火纯青的手感，但这份理解仅停留在机械操作上。当矿脉枯竭、关键变量悄然改变，只会重复却无法解释原理的工匠们，便无力回天。
02 从生成代码到理解代码
Programming should be regarded as an activity by which the programmers form a theory of the matters at hand, rather than the production of a program and certain other texts.
-- Peter Naur《Programming as Theory Building》
译：编程应被视为程序员对所处理事务建立起一套“理论”的活动，而非对程序及其他文本的生产。
半个多世纪后，软件领域正在重演同样的故事。当 AI 以远超人类阅读的速度生成代码，我们正逐渐沦为只会重复配方的铁匠：系统运行良好，功能持续交付，可一旦追问“为何如此设计”或“替换后的后果”，我们往往陷入沉默。
写代码的速度前所未有，真正的瓶颈已从“生产代码”转移至“理解代码”。Peter Naur 早在 1985 年就指出：程序的本质不是代码文本，而是程序员脑中的“理论”。当掌握理论的人离去，即便代码未改，程序也已“死亡”。
刀还是那把刀的样子。而当理解成为瓶颈，我们迟早要面对那张悄悄堆积的账单——软件世界称之为“技术债务”。
03 软件债务不是什么新鲜事
软件工程中的债务并非新概念。从 50 年前 Fred Brooks 在《The Mythical Man-Month》中探讨的软件复杂性，到 Robert C. Martin 的《Clean Code》与《Clean Architecture》，核心都在教导如何控制复杂性。当复杂性无法被有效治理与隔离，进而影响后续迭代时，便形成了技术债务。
Ward Cunningham describes unfinished refactoring as going into debt. Most companies need some debt in order to function efficiently.
-- Martin Fowler《Refactoring》
译：沃德把未完成的重构工作形容为“债务”。很多公司都需要借债来使自己更有效地运转。
债务本身并非绝对错误。正如美国依靠美元、美股、美债三大支柱支撑金融帝国，中国政府债务也在 2026 年突破 100 万亿元。软件领域同样需要适度“借债”以换取发展速度，关键在于控制负债率。
04「理解」是真痛点还是伪目标
过往面对前人遗留的“祖传代码”，我们往往只能“屎上雕花”。但在 AI 编程时代，多层嵌套的条件分支、无限套用的函数回调等人类难以接受的代码，对机器而言或许十分友好。更关键的是，真正落笔的已不再是人类。
英伟达黄仁勋曾言：“不用再学具体的编程技术，AI 就是编程技术，人类语言就是编程语言。”当然，作为 Token 生产端的代表，此观点需辩证看待。从马斯克推崇的“第一性原理”出发，“理解”或许不是终极追求，达成诉求才是核心。若通过简单提示词即可构建所需软件，“理解”的重要性是否被高估？
Vibe Coding 风靡全球
There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
-- Andrej Karpathy
译：有一种新的编程方式我称之为“氛围编程”——你彻底交给感觉、拥抱指数增长、甚至忘记代码的存在。
2025 年 2 月，OpenAI 联合创始人 Andrej Karpathy 提出"Vibe Coding"一词，并迅速成为科技圈热词，入选《柯林斯词典》2025 年度词汇。其低门槛、高速度、自然语言驱动的特性，让开发者角色从“建筑工人”转变为“甲方”，使非专业人员也能快速从零构建完整软件。
歌手胡彦斌基于 Vibe Coding 打造的粉丝互动社区应用“彦火”APP，仅用一个月便完成开发与迭代，并同步上架 iOS 和 Android 端。他通过 AI 工具利用自然语言驱动代码生成、规划架构及调试部署，展示了这一模式的潜力。
近期有观点认为，理科生创造 AI 大模型的使命已完成，未来由自然语言驱动的发展中，文科生将更具优势。尽管 Vibe Coding 存在诸多问题，但不可否认，它在“不理解”的前提下仍能达成阶段性目标。
Grok 的二进制直出愿景
2024 年，东京大学开发了一项自动驾驶技术：人形机器人无需改造车辆电子系统或安装昂贵传感器，仅凭仿生骨架、高精度摄像头及传感器，模仿人类驾驶决策即可完成全自动驾驶。
这一案例引人深思：车本身就是系统，系统间通过电路信息互通即可，无需额外桥接物理层。反观当前计算机编程，人类发明编程语言与编译器将代码转为机器码。AI 介入后，并未直接对接计算机系统，而是像人一样产出代码，本质上只是替换了流程中的节点负责人，未改变生产方式。
maybe even by the end of this year, you don't even bother doing coding — the AI just creates the binary directly, more efficiently than any compiler.
-- Elon Musk
译：也许就在今年年底，你甚至都不用写代码了——AI 会直接生成二进制文件，比任何编译器都高效。
马斯克在 2026 年 2 月 xAI 全员大会上提出"AI 将跳过源代码直接生成二进制文件”。若对比东京大学的自动驾驶案例，当前仅用 AI 提效原流程节点的做法，大概率不属于 AI Native 范畴。
或许"Binary Directly"才是终局。AI 不应只是流水线上的替代者，而应重构整个流水线。若此愿景成真，软件工程师的“理解”将失去意义，因为“软件工程师”这一角色也将随之消失。
05「理解」到底决定着什么？
加拿大维多利亚大学软件工程教授 Margaret-Anne Storey 在其创业课程中发现一个典型问题：学生团队借助 AI 能快速交付功能并达成里程碑，但在第八周时，一处简单修改却在意想不到的地方破坏系统，导致进展停滞。
起初团队归咎于快速交付产生的技术债务（混乱代码、仓促实现）。但深入分析后发现，更深层的问题在于：无人能解释某些设计决策的成因，也说不清系统各部分如何协同。代码或许混乱，但核心危机是团队的“共享理解”（即系统理论）已悄然碎裂。
三元债模型（Triple Debt Model）
Margaret-Anne Storey 在《From Technical Debt to Cognitive and Intent Debt》中指出，生成式 AI 不会消除软件工程挑战，而是重新分配它们。她将 AI 编码时代的软件债务分为三类：
债类型 |
存在于 |
定义 |
造成的后果 |
技术债 Technical Debt |
代码 (code) |
代码层的问题/捷径 |
让系统难以改变 |
认知债 Cognitive Debt |
人 (people) |
团队随时间对系统共享理解的侵蚀 |
让团队难以理解、难以安全推理变更 |
意图债 Intent Debt |
制品 (artifacts) |
目标/约束/理由未被外化捕获 |
让人不知道系统到底是为什么而建 |
技术债 Technical Debt
技术债是最为人熟知的一层，存在于代码之中。自 1993 年 Ward Cunningham 提出以来，Kent Beck、Martin Fowler 等人已配套了测试驱动、重构、代码评审等还债工具。由于其可见性（如圈复杂度、重复代码率等量化指标），程序员可通过设计模式、关注点分离等手段进行有效治理。
Generative AI may reduce technical debt while simultaneously accelerating the accumulation of cognitive and intent debt.
-- Margaret-Anne Storey From Technical Debt to Cognitive and Intent Debt
译：生成式 AI 可能在降低技术债的同时，加速认知债与意图债的累积。
在 AI 编程时代，技术债相对容易管理。代码重构、单测生成、逻辑解释及 AI 代码评审正是大模型擅长之处。但这并不意味着可以忽视它，只是相较于认知债与意图债，其风险更可控。
认知债 Cognitive Debt
若技术债活在代码里，认知债则活在人身上。它指团队对系统“共享理解”的缺失。软件运转依赖分布在不同人和文档中的足够共享理解，而认知债即是这份理解中不断累积的空洞。
When a developer writes code from scratch, even messy code, the friction and effort mean they build at least a partial mental model along the way. When an AI generates that same code, the developer may accept it without building the same level of understanding.
-- Margaret-Anne Storey From Technical Debt to Cognitive and Intent Debt
译：当开发者从零写代码，哪怕是烂代码，那份摩擦与投入意味着他至少在过程中建立起了部分心智模型。而当 AI 生成同样的代码，开发者可能直接接受，却没有建立起同等程度的理解。
其形成机制尤为致命：手动敲代码时的“卡壳”与“费劲”迫使开发者建立心智模型；而 AI 生成代码时，开发者往往直接接受（accept all），却未同步生长出相应的理解。连续操作数天后，便不知程序究竟如何运行。
意图债 Intent Debt
意图债既不存于代码，也不存于人脑，而存在于制品中：需求文档、架构决策记录、实现计划等。当指导系统演进的目标、约束和理由未被清晰表达或记录时，便欠下了意图债。表现为反复澄清需求、技术方案答非所问或因缺乏上下文消耗过量 Token。
Looking ahead, the core developer's skill may not be authoring code, but maintaining correct understanding of what the system does and why, and how it can evolve.
-- Hicks The New Developer
译：展望未来，开发者的核心技能或许不再是写代码，而是持续维护对“系统在做什么、为什么这么做、以及它能如何演进”的正确理解。
代码承载的“意图”不仅是“怎么做”，更是“为什么这么做”。在依赖 AI 之前，这个“为什么”至少存在于程序员脑中；而 AI 生成代码时，取舍基于统计概率，既未落入代码，也未存入记忆，在生成瞬间便已蒸发。
意图债催生认知债（无人知晓“为什么”，新人难建心智模型），认知债又反噬制造技术债（不理解系统导致糟糕实现）。三者相互咬合、彼此放大，漩涡中心正是被让渡出去的“理解”。
理解的本质是为了参与
2026 年 7 月，前 MIT 研究者、Notion 设计工程师 Geoffrey Litt 在 AI Engineer Conference 上提出：理解的本质不是为了验证，而是为了参与，是为了让你具备提出改进系统下一个想法的能力。
三年前，AI 主要用于代码补全，我们需验证其推荐是否正确。如今随着 Agentic AI 的发展，在定好 SPEC 和验证标准后，AI 的表现甚至优于人类。
We don't understand to verify — we understand to participate. Your understanding of the system is what lets you have the next idea.
-- Geoffrey Litt（AI Engineer Conference, 2026）
译：我们理解代码，不是为了“验收”，而是为了“参与”。是你对系统的理解，让你能想出下一个点子。
Geoffrey Litt 的答案是"understand to participate"。AI 让“写代码”变易，但“决定下一步做什么”仍需由脑中装有系统的人完成。项目是与 Agent 成千上万次的循环，每次循环后需有人提问：“如果……会怎样？”能否提出高质量问题，取决于脑中是否有完整的心智模型。缺乏此储备，指令将愈发模糊同质，最终丧失创造性主导权。
Vibe Coding 的自我修正
Vibe Coding 虽因低门槛、快产出而风靡，但在生产项目中效果不及预期。高达 95% 的开发者表示，修正 AI 生成代码错误的时间远超节省的时间，自嘲为“大模型善后工程师”。
Karpathy 在一年为其按下暂停键，认为 Vibe Coding 仅适用于一次性项目或 Demo。随着 AI Agent 编程成为专业人士默认工作流，他提出"Agentic Engineering"取代 Vibe Coding。当前践行的"Harness Engineering"亦是该思想的落地。
You can outsource your thinking but you can't outsource your understanding.
-- Andrej Karpathy
译：你可以外包你的思考，但不要外包你的理解。
Karpathy 强调：“你可以外包思考，但不要外包理解。”AI 可辅助选择技术方案或算法，但无法替你理解系统为何而建、核心问题是什么。“到底要做什么？为什么值得做？如何分配给 Agent？”这些仍受限于人类的“理解能力”。
06 写在最后
《权力的游戏》中“兰尼斯特必有偿”深入人心。软件世界的债务亦不会凭空消失，只会被记账、转移或延期，终将在某刻引发不可逆转的灾难。
AI gets you 70% of the way fast. The remaining 30% is where experienced engineers earn their keep.
-- Addy Osmani The 70% Problem
译：AI 能飞快带你走完 70% 的路，剩下的 30% 才是资深工程师体现价值的地方。
AI 编程时代，单纯的 Coding 正逐渐被接管，但代码只是理解的产物，而非理解本身。理解系统行为、用户需求及未来方向至关重要。AI 是放大器而非替代者，它既放大优势，也暴露薄弱。
大马士革刀会越来越锋利，但挥向何处由握刀之人决定。你不会被 AI 取代，前提是你仍在持续生长新的理解。
References
[01] 大马士革刀
[02] Programming as Theory Building
[03] 《The Mythical Man-Month》
[04] 《Clean Code》
[05] 《Clean Architecture》
[06] Loop Engineering
[07] 什么是第一性原理
[08] Andrej Karpathy
[09] Vibe Coding
[10] Margaret-Anne Storey
[11] From Technical Debt to Cognitive and Intent Debt
[12] Geoffrey Litt
[13] AI Engineer conference
[14] Agentic Engineering
[15] Harness Engineering
[16] From Vibe Coding to Agentic Engineering
*注：本文为作者个人技术思考与经验分享，不代表公司的官方立场或观点。文中部分论述涉及对技术趋势和发展方向的前瞻性判断，基于作者写作时的认知与经验，所有内容仅供交流参考，读者应结合自身场景独立评估。
