LLM成为新型高级编程语言

LLM成为新型高级编程语言

基本信息

• 作者: swah
• 评分: 153
• 评论数: 290
• 链接: https://federicopereiro.com/llm-high
• HN 讨论: https://news.ycombinator.com/item?id=46868928

导语

随着大语言模型（LLM）能力的快速迭代，一种新的编程范式正在悄然形成：自然语言正逐渐演变为继汇编、C 和 Python 之后的“下一代高级语言”。这一转变不仅意味着我们可以用更直观的方式指挥计算机，更预示着软件开发流程的底层逻辑将发生根本性重构。本文将深入探讨这一趋势，分析 LLM 如何从单纯的辅助工具转变为系统的核心控制层，并帮助开发者理解在“自然语言即代码”的时代，如何构建更具韧性的技术架构。

评论

文章中心观点： 大语言模型（LLM）正在演变为一种新型的高级编程语言（HL），它将自然语言语义直接编译为机器指令，从而从根本上改变软件工程的抽象层级和人机交互模式。

支撑理由与边界条件分析：

1. 语义压缩与抽象层级的跃升

   • [事实陈述] 传统编程语言（如Python、C++）通过语法结构抽象了机器码，而LLM通过概率模型抽象了语义意图。
   • [作者观点] 文章主张LLM是比现有HL更高维度的抽象，因为开发者只需描述“做什么”，模型即可处理“怎么做”。
   • [你的推断] 这类似于从汇编语言转向高级语言的范式转移，但这次转移的跨度更大，因为它将“逻辑实现”也黑盒化了。
   • [反例/边界条件] 这种抽象在需要确定性控制（如编写操作系统内核、高频交易系统）时不仅无效，甚至危险。LLM的随机性本质与底层系统对确定性的要求存在根本冲突。

2. 从“代码编写”到“意图编程”的范式转移

   • [事实陈述] 现有的LLM应用（如GitHub Copilot）已经展示了通过注释生成代码的能力。
   • [作者观点] 未来的编程将不再关注语法细节，而是关注Prompt Engineering（提示工程）和对模型输出结果的验证。
   • [你的推断] 这将导致“软件工程师”的角色向“系统架构师”或“AI牧羊人”转变，核心技能从记忆API变为精确的语义表达。
   • [反例/边界条件] 在处理遗留系统或极度复杂的遗留代码库时，自然语言的模糊性难以精确映射到具体的代码修改点，人工介入编写代码依然效率更高。

3. 上下文窗口作为新的“内存与状态管理”

   • [事实陈述] LLM的上下文窗口限制了其处理任务的连续性和规模。
   • [作者观点] 随着上下文窗口的扩大，LLM能够承载更完整的系统状态，从而承担更复杂的编程任务。
   • [你的推断] 这意味着未来的编程语言设计将不再侧重于变量作用域，而是侧重于如何高效地向模型注入上下文。
   • [反例/边界条件] 当上下文窗口达到极限（例如处理数百万行级别的企业级代码库），单纯的语义检索无法替代传统的模块化导入和符号链接机制，LLM的“遗忘”特性会导致系统维护成本指数级上升。

多维度评价：

1. 内容深度：观点的深度和论证的严谨性 文章的核心隐喻（LLM = HL）极具洞察力，触及了计算的本质——抽象。它不仅仅将LLM视为工具，而是视为一种新的媒介。论证较为严谨，指出了从“确定性语法”向“概率性语义”的转变。然而，文章可能低估了“幻觉”问题对编程语言基础属性的破坏。编程语言的核心价值在于可预测性和形式化验证，LLM目前在这方面缺乏数学上的完备性支撑。

2. 实用价值：对实际工作的指导意义 对开发者而言，该观点具有极高的指导意义。它提示工程师不应仅仅将AI视为辅助补全工具，而应开始练习“用自然语言描述复杂逻辑”的能力。这促使开发者思考如何构建更适合AI理解的系统架构，例如倾向于模块化、文档驱动的开发模式，以便AI能够更好地理解和生成代码。

