技术
采纳
-
1. 数据产品思维
企业正在积极采用 数据产品思维 作为管理数据资产的标准实践。这一方法将数据视为具有自身生命周期、质量标准，并专注于满足消费者需求的“产品”。无论组织选择 数据网格 还是 Lakehouse 架构，我们现在将其推荐为数据管理的默认建议。
我们强调数据产品思维中的以消费者为中心的原则，以推动更大的采用率和价值实现。这意味着通过 设计数据产品，从用例出发反向工作。同时，我们专注于使用现代数据目录（如 DataHub、Collibra、Atlan 和 Informatica）捕获和管理业务相关元数据与技术元数据。这些实践提升了数据的可发现性和可用性。此外，我们将数据产品思维应用于扩展 AI 项目，创建 AI 就绪数据。这一方法涵盖了全面的生命周期管理，确保数据不仅得到良好治理并具备高质量，同时在不再需要时能够符合法律和监管要求进行退役。
-
2. Fuzz测试
Fuzz 测试 ，或称模糊测试，是一种已经存在很长时间但仍然较少被广泛了解的测试技术。其目标是向软件系统输入各种无效数据并观察其行为。例如，对于一个 HTTP 端点，错误的请求通常应返回 4xx_ 错误，但 fuzz 测试往往会引发 5xx_ 错误甚至更严重的问题。随着工具的完善以及文档支持的增强，fuzz 测试在如今显得尤为重要，尤其是在更多 AI 生成代码和自满于 AI 生成的代码的背景下。因此，现在是采用 fuzz 测试的好时机，以确保代码的健壮性和安全性。
-
3. 软件物料清单（SBOM）
自我们在 2021 年首次提到 软件物料清单（SBOM） 以来，其生成已经从新兴实践转变为我们项目中的默认选项。SBOM 生态系统显著成熟，提供了强大的工具支持，并实现了与 CI/CD 系统的无缝集成。工具如 Syft、Trivy 和 Snyk 能够从源代码到容器镜像生成全面的 SBOM，同时支持漏洞扫描。FOSSA 和 Chainloop 等平台通过与开发工作流集成以及实施安全策略，进一步提升了安全风险管理能力。尽管统一的 SBOM 标准仍在演化，但对 SPDX 和 CycloneDX 的广泛支持已显著降低了采用门槛。同时，AI 系统也需要 SBOM 的支持。英国政府的 AI 网络安全行为准则 和 CISA 的 AI 网络安全协作手册 就证明了这一点。我们将继续关注该领域的发展动态。
-
4. 威胁建模
在快速发展的 AI 驱动软件开发领域，威胁建模 比以往任何时候都更为关键，它不仅能够帮助构建安全的软件，同时还能保持敏捷性并避免出现 “安全三明治” 的情况。威胁建模是一组用于识别和分类潜在威胁的技术，可广泛应用于各种场景，包括生成式 AI 应用 ，这些应用 带来了独特的安全风险 。要想取得成效，威胁建模必须贯穿软件生命周期的各个阶段并定期执行，同时与其他安全实践相结合才能发挥最佳效果。这些实践包括定义跨职能的安全需求，以应对项目技术中的常见风险，以及利用自动化安全扫描工具进行持续监控，从而保障系统安全。
评估
-
13. AI友好的代码设计
监督式软件工程代理的能力正在不断提升，它们现在能够识别所需的更新，并对代码库进行更大范围的修改。然而，我们也注意到，开发者对 AI 生成代码的自满情绪 正在增加，很多人不愿意审查由 AI 创建的大型变更集。一个常见的理由是：既然未来的修改可以交给 AI 来完成，那么面向人类的代码质量就没那么重要了。然而，事实恰恰相反——AI 编程助手在结构良好的代码库上表现得更好，因此 AI 友好的代码设计 对于代码的可维护性至关重要。
值得庆幸的是，面向人类的优秀软件设计同样能够为 AI 提供助力。比如，明确的命名可以为代码提供领域上下文和功能信息；模块化和抽象设计能够限制代码改动范围，使 AI 的工作上下文更易于处理；而 DRY（don’t repeat yourself）原则则能减少重复代码，让 AI 更容易确保行为一致性。到目前为止，最适合 AI 的设计模式依然与传统的软件设计最佳实践密切相关。随着 AI 的不断发展，我们预计会有更多专门针对 AI 的设计模式出现。因此，从现在开始以 AI 友好的视角来思考代码设计，将会对未来大有裨益。
-
14. AI驱动的UI测试
AI 在软件团队中的应用正逐步超越单纯的代码生成，新的技术正在涌现。其中， AI 驱动的 UI 测试 正受到越来越多的关注，它利用 LLM 的能力来理解图形用户界面（GUI）。目前，该领域主要有几种不同的实现方式。一种方法是使用针对 UI 快照处理进行微调的多模态 LLM，这类工具允许测试脚本以自然语言编写，并能自主导航应用程序。例如，QA.tech 和 LambdaTest 的 KaneAI 就属于这一类别。另一种方法，则是像 Browser Use 这样，结合多模态基础模型与 Playwright，通过对网页结构的深入理解进行测试，而不是依赖于特定微调的模型。
在测试策略中引入 AI 驱动的 UI 测试时，需要考虑其价值所在。这些方法可以补充人工探索性测试。尽管 LLM 的非确定性特性可能会导致测试结果的不稳定性，但它的模糊匹配能力也可能成为优势，尤其适用于缺少选择器的遗留应用程序或经常变更标签和点击路径的应用。
-
15. 能力边界作为理解系统故障的模型
优雅扩展性理论 定义了适应性系统（包括构建和操作软件的社会技术系统）的基本规则。这一理论中的一个关键概念是 能力边界（competence envelope） —— 系统在面对失败时能够 稳健 运作的边界。当系统被推到能力边界之外时，它会变得脆弱，更容易崩溃。该模型为理解系统故障提供了一个有价值的视角，例如在 2024 Canva 故障 中观察到的复杂故障。
残余性理论 是软件架构思维中最近的发展，它提供了一种方法，可以通过故意引入压力源并分析系统随时间对历史压力源的适应情况，来测试系统的能力边界。这些方法与社会技术系统中的反脆弱性、弹性和稳健性概念相一致。我们期待这些理论在实践中的应用，为提升系统的适应性与可靠性提供新的思路和工具。
-
16. 从LLMs获取结构化输出
从 LLMs 获取结构化输出 是指通过定义的结构模式来约束语言模型的响应。这可以通过指示通用模型以特定格式响应，或者通过微调模型使其“原生”输出例如 JSON 的结构化数据来实现。OpenAI 现在支持结构化输出，允许开发人员提供 JSON Schema、pydantic 或 Zod 对象来约束模型响应。这种能力在函数调用、API 交互和外部集成中尤其有价值，因为这些场景中格式的准确性和一致性至关重要。结构化输出不仅提升了 LLMs 与代码交互的方式，还支持更广泛的使用场景，例如生成用于呈现图表的标记语言。此外，结构化输出已被证明可以减少模型输出中的幻觉现象。
暂缓
-
17. AI 加速影子 IT（AI-accelerated Shadow IT）
AI 正在降低非专业开发人员自行构建和集成软件的门槛，使他们无需等待 IT 部门响应自己的需求。尽管我们对这种技术带来的潜力感到兴奋，但同时也开始关注到 AI 加速影子 IT（AI-accelerated Shadow IT） 的初步迹象。一些无代码（No-code）工作流自动化平台已支持对 AI API（如 OpenAI 或 Anthropic）的集成，这使得用户可能倾向于将 AI 用作“胶带”，将此前难以实现的系统集成临时拼凑起来，例如通过 AI 将聊天消息转换为 ERP 系统的 API 调用。同时，越来越多具有自主 Agent 能力的 AI 编码助手，甚至允许仅经过基础培训的非技术人员创建内部工具应用。
这些迹象呈现出类似于电子表格（Spreadsheets）当年迅速扩散的特征：虽然为企业关键流程提供了快速解决方案，但在长期运行后往往会造成规模更大的技术债（Tech Debt）。如果不加管控，这种新型影子 IT 将导致未经治理的应用程序激增，安全隐患加剧，数据分散在不同系统内。我们建议企业对此风险保持警觉，并谨慎评估快速问题解决与长期技术稳定性之间的平衡与取舍。
-
18. 自满于 AI 生成的代码
随着 AI 编码助手的普及，越来越多的数据和研究也揭示了关于 自满于 AI 生成的代码 所带来的问题。GitClear 最新的代码质量研究显示，到 2024 年，重复代码和代码频繁变更的现象比预测的还要严重，而提交历史中的重构活动却在减少。同样反映出对 AI 的自满，微软的研究显示，AI 驱动的信心往往以牺牲批判性思维为代价——这种模式在长期使用编码助手时表现得尤为明显。随着监督式软件工程代理的兴起，这种风险进一步放大，因为当 AI 生成的变更集越来越大时，开发者在审查这些结果时面临的挑战也随之增加。而 vibe coding 的出现——即开发者在审查极少的情况下让 AI 生成代码——更是说明了人们对 AI 生成输出的信任正在增长。这种方法可能适用于原型或其他一次性代码，但我们强烈建议不要将其用于生产环境的代码。
-
19. 本地编码助手
由于对代码机密性的担忧，许多组织对第三方 AI 编码助手保持谨慎态度。因此，许多开发者开始考虑使用 本地编码助手 ，即完全在本地机器上运行的 AI 工具，无需将代码发送到外部服务器。然而，本地助手仍然落后于依赖更大型、更强大模型的云端助手。即使是在高端开发者设备上，较小的模型仍然存在能力上的局限性。我们发现它们难以处理复杂的提示词，缺乏解决更大问题所需的上下文窗口，并且通常无法触发工具集成或函数调用。这些能力对于当前编码辅助领域的前沿技术——代理式工作流——尤为重要。
因此，我们建议在使用本地助手时保持较低的期望值，但也有一些功能在本地环境中是可行的。目前一些流行的 IDE 已将较小的模型嵌入其核心功能中，例如 Xcode 的预测代码补全和 JetBrains 的整行代码补全。此外，可在本地运行的大语言模型，如 Qwen Coder，为本地的行内建议和处理简单编码查询迈出了重要一步。您还可以使用 Continue 测试这些功能，该工具支持通过 Ollama 等运行时集成本地模型。
-
20. 使用AI代替结对编程
当人们谈论编码助手的时候，关于 结对编程 的话题就会不可避免地被提及。我们所处的行业对于它爱恨交织: 有的同行信任它，有的同行讨厌它。现在大家都会对编码助手们提出同样的问题: 一个程序员可以选择与人工智能，而不是另外一个程序员，进行结对编程，从而达到同样的团队产出吗？Github Copilot 甚至自称为“你的 AI 结对程序员”。然而当大家都认为编程助手可以在结对编程方面带来好处时，我们还是不建议完全使用 AI 代替结对编程。把编码助手当做结对编程者忽略了结对编程的一个关键收益: 它可以让团队而不只是个人变得更好。在帮助解决难题，学习新技术，引导新人，或者提高技术任务的效率从而让团队更关注战略性设计等这些方面，使用编程助手确实大有裨益。但在诸如将正在进行的工作的数量控制在低水平，减少团队交接与重复学习，让持续集成成为可能，或者改善集体代码所有权等等这些团队合作相关的层面，它没有带来什么好处。
-
21. 逆向ETL（Reverse ETL）
我们注意到，所谓的 逆向 ETL（Reverse ETL） 正在迅速扩散。常规 ETL 在传统数据架构中是很常见的，它将数据从事务处理系统传输到集中式分析系统（如数据仓库或数据湖）。尽管这种架构存在许多已被广泛记录的缺点，其中一些问题通过 数据网格 方法得到了缓解，但它在企业中仍然很常见。在这种架构中，将数据从集中分析系统逆向回流到事务处理系统，在某些特定场景下有其合理性，例如，集中系统可以汇总来自多个来源的数据，或者在向数据网格迁移的过程中，作为一种 过渡架构 的一部分。然而，我们观察到一个令人担忧的趋势，产品供应商正利用 Reverse ETL 的概念，将越来越多的业务逻辑转移到一个集中式的平台（即它们的产品）中。这种方法加剧了集中式数据架构所导致的许多问题。例如，过度依赖于将业务逻辑嵌入到一个庞大的中央数据平台中，会导致数据管理复杂性增加，并削弱领域团队对其数据的控制能力。因此，我们建议在从庞大的集中数据平台向事务处理系统引入数据流时，务必保持高度谨慎。
-
22. SAFe™
我们持续观察到 SAFe™ (Scaled Agile Framework®)（规模化敏捷框架）正被广泛采用。同时我们也注意到，SAFe 过度标准化和阶段性门限的流程会造成阻碍，这可能助长信息孤岛，其自上而下的管控模式会在价值流中产生浪费，并抑制工程人才的创造力，还会限制团队的自主性和实验空间。企业之所以采用 SAFe，一个关键原因是组织敏捷化过程非常复杂，他们希望像 SAFe 这样的框架能够提供一个基于流程的简单捷径，从而实现敏捷转型。鉴于 SAFe 的广泛应用——包括在我们的客户中——我们已经培训了 100 多名 Thoughtworks 咨询顾问，以便更好地为他们提供支持。尽管我们拥有深入的知识并且做了诸多尝试，但我们仍然认为，面对复杂问题，有时确实没有简单的解决方案。因此，我们一直建议采用与全面变革计划相结合的更加精简、价值驱动的方法和治理模式。
Scaled Agile Framework® 和 SAFe™ 是 Scaled Agile, Inc. 的商标。
无法找到需要的信息？
每期技术雷达中的条目都在试图反映我们在过去六个月中的技术洞见，或许你所搜索的内容已经在前几期中出现过。由于我们有太多想要谈论的内容，有时候不得不剔除一些长期没有发生变化的条目。技术雷达来自于我们的主观经验，而非全面的市场分析，所以你可能会找不到自己最在意的技术条目。
