Fabric 实测：用管道把 AI 提示词接进终端工作流

Fabric 是一个开源的命令行AI 工具，把整理好的提示词做成可以直接调用的命令，输入走标准输入，输出走标准输出。系统日志、代码 diff、剪贴板内容都能直接接到模型上，结果还能继续用管道传给下一个命令。它不替代聊天客户端，补的是「把 AI 嵌进脚本和日常命令」这一段。

它解决什么问题：提示词也需要版本管理

项目作者 Daniel Miessler 的判断是：模型能力已经不缺，缺的是把这些能力接进日常工作流的方式。散落在各个聊天窗口里的提示词，换个任务就要重新组织一遍，前后两版差别也很难比较。

Fabric 的做法是把每条提示词存成一个 Markdown 文件，用任务名当命令名调用。模式目录可以交给 git 管理，改动前后直接看 diff，团队里也能分发给同事。

项目采用 MIT 协议，写作时 GitHub 仓库 约有 4.4 万星标、4,335 个 fork。当前发布版本为 v1.4.557，发布于 2026 年 10 月 29 日，主干提交频率较高，功能项还在持续增加。

安装与首次配置：先把一条命令跑通

它已经被 Go 重写，装起来比早年 Python 版省事。下面几种方式任选一种，装完都需要跑一次 setup。没有包管理器的环境，也可以直接到 发布页 下载对应平台的压缩包。

• Windows（winget）：winget install danielmiessler.Fabric
• Windows（Scoop）：scoop install fabric-ai
• macOS（Homebrew）：brew install fabric-ai
• 从源码：go install github.com/danielmiessler/fabric/cmd/fabric@latest
• Docker：挂载配置目录后运行 kayvan/fabric 镜像，适合不想在本机装 Go 的环境

用 Homebrew 或 AUR 安装时，命令名会变成 fabric-ai，需要在 shell 配置里加一条别名，否则直接敲 fabric 会提示找不到命令。

配置模型与密钥

执行 fabric --setup，交互式地问你要接哪家模型、密钥填什么。配置和模式都存在 ~/.config/fabric 目录下，模式文件在 patterns 子目录里，可以直接打开看内容。

官方列出的接入方式里，原生支持的有 OpenAI、Anthropic、Gemini、Ollama、LM Studio、Azure OpenAI、Bedrock、Vertex AI 等，另有 DeepSeek、Groq、OpenRouter、SiliconCloud、LiteLLM 等一批兼容 OpenAI 接口的渠道。想先看清单可以跑 fabric --listvendors。

按模式指定模型也支持，用环境变量把某个模式固定到某家渠道与模型，避免每次敲 -m 参数。

管道用法：几个能直接抄的组合

Fabric 读标准输入，任何能打印文本的命令都能接上来。下面这些组合我按当前版本的参数名核对过。

从剪贴板、日志和 diff 出发

• 剪贴板总结：macOS 用 pbpaste，Windows 用 Get-Clipboard，Linux 用 xclip 输出，再接 fabric --pattern summarize
• 流式提取观点：在命令后加 --stream，输出边生成边打印，长文本不用干等
• 看日志：grep -i error 日志文件 | fabric -p analyze_logs，先筛出可疑行再看模型归纳
• 写提交信息：git diff | fabric -p create_git_diff_commit
• 读网页：fabric -u 网址 -p analyze_claims，它先用 Jina 把页面转成 Markdown 再送模型
• 指定输出语言：加 -g zh，中文任务不必每次在提示词里强调

也能串联。前一条模式的输出直接喂给下一条，比如先从日志里提取报错，再让模型给修复建议。写进定时脚本时留意：每多一次调用就多一份 token 消耗，串三步就是三次请求。

常用模式与用途

官方 模式库 下现有 265 个模式，方向覆盖总结、观点提取、代码审阅、会议纪要、威胁建模等。挑几个上手成本低的：

模式太多不好挑，可以先用 suggest_pattern 描述任务让模型推荐，再用 --dry-run 看拼好的请求、用 --print-prompt 只渲染提示词不发请求。这两步能省掉不少无效调用。

自建模式与服务化：从个人命令到团队接口

自建一个模式只要两件事：在自定义目录里建同名文件夹，写一个 system.md。自定义模式优先级高于内置模式，fabric --updatepatterns 更新内置库时也不会被覆盖，这一点比直接改官方目录稳妥。

需要参数时用 -v 传变量，需要长期背景时用 -C 指定 context 文件。项目还内置了 cot、cod、tot、self-refine 等 9 种提示策略，用 --strategy 叠加，例如让模型先写草稿再自评。

如果不想每条命令都敲一遍，可以用 alias 为每个模式生成同名命令，或者用 fabric --serve 起一个本地 REST 服务，默认监听 8080 端口。端点清单与鉴权说明在仓库的 REST API 文档 里。加上 --serveOllama 后还会提供 Ollama 兼容端点，模式会以模型名的形式出现，别的客户端可以把它当成一个模型服务来连。

服务化之前先想清楚鉴权。--serve 支持用 --api-key 保护路由，绑定的地址也建议限制在本机或内网，不要直接暴露到公网。

Fabric 的边界与局限：它不是 Agent

• 不主动找文件：它不遍历目录、不执行命令，输入什么就处理什么，需要你自己把上下文喂进去。
• 不改代码：少数模式会输出补丁或命令文本，但落盘与执行仍由你决定，误改的风险不由它兜底。
• 质量取决于提示词和模型：模式只是结构化的提示词，换一个弱模型结果会明显走样。
• 长文本受限：超出上下文窗口要自己切分，模式本身不做分段调度。
• 依赖外部服务：读网页走 Jina，转录依赖 yt-dlp 与 ffmpeg，这些环节不可用时对应功能直接失效。
• 模式数量本身是负担：265 个模式里真正合用的可能只有十来个，前期要花时间筛。

如果你的需求是「给它一个目标、它自己拆任务跑完」，那要看的是 Agent 类工具；Fabric 的位置更接近一把改锥，一次拧一个螺丝。终端里的 AI 结对编程工具走的是另一条路，比如 Aider 那类把改动交给 git 审阅的用法，两者可以并存。

适合谁先用：三类人可以先试

常驻终端的人收益最直接：日志、diff、curl 返回的 JSON，都能顺手接一条命令处理完，不必切窗口复制粘贴。第二类是需要把同一套提示词分给多人使用的团队，模式目录进 git 之后，提示词的变更就有记录可查。第三类是想把 AI 输出接进脚本和流水线的开发者，标准输入输出加一个本地 REST 服务，接起来比调各家 SDK 省事。

只在网页端偶尔问几句的人，装它的收益不大。先想清楚你每周有多少次是「拿到一段文本、想让模型按固定格式处理」，如果这个动作重复出现，再动手装。

想要统一多家模型的调用入口，也可以先看看 LiteLLM 把多家 API 收成一个兼容入口 的做法，和 Fabric 的 vendor 层是互补关系。日常在命令行里混用多款工具的话，终端命令行工具清单 里有几款可以和它搭配。

上手建议是：先用 summarize 和 explain_code 两个模式跑一周，确认模型输出质量能接受，再考虑自建模式和写 alias。项目迭代快，装完记得定期跑 fabric -U 更新模式库，升级后如果配置项有变化，重新执行一次 setup 更省心。仓库与发布页都在 GitHub，遇到问题先看 docs 目录和 CHANGELOG。