当我在 Prompt 里写 if-else：自然语言正在成为新的“胶水语言”

写在前面

你好，我是 Evan。2025 年，我第一次在 Agent 项目里用自然语言写了一段“伪代码”：

text IF 用户意图是“查询物流” AND 未提供订单号： 回复“请提供您的订单号” IF 意图是“查询物流” AND 已有订单号： 调用 order_query_api 获取物流状态

同事看到后笑我：“你这是写 Prompt 还是写代码？”

我当时没回答上来。直到后来我才意识到——这既不是传统的 Prompt，也不是传统的代码，而是一种正在崛起的新物种：Prompt 编程。

一、什么是 Prompt 编程？——当自然语言变成可执行逻辑

2023 年，你写 Prompt 是为了让 AI 帮你写诗、写周报，那时候我们叫它“咒语”。2025 年，你写 Prompt 是为了让 Dify、Coze 里的智能体去调用 API、查数据库、执行复杂任务——这时候，Prompt 已经不再是“提示”，而是自然语言代码。

所谓Prompt 编程，就是用结构化的自然语言描述业务逻辑、控制流和工具调度，让大语言模型（LLM）按照你设定的“伪代码”去执行任务。它介于“写代码”和“写需求”之间——你不写具体的编程语言语法，但你在写逻辑。

Andrej Karpathy 在 2025 年提出的Vibe Coding概念，本质上就是 Prompt 编程的一种形态——通过自然语言与 AI 交互生成代码，让开发者从“编码者”变成“需求引导者”。

而在我自己的 Agent 项目中，Prompt 编程的体验更接近于用一种新的“胶水语言”把各种工具、API 和业务规则粘在一起。你不用写 Java 或 Python 来编排它们，而是用自然语言来描述“什么时候调用什么、怎么处理结果”。

二、Prompt 编程的三种典型实践

2.1 用自然语言生成业务规则

传统开发中，业务规则通常用规则引擎（如 Drools）或硬编码的 if-else 来实现。而在 Prompt 编程中，你可以直接用自然语言描述规则，让 LLM 来执行判断。

一个典型的例子是电商客服 Agent 的提示词：

text Role：你是京东自营旗舰店的资深售后专家 技能： 1. 订单查询工具：当用户提供订单号时，必须优先调用 order_query_api 2. 知识库检索：当用户询问产品参数时，查询 product_knowledge_base SOP（标准作业程序）： 1. 意图识别：分析用户是想“咨询商品”、“查询物流”还是“投诉建议” 2. 信息核验： IF 意图是“查询物流” AND 用户未提供订单号 → 回复“请提供您的订单号” IF 意图是“查询物流” AND 已有订单号 → 调用 order_query_api IF 意图是“投诉建议” → 调用 ticket_create_api 创建工单

这里的IF...AND...→结构，本质上就是业务规则的声明式描述。你不需要写 Java 的if-else，不需要配置 Drools 的规则文件，只需要用自然语言把逻辑讲清楚。

但局限也很明显：复杂规则（如多层嵌套、多条件组合、数值计算）用自然语言描述时，LLM 容易遗漏边界条件或产生歧义。研究也表明，自然语言的模糊性是导致 LLM 生成失败的主要原因之一——问题往往出在 Prompt信息不足，而不是信息表达方式有问题。对于计算密集型的规则，传统代码仍然是更可靠的选择。

2.2 用自然语言生成 SQL（NL2SQL）

这是 Prompt 编程在生产环境中落地最成熟的场景之一。NL2SQL（Natural Language to SQL）技术让非技术用户也能通过自然语言提问来查询数据库。

一个真实的案例：Zenn 团队实现了一个功能，让运营人员用自然语言查询数据库。他们发现 Claude Code 能够通过读取 Rails 项目的schema.rb文件（数据库结构定义）来生成正确的 SQL。最终方案使用了 Gemini SDK，并定义了严格的响应格式——包括生成的 SQL、解释、置信度和警告。

Prompt 中包含了关键的安全约束：

text 安全规则： - 只生成 SELECT 语句 - 绝不使用 INSERT、UPDATE、DELETE、DROP - 不访问系统表（pg_*、information_schema） - 限制结果最多 1000 行 - 尽可能使用参数化查询

这正是 Prompt 编程的核心能力：用自然语言描述“要什么”，同时用约束描述“不能做什么”。

开源的 NL2SQL 项目（如 Tele-AI/nl2sql）已经将这一能力封装成了完整的后端服务，支持 OpenAI、DeepSeek、Qwen 等多种大模型。

局限：NL2SQL 的准确性高度依赖数据库 Schema 的完整性和 Prompt 的质量。复杂的多表 JOIN、子查询、窗口函数等场景，LLM 生成的 SQL 仍然可能出错。Zenn 团队也承认，这“只是第一步”，理想状态是未来 AI Agent 能自主解决问题。

2.3 用自然语言生成正则表达式

正则表达式被称为程序员的“只写语言”——写的时候觉得自己是神，一周后再看，连自己都不知道这堆符号在干什么。

Prompt 编程正在改变这一点。通过设计结构化的 Prompt，你可以让 AI 不仅生成正则表达式，还提供逐字解析和性能优化建议。

一个典型的 Prompt 框架：

