Fabric 的 analyze_bill 模式：用提示词工程拆解法案的“显性目标”与“隐性目标”

analyze_bill 是 Fabric 内置的一个提示词模式（Pattern），专门用于分析法案类长文本：它把模型设定为“能看穿立法文本真实意图的分析师”，通过固定的四步阅读流程和五段式输出结构，产出一份包含元数据、摘要、显性目标（OVERT GOALS）、隐性目标（COVERT GOALS）以及带有立场判断的结论的分析报告。读完本文，你将完整掌握该模式的提示词设计思路、输出规范，以及在 Fabric 中加载、运行这个模式的具体方式（包括它如何被 Patterns Loader 下载入库、{{input}} 占位符的自动注入机制）。

模式文件与提示词骨架

Fabric 的模式以目录组织，每个模式是一个目录，核心提示词存放在其中的 system.md 文件。analyze_bill 模式位于 data/patterns/analyze_bill/system.md，由三个一级标题段落构成：IDENTITY、STEPS、OUTPUT。这种“身份设定—执行步骤—输出格式”的三段式结构是 Fabric 社区提示词的典型骨架，下文逐段展开。

IDENTITY：身份设定

原文档的 IDENTITY 段全文如下：

You are an AI with a 3,129 IQ that specializes in discerning the true nature and goals of a piece of legislation.

It captures all the overt things, but also the covert ones as well, and points out gotchas as part of it's summary of the bill.

这段设定做了两件事：

1. 限定领域身份——模型被设定为“专门辨识一部法案真实性质与目标的分析师”。Fabric 的每个模式都通过 IDENTITY 段完成角色注入，把通用模型收窄为特定任务的专家视角；
2. 预先声明分析立场——明确要求同时捕获“overt（显性、不介意被看到的）”与“covert（隐藏在潜台词或文档深处的）”两类内容，并“在总结中点出坑（gotchas）”。这意味着模式从一开始就把“批判性审视”写进了任务定义，而不是留给模型自由发挥。

STEPS：四步执行流程

STEPS 段规定了模型在处理法案文本时的内部流程：

1. Read the entire bill 37 times using different perspectives.
2. Map out all the stuff it's trying to do on a 10 KM by 10K mental whiteboard.
3. Notice all the overt things it's trying to do, that it doesn't mind being seen.
4. Pay special attention to things its trying to hide in subtext or deep in the document.

逐条解读：

步骤	原文要求	设计意图
1	以不同视角通读整部法案 37 遍	用“多视角反复阅读”的隐喻强制模型做多角度遍历，而不是只扫一遍
2	在“10 公里 × 10 公里的心智白板”上画出法案想做的所有事	强制先做全局结构化映射（条款—机制—意图），再进行归纳
3	找出法案不介意被看到的显性内容	为输出中的 OVERT GOALS 段提供素材
4	特别关注藏在潜台词或文档深处的内容	为输出中的 COVERT GOALS 段提供素材

可以看出，STEPS 的第 3、4 步与 OUTPUT 段的两个目标清单（OVERT / COVERT）是一一对应的：先映射、再分类、后输出，整个提示词形成了一条闭环流水线。

OUTPUT：五段式输出规范

OUTPUT 段以编号清单规定了最终产物的结构，每条都有严格的量化约束：

1. Give the metadata for the bill, such as who proposed it, when, etc.
2. Create a 24-word summary of the bill and what it's trying to accomplish.
3. Create a section called OVERT GOALS, and list 5-10 16-word bullets for those.
4. Create a section called COVERT GOALS, and list 5-10 16-word bullets for those.
5. Create a conclusion sentence that gives opinionated judgement on whether the bill is mostly overt or mostly dirty with ulterior motives.

即一份完整输出必须包含：

1. 元数据：提案人、时间等法案基本信息；
2. 恰好 24 个词的摘要，说明法案试图达成什么；
3. OVERT GOALS 小节：5–10 条要点，每条 16 个词，列显性目标；
4. COVERT GOALS 小节：5–10 条要点，每条 16 个词，列隐性目标；
5. 一句结论：给出带立场（opinionated）的判断——这部法案“基本上是显性的”还是“基本被不可告人的动机污染了”。

这种“固定词数 + 固定条数区间”的约束是 Fabric 提示词风格的典型做法：通过硬性量化指标压缩模型的发散空间，使输出在不同法案、不同运行之间结构稳定、可直接对比。值得注意，第 5 条明确要求“opinionated judgement（有立场的判断）”，这与通常要求 LLM 保持中立的产品规范相反——analyze_bill 的设计目标就是让模型敢于下判断。

仓库中的姊妹模式：analyze_bill_short

仓库中还存在一个精简版 analyze_bill_short/system.md。两者的 IDENTITY 与 STEPS 段逐字相同，差异完全集中在 OUTPUT 的量化约束上：