3. 创新性：提出了什么新观点或新方法 将LLM重新定义为“语言”而非“工具”是文章最大的创新点。这一视角跳出了单纯比较模型参数或Benchmark的框架，从计算机科学历史演变的宏观角度定位了LLM的地位。它暗示了未来的编程环境将是一个集成了解释器、编译器和LLM的混合体。

4. 可读性：表达的清晰度和逻辑性 该概念本身具有极强的解释力，能够迅速在读者脑海中建立认知框架。通过类比传统高级语言的演变，文章降低了理解门槛，使得非AI研究人员也能理解这一趋势的重要性。

5. 行业影响：对行业或社区的潜在影响 如果这一观点成立，软件行业的准入门槛将发生改变。低代码/无代码平台将获得真正的智能内核，初级程序员的“语法熟练度”价值将被稀释，而“系统设计能力”和“需求分析能力”的价值将大幅提升。同时，这可能催生新的编程语言标准，即“为AI优化的自然语言子集”。

6. 争议点或不同观点

   • 确定性缺失： 传统编程语言通过编译器保证逻辑的确定性执行。LLM的随机性本质使得它难以胜任关键任务系统。批评者会认为，没有形式化验证的语言只能用于脚本，不能用于工程。
   • 效率与成本： 相比于直接运行编译后的机器码，每次运行LLM进行推理（Inference）的算力成本极其高昂。将LLM视为通用语言在能源和成本上目前是不可持续的。
   • 调试的噩梦： 当代码是由概率生成的，调试过程将变得极其复杂。传统的断点调试可能失效，取而代之的是对Prompt的微调，这种非确定性的调试过程难以被传统工程界接受。

7. 实际应用建议

   • 拥抱“AI优先”的开发模式： 在新项目中，优先考虑使用LLM作为逻辑处理层，而非仅仅作为外挂。
   • **投资于RAG技术：

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# 示例1：智能文本摘要生成
from openai import OpenAI

def summarize_text(text: str, max_length: int = 100) -> str:
    """
    使用LLM将长文本摘要为指定长度的简短描述
    参数:
        text: 需要摘要的原始文本
        max_length: 摘要的最大长度(字符数)
    返回:
        摘要后的文本
    """
    client = OpenAI()  # 需要设置OPENAI_API_KEY环境变量
    
    response = client.chat.completions.create(
        model="gpt-3.5-turbo",
        messages=[
            {"role": "system", "content": f"你是一个专业文本摘要员，请将文本摘要为不超过{max_length}字的简短描述"},
            {"role": "user", "content": text}
        ]
    )
    return response.choices[0].message.content

# 使用示例
long_text = "这里是一段很长的文本..."  # 替换为实际文本
summary = summarize_text(long_text)
print(f"摘要结果: {summary}")

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

# 示例2：自然语言数据库查询
from openai import OpenAI
import sqlite3

def query_database(natural_query: str, db_path: str = "example.db") -> str:
    """
    将自然语言问题转换为SQL查询并执行
    参数:
        natural_query: 自然语言问题(如"显示销量前5的产品")
        db_path: SQLite数据库文件路径
    返回:
        查询结果的JSON字符串
    """
    client = OpenAI()
    
    # 第一步：将自然语言转换为SQL
    sql_response = client.chat.completions.create(
        model="gpt-3.5-turbo",
        messages=[
            {"role": "user", "content": f"数据库包含products表(字段:id,name,price,sales)。问题: {natural_query}"}
        ]
    )
    sql_query = sql_response.choices[0].message.content.strip()
    
    # 第二步：执行SQL查询
    conn = sqlite3.connect(db_path)
    cursor = conn.cursor()
    cursor.execute(sql_query)
    results = cursor.fetchall()
    conn.close()
    
    # 第三步：将结果转换为自然语言描述
    result_response = client.chat.completions.create(
        model="gpt-3.5-turbo",
        messages=[
            {"role": "system", "content": "将查询结果转换为友好的自然语言描述"},
            {"role": "user", "content": f"问题: {natural_query}\n结果: {results}"}
        ]
    )
    return result_response.choices[0].message.content

# 使用示例
answer = query_database("哪些产品销量超过1000?")
print(answer)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 示例3：智能代码补全和生成
from openai import OpenAI

