DeepSeek 指令公式模板化：四段式结构、批量调用与 PDF 导出

简介：《DeepSeek指令公式大全》是一份面向AI工具使用者的实战PDF手册，聚焦如何借助DeepSeek把专业概念转述成人人能懂的“大白话”，适用于教师、科普作者与内容创作者。内容围绕知识降维展开，从知识脱衣服、现实锚定、反常识检验、场景化测试到超级缝合术，并给出幼儿园公式、广场舞大妈式、追剧狂魔式、游戏废柴式、厨房爆炸式等可直接套用的提示词结构，正文以公式加案例对照表编排。压缩包内仅含1个PDF文件，体积约501KB，轻量便于随时查阅；案例用菜市场、快递驿站、相亲、打麻将、健身等生活场景类比区块链、TCP三次握手、DNS解析、过拟合等知识点，另附避坑自查表与万能提示词模板。目前已有646人学习下载，可作为拿来即用的改写范例，帮助降低知识传播门槛。

1. 指令公式到底解决了什么：从随口问一句到可复用的提示词模板

同一句「帮我把这段日志分析一下」，A 同事得到的是一堆正确的废话，B 同事得到的是带排查顺序、带验证命令、还标了不确定项的结论。用的都是 DeepSeek，差的不是模型，是喂进去的那段指令。

所谓指令公式，就是把提示词从「自然语言随口说」变成「有固定字段的模板」：角色、任务、约束、输出格式各占一块，可变的部分留成占位符，剩下的沉下来当资产。它解决的是三个具体问题——同一个人重复问同一类问题时的口语漂移，团队里每个人问法不一致导致结果不可比，以及必须反复复制粘贴提示词的时间损耗。

标题里的.pdf是这层沉淀的落地形态。几十上百条公式要能被人搜到、能打印出来贴在工位、能扔给不看 Markdown 的同事，PDF 是最省事的交换格式，配合 PDF 阅读器的全文检索，比翻聊天记录可靠得多。这套东西适合已经用 DeepSeek 处理固定类型工作的人，也适合要把它接进内部工具链的工程师。

2. 拆解一条 DeepSeek 指令公式：四段式结构与最小验证

2.1 角色、任务、约束、输出格式各自管什么

DeepSeek 这类对话模型对结构化指令的敏感度比想象中高。同一件事写成一段流水账，和写成四段带小标题，输出的稳定性差一个量级。四段不是铁律，但覆盖了日常需求的绝大部分。

最容易忽略的是约束段。没有约束时，模型倾向于补全信息——你给它半段日志，它会替你把缺失的行号、服务名一起「推理」出来，看起来煞有介事。加了「不确定的地方标待确认」之后，幻觉并没有消失，但它变成了可识别的标记，你扫一眼就知道哪几行不能信。

输出格式段的写法直接决定了后面能不能自动化。如果只是给人看，编号加粗就够了；如果要喂给脚本，就得约定成 JSON 或者固定的键值行。提前想清楚这一层，能省掉后面写正则解析的时间。

2.2 用 OpenAI 兼容接口跑通一条公式的最小调用

调试阶段别在聊天窗口里反复改，用 API 跑一遍最省事。DeepSeek 提供 OpenAI 兼容的端点，用官方openaiSDK 换个base_url就能用。

import os from openai import OpenAI client = OpenAI( api_key=os.environ["DEEPSEEK_API_KEY"], base_url=os.environ.get("DEEPSEEK_BASE_URL", "https://api.deepseek.com/v1"), ) FORMULA = """# 角色 你是一名有 8 年经验的运维工程师，习惯用最小代价定位问题。 # 任务 把下面这段报错日志翻译成人话，并给出排查顺序。 # 约束 - 只依据日志内容推断，不要编造不存在的服务名和字段名 - 无法确定的地方，在该条后面标注「待确认」 # 输出格式 1. 一句话结论 2. 可能原因（最多 3 条，按可能性从高到低排序） 3. 每条原因对应的验证命令，用 bash 代码块包裹 # 输入 {log} """ log_text = open("sample.log", encoding="utf-8").read() resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你输出简洁，不写客套话。"}, {"role": "user", "content": FORMULA.replace("{log}", log_text)}, ], temperature=0.2, # 诊断类任务要低，减少发散 top_p=0.9, max_tokens=1200, ) print(resp.choices[0].message.content)

几个参数的作用和取值方向值得单独说清楚：temperature控制采样随机性，诊断、抽取、改写这类要稳定复现的任务压到 0.1～0.3，创意文案才往上抬到 0.8 以上；top_p是另一种截断方式，通常和temperature二选一调，同时大改会互相干扰；max_tokens卡住的是输出长度上限，设太小会出现半截 JSON，设太大对短任务没影响但会拉高最坏情况的等待时间。

system 消息里放「不写客套话」这类全局风格，user 消息里放公式本身，这个分工比把风格要求塞进公式里更好维护——风格是跨公式共用的，公式是逐条独立的。

