预测25年会逐渐流行的开发方式

大家好，我卡颂。

AI的发展对软件行业产生了不小冲击。当下经常能听到程序员终将被AI取代的论调。

虽然我们不知道这是否会发生、什么时候发生，但有一点可以肯定 —— 如果他终将发生，一定不是一蹴而就的，而是以渐进的形式逐渐改变程序员的开发方式。

本文基于我的行业观察，对明年（25年）会流行的开发方式做一个预测。

欢迎围观朋友圈、加入人类高质量前端交流群，带飞

我的预测逻辑

开发方式的变化并不是一蹴而就的，而是自底向上逐级传导的。

传导的层级包括三个：

1. 基建
2. 应用
3. 开发方式

接下来让我们看看每一层的变化是如何产生的，又是如何传导到上层的。

基建层面变化

上层应用只有在基建支持的情况下才会出现，比如短视频、直播、移动流媒体都是在4G基建成熟的前提下诞生的。

如果将LLM（大语言模型）作为基建，25年可以预见的变化包括：

1. 模型的思考能力（包括思考时长、分析能力）会提高

比如openAI表示在今年晚些时候会发布一个代号为Strawberry（草莓）的模型，比当前的GPT4更聪明。

2. 模型的上下文窗口大小会提高

去年，LLM的上下文窗口还普遍在4K～8K，今年已经涌现很多超过128k的模型，比如Claude3.5-sonnet-200k、GPT4-Turbo-128k，甚至有夸张的Gemini-1.5-pro-2M。

在编程领域：

• 思考能力提高意味着AI能更快、更好理解代码含义，同时有更强意愿输出详细的代码
• 上下文提高意味着AI能理解“代码量更多的项目”，这是单靠RAG技术无法实现的

两者是相辅相成的，这里存在一个两种能力的临界点。

达到临界点前，模型在使用场景上并没有代差，大家的使用场景都是“辅助生成上下文无关的代码片段”。

一旦某一模型突破临界点，该模型就会与其他模型形成代差，进化出新的使用场景 —— 可以为真实项目编写代码。

我认为今年突破临界点的模型是Claude3.5-sonnet：

• 思考能力方面：Claude3.5比GPT4更聪明
• 上下文方面：最大能到200k，足够一次性输入“上万行代码的项目”

之所以最近Cursor（一款AI驱动的IDE）能大放异彩，主要原因在于“他的默认模型是Claude3.5-sonnet”。

只有像Claude3.5-sonnet这样突破临界点的模型，才能支持Cursor Composer功能良好运行。

Cursor Composer功能可以简单理解为：AI帮你生成和修改整个项目的代码，包括配置、目录、代码文件等

有了Composer功能，8岁女孩都能在45分钟内搭起一个聊天机器人。

应用层面变化

今年在AI辅助编程领域比较成功的案例便是Cursor Composer功能的落地。

上一段已经聊到，这个功能的背后是Claude3.5-sonnet在支持。

实际上，我们不应该将Composer看作一个独立的功能，而应该是Cursor众多功能中粒度最粗的功能。

不管是Github Copilot还是Cursor，在最初诞生时，首先支持的都是“预测当前光标位置处可能需要的代码，通过按Tab键补齐”。

再往后，Cursor支持了更多粒度的“AI对代码进行操作”，比如：

• 对任意框选的代码
• 对命令行工具中会输入的代码
• 对任意文件下的所有代码
• 对任意项目下的所有代码（即Composer功能）

发现了么，Cursor并没有创造新的“AI与代码交互的方式”，而是用AI增强“程序员与代码已有的交互方式”。

这种渐进增强相比一刀切的低代码工具更容易被程序员接受。

同时我们也可以发现，上述“AI对代码执行的操作”，随着粒度逐渐变粗，还包含两个上升趋势：

1. 操作对应的提示词包含的内容变多
2. 操作包含代码的复杂度上升

