简介《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_keyos.environ[DEEPSEEK_API_KEY], base_urlos.environ.get(DEEPSEEK_BASE_URL, https://api.deepseek.com/v1), ) FORMULA # 角色 你是一名有 8 年经验的运维工程师习惯用最小代价定位问题。 # 任务 把下面这段报错日志翻译成人话并给出排查顺序。 # 约束 - 只依据日志内容推断不要编造不存在的服务名和字段名 - 无法确定的地方在该条后面标注「待确认」 # 输出格式 1. 一句话结论 2. 可能原因最多 3 条按可能性从高到低排序 3. 每条原因对应的验证命令用 bash 代码块包裹 # 输入 {log} log_text open(sample.log, encodingutf-8).read() resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你输出简洁不写客套话。}, {role: user, content: FORMULA.replace({log}, log_text)}, ], temperature0.2, # 诊断类任务要低减少发散 top_p0.9, max_tokens1200, ) print(resp.choices[0].message.content)几个参数的作用和取值方向值得单独说清楚temperature控制采样随机性诊断、抽取、改写这类要稳定复现的任务压到 0.10.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(encodingutf-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( modelmeta.get(model, deepseek-chat), messages[{role: user, content: prompt}], temperaturemeta.get(temperature, 0.3), timeout60, ) 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_workers4) as pool: results list(pool.map(lambda p: run_one(p, 示例输入), paths)) Path(runs.jsonl).write_text( \n.join(json.dumps(r, ensure_asciiFalse) for r in results), encodingutf-8)max_workers不要开太大接口侧有速率限制四到八之间比较稳重试用指数退避1s、2s、4s而不是固定间隔否则限流时整批会同步撞墙。结果写成 JSONL 而不是 JSON 数组是因为追加写更方便——跑到一半中断了已经完成的部分不会丢。下面这张表是试跑不同任务类型时我常用的参数起点任务类型temperaturetop_pmax_tokens备注抽取 / 分类0.11.0500配 JSON 输出便于解析诊断 / 排错0.20.91200允许多条原因时留足空间改写 / 润色0.50.9与原文等长过高会偏离原意头脑风暴0.90.952000需要明显发散时才用3.3 怎么判断一条公式该留还是该删批量跑完一百条真正好用的可能只有三十条。三个筛子结构合规率输出能不能被json.loads直接解析、人工抽样通过率随机抽十条看有没有幻觉、复现率同一输入跑三次结论是否一致。结构合规率低于 80% 的公式问题几乎都在输出格式段写得太含糊复现率低的多半是temperature没压下来或者约束段给的空间太大。同一批公式里语义重复的也要清掉。两条公式的差别只在于「请用中文输出」和「用中文回答」合并成一条加个参数就行留着只会让后来人不知道该用哪个。4. 导出成 PDF渲染链路、打印参数与中文字体4.1 三条导出路线的取舍路线适用场景优点代价Pandoc LaTeX公式以纯文本和代码为主排版精细自动目录装 LaTeX 环境重中文字体配置绕无头浏览器打印需要自定义样式、页眉页脚用 CSS 控制一切改样式快要写一份打印样式表在线转换 / PDF 编辑器一次性、少量文档零配置批量不可控隐私敏感内容不合适公式库这种「代码块多、表格多、中英混排」的文档我一般走无头浏览器先 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(encodingutf-8) for f in md_files) html markdown.markdown(body, extensions[tables, fenced_code, toc]) page_html fhtmlheadmeta charsetutf-8style{CSS}/style/headbody{html}/body/html Path(build/formulas.html).write_text(page_html, encodingutf-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( pathDeepSeek指令公式大全.pdf, formatA4, print_backgroundTrue, outlineTrue, # 依据 h1~h6 生成书签 display_header_footerTrue, header_templatediv stylefont-size:8pt;width:100%;text-align:centerDeepSeek 指令公式大全/div, footer_templatediv stylefont-size:8pt;width:100%;text-align:centerspan classpageNumber/span / span classtotalPages/span/div, ) browser.close()print_backgroundTrue不加的话代码块底色和表格边框全部消失打印出来是一片白。outlineTrue依赖 HTML 里存在h1h6标签如果 Markdown 转出来只有h2和h3书签层级也就是这两级正好够用。4.3 中文字体、代码块换行、书签三个高频坑中文字体回退。Linux 容器里如果没有装中文字体Chromium 会静默用默认字体渲染结果是整篇 PDF 全是方框而且不报错。部署时显式装一套思源黑体或 Noto Sans CJKCSS 里的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 matterPDF 导出时一并渲染进页脚两份文件一对照就知道同不同源。5.2 同一公式跨模型跑一致性对照公式写得好不好换个执行体就露馅了。把同一批公式分别丢给在线接口和本地部署的开源权重跑一遍输出结构差异大的那几条通常就是约束段没写死。如果平时在 VS Code 里接了 DeepSeek切模型对比的成本几乎为零开两个面板并排看就行。对照结果按「结构合规率」排序低于阈值的公式重点看输出格式段对照维度观察点差异大说明什么JSON 可解析能否直接json.loads格式约定不够机械靠模型自觉条目数量是否稳定给 3 条「最多 3 条」被理解成「随便几条」待确认标注是否出现约束段没压住补全倾向语气与详略长度差异是否超 50%角色段太虚没锚定输出粒度最后落一个可执行的检查把对照脚本挂到公式库的提交钩子上任何一条公式改动后自动跑两个模型各一次结构合规率低于 80% 就直接拦下。公式库这种东西靠人自觉维护迟早烂掉用一条命令把它管住最省事。本文还有配套的精品资源点击获取
简介《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_keyos.environ[DEEPSEEK_API_KEY], base_urlos.environ.get(DEEPSEEK_BASE_URL, https://api.deepseek.com/v1), ) FORMULA # 角色 你是一名有 8 年经验的运维工程师习惯用最小代价定位问题。 # 任务 把下面这段报错日志翻译成人话并给出排查顺序。 # 约束 - 只依据日志内容推断不要编造不存在的服务名和字段名 - 无法确定的地方在该条后面标注「待确认」 # 输出格式 1. 一句话结论 2. 可能原因最多 3 条按可能性从高到低排序 3. 每条原因对应的验证命令用 bash 代码块包裹 # 输入 {log} log_text open(sample.log, encodingutf-8).read() resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你输出简洁不写客套话。}, {role: user, content: FORMULA.replace({log}, log_text)}, ], temperature0.2, # 诊断类任务要低减少发散 top_p0.9, max_tokens1200, ) print(resp.choices[0].message.content)几个参数的作用和取值方向值得单独说清楚temperature控制采样随机性诊断、抽取、改写这类要稳定复现的任务压到 0.10.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(encodingutf-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( modelmeta.get(model, deepseek-chat), messages[{role: user, content: prompt}], temperaturemeta.get(temperature, 0.3), timeout60, ) 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_workers4) as pool: results list(pool.map(lambda p: run_one(p, 示例输入), paths)) Path(runs.jsonl).write_text( \n.join(json.dumps(r, ensure_asciiFalse) for r in results), encodingutf-8)max_workers不要开太大接口侧有速率限制四到八之间比较稳重试用指数退避1s、2s、4s而不是固定间隔否则限流时整批会同步撞墙。结果写成 JSONL 而不是 JSON 数组是因为追加写更方便——跑到一半中断了已经完成的部分不会丢。下面这张表是试跑不同任务类型时我常用的参数起点任务类型temperaturetop_pmax_tokens备注抽取 / 分类0.11.0500配 JSON 输出便于解析诊断 / 排错0.20.91200允许多条原因时留足空间改写 / 润色0.50.9与原文等长过高会偏离原意头脑风暴0.90.952000需要明显发散时才用3.3 怎么判断一条公式该留还是该删批量跑完一百条真正好用的可能只有三十条。三个筛子结构合规率输出能不能被json.loads直接解析、人工抽样通过率随机抽十条看有没有幻觉、复现率同一输入跑三次结论是否一致。结构合规率低于 80% 的公式问题几乎都在输出格式段写得太含糊复现率低的多半是temperature没压下来或者约束段给的空间太大。同一批公式里语义重复的也要清掉。两条公式的差别只在于「请用中文输出」和「用中文回答」合并成一条加个参数就行留着只会让后来人不知道该用哪个。4. 导出成 PDF渲染链路、打印参数与中文字体4.1 三条导出路线的取舍路线适用场景优点代价Pandoc LaTeX公式以纯文本和代码为主排版精细自动目录装 LaTeX 环境重中文字体配置绕无头浏览器打印需要自定义样式、页眉页脚用 CSS 控制一切改样式快要写一份打印样式表在线转换 / PDF 编辑器一次性、少量文档零配置批量不可控隐私敏感内容不合适公式库这种「代码块多、表格多、中英混排」的文档我一般走无头浏览器先 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(encodingutf-8) for f in md_files) html markdown.markdown(body, extensions[tables, fenced_code, toc]) page_html fhtmlheadmeta charsetutf-8style{CSS}/style/headbody{html}/body/html Path(build/formulas.html).write_text(page_html, encodingutf-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( pathDeepSeek指令公式大全.pdf, formatA4, print_backgroundTrue, outlineTrue, # 依据 h1~h6 生成书签 display_header_footerTrue, header_templatediv stylefont-size:8pt;width:100%;text-align:centerDeepSeek 指令公式大全/div, footer_templatediv stylefont-size:8pt;width:100%;text-align:centerspan classpageNumber/span / span classtotalPages/span/div, ) browser.close()print_backgroundTrue不加的话代码块底色和表格边框全部消失打印出来是一片白。outlineTrue依赖 HTML 里存在h1h6标签如果 Markdown 转出来只有h2和h3书签层级也就是这两级正好够用。4.3 中文字体、代码块换行、书签三个高频坑中文字体回退。Linux 容器里如果没有装中文字体Chromium 会静默用默认字体渲染结果是整篇 PDF 全是方框而且不报错。部署时显式装一套思源黑体或 Noto Sans CJKCSS 里的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 matterPDF 导出时一并渲染进页脚两份文件一对照就知道同不同源。5.2 同一公式跨模型跑一致性对照公式写得好不好换个执行体就露馅了。把同一批公式分别丢给在线接口和本地部署的开源权重跑一遍输出结构差异大的那几条通常就是约束段没写死。如果平时在 VS Code 里接了 DeepSeek切模型对比的成本几乎为零开两个面板并排看就行。对照结果按「结构合规率」排序低于阈值的公式重点看输出格式段对照维度观察点差异大说明什么JSON 可解析能否直接json.loads格式约定不够机械靠模型自觉条目数量是否稳定给 3 条「最多 3 条」被理解成「随便几条」待确认标注是否出现约束段没压住补全倾向语气与详略长度差异是否超 50%角色段太虚没锚定输出粒度最后落一个可执行的检查把对照脚本挂到公式库的提交钩子上任何一条公式改动后自动跑两个模型各一次结构合规率低于 80% 就直接拦下。公式库这种东西靠人自觉维护迟早烂掉用一条命令把它管住最省事。本文还有配套的精品资源点击获取