text # 角色定义 你是一位资深的正则表达式专家，精通 JavaScript、Python、Java、PCRE 等引擎。 # 任务描述 请根据用户的文本匹配需求，生成对应的正则表达式，并提供详细的解释和使用示例。 # 输入信息 - 匹配目标：[如：邮箱地址、手机号码、日期格式] - 编程语言/环境：[如：JavaScript、Python] - 示例文本：[需要处理的示例文本] # 输出要求 1. 正则表达式：完整的模式 2. 逐字解析：每个符号的含义 3. 使用示例：在指定语言中的代码 4. 测试用例：匹配成功和失败的案例 5. 优化建议：性能和可读性改进

局限：正则表达式的生成是 Prompt 编程中“看起来很美”的场景，但实际使用中仍面临挑战。复杂正则的生成需要多轮迭代优化，而且 LLM 生成的正则表达式可能存在性能隐患（如灾难性回溯）。Brown 大学的研究团队开发的 PICK:Regex 工具，会让 LLM 一次生成多个候选表达式来降低风险——这也从侧面说明，单次生成的可靠性仍然不足。

三、Prompt 编程 = 新的“胶水语言”？

“胶水语言”原本指用来连接不同系统、组件和库的编程语言（如 Python 常被这样称呼）。Prompt 编程正在扮演类似的角色——但它“粘合”的不是代码库，而是自然语言意图和可执行动作之间的鸿沟。

传统的胶水语言需要你写代码来连接 A 和 B。Prompt 编程只需要你用自然语言描述“当 X 发生时，做 Y”——LLM 负责把这句话翻译成实际的工具调用。

但它和传统胶水语言有本质区别：

Prompt 编程最大的问题不是“能不能做”，而是“能不能确定地做”。传统代码的每一次执行都是确定的，而 LLM 的每一次推理都可能产生不同的结果。

四、Prompt 编程的根本局限

4.1 自然语言的“模糊性”困境

自然语言天生具有歧义和模糊性。一个需求用中文描述可能有 10 种理解方式，而 LLM 可能会选中你没想到的第 11 种。研究表明，LLM 在面对模糊的任务描述时，往往会“坍缩”到单一的错误解释上，而不是产生多个合理的实现方案。这意味着，模糊的 Prompt 不是让 AI 多给你几个选项，而是让 AI 坚定地走向一个错误的方向。

4.2 “过程式 Prompt”的维护噩梦

当前主流的 Prompt 写法——把角色、任务、规则、格式全部塞进一个巨大的 System Prompt 里——本质上就是用自然语言写的过程式代码。

这种写法的局限在复杂 Agent 场景下暴露无遗：

• 没有状态管理：Agent 的“状态”无处存储，只能每轮对话用大白话提醒

• 高耦合，难维护：所有逻辑搅在一起，改一处可能崩全局（“提示词脆性”）

• 扩展性差：加一个新功能就要往几万字的 Prompt 里继续堆内容

4.3 “提示词即知识产权”的风险

随着 Prompt 越来越复杂、越来越贴近核心业务逻辑，提示词正在成为企业新的“知识产权容器”——里面浓缩了领域知识、商业机密和关键流程。这意味着：

• Prompt 的泄露风险比代码泄露更高（因为它是自然语言，更容易被复制和理解）

• Prompt 的版本管理和权限控制成为新的治理难题

• 依赖第三方 LLM 服务时，你的业务逻辑可能被模型提供商间接获取

五、Prompt 编程的“正确姿势”

经历了多次踩坑后，我总结了几条实践经验：

5.1 结构化优于散文

不要写“小作文”式的 Prompt。用 Markdown 格式组织成模块：角色定义、技能/工具、SOP、约束条件、输出示例。这就像写代码要有清晰的函数划分一样。

5.2 用“伪代码”代替“描述”

与其说“你要先判断用户有没有给订单号，如果给了就查物流，没给就提醒他”，不如直接写：

text IF 有订单号 → 调用 order_query ELSE → 回复“请提供订单号”

这让 LLM 更容易理解执行路径。

5.3 为不确定性留“后门”

永远在 Prompt 中加入兜底逻辑：

text IF 无法确定用户意图 → 回复“我没理解您的问题，请您再描述一下” IF 工具调用失败 → 重试最多 3 次，仍失败则转人工

5.4 把“代码思维”带进 Prompt

Prompt 编程不是让你放弃编程思维，而是让你用编程思维来写自然语言。状态管理、异常处理、边界条件——这些你在写 Java 时思考的东西，在写 Prompt 时一样都不能少。

六、总结：Prompt 编程不是终点，是起点

Prompt 编程不会取代传统编程，就像胶水语言不会取代系统语言一样。它解决的是不同的问题——传统编程解决“如何精确执行”，Prompt 编程解决“如何用自然语言描述意图并让机器理解”。

但我们需要清醒地认识到：Prompt 编程的“胶水”本质，决定了它只能粘合，不能承重。对于核心业务逻辑、高精度计算、安全敏感的代码，传统编程仍然是不可替代的。

而 Prompt 编程的真正价值，或许不在于“替代”什么，而在于让更多人能够参与到软件构建的过程中来——业务人员可以直接描述规则，产品经理可以直接定义流程，开发者则可以花更多时间在架构和验证上。

未来已来，只是分布不均。2025 年，Prompt 编程还是少数人的探索；2026 年，它正在成为每个后端开发者工具箱里的新成员——不是取代你写 Java，而是给你多了一把解决问题的钥匙。