在很多实际场景中，模型虽然能够理解内容，但它能否输出一份经得起核对、每条结论都可追溯来源的结果，完全是另一回事。如果你恰好需要处理语音、截图、文档等多模态输入，并且希望模型的输出不仅仅是一个模糊的结论，而是一个结构清晰、每项结论都附带明确证据的交付物，那么下面这套流程将非常实用。
你需要准备的三样东西
整个流程并不复杂，核心只有三个步骤，每个步骤对应一种输入方式：
- 语音：清晰说明你要输出的字段以及最终的格式要求
- 视觉：拍摄一张表格或截图，确保字段名和行列关系清晰可辨
- 文件：上传规范或说明文档，让模型能够从中提取规则条目
强约束提示模板：直接拿来用
Step 0：先做意图确认，只规划结构
将你的语音转写内容粘贴进去，让模型输出字段清单。注意，这一阶段不要引入任何截图或文档证据，让模型仅做结构规划。
当前阶段：S0 意图确认。
要求输出：任务目标、输出格式、关键字段清单（字段名/含义/类型/约束）。
这一阶段不需要引用截图/文件证据。
最终输出严格 JSON。Step 1：视觉对齐，强制引用截图定位
上传截图，同时加上一句“可见性要求”。关键就在这里——你必须要求每一条结论都指向明确的证据。
当前阶段：S1 视觉识别并对齐。
规则：只对图中明确可读内容进行判断；不可读的部分用 [UNSURE] 占位，并说明需要补图的位置。
每个字段必须输出 evidence：source_type=vision、locator=行列/行号、quote=短引用。
输出严格 JSON。实测效果非常明显：强制要求 evidence 之后，证据一致性从约 88% 回升到了 92%（对照母版实测数据）。
Step 2：文件证据定位，编号不能瞎编
上传文档后，要求模型输出规则条目编号或段落位置。这是防止模型胡编乱造的关键步骤。
当前阶段：S2 文件证据定位。
为每个字段找到对应的规则条目/段落编号或页码定位。
不能编造编号；不确定就用 [UNSURE]。
每条输出必须包含 evidence：source_type=file、locator、rule_quote。
输出严格 JSON。Step 3：最终生成，所有映射必须带证据链
将前两步的结果一起输入模型，要求最终表格必须引用 evidence，并且禁止凭空新增任何证据。
当前阶段：S3 最终生成（强约束结构输出）。
每个字段映射都必须包含 source_evidence.vision / source_evidence.file。
禁止凭空新增证据；结构 schema 必须严格匹配。
输出严格 JSON：field_mapping_table + validation_checklist。效果怎么样？用数据说话
在同一类字段映射任务中（语音+视觉+文件同会话），实测结果如下：
- Success：10/10
- Field Acc：93%
- Evidence Consistency：92%
如果不要求证据定位，Evidence Consistency 会下降到 88% 左右。这组数据说明一个道理：你并非在“提升模型的能力”，而是在“提升交付的可靠性”。
两段式流程：什么时候特别值得用
如果你的任务是文档规则抽取、截图中有格式错误需要修复建议，或者要输出 JSON 格式的校验清单，那么两段式流程会明显更稳定。实测对照如下：
- 一步到位：JSON 合规 75%
- 两段式：JSON 合规 92%
两段式的本质很简单：先定位证据链，再根据证据生成结构化结果。相比直接一步到位多了一个环节，但换来的是交付的稳定性和可核对性。
最后提醒一句：不是所有场景都适合
如果你只想要一句“总结”，不关心结构化输出，也不在意证据能否被核对，那么这套流程确实显得“工程化过头”。但反过来，如果目标是交付——校验清单、字段映射表、审阅记录——那么这套流程的回报是值得的。