技术

企业正在积极采用 数据产品思维 作为管理数据资产的标准实践。这一方法将数据视为具有自身生命周期、质量标准，并专注于满足消费者需求的“产品”。无论组织选择 数据网格 还是 Lakehouse 架构，我们现在将其推荐为数据管理的默认建议。

我们强调数据产品思维中的以消费者为中心的原则，以推动更大的采用率和价值实现。这意味着通过 设计数据产品，从用例出发反向工作。同时，我们专注于使用现代数据目录（如 DataHub、Collibra、Atlan 和 Informatica）捕获和管理业务相关元数据与技术元数据。这些实践提升了数据的可发现性和可用性。此外，我们将数据产品思维应用于扩展 AI 项目，创建 AI 就绪数据。这一方法涵盖了全面的生命周期管理，确保数据不仅得到良好治理并具备高质量，同时在不再需要时能够符合法律和监管要求进行退役。

Fuzz 测试 ，或称模糊测试，是一种已经存在很长时间但仍然较少被广泛了解的测试技术。其目标是向软件系统输入各种无效数据并观察其行为。例如，对于一个 HTTP 端点，错误的请求通常应返回 4xx_ 错误，但 fuzz 测试往往会引发 5xx_ 错误甚至更严重的问题。随着工具的完善以及文档支持的增强，fuzz 测试在如今显得尤为重要，尤其是在更多 AI 生成代码和自满于 AI 生成的代码的背景下。因此，现在是采用 fuzz 测试的好时机，以确保代码的健壮性和安全性。

自我们在 2021 年首次提到 软件物料清单（SBOM） 以来，其生成已经从新兴实践转变为我们项目中的默认选项。SBOM 生态系统显著成熟，提供了强大的工具支持，并实现了与 CI/CD 系统的无缝集成。工具如 Syft、Trivy 和 Snyk 能够从源代码到容器镜像生成全面的 SBOM，同时支持漏洞扫描。FOSSA 和 Chainloop 等平台通过与开发工作流集成以及实施安全策略，进一步提升了安全风险管理能力。尽管统一的 SBOM 标准仍在演化，但对 SPDX 和 CycloneDX 的广泛支持已显著降低了采用门槛。同时，AI 系统也需要 SBOM 的支持。英国政府的 AI 网络安全行为准则 和 CISA 的 AI 网络安全协作手册 就证明了这一点。我们将继续关注该领域的发展动态。

在快速发展的 AI 驱动软件开发领域，威胁建模 比以往任何时候都更为关键，它不仅能够帮助构建安全的软件，同时还能保持敏捷性并避免出现 “安全三明治” 的情况。威胁建模是一组用于识别和分类潜在威胁的技术，可广泛应用于各种场景，包括生成式 AI 应用 ，这些应用 带来了独特的安全风险 。要想取得成效，威胁建模必须贯穿软件生命周期的各个阶段并定期执行，同时与其他安全实践相结合才能发挥最佳效果。这些实践包括定义跨职能的安全需求，以应对项目技术中的常见风险，以及利用自动化安全扫描工具进行持续监控，从而保障系统安全。

将 API 视为产品 意味着优先考虑开发者体验，不仅需要在 API 本身中融入合理和标准化的设计，还需要提供全面的文档以及流畅的入门体验。虽然 OpenAPI（如 Swagger）规范可以有效记录 API 接口，但入门仍然是一个挑战。开发者需要快速获取可用的示例，包括预配置的身份验证和真实的测试数据。随着 API 客户端工具（例如 Postman、Bruno 和 Insomnia）的逐步成熟，我们建议将 API 请求集合做为 API 产品的制品 。API 请求集合应经过精心设计，以引导开发者完成关键工作流程，帮助他们轻松理解 API 的领域语言和功能。为了保持请求集合的最新状态，我们建议将其存储在代码库中，并将其与 API 的发布流水线集成在一起。

在大型软件团队中，一个持久的挑战是确定由谁来做出塑造系统演进的架构决策。State of DevOps 报告 显示，传统的架构评审委员会（Architecture Review Boards）方式往往适得其反，不仅阻碍了工作流，还与低组织绩效相关。一种引人注目的替代方案是 架构建议流程 —— 这是一种去中心化的方法，任何人都可以做出架构决策，前提是他们向受影响的人和具有相关专业知识的人寻求建议。这种方法使团队能够在不牺牲架构质量的前提下优化工作流，无论是在小规模还是大规模环境中。乍看之下，这种方法似乎具有争议性，但像 架构决策记录（ADR） 和建议论坛这样的实践能够确保决策是经过充分信息支持的，同时赋予那些最接近实际工作的人员决策权。我们看到这一模型在越来越多的组织中取得了成功，包括那些处于高度监管行业的组织。

