使用单个 GPT 客户端作为语言运行时（无 API，无代理）

Source: Dev.to

概览

DEV 上大多数 LLM 使用示例都聚焦于以下三类：

• Prompt 技巧
• 工具调用 / 代理
• 后端重型工作流

本文探讨一种不同的思路：如果一个单一的 GPT 客户端能够通过交互设计表现得像一个轻量、可审计的运行时——完全不依赖 API。

问题：聊天是一个糟糕的执行模型

聊天式提示虽然灵活，但它有结构性弱点：

• 输出在不同运行间会变化
• 决策难以审计
• 缺失的输入不会阻止执行

对于以决策为导向的任务（投资检查、风险筛查、止损决策），这是一大问题。问题不在于智能水平。

核心思路：语言层面的运行时

在软件中，运行时强制三件事：

1. 输入契约
2. 执行顺序
3. 输出结构

我没有去构建新框架，而是直接在自然语言中、在 GPT 客户端内部强制这些约束。结果出乎意料地表现得像一个运行时。

步骤 1：协议绑定（运行时头部）

每个会话都以最小的头部开始：

protocol: yuerdsl

把它当作语言层面的执行门。

步骤 2：严格的输入契约（DSL 形式）

用户不再“提问”。
关键规则： 没有完整的模板 → 不输出决策

仅此一步就能消除大多数因幻觉产生的结论。

步骤 3：固定的执行管线

模板完成后，运行时执行固定的管线：

1. 阶段检测
2. 状态编译
3. 结构化风险分析
4. 决策评分（PASS / WATCH / STOP）
5. 行动列表
6. 审计收据

用户看不到任何分支逻辑。

步骤 4：可审计的输出

每次运行以审计收据结束，内容包括：

• 输入摘要
• 关键变量
• 假设前提
• 决策评分
• 行动优先级

这使得运行可比、可重放。相同输入 → 相同结构 → 相同决策评分。

这不是普通的 Prompt 工程吗？

并非如此。Prompt 工程优化的是说什么。这里模型被要求保持一致，而不是聪明。

为什么不使用代理或工具？

代理和工具固然强大，但会增加复杂度：

• 工具的失效模式
• 状态同步问题
• 后端依赖

本实验有意提出一个更窄的问题：在零基础设施、仅靠协议设计的情况下，我们能走多远？ 对于轻量、仅客户端的场景，答案出乎意料地远。

为什么选 GPT（客户端）？

这是工程上的选择，而非品牌偏好。目前，GPT 提供：

• 对长结构化指令的稳定遵守
• 对表单式输入的可靠解析
• 一致的客户端执行环境

该方法本身是模型无关的。

实验展示的内容

LLM 本质上是概率性的。通过严格的契约和拒绝规则，你可以得到：

• 可重复的决策
• 明确的失效模式
• 人类可验证的痕迹

这往往足以满足真实场景的需求。

最后思考

与其问：

“如何让 LLM 更聪明？”

不如问：

“如何让它们更负责任？”

有时，更好的约束胜过更大的模型。

项目 / DSL 架构