Fabric 的 analyze_cfp_submission 模式：用系统提示词实现会议论文/演讲投稿的 AI 自动评审

本篇围绕 Fabric 仓库中的 analyze_cfp_submission 模式 展开。读完你可以完整掌握这个"会议演讲投稿评审"模式提示词的四段式结构（角色设定、评审步骤、输出约束、输入标记）、七个评审维度与三值结论设计，并了解 Fabric 如何从磁盘加载该模式、拼接用户输入、经 CLI 发送给模型，以及如何在本地覆盖、扩展和为它指定独立模型。

一、模式是什么：一个专门评审 CFP 投稿的系统提示词

Fabric 的核心理念是把"解决某类具体问题的提示词"沉淀为可复用的 Pattern（模式），存放在 data/patterns/<模式名>/system.md 下。analyze_cfp_submission 就是其中之一：它面向会议（Conference）征稿场景，让 AI 扮演评审人角色，对一份演讲投稿摘要（abstract）做系统性评估，并给出"接受 / 拒绝 / 要求修改"的明确建议。

该模式目录中只有一个文件 system.md，没有配套 user.md。这意味着全部提示词内容都由 system.md 承载，用户的投稿正文会在运行时注入到文件末尾的 INPUT: 标记处（见第五节调用链分析）。

二、提示词全文结构拆解

整个 system.md 由四个 # 级标题区块组成：IDENTITY and PURPOSE（身份与目的）、STEPS（评审步骤）、OUTPUT INSTRUCTIONS（输出指令）、INPUT（输入标记）。下面逐段说明其设计意图。

2.1 IDENTITY and PURPOSE：角色设定 + 元推理指令

第一段定义 AI 的身份：

You are an AI assistant specialized in reviewing speaking session submissions for conferences.

它明确了三个评审关注面：投稿的潜在质量（quality）、准确性（accuracy）、教育价值（educational value）与娱乐性（entertainment factor），并点出"成功会议演讲"的关键要素——内容相关性、讲者资质、观众互动潜力。

紧随其后的一句是关键：

Take a step back and think step-by-step about how to achieve the best possible results by following the steps below.

这是一条典型的元推理（meta-reasoning）指令，要求模型在回答前先"退后一步"按步骤逐步思考，而不是一步到位地给结论。

2.2 STEPS：十步评审流程

STEPS 区块以 10 个祈使句列出了完整的评审流水线，顺序即执行顺序：

1. 仔细阅读并分析提供的投稿摘要（Carefully read and analyze the provided submission abstract）
2. 评估摘要的清晰度与连贯性（clarity and coherence）
3. 评估主题与会议主题及目标受众的相关性（relevance）
4. 检验拟议内容的深度、原创性与潜在影响力（depth, originality, potential impact）
5. 考量讲者资质与领域专长（speaker's qualifications and expertise）
6. 评估演讲的教育价值（educational value）
7. 评估是否存在让人投入且有娱乐性的呈现要素（engaging and entertaining presentation）
8. 识别投稿中的红旗信号或隐忧（red flags or areas of concern）
9. 总结该演讲提议的优点与弱点（strengths and weaknesses）
10. 给出接受、拒绝或要求修改的推荐（recommendation）

注意步骤 8~10 与前面七步的关系：前 7 步是"逐维度分析"，第 8 步是"风险排查"，第 9~10 步是"综合收敛"。这个"分析 → 排雷 → 收敛为建议"的顺序，保证了最终 Recommendation 不是拍脑袋，而是有前序分析支撑。

2.3 OUTPUT INSTRUCTIONS：八条输出约束

OUTPUT INSTRUCTIONS 区块规定了评审报告的格式与措辞，共八条：

1. 只输出 Markdown（Only output Markdown）；
2. 以投稿简介开头，包含标题与主要主题；
3. 对摘要做详细分析，且必须把以下 7 点各自写成独立段落：
   1. Clarity and coherence（清晰度与连贯性）
   2. Relevance to conference and audience（与会议及受众的相关性）
   3. Content depth and originality（内容深度与原创性）
   4. Speaker qualifications（讲者资质）
   5. Educational value（教育价值）
   6. Entertainment potential（娱乐潜力）
   7. Potential concerns or red flags（潜在隐忧或红旗）
