Fabric analyze_debate 模式深度解析:辩论内容分析的提示词工程全拆解
本文以 Fabric 仓库内置的 analyze_debate 模式系统提示词 system.md 为核心,逐段拆解它的角色设定、推理步骤、八项结构化输出规范与防幻觉约束;并结合 chatter.go、patterns.go 等源码说明该模式如何被加载与执行,读完你可以完整复现一次辩论分析,并掌握 Fabric 提示词模式(Pattern)的编写范式。
模式定位:把辩论转录稿变成结构化分析
Fabric 将可复用的提示词组织成"模式"(Pattern),每个模式对应 data/patterns/ 下的一个目录,核心文件为 system.md。analyze_debate 就是其中一个官方模式,其目录 data/patterns/analyze_debate/ 下仅包含一个 system.md,没有配套的 user 模板文件——这意味着辩论转录稿全文由用户消息直接提供,系统提示词负责定义"怎么分析"。
仓库内的两处元数据也印证了它的定位:
- pattern_descriptions.json 中的官方描述:"Analyze debates identifying arguments, agreements, and emotional intensity."(分析辩论,识别论点、共识与情绪强度),标签为 ANALYSIS;
- pattern_explanations.md 第 14 行的解释:"Rate debates on insight, emotionality, and present an unbiased, thorough analysis of arguments, agreements, and disagreements."(对辩论的洞察度与情绪度打分,并客观深入地分析论点、共识与分歧)。
它的目标读者是"时间有限、只愿意消费高质量内容"的人:模式通过量化打分帮助读者快速判断一场辩论值不值得投入时间,再给出论点、共识、分歧、误解、收获与行动建议的完整分析。
提示词骨架逐段拆解
整个系统提示词共 43 行,由四个一级标题组织:IDENTITY and PURPOSE、STEPS、OUTPUT、OUTPUT INSTRUCTIONS,末尾以 INPUT: 作为转录稿的注入锚点。
IDENTITY and PURPOSE:中立裁判的角色锚定
You are a neutral and objective entity whose sole purpose is to help humans understand debates to broaden their own views.
第一段只定义三件事:身份是"中立、客观的实体",目标是"帮助人类理解辩论、拓宽自身视野",输入是"一段辩论的转录稿"。这种写法是典型的"角色锚定"——在模型输出任何观点之前,先用"neutral and objective"抑制立场倾向,后文所有"客观评估论点真伪"的要求都依赖这个前提。
STEPS:三步思考流程
- Consume the entire debate and think deeply about it.
- Map out all the claims and implications on a virtual whiteboard in your mind.
- Analyze the claims from a neutral and unbiased perspective.
三步分别对应:完整消费输入(避免遗漏)、在"心智白板"上建立论点-含义的映射(相当于让模型先做结构化梳理再作答)、以中立视角逐条分析。配合前一句 "Take a deep breath and think step by step",这是显式的 Chain-of-Thought 引导——要求模型先全局理解、再局部分析,而不是边读边下结论。
OUTPUT:八项硬性输出规范
这是提示词的核心部分,规定了输出必须包含的 8 个板块。每项都绑定了固定的标题文案、取值范围和词数约束,可整理如下表:
| 板块 | 固定标题(必须逐字使用) | 内容要求 | 取值范围/词数约束 |
|---|---|---|---|
| 洞察度评分 | INSIGHTFULNESS SCORE (0 = not very interesting and insightful to 10 = very interesting and insightful) | 对辩论的"有趣且有洞见"程度打分 | 0(无趣无洞见)到 10(极有趣极有洞见) |
| 情绪度评分 | EMOTIONALITY SCORE (0 (very calm) to 5 (very emotional)) | 整场辩论的情绪激烈程度 | 0(非常平静)到 5(非常情绪化) |
| 参与者列表 | PARTICIPANTS | 参与者名单,每人附情绪度分 | 每人 0~5 |
| 论点列表 | ARGUMENTS | 归因到具体参与者的论点摘要 + 姓名 + 原话引用,尽可能附外部参考来源 | 每条摘要必须恰好 16 个单词 |
| 共识列表 | AGREEMENTS | 参与者达成的共识,附姓名与引用 | 每条摘要恰好 16 个单词 |
| 分歧列表 | DISAGREEMENTS | 未能解决的分歧,附姓名与引用说明为何无法解决 | 每条摘要恰好 16 个单词 |
| 可能的误解 | POSSIBLE MISUNDERSTANDINGS | 可能存在的误解,附姓名与引用说明其成因 | 每条摘要恰好 16 个单词 |
| 收获与行动项 | LEARNINGS / TAKEAWAYS | LEARNINGS 为辩论中的学习点;TAKEAWAYS 突出值得思考的想法、值得探索的来源和可执行事项 | 每条恰好 16 个单词 |
几个细节值得单独说明:
洞察度评分的判分标准。提示词没有让模型自由发挥,而是给出了三条判分因子:参与者是否在做观点交换并试图理解对方;辩论主题是否新颖、未被普遍探讨;参与者是否达成了某种共识。同时要求"对评分保持高标准",面向的是时间有限、只找卓越观点的读者——等于把"从严评分"写进了评分规则,避免模型给出普遍性的高分。
16 个单词的硬约束。ARGUMENTS、AGREEMENTS、DISAGREEMENTS、POSSIBLE MISUNDERSTANDINGS、LEARNINGS、TAKEAWAYS 六个列表的每条摘要都被要求 "EXACTLY 16 words"。这种精确词数约束有两个作用:一是强制摘要高度浓缩,杜绝复述式长句;二是让输出条目长度均匀,便于后续做表格化或程序化处理。这是 Fabric 模式库中反复出现的"结构化压力"技巧,用形式约束换取信息密度。
防幻觉约束。在 ARGUMENTS 部分,提示词用大写反复强调引用外部来源时的三条红线:来源必须可信、可验证、易于访问;来源"BE REAL and NOT MADE UP";如果对论点真伪做客观评估,同样必须附可核查来源,并再次以大写 "DO NOT MAKE UP SOURCES" 收尾。由于模型在无检索能力时最容易在"外部参考"上虚构,这里等于对最易出错的环节做了双保险声明。
OUTPUT INSTRUCTIONS:输出纪律
- Output all sections above.
- Do not use any markdown formatting (no asterisks, no bullet points, no headers).
- Keep all agreements, arguments, recommendations, learnings, and takeaways to EXACTLY 16 words each.
- When providing quotes, these quotes should clearly express the points you are using them for. If necessary, use multiple quotes.
四条纪律中,"不使用任何 markdown 格式(无星号、无列表符、无标题符)"要求模型用固定标题文案 + 纯文本段落组织输出——这与前面"标题必须逐字固定"配合后,整个输出对下游解析极其友好:消费者可以按 8 个固定标题切分文本,无需处理 markdown 语法差异。引用则被要求"清晰表达你要用它证明的观点,必要时可用多条引用",防止断章取义式的单句摘引。
源码视角:这个模式如何被加载与执行
理解了提示词本身,再看 Fabric 如何把它跑起来。
模式发现与读取。db.go 中 NewDb 初始化 PatternsEntity 时硬编码了 SystemPatternFile: "system.md",即每个模式目录下的 system.md 就是系统提示词本体;patterns.go 中按 filepath.Join(o.Dir, name, o.SystemPatternFile) 拼接 data/patterns/analyze_debate/system.md 的路径来读取内容,自定义模式则从 CustomPatternsDir 下同名目录读取(db.go 支持通过环境变量 CUSTOM_PATTERNS_DIRECTORY 配置,且支持 ~/ 展开)。
模式下载与自定义模式保护。patterns_loader.go 中的 PatternsLoader 负责从 Git 仓库拉取模式:默认仓库地址常量 DefaultPatternsGitRepoUrl 指向上游 Fabric 仓库,默认目录常量 DefaultPatternsGitRepoFolder 为 "data/patterns"(即本仓库中模式的存放位置)。PopulateDB() 的流程是:创建临时目录 → gitCloneAndCopy() 拉取 → movePatterns() 移入本地配置目录 → createUniquePatternsFile() 生成 unique_patterns.txt 供命令补全使用。其中 PersistPatterns() 会在更新时把"新下载中不存在"的目录识别为自定义模式并原样保留,所以本地自建的 analyze_debate 变体不会被官方模式更新覆盖。此外 gitCloneAndCopy() 还包含一条路径迁移逻辑:当配置仍指向旧路径 patterns 时,自动探测并切换到 data/patterns,这与本仓库的模式目录位置一致。
执行链路。聊天请求到达后,chatter.go 根据请求携带的变量情况调用 o.db.Patterns.GetWithoutVariables(request.PatternName, request.Message.Content) 或 GetApplyVariables(...) 取出模式内容:analyze_debate 没有 {{variable}} 占位符,走的是无变量分支,用户消息(即辩论转录稿)作为消息内容传入,提示词末尾的 INPUT: 标记就是内容的落点。随后系统提示词 + 转录稿一起送入所选 LLM。
测试佐证。patterns_test.go 用 SystemPatternFile: "system.md" 构造实体验证读写,path_traversal_test.go 则验证了模式名中 .. 等路径穿越请求无法读到模式目录之外的文件,保证了按名取模式的边界安全。
实操:运行 analyze_debate
在已完成 fabric 初始化(模式已下载到本地配置目录)的前提下,典型用法有两种:
# 交互式:进入聊天后指定模式,粘贴辩论转录稿
fabric chat -p analyze_debate
# 管道式:把转录稿直接灌入(仓库 README 中同类示例的写法)
cat debate_transcript.txt | fabric -p analyze_debate
仓库 README.md 中的同类示例(fabric -u https://github.com/danielmiessler/fabric/ -p analyze_claims 与 echo "Analyze this code" | fabric --strategy cot -p analyze_code)说明了两种输入形态:一次性命令式与管道式。由于模式名会写入 unique_patterns.txt,shell 补全(见 completions/ 目录下的 bash/fish 脚本)可以直接提示 analyze_debate 这类模式名。
使用限制:输出遵循提示词约定的 8 段固定标题与纯文本格式;"16 词"约束对英文模型执行较严格,中文输出时模型可能按"字"或"词"的不同切分理解,对词数敏感的下游解析建议以英文输入/输出为准。
可复用的提示词工程要点
从 analyze_debate 可以提炼出 Fabric 模式库反复验证过的几条写法:
- 角色先于任务:开头用一句话锁定"中立、客观"身份,为后文的"客观评估真伪"提供立场基础;
- 评分规则量化:双量表(洞察度 0-10、情绪度 0-5)各自给出端点定义与判分因子,并要求"从严评分",避免模型趋中给分;
- 固定标题 + 禁用 markdown:输出结构以逐字固定的标题串组织、显式禁止 markdown 语法,换取可被稳定切分解析的纯文本;
- 词数硬约束:EXACTLY 16 words 的摘要约束强制浓缩,是低成本的信息密度开关;
- 针对最脆弱环节的防幻觉条款:外部引用"BE REAL and NOT MADE UP"、"DO NOT MAKE UP SOURCES" 用大写重复强调,直击 LLM 最容易虚构的环节;
- CoT 前缀 + 白板隐喻:"Take a deep breath and think step by step" 与 "virtual whiteboard" 引导模型先全局梳理再逐条分析。
若你希望为 Fabric 新增自己的分析模式,可直接参考 official_pattern_template 与 create_pattern 模式,按 data/patterns/<模式名>/system.md 的目录约定编写,并通过 patterns_loader.go 描述的机制将其纳入本地模式库使用。
atomcodeClaude Code 的开源替代方案。连接任意大模型,编辑代码,运行命令,自动验证 — 全自动执行。用 Rust 构建,极致性能。 | An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get StartedRust0623
Hy4-previewHy4 preview 是由腾讯混元团队研发的新一代混合专家(MoE)旗舰模型。模型总参数量 770B,每个 token 激活 49B,主干共包含78层,第一层采用标准 FFN,其余 77 层均为 MoE 结构,每层包含 256 个路由专家与 1 个共享专家,每个 token 激活 top-8 路由专家及共享专家。主干之外原生内置 1 层 MTP(总参数量 10B,激活 0.7B)以支持投机解码。Python00
GLM-5.3GLM-5.3 与 GLM-5.2 使用相同的基座模型——所有提升均来自后训练。与 GLM-5.2 相比,它在复杂编程和长程任务上的表现显著提升。Jinja00
GLM-5.3-FlashGLM-5.3-Flash (320B-A18B),是GLM-5系列的首个原生多模态模型。320B总参数,能力超过GLM-5.2Jinja00
Spark-X2.5-4BSpark-X2.5-4B 旨在让强大的 AI 更实用、更高效、更易获得。在广泛日常任务中表现强劲,涵盖对话、写作、翻译、推理、编码、工具调用以及智能体工作流,并在同等规模的开源模型中取得领先成绩。Spark-X2.5 将面向效率的架构与最高 1M tokens 的原生上下文窗口相结合,并支持 200 多种语言。Python00
Spark-X2.5-1.7BSpark-X2.5-1.7B 旨在让强大的 AI 更加实用、高效且易于获取。这些模型在广泛的日常任务中表现出色,涵盖对话、写作、翻译、推理、编程、工具调用和智能体工作流,并在同等规模的开源模型中取得领先结果。Spark-X2.5 将面向效率的架构与最高 1M tokens 的原生上下文窗口相结合,并支持 200 多种语言。Python00