分类： AI 与编程未来

引言：当 AI 从实验室走向生产

读完这篇关于 Yelp Assistant 架构演进的深度文章，我感受到一种前所未有的务实。文章重点关注从基础的检索增强生成（RAG）原型到稳健生产环境的转变，详细介绍了四个关键的数据策略转变。

这不是简单的技术升级，而是 AI 落地的实战智慧。从原型到生产，中间隔着无数的坑和挑战，Yelp 的经验为我们提供了宝贵的参考。

从 RAG 原型到生产环境：跨越鸿沟

文章首先探讨了从 RAG 原型到生产环境的转变。这让我思考一个问题：为什么从原型到生产这么难？

RAG 原型的特点：

• 数据量小：使用少量数据进行验证
• 功能简单：实现基本的检索和生成功能
• 性能要求低：对延迟和吞吐量要求不高
• 容错率高：可以接受一定的错误率

生产环境的要求：

• 数据量大：需要处理海量数据
• 功能复杂：需要支持各种复杂场景
• 性能要求高：对延迟和吞吐量要求很高
• 容错率低：几乎不能接受错误

这种转变的核心挑战在于：从”能用”到”好用”，从”验证想法”到”服务用户”，中间需要解决无数的技术和工程问题。

数据策略转变一：混合流式/批处理流水线

文章介绍的第一个数据策略转变是：通过混合流式/批处理流水线确保数据新鲜度。这个策略让我对数据管理有了新的认识。

流式流水线：

• 原理：实时处理数据，确保数据实时更新
• 优势：数据新鲜度高，延迟低
• 挑战：实现复杂，资源消耗大

批处理流水线：

• 原理：批量处理数据，定期更新
• 优势：实现简单，资源消耗小
• 挑战：数据新鲜度低，延迟高

混合流水线：

• 原理：结合流式和批处理的优势
• 优势：兼顾数据新鲜度和资源效率
• 挑战：实现复杂，需要精心设计

这个策略的意义在于：在数据新鲜度和资源效率之间找到平衡，确保 AI 助手能够提供最新、最准确的信息。

数据策略转变二：结构化事实与非结构化评论分离

文章介绍的第二个数据策略转变是：将结构化事实与非结构化评论分离。这个策略让我对数据架构有了新的认识。

结构化事实：

• 内容：商家信息、营业时间、地址等
• 特点：格式统一，易于查询
• 处理方式：使用数据库存储，通过 SQL 查询

非结构化评论：

• 内容：用户评论、评分、反馈等
• 特点：格式多样，难以查询
• 处理方式：使用向量数据库，通过向量检索

这种分离的意义在于：针对不同类型的数据，使用不同的存储和检索方式，提升查询效率和准确性。

数据策略转变三：利用文本和嵌入实现混合图片检索

文章介绍的第三个数据策略转变是：利用文本和嵌入实现混合图片检索。这个策略让我对多模态检索有了新的认识。

文本检索：

• 原理：通过文本描述检索图片
• 优势：直观，易于使用
• 挑战：需要准确的文本描述

嵌入检索：

• 原理：通过图片的向量嵌入检索相似图片
• 优势：可以找到视觉上相似的图片
• 挑战：需要训练嵌入模型

混合检索：

• 原理：结合文本和嵌入检索的优势
• 优势：兼顾准确性和灵活性
• 挑战：需要设计合理的融合策略

这个策略的意义在于：通过多模态检索，提升用户体验，让用户可以通过多种方式找到想要的图片。

数据策略转变四：统一的内容获取 API

文章介绍的第四个数据策略转变是：通过统一的内容获取 API 实现集中访问。这个策略让我对 API 设计有了新的认识。

分散访问：

• 原理：每个数据源有独立的 API
• 优势：灵活性高
• 挑战：难以管理，难以保证一致性

统一 API：

• 原理：所有数据源通过统一的 API 访问
• 优势：易于管理，易于保证一致性
• 挑战：设计复杂，需要抽象

这个策略的意义在于：通过统一的 API，简化数据访问，提升系统的可维护性和可扩展性。

推理优化一：将单体 LLM 解构为专用模型

文章介绍的第一个推理优化是：将单体 LLM 解构为用于护栏和关键词生成的专用模型。这个优化让我对模型架构有了新的认识。

单体 LLM：

• 原理：一个模型处理所有任务
• 优势：简单，易于部署
• 挑战：效率低，难以优化

专用模型：

• 原理：多个模型各司其职，每个模型专注于特定任务
• 优势：效率高，易于优化
• 挑战：复杂，需要协调

这种解构的意义在于：通过专用化，提升每个任务的效率和质量，同时降低整体成本。

推理优化二：通过并行化和分层模型优化推理效率

文章介绍的第二个推理优化是：通过并行化和分层模型优化推理效率，将延迟从 10 秒降低到 3 秒以下。这个优化让我对推理优化有了新的认识。

