一名云计算从业者的思考

大家都在搜：

热搜词1 热搜词2 热搜词3

当前位置：首页 > Serverless > 正文内容

当AI成为云函数的"造物主"：从AI Coding到AI Service的演进

anycodes1年前 (2025-07-01)Serverless6270

在[《AI Coding与FaaS的融合》](https://runor.cn/?id=9 "《AI Coding与FaaS的融合》")一文中，我曾提出一个观点：未来的函数开发中，将在现有编写确切代码基础上，新增“意图编程”，即通过用户的意图，即可完成函数的创建。当时这还是一个理论构想，而现在，通过Dify和Lambda构建的"AI代码工厂"，我完成了这个理念的初步验证。

这个POC项目的意义在于，它正在实现"意图驱动"的函数创建。传统FaaS开发中，即使有了Serverless框架的帮助，开发者仍然需要编写具体的处理逻辑、配置触发器、定义输入输出。而在这个系统中，你只需要表达意图："创建一个函数，验证信用卡号是否有效"，AI就会理解这个意图，生成符合相关的算法验证代码，完成部署。

从确切代码到意图表达，这个转变看似简单，实则触及了软件开发的本质。代码从来都只是手段，解决问题才是目的。当AI能够理解问题并自动选择解决方案时，我们实际上是在重新定义人与计算机的交互方式。这不仅是效率的提升，更是创造模式的根本改变——从"告诉计算机怎么做"到"告诉计算机做什么"。

## 意图理解的技术内核

在实现这个项目的过程中，我深刻体会到当前大语言模型在意图理解上的成熟度已经超出了很多人的预期。以Claude 4 Sonnet为例，当用户说"验证信用卡号"时，它不仅知道这需要实现某些算法，还能生成包含完整错误处理的生产级代码。当用户要求"处理Webhook请求"时，它会自动考虑签名验证、幂等性处理、超时重试等实际生产环境的需求。

这种能力已经不是实验室里的演示，而是可以投入实际使用的技术。在测试中，我发现对于大多数轻量级的业务逻辑——数据验证、格式转换、API调用、简单的业务规则判断——当前的LLM已经能够准确理解意图并生成高质量的实现。更令人惊喜的是，这些模型展现出了对上下文的深度理解：它们知道什么时候需要异步处理，什么时候应该使用缓存，什么样的错误需要重试。

这种理解能力的背后，是大语言模型通过海量代码训练获得的模式识别能力。但更重要的是，像Claude这样的模型已经能够理解代码的"为什么"，而不仅仅是"怎么做"。当你要求创建一个"处理支付回调"的函数时，它会自动考虑安全性、幂等性、事务性——这些都是基于对业务场景的理解，而非简单的模式匹配。

更深层的突破在于，这些AI模型开始展现出"工程思维"。在生成代码时，它们会主动考虑可维护性、可测试性、性能优化。这种"隐含意图"的理解，让AI生成的代码不仅能运行，还具备了生产级的品质。事实上，在很多标准场景下，AI生成的代码质量已经超过了初级开发者的平均水平。

通过"Lambda部署Lambda"的架构设计，系统实现了完整的自动化闭环。部署器本身也是一个Lambda函数，它理解部署的意图，处理打包、权限、配置等所有细节。这种递归式的设计不仅优雅，更展示了当AI与FaaS结合时的威力——当函数成为基本的计算单元，而AI能够理解和创造函数时，我们获得了一种全新的软件构建方式。

> 额外吐槽：Claude 4 现在非常容易过渡思考，过渡解读，还是有点痛苦的，好在 Prompt 还是有作用的。

## 从AI Coding到AI Service的范式跃迁

如果说AI Coding是让机器帮助人类写代码，那么AI Service则是让机器直接交付可用的服务。这个转变的核心在于"完整性"——不仅要生成代码，还要处理部署、配置、监控、维护的全生命周期。

当前市面上的AI编程工具如Cursor、GitHub Copilot等确实做得很出色，但它们本质上仍然是"辅助工具"。受限于token容量和上下文窗口，这些工具在面对大型项目时往往力不从心。它们可以帮你写一个函数、优化一段代码，但很难独立完成一个完整的系统。

而FaaS的特性恰好完美契合了当前AI的能力边界。云函数天生就是轻量级的——单一职责、输入输出明确、代码量通常在几百行以内。这种"短平快"的特性让AI能够真正掌控全局，从理解需求到生成代码，从配置环境到完成部署，整个过程都在AI的能力范围内。

更重要的是，现代微服务架构告诉我们，复杂的业务系统往往是由大量简单的服务组合而成的。一个电商系统可能包含订单处理、库存管理、支付验证、消息通知等数百个功能，但每个功能都可以是一个独立的函数。当AI能够快速创建和部署这些函数时，构建复杂系统就变成了组装积木的过程。

这个项目展示了AI Service的真正潜力。用户得到的不是一段需要手动部署的代码片段，而是一个已经在云端运行、可以直接调用的API。整个过程完全自动化：AI理解需求、生成代码、创建部署包、配置权限、部署函数、返回调用地址。这种端到端的自动化，是Cursor等工具目前还无法实现的。

传统的软件开发流程是线性且割裂的：需求分析→设计→编码→测试→部署→运维。每个环节都需要不同的专业技能，环节之间的交接往往成为瓶颈。而在AI Service模式下，这些环节被压缩成一个连续的过程。AI不仅理解业务需求，还理解技术约束，能够在生成代码时就考虑部署环境、性能要求、安全规范。

这种模式的深远影响在于，它重新定义了"开发者"的概念。未来的开发者可能不需要精通编程语言的语法细节，但需要能够清晰地表达意图、定义约束、验证结果。这是一种新的专业技能，更接近于"服务设计师"而非传统的程序员。他们的价值在于理解业务、设计服务交互、确保系统的整体一致性，而不是编写具体的实现代码。

## 技术栈的隐形化与价值的显性化

当函数可以通过自然语言创建时，一个有趣的现象出现了：技术栈开始逐渐变得"隐形"。用户不需要知道Python还是Node.js，不需要了解AWS的服务细节，甚至不需要理解什么是API。技术成为了背景，价值成为了前景。基于我的PoC，可以分享三个案例：

### 案例1：生成 IP 查询服务

如图所示，当我们表达出想要查询本地 IP 服务时，LLM 可以分析意图，完成函数编写，并调用 Agent 实现相关函数的创建。

![WechatIMG55.jpg](https://note.runor.cn/pic/home/bl/img/U1/WechatIMG55.jpg)

创建后，会烦会给我们对应的信息，包括服务地址以及使用方法，此时可以进行基础的测试：

![WechatIMG58.jpg](https://note.runor.cn/pic/home/bl/img/U1/WechatIMG58.jpg)

### 案例2：查询请求者所在地天气

如图所示，当我们给出了一个明确的功能，但是没有给出具体实现路径，LLM 可以在明确的功能基础上，对实现路径进行完善，例如：

1. 先通过谷歌搜索，进行相关 API 的查询；
2. 编排 API：先获取 IP 地址，再获取 IP 对应地区，再获取地区天气；

通过上面两个流程之后，完成业务所需的代码，并进行部署操作：

![WechatIMG62.jpg](https://note.runor.cn/pic/home/bl/img/U1/WechatIMG62.jpg)

同样可以对部署返回的结果进行测试：

![WechatIMG59.jpg](https://note.runor.cn/pic/home/bl/img/U1/WechatIMG59.jpg)

可以看到，非常顺利的返回预期的结果。当然，作为用户还可以进一步规约请求参数，响应格式等信息。

### 案例3：对文档解析并生成个人简历

找到了我很久之前的个人简历，通过传给 LLM，由 LLM 进行分析并生成对应的 HTML 代码：

![WechatIMG57.jpg](https://note.runor.cn/pic/home/bl/img/U1/WechatIMG57.jpg)

自动部署之后，可以通过反悔的页面查看效果（由于中间涉及到过多的个人信息，所以已省略，只保留部分截图内容）：

![WechatIMG60.jpg](https://note.runor.cn/pic/home/bl/img/U1/WechatIMG60.jpg)

![WechatIMG61.jpg](https://note.runor.cn/pic/home/bl/img/U1/WechatIMG61.jpg)

通过上面三个案例，不难看出，这种转变对整个软件产业都有深远影响。首先，它极大地扩展了软件创造者的范围。当一个销售人员可以创建自己的线索评分函数，当一个运营人员可以部署自己的数据清洗服务时，软件开发不再是程序员的专属领域。

其次，它改变了软件的经济学。传统模式下，软件开发的成本主要来自人力。而在AI Service模式下，创建一个函数的边际成本接近于零。这可能会催生全新的软件消费模式——也许未来我们不是购买软件，而是随时创建所需的功能。

但技术栈的隐形化并不意味着技术变得不重要。相反，底层技术需要变得更加智能和健壮。当用户不再直接控制技术细节时，系统必须能够自动做出最优选择。这对AI的要求更高——它不仅要理解意图，还要理解上下文，做出合理的技术决策。

## 新型软件生态的萌芽

这个项目让我看到了一种新型软件生态的可能性。在这个生态中，函数不再是预先定义的、静态的代码块，而是根据需求动态生成的、自适应的服务单元。

想象这样一个场景：企业的ERP系统检测到订单处理流程出现瓶颈，它自动生成一个优化的处理函数并部署；营销团队需要分析新的用户行为模式，他们描述需求后立即得到一个定制的分析服务；当业务规则改变时，相关的函数自动更新逻辑。

这种动态性和自适应性将从根本上改变企业IT的运作方式。IT部门的角色将从"建设者"转变为"编排者"，他们的工作是定义规则、设置边界、确保合规，而不是编写具体的代码。

更有趣的是函数之间的组合和协作。当创建函数变得足够简单时，我们可以构建更细粒度的服务，然后通过组合实现复杂功能。这种"原子化"的服务架构不仅更灵活，也更容易优化和维护。

更甚者，我认为我们正处于软件开发范式转变的早期阶段。就像从汇编到高级语言的转变一样，从代码到意图的转变将是渐进的、但最终是彻底的。

短期内，AI Service将首先在特定领域取得突破。数据处理、API集成、定时任务这些相对标准化的场景将最先被AI Service覆盖。随着AI能力的提升和最佳实践的积累，越来越复杂的业务逻辑也将被纳入自动化范围。

中期来看，我们可能会看到专门的"意图描述语言"的出现。这种语言将比自然语言更精确，但比编程语言更易懂。它将成为人类和AI协作的界面，确保意图的准确传达和实现。

长期而言，软件开发可能会变成一种全新的创造活动。当技术实现不再是瓶颈时，创新的焦点将转移到问题定义和价值创造上。这将释放巨大的创新潜力，让更多人参与到数字化创新中来。

当然，这个过程中也会有挑战。如何确保AI生成服务的质量和安全性？如何处理复杂的业务逻辑和边缘情况？如何在自动化和可控性之间找到平衡？这些都需要在实践中逐步解决。

## 总结

回顾这个项目的开发过程，我深刻感受到我们正站在一个历史性的转折点上。当创建一个云服务变得像写一句话一样简单时，我们不仅改变了软件开发的方式，更改变了人与技术的关系。

技术不再是少数人的特权，而成为所有人的工具。创新不再受限于技术能力，而取决于想象力和洞察力。这是技术民主化的真正含义——不是让每个人都成为程序员，而是让每个人都能用技术实现自己的想法。

从AI Coding到AI Service，从代码到意图，我们正在见证软件开发新纪元的开启。

----

为了让大家更直观看到我的实现，我将实现的架构图给大家展示如下：

整体架构图

![WechatIMG63.jpg](https://note.runor.cn/pic/home/bl/img/U1/WechatIMG63.jpg)

详细数据流图

![WechatIMG64.jpg](https://note.runor.cn/pic/home/bl/img/U1/WechatIMG64.jpg)

组件详细架构

![WechatIMG65.jpg](https://note.runor.cn/pic/home/bl/img/U1/WechatIMG65.jpg)

另外，我在 Lambda 创建的三个函数也可以简单的 Show 一下：

![WechatIMG66.jpg](https://note.runor.cn/pic/home/bl/img/U1/WechatIMG66.jpg)

其中获取 IP 地址的代码案例：

```python
import json

def lambda_handler(event, context):
    """
    获取访问者的IP地址
    """
    try:
        # 从API Gateway事件中获取客户端IP
        client_ip = None
        
        # 尝试从不同的头部获取真实IP
        headers = event.get('headers', {})
        
        # 检查常用的IP头部字段
        ip_headers = [
            'x-forwarded-for',
            'x-real-ip', 
            'x-client-ip',
            'cf-connecting-ip',  # Cloudflare
            'true-client-ip'
        ]
        
        for header in ip_headers:
            if header in headers:
                ip_value = headers[header]
                if ip_value:
                    # x-forwarded-for可能包含多个IP，取第一个
                    client_ip = ip_value.split(',')[0].strip()
                    break
        
        # 如果没有找到，使用requestContext中的IP
        if not client_ip:
            request_context = event.get('requestContext', {})
            if 'identity' in request_context:
                client_ip = request_context['identity'].get('sourceIp')
        
        # 如果还是没有找到，返回未知
        if not client_ip:
            client_ip = "未知"
        
        # 构造响应数据
        response_data = {
            'ip': client_ip,
            'message': f'您的IP地址是: {client_ip}',
            'timestamp': context.aws_request_id,
            'headers': headers  # 调试用，可以看到所有头部信息
        }
        
        return {
            'statusCode': 200,
            'headers': {
                'Content-Type': 'application/json; charset=utf-8',
                'Access-Control-Allow-Origin': '*',
                'Access-Control-Allow-Methods': 'GET, POST, OPTIONS',
                'Access-Control-Allow-Headers': 'Content-Type'
            },
            'body': json.dumps(response_data, ensure_ascii=False, indent=2)
        }
        
    except Exception as e:
        return {
            'statusCode': 500,
            'headers': {
                'Content-Type': 'application/json; charset=utf-8',
                'Access-Control-Allow-Origin': '*'
            },
            'body': json.dumps({
                'error': '获取IP地址失败',
                'message': str(e)
            }, ensure_ascii=False)
        }
```

扫描二维码推送至手机访问。

本文链接：https://runor.cn/?id=16

标签: AI服务云函数意图编程技术民主化软件开发范式 Serverless

分享给朋友：

返回列表

上一篇：FaaS+Agent：深入探索无服务器计算的产品边界

下一篇：当AI学会用AWS CLI：AIOps实践的新思路

刘博说云

大家都在搜：

当AI成为云函数的"造物主"：从AI Coding到AI Service的演进

“当AI成为云函数的"造物主"：从AI Coding到AI Service的演进” 的相关文章

与其AgentCore不如FC：函数计算FC如何重塑AI Agent开发

FaaS与AI的理性结合：为什么我们不需要另一个Dify

Serverless 没有死，它只是在等 AI

当AI学会用AWS CLI：AIOps实践的新思路

FaaS+Agent：深入探索无服务器计算的产品边界

发表评论

Powered By Z-BlogPHP. Theme by TOYEAN.

刘博说云

大家都在搜：

当AI成为云函数的"造物主"：从AI Coding到AI Service的演进

“当AI成为云函数的"造物主"：从AI Coding到AI Service的演进” 的相关文章

与其AgentCore不如FC：函数计算FC如何重塑AI Agent开发

FaaS与AI的理性结合：为什么我们不需要另一个Dify

Serverless 没有死，它只是在等 AI

当AI学会用AWS CLI：AIOps实践的新思路

FaaS+Agent：深入探索无服务器计算的产品边界

发表评论取消回复

Powered By Z-BlogPHP. Theme by TOYEAN.

发表评论