用规则工具构建无需自带模型的ChatGPT应用

Ladder 在 11 月 4 日进入 ChatGPT 应用目录，但它的服务端没有接入 AI 模型。ChatGPT 负责提问和对话，背后的工具只按固定规则处理答案。作者想验证的是：一个运行在 AI 助手里的应用，能否把核心业务判断留给普通函数。

这个案例对开发者的价值，在于展示了一种很轻的职责分工。它也留下了两个问题：规则如何识别真正的障碍，以及上架应用目录之后，用户究竟从哪里来。

没有模型，应用怎么完成对话和分析

作者有一套名为 Ladder 的方法：目标在顶端，当前的自己在底端，中间是阻碍行动的障碍，以及不愿直面的恐惧。9 月，作者加入 Astana Hub 运营的 AI'preneurs 加速器，第一次打开 Claude Code。两个月后，这套方法运行在了 ChatGPT 里。

原文将 ChatGPT apps 描述为 MCP 服务器。Ladder 的实现只有一个部署在 Cloudflare Worker 上的端点：https://108psy.com/mcp，对外暴露两个只读工具：

• get_ladder_questions 返回俄语、哈萨克语或英语问题，收集一个可衡量的目标、当前处境、3 到 5 个障碍，以及最多 5 个恐惧。
• analyze_ladder 接收答案，把它们从底部向上排列成台阶，并指出其中真正卡住用户的一步。

ChatGPT 用用户的语言逐个提问，再把用户原话交给工具。工具通过普通函数，为每个台阶划分区域：当前处境、障碍、恐惧或目标。

模型负责对话，规则负责方法内的判断。

作者选择规则的原因很具体：当用户开始输入私人内容时，不希望模型逐渐偏离既定方法。同一份梯子输入，规则应当给出同一份结果。

但文章没有公开分类函数，也没有解释「真正的阻碍」究竟如何选出。我们能看清架构，暂时无法检查它的判断依据。

两道提前返回，把分析范围收窄

Ladder 在正式分析之前，先处理两类情况。

如果答案涉及诊断、症状或药物，工具返回 kind: "health"，停止分析。作者给出的边界是：这个应用处理目标，不处理疾病。

如果文字暗示有人处于危险之中，工具返回 kind: "crisis"，提供求助热线，不生成任何台阶。服务器指令要求 ChatGPT 只展示这条消息。

这种设计把部分输入直接挡在常规流程之外。不过，原文没有说明两类输入的识别方式、覆盖语言、误判情况，也没有提供 ChatGPT 遵循该指令的测试结果。设计意图明确，执行效果还缺证据。

工具同时声明了 readOnlyHint: true、destructiveHint: false、openWorldHint: false。作者称，应用没有注册、数据库和日志，也没有内置价格或追加销售。网站另有较长版本，但 ChatGPT 内的应用可以独立使用。

这些声明与精简实现，让作者觉得审核更容易。文章没有提供审核耗时或其他应用的对照，不能据此推断通过审核的通用捷径。

同一 MCP 地址还能作为 Claude 的自定义连接器使用，服务端不需要知道调用者是哪一个助手。复用的是工具和规则，对话入口交给各自的助手。

我的判断

我认同这里的职责划分。对于已经有明确步骤、输入字段和判断规则的方法，把业务逻辑写成函数，确实更方便检查、复现和维护。相较于把整套方法塞进提示词，这种实现也更容易明确每一步由谁负责。

但「没有模型」只适用于作者自己的服务端。整个体验仍然依赖 ChatGPT 理解用户、组织问题并传递答案。规则能保证相同输入得到相同结果，不能自动保证输入完整、分类准确或结论有效。

尤其是「指出真正的阻碍」，听起来比简单分类更强。作者没有给出评估样本、用户效果数据，也没有和模型分析做对照。因此，这是一种有理由的工程选择，还不是规则优于模型的实验证明。

另外，作者自己也在追问首批用户如何发现应用，并表示进入目录似乎不会自动带来访问。工具能运行、能跨助手复用，与产品能获得用户，是两项独立工作。

能拿来做什么

• 做日常 AI 编程工具时，可以先把输入收集与业务判断拆开。让助手完成追问，把有明确标准的校验、分类和计算放进普通函数。
• 如果准备通过 MCP 暴露已有服务，可以参考 Ladder 的小接口设计：一个工具返回需要收集的信息，另一个接收结构化答案并计算结果，先跑通完整任务。
• 对明确不在服务范围内的输入，先定义返回类型和终止条件。若借鉴 kind: "health"、kind: "crisis"，还需要补上识别测试，不能只照搬返回值。
• 规划应用上线时，把分发渠道单独列出来验证。作者的经历至少提醒我们：进入目录之后，仍然需要回答用户为什么会发现并使用它。