别让 AI 重新生成文件,让它往模板里填—避坑手记第 2 期

生成和填写，本来就是两件事

用 AI 这么久，有些坑我们都踩过太多次了。

你有一份格式很讲究的文件——可能是自己公司、其他对接单位、部门的长期要求的报告模板，可能是合同，总之，你没有权限去更改调整这些模板，必须按照模板的格式要求来填写。

你想让 AI 帮你填里面的内容，你很自然地打开AI应用的对话框，把模板文件拖进去，说：

然后它又是输出思维链、又是调用工具，吭哧吭哧忙活了半天，给了你一份文件，内容看起来还行，但你一细看，格式全崩了：标题字号变了，行距乱了，编号没了，表格的边框不知道跑哪去了，和你给它的模板文件完全不一样了。

你让它改，它改了一处，另一处又崩了。

大部分人让 AI 处理模板时，走的是这条路：

把整份模板文件给 AI → 让它输出一份填好的完整文件

这在直觉上很合理，但它有个致命问题：AI 拿到模板后，是在「重新生成」整份文档，而不是「往里面填内容」。

而问题出在哪一步？很多人以为是 AI「生成得不够稳」，其实真正的丢失发生在更早——你把它拖进对话框的那一刻。

Word等Ofiice 文件送进AI应用后，可能会被压成纯文本，在这个过程里，类似「这个合并单元格横跨三列」这类格式排版布局信息，在 AI 还没开始干活之前可能就已经没了。它拿到的是一份被压平的稿子，自然也只能还你一份被压平的稿子。

正确的做法是走另一条路：

模板留在你自己手里 → 让 AI 只输出「内容」 → 由程序把内容填进模板

格式从来不需要被 AI 理解，它只需要被保留。

做法其实很简单。把你模板里所有要填内容的地方，替换成一个标记：

【申请人】{{applicant}}

【案　号】{{case_no}}

一、审查意见概述

{{oa_summary}}

这个 {{xxx}} 就是占位符。

然后，你不再让 AI 输出整份文件，而是让它输出一份数据：

{

　"applicant": "某某智能科技有限公司",

　"case_no": "2026-1234567.8",

　"oa_summary": "审查员认为，权利要求 1 相对于……"

}

最后，再让它自己写一个程序把这份数据替换填进模板，生成成品。

其实就和我们在Word里面查找/替换差不多，没有人在有了模板文件之后，把模板再重新手打出来填写吧？

一个前提：必须让 AI 输出结构化数据

你可能注意到了，上面我写的不是大白话自然语言格式， 它叫：JSON格式，而不是直接让 AI「把申请人和案号告诉我」。

这一步不能省，它是整条链的地基。因为模型是概率生成的——你不约束它，它就会自由发挥。同样是要申请人和案号，它可能给你「申请人是某某公司，案号 2026-xxx」，也可能写成一行带竖线的表格，或者干脆埋在一段话里。

这些对人来说都能看懂，但对要准确复用的程序来说是非常不稳定的——没有稳定的位置可以取值。

JSON 格式做的事情，就是把「信息」从「表达」里剥离出来：键名（占位符）告诉AI这里要什么，值告诉AI内容具体要怎么填，一句多余的话都没有。模型没有发挥空间，程序也不需要猜。

AI在训练时就被喂入了大量的JSON格式，模型返回的原始请求数据格式很多也是JSON，它看到这个比你看到Word还亲

还有一笔看不见的成本

前面讲的都是「格式会崩」。

但重新生成还有个更隐蔽的问题——就算它这次认真了，也很可能是在白费力气。

整份模板文件要塞进上下文，它还得一个字一个字把版式复刻出来。这些力气花在格式排版布局上，就没有花在内容上。而且模板越长，被格式吃掉的就越多。

把最贵的资源花在最没用的地方，这就是内耗。

更麻烦的是，模板正文里常常混着指导填写的文字。比如：

【申请人】＿＿＿＿＿＿＿＿＿＿

（注：请与请求书保持一致，多个申请人用顿号分隔）

让 AI 重新生成时，它面对一个没法可靠回答的问题：这行括注要不要保留？保留的话，是照抄，还是改成我填的内容？于是两种翻车都可能发生：要么把注释抄进了正式文书，要么把该填的位置改成了注释。

而用占位符，这个歧义直接消失：

【申请人】{{applicant}}

（注：请与请求书保持一致，多个申请人用顿号分隔）

括号里面的注释内容不在占位符里，它就是模板的一部分，永远不动；{{applicant}} 是唯一需要填的位置。AI 不用猜，也不该猜。

