GPT88 / API Docs
返回博客

老爷爷 laoyeye Skill：让 AI 按你的处境挑选合适提示语

AI Agent2026-10-21约 12 分钟laoyeye老爷爷 Skill提示语管理Prompt 路由Agent SkillsGPT88

卡尔（X 账号 @aiwarts）在 2026 年 10 月 20 日发布长文，介绍了开源项目「戒指老爷爷」laoyeye。这个项目试图解决一个常见问题：收藏了很多好用的提示语，真正需要时却想不起该用哪一条。

它把提示语和 Skill 收进一个路由。用户描述自己卡在哪里，由 Agent 先判断场景，再推荐适合的提示语或 Skill；用户不需要记住二十多条条目的名字。项目的重点因此不是再造一个“万能 Prompt”，而是降低选择与调用的成本。

卡尔介绍开源 laoyeye 提示语路由 Skill

提示语库为什么容易变成收藏夹

把提示语放进备忘录，解决的是存放与搜索；把常用规则写进 AGENTS.md 或其他 Agent 指令文件，解决的是默认上下文。但两种方式都不能保证人在遇到具体问题时会想起那条合适的提示语。每次手动查找、复制和删改，也会打断原本的对话。

laoyeye 采用类似 ask-matt 的路由形态：用户用自然语言描述当前处境，Agent 从一组有明确用途的提示语中匹配，并解释为什么选它、相邻选项有什么区别。提示语从“需要人记住的目录”变成“由 Agent 按场景检索的工具箱”。

这一设计并不意味着每件事都要套一个 Skill。仓库自己的路由规则要求先判断问题是否匹配；信息不足时先追问，找不到合适项时承认覆盖不到。它还列出复盘失败、多项排序、表达写作和急性情绪等不应硬塞进现有条目的情形。对话路由有“拒绝匹配”的能力，是它能否保持可信的关键。

六类场景与一条路由

项目把思考类提示语分到六类：问清问题、学习、解决问题、决策、动手和认识自己。每类解决不同阶段的需要：

场景适合的问题示例条目
问清问题目标还模糊，或想先梳理真实问题苏格拉底式提问、拷问、乔哈里视窗
学习想理解概念、学习领域或核验说法双层解释、寓言故事、横纵分析、事实核查
解决问题想拆解机制、借用其他领域做法或检查失败路径第一性原理、专家会诊、跨领域借解、逆向法
决策两个选项都有理由，或想用小实验减少不确定性双向钢人论证、最小实验
动手需要把目标写成 Agent 任务，或对齐项目文档领导、洁癖
认识自己需要较长的自我探索对话挖掘隐藏天赋、人生设计术

这些不是一套必须依次执行的流程。路由文件会先根据用户表达识别可观测信号，再决定是否追问、选哪一个条目，以及做完后如何接力。例如，用户还没想清自己真正的问题时，应先用提问澄清；已经有两个清楚选项却难以抉择，才适合比较两边论据。仓库还特别标注了少数需要用户主动触发的长对话条目，避免 Agent 擅自开启。

截至本文整理时，X 长文称收录 25 条思考提示语；仓库 README 也按 25 件列出六类条目，但 GitHub 仓库简介仍写着 21 件。仓库内容会持续变化，这些数量应以阅读时的 README、目录和版本为准，不能只凭简介作判断。

把原文保留下来，而不是“工程化改写”

laoyeye 的一个明确原则是：提示语原文尽量逐字保留。长文用苏格拉底式提问作例子：如果将“每次只问一个问题，根据我的回答决定下一问，不要提前给我一整套问卷”压缩成“逐步提问”，模型可能一次性列出多道问题，原本控制对话节奏的约束就消失了。

仓库把提示语原文放在 sources/prompts.md，从其他项目收录的 Skill 放在 vendor/，并通过同步和校验脚本检查内容漂移。被收录的上游 Skill 会使用来源前缀，README 说明这样能避免与上游安装项重名。校验脚本和锁定来源让维护者可以核对复制内容是否被意外改写；它们并不能自动证明每份内容都适合每位用户，也不能替代各自的许可与署名要求。

