"AI优先"与"巴士指数为0"的困境

当人工智能成为知识传承的唯一守护者

directions_bus 巴士指数(Bus Factor)的概念

巴士指数用来衡量一项知识彻底失传的风险——在软件开发项目中，它估算得有多少个团队成员被巴士撞倒，项目才会陷入无人能懂、无法继续的窘境。

巴士指数概念图

例如，如果你的团队里有3个人知道如何恢复数据库备份，那么这项工作的"巴士指数"就是3。

history 从"巴士指数为1"到"巴士指数为0"的转变

从人类文明的黎明开始，"巴士指数"的最坏情况也一直是1。只要某个知识的唯一掌握者不幸离世，除非他提前把知识传授了出去，否则这份知识就随之消失了。

为了避免这种窘境，人类付出了巨大努力：午餐分享会、撰写文档、录制视频教程、知识交接、项目演示和展示……更不用说还有学校这种机制。

然而，在2022年11月30日这一天，一切都改变了。ChatGPT正式向公众发布，开启了生成式AI(GenAI)的大众化时代。突然之间，人类开始心安理得地接受一个不仅是1，甚至是0的巴士指数。

smart_toy "AI优先"带来的问题

三年后，"AI优先"(AI first)的概念由此诞生。你可能会以为，"AI优先"意味着"人类第二"。但毫不意外的是，当我们将创造过程委托给机器后，在知识传承这件事上，我们人类自己反倒无处容身了。

在编程领域，越来越多的从业者乐于让大语言模型(LLM)来生成函数、整个功能，甚至是完整的项目。他们不再去理解自己的代码库并维护这份知识，而是主动地、从一开始就避免掌握任何关于项目的知识，转而追求所谓的"凭感觉编程"(vibe)。

// 凭感觉编程示例：开发者不理解代码，完全依赖AI生成
function processData(data) {
  // AI生成的代码，开发者不知道具体实现逻辑
  return aiGeneratedTransform(data);
}

warning "凭感觉编程"的缺陷

在大语言模型出现之前，接手一个新代码库时总能指望获得一些帮助——要么有一位导师，要么至少有一些（可能部分过时了的）文档。有了大语言模型后，这一切都成了泡影。

你唯一能依靠的，就是自己去破译一个极不完美的系统生成的东西，或许还能向这个同样不完美的系统询问关于它的代码的解释（它早就把最初是怎么写的忘得一干二净了）。

想象一下，你不得不去修复bug、添加新功能、修补安全漏洞、升级依赖，而你面对的这个软件，地球上没有任何一个人对它是如何构建的、以及为何要这样构建，有哪怕一丝一毫的概念。

结论与思考

"凭感觉编程"(Vibe Coding)从根本上就是有缺陷的，因为它创造了一个"巴士指数为0"的困境。除非有一天，我们能拥有一个100%的时间都能生成100%准确代码的AI，并且给它输入的提示(prompts)也是100%准确的。

在AI辅助编程的时代，我们需要重新思考知识传承的方式，确保人类仍然是知识的守护者，而不是完全依赖AI。这需要我们在享受AI带来的便利的同时，保持对代码的理解和掌控。

"AI优先"与"巴士指数为0"的困境 - 第二部分

从"巴士指数为1"到"巴士指数为0"的转变

AI时代下的知识传承危机

history 历史上的知识传承

从人类文明的黎明开始，甚至在巴士被发明出来之前，"巴士指数"的最坏情况也一直是1。只要某个知识的唯一掌握者不幸离世，除非他提前把知识传授了出去，否则这份知识就随之消失了。

1
知识唯一掌握者
↓
知识传授
N
多人掌握知识

为了避免这种"巴士指数为1"的窘境，人类付出了巨大的努力：

  • 午餐分享会
  • 撰写文档
  • 录制视频教程
  • 知识交接
  • 项目演示和展示
  • 学校教育机制

为了传承知识，我们投入了数不清的人力。

change_history AI时代的转折点

然而，在2022年11月30日这一天，一切都改变了。ChatGPT正式向公众发布，开启了生成式AI(GenAI)的大众化时代。突然之间，人类的大部分成员开始心安理得地接受一个不仅是1，甚至是0的巴士指数。

三年后，"AI优先"(AI first)的概念也由此诞生。你可能会以为，"AI优先"意味着"人类第二"。但毫不意外的是，当我们将创造过程委托给机器后，在知识传承这件事上，我们人类自己反倒无处容身了。

传统开发模式 AI优先模式
开发者理解代码逻辑 开发者依赖AI生成代码
巴士指数 ≥ 1 巴士指数 → 0
知识在团队中传承 知识仅存在于AI模型中
文档和注释详实 文档和注释缺失

code 编程领域的转变

让我们把目光聚焦在编程领域。现在，似乎有越来越多的从业者乐于让大语言模型（LLM）来生成函数、整个功能，甚至是完整的项目（连安全漏洞都一并打包送上）。

// 传统编程方式：开发者理解并维护代码
function calculateTotal(items) {
  // 开发者明确知道这个函数的作用和实现逻辑
  let total = 0;
  for (const item of items) {
    total += item.price * item.quantity;
  }
  return total;
}