省下来的力气用来干什么？用来想真正需要想的事：这份审查意见到底在质疑什么、这段答复的论证链条怎么搭、这条权利要求改到什么程度才不会超范围。那才是 AI 该花力气的地方。

为什么这样就稳了

关键在于：AI 从头到尾没见过你的格式。字体、行距、页边距这些信息一直留在模板文件里，是程序在填内容的时候原样保留下来的。

「保证」这个词，只有第二条路配得上。

有一点要说清楚：可复现的是格式，不是内容。同一个模板填十次，版式一模一样；但里面那段答复文字，每次生成仍可能不同。这不是缺陷，反而是好处——格式该稳定就稳定，内容该灵活就灵活。

有了占位符之后，你给 AI 的指令会变得完全不一样。

以前你得这么说：把第 3 行第 2 列那个单元格填上申请人，注意别超过 20 个字，如果是个人的话要加「先生／女士」，还有第 5 行的横线那里填案号……

现在你只需要说：

填 {{applicant}}。

差别在哪？位置不是个概念，字段是。

「第 3 行第 2 列」只是一个坐标——它今天在这个位置，明天表格调一下就不在了，你没办法为它定义规则。但 {{applicant}} 是个概念，你可以为它写规则：

{{applicant}}：与请求书一致；多个申请人用顿号分隔；不超过 100 字。

这就是「填写要求」这份文档能成立的原因。没有占位符，你没法写填写要求——你只能写「哪个位置填什么」。而这条规则的累积，就是流程的固化。

讲到这里你可能会想：这跟我有什么关系？我平时也不用什么复杂的模板。

那我换个说法。你每天在用的 Word 文件里，有一类格式，AI 几乎必然搞砸——嵌套表格和合并单元格。

一个大单元格里套着子项，上下共用表头，某几列合并成宽格子——企业里的报表、计划、审批单、对照表，全是这种结构。

你把它给 AI，让它「照着这个格式填一下」，会发生什么？

• 合并的单元格被拆开了——本来横跨三列的标题，变成三个独立格子，内容重复三遍

• 嵌套层级塌平了——主项和子项混成一个平铺的列表

• 边框、行高、列宽全丢——你自己的格式一点点都保不住

• 表格一长就开始偷懒——前面几行认真填，后面几行明显敷衍，或者干脆截断

而这些问题，用占位符替换全都不存在。因为表格的结构从头到尾就待在模板文件里，没动过——程序只把文字填进单元格，合并关系、嵌套层级、边框、行高，一个像素都不会变。

实测：一个合并单元格经历了什么

我做模板时顺手验证了一下：一张 3 列的表格，首行合并成一个标题格。

但一旦被压平成纯文本读出来，同一个「修改对照表」会被重复读出三次——程序已经分不清它到底是 1 个宽格，还是 3 个相同内容的窄格。合并信息一旦丢掉，就再也回不来了。

很多人觉得「让 AI 直接输出完整文件」是更高级的用法——它做得多嘛。但事实恰恰相反：让它重新生成整份文档，是在让它做一件它本来就不擅长的事。

大模型是按 token 顺序生成文本的，它没有「这个单元格横跨三列」这种结构概念。你要求它复现一个嵌套表格，等于要求它一边写字、一边在脑子里维护一张几何地图。这很难，而且它做得不稳定。

反过来，如果你只让它输出这样一份数据：

{

　"amend_table": [

　　{ "claim_no": "1",

　　　"before": "一种基于视觉识别的增强现实显示方法……",

　　　"after": "……基于双目视差计算目标深度信息……" },

　　{ "claim_no": "3",

　　　"before": "根据权利要求 1 所述的方法……",

　　　"after": "删除" }

　]

}

这就变成了一个纯文本填空任务——恰恰是大模型最拿手、最稳定的事。

前面说的都是通用场景。但对我这种做专利的来说，这个问题不是「好不好看」，而是合不合规。

专利文书有个特点：很多格式是法定的或者客户要求的。意见陈述书、权利要求书、说明书——结构、编号、段落格式都有明确要求，格式错了是要出形式缺陷的。

最难搞的是申请人的各种技术交底书、申请信息确认页，这些文件格式复杂，每家的可能都不一样，而这类文件恰好是嵌套结构的高发区：

• 权利要求书——独权下面挂着从权，从权还要引用上级权项，层级关系本身携带法律含义

• 技术交底书——里面一大堆文本框、复杂的合并单元格、解释性的填写指导说明

所以专利类的法律文书是占位符技巧价值最高的场景。它把「格式不能错」这件事，从「希望 AI 认真点」变成了结构上的保证。

具体动作只有三步：标占位符 → 写清填写要求 → 测试一遍。很长一段时间里，你不需要别的文件。