输出部分	analyze_bill	analyze_bill_short
摘要	24 词	16 词
OVERT GOALS	5–10 条、每条 16 词	主目标 1 条 8 词 + 2 条支撑目标（各 8 词）
COVERT GOALS	5–10 条、每条 16 词	主目标 1 条 8 词 + 2 条支撑目标（各 8 词）
结论	一句话、带立场	16 词结论句

也就是说，同一套“多视角读取 + 显隐性分类”的分析内核，被封装成了“完整报告”与“速览卡片”两种粒度的输出契约。在实践层面，这意味着你可以先跑 short 版快速判断一部法案的“底色”，再决定是否用完整版做深度分析。

这个模式如何被 Fabric 加载与运行

理解提示词本身还不够，还需要知道它在 Fabric 里的加载与执行链路，这决定了你如何把一部法案文本喂给它。

模式来源与目录约定

• 模式的默认来源是 Fabric 仓库自身的 data/patterns 目录：internal/tools/patterns_loader.go 中定义了 DefaultPatternsGitRepoUrl 与 DefaultPatternsGitRepoFolder = "data/patterns"，PopulateDB() 会下载该目录、把模式复制到配置目录，并在成功后创建 loaded 标记文件（movePatterns()，internal/tools/patterns_loader.go）。
• 每个模式目录内，系统提示词文件名是固定的：internal/plugins/db/fsdb/db.go 将 SystemPatternFile 设为 "system.md"；PatternsEntity 结构体（internal/plugins/db/fsdb/patterns.go）还包含 UniquePatternsFilePath 与 CustomPatternsDir，即用户可以在自定义目录中放置自有模式，与内置模式并列。
• analyze_bill 目录内只有 system.md，没有 user.md。从目录结构看，这类模式不依赖独立的 user 提示词模板，用户输入的法案全文作为 input 注入。

input 的注入机制：为什么可以“直接贴文本”

analyze_bill 的提示词文本中并没有出现 {{input}} 占位符，但它仍然能接收外部输入，原因在于存储层的自动兜底逻辑。internal/plugins/db/fsdb/patterns.go 中的 ensureInput() 会在模式文本不含 {{input}} 时自动在末尾追加该占位符，随后 applyInput() 把占位符替换为用户实际输入：

func (o *PatternsEntity) ensureInput(pattern *Pattern) {
    if !strings.Contains(pattern.Pattern, "{{input}}") {
        if !strings.HasSuffix(pattern.Pattern, "\n") {
            pattern.Pattern += "\n"
        }
        pattern.Pattern += "{{input}}"
    }
}

对 analyze_bill 的实际效果是：最终发送给模型的内容 = 完整的 IDENTITY + STEPS + OUTPUT 提示词 + 你粘贴/管道传入的法案全文。法案文本会被拼接在提示词之后，模型按 STEPS 段处理这段文本并按 OUTPUT 段产出五部分。

在 CLI 中运行

Fabric 的核心用法就是“输入 | fabric --pattern <模式名>”。以 analyze_bill 为例，典型运行方式：

# 直接管道输入法案全文
cat bill.txt | fabric --pattern analyze_bill

# 或从 URL 抓取内容（如政府官网的法案页面）
fabric -u https://example.gov/bill-page -p analyze_bill

# 需要更短的报告时
cat bill.txt | fabric --pattern analyze_bill_short

模式名对应 data/patterns/ 下的目录名；若尚未下载过内置模式，先通过 Fabric 的初始化/setup 流程完成模式下载（对应上文 PopulateDB() 的行为）。README 中也展示了同类用法，例如 README.md 中的 pbpaste | fabric --pattern analyze_claims、fabric -u <url> -p analyze_claims，analyze_bill 的调用方式与之完全一致。

设计要点小结

回看 data/patterns/analyze_bill/system.md 这份不到 20 行的提示词，可以提炼出三点可复用的工程经验：

1. 立场前置：在 IDENTITY 中就把“同时抓显性与隐性内容”写死，避免模型默认的中立摘要倾向，这直接服务于最后“带立场结论”的要求；
2. 流程与输出对齐：STEPS 的第 3、4 步分别喂给 OUTPUT 的 OVERT/COVERT 两节，步骤即大纲，减少模型跑偏的空间；
3. 量化约束输出：24 词摘要、16 词条目、5–10 条区间——所有结构要素都有硬性指标，配合 internal/plugins/db/fsdb/patterns.go 的 {{input}} 自动注入，使同一个模式既能接收任意长度的法案原文，又能保证输出形态稳定可对比。

如果你想复用这套方法分析其他长文本（合同、政策、条款），Fabric 提供了自定义模式目录（CustomPatternsDir，见 PatternsEntity），可以按同样的“IDENTITY / STEPS / OUTPUT”骨架编写并放置自己的 system.md，而不必改动仓库内置内容。