在上次关于检索增强生成(RAG)的更新中，我们已经介绍了 GraphRAG 。它最初在微软的文章中被描述为一个两步的流程：(1) 对文档进行分块，并使用基于大语言模型的分析构建知识图谱；(2) 通过嵌入检索的方式在查询时检索相关块，沿着知识图谱的边缘发现更多相关的分块，这些分块后续会被添加到增强提示中。在许多情况下，这种方法提高了大语言模型生成的响应数据的质量。我们在使用生成式 AI 理解遗留代码库的过程中也观察到了类似的好处——通过像抽象语法树和代码依赖这样的结构化信息去构建知识图谱。GraphRAG 模式正在获得更多的关注，像 Neo4j 的GraphRAG Python 库这样的工具与架构正在不断出现以支持该模式。同时，我们认为Graphiti也符合广义上的 GraphRAG 模式。

最小权限原则 确保用户和系统仅拥有执行任务所需的最低权限。特权凭证滥用是 安全漏洞 的主要原因之一，其中权限提升是常见的攻击向量。攻击者通常从低级访问权限开始，利用软件漏洞或配置错误获取管理员权限，尤其是在账号拥有过多或不必要权限时。另一个常被忽视的风险是静态特权（standing privileges）——即持续可用的特权访问，这大大增加了攻击面。 按需特权访问管理（Just-in-time Privileged Access Management） 有效缓解了这一问题，通过仅在需要时授予访问权限，并在任务完成后立即撤销权限，从而最大限度地降低暴露风险。真正的最小权限安全模型确保用户、应用程序和系统仅在最短时间内拥有完成任务所需的必要权限，这是合规性和监管安全的关键要求。我们的团队通过自动化工作流程实现了这一模型：触发轻量化的审批流程，为用户分配临时角色并限制访问权限，同时为每个角色强制设置生存时间（TTL），确保权限在任务完成后自动过期，从而进一步减少特权滥用的风险。

Scaling laws 是推动 AI 快速发展的关键原则之一，即更大的模型、更大的数据集和更多的计算资源能够带来更强大的 AI 系统。然而，消费级硬件和边缘设备往往缺乏运行大尺寸模型的能力，因此产生了对 模型蒸馏 的需求。

模型蒸馏 将知识从一个更大、更强的模型（教师模型）转移到一个更小、更高效的模型（学生模型）。这一过程通常包括从教师模型生成一个样本数据集，并对学生模型进行微调，以捕获其统计特性。与通过移除参数来压缩模型的 剪枝 技术或 量化 不同，蒸馏旨在保留领域特定的知识，同时将精度损失降到最低。此外，蒸馏还可以与量化结合使用，以进一步优化模型。

这种技术最早由 Geoffrey Hinton 等人提出，现已被广泛应用。一个显著的例子是 Qwen/Llama 的 DeepSeek R1 蒸馏版本，它们在小模型中保留了强大的推理能力。随着蒸馏技术的日益成熟，它已不再局限于研究实验室，而是被广泛应用于从工业项目到个人项目的各类场景中。像 OpenAI 和 Amazon Bedrock 这样的供应商也提供了详细的指南，帮助开发者蒸馏自己的 小语言模型（SLMs）。我们认为，采用模型蒸馏技术能够帮助组织更好地管理 LLM 部署成本，同时释放 本地设备上 LLM 推理 的潜力。

提示工程（Prompt Engineering） 是指为生成式 AI 模型设计与优化提示词（Prompt）的过程，其目标是生成高质量、上下文相关（Context-aware）的响应。这一过程通常包括针对特定任务或应用场景，精心构建清晰、具体且上下文相关的提示，以实现模型输出效果的最优化。随着大语言模型能力的不断提升，尤其是推理模型的出现，提示工程的实践也必须随之调整。根据我们在 AI 代码生成方面的经验，少样本提示（few-shot prompting） 在与推理模型协作时，可能不如简单的零样本提示（zero-shot prompting）表现出色。此外，被广泛使用的思维链（Chain-of-Thought，CoT）提示技术也可能降低推理模型的表现——原因可能在于当前推理模型通过强化学习已内置了 微调过的 CoT 机制 。