第一步：标占位符，顺手把格式调好

打开模板，光标放到要填的地方，打上 {{applicant}}。

但这里有个坑，第一次做的人基本都会踩：填进去的内容，会继承占位符自己的格式。

所以不能「随便打个占位符完事」，得先想清楚这个位置填完要长什么样、有哪些格式要求？再把占位符设成那个样子。

举个最常见的：模板里是「申请人：＿＿＿＿＿＿」，那条横线属于要保留的格式。如果占位符没带下划线，填进去的字就是光秃秃的——横线断了，而且程序不会报错。

另一个硬要求：必须在英文输入法下打花括号。中文输入法敲出来的是全角 ｛｝，和半角的 {{}} 在屏幕上几乎看不出区别，但程序扫过去就是匹配不上——同样不报错。

第二步：写清填写要求，留档

现在逐个占位符写清三件事：填什么、从哪来、按什么逻辑。

{{applicant}}　申请人全称

　　来源：请求书首页「申请人」栏

　　逻辑：与请求书完全一致；多个申请人用顿号分隔；≤100 字

{{case_no}}　申请号

　　来源：受理通知书

　　逻辑：保留原始的点号和校验位，不要改写成纯数字

写完存成一份文件，和模板放同一个目录。以后它就和模板绑定了——每次要填，把这两份一起给 AI，不用再重复解释一遍。

第三步：测试

拿一份真实数据跑一遍，检查三件事：格式对不对（下划线在不在、字体对不对）、有没有残留占位符、内容对不对。发现残留的 {{xxx}}，就说明 AI 少给了字段——那正是终检要抓的东西。

它的收益是复用次数乘以模板复杂度。填十次，明显划算；填一百次，离了它不行。所以先问自己一句：这份模板，我一年会填几次？

上面三步能让你跑起来。这一节补上规则细节——重点讲那些会导致「静默失败」的写法。

命名：只用小写英文和数字

用双大括号包起来，字段名只用小写字母、数字、下划线，层级用点号：

{{applicant}}　　　　　✅ 申请人

{{amend.claim_no}}　　 ✅ 点号表示层级

{{申请人}}　　　　　 ❌ 中文

{{Applicant}}　　　　 ❌ 大写

{{case-no}}　　　　　❌ 连字符

看起来像强迫症，但每条禁则背后，都对应一种替换直接失效、而且不报错的翻车。

最容易踩的是中文。中文输入法下敲出的花括号，常常是全角的 ｛｝——和半角的 {{}} 在屏幕上几乎看不出区别。你可能「看起来」写对了，程序扫过去就是匹配不上。更麻烦的是，Word 的自动更正、部分工具的标点归一化，都会在背后把半角符号悄悄转成全角。

所以我给这条规则加了一句限定：

听起来反直觉，但在这里，宽容是陷阱。程序一旦「智能地」兼容了写错的格式，就意味着你写错了它不吭声替你圆过去——你永远不知道自己写错过。哪天换了个工具、换了个人维护，同样一份模板替换就是失效的，而且没有任何提示。

让程序自己检查：预检 ＋ 终检

既然「静默失败」是最大的敌人，那就该让程序在两头都把住关。填写模板前扫一遍你已经填好了占位符的模板（预检），不合规的写法让AI逐条列出来，告诉你在哪里、原文是什么、为什么不行；填写替换后再扫一遍成品（终检），看还有没有没被替换的占位符。

预检防的是「模板写错了」，终检防的是「数据没给全」。没有终检，你会得到一份「填了一半」的文件——打开看着挺正常，某一行却赫然留着 {{case_no}} 没被替换。而如果这份文件是直接发给客户的，那就尴尬了。

发现 9 处写法不合规的占位符

· 正文段落 #6

　原文: ｛｛applicant｝｝

　原因: 含全角花括号，必须改为半角

· 正文段落 #5

　原文: {{申请人}}

　原因: 字段名含中文

表格里的占位符怎么放

这是最容易出错的地方。表格的结构必须完全留在模板里，占位符只放在单元格的文字里。对于需要重复行的表格，在第一行放占位符：

程序会自动按数据条数复制行。

这套方法的本质，其实不是技巧，是分工。

第一期我讲过一句话：起点错了，后面全错。那次讲的是文件解析——AI 拿到手的输入就是错的，后面怎么努力都没用。

这一期讲的是同一件事的另一面：别让 AI 承担它不该承担的环节。它不擅长解析，你就别让它解析；它不擅长维持格式，你就别让它维持格式。

我是旦旦，公众号「是旦不是蛋」。AI 工具用到现在，踩过的坑比学会的技巧多，就一条条记下来。

如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。

THANKS FOR READING