// AI优先编程方式：开发者不理解代码
function calculateTotal(items) {
  // AI生成的代码，开发者不知道具体实现逻辑
  return aiGeneratedFunction(items);
}

他们不再去理解自己的代码库并维护这份知识，而是主动地、从一开始就避免掌握任何关于项目的知识，转而追求所谓的"凭感觉编程"（vibe）。

关键转变

从"巴士指数为1"到"巴士指数为0"的转变，标志着人类知识传承方式的根本性变革。这种转变不仅影响软件开发领域，也可能扩展到其他知识密集型行业。

当AI成为知识的唯一掌握者，而人类完全依赖AI时，我们就面临着一个前所未有的风险：一旦AI系统失效、被修改或无法访问，相关的知识将永久消失。

"AI优先"与"巴士指数为0"的困境 - 第三部分

"AI优先"带来的问题

当人工智能成为知识创造的主导者

priority_high "AI优先"的实质

三年后，"AI优先"(AI first)的概念由此诞生。你可能会以为，"AI优先"意味着"人类第二"。但毫不意外的是，当我们将创造过程委托给机器后，在知识传承这件事上，我们人类自己反倒无处容身了。

"AI优先"不是将人类置于第二位，而是将人类完全排除在知识传承链之外。

让我们把目光聚焦在编程领域。现在，似乎有越来越多的从业者乐于让大语言模型（LLM）来生成函数、整个功能，甚至是完整的项目（连安全漏洞都一并打包送上）。

code_off 编程实践的转变

开发者不再去理解自己的代码库并维护这份知识，而是主动地、从一开始就避免掌握任何关于项目的知识，转而追求所谓的"凭感觉编程"（vibe）。

// 传统编程方式：开发者理解代码逻辑
function authenticateUser(username, password) {
  // 开发者明确知道认证流程和安全措施
  const user = database.findUser(username);
  if (!user) return false;
  // 使用安全的哈希比较
  return bcrypt.compare(password, user.hashedPassword);
}

// AI优先编程方式：开发者不理解代码
function authenticateUser(username, password) {
  // AI生成的代码，开发者不知道具体实现逻辑
  return aiGeneratedAuth(username, password);
}

当巴士撞上南墙，我们不得不面对一个现实：没有任何人真正理解这些AI生成的代码是如何工作的，也没有人知道如何修复它们的问题。

psychology "凭感觉编程"的心理机制

speed

效率至上

追求快速完成任务，而不关心代码质量和可维护性

trending_up

短期收益

关注眼前成果，忽视长期技术债务

psychology_alt

认知卸载

将思考负担转移给AI，减少自身学习动力

group_off

知识孤岛

缺乏团队协作和知识共享，各自依赖AI

compare_arrows 传统开发与AI优先的对比

传统开发模式
person 开发者理解代码逻辑
description 详尽的文档和注释
groups 团队知识共享
build 可维护的代码结构
security 明确的安全考量
AI优先模式
smart_toy 依赖AI生成代码
description_off 缺乏文档和注释
person_off 知识仅存在于AI中
build_circle 难以维护的代码结构
gpp_bad 潜在的安全隐患

核心问题

"AI优先"带来的最大问题是，它创造了一个巴士指数为0的环境。当没有任何人类真正理解系统的运作方式时，我们就面临着知识彻底失传的风险。

这种模式不仅影响软件开发的可持续性，还可能导致安全漏洞、技术债务累积，以及无法应对系统故障的窘境。更可怕的是，这种趋势可能从编程领域扩展到其他知识密集型行业。

"AI优先"与"巴士指数为0"的困境 - 第四部分

"凭感觉编程"的缺陷

当AI成为代码的唯一理解者

warning 理解与维护的困境

在大语言模型出现之前，只要你的团队尽职尽责，你在接手一个新代码库时总能指望获得一些帮助——要么有一位导师，要么至少有一些（可能部分过时了的）文档。有了大语言模型后，这一切都成了泡影。

你唯一能依靠的，就是自己去破译一个极不完美的系统生成的东西，或许还能向这个同样不完美的系统询问关于它的代码的解释（哦，对了，它早就把最初是怎么写的忘得一干二净了）。

我们可以暂时抛开"凭感觉编程"的种种缺陷，以及大语言模型生成的代码普遍存在的问题，这些留到另一篇文章再谈。事实上，AI生成的代码质量如何在这里并不关键。

bug_report "凭感觉编程"的核心问题

visibility_off

黑盒系统

开发者不理解AI生成的代码逻辑，无法预测其行为或副作用

build

维护困难

修复bug或添加新功能时，缺乏对系统架构的理解

security

安全风险

无法识别和修复AI可能引入的安全漏洞

sync_problem

依赖升级

升级依赖库时，无法预测对系统的影响

// AI生成的代码示例：开发者不理解其工作原理
function processUserData(userData) {
  // 这段代码由AI生成，开发者不知道具体实现逻辑
  const transformedData = userData.map(item => {
    return {
      ...item,
      processed: complexTransformation(item)
    };
  });
  // 开发者不知道complexTransformation函数做了什么
  return transformedData;
}