并行化：

• 原理：同时执行多个任务，减少总时间
• 优势：大幅提升效率
• 挑战：需要设计合理的并行策略

分层模型：

• 原理：使用不同规模的模型处理不同复杂度的任务
• 优势：在保证质量的同时提升效率
• 挑战：需要设计合理的分层策略

这个优化的意义在于：从 10 秒降低到 3 秒以下，延迟降低 70% 以上，用户体验大幅提升。

评估框架：使用 LLM-as-a-judge 的多维度评估

文章介绍的评估框架是：建立使用 LLM-as-a-judge 的多维度评估框架。这个框架让我对 AI 评估有了新的认识。

LLM-as-a-judge：

• 原理：使用 LLM 作为评估器，评估 AI 助手的回答质量
• 优势：可以评估多个维度，评估结果客观
• 挑战：需要设计合理的评估提示词

多维度评估：

• 准确性：回答是否准确
• 相关性：回答是否相关
• 完整性：回答是否完整
• 有用性：回答是否有用

这个评估框架的意义在于：通过多维度评估，全面了解 AI 助手的表现，为持续优化提供数据支持。

深度思考：AI 落地的核心是什么？

读完这篇文章，我一直在思考一个问题：AI 落地的核心是什么？

第一，不是模型。模型只是基础，不是核心。AI 落地的核心是数据和工程。

第二，不是算法。算法只是手段，不是核心。AI 落地的核心是系统架构和流程优化。

第三，不是技术。技术只是工具，不是核心。AI 落地的核心是用户体验和业务价值。

AI 落地的核心是：通过数据和工程的优化，将 AI 从原型转化为生产系统，为用户提供真正有价值的服务。

实践启示：如何实现 AI 落地？

作为从业者，我们需要思考如何实现 AI 落地。

第一，重视数据策略。通过混合流水线、数据分离、混合检索、统一 API 等策略，优化数据管理。

第二，优化推理效率。通过模型解构、并行化、分层模型等方法，优化推理效率。

第三，建立评估框架。通过 LLM-as-a-judge 的多维度评估框架，全面评估 AI 助手的表现。

第四，关注用户体验。通过降低延迟、提升准确性、增强相关性等方式，提升用户体验。

第五，持续迭代优化。通过数据分析和用户反馈，持续优化 AI 助手的性能。

这些方法不是一蹴而就的，需要长期投入和持续优化。但只有这样，才能实现真正的 AI 落地。

总结：从原型到生产，跨越鸿沟的智慧

这篇文章让我深刻认识到，从 RAG 原型到生产环境，中间隔着无数的坑和挑战。Yelp 的经验为我们提供了宝贵的参考。

作为从业者，我们需要：

• 理解从原型到生产的差距：认识到原型和生产环境的巨大差异
• 重视数据策略：通过混合流水线、数据分离、混合检索、统一 API 等策略，优化数据管理
• 优化推理效率：通过模型解构、并行化、分层模型等方法，优化推理效率
• 建立评估框架：通过 LLM-as-a-judge 的多维度评估框架，全面评估 AI 助手的表现
• 关注用户体验：通过降低延迟、提升准确性、增强相关性等方式，提升用户体验

AI 落地不是一蹴而就的，需要长期投入和持续优化。但只有这样，才能让 AI 真正为用户创造价值。

---

来源：Yelp 如何构建 “Yelp Assistant”

引言：当中国团队突破 MoE 的思维定式

读完这篇关于美团 LongCat 团队开源 LongCat-Flash-Lite 模型的详细介绍，我感受到一种前所未有的振奋。文章指出，该模型采用”非典型 MoE”设计，将近一半参数（31.4B）分配给 N-gram 嵌入层，实现了以 3B 级激活参数达到 80B 级性能的效果。

这不是简单的参数优化，而是对 MoE 架构的根本性创新。中国团队用实践证明：突破思维定式，才能实现真正的技术创新。

非典型 MoE 设计：打破传统架构

文章详细介绍了 LongCat-Flash-Lite 的”非典型 MoE”设计。这个设计让我对 MoE 架构有了新的认识。

传统 MoE 设计：

• 专家网络：多个专家网络，每个专家负责不同的任务
• 门控网络：选择最合适的专家处理输入
• 参数分配：参数主要分配给专家网络

非典型 MoE 设计：

• N-gram 嵌入层：将近一半参数（31.4B）分配给 N-gram 嵌入层
• 专家网络：剩余参数分配给专家网络
• 参数分配：参数主要分配给嵌入层

这种设计的核心思想是：将更多的参数分配给嵌入层，提升模型的语言理解能力，而不是简单增加专家数量。

这让我想到一个问题：为什么传统 MoE 将参数主要分配给专家网络？因为专家网络是 MoE 的核心，但这可能是一个思维定式。LongCat-Flash-Lite 的创新在于：打破这个思维定式，将参数分配给嵌入层。