虽然Cursor会利用RAG技术为整个项目建立索引，但对于粒度较粗的操作，类似：

• 对任意文件下的所有代码
• 对任意项目下的所有代码

背后还是需要“突破临界点的模型”支持的。

比如，如果你在Cursor中开启了LONG CONTEXT CHAT功能，在对文件夹提问时，Cursor会将文件夹中所有文件包含的代码整合到提示词中。

如果你想体验这条提示词有多长多复杂，可以试试code2prompt，这个工具可以帮你将一个目录下所有代码整合到一条提示词中。用他配合Claude3.5-sonnet-200k可以手动实现Composer功能

开发方式层面变化

基于基建、应用层面已经发生的变化，可以预测开发方式会产生什么变化呢？

首先，在讲解应用层面变化时有一个很重要的点 —— 变化一定是基于当前程序员熟悉的方式渐进增强，而不是突然产生新的方式。

当前，AI辅助编程的优点是提高编程效率，缺点是程序员对AI生成、修改的代码可能不太信任。

基于以上信息可以推导出 —— 这种新的开发方式是对已经存在的开发方式的增强，提高编程效率的同时，也能打消程序员对“AI生成代码”的顾虑。

这种新的开发方式就是AI驱动的TDD。

TDD (Test-Driven Development) 是一种软件开发方式，它强调在编写实际代码之前先编写测试。

可以用三个步骤的循环概括TDD：

1. 红色部分："Write a failing test"（编写一个失败的测试）

首先，开发者编写一个测试，这个测试是针对尚未实现的功能，因此它会失败。这个步骤的目的是明确定义期望的行为。

2. 绿色部分："Make the test pass"（使测试通过）

接下来，开发者编写最少量的代码，使刚才编写的测试能够通过。这一步的重点是快速实现功能，而不是追求完美的代码。

3. 蓝色部分："Refactor"（重构）

最后，在测试通过的基础上，开发者可以安全地重构代码，改进其结构和可读性，同时保持功能不变。重构后，所有测试应该仍然通过。

TDD的优点很明显，包括：

1. 提高代码质量和可靠性
2. 便于重构和维护
3. 形成自动化测试套件
4. 有助于设计清晰的接口和架构

但TDD对程序员素质要求较高，所以一直无法大规模推广。

有了AI辅助后，TDD的门槛大幅度降低。

要尝试AI驱动的TDD其实很简单，只需要修改提示词，让AI遵循TDD原则，在实现功能前，先实现高覆盖率的单测。

通过审视每个单测的描述，其实就能大体推断“AI对需求的理解是否到位”。

接下来，AI生成、修改业务代码后，都可以跑一遍测试用例来验证代码的正确性。

甚至，当AI驱动的TDD成熟后，很多手动执行的步骤都能由AI自动完成，比如如下步骤：

1. AI修改业务代码
2. 修改完成后，IDE自动跑测试用例
3. 用例报错后，AI根据报错信息修复代码
4. 重复步骤2直到通过用例

总结

任何变化都不是一蹴而就的，经济基础决定上层建筑。

在基建层面，最近几年大模型的思考能力、上下文窗口大小不断提升。

在两种能力达到临界点之前，在应用层面AI辅助编程主要局限在粒度较细的场景，比如“预测当前光标位置处可能需要的代码，通过按Tab键补齐”。

当基建层面的模型能力突破临界点后，应用层面就诞生更多粒度的AI辅助编程。

当应用层面的AI辅助编程能够理解完整项目后，就会催生AI驱动的TDD这种开发方式的流行。

我们不知道AI多久能取代程序员，但这个过程不会是一蹴而就的。

他会是基建到应用，再到开发方式的自底向上演进。

随着新开发方式的产生，就会有一部分手动工作被AI取代，比如上面提到的“AI跑测试用例修复代码”。

上述过程循环往复，AI编程的能力就会越来越强。