两周前受彭鑫老师邀请，在《智能化软件开发微访谈·第三十四期 基于大模型的软件智能化开发实践》分享了我们在 Thoughtworks 以及在客户侧的一些实践和探索。 在其中分享了我的一些心得和感受，在这里重新整理一下，并加上一些新的思考和想法。

在不考虑模型和算力，要在企业落地还是有比较大门槛：

第一，AI 提升效能效果有限。AI 工具并没有企业想象中好用，存在大量的学习成本 ，很多开发容易放弃； 第二，普遍缺少 AI 软件工程专家。。软件智能化开发依赖于 AI 融合到研发流程中，大量企业缺少 AI 人才去改善内部流程、规范和提炼知识； 第三，端到端难度还是比较大，研发的智能化依赖于需求侧。过去，DevOps 推不动，所以有了在 BizDevOps，希望更多的 Involve 业务人员参加。在 AI 时代，依旧存在同样的问题。

最重要的还是有人持续在内部探索。

1：现阶段 AI 工具不完善，对端到端提升比较有限

我们公司在在全球有 19 个国家，48个办公室，涉及到大量不同的部门和团队。在其它国家，我们看到国外对于 AI 遗留系统改造和迁移的需求，是远大于辅助开发。在国内的交付部门里，我们的尝试主要覆盖了需求、开发和测试、运维都有所覆盖 ，另外一个是结合 Thoughtworks 内部的技术实践和知识库的工具，如 AskThoughtworks 或者辅助研发团队 AI 助手 Haiven，融合软件开发的内部知识库，加速 SDLC 。

• AI 辅助需求：公开可访问的有 Boba AI，协助产品经理和业务分析师更好地理解需求并生成相关文档，支持前期需求分析的自动化；还有
• AI 辅助开发：工具就比较丰富多彩了，除了可以使用 Cursor 和 GitHub Copilot 等工具，还有我们开源的 AutoDev IDE 插件（https://github.com/unit-mesh/auto-dev)，也帮助了不少企业在内部落地 AI 辅助开发。
• AI 辅助测试：我们比较推荐开发编写测试和 TDD （测试驱动开发）的方式，所以在 AutoDev 结合静态代码分析，做了一键精准单元测试生成、
• API 测试数据生成等功能。 AI 辅助运维：我没啥兴趣，观察比较少，传统的 AI运维已经做得很好了，但是也看到了自身内部在实现 AI 辅助 Thoughtworks 的工单分类和管理。

从我们之前的统计和分析效果来看，我们在不同的开发环节中实现了 2% 到 13% 的交付效率提升，尤其是在项目初期体现得更为显著。不过，对于大部分已有项目的提升会在 5% 以下，寻找变更点才是老系统的痛点。

2：治理 AI 代码以及代码质量是下一步的重点

只从 AI 辅助编程来看，内容的数据，以及和一些团队聊过这个问题，结合个人的使用体验，我现在的结论是：

1. 开发环节效率提升不一。受限于编程语言、研发流程和团队规范；
2. 代码质量是下降的。

效率上的话主要有两点：

1. AI 工具，现有的 AI辅助研发方式对于增量代码提升比较有限，还是大量依赖于人来做分析，有一些环节缺乏工具配套，比如不熟悉代码库、缺少领域知识不会提问。
2. 2.流程角度，开发环节只是 SDLC 的一环节，如果我本身 DevOps 不成熟或者需求太少，缺少知识，这种提升就无从下手。

代码质量主要受：

1. 团队平均水平的代码质量。也就是，别人写的代码的影响 —— AI 会参考当前代码文件和相关代码。别人喜欢用 if-else，你喜欢用 when 或者 switch，给你生成的就是 if-else。
2. 未经人工详细 review 的代码。我自身的体验是这样的，我之前还和几个 Tech Lead（技术负责人）聊过这个问题：“你们在 code review 有没有发现，未经人工 review 的 AI 代码”，他们的回答是：有，偶尔。可以反推，如果经典的 Sonarlint、Code Review 质量环节缺少了，那么质量就下滑更严重。