N-gram Embedding：语言理解的新维度

文章重点介绍了 N-gram Embedding 的作用。这让我对语言模型的语言理解能力有了新的认识。

N-gram Embedding 的原理：

• N-gram：连续 N 个词的序列
• Embedding：将 N-gram 映射为向量
• 作用：捕获语言的局部模式和语义信息

N-gram Embedding 的优势：

• 语言理解：提升模型的语言理解能力
• 上下文感知：更好地理解上下文信息
• 语义捕获：捕获语言的语义信息

这种设计的意义在于：通过增加 N-gram Embedding 的参数量，提升模型的语言理解能力，而不是简单增加模型的总参数量。

专用缓存、内核融合及推测解码：推理效率的三重优化

文章介绍了 LongCat-Flash-Lite 的三项推理优化技术：专用缓存、内核融合及推测解码。这三重优化让我对推理效率的提升有了新的认识。

专用缓存：

• 原理：为常用的 N-gram 建立专用缓存
• 优势：减少重复计算，提升推理速度
• 效果：推理速度提升 30% 以上

内核融合：

• 原理：将多个操作融合为一个内核，减少内存访问
• 优势：减少内存访问次数，提升推理速度
• 效果：推理速度提升 20% 以上

推测解码：

• 原理：预测下一个 Token，减少实际计算量
• 优势：减少计算量，提升推理速度
• 效果：推理速度提升 50% 以上

这三重优化的核心是：从多个层面优化推理效率，实现 3B 级激活参数达到 80B 级性能的效果。

3B 级激活参数达到 80B 级性能：效率的革命

文章指出，LongCat-Flash-Lite 实现了以 3B 级激活参数达到 80B 级性能的效果。这个成就让我对模型效率有了新的认识。

激活参数 vs 总参数：

• 总参数：模型的所有参数，包括激活和未激活的参数
• 激活参数：实际参与推理的参数
• 效率：激活参数越少，推理效率越高

3B 级激活参数达到 80B 级性能：

• 效率提升：推理效率提升 26 倍以上
• 成本降低：推理成本降低 26 倍以上
• 速度提升：推理速度提升 26 倍以上

这种效率的革命，让大模型的应用变得更加可行。当推理成本降低 26 倍时，更多的应用场景变得经济可行。

API 可达 500-700 token/s：推理速度的极致

文章提到，LongCat-Flash-Lite 的 API 可达 500-700 token/s。这个速度让我对推理速度的极致有了新的认识。

500-700 token/s 的意义：

• 实时交互：可以实现实时的文本生成和交互
• 低延迟：响应延迟低于 200ms
• 高吞吐：单机可以服务大量用户

这个速度的意义在于：让大模型的实时应用成为可能。当推理速度达到 500-700 token/s 时，大模型可以用于实时对话、实时翻译、实时摘要等场景。

Agent 工具调用和代码修复：实战场景的领先

文章指出，LongCat-Flash-Lite 在 Agent 工具调用和代码修复（SWE-Bench）等实战场景中显著领先同类模型。这个成就让我对模型的实战能力有了新的认识。

Agent 工具调用：

• 场景：AI 智能体需要调用各种工具完成任务
• 挑战：需要准确理解工具的用途和调用方式
• 表现：LongCat-Flash-Lite 显著领先同类模型

代码修复（SWE-Bench）：

• 场景：AI 需要修复代码中的错误
• 挑战：需要准确理解代码逻辑和错误原因
• 表现：LongCat-Flash-Lite 显著领先同类模型

这些实战场景的领先，说明 LongCat-Flash-Lite 不是简单的参数优化，而是在实战能力上的真正提升。

生产级部署指南：从实验到生产

文章提供了基于 Transformers 和 SGLang 的生产级部署指南。这个指南让我对模型的生产部署有了具体的认识。

Transformers 部署：

• 优势：兼容性好，易于集成
• 适用场景：中小规模部署
• 挑战：推理效率相对较低

SGLang 部署：

• 优势：推理效率高，适合大规模部署
• 适用场景：大规模生产部署
• 挑战：需要额外的学习成本

这两个部署方案的意义在于：让 LongCat-Flash-Lite 可以快速从实验环境迁移到生产环境，实现真正的价值。

Function Calling 实战示例：AI 智能体的新能力

文章提供了 Function Calling 的实战示例。这个示例让我对 AI 智能体的新能力有了具体的认识。

Function Calling 的原理：

• AI 智能体可以调用预定义的函数
• 通过函数调用，AI 可以执行各种任务
• 这是 AI 智能体从”思考者”到”行动者”的关键

Function Calling 的意义：

• 扩展 AI 能力：让 AI 可以执行各种任务
• 提升实用性：让 AI 可以解决实际问题
• 增强交互性：让 AI 可以与外部系统交互