person_off 真实世界的风险场景

engineering 开发者视角

想象一下，你不得不去修复bug、添加新功能、修补安全漏洞、升级依赖，而你面对的这个软件，地球上没有任何一个人对它是如何构建的、以及为何要这样构建，有哪怕一丝一毫的概念。

people 用户视角

现在，再想象一下，你就是那个用户，正在向一个软件上传你的个人文档、信用卡信息、私密照片或想法，而对于这个软件是如何构建的、以及为何要这样构建，地球上没有任何一个人有哪怕一丝一毫的概念。

读代码终究比写代码要复杂得多。当没有人真正理解代码时，维护和改进就成了一场赌博。

psychology 知识传承的断裂

"凭感觉编程"不仅影响当前的开发工作，更重要的是它切断了知识传承的链条。在传统的软件开发模式中，知识通过以下方式在团队中传递：

  • 代码审查和讨论
  • 技术文档和注释
  • 团队培训和指导
  • 项目交接和演示

而在"凭感觉编程"模式下，这些知识传承机制都被绕过或简化，导致：

  • 新成员无法理解系统架构
  • 团队成员之间缺乏共同理解
  • 系统决策和设计思路丢失
  • 技术债务不断累积

根本缺陷

"凭感觉编程"(Vibe Coding)从根本上就是有缺陷的，因为它创造了一个巴士指数为0的困境。当然，除非有一天，我们能拥有一个100%的时间都能生成100%准确代码的AI，并且给它输入的提示（prompts）也是100%准确的。

在当前的AI发展阶段，这种编程方式不仅不可持续，而且对软件质量和安全性构成严重威胁。我们需要重新思考如何在利用AI提高效率的同时，保持对代码的理解和掌控。

"AI优先"与"巴士指数为0"的困境 - 第五部分

风险与解决方案

应对"巴士指数为0"的挑战

crisis_alert "巴士指数为0"带来的风险

当软件开发完全依赖AI，而人类开发者不再理解代码时，我们面临着一系列严峻的风险：

security

安全漏洞

AI生成的代码可能包含未被发现的安全漏洞，而没有人能够识别和修复这些漏洞，导致系统面临严重的安全威胁。

build_circle

维护困境

当系统出现故障或需要添加新功能时，缺乏对代码理解的人类开发者将无法有效维护和改进系统。

trending_up

技术债务

不断累积的技术债务将使系统变得越来越难以维护，最终可能导致整个项目需要重写。

cloud_off

AI依赖风险

过度依赖特定AI服务可能导致当该服务不可用时，整个开发流程陷入瘫痪。

想象一下，一个关键的基础设施系统（如电网、交通控制系统或医疗系统）完全由AI生成和维护，而没有任何人类真正理解其工作原理。当系统出现故障时，后果可能是灾难性的。

lightbulb 可能的解决方案

面对"巴士指数为0"的困境，我们需要重新思考AI在软件开发中的角色，并采取以下策略：

psychology

人机协作模式

将AI视为辅助工具而非替代者，人类开发者保持对代码的理解和掌控，同时利用AI提高效率。

// 人类开发者理解并验证AI生成的代码
function processData(data) {
  // AI建议的实现方式
  const result = aiSuggestedTransform(data);
  
  // 人类开发者添加验证和注释
  if (!validateResult(result)) {
    throw new Error("处理结果无效");
  }
  return result;
}
description

增强文档和知识管理

建立完善的知识管理系统，确保设计决策、架构思路和关键算法都有详细记录，并定期更新。

school

持续学习和技能提升

鼓励开发者深入理解系统原理，不仅会使用AI工具，还要掌握底层知识和技能，保持对代码的理解能力。

groups

团队知识共享

建立有效的团队知识共享机制，包括代码审查、技术分享会、配对编程等，确保知识在团队中广泛传播。

balance 平衡效率与可持续性

在AI辅助编程的时代，我们需要在追求短期效率和保证长期可持续性之间找到平衡。以下是一些实用的策略：

  • 代码审查制度：即使是AI生成的代码，也应经过人类开发者的严格审查，确保代码质量和安全性。
  • 渐进式采用：逐步引入AI工具，而不是完全依赖，让团队有时间适应和学习。
  • 明确责任边界：明确规定哪些任务可以委托给AI，哪些必须由人类完成。
  • 定期技术债务评估：定期评估和清理技术债务，防止系统变得难以维护。

AI是强大的工具，但工具的价值在于使用它的人。在追求效率的同时，我们不能牺牲对知识的理解和传承。

未来展望

"巴士指数为0"的困境是AI时代我们必须面对的挑战。解决这一困境需要我们重新思考软件开发的方式，将AI定位为增强人类能力的工具，而非替代人类的决策者。

通过建立人机协作的开发模式、加强知识管理和团队共享、持续提升开发者技能，我们可以在享受AI带来的效率提升的同时，保持对代码的理解和掌控，避免陷入"巴士指数为0"的困境。

最终，我们的目标不是抵制AI，而是找到一种方式，让AI和人类开发者共同工作，创造出既高效又可持续的软件系统。