仓库 README 标注仓库代码与文档使用 MIT，但同时说明被收录的 Skill 仍按各自来源许可处理，提示语原文著作权属于各自作者。引用或复用时应分别查看仓库中的许可文件、上游来源及署名说明，不能把仓库整体的 MIT 说明推及所有收录内容。

安装后怎么使用

仓库给出的安装命令是：

npx skills@latest add LearnPrompt/laoyeye

安装前先检查该命令的当前说明和目标 Agent 的 Skills 支持方式。安装完成后，可以按仓库文档使用 /laoyeye 并描述具体处境，例如“我不确定这个功能需求该怎么拆”“这两个方案各有利弊，不知道怎么选”。路由会尝试推荐一条对应方法；不同 Agent 对命令、自动发现和显式调用的处理可能不同，应以客户端自身的 Skill 机制和项目说明为准。

特别注意，仓库中名为 kaz-leader、kaz-neat-freak 的条目会读取代码库或修改文件。路由说明要求在调用这类真实执行型 Skill 前增加确认。使用任何第三方 Agent Skill 前，都应先阅读其说明和脚本，确认其访问范围、写入行为与依赖来源。

与 GPT88 大模型 API 配合的边界

GPT88 与 laoyeye 处于两层：GPT88 提供可由兼容客户端调用的大模型 API；laoyeye 是安装在 Agent 客户端中的路由提示语及 Skill 文件。若你使用的 Agent 客户端支持 Skills，并允许接入 OpenAI 兼容 API，可以让该客户端通过 GPT88 调用当前可用模型，同时在客户端侧加载 laoyeye。只配置 GPT88 API Key 并不会自动安装 laoyeye；只安装 Skill 也不会自动配置模型服务。

接入时可先通过GPT88 模型列表 API确认当前 API Key 可用的模型，再按Chat Completions API配置客户端 Base URL 与密钥。模型目录、客户端 Skills 行为和仓库内容都可能变化，应分别按当前官方说明核对。不要将 API Key 写入公开 Skill 文件、仓库或提示语内容。

这套做法适合哪些人

  • 手里有一批经常复用的提示语，但不想靠背名字和手动翻找的人。
  • 已经使用支持 Agent Skills 的编码或通用 Agent，希望按场景调用专家提示语的人。
  • 维护 Prompt/Skill 集合，需要追溯来源、避免改写漂移或处理上游更新的人。

如果你只有两三条提示语，或当前客户端不支持 Skill，直接保存短提示语并手动使用通常更简单。路由有维护成本：上游内容需要同步，条目要能准确区分，说明也要持续更新。条目数量越多，越需要完善“不匹配”边界和路由验证，而不是只继续堆条目。

常见问题

laoyeye 是一个模型吗？

不是。它是一个 Agent Skill 仓库，包含路由规则、可调用的提示语和收录的 Skill。它需要在支持相应 Skills 机制的 Agent 客户端中使用。

laoyeye 会把任何问题都路由到提示语吗？

仓库的路由说明要求允许“不匹配”：问题不在覆盖范围、用户只是闲聊或信息不足时，不应为了调用 Skill 而强行选择一条。

GPT88 能直接安装或运行这个 Skill 吗？

GPT88 API 是模型服务接口；Skill 的安装与调用由 Agent 客户端负责。客户端需要同时具备 GPT88 接入配置和对应的 Skills 能力。实际支持情况取决于具体客户端与模型配置。

为什么不把提示语统一改写成更标准的 Agent 流程？

提示语可能依赖具体措辞、提问顺序和约束。改写可能改变行为。laoyeye 选择通过路由描述使用场景、尽量保留条目正文；这是一种维护策略，并不表示任何提示语原文都无需审核或永远适用。

来源与延伸阅读

相关指南

GPT88 Skill 完整指南：作用、安装使用方法与适用场景