Anthropic最近发布了Claude 3.7，吸引了媒体的广泛关注。不过，大多数人似乎忽略了同时推出的另一个工具——Claude Code。这个命令行工具看起来不那么引人注目，界面也不够人性化，没有像Cursor或Devin那样高调宣称要自我进化甚至取代人类程序员。但当我深入了解后才意识到，这个看似普通的工具可能恰恰是推动AI Native软件开发革命的关键，甚至有可能深刻影响未来的商业模式和生态系统。
从传统模式到AI Friendly开发
在我们介绍和推广Agentic AI的过程中，经常收到针对Cursor这样的AI编程工具的反馈是：这些工具对于快速做原型、辅助写一些脚本或者进行数据分析的ad-hoc的任务可以完成得很好。但是，只要涉及到大型项目或者已有的成熟的代码库，AI就经常卡壳——它往往找不到最相关的文件和函数接口，也不了解相关的开发规范和最佳实践，更不用说去理解每个设计的高层决策过程甚至历史包袱了。
但这实际上是一个很关键的问题。很多企业手里都有十几万行、甚至上百万行的内部核心代码，光是列出依赖、结构、文档就够人喝一壶，别说让AI一次性学完。于是AI在小项目里大显身手，却对企业最关键的系统无从下手。如果我们没办法解决对接已有代码库这个问题，AI开发就只能停留在辅助开发或者原型构建上，而不能真的用于大型、严肃和最具有商业价值的项目里。而如果我们能解决让AI正确且高效地使用已有的代码库这个问题，下面整个领域的发展可能就一日千里。我们可以看见AI主导的软件开发在各个领域迅速落地。因此从某种程度上说，AI开发正面临一个鸿沟，一边是AI自主开发软件的美好愿景，一边则是AI还没办法利用大多数私有代码库的现实困境。
但说句公道话，这其实不是AI自己的问题。我们之前也多次讨论过，AI 要想有效地完成任何任务（不仅限于编程），前提是它要有足够的背景知识。就好比你新招了一个实习生，如果直接扔给他几百个文件的代码库，就指望他立刻写出正确高效的代码，这本身就是强人所难。更好的方法是给他一个入职培训，让他理解整个库的函数，结构，设计甚至历史。经过这样的培训，实习生写出高质量代码的成功率就会大幅提升。
对于AI来说，这种入职培训的具体形式往往是给它一个现成的prompt文件。例如，Model Context Protocol (MCP)这个项目就在这个URL里提供了这样的prompt文件。如果你把这个prompt文件扔给AI（比如ChatGPT或者Cursor），它就会有足够的背景知识来写出正确的代码。目前这个prompt文件的构建很多时候仍然是一个半自动甚至手动的过程。例如，我们可以把一个库里所有函数的docstring全部扔给ChatGPT，让它筛选出最重要的函数，然后写出一个Markdown的文档，作为AI的prompt使用。在这种文档的支持下，对于中小规模的项目，AI就可以轻松写出正确的程序了。
所以，到这一步为止，我们已经看见了两种不同的软件开发模式。一种传统模式是软件开发的deliverable就是代码本身，最多加一个给人类看的文档。但是，另一种新的思路是AI friendly的软件开发。它强调软件开发的交付物不仅是针对人类交付，同时是针对AI交付。所以，在代码本身和针对人类的文档之外，往往还会包含一个针对AI的prompt文件。它的好处是让AI可以迅速上手，用这个库直接写出正确的程序。
随着Cursor等工具的逐渐流行，软件开发是否AI friendly的重要性也越来越高。例如，你是一个公司的技术领导，面对两个库要做技术选型。一个库直接拿过来用Cursor就能上手写程序，另一个库你还要去做各种学习和处理，才能在AI的辅助下一点一点写。前者在市场上的竞争优势是不言而喻的。
21st.dev，Library as a Service，和AI Native开发
AI friendly的软件开发模式，虽然相比于传统的软件开发模式有了长足进步，但是它离引发整个软件开发领域的革新，仍然有着相当大的距离。为了理解这一点，我们先看一下21st.dev这个网站。21st.dev这个网站或者说软件库很有意思。它本质上是一个 UI 库，提供了很多前端组件。但和传统的软件库的使用方法不同，它不是把所有的组件交付给用户，让用户来学习和写代码，而是反过来，让用户告诉它想构建什么东西，它来选择调用什么样的 UI 组件来为用户构建一个前端。换言之，它的deliverable不是一个类库，而是用户需要的代码本身，这个代码里面包含了相关的类，用户也可以在拿到以后自行更改。
这其实是一种新的使用库的方法，Library as a Service（LaaS）。软件库的交付物不是代码，不是文档，而直接变成了一种服务，一个 API。对用户/开发体验来说，这是一个重大的改变。因为就算是AI Friendly的模式，在实际开发中，这个prompt文件也还是需要开发者自己撰写和维护，对团队在文档管理、版本控制、prompt撰写等方面提出了很多要求。因此，即使是AI Friendly这种开发模式，也往往只是在原有写代码—打包—部署的流水线里做局部改进，并没有颠覆性地改变交付模式。而LaaS就不一样了，它从“我交付的是API+背后的AI执行力”这个逻辑出发，把商业和技术交付捆绑在一起，彻底改变了怎么收费、怎么对外演示、怎么迭代升级。如果说传统的软件库交付的是建筑材料，LaaS交付的就是一个包工包料的施工团队，重构了软件开发的价值链。
在用户体验升级之外，LaaS对提供库的企业来说，也有很大的好处。一方面，这让企业有了更大的控制力和自主权，对外可以鼓励用户在使用库的时候应用最佳实践，对内可以做出更综合更高效的优化。另一方面，从收费的角度来说，它提供的这种附加值服务也可以带来超额盈利，让传统意义上一次交付的软件库变成了一只持续下金蛋的鸡。
从整个软件开发的领域来说，LaaS这种方法带来了巨大的想象空间。如果未来我们的软件库都以LaaS的方法交付的话，AI利用这些库来进一步构建软件的过程会变得特别简单和流畅。它更多的是起一个planner统筹规划的作用，只需要根据每个库擅长的领域决定什么问题用什么库就可以了。接下来，具体利用这些库来写代码则完全可以使用每个库的服务，利用API调用来完成。从某种层面上说，这也可以被称为Library as an Agent。这样我们就把一个复杂的利用多个软件库的软件开发流程，变成了一个multi-agent合作、迭代的问题。这样就可以解决我们在上一章开头提出的问题。如果有了LaaS，通过把库的学习和使用完全delegate给库的作者构建的agent，Agentic AI就不再是只能解决adhoc问题的玩具，而可以灵活高效地适配已有的企业级的软件库。
这种开发方法相比于传统的方法，甚至AI friendly的方法，是更加AI native的。虽然Agentic AI仍然是一个非常新的东西，我们在目前还很难预测未来软件开发最终会收敛到怎样的形式上去。但是我们基本可以肯定，最终大家都采用的一定是一种AI native的方法——所有技术手段围绕AI来设计，作为AI enabler来尽可能提升AI的工作效率这样的技术框架。
Claude Code和未来的AI开发生态
LaaS 的愿景虽然美好，但它的实现门槛仍然很高。比如，如何在代码生成的过程中引入 Agentic Workflow，来实现自我迭代、自我更正，从而保证生成的代码质量。这需要相当多的实战经验和对 LLM 的深刻理解。我们只要看一下开源的 Cline 和 Cursor 之间的性能差距，就容易理解了。
但 Claude Code 的出现正好填补了这个空白，极大地降低了 LaaS 的实现难度。具体来说，Claude Code 提供的功能就好像是一个命令行版的 Cursor。在命令行的参数里面用自然语言描述要实现的编程任务，它就会调用附带的几种工具，包括运行命令、修改文件等，来利用 Agentic Workflow 实现自我迭代、自我更正。因此，很多之前因为 Cursor 不提供 API 而很难解决的应用场景，我们可以通过借助 Claude Code 来轻松实现。
因此虽然它没有 GUI，看起来对终端用户没有太大吸引力，但是Claude Code作为一个基础的 Building Block，则为我们构建很多类似的应用提供了坚实的基础。与此同时，在 LaaS 愿景的指导下，它的价值不是让我们能够快速地抄一个 Cursor 出来，而是有潜力推动整个软件开发领域向 LaaS 或者类似的 AI-Native 开发的范式进发。这为彻底改变整个 AI 开发的模式，补全了一块重要的拼图。
除此之外，Claude Code 还有另一个功能是它可以用 Agentic 的方式调用各种工具，来阅读一个文件夹下面的代码，一步一步构建出一个 Prompt 文件。它具备的Agentic特征让它可以主动探索代码库，并通过对执行过程的动态分析来不断完善、修正对项目的理解。它就像一个人类实习生，在得到最初的指令后，会自己去读取并分析相关模块，用自然语言描述和工具调用相结合的方式，确认哪部分代码适合复用、哪部分需要改写。一旦我们在现有系统里完成这样的迁移过程，就等于为AI真正打通了与传统代码库的阻隔。后续开发新功能或重构旧逻辑时，AI不需要再次经历同样冗长的学习过程，而是能够直接接管这套自动化工作流，迭代更新成果。
因此，总的来说，Claude Code 的目标是把传统的软件库的使用方式向 AI-Friendly 和 AI-Native 的方向转变，通过提供适当的工具来让这两种迁移更加顺利和无痛。它背后所拥有的愿景和野心其实远远大于这个简单的命令行工具表面上的价值。一个AI统筹所有服务、自动编码、自动调度的世界的雏形，或许已经悄悄地在Claude Code身上出现了。这种愿景离真正落地还有不少路要走，包括对API规范的标准化、对安全的策略把控，以及对Agentic AI在不同场景下边界与责任划分的探讨。但从Claude Code迈出的这一步来看，Anthropic已经在非常务实地解决一个业界普遍痛点：如何让AI更智能地对接旧系统，又如何让旧系统逐渐蜕变为新的LaaS形态，从而通往AI-native的未来。
也许这正是Anthropic最具前瞻性的地方，却因为没有Claude 3.7那么炫目而被很多人忽视。但我相信，将来大家回头看时，会发现Claude Code在这场AI-native软件革命里扮演了一个不可替代的起点角色。
Comments