def generate_code(description: str, language: str = "python") -> str:
    """
    根据自然语言描述生成代码
    参数:
        description: 功能描述(如"用快速排序算法排序列表")
        language: 目标编程语言
    返回:
        生成的代码字符串
    """
    client = OpenAI()
    
    response = client.chat.completions.create(
        model="gpt-3.5-turbo",
        messages=[
            {"role": "user", "content": f"请实现: {description}"}
        ]
    )
    return response.choices[0].message.content

# 使用示例
code = generate_code("用快速排序算法排序列表", "python")
print(code)
exec(code)  # 执行生成的代码

案例研究

1：Klarna（瑞典金融科技巨头）

1：Klarna（瑞典金融科技巨头）

背景: Klarna 是欧洲最大的金融科技公司之一，提供“先买后付”等服务。随着全球业务扩张，其客服团队面临巨大压力，需要处理数百万次日常咨询，包括退款查询、支付状态检查等重复性高的问题。

问题: 传统的客服模式人力成本高昂，且在高峰期响应速度慢。公司希望通过自动化手段提升效率，但旧式的基于规则的聊天机器人体验僵硬，无法理解复杂的用户意图，导致用户满意度下降。

解决方案: Klarna 并没有编写大量的 Python 或 Java 代码来构建传统的决策树机器人，而是将 OpenAI 的 GPT-4 模型作为一种“高级语言”使用。他们通过精心设计的 Prompt Engineering（提示词工程），让 LLM 直接理解用户意图并调用内部 API 执行操作。开发人员不再编写传统的“if-then-else”逻辑，而是编写自然语言指令来定义机器人的行为边界和知识库。

效果: 该 AI 助手上线一个月内就处理了 230 万次对话，相当于 700 名全职客服的工作量。

• 直接为 Klarna 每年节省了 4000 万美元的成本。
• 客服响应时间从 11 分钟缩短至 2 分钟。
• 重复性问题解决率极高，且用户体验更加自然流畅。

2：Cognition AI（Devin 开发团队）

2：Cognition AI（Devin 开发团队）

背景: Cognition AI 是一家初创公司，致力于开发世界上第一个 AI 软件工程师 Devin。他们的目标是让 AI 能够像人类工程师一样，通过规划、编写代码、调试和部署来解决复杂的工程任务。

问题: 传统的自动化脚本或代码生成工具只能处理片段式的代码，无法在复杂的开发环境中进行长期的逻辑推理和自我纠错。如何让 AI 理解整个项目的上下文，并在没有人类持续干预的情况下完成多步骤任务，是核心挑战。

解决方案: 开发团队将 LLM（特别是具备强推理能力的模型）视为控制系统的“大脑”或“高级语言”。LLM 不再仅仅是生成代码片段的工具，而是负责发出指令（Shell 命令、搜索文件、编辑代码）。他们构建了一个沙箱环境，让 LLM 能够通过自然语言推理来决定下一步操作（例如：“我发现测试失败了，我需要检查日志文件”，然后 LLM 调用 Shell 命令去读取日志，再根据内容修改 Python 代码）。

效果: Devin 成功通过了顶级工程公司的实际面试测试，并在 Upwork 等自由职业平台上完成了真实的开发任务。

• 能够端到端地完成网站开发和 Bug 修复，展示了 LLM 作为高级语言在逻辑规划和工具调用上的巨大潜力。
• 标志着软件开发从“手写语法”向“描述逻辑让机器生成”的范式转变。

3：Bloomberg（彭博社）

3：Bloomberg（彭博社）

背景: 彭博社拥有海量的金融数据，包括数十年的文档、新闻稿、财报和交易数据。金融分析师需要从这些非结构化数据中快速提取关键信息，并结合结构化数据进行趋势分析。

问题: 传统的 SQL 查询只能处理结构化数据，而针对新闻的情感分析或特定事件的提取通常需要训练专门的 NLP 小模型。这种开发模式周期长，且模型泛化能力差，难以应对金融领域瞬息万变的查询需求。

