在上一篇文章里，我们聊了为什么要把结构化表格塞给 AI——讲道理、谈逻辑、看场景，结论其实就一句话：你不给它格子，它就给你写散文。今天这篇是“下篇”，直接上硬货：怎么一步步让 AI 从“自由发挥”变成“按格填空”，以及我在实际项目中踩过的坑和总结出来的一套可复用的模板。文章会涉及提示词编写、格式化输出、JSON 输出、Agent 场景下的结构化约束，适合被 AI 输出问题折磨过的数据分析师、产品经理、开发者和所有重度 AI 用户。没有太多空话，全是可以直接拿去抄的作业。
1. 为什么 AI 总爱“自由发挥”：先理解输出失控的底层原因
1.1 Token 的“最省力原则”是万恶之源
很多人第一次用大模型的时候都会有一种感觉：这玩意儿怎么这么能说？我想要个表格，它给我写了两大段文字；我想要个结论，它给我列了七八条建议。你越说“详细一点”，它越来劲。
这里面的底层逻辑其实不复杂。大模型的生成过程是一个 token 一个 token“预测”出来的，它每一步都在根据前文选择概率最高的下一个词。训练过程中它见过太多“自然语言”的文本，所以默认情况下，它输出自然语言的能力是满级的，输出结构化数据的能力反而需要额外“激活”。
注意我说的这个“激活”——模型本身是具备格式化输出能力的，但如果你不给它明确的格式预期，它就会沿着最自然的语言惯性走。这就像你让一个特别会聊天的人帮你填表，结果他坐下来跟你唠了半小时，表格还是空的。你要做的不是怪他话多，而是把表格放在他面前，让他填。
1.2 真正的问题：你没有把“格式”当成硬需求
我们在实际使用中遇到的 90% 的输出失控情况，其实不是模型不行，而是提示词里根本没有规定“格式”这件事。
比如你写：“帮我分析一下这段用户反馈的意见”，AI 会输出什么？大概率是分点论述、加粗标题、甚至再来个总结。你觉得它“自由发挥”了，但在模型眼里它挺正常的，因为你只说了“分析”，没说“分析完填到哪张表里”。
所以从今天开始，我建议你把“格式”视作提示词的第一需求，而不是附加需求。你要在任务描述里明确告诉AI：我不是让你写作文，我是让你做填空题。这样输出的结果才是稳定、可靠、可复用的。
2. 建立“按格填空”的提示词骨架：先学会写模板
2.1 一个好模板必备的四个区
我把一套好用的结构化提示词拆成四个区：角色区、任务区、结构区、边界区。
角色区是告诉 AI 你是谁，比如“你是一名资深数据分析师”。任务区是描述你要做什么，比如“根据以下用户反馈提取关键信息”。结构区是核心，你要具体定义输出的格式、字段、顺序、样式。边界区是兜底的，比如“如果没有相关信息，填‘无’，不要编造”。
这四个区不是说每条都要写满，但结构区和边界区绝对不能省。很多人写提示词只写了角色和任务，漏了结构，结果 AI 又飞了。记住一个公式：角色 + 任务 + 结构 + 边界 = 可复现的输出。
2.2 一个可以直接抄的模板
这里直接分享一个我每篇结构化提示词都会用的基础模板，标题都能直接替换的那种：
角色：你是一名严谨的内容结构化助手。 任务：根据我提供的原始内容，提取关键信息，并严格按照我规定的表格格式输出。 输出结构要求： - 必须输出一个 Markdown 表格，列名必须严格使用我下面给出的列名，不得修改或者增删。 - 每一行数据都要从原始内容中提取，不得自行补充原始内容中不存在的信息。 - 如果某一项在原始内容中找不到，请填写“无”。 列名：编号 | 项目名称 | 核心问题 | 建议方案 | 优先级 原始内容： （在这里粘贴文本） 请先确认你理解了要求，然后直接输出结果，不要输出任何解释。这个模板我个人用了很久，效果非常稳定。它的关键是最后那句话：不要输出任何解释。很多人写提示词没有这句话，AI 就会先来一段“好的，我已经理解了您的要求”，然后才开始干活。浪费 token 是一回事，破坏格式统一是更严重的问题。
2.3 “格式示例”比“格式描述”更管用
还有一个经验，是在模板里直接给出一个“格式示例”。这不是可选项，是必选项。
你光说“请输出一个表格”，AI 可能给你列一个 3 列的表；你说“请按我下面的表头输出”，它就老实很多。如果还能给出一行示例数据，命中率会更高。原因是：示例相当于给模型一个具体的锚点，它会在生成的时候模仿示例的结构，这就是成熟的 one-shot/few-shot 思路。
我自己在写提示词时，通常会抄一段希望 AI 输出的表格格式放在结构区里，哪怕只给列名和一行样例，效果也比纯文字描述高很多。这个技巧在复杂格式场景下尤其有效，值得成为你所有提示词的习惯。
3. 三种落地姿势：纯文本表、Markdown 表和 JSON
3.1 给人类看的：Markdown 表格
先说最常用的场景：让 AI 输出给人看的内容，这个时候 Markdown 表格几乎是无脑首选。
Markdown 表格的优势是既有结构又易读，在主流聊天工具里都会直接渲染，复制到文档里也方便。缺点则是程序解析起来比较麻烦，如果你后面要接代码自动化流程，不建议用它。
一个写得好的提示词示例大概是这样的：
请用 Markdown 表格输出以下内容，表头为：日期 | 事件 | 影响程度 | 处理建议这里有一个小细节：表头顺序一定要写清楚。你如果只说“输出一个表格”，AI 有可能会把“日期”“影响程度”的顺序调换。但你把表头按顺序写死了，它一般会乖乖按着来。怕它乱改，还可以补一句“严格按给定的表头顺序输出”。
3.2 给程序用的：JSON 输出
如果你的下游是代码，不是人眼，那我强烈建议你用 JSON。这是目前大模型格式化输出里程序兼容性最好的格式。
用 JSON 的时候，提示词的写法要稍微变一变。核心原则有两个：第一，定义好 JSON 的字段名，包括字段的含义和你期望的类型；第二，声明“只输出 JSON，不要输出解释性文字”。
请提取原始内容中的信息，并输出成 JSON 格式。JSON 的字段和类型如下： { "summary": "string，一句话总结", "keywords": "string[]，关键词列表", "risk_level": "string，可选值：低/中/高", "actions": "string[]，建议措施列表" } 要求： - 只输出 JSON，不要输出解释、不要包裹在 Markdown 代码块里。 - 如果某个字段无法判断，填写 null。 原始内容：......这里最常遇到的问题就是 AI 会给你输出一个 Markdown 代码块包裹的 JSON，或者输出一段话再接一个 JSON。解决方案是几乎每条都要加一句“不要用 Markdown 代码块包裹，直接输出纯 JSON 文本”。做了这一步的稳定性提升非常明显。
3.3 进阶玩法：用 JSON Schema 和接口参数把格子焊死
聊到 JSON，不能跳过“结构化输出”这个概念。现在很多主流模型的 API 已经支持在接口层强制 JSON 格式，这在 AI Agent 开发里也特别常用。
具体点说，你可以用请求参数里的response_format指定输出格式，比如设置成{ "type": "json_object" }，亦或在函数调用（Function Calling）里传入 JSON Schema 定义参数结构。这样模型在生成的时候，被要求在底层就遵守结构，而不是靠提示词“自觉”。
我用这个方案做了不少自动化脚本，主要用于把 AI 的输出直接喂给下游程序，不用再做额外清洗。如果你现在只是聊天场景，可以不学这么深；但如果你写代码调用 AI，这块建议认真研究。它解决的痛点是：提示词写得再好，也存在意外；接口层强制约束，才是真正意义上的“按格填空”。
4. 实战演示：把一段自由文本培训成七行表格
4.1 场景设定：把产品需求变成需求评审表
为了让你看得更明白，我拿一个实际场景走一遍。假设你是一个产品经理或者技术负责人，团队每天在群里发各种需求，你希望用 AI 把这些需求整理成一张结构化的需求评审表，字段包括：需求ID、来源、需求描述、优先级、工作量预估、状态、备注。
原始输入是群聊里一段很随意的文字，比如：
“小明说登录页最近老有人反馈验证码看不清，想放大一点，最好能支持点击刷新。这个还挺急的，感觉一个小版本就能做掉。另外运营那边希望分享海报加个二维码，这个排到下个月吧。”
这段文字很口语化、没有结构，但如果直接丢给 AI 说“帮我整理成需求表”，它大概率会给你输出一段总结性文字，而不是表格。现在我们来按格填空。
4.2 编写提示词的完整过程
我的提示词会这样写：
你是一名严谨的需求管理助理。请根据我提供的原始沟通记录，提取需求信息并输出为一个 Markdown 表格。 表格必须包含以下列，且列名不得修改： 需求ID | 来源 | 需求描述 | 优先级 | 工作量预估 | 状态 | 备注 要求： 1. 如果原始内容提到了多条不同的需求，请拆分为多行。 2. 没有提到的字段填写“无”，不要编造。 3. 优先级只能填：紧急、高、中、低。 4. 直接输出表格，不要输出任何说明或建议。 原始内容： 小明说登录页最近老有人反馈验证码看不清，想放大一点，最好能支持点击刷新。这个还挺急的，感觉一个小版本就能做掉。另外运营那边希望分享海报加个二维码，这个排到下个月吧。这里我把“优先级只能填：紧急、高、中、低”作为边界条件写进去了。为什么？因为如果不限定可选值，AI 可能会填“高优先级”“较高”这类不统一的描述，导致后面统计困难。枚举字段提前锁死，是表格输出稳定性的一个关键操作。
4.3 输出效果对比：自由发挥 vs 按格填空
如果我不做结构约束，直接问 AI“帮我整理一下这些需求”，它的输出往往长这样：
“根据反馈，登录页验证码存在不清晰的问题，建议进行优化，同时增加点击刷新功能，该需求较为紧急；运营部门提出了新的二维码需求，可以安排在后续版本中……”
这句话信息量没错，但它不是表，你没法直接往下游用。而用上面那套“按格填空”的提示词，实际输出就是一个干净的表格：
| 需求ID | 来源 | 需求描述 | 优先级 | 工作量预估 | 状态 | 备注 |
|---|---|---|---|---|---|---|
| 1 | 小明 | 登录页验证码放大、支持点击刷新 | 紧急 | 小版本可完成 | 无 | 无 |
| 2 | 运营 | 分享海报增加二维码 | 中 | 无 | 无 | 下月排期 |
差别是不是非常直观？左边那版只能拿来读，右边这版可以直接复制进 Excel 或者需求管理工具里流转。这就是“从自由发挥到按格填空”的本质价值。
4.4 实际操作时要注意的几个小点
第一个小点是用分隔符把原始内容和其他指令区开。我习惯用三个引号包住原始文本，能有效降低 AI 混淆指令和内容的概率。第二个小点是当原始内容里有多条信息时，要提前告诉 AI“按行拆分”，否则它会自作主张合并成一段话。第三个小点是输出后如果发现字段不符合预期，不要直接放弃，用追问修复比重新生成省很多 token。
5. 常见翻车现场与排查清单
5.1 症状一：AI 拒绝按格填空，自己加戏
这种表现是：提示词里明明写了“只输出表格”，结果 AI 还是在表格前面加了一段“根据您的要求，我整理如下”，后面再来一段“希望对您有帮助”。遇到这种情况，先别怪 AI，而是检查提示词里有没有写“不要输出任何解释性文字”。
另一个原因是温度参数可能设得偏高。如果你调的 API，可以把 temperature 降到 0 或接近 0，输出会更稳定。我自己的经验是，对结构化输出场景，温度超过 0.5 就容易出幺蛾子。如果用的是聊天界面，记得每次都在提示词里明确说“直接输出结果，不要解释”。
5.2 症状二：字段漏了、多了、顺序乱了
字段相关问题是最常见的。排查时首先确认你给的表头有没有写死。如果你只说了“输出一个需求表”，AI 凭经验给你加一列“负责人”，这不怪它，怪你没写死。你可以加上一句“严格使用以下列名，不得增删列”，能解决 90% 的字段漂移问题。
如果字段还是乱，建议给一个“示例行”。这一步我不是每次都会做，但一旦发现字段频出问题，就果断加示例。模型对示例的模仿能力比对规则的理解能力更强，这是我做多次实验后的体会。
5.3 症状三：长文本输出被截断
搜索热词里有人提到“已达到输出 token 上限回答被截断”，这在大模型处理长文档时极其常见。模型单次输出长度有限，你让它把一篇几万字报告转成一张几十行的表，它可能写到一半就断了。
处理方案有两种。一种是拆：把长文先切块，多轮调用，每次只处理一部分，最后合并。另一种是要求 AI 分批汇总，比如先要求“按自然段逐段输出结构化结果”，再把多段结果合并。我在做长文档批量处理时，通常要求 AI 只输出核心字段，不输出完整原文摘要，能极大降低 token 消耗和截断概率。
5.4 症状四：JSON 输出解析失败
JSON 输出最常见的问题有三个：被 Markdown 代码块包裹、字段值带了多余逗号、中文上下文中混入了注释。写提示词时加上“直接输出纯 JSON，不要包裹在代码块中”是第一道防线。如果还失败，开发阶段可以加一个简单的后处理清洗函数，用正则去掉首尾的代码块标记。如果用 API 的response_format配合 JSON Schema，基本能从根上杜绝这类问题。
下面把常见问题整理成一张速查表，方便你之后快速定位：
| 问题 | 可能原因 | 解决方法 |
|---|---|---|
| 输出带解释和开场白 | 未限制解释性输出 | 提示词加“不要输出任何解释” |
| 列名被改动或乱序 | 表头未写死 | 提示词加“严格使用列名，不得增删列” |
| 字段内容编造 | 缺少边界条件 | 提示词加“找不到填无，不要编造” |
| 格式不稳定，时好时坏 | 缺少示例 | 增加一行示例数据作为格式锚点 |
| 长文本输出被截断 | 超出 token 上限 | 拆分输入，分批处理，合并结果 |
| JSON 解析失败 | 代码块包裹或多余注释 | 提示词说明，或用 response_format 强制 JSON |
真正把这个方法体系跑通之后，你会发现 AI 输出的稳定性提高了一个量级。以前是抽盲盒，现在像是填表格，心里很有底。我自己现在写提示词的步骤基本固定：先在纸上画一遍想要的格子，把列名确定下来；然后用“角色 + 任务 + 结构 + 边界”四件套去写；输出前如果条件允许，再补一个示例。这套流程用了很久，实测下来比任何“万能提示词”都可靠。
最后再分享一个小技巧：如果你希望 AI 长期稳定地按某种格式输出，可以把这套格式要求单独存成一段“格式守则”，在每次对话开始前粘贴进去。不要嫌麻烦，这比每次现写要稳定得多。毕竟 AI 协作这件事，驯得越细，用得越顺。