2.3 占位符渲染：花括号冲突这个坑要先绕开

公式模板里一旦出现 JSON 示例，str.format()就会把{"key": "value"}里的花括号当占位符，直接抛KeyError。三条常见路线：用string.Template的$log语法避开花括号；用 Jinja2 并把 JSON 段整体转义；或者干脆用不容易撞车的自定义分隔符。

from string import Template TPL = Template("""# 任务 把下面的结构化数据整理成一句话摘要。 # 输出格式 {"summary": "不超过 50 字", "risk_level": "low|medium|high"} # 输入 $payload """) print(TPL.safe_substitute(payload='{"order_id": 1024, "status": "timeout"}'))

safe_substitute和substitute的差别在于，前者遇到没传的变量会原样保留而不是报错，批量试跑时更抗造——某条公式新加了占位符但脚本还没更新，至少不会整批挂掉。Jinja2 更适合需要条件分支的场景，比如「如果给了lang就加一行语言要求」，但引入了模板语言本身的复杂度，公式数量少于二十条时未必划算。

3. 公式库的归档与批量试跑：从单条调试到一整个仓库

3.1 用目录结构和 YAML front matter 管住规模

公式超过二三十条之后，全部塞进一个文件就开始失控。按场景分目录，文件里用 front matter 记元数据，这样脚本能按标签筛选、按版本回溯。

formulas/ ├── 01-writing/ │ ├── weekly-report.md │ └── meeting-notes.md ├── 02-code/ │ ├── error-triage.md │ └── code-review.md └── 03-data/ └── log-summary.md

单条公式长这样：

--- id: error-triage title: 报错日志分诊 tags: [运维, 诊断] model: deepseek-chat temperature: 0.2 version: 3 updated: 2026-01-15 --- # 角色 ...

id用于引用和去重，version在公式被改坏时能快速回退，model和temperature写在文件里而不是散在脚本中，是为了让一条公式自己带齐复现所需的全部参数。改公式时顺手把updated更新掉，半年后回头看哪条还在用、哪条已经烂掉，一目了然。

3.2 批量调用：并发、重试和结果落盘

import json, time from concurrent.futures import ThreadPoolExecutor from pathlib import Path import yaml from openai import OpenAI client = OpenAI(api_key=..., base_url=...) def load(path): raw = Path(path).read_text(encoding="utf-8") _, fm, body = raw.split("---", 2) return yaml.safe_load(fm), body.strip() def run_one(path, payload): meta, body = load(path) prompt = body.replace("{input}", payload) for attempt in range(3): # 429/超时退避重试 try: r = client.chat.completions.create( model=meta.get("model", "deepseek-chat"), messages=[{"role": "user", "content": prompt}], temperature=meta.get("temperature", 0.3), timeout=60, ) return {"id": meta["id"], "ok": True, "out": r.choices[0].message.content} except Exception as e: if attempt == 2: return {"id": meta["id"], "ok": False, "err": str(e)} time.sleep(2 ** attempt) # 1s / 2s / 4s paths = list(Path("formulas").rglob("*.md")) with ThreadPoolExecutor(max_workers=4) as pool: results = list(pool.map(lambda p: run_one(p, "示例输入"), paths)) Path("runs.jsonl").write_text( "\n".join(json.dumps(r, ensure_ascii=False) for r in results), encoding="utf-8")

max_workers不要开太大，接口侧有速率限制，四到八之间比较稳；重试用指数退避（1s、2s、4s）而不是固定间隔，否则限流时整批会同步撞墙。结果写成 JSONL 而不是 JSON 数组，是因为追加写更方便——跑到一半中断了，已经完成的部分不会丢。

下面这张表是试跑不同任务类型时我常用的参数起点：

3.3 怎么判断一条公式该留还是该删

批量跑完一百条，真正好用的可能只有三十条。三个筛子：结构合规率（输出能不能被json.loads直接解析）、人工抽样通过率（随机抽十条看有没有幻觉）、复现率（同一输入跑三次，结论是否一致）。结构合规率低于 80% 的公式，问题几乎都在输出格式段写得太含糊；复现率低的多半是temperature没压下来，或者约束段给的空间太大。

同一批公式里语义重复的也要清掉。两条公式的差别只在于「请用中文输出」和「用中文回答」，合并成一条加个参数就行，留着只会让后来人不知道该用哪个。

4. 导出成 PDF：渲染链路、打印参数与中文字体

4.1 三条导出路线的取舍

公式库这种「代码块多、表格多、中英混排」的文档，我一般走无头浏览器：先 Markdown 转 HTML，再用 Chromium 的 print to PDF 能力输出。样式调整全在 CSS 里，改一次所有公式一起生效。

4.2 无头浏览器打印的完整链路