解决方案: 彭博社基于开源 LLM 微调开发了 BloombergGPT。他们将 LLM 作为一种新的“数据查询接口”。分析师不再需要编写复杂的正则表达式或专门的 ETL 脚本，而是直接用自然语言向模型提问。LLM 充当了“高级编译器”的角色，将自然语言的业务需求转化为对底层数据库的查询或对文档的总结。

效果:

• 极大地提高了金融信息检索的效率，分析师可以快速获取如“总结过去一周关于某公司的负面新闻对股价的影响”这类复杂问题的答案。
• 证明了在高度专业化和数据敏感的领域，使用 LLM 作为统一的高级交互层，可以替代原本碎片化的工具链，显著降低信息获取的门槛。

最佳实践

最佳实践指南

实践 1：采用“意图优先”的编程范式

说明: 传统编程要求开发者精确指定每一步操作，而将 LLM 视为高级语言意味着开发者只需描述期望的最终状态或目标。这种范式转变要求从“命令式”思维转向“声明式”思维，让模型负责填补逻辑空白。

实施步骤:

1. 在编写代码前，先用自然语言清晰定义函数的输入、输出和业务逻辑目标。
2. 使用结构化注释或文档字符串作为提示词，而非直接编写底层逻辑代码。
3. 编写测试用例来验证意图是否被正确实现，而非关注具体的代码路径。

注意事项: 避免在提示词中过度规定实现细节（如具体的变量名或循环结构），这可能会限制模型生成更优解的能力。

实践 2：构建上下文感知环境

说明: LLM 作为编译器或解释器运行时，极度依赖上下文。最佳实践要求将代码库、API 文档和业务规则有效地注入到模型的上下文窗口中，使其能够“看到”整个项目的全貌，从而生成符合项目规范的代码。

实施步骤:

1. 建立标准化的 RAG（检索增强生成）流程，从知识库中提取相关的代码片段和文档。
2. 在项目根目录维护一个高度结构化的 CONTEXT.md 文件，包含架构设计、编码规范和关键业务逻辑。
3. 使用长上下文模型或滑动窗口技术，确保模型在生成代码时能引用之前的定义。

注意事项: 上下文窗口是有限资源（或成本较高），必须通过语义相似度检索最相关的信息，防止引入噪音导致模型注意力分散。

实践 3：实施“人机协同”的验证闭环

说明: 将 LLM 视为高级语言并不意味着完全放弃人类控制。由于概率性输出可能导致非确定性错误，必须建立严格的审查机制。人类从“编写者”转变为“审核者”和“架构师”。

实施步骤:

1. 对于关键业务逻辑，强制要求代码审查，重点检查模型生成代码的安全性、边界条件和逻辑漏洞。
2. 利用 LLM 自身进行自我审查，要求模型在生成代码后解释其逻辑，并生成对应的单元测试。
3. 建立“红队”机制，专门尝试攻击或破坏生成的代码，以验证其鲁棒性。

注意事项: 不要盲目信任模型生成的代码，特别是涉及权限、数据操作或外部 API 调用的部分。

实践 4：建立渐进式提示词工程标准

说明: 既然 LLM 是新的语言，那么提示词就是新的语法。最佳实践要求将提示词工程视为与代码工程同等重要的一环，建立版本控制、模块化和复用机制。

实施步骤:

1. 将复杂的系统指令拆解为模块化的提示词组件（如“角色定义”、“任务描述”、“输出格式限制”）。
2. 使用配置文件管理提示词，并将其纳入 Git 版本控制，以便追踪和回滚。
3. 开发“元提示词”，即用于生成或优化其他提示词的提示词，以保持指令的一致性和高质量。

注意事项: 避免在代码库中硬编码提示词字符串，应使用专门的提示词管理工具或类库进行维护。

实践 5：设计适应概率性输出的容错架构

说明: 传统的确定性代码在遇到异常时会抛出错误，而 LLM 的输出可能会出现幻觉、格式错误或逻辑偏差。系统架构必须具备处理这些“软错误”的能力。

实施步骤:

