AI 让人人都能写软件，但不是人人都能负责

过去半年，你可能见过类似的场景：一个做运营的朋友，用一个周末，借助 AI 编程工具搭出了一个内部数据看板。一个做产品的同事，三天内上线了一个客户自助查询的小工具。没有专业开发团队，没有代码评审，甚至没有正式的部署文档。

它们跑起来了。至少在演示的时候，看起来跑得不错。

但很少有人问：三个月后呢？

数据源格式变了怎么办？用户量翻了十倍怎么办？有人发现了安全漏洞怎么办？谁来接手？谁看得懂当时 AI 生成了什么、为什么这样生成、哪些决策是有意的、哪些只是模型的随机偏好？

这不是在否定 AI 编程的价值。AI 让”先把东西做出来”变得前所未有地容易。问题在于，“做出来”只是软件生命周期的第一分钟。

理解代码，不只是为了挑错

Notion 设计工程师 Geoffrey Litt 今年 7 月发了一篇长线程。核心观点：即使 AI Agent 能写出越来越好的代码，人类仍然需要理解这些代码。

Litt 的背景值得注意。MIT HCI 博士，研究方向是”终端用户编程”——如何让非程序员也能驾驭计算机。他长期关注的问题不是”程序员怎么更高效”，而是”普通人怎么真正参与软件创造”。

有意思的是，他的论点不是”AI 写的代码可能有 bug，所以我们要去检查”。如果只是验证对错，AI 本身已经越来越擅长自我检查了。他的论点更深一层：理解是为了参与。

项目不是一次性的。它是人和 AI 之间无数次的迭代循环。你对系统的理解，决定了你能不能提出下一个有价值的方向。如果你脑中缺少对系统的概念模型，你参与这个项目的能力就会被实质性地限制。

不理解自己做出了什么，你就无法决定下一步该做什么。

认知债：速度背后的隐性成本

这个判断和近两年逐渐升温的一个概念高度吻合：认知债（Cognitive Debt）。

维多利亚大学计算机科学教授 Margaret-Anne Storey 在 2026 年初系统阐述了这个概念。定义很精确：技术债存在于代码里，认知债存在于人的脑子里。它是指系统的演进结构和团队对系统的共同理解之间，逐渐扩大的鸿沟。

Storey 讲了一个真实案例。她指导的一个学生团队前几周进展顺利，但到第七八周时撞了墙——无法做出任何简单修改而不破坏其他东西。表面看是代码质量问题，但深入看，真正的问题是：团队中没有人能解释清楚某些设计决策为什么被做出，系统各部分之间如何协作。

Simon Willison 也坦言，他在 vibe coding 项目中遇到过同样的问题：通过提示词把整个新功能变出来，不审查实现细节，短期效果惊人，但代价是——他不再对自己项目有清晰的 mental model。

🧠 认知债和技术债一样，短期可以容忍，长期必须偿还。区别在于：技术债可以通过重构代码来还，认知债必须通过重建理解来还。而重建理解，往往比重构代码更慢、更痛苦。

我自己的体会：理解深浅决定迭代快慢

说一个更切身的例子。

过去几个月，我用 AI 编程工具陆续做了许多系统、插件，典型的如：一个多平台内容发布与数据分析工具（稿见），一个 AI 热点资讯聚合平台，还有一个多 Agent 工作流编排系统。工具无非 Claude Code、Cursor 这些，模型在 DeepSeek、GPT、Qwen 之间切换。

体验差异很大。

稿见和 AI 热点迭代很快。原因不复杂：这两个项目规模小，架构简单，我对这两个系统的业务理解比较深。遇到线上问题，能快速定位关联模块，结合 AI 辅助高效排障。理解深，所以迭代顺。

多 Agent 工作流平台则是另一个故事。前期开发很快，但后期维护和迭代明显慢。架构比较复杂，而我投入的理解时间远不如前两个。每次迭代都要重新花时间理解架构和业务逻辑；做久了还容易跟最初的设计偏离，需要反复校正。理解不够，迭代就慢。这块我准备用understand-anything 插件对系统做代码分析，生成知识图谱，以便深入梳理现有代码。

这个对比很直观：同一个作者、同样的 AI 工具，理解深的系统迭代快，理解浅的系统迭代慢。 AI 降低了写代码的门槛，但没有降低理解系统的门槛。

当然也有反例。AI 热点资讯聚合平台作为较小的项目，我可以在不太深入代码细节的情况下长期负责。但它有几个前提：项目体量小、业务逻辑我足够熟悉、每次迭代过什么我都清楚。这些条件缺一个，”不理解也能负责”就不成立。

开发门槛和负责门槛是两件事

回到最初的问题。AI 编程引发的讨论，很多时候混淆了两件不同的事：

开发门槛——能不能把一个想法变成可运行的软件。

负责门槛——能不能对这个软件的持续运行、安全、迭代和后果承担责任。

AI 确实在大幅降低前者。一个有领域知识但不会编程的人，现在可以绕过传统的学习曲线，直接让 AI 生成可工作的代码。快速验证想法、搭建内部工具、做原型演示、处理一次性数据分析——这些都是好事。

但负责门槛没有同步降低。软件一旦进入真实使用场景，它就需要：

• 有人能在出问题时排查原因

• 有人能判断什么时候该改、什么时候该重写

• 有人能评估安全风险和数据合规

• 有人能在需求变化时做出合理的架构调整

• 有人能对用户说”这个我来负责”

这些能力不来自”会用 AI 工具”，而来自对系统的理解。这种理解不是背诵语法，而是知道：这个系统为什么这样运作、它的边界在哪、哪些部分是脆弱的、改变一个变量会引发什么连锁反应。

那应该怎么办

这不是一个”所以大家都去学编程”的结论。时代不同了，学习路径也不同了。

更实际的做法可能是：

第一，区分场景。 用完即弃的一次性脚本、内部原型、验证假设的 MVP，AI 编程完全可以”做完就算”。但要长期运行、有真实用户、涉及数据的系统，至少需要有一个人能理解它的全貌。

第二，把理解当作持续动作。 Geoffrey Litt 在实践中总结了几种方法：让 AI 生成结构化的代码解释文档，而不是只给 diff；用小测试检验自己是否真的理解了刚生成的代码；为系统构建可以交互操作的”微世界”。共同点是：都在帮人维持对系统的理解，而不是把理解外包给 AI。

第三，承认认知债的存在，主动管理它。 就像技术债需要定期清理一样，认知债也需要定期检查。几个简单的问题：如果核心成员离开，还有人能解释这个系统为什么这样设计吗？如果 AI 生成的某段代码出了意料之外的问题，我们有能力判断和修复吗？我们对系统的理解，跟得上系统的变化速度吗？

几个注意

这篇文章不是在说 AI 编程不值得用。恰恰相反，AI 编程工具正在释放大量过去被技术门槛挡在外面的创造力。

也不是在说所有 AI 生成的代码都不可靠。很多场景下，AI 写出的代码质量足够好，甚至比一般人手写更稳定。

真正想说的是：做出来和能负责是两件不同的事。 AI 降低了前者，但没有消除后者。当越来越多人用 AI 做出越来越多的软件时，真正稀缺的能力不是”能写代码”，而是”能理解自己写出的系统，并对它的长期运行负责”。

这个判断不依赖于 AI 的能力上限在哪。即使未来 AI 能写出完美无 bug 的代码，”理解自己做出的东西”这件事仍然有价值。因为理解不只是为了纠错，而是为了继续创造。

参照来源

1. Geoffrey Litt X 长线程

https://x.com/geoffreylitt/status/2072522251300409556