这个实战示例的意义在于：展示了 LongCat-Flash-Lite 在 AI 智能体场景中的应用潜力。

MIT 协议开源：真正的开源精神

文章宣布 LongCat-Flash-Lite 采用 MIT 协议开源。这个决定让我对开源精神有了新的认识。

MIT 协议的优势：

• 宽松：允许商业使用和修改
• 简单：没有复杂的限制条款
• 友好：对企业和开发者都友好

开源的意义：

• 促进创新：让更多人可以基于 LongCat-Flash-Lite 进行创新
• 降低门槛：让中小企业也能使用大模型技术
• 推动发展：推动整个行业的技术进步

这个开源决定的意义在于：体现了中国团队的开源精神，让更多人可以受益于这项技术创新。

深度思考：技术创新需要突破思维定式

读完这篇文章，我一直在思考一个问题：技术创新需要突破思维定式。

第一，传统 MoE 的思维定式。传统 MoE 将参数主要分配给专家网络，这可能是思维定式。LongCat-Flash-Lite 打破了这个思维定式，将参数主要分配给嵌入层。

第二，效率优先的思维定式。传统大模型追求更大的参数量，这可能也是思维定式。LongCat-Flash-Lite 证明了：效率比规模更重要。

第三，开源的思维定式。很多企业不愿意开源核心技术，这可能也是思维定式。LongCat-Flash-Lite 采用 MIT 协议开源，打破了这个思维定式。

技术创新的本质是：突破思维定式，尝试新的可能性。只有敢于挑战传统，才能实现真正的创新。

总结：中国团队的技术创新能力

这篇文章让我深刻认识到，中国团队的技术创新能力已经达到世界领先水平。

作为从业者，我们需要：

• 学习 LongCat-Flash-Lite 的创新思路：突破思维定式，尝试新的架构设计
• 重视模型效率：效率比规模更重要，追求更高的推理效率
• 关注实战场景：模型的最终价值在于解决实际问题
• 拥抱开源精神：开源可以促进创新，推动整个行业的发展

LongCat-Flash-Lite 的成功，标志着中国团队在 MoE 架构上的创新能力已经达到世界领先水平。这不是终点，而是新的起点。未来，中国团队将在更多领域实现技术创新，为 AI 的发展贡献中国智慧。

---

来源：美团开源 LongCat-Flash-Lite：实现轻量化 MoE 高效推理

引言：当 AI 需要隔离的”工作区”

读完这篇关于 AI 智能体沙箱技术的深度探讨，我感受到一种前所未有的清醒。文章的核心观点令人深思：AI 智能体需要隔离”工作区”（沙箱）以安全执行代码而不损害宿主系统。

这不是简单的技术问题，而是 AI 安全的根本性挑战。当 AI 能够执行代码时，如何确保它不会造成破坏，成为我们必须面对的问题。

智能体执行代码的风险：为什么需要沙箱？

文章首先探讨了 AI 智能体需要隔离”工作区”的迫切需求。这让我思考一个问题：为什么 AI 智能体需要沙箱？

执行代码的风险：

• 恶意代码：AI 可能生成恶意代码，破坏宿主系统
• 资源滥用：AI 可能滥用系统资源，导致系统崩溃
• 数据泄露：AI 可能访问敏感数据，导致数据泄露
• 权限提升：AI 可能尝试提升权限，获得更多控制权

这些风险不是理论上的，而是实际存在的。当 AI 能够执行代码时，它就像一个不受控制的程序，可能造成严重的破坏。

沙箱的意义在于：为 AI 提供一个隔离的执行环境，限制其权限，防止其造成破坏。

模式 1：智能体在沙箱内

文章正式提出了两种主要的集成模式，第一种是”智能体在沙箱内”。

模式 1 的架构：

• 智能体驻留在沙箱内部
• 沙箱提供隔离的执行环境
• 智能体在沙箱内执行代码

模式 1 的优势：

• 开发体验好：类似于本地环境的开发体验
• 性能高：智能体直接在沙箱内执行，无需网络通信
• 延迟低：没有网络延迟，响应速度快

模式 1 的风险：

• API Key 泄露：智能体可能泄露 API Key
• 知识产权外泄：智能体可能将敏感代码发送到外部
• 数据泄露：智能体可能访问沙箱外的数据

这种模式的核心问题在于：智能体在沙箱内，但沙箱不是完全隔离的。智能体可能通过 API 调用、网络通信等方式，泄露敏感信息。

模式 2：沙箱作为工具

第二种模式是”沙箱作为工具”。

模式 2 的架构：

• 智能体在外部运行
• 沙箱作为工具，通过 API 调用
• 智能体通过 API 调用沙箱执行代码

模式 2 的优势：

