简介《200Deepseek润色指令》v1.0是一份面向Deepseek使用者的指令合集聚焦文字内容、语言风格与结构的细致加工帮助用户在语法、标点、拼写、风格一致性和逻辑连贯性等方面提升表达质量。资源以单个PDF文件交付压缩包约2.92MB共1个文件便于集中查阅与检索。内容涵盖200余条润色指令并涉及商务写作、学术论文、广告文案等场景下的调整建议读者可按顺序执行也可根据实际任务挑选合适指令使用。由于文档由OCR转换而来个别文字可能存在识别错误或遗漏使用时需结合上下文和专业知识进行修正以确保指令理解的准确性与应用效果。目前已有296人学习适合希望系统改善文案质量、提高修改效率的Deepseek用户参考。1. 一份 OCR 出来的指令集200 多条润色指令到底能干什么手上攒了十几份来源不同的稿子产品说明、会议纪要、投放文案混在一起要求统一成一种口吻发出去。直接丢给 Deepseek 改第一遍还行第二遍就飘了同一段话两次出来的风格能差出一个人。这份《200Deepseek润色指令》解决的就是“飘”的问题——它把“怎么让模型改稿”拆成两百多条可以挑、可以组合的润色指令覆盖体裁定调、段落重排、长句拆分、术语统一这些具体动作。文档是 OCR 转出来的个别编号和参数有残缺得先清洗再使用。适合手上有一批文字要批量过一遍、又要求结果可复现的人只想改一两句话的用不上这么重的方案。2. 指令集的骨架拆解四类指令与不能反的调用顺序2.1 把 200 多条指令按“作用层”归成四类OCR 出来的原始文档是扁平列表两百多条平铺在一起编号还断了几处。照着顺序从上往下用前十条就开始互相冲突第 12 条让你“把长句拆开”第 15 条又让你“提升句子密度减少碎句”同一段文字被推来推去最后出来一坨四不像。所以第一步不是挑指令是给指令分层。我一般按“模型改动文字时实际动的粒度”分四层层级典型指令改的是用错了的表现体裁层改成商务邮件口吻、学术摘要风格用词范围、称呼、语气强度全文堆敬语事实信息被稀释篇章层调整段落顺序、补逻辑连接、压缩冗余段段落边界、信息顺序段落重排后指代错乱“它”不知道指谁句法层拆长句、被动改主动、主语显化句子结构主语补错责任人变了词汇层同义替换、术语统一、删虚词词专业术语被换成近义词外行读着顺、内行读着错分层的好处很实在层与层之间有优先级层内可以随便挑。词汇层永远最后做因为它改动最小、最容易执行。模型一旦发现你给了词汇层指令它会优先把那部分做完交差前面的句法和篇章就糊弄过去了。很多人抱怨“让它改结构结果只给我换了几个词”真实原因就在这里——不是模型不听话是任务没分层。还有一个判断标准一条指令如果同时提到两个不同层的动作比如“精简并提升专业度”那多半是两条指令被 OCR 拼成了一行用之前必须拆开。血泪经验是凡是能一口气读完还觉得特别顺的指令八成是合并过的直接拿去跑一定出问题。2.2 单条指令与指令链什么时候不能一次全用单条指令的适用范围比想象中窄。它适合句子级、边界清楚的动作把被动改主动、把“进行了一次讨论”改成“讨论了一次”、把三个并列短句合成一个带分号的句子。这类任务输入输出都是句子模型不需要理解上下文失败了一眼能看出来。指令链处理的是段落和整篇但它有个硬约束顺序固定。我固定成 体裁 → 篇章 → 句法 → 词汇。理由并不神秘体裁层决定用词范围先做它后面三层才有边界如果先做词汇替换再压体裁词汇层刚挑好的书面词会被体裁层再洗一遍等于白干。# 四层指令按固定顺序拼接层内一次只放一条指令 LAYER_ORDER [genre, discourse, syntax, lexical] def build_chain(text: str, rules: dict) - str: rules 形如 {genre: ..., discourse: ..., syntax: ..., lexical: ...} blocks [] for layer in LAYER_ORDER: rule rules.get(layer) if not rule: continue # 缺层就跳过不要用默认值硬凑 blocks.append(f【{layer}】{rule}) blocks.append(【硬约束】不新增事实不删除限定语数字与专有名词原样保留) blocks.append(f【原文】\n{text}) return \n\n.join(blocks)逻辑说明缺层跳过而不是补默认值这一点很关键。默认值一旦写死就成了一条你根本没审过的指令出了问题顺着 prompt 查查到最后发现是三个月前随手写的兜底文案这种坑最难排查。参数说明rules每一层的值应该从文档里挑一条原文指令尽量别自己改写措辞。文档里那些表述是被人反复用过的你重写一遍措辞变了效果和文档描述就对不上出了问题也没法判断是指令的问题还是你的问题。text建议控制在 800 字以内超过就分段原因在 4.4 节。2.3 一条指令该有哪些字段OCR 文档只给了“指令正文”其它什么都没有。要落地成能反复调用的模板至少补四个字段缺一个就会在某个环节翻车字段作用缺失后果id定位是哪条指令方便回滚改坏了不知道退回哪一版scope适用体裁与段落类型商务邮件的指令被用到学术摘要上act唯一的动作动词一条里混了三个动作只执行最后一个forbid反例明确不要什么模型默认往华丽、冗长方向跑expect输出形态纯正文带标注结果里混进“修改说明”还得手动删forbid最容易被跳过也最要命。文档里大量指令只写了“要什么”没写“不要什么”。模型在没有反例时默认往更华丽、更长、更多形容词的方向走因为训练数据里“润色”附近的样本大多长这样。补一条反例效果立竿见影提示反例要写具体的词不要写“不要过度修饰”这种没法执行的话。写成“不要新增形容词不要使用‘深刻极致赋能抓手’这类词不要把陈述句改成感叹句”模型才知道边界在哪。2.4 颗粒度一条指令只允许一个动词判断一条指令能不能直接用我只看它有几个动词。“拆长句并统一术语”是两个动作必须拆。“优化表达”压根不算动词它没有可验收的边界跑完你没法说它做没做对。合格的指令有明确的输入条件和输出形态比如“把超过 40 字的句子拆成两句拆出的第二句以原句的宾语作主语不改动数字与专有名词。”这条能验收数一下超过 40 字的句子还剩几句、看拆出的第二句主语对不对。对照着看几个不合格的例子改法很直观“提升文案感染力” —— 没有可测量对象换成“每段增加一个具体场景细节不增加形容词”。“让语言更专业” —— 专业是相对谁的换成“把口语词替换为术语表内的对应词术语表外的不动”。“适当精简” —— 适当是多少换成“删除原文中重复表达同一意思的句子总字数压缩到原文 80% 以内”。颗粒度这一层做扎实后面批量跑的时候才知道哪一条出了问题。两百多条指令里我第一批只筛出三十来条能直接用的剩下的要么合并过、要么缺反例得手工补这个工作量别低估。3. 把指令跑起来从 OCR 文档到可复用模板的四步3.1 清洗先把指令正文和排版噪声分开OCR 出来的文本有三类噪声页码页眉、中文断行、空格错位。页码好处理中文断行麻烦——原文档一段话被硬切成三行直接合并会把两条不同指令粘成一条。判断依据是标点行尾没有句号、问号、分号的中文行才和下一行合并。import re def clean_ocr(raw: str) - list[str]: raw re.sub(r第\s*\d\s*页, , raw) # 去页码 raw re.sub(r[ \t], , raw) # 压缩连续空格 # 仅当上一行结尾是中文且没有句末标点时才合并下一行 raw re.sub(r(?[\u4e00-\u9fa5、])\n(?[\u4e00-\u9fa5]), , raw) blocks re.split(r\n{2,}, raw) return [b.strip() for b in blocks if len(b.strip()) 8]逻辑说明第三条正则用了 lookbehind 限制前一个字符是中文或顿号避免把“1. 拆长句”这种编号行和正文粘起来。最后按空行切块长度阈值 8 是为了过滤目录残片和孤立的编号——OCR 经常把“12.”单独识别成一行。参数说明阈值 8 不是死的文档里如果有大量短指令比如“去口语词”这种四字指令阈值要降到 4否则会被误删。清洗完先len(blocks)看一眼正常应该在 200 上下差太多说明切分规则不对。3.2 结构化五段式模板清洗出来的每一块文本要套进固定模板再发出去。模板的意义是把“指令”和“原文”隔开让模型清楚哪部分是规则、哪部分是待处理内容。TEMPLATE 你是文字编辑。只执行下面这一条指令不要执行其它指令。 指令{instruction} 适用范围{scope} 改写幅度最多改动原文 {ratio}% 的句子 保留数字、专有名词、术语表内词汇原样保留 反例{forbid} 输出只输出润色后的正文不要解释不要加标题 原文 {text} def render(instruction, scope, forbid, text, ratio30): return TEMPLATE.format( instructioninstruction, scopescope, forbidforbid, texttext, ratioratio, )逻辑说明只执行下面这一条指令这句必须留它是防止指令串味的第一道闸。改写幅度写成百分比而不是“适当”“适度”是因为百分比能在 3.4 节用 diff 校验。参数说明ratio默认 30 偏保守适合已经定稿只做微调的稿子初稿阶段放到 5060。scope填体裁比如“商务邮件正文”“学术论文摘要”填得越窄模型越稳填“通用”等于没填。3.3 批量执行一次调用只做一件事两百多条指令不代表两百多次调用都要跑。实际做法是先按 2.1 的层级筛出当前稿子需要的 35 条每条单独一次调用串行执行上一步的输出作为下一步的输入。import json, time def run_chain(client, model, text, steps, sleep0.6): steps 是按顺序排好的指令列表每步一次独立调用 log, cur [], text for i, s in enumerate(steps): prompt render(s[instruction], s[scope], s[forbid], cur, s.get(ratio, 30)) resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.3, # 润色要稳定温度压住 top_p0.8, max_tokensint(len(cur) * 1.5) 256, ) cur resp.choices[0].message.content.strip() log.append({step: i, id: s[id], before: text if i 0 else None, after: cur, tokens: resp.usage.total_tokens}) time.sleep(sleep) # 串行执行时留间隔避免触发限流 return cur, log逻辑说明每一步的输入是上一步的输出日志里记下id和 token 数。出了问题能一眼定位是哪条指令改坏的而不是只看到一个面目全非的终稿。这是整套流程里最有价值的一步没有日志两百条指令就是黑匣子。参数说明temperature0.20.4再高就开始自由发挥top_p0.8 配合它够用max_tokens按原文长度 1.5 倍加 256留余量但不给太多给多了模型容易往里灌解释性文字sleep0.51 秒视接口限流而定批量跑几十篇的时候这个参数决定你会不会被卡住。3.4 对照同一段原文跑三组不做对照就下判断等于闭眼调参。我一般固定拿三段有代表性的原文一段商务、一段学术、一段文案跑三组配置组别配置观察点A单条指令裸跑无模板输出是否夹带解释、格式是否跑偏B五段式模板 单条指令格式稳定性、改写幅度是否可控C指令链3 步 术语表前后一致性、术语有没有被替换三组结果并排看重点看两件事B 组相比 A 组输出里“修改说明”类文字是不是消失了C 组相比 B 组同一个人名、同一个产品型号是不是从头到尾写法一致。这两项都过再上量。上量之后每 20 篇抽 1 篇人工看抽样率别低于 10%这是最容易省掉也最容易出事的一环。4. 参数与上下文让润色结果稳定的六个变量4.1 温度与 top_p润色的目标函数和创作相反润色要的是“在原意不变的前提下变好”创作要的是“变新”。这两个目标对采样参数的要求完全相反。creative writing 那套高温高 top_p 的参数直接搬过来会得到一堆用词花哨但事实漂移的稿子。参数建议值说明temperature0.20.4越低越贴原文0 会过于机械重复句式不拆top_p0.8和温度配合单独调它意义不大frequency_penalty0开启会强行换词术语容易被动presence_penalty0开启会鼓励引入新词润色场景里是负担max_tokens原文 ×1.5256给太多会灌解释给太少会截断stop视模板而定用“原文”作分隔时可不设presence_penalty这一项踩过坑。它鼓励模型说没说过的话用在对话里是优点用在润色里就是灾难——同一段里第二次出现的“客户”会被换成“用户”“甲方”“采购方”读者以为在说三个不同的对象。做润色这两项惩罚参数建议全部归零。4.2 改写幅度用“改动句子比例”代替“润色得更好”“润色得好一点”没法验收“改动不超过 30% 的句子”可以。做法是在 prompt 里写死比例跑完用 diff 算实际改动率超过就重跑或者换更保守的指令。import difflib def change_ratio(a: str, b: str) - float: 按字符级差异估算改动比例1.0 表示完全重写 sm difflib.SequenceMatcher(None, a, b) changed sum(max(i2 - i1, j2 - j1) for tag, i1, i2, j1, j2 in sm.get_opcodes() if tag ! equal) return changed / max(len(a), 1)逻辑说明SequenceMatcher的 opcode 里非 equal 的块就是被改动的位置字符数取两侧最大值避免“删掉一段”被算成零改动。这个指标粗糙但够用用来卡上下限而不是精确评估质量。参数说明商务邮件、合同类文本控制在 0.25 以内学术摘要 0.35 以内广告文案可以放到 0.6。超过上限说明指令太激进或者模型温度太高先调温度再考虑换指令顺序别反。4.3 术语表与禁用词表把黑匣子变成可控润色最怕的不是改得不好是改得你不知道哪里变了。术语表把“不能动的词”显式列出来等于给模型画了红线。def inject_terms(prompt: str, terms: dict) - str: terms: {型号A: [该型号, A型], 报价单: [价格表, 报价表]} lines [f{k}不得替换为{/.join(v)} for k, v in terms.items()] block 【术语】以下词汇原样保留禁止同义替换 .join(lines) return prompt.replace(【硬约束】, block \n【硬约束】)逻辑说明把术语块插在硬约束之前位置靠后模型的注意力更容易落在它上面。禁用词表可以合并进同一个块格式是“禁用赋能抓手闭环”列具体词别列词性。参数说明术语表条目控制在 20 条以内太多会稀释注意力反而让模型记不住。超过 20 条就按体裁拆成几份商务一份、技术一份按稿子类型加载。4.4 分段与整篇上下文窗口的取舍整篇一次性丢进去模型对后半段的注意力会掉表现为前半段改得细、后半段基本原样返回。这不是玄学是长上下文里的常见现象。分段处理能缓解但会带来另一个问题段与段之间的指代和术语一致性没人管。处理方式适用篇幅一致性风险建议整篇一次1500 字以内低首选省事按段处理15006000 字中每段带上术语表和首段摘要做锚分段 合并后再跑一遍6000 字以上高合并后只跑篇章层与词汇层别碰句法分段处理时我给每段的 prompt 里都塞一段 100 字左右的全篇摘要当锚点让它知道这段话在整体里的位置。这一步多做一次能省掉大量“改完发现前后口吻对不上”的返工。5. 避坑与排查五条血泪记录5.1 五个高频翻车现场现象一指令跑完输出里夹着“以下是润色后的版本”和一段修改说明。原因模板里没写死输出形态模型按对话习惯补了开场白。OCR 文档里的指令大多是裸指令本身不含格式约束。 解决模板末尾固定加“只输出润色后的正文不要解释不要加标题”并配stop兜底。已经生成的稿子用正则删掉首行“以下是”开头的段落别手工一条条删。现象二一次给了五条指令结果只执行了最后一条。原因长 prompt 里靠后的指令权重更高前面的被稀释。这跟 2.1 说的层内冲突是同一件事的两个表现。 解决一次调用只给一条指令用 3.3 的串行执行。真需要合并的把最重要的放最后并且在开头写“按顺序执行以下 N 条每条都要生效”。现象三商务邮件改成了散文越改越华丽。原因缺反例字段模型按训练数据里“润色美化”的默认路径走。 解决补forbid明确列出禁止的形容词和句式同时把温度压到 0.25 以下。改完再看 diff改动率超过 0.4 的直接重跑。现象四专业术语被同义替换外行读着顺、内行读着错。原因frequency_penalty或presence_penalty非零模型被鼓励换词或者术语没进术语表。 解决两项惩罚参数归零术语表按 4.3 注入。已经改错的稿子用术语表做一次全局反查把出现过的错误替换词列出来回填进禁用词表下次就不会再犯。现象五长文档后半段质量明显下滑前面改得细后面几乎原样返回。原因上下文过长注意力衰减也可能是max_tokens卡在临界值输出被截断后模型草草收尾。 解决超过 1500 字就分段每段带全篇摘要当锚max_tokens按 1.5 倍留足。分段后必须再跑一遍合并检查专看人称和术语。5.2 排查顺序从输入到输出的四道卡出问题别一上来就怀疑模型。按顺序查四道卡查完基本能定位到具体环节。第一步查指令本身这条指令有几个动词有没有反例scope 是不是写成了“通用”。第二步查请求参数温度、两项惩罚、max_tokens 是不是按 4.1 的表配的。第三步查输出跑change_ratio看改动率是否在设定区间内。第四步才是人工抽检重点看事实有没有被改、术语有没有被动、指代有没有断。def diagnose(origin: str, output: str, expect_max0.35) - list[str]: issues [] r change_ratio(origin, output) if r expect_max: issues.append(f改动率 {r:.0%} 超上限先降 temperature 到 0.25 以下) if len(output) len(origin) * 1.3: issues.append(输出显著变长检查是否缺 forbid 反例字段) if 以下是 in output[:20] or 修改说明 in output: issues.append(格式跑偏模板缺输出形态约束) return issues or [参数层面无异常转人工抽检事实与术语]逻辑说明三条判断分别对应改动过大、篇幅膨胀、格式跑偏这三类最高频的问题能覆盖大部分现场情况。返回空列表时不要松口气那说明问题在语义层只能人工看。排查这件事顺序比经验重要。我见过太多人一上来就换模型换完发现是 prompt 里两条指令互相冲突白折腾一天。6. 验收与进阶用差分对照把“改得好不好”变成可测润色最难的不是改是证明改完确实更好。两百多条指令给的是可能性不是保证。我的做法是把验收拆成三个可执行的检查跑完再上量。第一个检查是改动率分布。抽 20 篇样本逐篇算change_ratio看分布是不是集中在设定区间内。如果出现两个峰——一半在 0.1 以下、一半在 0.6 以上——说明指令在不同体裁上的激进程度不一致得按体裁拆成两套参数别用一套打天下。第二个检查是事实零漂移。把所有数字、日期、型号、人名抽出来做前后集合比对少一个都不行。这一步我写成脚本挂在批量流程后面比人工核对可靠得多。import re def fact_check(origin: str, output: str) - dict: 抽取数字与拉丁字母串做集合比对任何缺失都视为漂移 pat re.compile(r\d(?:\.\d)?%?|[A-Za-z][A-Za-z0-9\-]{2,}) a, b set(pat.findall(origin)), set(pat.findall(output)) return {missing: sorted(a - b), added: sorted(b - a)} # 用法missing 非空直接打回重跑added 非空人工确认逻辑说明missing非空意味着原文里的事实被删了这是硬错误不用看质量直接打回。added非空可能是模型自己补的也可能是合理换算比如“30%”写成“三成”必须人工确认不能自动放行。第三个检查是术语一致性。术语表里的每个词在终稿里出现的次数应该和原文一致或接近出现次数腰斩说明被替换了。进阶一点的做法是把这三项检查做成流水线的出口网关不通过就不出稿返回上一步重跑最多重试两次两次都不过就转人工。这样做的好处是把“我觉得改得还行”换成“三项指标都过了”返工率能压下来一大截。参数上可以根据自己的稿子调阈值但改动率上限和事实零漂移这两条我从来不放宽。有个后悔药值得提前备着每批稿子开跑之前把原始文本、指令 id、参数组合、输出全部落一份 JSON 存档按批次号命名。出事的时候能精确回滚到某一步而不是从头再来。这份存档的存储成本几乎为零救命的次数不少。从那以后我每批稿子进模型之前都强制先跑一遍清洗后的指令审核和改动率基线慢是慢点但不会再出现改完还得整篇回头重改的情况。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/25 1:44:25 · 阅读 1.2k 从OCR指令集到可复现润色：DeepSeek批量改稿的分层指令链与参数控制
简介《200Deepseek润色指令》v1.0是一份面向Deepseek使用者的指令合集聚焦文字内容、语言风格与结构的细致加工帮助用户在语法、标点、拼写、风格一致性和逻辑连贯性等方面提升表达质量。资源以单个PDF文件交付压缩包约2.92MB共1个文件便于集中查阅与检索。内容涵盖200余条润色指令并涉及商务写作、学术论文、广告文案等场景下的调整建议读者可按顺序执行也可根据实际任务挑选合适指令使用。由于文档由OCR转换而来个别文字可能存在识别错误或遗漏使用时需结合上下文和专业知识进行修正以确保指令理解的准确性与应用效果。目前已有296人学习适合希望系统改善文案质量、提高修改效率的Deepseek用户参考。1. 一份 OCR 出来的指令集200 多条润色指令到底能干什么手上攒了十几份来源不同的稿子产品说明、会议纪要、投放文案混在一起要求统一成一种口吻发出去。直接丢给 Deepseek 改第一遍还行第二遍就飘了同一段话两次出来的风格能差出一个人。这份《200Deepseek润色指令》解决的就是“飘”的问题——它把“怎么让模型改稿”拆成两百多条可以挑、可以组合的润色指令覆盖体裁定调、段落重排、长句拆分、术语统一这些具体动作。文档是 OCR 转出来的个别编号和参数有残缺得先清洗再使用。适合手上有一批文字要批量过一遍、又要求结果可复现的人只想改一两句话的用不上这么重的方案。2. 指令集的骨架拆解四类指令与不能反的调用顺序2.1 把 200 多条指令按“作用层”归成四类OCR 出来的原始文档是扁平列表两百多条平铺在一起编号还断了几处。照着顺序从上往下用前十条就开始互相冲突第 12 条让你“把长句拆开”第 15 条又让你“提升句子密度减少碎句”同一段文字被推来推去最后出来一坨四不像。所以第一步不是挑指令是给指令分层。我一般按“模型改动文字时实际动的粒度”分四层层级典型指令改的是用错了的表现体裁层改成商务邮件口吻、学术摘要风格用词范围、称呼、语气强度全文堆敬语事实信息被稀释篇章层调整段落顺序、补逻辑连接、压缩冗余段段落边界、信息顺序段落重排后指代错乱“它”不知道指谁句法层拆长句、被动改主动、主语显化句子结构主语补错责任人变了词汇层同义替换、术语统一、删虚词词专业术语被换成近义词外行读着顺、内行读着错分层的好处很实在层与层之间有优先级层内可以随便挑。词汇层永远最后做因为它改动最小、最容易执行。模型一旦发现你给了词汇层指令它会优先把那部分做完交差前面的句法和篇章就糊弄过去了。很多人抱怨“让它改结构结果只给我换了几个词”真实原因就在这里——不是模型不听话是任务没分层。还有一个判断标准一条指令如果同时提到两个不同层的动作比如“精简并提升专业度”那多半是两条指令被 OCR 拼成了一行用之前必须拆开。血泪经验是凡是能一口气读完还觉得特别顺的指令八成是合并过的直接拿去跑一定出问题。2.2 单条指令与指令链什么时候不能一次全用单条指令的适用范围比想象中窄。它适合句子级、边界清楚的动作把被动改主动、把“进行了一次讨论”改成“讨论了一次”、把三个并列短句合成一个带分号的句子。这类任务输入输出都是句子模型不需要理解上下文失败了一眼能看出来。指令链处理的是段落和整篇但它有个硬约束顺序固定。我固定成 体裁 → 篇章 → 句法 → 词汇。理由并不神秘体裁层决定用词范围先做它后面三层才有边界如果先做词汇替换再压体裁词汇层刚挑好的书面词会被体裁层再洗一遍等于白干。# 四层指令按固定顺序拼接层内一次只放一条指令 LAYER_ORDER [genre, discourse, syntax, lexical] def build_chain(text: str, rules: dict) - str: rules 形如 {genre: ..., discourse: ..., syntax: ..., lexical: ...} blocks [] for layer in LAYER_ORDER: rule rules.get(layer) if not rule: continue # 缺层就跳过不要用默认值硬凑 blocks.append(f【{layer}】{rule}) blocks.append(【硬约束】不新增事实不删除限定语数字与专有名词原样保留) blocks.append(f【原文】\n{text}) return \n\n.join(blocks)逻辑说明缺层跳过而不是补默认值这一点很关键。默认值一旦写死就成了一条你根本没审过的指令出了问题顺着 prompt 查查到最后发现是三个月前随手写的兜底文案这种坑最难排查。参数说明rules每一层的值应该从文档里挑一条原文指令尽量别自己改写措辞。文档里那些表述是被人反复用过的你重写一遍措辞变了效果和文档描述就对不上出了问题也没法判断是指令的问题还是你的问题。text建议控制在 800 字以内超过就分段原因在 4.4 节。2.3 一条指令该有哪些字段OCR 文档只给了“指令正文”其它什么都没有。要落地成能反复调用的模板至少补四个字段缺一个就会在某个环节翻车字段作用缺失后果id定位是哪条指令方便回滚改坏了不知道退回哪一版scope适用体裁与段落类型商务邮件的指令被用到学术摘要上act唯一的动作动词一条里混了三个动作只执行最后一个forbid反例明确不要什么模型默认往华丽、冗长方向跑expect输出形态纯正文带标注结果里混进“修改说明”还得手动删forbid最容易被跳过也最要命。文档里大量指令只写了“要什么”没写“不要什么”。模型在没有反例时默认往更华丽、更长、更多形容词的方向走因为训练数据里“润色”附近的样本大多长这样。补一条反例效果立竿见影提示反例要写具体的词不要写“不要过度修饰”这种没法执行的话。写成“不要新增形容词不要使用‘深刻极致赋能抓手’这类词不要把陈述句改成感叹句”模型才知道边界在哪。2.4 颗粒度一条指令只允许一个动词判断一条指令能不能直接用我只看它有几个动词。“拆长句并统一术语”是两个动作必须拆。“优化表达”压根不算动词它没有可验收的边界跑完你没法说它做没做对。合格的指令有明确的输入条件和输出形态比如“把超过 40 字的句子拆成两句拆出的第二句以原句的宾语作主语不改动数字与专有名词。”这条能验收数一下超过 40 字的句子还剩几句、看拆出的第二句主语对不对。对照着看几个不合格的例子改法很直观“提升文案感染力” —— 没有可测量对象换成“每段增加一个具体场景细节不增加形容词”。“让语言更专业” —— 专业是相对谁的换成“把口语词替换为术语表内的对应词术语表外的不动”。“适当精简” —— 适当是多少换成“删除原文中重复表达同一意思的句子总字数压缩到原文 80% 以内”。颗粒度这一层做扎实后面批量跑的时候才知道哪一条出了问题。两百多条指令里我第一批只筛出三十来条能直接用的剩下的要么合并过、要么缺反例得手工补这个工作量别低估。3. 把指令跑起来从 OCR 文档到可复用模板的四步3.1 清洗先把指令正文和排版噪声分开OCR 出来的文本有三类噪声页码页眉、中文断行、空格错位。页码好处理中文断行麻烦——原文档一段话被硬切成三行直接合并会把两条不同指令粘成一条。判断依据是标点行尾没有句号、问号、分号的中文行才和下一行合并。import re def clean_ocr(raw: str) - list[str]: raw re.sub(r第\s*\d\s*页, , raw) # 去页码 raw re.sub(r[ \t], , raw) # 压缩连续空格 # 仅当上一行结尾是中文且没有句末标点时才合并下一行 raw re.sub(r(?[\u4e00-\u9fa5、])\n(?[\u4e00-\u9fa5]), , raw) blocks re.split(r\n{2,}, raw) return [b.strip() for b in blocks if len(b.strip()) 8]逻辑说明第三条正则用了 lookbehind 限制前一个字符是中文或顿号避免把“1. 拆长句”这种编号行和正文粘起来。最后按空行切块长度阈值 8 是为了过滤目录残片和孤立的编号——OCR 经常把“12.”单独识别成一行。参数说明阈值 8 不是死的文档里如果有大量短指令比如“去口语词”这种四字指令阈值要降到 4否则会被误删。清洗完先len(blocks)看一眼正常应该在 200 上下差太多说明切分规则不对。3.2 结构化五段式模板清洗出来的每一块文本要套进固定模板再发出去。模板的意义是把“指令”和“原文”隔开让模型清楚哪部分是规则、哪部分是待处理内容。TEMPLATE 你是文字编辑。只执行下面这一条指令不要执行其它指令。 指令{instruction} 适用范围{scope} 改写幅度最多改动原文 {ratio}% 的句子 保留数字、专有名词、术语表内词汇原样保留 反例{forbid} 输出只输出润色后的正文不要解释不要加标题 原文 {text} def render(instruction, scope, forbid, text, ratio30): return TEMPLATE.format( instructioninstruction, scopescope, forbidforbid, texttext, ratioratio, )逻辑说明只执行下面这一条指令这句必须留它是防止指令串味的第一道闸。改写幅度写成百分比而不是“适当”“适度”是因为百分比能在 3.4 节用 diff 校验。参数说明ratio默认 30 偏保守适合已经定稿只做微调的稿子初稿阶段放到 5060。scope填体裁比如“商务邮件正文”“学术论文摘要”填得越窄模型越稳填“通用”等于没填。3.3 批量执行一次调用只做一件事两百多条指令不代表两百多次调用都要跑。实际做法是先按 2.1 的层级筛出当前稿子需要的 35 条每条单独一次调用串行执行上一步的输出作为下一步的输入。import json, time def run_chain(client, model, text, steps, sleep0.6): steps 是按顺序排好的指令列表每步一次独立调用 log, cur [], text for i, s in enumerate(steps): prompt render(s[instruction], s[scope], s[forbid], cur, s.get(ratio, 30)) resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.3, # 润色要稳定温度压住 top_p0.8, max_tokensint(len(cur) * 1.5) 256, ) cur resp.choices[0].message.content.strip() log.append({step: i, id: s[id], before: text if i 0 else None, after: cur, tokens: resp.usage.total_tokens}) time.sleep(sleep) # 串行执行时留间隔避免触发限流 return cur, log逻辑说明每一步的输入是上一步的输出日志里记下id和 token 数。出了问题能一眼定位是哪条指令改坏的而不是只看到一个面目全非的终稿。这是整套流程里最有价值的一步没有日志两百条指令就是黑匣子。参数说明temperature0.20.4再高就开始自由发挥top_p0.8 配合它够用max_tokens按原文长度 1.5 倍加 256留余量但不给太多给多了模型容易往里灌解释性文字sleep0.51 秒视接口限流而定批量跑几十篇的时候这个参数决定你会不会被卡住。3.4 对照同一段原文跑三组不做对照就下判断等于闭眼调参。我一般固定拿三段有代表性的原文一段商务、一段学术、一段文案跑三组配置组别配置观察点A单条指令裸跑无模板输出是否夹带解释、格式是否跑偏B五段式模板 单条指令格式稳定性、改写幅度是否可控C指令链3 步 术语表前后一致性、术语有没有被替换三组结果并排看重点看两件事B 组相比 A 组输出里“修改说明”类文字是不是消失了C 组相比 B 组同一个人名、同一个产品型号是不是从头到尾写法一致。这两项都过再上量。上量之后每 20 篇抽 1 篇人工看抽样率别低于 10%这是最容易省掉也最容易出事的一环。4. 参数与上下文让润色结果稳定的六个变量4.1 温度与 top_p润色的目标函数和创作相反润色要的是“在原意不变的前提下变好”创作要的是“变新”。这两个目标对采样参数的要求完全相反。creative writing 那套高温高 top_p 的参数直接搬过来会得到一堆用词花哨但事实漂移的稿子。参数建议值说明temperature0.20.4越低越贴原文0 会过于机械重复句式不拆top_p0.8和温度配合单独调它意义不大frequency_penalty0开启会强行换词术语容易被动presence_penalty0开启会鼓励引入新词润色场景里是负担max_tokens原文 ×1.5256给太多会灌解释给太少会截断stop视模板而定用“原文”作分隔时可不设presence_penalty这一项踩过坑。它鼓励模型说没说过的话用在对话里是优点用在润色里就是灾难——同一段里第二次出现的“客户”会被换成“用户”“甲方”“采购方”读者以为在说三个不同的对象。做润色这两项惩罚参数建议全部归零。4.2 改写幅度用“改动句子比例”代替“润色得更好”“润色得好一点”没法验收“改动不超过 30% 的句子”可以。做法是在 prompt 里写死比例跑完用 diff 算实际改动率超过就重跑或者换更保守的指令。import difflib def change_ratio(a: str, b: str) - float: 按字符级差异估算改动比例1.0 表示完全重写 sm difflib.SequenceMatcher(None, a, b) changed sum(max(i2 - i1, j2 - j1) for tag, i1, i2, j1, j2 in sm.get_opcodes() if tag ! equal) return changed / max(len(a), 1)逻辑说明SequenceMatcher的 opcode 里非 equal 的块就是被改动的位置字符数取两侧最大值避免“删掉一段”被算成零改动。这个指标粗糙但够用用来卡上下限而不是精确评估质量。参数说明商务邮件、合同类文本控制在 0.25 以内学术摘要 0.35 以内广告文案可以放到 0.6。超过上限说明指令太激进或者模型温度太高先调温度再考虑换指令顺序别反。4.3 术语表与禁用词表把黑匣子变成可控润色最怕的不是改得不好是改得你不知道哪里变了。术语表把“不能动的词”显式列出来等于给模型画了红线。def inject_terms(prompt: str, terms: dict) - str: terms: {型号A: [该型号, A型], 报价单: [价格表, 报价表]} lines [f{k}不得替换为{/.join(v)} for k, v in terms.items()] block 【术语】以下词汇原样保留禁止同义替换 .join(lines) return prompt.replace(【硬约束】, block \n【硬约束】)逻辑说明把术语块插在硬约束之前位置靠后模型的注意力更容易落在它上面。禁用词表可以合并进同一个块格式是“禁用赋能抓手闭环”列具体词别列词性。参数说明术语表条目控制在 20 条以内太多会稀释注意力反而让模型记不住。超过 20 条就按体裁拆成几份商务一份、技术一份按稿子类型加载。4.4 分段与整篇上下文窗口的取舍整篇一次性丢进去模型对后半段的注意力会掉表现为前半段改得细、后半段基本原样返回。这不是玄学是长上下文里的常见现象。分段处理能缓解但会带来另一个问题段与段之间的指代和术语一致性没人管。处理方式适用篇幅一致性风险建议整篇一次1500 字以内低首选省事按段处理15006000 字中每段带上术语表和首段摘要做锚分段 合并后再跑一遍6000 字以上高合并后只跑篇章层与词汇层别碰句法分段处理时我给每段的 prompt 里都塞一段 100 字左右的全篇摘要当锚点让它知道这段话在整体里的位置。这一步多做一次能省掉大量“改完发现前后口吻对不上”的返工。5. 避坑与排查五条血泪记录5.1 五个高频翻车现场现象一指令跑完输出里夹着“以下是润色后的版本”和一段修改说明。原因模板里没写死输出形态模型按对话习惯补了开场白。OCR 文档里的指令大多是裸指令本身不含格式约束。 解决模板末尾固定加“只输出润色后的正文不要解释不要加标题”并配stop兜底。已经生成的稿子用正则删掉首行“以下是”开头的段落别手工一条条删。现象二一次给了五条指令结果只执行了最后一条。原因长 prompt 里靠后的指令权重更高前面的被稀释。这跟 2.1 说的层内冲突是同一件事的两个表现。 解决一次调用只给一条指令用 3.3 的串行执行。真需要合并的把最重要的放最后并且在开头写“按顺序执行以下 N 条每条都要生效”。现象三商务邮件改成了散文越改越华丽。原因缺反例字段模型按训练数据里“润色美化”的默认路径走。 解决补forbid明确列出禁止的形容词和句式同时把温度压到 0.25 以下。改完再看 diff改动率超过 0.4 的直接重跑。现象四专业术语被同义替换外行读着顺、内行读着错。原因frequency_penalty或presence_penalty非零模型被鼓励换词或者术语没进术语表。 解决两项惩罚参数归零术语表按 4.3 注入。已经改错的稿子用术语表做一次全局反查把出现过的错误替换词列出来回填进禁用词表下次就不会再犯。现象五长文档后半段质量明显下滑前面改得细后面几乎原样返回。原因上下文过长注意力衰减也可能是max_tokens卡在临界值输出被截断后模型草草收尾。 解决超过 1500 字就分段每段带全篇摘要当锚max_tokens按 1.5 倍留足。分段后必须再跑一遍合并检查专看人称和术语。5.2 排查顺序从输入到输出的四道卡出问题别一上来就怀疑模型。按顺序查四道卡查完基本能定位到具体环节。第一步查指令本身这条指令有几个动词有没有反例scope 是不是写成了“通用”。第二步查请求参数温度、两项惩罚、max_tokens 是不是按 4.1 的表配的。第三步查输出跑change_ratio看改动率是否在设定区间内。第四步才是人工抽检重点看事实有没有被改、术语有没有被动、指代有没有断。def diagnose(origin: str, output: str, expect_max0.35) - list[str]: issues [] r change_ratio(origin, output) if r expect_max: issues.append(f改动率 {r:.0%} 超上限先降 temperature 到 0.25 以下) if len(output) len(origin) * 1.3: issues.append(输出显著变长检查是否缺 forbid 反例字段) if 以下是 in output[:20] or 修改说明 in output: issues.append(格式跑偏模板缺输出形态约束) return issues or [参数层面无异常转人工抽检事实与术语]逻辑说明三条判断分别对应改动过大、篇幅膨胀、格式跑偏这三类最高频的问题能覆盖大部分现场情况。返回空列表时不要松口气那说明问题在语义层只能人工看。排查这件事顺序比经验重要。我见过太多人一上来就换模型换完发现是 prompt 里两条指令互相冲突白折腾一天。6. 验收与进阶用差分对照把“改得好不好”变成可测润色最难的不是改是证明改完确实更好。两百多条指令给的是可能性不是保证。我的做法是把验收拆成三个可执行的检查跑完再上量。第一个检查是改动率分布。抽 20 篇样本逐篇算change_ratio看分布是不是集中在设定区间内。如果出现两个峰——一半在 0.1 以下、一半在 0.6 以上——说明指令在不同体裁上的激进程度不一致得按体裁拆成两套参数别用一套打天下。第二个检查是事实零漂移。把所有数字、日期、型号、人名抽出来做前后集合比对少一个都不行。这一步我写成脚本挂在批量流程后面比人工核对可靠得多。import re def fact_check(origin: str, output: str) - dict: 抽取数字与拉丁字母串做集合比对任何缺失都视为漂移 pat re.compile(r\d(?:\.\d)?%?|[A-Za-z][A-Za-z0-9\-]{2,}) a, b set(pat.findall(origin)), set(pat.findall(output)) return {missing: sorted(a - b), added: sorted(b - a)} # 用法missing 非空直接打回重跑added 非空人工确认逻辑说明missing非空意味着原文里的事实被删了这是硬错误不用看质量直接打回。added非空可能是模型自己补的也可能是合理换算比如“30%”写成“三成”必须人工确认不能自动放行。第三个检查是术语一致性。术语表里的每个词在终稿里出现的次数应该和原文一致或接近出现次数腰斩说明被替换了。进阶一点的做法是把这三项检查做成流水线的出口网关不通过就不出稿返回上一步重跑最多重试两次两次都不过就转人工。这样做的好处是把“我觉得改得还行”换成“三项指标都过了”返工率能压下来一大截。参数上可以根据自己的稿子调阈值但改动率上限和事实零漂移这两条我从来不放宽。有个后悔药值得提前备着每批稿子开跑之前把原始文本、指令 id、参数组合、输出全部落一份 JSON 存档按批次号命名。出事的时候能精确回滚到某一步而不是从头再来。这份存档的存储成本几乎为零救命的次数不少。从那以后我每批稿子进模型之前都强制先跑一遍清洗后的指令审核和改动率基线慢是慢点但不会再出现改完还得整篇回头重改的情况。希望帮到你。本文还有配套的精品资源点击获取