1. 在 LLM 输出与实际执行逻辑之间建立解析层，使用 Pydantic 或 JSON Schema 验证输出格式的合法性。
2. 实施自动重试机制，当输出不符合预期或验证失败时，自动调整参数或提示词并重新生成。
3. 设计回退策略，当模型无法解决特定问题时，平滑降级到传统规则引擎或人工处理流程。

注意事项: 验证逻辑必须严密，防止格式错误的模型输出导致下游系统崩溃。

实践 6：优化成本与延迟的平衡策略

说明: 将 LLM 作为通用计算层会带来显著的经济成本和延迟开销。最佳实践要求根据任务的复杂度动态分配计算资源，而非对所有任务一视同仁。

实施步骤:

1. 建立模型路由机制：简单任务（如文本分类）使用小参数量、低成本的模型；复杂任务（如代码生成）使用高推理能力模型。
2. 对于高频重复性查询，实施语义缓存，直接返回之前生成的高质量结果，跳过模型推理过程。
3. 定期评估模型输出的 ROI（投资回报率），移除那些未能显著提升开发效率或用户体验的 LLM 调用点。

注意事项: 不要为了追求使用最先进的模型而忽视成本控制，应根据实际业务场景选择性价比最高的模型。

学习要点

• 根据您提供的主题“LLMs as the new high level language”（大语言模型作为新的高级编程语言），以下是总结出的关键要点：
• 大语言模型正在演变为一种新的高级抽象层，使得自然语言成为比传统代码更高效的通用指令接口。
• 通过语义而非语法进行编程，极大地降低了软件开发的门槛，使非专业用户也能通过对话构建复杂的应用程序。
• 提示工程正在成为新的核心编程技能，开发者需要从编写逻辑代码转向设计能够引导模型生成正确结果的指令。
• 未来的软件架构将转向以模型为中心，开发者通过编排模型调用和工具使用来构建系统，而非编写底层的实现细节。
• 这种范式转变模糊了编写代码与定义需求之间的界限，显著加速了从概念构思到产品原型的开发流程。
• 尽管抽象程度提高，但确保模型输出的确定性和处理潜在的幻觉仍然是该技术栈面临的主要挑战。

常见问题

1: 为什么将大语言模型（LLM）比作“新的高级编程语言”？

1: 为什么将大语言模型（LLM）比作“新的高级编程语言”？

A: 这个类比反映了编程范式的潜在转变。传统的编程语言（如 Python 或 C++）要求开发者编写确定性的逻辑指令来控制计算机。而将 LLM 视为一种新的高级语言，意味着我们正在进入一种“自然语言编程”或“意图编程”的模式。

在这种模式下，开发者不再需要指定具体的算法步骤（例如“如何解析字符串”或“如何遍历数组”），而是用自然语言描述期望的目标或意图（例如“总结这篇文章”或“把这段代码转换成 Go 语言”）。LLM 充当了推理引擎的角色，负责将高层次的意图转化为具体的低级操作。因此，LLM 被视为一种比现有语言抽象级别更高、更接近人类自然表达形式的“新语言”。

2: LLM 作为编程语言与传统编程语言最大的区别是什么？

2: LLM 作为编程语言与传统编程语言最大的区别是什么？

A: 最大的区别在于确定性与概率性。

1. 传统语言是确定性的。对于相同的输入，代码总是产生完全相同的输出。逻辑是显式的，错误通常是语法或逻辑错误，易于调试和复现。
2. LLM是概率性的。它们基于上下文预测下一个 token，因此对于相同的输入，可能会产生略微不同的输出。其内部逻辑是隐式的（隐藏在神经网络的权重中），而不是显式的代码逻辑。

这种区别使得 LLM 在处理模糊性、创造性和非结构化数据（如文本、图像）方面表现出色，但在需要严格精确计算和 100% 可靠性的场景下，仍需要传统代码或外部工具的辅助。

3: 如果 LLM 是新的语言，那么现有的软件工程师会被取代吗？

3: 如果 LLM 是新的语言，那么现有的软件工程师会被取代吗？

A: 这种观点认为工程师的角色会发生转变，而不是消失。就像汇编语言的使用场景随着高级语言的普及而改变一样，软件工程师的工作重心将从“编写语法”转向“设计系统”和“编排意图”。