我们的实际经验也得到了学术研究的印证，即“高级模型可能消除软件工程领域对提示工程的依赖”。但在实际场景中，传统提示 工程技术仍然是减少模型幻觉（Hallucinations）并提升输出质量的重要手段，特别是在考虑推理模型与普通 LLM 在响应时间和 Token 成本等因素存在显著差异的前提下。在构建自主代理应用（Agentic Applications）时，我们建议根据实际需求策略性地选择模型，并持续迭代与优化提示模板及相应的工程方法。如何在性能、响应速度与 Token 成本之间找到最佳平衡，依然是充分发挥 LLM 效能的关键所在。

最近发布的 DeepSeek R1 充分展示了 小语言模型(SLMs） 为何仍然备受关注。满血版 R1 拥有 6710 亿个参数，并且需要约 1342GB 的 VRAM 才能运行，这通常只能通过八块最先进的 NVIDIA GPU 组成的“迷你集群”来实现。然而，DeepSeek 也提供了“蒸馏版”，即 Qwen 和 Llama 等更小的开放权重模型，使其能力得以迁移，并能够在更普通的硬件上运行。尽管这些小型版本在性能上有所折损，但相较于以往的小语言模型，依然实现了巨大的性能飞跃。小语言模型领域仍在不断创新。自上次技术雷达以来，Meta 推出了 Llama 3.2，涵盖 10 亿和 30 亿参数规模；微软发布了 Phi-4，其 140 亿参数模型在质量上表现出色；谷歌则推出了 PaliGemma 2，一个支持视觉-语言任务的模型，提供 30 亿、100 亿和 280 亿参数版本。这些只是近期发布的小型模型中的一部分，但无疑表明了这一趋势仍值得持续关注。

过去几个月， 利用生成式 AI 理解遗留代码库 这一领域取得了显著进展。主流工具如 GitHub Copilot 已被广泛宣传能够帮助现代化改造遗留代码库。类似 Sourcegraph Cody 等工具，也正在让开发者更轻松地导航和理解整个代码库。这些工具综合运用多种生成式 AI 技术提供上下文感知（Context-aware）的帮助，极大地简化了对复杂遗留系统的分析与处理。此外，S3LLM 等专业框架则展示了大语言模型（LLMs）如何有效处理大规模科学计算软件（例如 Fortran 或 Pascal），将 GenAI 强化的代码理解能力推广到传统企业 IT 以外的场景。我们认为，鉴于全球范围内大量的遗留代码，这种技术未来将持续获得更多关注并加速普及。

监督式软件工程代理的能力正在不断提升，它们现在能够识别所需的更新，并对代码库进行更大范围的修改。然而，我们也注意到，开发者对 AI 生成代码的自满情绪 正在增加，很多人不愿意审查由 AI 创建的大型变更集。一个常见的理由是：既然未来的修改可以交给 AI 来完成，那么面向人类的代码质量就没那么重要了。然而，事实恰恰相反——AI 编程助手在结构良好的代码库上表现得更好，因此 AI 友好的代码设计 对于代码的可维护性至关重要。

值得庆幸的是，面向人类的优秀软件设计同样能够为 AI 提供助力。比如，明确的命名可以为代码提供领域上下文和功能信息；模块化和抽象设计能够限制代码改动范围，使 AI 的工作上下文更易于处理；而 DRY（don’t repeat yourself）原则则能减少重复代码，让 AI 更容易确保行为一致性。到目前为止，最适合 AI 的设计模式依然与传统的软件设计最佳实践密切相关。随着 AI 的不断发展，我们预计会有更多专门针对 AI 的设计模式出现。因此，从现在开始以 AI 友好的视角来思考代码设计，将会对未来大有裨益。

AI 在软件团队中的应用正逐步超越单纯的代码生成，新的技术正在涌现。其中， AI 驱动的 UI 测试 正受到越来越多的关注，它利用 LLM 的能力来理解图形用户界面（GUI）。目前，该领域主要有几种不同的实现方式。一种方法是使用针对 UI 快照处理进行微调的多模态 LLM，这类工具允许测试脚本以自然语言编写，并能自主导航应用程序。例如，QA.tech 和 LambdaTest 的 KaneAI 就属于这一类别。另一种方法，则是像 Browser Use 这样，结合多模态基础模型与 Playwright，通过对网页结构的深入理解进行测试，而不是依赖于特定微调的模型。

在测试策略中引入 AI 驱动的 UI 测试时，需要考虑其价值所在。这些方法可以补充人工探索性测试。尽管 LLM 的非确定性特性可能会导致测试结果的不稳定性，但它的模糊匹配能力也可能成为优势，尤其适用于缺少选择器的遗留应用程序或经常变更标签和点击路径的应用。

优雅扩展性理论 定义了适应性系统（包括构建和操作软件的社会技术系统）的基本规则。这一理论中的一个关键概念是 能力边界（competence envelope） —— 系统在面对失败时能够 稳健 运作的边界。当系统被推到能力边界之外时，它会变得脆弱，更容易崩溃。该模型为理解系统故障提供了一个有价值的视角，例如在 2024 Canva 故障 中观察到的复杂故障。

残余性理论 是软件架构思维中最近的发展，它提供了一种方法，可以通过故意引入压力源并分析系统随时间对历史压力源的适应情况，来测试系统的能力边界。这些方法与社会技术系统中的反脆弱性、弹性和稳健性概念相一致。我们期待这些理论在实践中的应用，为提升系统的适应性与可靠性提供新的思路和工具。

从 LLMs 获取结构化输出 是指通过定义的结构模式来约束语言模型的响应。这可以通过指示通用模型以特定格式响应，或者通过微调模型使其“原生”输出例如 JSON 的结构化数据来实现。OpenAI 现在支持结构化输出，允许开发人员提供 JSON Schema、pydantic 或 Zod 对象来约束模型响应。这种能力在函数调用、API 交互和外部集成中尤其有价值，因为这些场景中格式的准确性和一致性至关重要。结构化输出不仅提升了 LLMs 与代码交互的方式，还支持更广泛的使用场景，例如生成用于呈现图表的标记语言。此外，结构化输出已被证明可以减少模型输出中的幻觉现象。

AI 正在降低非专业开发人员自行构建和集成软件的门槛，使他们无需等待 IT 部门响应自己的需求。尽管我们对这种技术带来的潜力感到兴奋，但同时也开始关注到 AI 加速影子 IT（AI-accelerated Shadow IT） 的初步迹象。一些无代码（No-code）工作流自动化平台已支持对 AI API（如 OpenAI 或 Anthropic）的集成，这使得用户可能倾向于将 AI 用作“胶带”，将此前难以实现的系统集成临时拼凑起来，例如通过 AI 将聊天消息转换为 ERP 系统的 API 调用。同时，越来越多具有自主 Agent 能力的 AI 编码助手，甚至允许仅经过基础培训的非技术人员创建内部工具应用。

这些迹象呈现出类似于电子表格（Spreadsheets）当年迅速扩散的特征：虽然为企业关键流程提供了快速解决方案，但在长期运行后往往会造成规模更大的技术债（Tech Debt）。如果不加管控，这种新型影子 IT 将导致未经治理的应用程序激增，安全隐患加剧，数据分散在不同系统内。我们建议企业对此风险保持警觉，并谨慎评估快速问题解决与长期技术稳定性之间的平衡与取舍。

随着 AI 编码助手的普及，越来越多的数据和研究也揭示了关于 自满于 AI 生成的代码 所带来的问题。GitClear 最新的代码质量研究显示，到 2024 年，重复代码和代码频繁变更的现象比预测的还要严重，而提交历史中的重构活动却在减少。同样反映出对 AI 的自满，微软的研究显示，AI 驱动的信心往往以牺牲批判性思维为代价——这种模式在长期使用编码助手时表现得尤为明显。随着监督式软件工程代理的兴起，这种风险进一步放大，因为当 AI 生成的变更集越来越大时，开发者在审查这些结果时面临的挑战也随之增加。而 vibe coding 的出现——即开发者在审查极少的情况下让 AI 生成代码——更是说明了人们对 AI 生成输出的信任正在增长。这种方法可能适用于原型或其他一次性代码，但我们强烈建议不要将其用于生产环境的代码。

由于对代码机密性的担忧，许多组织对第三方 AI 编码助手保持谨慎态度。因此，许多开发者开始考虑使用 本地编码助手 ，即完全在本地机器上运行的 AI 工具，无需将代码发送到外部服务器。然而，本地助手仍然落后于依赖更大型、更强大模型的云端助手。即使是在高端开发者设备上，较小的模型仍然存在能力上的局限性。我们发现它们难以处理复杂的提示词，缺乏解决更大问题所需的上下文窗口，并且通常无法触发工具集成或函数调用。这些能力对于当前编码辅助领域的前沿技术——代理式工作流——尤为重要。

因此，我们建议在使用本地助手时保持较低的期望值，但也有一些功能在本地环境中是可行的。目前一些流行的 IDE 已将较小的模型嵌入其核心功能中，例如 Xcode 的预测代码补全和 JetBrains 的整行代码补全。此外，可在本地运行的大语言模型，如 Qwen Coder，为本地的行内建议和处理简单编码查询迈出了重要一步。您还可以使用 Continue 测试这些功能，该工具支持通过 Ollama 等运行时集成本地模型。

当人们谈论编码助手的时候，关于 结对编程 的话题就会不可避免地被提及。我们所处的行业对于它爱恨交织: 有的同行信任它，有的同行讨厌它。现在大家都会对编码助手们提出同样的问题: 一个程序员可以选择与人工智能，而不是另外一个程序员，进行结对编程，从而达到同样的团队产出吗？Github Copilot 甚至自称为“你的 AI 结对程序员”。然而当大家都认为编程助手可以在结对编程方面带来好处时，我们还是不建议完全使用 AI 代替结对编程。把编码助手当做结对编程者忽略了结对编程的一个关键收益: 它可以让团队而不只是个人变得更好。在帮助解决难题，学习新技术，引导新人，或者提高技术任务的效率从而让团队更关注战略性设计等这些方面，使用编程助手确实大有裨益。但在诸如将正在进行的工作的数量控制在低水平，减少团队交接与重复学习，让持续集成成为可能，或者改善集体代码所有权等等这些团队合作相关的层面，它没有带来什么好处。

我们注意到，所谓的 逆向 ETL（Reverse ETL） 正在迅速扩散。常规 ETL 在传统数据架构中是很常见的，它将数据从事务处理系统传输到集中式分析系统（如数据仓库或数据湖）。尽管这种架构存在许多已被广泛记录的缺点，其中一些问题通过 数据网格 方法得到了缓解，但它在企业中仍然很常见。在这种架构中，将数据从集中分析系统逆向回流到事务处理系统，在某些特定场景下有其合理性，例如，集中系统可以汇总来自多个来源的数据，或者在向数据网格迁移的过程中，作为一种 过渡架构 的一部分。然而，我们观察到一个令人担忧的趋势，产品供应商正利用 Reverse ETL 的概念，将越来越多的业务逻辑转移到一个集中式的平台（即它们的产品）中。这种方法加剧了集中式数据架构所导致的许多问题。例如，过度依赖于将业务逻辑嵌入到一个庞大的中央数据平台中，会导致数据管理复杂性增加，并削弱领域团队对其数据的控制能力。因此，我们建议在从庞大的集中数据平台向事务处理系统引入数据流时，务必保持高度谨慎。

我们持续观察到 SAFe™ (Scaled Agile Framework®)（规模化敏捷框架）正被广泛采用。同时我们也注意到，SAFe 过度标准化和阶段性门限的流程会造成阻碍，这可能助长信息孤岛，其自上而下的管控模式会在价值流中产生浪费，并抑制工程人才的创造力，还会限制团队的自主性和实验空间。企业之所以采用 SAFe，一个关键原因是组织敏捷化过程非常复杂，他们希望像 SAFe 这样的框架能够提供一个基于流程的简单捷径，从而实现敏捷转型。鉴于 SAFe 的广泛应用——包括在我们的客户中——我们已经培训了 100 多名 Thoughtworks 咨询顾问，以便更好地为他们提供支持。尽管我们拥有深入的知识并且做了诸多尝试，但我们仍然认为，面对复杂问题，有时确实没有简单的解决方案。因此，我们一直建议采用与全面变革计划相结合的更加精简、价值驱动的方法和治理模式。

Scaled Agile Framework® 和 SAFe™ 是 Scaled Agile, Inc. 的商标。