4. 包含一个 Strengths 章节，用项目符号列出正面亮点；
5. 包含一个 Weaknesses 章节，用项目符号列出待改进或存疑之处；
6. 以 Recommendation 章节收尾，明确说明推荐"接受 / 拒绝 / 要求修改"中的哪一种，并给出简要理由；
7. 全程使用专业、客观的语言；
8. 确保遵循以上所有指令。

这八条约束共同作用的结果是：无论输入什么质量的投稿摘要，产出都是结构固定、可直接归档的 Markdown 评审报告——先简介，再 7 段分维度分析，再 Strengths/Weaknesses 两栏对比，最后给出三值结论。这种"格式契约"正是 Prompt Engineering 中让 LLM 输出稳定可解析的关键手法。

2.4 INPUT 标记

文件最后两行是：

# INPUT

INPUT:

INPUT: 是一个占位锚点。Fabric 在运行该模式时，会把用户实际输入的投稿内容拼接到此处之后（源码层面见 chatter.go 中的 GetApplyVariables 调用），从而完成"系统提示词 + 待评审摘要"的组装。由于本模式没有定义任何 {{变量}} 模板占位符，用户输入就是整段投稿文本本身。

三、七个评审维度与结论设计

把 STEPS 与 OUTPUT INSTRUCTIONS 对照起来，可以看到模式刻意保持了一致性：分析步骤中的 7 个维度（清晰度、相关性、深度原创性、讲者资质、教育价值、娱乐潜力、红旗）与输出中的 7 个独立段落一一对应，再叠加 Strengths / Weaknesses / Recommendation 三个汇总章节。最终输出的评审报告骨架如下：

报告章节	内容	对应 STEPS 步骤
投稿简介	标题 + 主题概要	步骤 1
7 段分维度分析	清晰度 / 相关性 / 深度原创性 / 讲者资质 / 教育价值 / 娱乐潜力 / 红旗	步骤 2~8
Strengths	优点项目符号列表	步骤 9
Weaknesses	弱点项目符号列表	步骤 9
Recommendation	accept / reject / request modifications + 理由	步骤 10

三值结论（接受、拒绝、要求修改）而非二元"录用/不录用"，是征稿评审场景的务实设计：大量投稿处于"有潜力但需打磨"区间，request modifications 给了讲者明确反馈通道，也贴合 CFP（Call for Papers）流程中"补件修改"的实际操作。

四、在 Fabric 中如何调用这个模式

Fabric 的 CLI 提供了与模式直接交互的完整能力，相关标志定义在 flags.go：

• -p, --pattern <模式名>：选择要使用的模式；
• --readpattern <模式名>：把指定模式的内容直接打印到终端，不发送给模型，适合先审查提示词；
• -l, --listpatterns：列出全部可用模式（analyze_cfp_submission 会在其中）；
• -o, --output <文件>：把结果写入文件，方便把评审报告归档；
• -c, --copy：把结果复制到剪贴板；
• -m, --model <模型>：临时指定模型。

典型的评审投稿流程（在已安装并配置好 Fabric 的环境中执行）：

# 1. 确认模式存在
fabric --listpatterns

# 2. 先查看该模式的提示词全文（不消耗模型调用）
fabric --readpattern analyze_cfp_submission

# 3. 用一段投稿摘要文本运行评审，报告输出到文件
fabric -p analyze_cfp_submission "Talk title: Scaling Postgres in 2026. Abstract: ..." -o cfp_review.md

此外，chat.go 中还有一个针对模式的细节：如果设置了环境变量 FABRIC_MODEL_<模式名大写，连字符转下划线> 且没有用 -m 显式指定模型，Fabric 会自动为该模式选用对应模型。对于本模式，即 FABRIC_MODEL_ANALYZE_CFP_SUBMISSION，可以单独为"征稿评审"这类任务固定一个更擅长的模型，而不影响其他模式。

五、源码级解析：Fabric 如何加载并执行这个 system.md

5.1 system.md 是模式目录的法定文件名

db.go 中构造 PatternsEntity 时硬编码了 SystemPatternFile: "system.md"，这就是为什么所有模式（包括 analyze_cfp_submission 与 官方模式模板）都必须把提示词放在 <模式名>/system.md 下。