• 更快的迭代：智能体在外部，可以快速迭代
• 更好的凭据安全性：API Key 存储在外部，不泄露给智能体
• 推理与执行的清晰分离：智能体负责推理，沙箱负责执行

模式 2 的挑战：

• 开发体验差：需要通过 API 调用，开发体验不如本地环境
• 性能较低：需要网络通信，性能较低
• 延迟较高：有网络延迟，响应速度较慢

这种模式的核心优势在于：推理与执行的清晰分离。智能体在外部，不直接执行代码，降低了安全风险。

两种模式的对比：如何选择？

文章对比了两种模式，让我对如何选择有了清晰的认识。

选择模式 1 的场景：

• 需要本地开发体验
• 对性能要求高
• 对延迟敏感
• 可以接受一定的安全风险

选择模式 2 的场景：

• 需要更高的安全性
• 需要更快的迭代速度
• 需要清晰的推理与执行分离
• 可以接受一定的性能损失

这两种模式没有绝对的优劣，关键在于根据具体需求选择合适的模式。

耦合度、安全性和速度：三个核心权衡

文章指出，选择合适的架构需要考虑对耦合度、安全性和速度的具体需求。这三个因素是相互制约的。

耦合度：

• 模式 1：智能体在沙箱内，耦合度高
• 模式 2：智能体在外部，耦合度低

安全性：

• 模式 1：智能体在沙箱内，安全性较低
• 模式 2：智能体在外部，安全性较高

速度：

• 模式 1：智能体直接执行，速度快
• 模式 2：需要网络通信，速度慢

这三个因素的权衡，是选择架构的核心。没有完美的架构，只有最适合的架构。

deepagents 框架：实际实现示例

文章最后给出了使用 deepagents 框架的实际实现示例。这个示例让我对如何实现沙箱技术有了具体的认识。

deepagents 框架的核心功能：

• 沙箱管理：自动创建和管理沙箱
• API 封装：提供简洁的 API 调用接口
• 安全隔离：确保沙箱与宿主系统的隔离
• 资源限制：限制沙箱的资源使用

这个框架的意义在于：降低了沙箱技术的实现难度，让开发者可以快速集成沙箱功能。

深度思考：沙箱技术的本质是什么？

读完这篇文章，我一直在思考一个问题：沙箱技术的本质是什么？

第一，不是简单的隔离。沙箱技术不仅仅是隔离执行环境，更是对 AI 能力的限制和约束。

第二，不是完全的安全。沙箱技术可以提高安全性，但无法保证绝对安全。AI 仍然可能通过其他方式造成破坏。

第三，不是一劳永逸的解决方案。沙箱技术需要持续维护和更新，才能应对新的安全威胁。

沙箱技术的本质是：在 AI 的能力和安全性之间找到平衡。既让 AI 能够执行代码，又限制其权限，防止其造成破坏。

实践启示：如何构建安全的 AI 智能体？

作为从业者，我们需要思考如何构建安全的 AI 智能体。

第一，使用沙箱技术。为 AI 智能体提供隔离的执行环境，限制其权限。

第二，选择合适的架构。根据具体需求，选择”智能体在沙箱内”或”沙箱作为工具”架构。

第三，实施多层防护。除了沙箱，还需要实施代码审查、安全扫描、权限控制等多层防护。

第四，持续监控和审计。监控 AI 智能体的行为，审计其执行记录，及时发现异常。

第五，建立应急响应机制。当 AI 智能体出现异常时，能够快速响应，限制其影响。

这些措施不能保证绝对安全，但可以大大降低安全风险。

总结：沙箱技术是 AI 安全的最后一道防线

这篇文章让我深刻认识到，沙箱技术是 AI 安全的最后一道防线。当 AI 能够执行代码时，沙箱技术是防止其造成破坏的关键。

作为从业者，我们需要：

• 理解沙箱技术的必要性：认识到 AI 执行代码的风险，理解沙箱技术的重要性
• 选择合适的架构：根据具体需求，选择”智能体在沙箱内”或”沙箱作为工具”架构
• 权衡耦合度、安全性和速度：在三个因素之间找到平衡，选择最适合的架构
• 使用成熟的框架：使用 deepagents 等成熟框架，降低实现难度
• 实施多层防护：除了沙箱，还需要实施其他安全措施，构建多层防护体系

沙箱技术不是万能的，但它是 AI 安全的基础。只有建立了安全的沙箱环境，才能让 AI 智能体安全地执行代码，发挥其价值。

---

来源：智能体连接沙箱的两种模式

引言：破解”提效陷阱”的智慧

读完这篇快手技术团队对其三年 AI 研发范式演进的深度总结，我感受到一种前所未有的震撼。文章指出，企业在引入 AI 时普遍面临”提效陷阱”：即个人编码效率的提升往往无法转化为组织整体交付能力的增长。

这不是简单的技术问题，而是组织转型的系统性挑战。快手用 3 年、1 万人的实践，为我们揭示了 AI 转型的正确姿势。

