聊聊AI与软件工程的那些事

一、AI时代的软件工程-开篇

（春青）

徐昊老师作品。这个课题和老师一起学习AI时代的软件工程随着2022年底大语言模型（Large Language Model）进入技术爆炸期，LLM也对软件研发产生了巨大的冲击。无论是使用ChatGPT直接从头生成应用，还是在Github Copilot辅助下载已有代码中编码，每一次与LLM有关的新闻都在刺激着从业者人士的神经，好像过不了几天，工作就会被AI取代。进入chatGPT：在浏览器中输入，人工智能聊天.site 就可以了

通过ChatGPT编写生成代码让我们看一个例子，如果我们想做一个产品目录服务，通过API的调用返回产品信息。输入如下信息：1 目前我们在编写一个产品目录服务，通过API提供所有可售商品的详细信息，使用java编写2 请提供代码和对应的功能测试chatGPT给的答复如下为了提供一个简单的Java产品目录服务，我们可以使用Spring Boot框架来快速搭建一个REST API。以下是一个基本的示例代码，以及如何进行功能测试。

1. 创建Spring Boot项目

首先，你需要创建一个Spring Boot项目。你可以使用Spring Initializr来生成项目结构。选择以下依赖项：- Spring Web- Spring Data JPA- H2 Database

2. 编写产品实体和服务

创建一个Product实体类：