from pathlib import Path import markdown from playwright.sync_api import sync_playwright CSS = """ @page { size: A4; margin: 18mm 16mm; } body { font-family: "Noto Sans CJK SC", "Source Han Sans SC", sans-serif; font-size: 10.5pt; line-height: 1.7; } pre { background: #f6f8fa; padding: 8px 10px; border-radius: 4px; white-space: pre-wrap; word-break: break-word; } /* white-space 默认是 pre，长代码行会把页面撑宽，必须改成 pre-wrap */ table { border-collapse: collapse; width: 100%; font-size: 9.5pt; } th, td { border: 1px solid #d0d7de; padding: 4px 6px; } h1, h2, h3 { break-after: avoid; } /* 标题别留在页尾 */ """ md_files = sorted(Path("formulas").rglob("*.md")) body = "\n\n".join(f.read_text(encoding="utf-8") for f in md_files) html = markdown.markdown(body, extensions=["tables", "fenced_code", "toc"]) page_html = f"<html><head><meta charset='utf-8'><style>{CSS}</style></head><body>{html}</body></html>" Path("build/formulas.html").write_text(page_html, encoding="utf-8") with sync_playwright() as p: browser = p.chromium.launch() page = browser.new_page() page.goto("file://" + str(Path("build/formulas.html").resolve())) page.pdf( path="DeepSeek指令公式大全.pdf", format="A4", print_background=True, outline=True, # 依据 h1~h6 生成书签 display_header_footer=True, header_template="<div style='font-size:8pt;width:100%;text-align:center'>DeepSeek 指令公式大全</div>", footer_template="<div style='font-size:8pt;width:100%;text-align:center'><span class='pageNumber'></span> / <span class='totalPages'></span></div>", ) browser.close()

print_background=True不加的话，代码块底色和表格边框全部消失，打印出来是一片白。outline=True依赖 HTML 里存在h1～h6标签，如果 Markdown 转出来只有h2和h3，书签层级也就是这两级，正好够用。

4.3 中文字体、代码块换行、书签三个高频坑

中文字体回退。Linux 容器里如果没有装中文字体，Chromium 会静默用默认字体渲染，结果是整篇 PDF 全是方框，而且不报错。部署时显式装一套思源黑体或 Noto Sans CJK，CSS 里的font-family要和系统里实际存在的字体名对得上，写错了同样退化成方框。

代码块撑破版面。white-space: pre遇到一行两百字符的 JSON 会把页面宽度顶开，打印时右侧内容直接被裁掉。改成pre-wrap配合word-break: break-word就能自动折行，代价是缩进视觉上会乱一点，但内容完整比好看重要。

书签和页码。Chromium 的page.pdf()生成书签需要 HTML 里有语义化标题，用div加粗冒充标题是不行的。页码用pageNumber和totalPages这两个占位 class，写在header_template或footer_template里由浏览器替换。

导出之后建议用 PDF 阅读器实际翻一遍，重点看三个地方：中文有没有变方框、长代码行有没有被切、侧边栏书签能不能点。这三项过了，这份 PDF 才算真能用。如果终稿要交给只用 Word 的同事，再走一次 PDF 转 Word 也行，但代码块的缩进会掉，最好同时保留 HTML 版本。

5. 进阶：让 PDF 和源文件互相校验的检索玩法

5.1 用 PDF 文本层反查公式副本

公式库改久了，同一个 PDF 可能在不同人手里存了好几个版本，谁也不知道哪份是最新的。与其靠文件名猜，不如直接从 PDF 文本层里抽特征做比对——这一步本质上是 PDF 解析。

from pypdf import PdfReader import re, hashlib def fingerprints(pdf_path): text = "\n".join((pg.extract_text() or "") for pg in PdfReader(pdf_path).pages) # 抓每个公式的 id 行和版本行，作为该条的指纹 ids = re.findall(r"^\s*id:\s*(\S+)", text, re.M) return {i: hashlib.md5(i.encode()).hexdigest()[:8] for i in set(ids)} a, b = fingerprints("DeepSeek指令公式大全.pdf"), fingerprints("archive/old.pdf") print("仅在旧版:", sorted(set(b) - set(a))) print("新增:", sorted(set(a) - set(b)))

extract_text()拿到的顺序是按页面物理位置排的，多栏排版时可能串行，所以只用它做集合比对，不要拿来做逐字 diff。真正需要精确比对时，把源 Markdown 的哈希写进 front matter，PDF 导出时一并渲染进页脚，两份文件一对照就知道同不同源。

5.2 同一公式跨模型跑一致性对照

公式写得好不好，换个执行体就露馅了。把同一批公式分别丢给在线接口和本地部署的开源权重跑一遍，输出结构差异大的那几条，通常就是约束段没写死。如果平时在 VS Code 里接了 DeepSeek，切模型对比的成本几乎为零，开两个面板并排看就行。

对照结果按「结构合规率」排序，低于阈值的公式重点看输出格式段：

最后落一个可执行的检查：把对照脚本挂到公式库的提交钩子上，任何一条公式改动后自动跑两个模型各一次，结构合规率低于 80% 就直接拦下。公式库这种东西，靠人自觉维护迟早烂掉，用一条命令把它管住最省事。

本文还有配套的精品资源，点击获取