提效陷阱：个人效率 vs 组织效能

文章指出的”提效陷阱”让我深思。为什么个人编码效率的提升，无法转化为组织整体交付能力的增长？

个人效率提升：

• 开发者使用 AI 工具，编码速度提升
• 个人产出增加，完成任务更快
• 表面看，组织效能应该提升

组织效能停滞：

• 整体交付能力没有显著提升
• 项目周期没有明显缩短
• 产品迭代速度没有加快

这种反差的核心原因在于：AI 提升的是个人效率，但组织效能取决于多个因素，包括协作效率、流程效率、决策效率等。只提升个人效率，不优化组织流程，无法实现组织效能的整体提升。

平台化：AI 转型的第一阶段

快手经历了从平台化到智能化的跃迁。平台化是 AI 转型的第一阶段。

平台化的核心：

• 统一开发环境：为开发者提供统一的开发环境和工具链
• 标准化流程：建立标准化的开发流程和规范
• 集中管理：集中管理开发资源，提升资源利用率

平台化的意义在于：为 AI 的引入奠定基础。没有统一的平台，AI 工具难以集成，效果难以评估。

这让我想到一个类比：基础设施建设。在引入新技术之前，需要先建设基础设施。平台化就是 AI 转型的基础设施建设。

智能化 1.0：聚焦个人工具

智能化 1.0 阶段，快手聚焦个人工具的智能化。

个人工具智能化：

• AI 代码补全：帮助开发者快速生成代码
• AI 代码审查：自动检查代码质量
• AI 测试生成：自动生成测试用例

这些工具确实提升了个人编码效率，但无法解决组织效能的问题。因为组织效能的提升，需要的是端到端的流程优化，而不仅仅是个人工具的智能化。

智能化 2.0：聚焦组织协同

智能化 2.0 阶段，快手聚焦组织协同的智能化。这是破解”提效陷阱”的关键。

组织协同智能化：

• 智能工作流平台（Flow）：支持 AI 上下文传递的智能工作流平台
• AI 代码生成率度量体系：建立严格的 AI 代码生成率度量体系
• 研发成熟度模型：定义从 L1 辅助到 L3 自主的研发成熟度模型

这些举措的核心是：将 AI 深度嵌入端到端的需求交付流程，重塑人机协作模式。

智能工作流平台（Flow）：AI 上下文传递的关键

文章详细介绍了智能工作流平台（Flow），这是快手 AI 转型的核心创新。

Flow 的核心功能：

• 支持 AI 上下文传递：在不同环节之间传递 AI 的上下文信息
• 智能任务分配：根据任务特点，自动分配给最合适的人或 AI
• 自动化流程：自动化重复性工作，提升流程效率

Flow 的意义在于：解决了 AI 工具的”孤岛”问题。传统 AI 工具各自为战，无法共享上下文，导致效率低下。Flow 通过上下文传递，让 AI 工具协同工作，实现端到端的智能化。

AI 代码生成率度量体系：量化 AI 的价值

文章提到，快手建立了严格的 AI 代码生成率度量体系。这个体系让我对 AI 的价值评估有了新的认识。

度量体系的核心指标：

• AI 代码生成率：AI 生成的代码占总代码的比例
• AI 代码质量：AI 生成代码的质量指标
• AI 代码采纳率：AI 生成代码被采纳的比例
• AI 代码修复率：AI 生成代码需要修复的比例

这些指标的意义在于：量化 AI 的价值，为决策提供数据支持。没有度量，就无法评估 AI 的效果，也无法持续优化。

研发成熟度模型：从 L1 辅助到 L3 自主

文章介绍了快手定义的研发成熟度模型，从 L1 辅助到 L3 自主。这个模型让我对 AI 的应用阶段有了清晰的认识。

L1 辅助：

• AI 作为辅助工具，帮助开发者完成任务
• 开发者主导，AI 辅助
• 适合简单任务

L2 协作：

• AI 与开发者协作完成任务
• 开发者与 AI 平等协作
• 适合中等复杂度任务

L3 自主：

• AI 自主完成任务，开发者审核
• AI 主导，开发者审核
• 适合复杂任务

这个模型的意义在于：为 AI 的应用提供了清晰的路径。从辅助到协作到自主，逐步提升 AI 的能力，降低风险。

端到端的需求交付流程：AI 转型的核心

文章的核心观点是：只有将 AI 深度嵌入端到端的需求交付流程，并重塑人机协作模式，才能实现组织级的效能突破。

端到端的需求交付流程：

• 需求分析：AI 辅助需求理解和分析
• 设计：AI 辅助架构设计和方案设计
• 编码：AI 辅助代码生成和代码审查
• 测试：AI 辅助测试用例生成和测试执行
• 部署：AI 辅助部署和运维

