放弃聊天机器人：Prompt导向编程(POP)架构实践

如果你只是往 SaaS 产品上接一个对话式 AI 小组件就觉得完事了，那做的只是个玩具，不是工具。我们最初尝试用标准 LLM 集成直接把用户意图映射到后端数据库操作，结果产生的幻觉 JSON 和不一致的数据结构不断打破我们的应用状态。我们很快意识到，对话式的、随意的 prompt 方式与确定性软件架构根本上是互不兼容的。

要构建一个技术团队真正能依赖的 AI 流水线，我们必须停止把语言模型当聊天机器人看待，而是把它们当作内部编译引擎来对待。我们将整个后端切换到一种叫做 Prompt-Oriented Programming（POP） 的方法论。

什么是 Prompt-Oriented Programming？

Prompt-Oriented Programming（POP）是一种架构规范——将自然语言 prompt 视为严格的、版本受控的后端代码。它依赖严格的边界条件和硬编码的 schema 约束，将自然语言直接映射到确定性的数据库执行。

在标准开发中，你不会部署一个混乱的、未经测试的脚本来处理数据库变更。然而，大多数开发者在将开放式用户 prompt 直接传给 LLM 时，做的正是这种事。

在 POP 架构中，prompt 遵循与应用逻辑同样严格的标准：

• 版本控制：prompt 存在于代码库中，需要同行评审。
• Schema 强制：LLM 在结构上被阻止返回对话式文本；它只能返回严格类型化的数据对象。
• 上下文隔离：负向约束被硬编码，以防止作用域漂移和幻觉。

问题：PRD 到 Kanban 的流水线

每个工程团队都会遇到一个行政瓶颈——架构规格和产品需求文档（PRD）必须被手动分解为可操作的 Kanban 工单。这是一个缓慢的、有损耗的过程，关键约束在手动录入时经常被遗忘。

当我们为自己的零摩擦项目追踪工具 Task Lemon 构建后端时，我们想要完全自动化这一流程。目标是上传一份原始 Markdown 规格文档，然后立即用结构化的 sprint backlog 填充数据库。

使用标准聊天 prompt，API 会返回差异极大的工单尺寸、编造规格中没有的功能，或者彻底破坏我们的 JSON 解析器。我们需要强制执行 POP 约束。

开发者的转向：硬编码约束

为了解决这个问题，我们构建了 Taurus AI，一个由 Gemini API 驱动的集成提取引擎。Taurus 不让 Gemini 与用户"对话"，而是作为一个安静的、后端的数据解析器运行，被严格的 POP 规则包裹。

真正的突破来自我们停止让 AI"创建任务"，而是强制它填充预定义的 JSON schema。

以下是我们传递给 API 的 schema 约束简化版——与用户的 Markdown 文档一起传递。这强制 LLM 放弃对话式输出，充当确定性的数据映射器：

{
  "system_instruction": "You are a backend compilation engine. You do not converse. You strictly extract actionable software engineering tasks from the provided Markdown specification. You must return a JSON array of objects strictly matching the schema below. Do not invent requirements.",
  "schema_definition": {
    "type": "array",
    "items": {
      "type": "object",
      "properties": {
        "task_title": {
          "type": "string",
          "description": "A concise, actionable title starting with a verb."
        },
        "technical_criteria": {
          "type": "array",
          "items": { "type": "string" },
          "description": "Specific architectural constraints extracted from the text."
        },
        "estimated_complexity": {
          "type": "string",
          "enum": ["low", "medium", "high", "critical"]
        }
      },
      "required": ["task_title", "technical_criteria", "estimated_complexity"]
    }
  }
}

结果：意图到执行

通过将这些严格的 POP 约束包裹 LLM，输出变得完全确定性。

当一份 10 页的规格文档被输入 Taurus 时，API 返回一个完美格式化的 JSON 数组。我们的后端针对数据库 schema 验证该数组，然后在毫秒级执行批量创建。在不到 15 秒内，一份原始 Markdown 文档被翻译成一个完全映射好的、可分配的 Kanban 面板，全程没有一次手动录入。

未来是意图驱动的

非结构化聊天机器人的时代正在结束。如果我们想让 AI 执行复杂的软件工作流，架构本身必须演进。通过将自然语言视为正式的编程层并强制执行严格的边界，我们终于可以消除运营摩擦，回到写代码的状态。

我很想知道你的团队在自己的后端中是如何处理 prompt 约束和 JSON 强制的？是依赖 LLM 原生的 JSON 模式，还是构建了自定义中间件来验证输出？欢迎在评论区留言。