应对 Codex 0.118.0 破坏性更新：Slash Prompt Router 架构解析与实践
目标读者 ：Codex CLI 用户、AI Agent 开发者、依赖自定义工作流的工程师
核心价值 ：了解如何在 Codex 移除自定义 Prompt 支持后，通过 Skill 机制优雅地恢复并增强该功能，掌握 Slash Prompt Router 的底层架构与使用技巧。
阅读时间：8 分钟
面对 Codex 0.118.0 移除 custom prompt 的突发变化，slash-prompt-router不仅是一个临时补丁，更是展示 Agent 生态扩展能力的范例。
Codex 0.118.0 (PR #16115) 移除了 Custom Prompt 支持
引言：当熟悉的工具突然"断轴"
"What should we use instead? Skills?"
这是 Codex 0.118.0 发布后，开发者在社区里发出的真实疑问。在这个版本中（PR #16115），官方团队出于精简核心流程的考虑，正式移除了对发现和罗列 Custom Prompt 的原生协议与核心支持。
对于习惯了通过输入 /handover 进行会话交接，或是通过 /git:commit-push 一键完成代码提交的资深用户来说，这一破坏性更新无疑打断了原有的心流。为了缓解这次合并带来的阵痛，我们基于现有的 Skill 机制，迅速孵化了 slash-prompt-router。它不仅完美"平替"了失去的功能，甚至在匹配精度和执行灵活性上走得更远。
本文将深度解析 slash-prompt-router 的设计哲学、核心架构以及它如何重新定义本地 Prompt 的管理方式。
1. 为什么我们需要一个 "Router"？
在官方移除了原生入口后，本地存放在 ~/.codex/prompts 目录下的宝贵经验库（如架构分析、代码简化、错误排查等专属提示词）变成了一座座"孤岛"。如果没有一个集中的调度员，AI 助手将无法主动发现它们，用户也需要耗费大量时间去手动复制粘贴。
slash-prompt-router 的核心定位，就是充当终端与本地资产之间的智能调度中枢。
它的工作流被精简为三个核心能力：
- 资产盘点 ：动态扫描并解析
~/.codex/prompts/*.md。 - 意图匹配：当用户提出模糊需求时，根据语义推荐最合适的提示词候选列表。
- 加载与执行 ：接管参数解析（如
$ARGUMENTS、$1），并将选定的提示词作为当前任务的最高执行纲领。
优秀的工具链不应该被版本更新所绑架；通过开放的扩展机制，我们能在废墟上建起更稳固的高塔。
2. 深入引擎：意图识别与排序机制
slash-prompt-router 的灵魂在于其背后的 catalog_prompts.py 脚本。它并没有依赖庞大复杂的向量数据库，而是采用了一种轻量且高效的混合文本评分策略，确保在本地极速运行。
文本特征提取
为了兼顾中英文查询，脚本内部实现了双轨提取机制：
- 英文体系 ：通过正则表达式
[a-z0-9][a-z0-9:-]*提取完整的技术词汇（Tokens），如git、commit。 - 中文体系 ：采用 CJK 字符检测与双字 N-Gram（Bi-gram）分块策略。例如"分析架构"会被切分为
分析、析架、架构，这在不引入外部中文分词库的前提下，最大化了匹配的召回率。
评分策略
在获取了 Query 的特征集合后，引擎会对每个本地提示词进行多维度评分：
- 命名命中 （+30分）：如果用户的查询直接命中了提示词的文件名或 Slash 指令名称（如查询包含
handover）。 - 标题命中（+15分）：命中提示词内部定义的元信息。
- 描述命中（+5分）：命中详细描述信息。
这种粗排（Coarse Recall）机制能够在几百毫秒内从几十个 Prompt 中筛选出 Top 5 的候选者，随后交由核心决策流做出最终的精细选择。
3. 动态参数绑定：让 Prompt 活起来
静态的 Prompt 是死板的，只有结合当前任务上下文，它才能成为生产力工具。slash-prompt-router 实现了一套强大的参数绑定（Argument Resolution）协议。
当用户选中某个 Prompt 并执行时，Router 会拦截执行流，进行参数替换：
$ARGUMENTS：这是最常用的占位符。Router 会将用户在对话框中输入的整个任务描述，作为一个完整的字符串注入其中。这非常适合/ui-engineer或/code-simplifier这类需要大段背景信息的工作流。- 位置参数
$1到$9：对于特定场景（如/kill-port 3000），它会自动映射第一个参数3000。如果所需参数缺失，Agent 会主动询问用户补齐。
通过这种方式，Router 不仅只是"读取"文件，它实际上是将 Markdown 编译成了动态的执行计划。
4. 最佳实践：如何将 Router 融入日常
如何优雅地使用这个新 Skill？以下是几个典型的对话范式：
场景一：模糊探索
用户 ："我想梳理前端的 API 调用链，推荐几个合适的 prompt"
Router 行为 ：扫描目录，识别到/api-flow-analyzer和/analyze-complexity，由于前者的描述高度匹配，作为首选推荐，并列出所需参数。
场景二：精确制导
用户 ："直接用
/git:commit-push帮我把刚才的修改提交了"
Router 行为 ：直接跳过推荐环节，加载该 Prompt，将"把刚才的修改提交了"解析为$ARGUMENTS注入，随后完全接管后续的提交流程。
场景三：无缝交接
用户 ："/handover"
Router 行为 ：读取handover.md，执行内部定义的生成交接文档的指令，最终在根目录输出HANDOVER.md。
总结：从内置功能到生态扩展的范式转移
最新版本中移除 Custom Prompt 乍看是一次功能的"倒退"，但从长远架构来看，这是一次成功的减负。官方核心代码库不再需要维护日益臃肿的 Prompt 发现逻辑，而是将其下放给了更灵活的 Skill 系统。
slash-prompt-router 作为这一真空期的完美填补者，不仅证明了基于文件的扩展机制的强大生命力，也向我们展示了 Agentic Engineer 的破局思路：当系统关上一扇门时，我们只需编写一个自动开门的脚本。
立即在你的环境中部署 slash-prompt-router，重新夺回你的工作流主导权吧！
参考
- Codex PR #16115: Remove remaining custom prompt support
- slash-prompt-router skill