这个流程的核心是：AI 渗透到开发的每个环节，实现端到端的智能化。只有这样，才能实现组织效能的整体提升。

重塑人机协作模式：从”人+AI”到”AI+人”

文章提到，重塑人机协作模式是 AI 转型的关键。这让我对未来的协作模式有了新的想象。

传统模式（人+AI）：

• 人类主导，AI 辅助
• AI 是工具，人类是使用者
• 适合简单任务

新模式（AI+人）：

• AI 主导，人类审核
• AI 是执行者，人类是决策者
• 适合复杂任务

这种转变的意义在于：充分发挥 AI 的能力，让 AI 承担大部分执行工作，人类专注于更高层次的思考和决策。

深度思考：AI 转型的核心是什么？

读完这篇文章，我一直在思考一个问题：AI 转型的核心是什么？

第一，不是工具。AI 工具只是手段，不是目的。AI 转型的核心是组织效能的提升。

第二，不是技术。AI 技术只是基础，不是关键。AI 转型的核心是流程的优化和协作模式的重塑。

第三，不是个人。个人效率的提升只是开始，不是终点。AI 转型的核心是组织效能的整体提升。

AI 转型的核心是：将 AI 深度嵌入端到端的需求交付流程，重塑人机协作模式，实现组织级的效能突破。

实践启示：如何实现 AI 转型？

作为从业者，我们需要思考如何实现 AI 转型。

第一，建设平台。建设统一的开发平台，为 AI 的引入奠定基础。

第二，度量价值。建立 AI 价值度量体系，量化 AI 的贡献。

第三，优化流程。将 AI 深度嵌入端到端的需求交付流程，实现流程智能化。

第四，重塑协作。重塑人机协作模式，从”人+AI”到”AI+人”。

第五，持续迭代。持续优化 AI 工具和流程，不断提升组织效能。

这些方法不是一蹴而就的，需要长期投入和持续优化。但只有这样，才能实现真正的 AI 转型。

总结：AI 转型是组织变革，不是技术升级

这篇文章让我深刻认识到，AI 转型是组织变革，不是技术升级。个人效率的提升只是开始，组织效能的整体提升才是目标。

作为从业者，我们需要：

• 理解”提效陷阱”：认识到个人效率提升不等于组织效能提升
• 聚焦组织协同：将 AI 深度嵌入端到端的需求交付流程
• 重塑协作模式：从”人+AI”到”AI+人”，充分发挥 AI 的能力
• 建立度量体系：量化 AI 的价值，为决策提供数据支持
• 持续迭代优化：持续优化 AI 工具和流程，不断提升组织效能

AI 转型不是一蹴而就的，需要长期投入和持续优化。但只有这样，才能实现真正的组织级效能突破。

---

来源：3 年、1 万人，快手技术团队首次系统披露 AI 研发范式升级历程

引言：当大师为软件工程正名

读完这篇关于 UML 之父 Grady Booch 对 Anthropic CEO Dario 言论的有力反击，我感受到一种前所未有的振奋。文章的核心观点令人深思：软件工程的核心在于复杂系统中的权衡与取舍，而非单纯的代码编写。

这不是简单的观点之争，而是对软件工程本质的深刻洞察。Grady Booch 用他几十年的经验告诉我们：软件工程不会死亡，而是迎来了第三次黄金时代。

Dario 的”软件工程将死”论

文章提到，Anthropic CEO Dario 曾发表”软件工程将死”的言论。这个观点在 AI 时代并不罕见，很多人认为 AI 会取代程序员，软件工程将不再重要。

支持者的理由：

• AI 可以自动生成代码，程序员不再需要手写代码
• AI 可以自动测试代码，测试工程师不再需要手动测试
• AI 可以自动优化代码，性能工程师不再需要手动优化

这些理由看似合理，但忽略了一个关键问题：软件工程的核心是什么？

Grady Booch 的有力反击

Grady Booch 对 Dario 的言论进行了有力反击。他认为，软件工程的核心在于复杂系统中的权衡与取舍，而非单纯的代码编写。

软件工程的核心：

• 需求分析：理解用户需求，定义系统功能
• 架构设计：设计系统架构，确保系统可扩展、可维护
• 权衡取舍：在性能、成本、时间等因素之间做出权衡
• 风险管理：识别和管理项目风险，确保项目成功

这些核心工作，AI 可以辅助，但无法替代。因为它们需要人类的判断力、创造力和系统思维。

软件工程的三个黄金时代

Grady Booch 通过回顾软件工程与 AI 的三个黄金时代，阐明了技术演进始终伴随着抽象层级的提升。

第一个黄金时代（1960s-1980s）：

• 核心技术：操作系统、数据库、编程语言
• 抽象层级：从机器语言到高级语言
• 特点：从底层硬件到软件系统的抽象

第二个黄金时代（1990s-2010s）：