如何治理 AI 代码会成为未来的一个重要问题。结合代码质量工具，如 Sonarlint、Code Review 等是一个不错的方案，结合 ArchGuard 之类的架构治理平台，也是一个不错的方案。

3：高效校验 AI 内容是工程化落地的最大挑战

工程是 1，AI 是 0，没有工程化，AI 发挥不了价值。在经历了大量的调研和探索之后，从生成式 AI 能力上来说，我们更需要是传统 AI 和工程能力 —— 生成测试用例之前，生成准确的测试数据。

生成式 AI 一次生成大量代码，几十行、几百行，我们就需要有效的方式来校验这些代码。我们在实践中会发现，AI 生成的代码，很难通过单元测试来校验。在 生成一些架构知识，也会出现一些明显错误。除此，由于人提供的时候，问题本身也是有些便向性，AI 生成的答案也是有 些偏向性。

最近，我们探索的方向是结合流程 Shire 编程场景智能体语言，可以自由和不同内部工具、IDE 插件做集成。 除此，我们最近一直在研究的点是， 如何挖掘流程中的隐性知识？比如，你编写测试用例，要挖掘出用例的策略，什么情况下关注什么？需要如何准备测试数据？ 然后才是，如何通过 AI 技术简化这些知识提炼的成本。在需求和开发等领域也是类似的作用，先从流程模拟人如何思考，再去结合 AI 技术。

4：新人会面临更多的生成式 AI 挑战

当前，阶段普通开发人员面临一个非常大的挑战：如何判断 AI 生成代码、设计是否正确？

上个月，有个毕业生拿 ChatGPT 回答的领域驱动设计（DDD）问题来找我，说这个 AI 和他们 TL 回答的结果不一样。他们这种相当于是，一个意图， 但是问法相近，结果却不一样了。对于资深开发人员来说，我就是对的，GPT 只需要按我的结果执行就行了。

结论会变成，如何获取可信的“软件工程知识”吗？要知道，其实传统的软件工程知识也是并不可信的 —— 同样的领域驱动设计的解释，在不同作者眼里是不一样的。所以，最后架构设计还是会变成 by experience。

相似的，对于新人来说，需要寻找快速校验的方式，来检验 AI 内容正确性。比如架构设计，可以快速生成 API、代码校验；生成业务代码时，可以快速生成个测试试试等等。 更简单的方式，可能是直接问 TL 或者更有经验的同事。

5：生成式 AI 或更适合改善流程规范化

当前阶段，我比较看好的企业智能化场景是：借助生成式 AI 把 DevOps 流程标准化、规范化，做好研发数字化。比较理想的情况是，刚好抵消标准化的成本。 从结果来看，企业可以：

1. 小范围构建原型并去小范围试点，以培养 AI 人才。
2. 建立基本的规范，规范化开发流程
3. 有意识的改进现有的知识管理方式

因此，对于流程繁琐的企业，AI 生成式工具是一个不错的机会。既然涉及到流程重塑，这就不会是一件简单的事。

6：领域知识的汲取是落地团队级 AI 的关键

随着，越来越多团队的进一步深入构建团队级 AI 助手，会发现构建 Team AI 的门槛并非在构建 AI 平台本身，而是在于如何将领域、知识等提炼出来， 以用于强化自身的流程。从模式和解决方案来说，围绕 DDD（领域驱动设计）思想的 AI 辅助工具，是一个不错的方向：

• 构建业务与技术的统一语言，实现需求、设计、开发、测试、运维等环节的无缝衔接；
• 提取团队成员的思考模式，转换为 AI 工具的流程与提示词，无缝融入团队的日常工作；

当然了，其它的还有诸如从数据打通团队内部的知识壁垒，实现关键数据的共享。

总结

生成式 AI 并非银弹，要与现有的体系结合，并非一蹴而就。