写在前面你好我是 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 用自然语言生成 SQLNL2SQL这是 Prompt 编程在生产环境中落地最成熟的场景之一。NL2SQLNatural 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 负责把这句话翻译成实际的工具调用。但它和传统胶水语言有本质区别维度传统胶水语言如 PythonPrompt 编程执行方式编译/解释执行确定性LLM 推理概率性调试难度有明确的堆栈和断点黑盒依赖 Prompt 调优可测试性单元测试、集成测试成熟缺乏标准化测试框架性能可预测依赖模型响应时间不稳定确定性输入相同输出相同输入相同输出可能不同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 把“代码思维”带进 PromptPrompt 编程不是让你放弃编程思维而是让你用编程思维来写自然语言。状态管理、异常处理、边界条件——这些你在写 Java 时思考的东西在写 Prompt 时一样都不能少。六、总结Prompt 编程不是终点是起点Prompt 编程不会取代传统编程就像胶水语言不会取代系统语言一样。它解决的是不同的问题——传统编程解决“如何精确执行”Prompt 编程解决“如何用自然语言描述意图并让机器理解”。但我们需要清醒地认识到Prompt 编程的“胶水”本质决定了它只能粘合不能承重。对于核心业务逻辑、高精度计算、安全敏感的代码传统编程仍然是不可替代的。而 Prompt 编程的真正价值或许不在于“替代”什么而在于让更多人能够参与到软件构建的过程中来——业务人员可以直接描述规则产品经理可以直接定义流程开发者则可以花更多时间在架构和验证上。未来已来只是分布不均。2025 年Prompt 编程还是少数人的探索2026 年它正在成为每个后端开发者工具箱里的新成员——不是取代你写 Java而是给你多了一把解决问题的钥匙。