• 核心技术：互联网、云计算、移动应用
• 抽象层级：从单机系统到分布式系统
• 特点：从本地计算到云端计算的抽象

第三个黄金时代（2020s-）：

• 核心技术：AI、机器学习、自动化
• 抽象层级：从代码到意图的抽象
• 特点：从手动编码到 AI 辅助编码的抽象

每个黄金时代，软件工程都面临新的挑战，也迎来了新的机遇。AI 时代不是软件工程的终结，而是新的开始。

代码的分化：一次性自动化代码与长期存在的系统

Grady Booch 预测未来代码将分化为”一次性自动化代码”与”长期存在的系统”。这个预测让我对代码的本质有了新的认识。

一次性自动化代码：

• 特点：由 AI 自动生成，用于特定任务，用完即弃
• 例子：脚本、原型、测试代码
• 价值：快速验证想法，提升开发效率

长期存在的系统：

• 特点：由人类精心设计，长期维护和演进
• 例子：核心业务系统、基础设施、平台
• 价值：支撑业务发展，积累技术资产

这种分化的意义在于：AI 不是要取代所有代码，而是要取代那些不需要长期维护的代码。人类开发者可以专注于长期存在的系统，这些系统需要精心设计、持续优化。

提升在规模化条件下管理复杂性的能力

Grady Booch 建议开发者通过研习系统理论、生物学和神经科学，提升在规模化条件下管理复杂性的能力。这个建议让我深受启发。

系统理论：

• 核心思想：将系统作为一个整体来研究，关注系统各部分之间的相互作用
• 应用价值：帮助开发者理解复杂系统的行为，设计更好的系统架构

生物学：

• 核心思想：研究生命系统的演化、适应、协作等机制
• 应用价值：帮助开发者设计具有自适应、自修复能力的系统

神经科学：

• 核心思想：研究神经系统的结构、功能、学习机制
• 应用价值：帮助开发者设计具有学习能力、推理能力的 AI 系统

这三个学科的核心都是”复杂性”，这正是软件工程面临的最大挑战。通过研习这些学科，开发者可以提升管理复杂性的能力。

在 AI 时代实现职业升维

Grady Booch 的最终建议是：在 AI 时代实现职业升维。这个建议让我对职业发展有了新的思考。

职业升维的路径：

• 从编码者到架构师：从关注代码实现到关注系统设计
• 从执行者到决策者：从关注具体任务到关注战略决策
• 从技术专家到业务专家：从关注技术实现到关注业务价值
• 从个体贡献者到团队领导者：从关注个人产出到关注团队效能

这种升维不是简单的职位提升，而是思维模式的根本性转变。在 AI 时代，只有实现职业升维，才能保持竞争力。

深度思考：软件工程的核心是什么？

读完这篇文章，我一直在思考一个问题：软件工程的核心是什么？

第一，不是代码。代码只是软件工程的产物，不是核心。软件工程的核心是解决问题。

第二，不是工具。工具只是软件工程的手段，不是核心。软件工程的核心是方法论。

第三，不是技术。技术只是软件工程的基础，不是核心。软件工程的核心是权衡取舍。

软件工程的核心是：在复杂系统中，通过权衡取舍，找到最优解。这需要人类的判断力、创造力和系统思维，AI 可以辅助，但无法替代。

业界回应：有了 AI，SaaS 只会更加繁荣

文章提到，业界对”软件工程将死”的回应是：有了 AI，SaaS 只会更加繁荣。这个回应让我深有同感。

AI 对 SaaS 的影响：

• 降低开发成本：AI 可以自动生成代码，降低开发成本
• 提升开发效率：AI 可以辅助开发，提升开发效率
• 扩展应用场景：AI 可以实现传统方式无法实现的功能
• 创造新的商业模式：AI 可以催生新的商业模式

这些影响不是要取代 SaaS，而是要让 SaaS 更加繁荣。因为 AI 降低了开发门槛，让更多人可以参与软件开发，这将催生更多的 SaaS 应用。

总结：软件工程的第三次黄金时代已经到来

这篇文章让我深刻认识到，软件工程不会死亡，而是迎来了第三次黄金时代。

作为从业者，我们需要：

• 理解软件工程的核心：认识到软件工程的核心是权衡取舍，不是代码编写
• 拥抱 AI 工具：将 AI 作为辅助工具，提升开发效率
• 提升系统能力：通过研习系统理论、生物学、神经科学，提升管理复杂性的能力
• 实现职业升维：从编码者到架构师，从执行者到决策者，在 AI 时代保持竞争力

软件工程的第三次黄金时代已经到来，那些能够快速适应变化、实现职业升维的人，将迎来前所未有的机遇。

---

来源：UML 之父：Dario 大错特错，根本不懂软件工程！软件工程不会死亡！软件已经迎来第三次黄金时代！业界回应：有了 AI，SaaS 只会更加繁荣！