5.2 调用链：从 CLI 到最终 system 消息

从 chatter.go 的源码结构看，一次带模式的对话处理流程是：

1. 若启用了变量替换，先对用户输入执行 template.ApplyTemplate（本模式无 {{变量}}，此步基本直通）；
2. 调用 o.db.Patterns.GetApplyVariables(patternName, vars, message) 从磁盘读取 <模式名>/system.md，并把用户消息（即投稿摘要）拼接到 INPUT: 锚点之后；
3. systemMessage := joinPromptSections(contextContent, patternContent)——模式内容（含注入的输入）与上下文（-C/--context 指定，可选）合并为最终 system 消息；
4. 随后才附加策略（strategy）、语言约束等可选层。

也就是说，system.md 里的 IDENTITY、STEPS、OUTPUT INSTRUCTIONS 会原封不动地进入 system 消息，用户投稿则紧跟在其后。模式提示词写得越结构化（如本模式的编号输出约束），模型越容易严格遵循。

5.3 自定义模式目录可以覆盖同名官方模式

custom_patterns.go 提供了可选的 Custom Patterns 配置项，指向一个自定义模式目录；fsdb/patterns.go 的读取逻辑中先查自定义目录、未命中再回退主目录，且官方模式更新（PopulateDB，见 patterns_loader.go）时会把自定义目录中官方没有的同名/新名字模式一并保留。

这对 analyze_cfp_submission 的实际意义是：评审组织者可以按自家会议偏好（例如增加"安全合规""赞助商相关性"等维度，或把三值结论改为评分制）在自定义目录里放一份同名 analyze_cfp_submission/system.md 覆盖官方版本，而不必改动仓库内文件；fabric --updatepatterns 更新官方模式集后，自定义版本依然生效。测试用例 patterns_test.go 中"custom should override"的场景正是验证这一优先级。

5.4 模式更新机制

patterns_loader.go 定义了默认模式来源常量：默认仓库地址与 data/patterns 文件夹，PopulateDB() 会拉取该文件夹、合并自定义模式后写入本地配置目录，并生成 unique_patterns.txt 模式名清单（createUniquePatternsFile，同名去重、按字母排序）。IsConfigured() 还依赖一个 loaded 标记文件判断模式是否已下载完成。因此在新环境中，先完成模式初始化，analyze_cfp_submission 才会出现在 --listpatterns 结果里。

六、如何基于此模式扩展你自己的评审提示词

仓库自带了 official_pattern_template，它给出官方推荐的模式写作骨架：IDENTITY → GOALS → STEPS（可带"深度消费输入"式的心智演练描述）→ OUTPUT（按命名分节输出）→ POSITIVE/NEGATIVE EXAMPLES → OUTPUT INSTRUCTIONS → INPUT。analyze_cfp_submission 正是这套骨架的一个精简实例（省去 GOALS 与示例区块，用更直接的角色句和步骤清单实现）。

如果要派生一个面向自家会议的评审模式，建议：

1. 新建 <模式名>/system.md，放到自定义模式目录（或本地主模式目录）中；
2. 保留"IDENTITY + step-by-step 元指令 + 编号 STEPS + 分节 OUTPUT INSTRUCTIONS + 结尾 INPUT:"四段式，这是本模式产出稳定的关键；
3. 若评审维度与你的会议主题强相关，把 STEPS 的第 3 步（相关性评估）细化为针对该会议 track 的具体问题；
4. 用 fabric --readpattern <模式名> 核对最终落盘的提示词，再对同一份投稿摘要分别用官方与自定义版本各跑一次，对比 Recommendation 的一致性。

七、小结

analyze_cfp_submission 是一个结构紧凑但设计完整的评审型模式：以会议评审专家身份 + step-by-step 元指令开场，用 10 个有序步骤覆盖"分析 → 排雷 → 收敛"全流程，用 8 条输出约束锁定"Markdown + 7 段分析 + Strengths/Weaknesses + 三值 Recommendation"的报告格式，最后以 INPUT: 锚点接收投稿摘要。结合 Fabric 的 system.md 约定、-p/--readpattern CLI 能力、自定义模式目录覆盖机制与按模式独立指定模型的环境变量，它既可以开箱即用，也适合作为模板派生出针对特定会议场景的定制评审模式。