在这种新范式下，工程师需要掌握的新技能包括：

• 提示词工程：如何精确地描述需求。
• RAG（检索增强生成）：如何给模型提供正确的上下文。
• Agent 编排：如何将复杂的任务拆解并分配给不同的模型或工具。

工程师将更多地扮演系统架构师的角色，利用 LLM 来辅助完成具体的编码或逻辑实现工作。

4: 这种“新语言”存在哪些局限性或风险？

4: 这种“新语言”存在哪些局限性或风险？

A: 虽然这种范式具有潜力，但目前存在显著的技术挑战：

• 幻觉：LLM 可能会生成不准确的信息，这在关键任务系统中是不可接受的。
• 不可复现性：由于输出的随机性，调试和测试变得相对困难。
• 成本与延迟：与直接运行编译好的机器码相比，运行庞大的推理模型在计算成本和响应速度上面临挑战。
• 上下文窗口限制：与传统程序可以处理无限大的数据流不同，LLM 的上下文长度有限，难以直接处理超大规模的代码库或数据。

5: 在实际开发中，如何结合 LLM 和传统代码？

5: 在实际开发中，如何结合 LLM 和传统代码？

A: 目前最主流的模式是混合架构，即 LLM 并不是完全替代传统代码，而是与之协作。这种模式通常被称为“LLM OS”或“Agent 框架”。

具体做法包括：

• 编排层：使用 Python 等传统语言编写控制流。
• 工具调用：当需要精确计算（如数学运算）或获取实时数据时，传统代码调用 API 或计算器，而不是让 LLM 进行猜测。
• 逻辑补全：LLM 负责处理非结构化输入、生成代码片段或提供自然语言接口，而具体的执行仍由确定性代码完成。

简而言之，LLM 成为了软件堆栈中的一个新的逻辑层，负责处理模糊和认知层面的任务，而传统代码依然处理精确和确定性的任务。

6: 这种观点对未来的软件开发工具链有什么影响？

6: 这种观点对未来的软件开发工具链有什么影响？

A: 如果 LLM 被视为新的高级语言，那么未来的工具链将围绕“模型即服务”和“自然语言接口”构建。

• IDE 的演变：集成开发环境（如 Cursor 或 GitHub Copilot）将不再只是文本编辑器，而是变成与模型交互的界面，能够理解整个代码库的语义。
• 新的运行时：我们需要新的标准来管理模型的生命周期、版本控制、提示词管理和推理路由。
• 调试工具：调试器将不仅追踪变量状态，还需要追踪模型的推理过程，分析模型生成特定输出的原因。

7: 普通人（非程序员）是否也能通过这种“新语言”进行编程？

7: 普通人（非程序员）是否也能通过这种“新语言”进行编程？

A: 理论上是的，这也是该观点受到关注的原因之一。通过降低编程的门槛，LLM 允许用户用自然语言描述需求，由模型将其转化为可执行的代码或操作。然而，要构建复杂、健壮且安全的软件系统，仍然需要专业的工程知识来确保逻辑的正确性和

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 在传统的编程中，我们使用 Python 或 C++ 等语言通过逻辑精确控制程序。如果将 LLM 视为一种新的高级语言，请尝试编写一个 Prompt（提示词），让 LLM 完成一个传统的编程任务：将一段包含日期、金额和摘要的非结构化文本转换为 JSON 格式。

要求：

定义明确的输出 Schema。

引用

• 原文链接: https://federicopereiro.com/llm-high
• HN 讨论: https://news.ycombinator.com/item?id=46868928

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

• 分类： 大模型 / AI 工程
• 标签： LLM / 编程语言 / AI 编程 / 代码生成 / 自然语言编程 / 软件工程 / Copilot / 低代码
• 场景： 大语言模型 / AI/ML项目

相关文章

• 大语言模型成为新一代高级编程语言
• 大语言模型成为新型高级编程语言
• LLM成为新一代高级编程语言
• 超越智能体编码：AI 编程助手的演进方向
• AI 编程代理已全面替代我使用的所有开发框架 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。