在终端里养一个提示词库：把重复杂活交给 AI

提示词库不是模板坟场，按杂活归档才有复用价值

很多人第一次搭提示词库，都会犯同一个错：把随手写过的片段全塞进一个文件，三个月后它变成模板坟场，自己都不想翻。库不在大，在于每一条都能被下一次杂活直接命中。

真正有效的分类维度不是模型也不是项目，而是杂活本身。提交说明、变更日志、代码评审、测试补写、日志摘要、依赖升级、重构建议、文档补齐，这些每周都会重来一次的事情才是提示词库的骨架，仓库名、语言、风格都应该作为变量后填。

判断一条提示词该不该入库，可以用三道筛子，任何一道没过就先留在草稿区，别急着进主目录。

• 这条提示词在过去一个月里被我重复敲过至少三次以上。
• 它的输出格式能被脚本或者下一条提示词直接消费下去。
• 换一个仓库或语言使用时，只需要替换变量而不用重写正文。

参数化让一条评审提示词吃下十个仓库

另一个常见迷信是提示词必须一次写到完美。实际天天写代码的人都知道，最花时间的从来不是措辞，而是每次都要重贴一遍上下文。把仓库名、语言版本、风格约定、改动范围抽成变量，一条正文就能覆盖十个仓库。

我自己的评审提示词固定四段：角色设定、输入清单、输出格式、禁止事项。输出格式规定成紧凑列表，逐条给出文件位置、风险等级和修复建议；禁止事项写明不要复述代码、不要给通用建议、不要动无关文件。换项目时只改第二段，正文三个月不用动。

变量用简单的占位写法维护，配合终端里的替换命令在调用前把值灌进去，提示词正文就始终保持干净，也不会有人半夜把某家公司的仓库名留在公共库里。

• 占位符命名要跟你的口头习惯一致，读起来像一句待填的自然语言。
• 必填变量缺失时让脚本直接报错，不要让模型替你猜一个默认值。
• 把输出格式写进提示词，比事后用正则清洗省掉一半返工时间。

长提示词更贵这笔账，缓存读写已经翻过来了

第三个神话是提示词越长越烧钱，于是大家把指令压缩成几个词，结果模型自由发挥，返工两轮反而更贵。现代计费不看感觉，看真实 token：在 Fluxo 上账单按真实 token 计入，缓存的读与写也如实入账，没有月费，也没有把调用拆成套餐的把戏。

实际工作里，稳定的前缀（角色、规范、输出格式）放在最前面，重复调用时缓存命中会带来明显的延迟和成本改善，你只需要盯住缓存写入那一次的花费。一个 key 加一个 base URL https://api.fluxorelay.com 就能接入 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等模型，换模型不用改客户端，账目也全在一条线上。

提示词库的价值也在这一刻显现：越稳定的指令越容易被缓存命中，而每次现敲的碎片化提示词，缓存几乎帮不上忙。

• 把稳定的规则段放在提示词最前面，易变的项目信息放在末尾位置。
• 每周看一次缓存写入与读取的比例，比例异常往往意味着前缀在抖动。

文件就是提示词库，fzf 和 ripgrep 比任何工具都顺手

第四个误解是必须有专门的软件才能管理提示词。其实文件系统已经是很称职的数据库：家目录下一个 prompts 文件夹，每条一个 markdown 文件，文件名用动词开头，比如 review-pr、write-changelog、summarize-logs，正文就是提示词本身。

配合 fzf 模糊挑选、ripgrep 全文检索，再加一行别名把选中的文件送进剪贴板或者直接管道喂给客户端，取用一条提示词的成本从三十秒降到两秒。Fluxo 在 Claude Code、Codex、Gemini CLI 里都能直接用，任何 OpenAI SDK 写的脚本改一个 base URL 也能接上，所以库的形态完全由你自己决定。

我的目录里还有 drafts 和 retired 两个文件夹，写砸的进草稿，过期的退役，主目录永远只放今天就能用的东西，检索结果里不会混进垃圾。

• 文件名用动词加对象命名，模糊搜索时靠肌肉记忆就能一次选中。
• 提示词正文里保留一行修改日期，方便判断这条指令是否已经过期。
• 把常用组合写成 shell 函数，避免每次手拼一长串容易出错的参数。

分流模型：高频杂活交给快的，判断力留给稳的

第五个神话是最贵的模型一定最适合。日常杂活里，日志摘要、提交说明、注释清理这类任务结构清晰，快模型足够，没必要用旗舰模型刷存在感；而架构评审、边界条件推演这种需要判断力的事情，才值得换更强的档位。

我的默认分流是：DeepSeek V4 Flash 处理摘要和格式化这类高频杂活，Claude Sonnet 5.5 负责评审与重构建议。两者走同一个 key 和同一个 base URL，切换只改一个模型名，账单一起结算，按真实 token 计费也意味着不必再为月底闲置的订阅付费。

把分流规则写进提示词库的元信息里，同事接手脚本时一眼就知道该选哪个档位。你邀请来的朋友付费时，你还能拿到一份推荐分成，省下来的成本刚好留给咖啡。

• 为每个提示词条目标注推荐模型档位和触发场景，避免每次都随手乱选。
• 把升级到更强模型的条件写清楚，比如出现跨层多文件改动时才切换。

每周十分钟除草，提示词库会腐烂也会生长

最后一个神话是提示词写好就不用再管。代码会腐烂，提示词也会：模型升级后原本有效的约束可能失效，项目风格变了，输出格式过时了。我固定每周五收工前花十分钟，把这一周用过三次以上的提示词翻出来，对照真实输出改一版。

除草只做三件事：删掉再也没用过的条目，补上缺漏的变量，把踩过的坑写进禁止事项。改动直接进版本库，回滚成本几乎为零。日积月累，这套库比任何文档都更贴近你真实的工作方式，也更诚实。

如果你手边还没有顺手的 API 入口，不妨注册一个 Fluxo 账号，把第一条提示词搬进你的库里跑一次真实调用。遇到具体问题，登录后到联系页留个言就好，把提示词、模型名和期望输出一起贴上，排查起来最快。