@Entitypublic class Product { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String name; private double price; private String description; // Getters and Setters // ...}```创建一个`ProductRepository`接口：```javaimport org.springframework.data.jpa.repository.JpaRepository;public interface ProductRepository extends JpaRepository {}```创建一个`ProductService`类：```javaimport org.springframework.stereotype.Service;import java.util.List;@Servicepublic class ProductService { private final ProductRepository productRepository; public ProductService(ProductRepository productRepository) { this.productRepository = productRepository; } public List getAllProducts() { return productRepository.findAll(); } // Other CRUD operations // ...}```### 3. 创建REST Controller创建一个`ProductController`类：```javaimport org.springframework.web.bind.annotation.GetMapping;import org.springframework.web.bind.annotation.RequestMapping;import org.springframework.web.bind.annotation.RestController;import java.util.List;@RestController@RequestMapping(”/api/products”)public class ProductController { private final ProductService productService; public ProductController(ProductService productService) { this.productService = productService; } @GetMapping public List getAllProducts() { return productService.getAllProducts(); } // Other CRUD operations // ...}```### 4. 编写功能测试使用Spring Boot Test来编写功能测试：```javaimport org.junit.jupiter.api.Test;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;import org.springframework.boot.test.context.SpringBootTest;import org.springframework.test.web.servlet.MockMvc;import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;@SpringBootTest@AutoConfigureMockMvcpublic class ProductControllerTest { @Autowired private MockMvc mockMvc; @Test public void testGetAllProducts() throws Exception { mockMvc.perform(get(”/api/products”)) .andExpect(status().isOk()); }}```### 5. 运行测试运行上述测试类，确保所有的测试用例都能通过。请注意，这个示例是一个非常基础的实现，实际的产品目录服务可能需要更复杂的业务逻辑，例如分页、过滤、排序等。此外，为了确保数据的完整性和安全性，你可能还需要实现身份验证和授权机制。比起可以使用的生产代码，这更像一份在给定上下文下的Spring Boot教程。离生产代码还有很大的差距。我们需要在现在的结果上给予ChatGPT反馈，让ChatGPT做出调整。为了让ChatGPT给出的结果更贴近生产代码，我们需要在提示词或者对话中提供丰富的上下文信息。1 目前我们在编写一个产品目录服务，通过API提供所有可售商品的详细信息（业务上下文）2 此API包含列出所有商品，按SKU查看某个商品，按照分类列出商品以及关键词搜索功能（业务功能描述）3 API返回的结果是json格式：（技术规范描述）4 当查找的SKU不存在时，返回404（技术规范描述）5 按照关键词搜索使用POST不是GET（最佳实践）6 使用java编写（技术栈）7 为所有功能提供功能测试，包含异常情况（代码范围）8 请编写功能和测试代码（最终j交付物要求）9在于ChatGPT一起完成代码功能时，我们需要它通过上下文信息补充。知道ChatGPT生成更接近我们所需的代码。这个过程中，具体的程序编写是有ChatGPT来完成，而要做什么，怎么做则有人来指定的。从软件工程到知识工程这可能是ChatGPT出现带来恐慌的根源，在大多数程序员的心中，都认为搞技术的，是写代码。现在ChatGPT把代码都写了，那岂不是我们就可有可无了？是不是未来都要被AI取代了？这恐怕是对软件工程最大的误解了。软件工程不仅仅是写代码。写代码在软件开发中只占很小的比例，甚至不是最困难的最复杂的。实际上，软件工程还涉及问题解决、需求分析、系统设计、测试和维护等方面。有效编写代码的前提是，所需要的知识已经有效地获取了。知识先存在于大脑中，然后才体现在软件中。如果所有的知识都已经被掌握，那么编码也不会太费力气。否则，开发过程就会迅速的转化为如何寻找并掌握真正的知识。对于大多数软件开发人员来说，通过会议反复确认需求、构思正确的解决方案、查找文档、到Stackoverflow之类社区寻求问题解答、通过调试理解存在于代码中的逻辑构成了开发工作的主要内容。与之相比，真正编码的时间反而不会太多。而对于高水平的程序员，在敲下代码之前，80%的代码都已经在头脑中构思好了。所以，写代码从来不是软件开发的核心部分。但编码的确是一种琐碎且繁杂的活动，它甚至掩盖了我们工作中最有价值的部分：获取、学习并传递知识。LLM正在改变软件开发的面貌，它可以自动化一些编码工作，将使软件工程师能够更多地专注于复杂问题的解决和创新，专注于更有价值的部分。也就是知识的获取与传递。我们的主要工作，从编码转变为LLM提供足够多的上下文信息。为其提供功能需求、业务知识、架构决策、测试策略等关乎“生产代码”的重要信息。我们的关注点从如何构造软件，变成了如何提取组织知识，让知识变成LLM能够理解的形式。因此，提示词工程的关键并不是提示词，而是在如何组织其中的知识。因而知识工程是一个更合适的名字。随着LLM的兴起，我们也应该使用知识工程改造软件工程，即提取知识、组织知识为LLM更易于理解的形式，再通过LLM将这些知识转换为可以工作的软件。课程设计对个人而言：从自己编码变成LLM编码。ChatGPT看做是一个编码助手，怎样提升这个助理的能力，是提升效率的关键。我们的角色从运动员变为教练员。对于编码技能的要求降低了提高了对知识总结、知识传递、任务分解等技能的要求。LLM让90%的技能无用了，让10%的技能放大1000倍。对于团队而言，大量的知识可以通过LLM得到有效的沉淀。关键岗位人才流失造成大量上下文损失在团队中难以形成同一共识新人培养时间太长，难以上手等。直接套用LLM并不能有效地实现这一点，需要我们有能力将现在研发流程重新梳理为知识管理的过程，从中捕获关键知识，并通过LLM加以沉淀。这门课，站在知识工程的角度，阐述如何从知识管理的角度理解软件开发。在软件开发的不同阶段，提取核心知识和关键载体，将他们表示成易于LLM理解的形式。其中编码阶段的知识提取和传递，将是个人与LLM合作的核心技能。首先，介绍知识 工程的整体框架。从识别软件中不同知识种类开始，讨论这些知识在传递过程中带来的认知行为的改变，以及不同的认知行为适合那种LLM交互模式其次，讲解在不同的软件开发生命周期中，需要传递的关键知识，以及如何将它们组织成LLM可以理解的形式。首先是需求分解与传递的过程，这是整个开发流程中最关键的一部分知识，LLM可以发挥非常重要的作用。然后，将目光聚焦在技术和实现方式的知识，并通过这些知识构造有效的现场管理框架。最后，构建AI辅助团队。毕竟，任何改变，只有彻底改变了团队中的人，才能是真正的落地。希望通过这门课的学习，能帮忙你更好的利用LLM提高效率，还可以站在更全面的立场上，讨论如何将LLM引入团队或者组织。

二、AI掌控编码人类狂按Tab，软件工程自主时代来临！OpenAI董事长Taylor重磅长文

（新智元 新智元）

随着自动驾驶技术的成熟，未来几十年，汽车将会发生多么戏剧性的变化。

三、软件工程3.0时代，AI落地研效成熟时

（原创 小逸 思码逸研发效能）

1

回看2024

去年，随着大模型的兴起，我们进入了软件工程 3.0 的时代。我在去年开始就投入了大量实验田，比如输入需求可直接生成代码，输入代码可直接生成单元测试，根据需求产生测试用例，这些基于一些普适知识就能够实现的内容，在过去个体力量需要通过充分培训学习才可以掌握的能力，在当下可以通过大模型加速实现（虽然仍然会很大程度依赖于知识库的应用）。在那一刻开始，我意识到普适性知识的重要性可能正在逐步下降，而创意和想法变得更为关键，基于普适知识所产生的一切衍生品都会因此加速产生。

我们将这种变化比作“外骨骼”的出现，它增强了工程师的能力。

总的来说，过去一年的发展让我意识到，如果我们能发展出足够强大的“外骨骼”，那么许多我们曾经认为重要的东西可能不再那么关键。这就是我想分享的主要内容。

王欢：今天，我想从一个细微角度分享我在效能提升方面的重要收获。自 2019 年起，我们公司便开始探索效能度量，当时这一领域鲜有公司涉足。我们的工作经历了几个阶段，从攻克“取数难”，到突破“度量难”，如今正面临“改进难”的挑战。

我们深知，若仅将度量作为考核工具，研发团队可能会为了迎合指标而开展无意义的工作，这显然不是我们所追求的可持续度量模式。

我们真正追求的是，在度量发现问题后，如何指导项目组进行持续改进，从而真正实现提质增效。因此，效能改进成为了我们的核心工作。然而，通过改进切实提升效能并非易事。例如，效能低的团队本就处于高压状态，再提出改进要求容易引发他们的抵触情绪；而效能尚可的团队，问题相对较小，可能会觉得我们在无事生非。好不容易说服他们进行改进，后续的跟踪、复盘、指导却耗费大量精力，这无疑让本就人员稀缺的效能组雪上加霜。

后来，我们借助 CMMI 贯标契机与 EPG（过程改进小组）展开合作。EPG 本身作为持续改进小组，协助督办效能持续改进，发挥了巨大作用。需要特别强调的是，EPG 的特殊之处在于，其成员涵盖一线骨干专家，如测试、开发、质控、规划等，也有领导组成员，这既能保证效能决策的专业性，又能确保执行落地的及时性，还能促进执行小组与领导小组的有效链接。而且，EPG 小组也需要改进任务作为他们的 KPI，可谓是天作之合。公司多项效能持续改进的落地，均体现了联合带来的巨大作用，实现了合作双赢。

因此，我的建议是，效能管理工作不要单打独斗，要积极寻找合作伙伴。若公司没有类似组织，可建议领导层予以建设，或者找个契机联合起来。共同解决效能管理的“最后一公里”。以上是我的分享，感谢大家。

任晶磊： 我也想呼应一下王欢老师，并结合最近的几个案例做一些分享。首先，确实有些公司也成立了效能委员会，由不同业务线和流程管理方面的代表组成。这个委员会通常涉及多个业务线，每个业务线都会指定相应的角色，比如决策者和数据分析专家。如果缺乏相关能力，公司还会提供培训。这样的建制化做法效果显著，形成了一个高效协作的组织。

在效能提升的最后一公里，责任不应仅由效能度量部门承担。一线管理者的参与对于理解流程问题和实际情况至关重要，这样才能确保责任分配的合理性和效率。

另外，有些时候数据的价值在于揭示问题的紧迫性，而非仅仅提出改进建议。如果开发负载过重无法改进，出现负向循环，就需要外部力量介入以恢复正向循环。这时，资源分配成为关键，可能需要更高层的技术领导者做出判断。度量的目的之一是让有决策权的人意识到问题的严重性，从而提供必要的资源支持。例如，一个客户在考虑系统是否要进行一次大规模重构。通过数据分析揭示出需要立即关注的问题，我们可以促使领导者意识到必须投入时间和精力进行重构。这个案例中，系统已经七八年没有大规模重构，可以说已经非常坚挺了。但质量数据和分析会帮助领导者认识到，即使是最优秀的系统，这么长时间也需要做一些底层优化。

总之，通过度量和数据分析，我们可以揭示问题，促使领导者采取行动，从而推动组织进入正向循环。这种方法在比较煎熬的时候尤其有效，能够帮助团队从压力中解脱出来，走向更加健康和可持续的发展道路。

张乐： 感谢各位老师的分享。研发效能的提升、效能度量、效能改进闭环及组织协同，无疑是一项复杂的工程。如何综合运用各种实践、方法和经验来解决实际问题，实现提质增效，确实是一个体系化的事情。

2024 年，我们见证了 AI 编码赛道的热度和潜力，我个人的很多精力也放在打造公司内部 AI 编码助手产品上。我认为，从想法到落地再到取得效果，这类产品的成功落地需要三个层次的支撑：模型层、工程层和产品层。

• 模型层：更强大的模型可以处理更复杂的编程问题。比如当下很火的 Cursor/Windsurf，它们在底层都使用了 Claude 3.5 Sonnet 模型，正是模型能力的持续增强，才能更好实现从自然语言生成复杂代码的效果；

• 工程层：对私域知识及本地工程的理解等。比如为了支持基于整个工程、整个仓库的理解进行代码解释或代码生成，就需要 codebase 能力的支持（结合语义检索、关键字检索、代码符号检索等）；为了支持 AI 修改代码时，能快速应用（Fast Apply）到原有代码中并以 Diff 方式展现出来，也需要在工程侧做非常多的工作（如除了让模型生成修改的代码外，还要在很短的时间内，找到原始代码中正确的位置，并插入正确的代码）；

• 产品层：我们无论从哪里切入，都要抓住用户的痛点、解决实际问题。比如原来是一行一行补全，现在可以在多个地方、多点编辑，并且能预测用户下个行为；原来是是 Copilot 模式，通过 Chat 进行聊天，现在是通过 Agent 能力直接帮用户写、帮用户改代码。这些体验提升了“打工人”的愉悦感，情绪价值拉满，而实际效率也提升了。这些都需要在产品层面，基于对用户操作流程、习惯、行为的深刻洞察，形成有想法、有创新的产品。

2

大模型在研发效能度量中的应用

任晶磊

更推荐通过综合各个场景下的成本来计算AI可能节省的成本，作为AI提效的综合数字，而不是计算时间。

AI可以帮助我们逾越知识的瓶颈，从而实现能效的突破。度量只是第一步，真正目的是通过度量提升工作效率。

徐陈飞

王欢

我们结合大模型和机器学习算法，更有效地告知团队成员代码提交的质量标准，半年间代码不重复度提升近10%。

在度量过程中，我们需要谨慎使用单一指标，尤其是那些容易被操纵的指标。

张乐

张乐： 接下来，让我们进入第二个议题，探讨大模型在研发效能度量中的应用。我们将讨论如何利用大模型进行度量，使用哪些指标，以及最终的效果如何。

任晶磊： 首先，度量与具体应用 AI 的场景密切相关。例如，代码补全是目前最好且最实际落地的场景。但在这个场景中，有一个很现实的问题，就是当代码最终脱离编辑窗口，甚至被提交到代码库中时，就无法区分哪些代码是人写的，哪些是机器生成的。因此，对于这样的场景，度量只能在生成时进行。

区分一般文本是否由人或机器生成的问题，实际上比区分代码要难。因为人的语言空间非常大，可以体现不同人的习惯和模式。而代码的关键词相对有限，产生的组合也相对有限，所以不容易区分。OpenAI 曾提供服务，但因为准确度太低，发布六个月后就下线了。目前学术界也在研究这个问题，但目前主要从编程风格上的差异出发。

在生成时度量，我们可以观测一些直接指标。例如，接收率或采纳率，即在机器给出备选项后，编码人接受推荐的概率。这更多是从工具角度出发的度量。此外，我们还可以看生成的占比，即最终生成的代码占整个代码库的比例。

对于事后度量，代码生成后虽然无法再区分哪些由 AI 生成，但是我们可以通过其他一些直接或者间接的指标来度量 AI 产生的效果。例如，在编写测试用例的场景，可以通过单元测试覆盖率、接口测试覆盖率等指标的变化来直接度量 AI 带来的产出。此外，还可以通过用户反馈、满意度等间接指标来衡量。

除了跟传统度量一样可以看交付效率、交付质量、交付能力，我们还建议关注交付成本的角度。比如实际当中，我们可以通过一段时间测试团队的成本和自动化用例数估算出一个用例的成本，也可以算出修复一个代码缺陷的成本等等。这样，我们再去观察 AI 在这些方面是否带来了一些变化。这些变化就能够反映出在成本方面的作用。

除了度量 AI 的成效，还可以将 AI 直接作用于度量本身。第一，我们可以将 AI 应用于度量的对象之上，这样可以提升我们数据的准确度和健康度。比如对于测试的覆盖度，我们无法一个一个地去检查每一个用例是否可靠，有没有只写了一堆 assert true。而利用 AI 就可以解决这样的问题。

此外，我们还可以将 AI 应用于度量的结果之上。例如让 AI 帮我们进行数据分析，或者在撰写报告的过程中让 AI 给我们提供更多的建议。

张乐：非常感谢晶磊的补充。我想强调的是，在度量过程中，我们需要谨慎使用单一指标，尤其是那些容易被操纵的指标。

徐陈飞： 晶磊提到的许多内容非常启发我。我也想在此基础上分享三个衡量 AI 大模型的关键点。

首先，AI 大模型的引入为我们提供了一种全新的视角。许多公司可能还处于度量的起步阶段，不知道如何合理地设置度量标准。而有些公司虽然已经建立了度量体系，但对度量指标的有效性存有疑问。这时，AI 大模型就像一个智能顾问，通过简单的问答形式，提供知识支持，帮助识别哪些做法是正确的，哪些需要改进，以及未来的规划方向。

其次，当我们积累了大量的数据，来自不同平台的数据需要整合和分析时，AI 大模型的作用尤为显著。传统的分析方法可能难以处理和识别复杂变量组合的的数据，而 AI 模型能够帮助分析我们的能效指标数据指标，可以帮助进行指标数据的相关性分析，揭示复杂数据背后的规律。我们发现，通过多模态的方式，可以更有效地解决数据分析中的问题。加强了分析能力，减少了误判的可能。

最后，在知识结构方面，AI 可以帮助我们逾越知识的瓶颈，从而实现能效的突破。度量只是第一步，真正的目的是通过度量来提升我们的工作效率。

王欢：我给大家分享一个 2024 年，我们做的 AI 跟效能结合的一个比较落地的点。

各位老师前面提到的 AI 应用多集中在提升效率，如代码补全和智能问答。而我们则专注于代码质量，这是一个相对小众但至关重要的领域。

引入效能度量系统后，我们发现代码重复度较高，这是一个警示。思码逸的效能基准报告中提到，较好的代码不重复度标准大约在 85%，而我们的数据显著低于这一水平。高代码重复度可能会影响代码的可维护性和健壮性，因此我们决定着手解决这一问题。

我们与高校合作，开发了一个代码相似度检测工具。这个项目耗费了半年时间，期间我们不断验证算法并进行标注。直到前两个月，我们才取得了重大突破，精准度达到了 85%以上。我们计划进一步验证并扩大应用范围。

最初，我们通过行政手段提高代码质量，但现在我们结合了大模型和机器学习算法，更有效地告知团队成员代码提交的质量标准，半年间代码不重复度提升近 10%，对于我们来说是一个巨大的进步。这也证明了效能度量后的改进是效能提升的关键一步。我的分享就到这里，谢谢大家。

3

展望 2025

任晶磊

AI将极大地提升单兵作战的能力，未来可能会出现更多技术领域的超级个体。

AI的安全合规将成为行业关注的重点。我们需要考虑如何让AI赋能我们的组织，同时确保数据的安全性和合规性。企业应当在内部培养适合自己组织的私有模型，以提升竞争力和自主能力。

徐陈飞

王欢

未来，效能度量将更侧重于实时洞察与闭环改进的协同联动，效能与AI的融合也将朝着实时性、个性化和预测性的方向迈进。

在AI4SE领域，我们已经看到了一些明显的趋势。从辅助编码Copilot到现在的AutoPilot，AI在研发工作中的角色正在从辅助逐步转向主导。我们的产品，无论是外部的GitHub还是内部的编码助手，都在朝着更加智能、更加自主的方向发展，相信未来将能够独立完成更多研发任务。

张乐

张乐： 2025 年已经开始了，那对于新的一年，对于研发效能的发展方向，大家有没有什么样的看法或一些展望？

任晶磊： 那我来简单说一下我的想法吧。首先，除了 AI 之外，许多企业正在“补课”数字化进程。例如为了实现基础度量，需要加强需求的管理；为了实现进一步精细化的度量，还要配合代码层面的分析。许多企业将在 2025 年继续加强数字化建设。

其次，关于 AI，我们期待出现更完整的解决方案，特别是开源方案。知识管理、知识工程和知识飞轮的概念正在发展中，目前还处于初级阶段。我们希望今年能看到一些开源或标准产品的出现。我自己也在探索将 AI 能力中的知识管理部分抽象出来并开源。

我相信，AI 将极大地提升单兵作战的能力，未来可能会出现更多技术领域的超级个体。我开始了一个“技术超级个体实验室”的项目，希望通过开放的方式，从产品定位到开发，再到市场和推广，利用 AI 增强个体能力来完成整个过程。我希望能够记录下这个过程，并为程序员提供参考。

最终，这个项目可能需要数月的时间来完善，但我计划从下周开始投入这个项目，这是我 2025 年的计划之一。如果这个项目成功获类似产品出现，我们可能会迎来一个重要时刻，类似 Hadoop 在大数据领域进程中出现那样关键。

徐陈飞：感谢晶磊老师的启发，我也来谈谈“超级个体”这一概念。2024 年下半年，我开始意识到个体能力的重要性。过去，我们常被教育说个体是渺小的，软件工程是一项庞大的集体事业。但如今，随着 AI 的发展，单兵作战的可能性似乎又重新出现了。

个体要想更强大，关键在于知识结构的梳理。企业也是如此，将知识沉淀好、规整好、结合好，就能成就一个新的未来。强大知识库的建立，能够从各个方面帮助提升能效，例如：需求自动化生成，测试用例自动化生成，运维智能化定位分析等等，包括代码重构和生成。知识库的构建本身来说就可能是一个庞大的工程，因此尽早投入实施将对未来个人或者企业达到事半功倍的效果。

同时，安全合规也成为我们关注的重点。我们需要考虑如何让 AI 赋能我们的组织，同时确保数据的安全性和合规性。市场上虽然有许多顶尖的公有模型，但我们不能完全依赖它们。我们需要培养自己的本土模型，以减少对公有模型的依赖。因此在公司内部培养搭建适合自己企业的私有模型是一个任重而道远的工作。

张乐： 谢谢徐老师。特别是关于知识工程的那部分，我深有感触。我最近也在处理基于原有知识结构的问题，由于之前的文档散乱无序，我们试图通过工程化方法来整理，过程确实非常艰难。这让我们意识到，一开始就做好知识结构的梳理是多么重要。这是一门我们必须补上的课，也是非常关键的一项工作。

至于安全问题，实事求是地讲，国内外在顶尖模型上存在差距。我们正在努力解决这一问题，对于一些安全性要求不那么高的内容，我们可能会考虑使用外部模型。但同时，我们也在推动内部模型的发展，以保护我们的敏感信息和保持对关键部分的控制。接下来，我想听听王欢老师在新的一年里有什么计划和想法。

王欢：感谢各位老师的启发，特别是晶磊提到的超级个体概念。罗老师的《预测之书》中提到的人类 2.0 概念，让我们思考在元宇宙中实现自由意志的可能性，甚至是在数字世界中实现永生。这引发了我对人类本质的思考。

徐老师提到的未来 AI 普及后，普适知识不再重要，个人特色和企业的个性化探索将成为关键。我也赞同这一观点。《预测之书》中提到，当普及知识不再是竞争要素时，个人的独特性和擅长领域将成为实现自我价值的关键。

关于效能度量的未来，我认为我们会更加注重实时洞察和闭环行动。目前，我们的度量往往是事后的，但展望 2025 或 2026 年，AI 的应用可能会让我们在事中进行度量，比如在代码生成过程中即时发现并解决质量问题。再进一步，我也期待 AI 能够进行事前预测，比如预测项目进度、风险和资源需求，从而提前制定解决方案。

总结来说，未来效能度量和 AI 的结合将朝着实时性、个性化和预测性发展，这将极大地提升我们的工作效率和决策质量。谢谢大家。

张乐： 非常感谢王欢老师的见解。在 AI4SE 领域，我们已经看到了一些明显的趋势。从辅助编码 Copilot 到现在的 AutoPilot，AI 在研发工作中的角色正在从辅助逐步转向主导。我们的产品，无论是外部的 GitHub 还是内部的编码助手，都在朝着更加智能、更加自主的方向发展，相信未来将能够独立完成更多研发任务。

我们一直在不断地集成 AI 能力，覆盖编码、测试、部署和运维各个阶段。进而通过智能体，将这些阶段将更加高效地串联起来，减少人工干预。

然而，我认为还有一些紧迫的问题需要解决。首先是需求的准确理解。工程师们常说，最终实现的产品可能与最初的需求不一致。我们需要让模型更好地理解需求，因为如果需求理解不准确，后续的工作将是无效的。

另一个问题是，对于复杂业务和遗留系统，我们如何提升 AI 的处理能力。许多创业项目或明星项目的演示都是从零开始，但在现实世界中，我们面对的是十年累积未经重构的复杂代码。如何在这些遗留系统上有效工作，也是一个需要解决的挑战。未来的突破点在于更好地理解需求和复杂工程。我们需要从模型、工程和产品三个角度持续探索。尽管挑战重重，但我相信我们每年都会朝着通用人工智能（AGI）的方向迈进一步，我们也应该保持乐观。

4

《DevData 研发效能基准报告》再度起航！

1、如您转载本公众号原创内容必须注明出处。

2、本公众号转载的内容是出于传递更多信息之目的，若有来源标注错误或侵犯了您的合法权益，请作者或发布单位与我们联系，我们将及时进行修改或删除处理。

3、本公众号文中部分图片来源于网络，版权归原作者所有，如果侵犯到您的权益，请联系我们删除。

4、本公众号发布的所有内容，并不意味着本公众号赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本公众号证实，对本文全部或者部分内容的真实性、完整性、及时性我们不作任何保证或承诺，请浏览者仅作参考，并请自行核实。