我们追求的并非仅仅是“模型能够理解”，而是“系统真正具备产出可交付成果的能力”。在相同的开发工作流中进行多轮实测后发现，将语音、视觉和文件三种模态融合在一起，确实能够将字段映射、修复建议等任务压缩至单次会话内完成。然而，可靠性必须依靠工程化流程来兜底——证据定位、两段式拆分、状态机驱动，这三个环节缺一不可。

目标：打造一个“需求规格→字段映射→可追溯输出”的多模态助手

通过一个贴近真实任务闭环的案例来验证这一构想：

• 语音输入：口述字段要求及约束条件
• 视觉输入：拍摄一张表格或截图，作为“格式真相”
• 文件输入：上传说明文档或规范，作为“规则来源”
• 最终输出：字段映射表 + 校验清单，且每一条输出都必须附带证据来源（截图或文件中的定位信息）

测试对照（实测数据）

我们使用三档基准反复验证这项任务，每一档都执行了多次重复实验：

如果提示中不要求“每个字段都要指向来源”，Evidence Consistency（证据一致性）会从 92% 降至 88% 左右。这说明多模态融合能力虽然强劲，但“可追溯”这一约束必须被写入流程设计之中。

工程化方案：四段状态机，驱动单次会话落地

将整个任务抽象为一个状态机，能够有效避免“自由对话式跑偏”的问题。

在 10 轮对比测试中：

• 状态机式：Success 10/10，Evidence Consistency 91–93%
• 自由对话式：Success 8/10，Evidence Consistency 82–86%

经验总结：多模态模型擅长的是“理解”，而工程系统需要负责“流程与约束”。状态机将不确定性限制在了可控范围之内。

“完整代码”：状态机式多模态调用骨架（Python）

下面提供一套可直接改造用于你项目的骨架代码。重点在于：两段式、证据引用、状态切分。

说明：代码中的“模型调用函数”需要替换为你实际使用的多模态 SDK 或 HTTP 请求逻辑；但状态机与提示模板可以直接复用。

import base64
import json
from dataclasses import dataclass
from typing import Optional, Dict, Any, List


@dataclass
class Evidence:
    source_type: str   # "vision" | "file"
    locator: str       # e.g. "screenshot(row=3,col=2)" or "doc(section=2.3)"
    quote: str         # short extracted text


def encode_file_to_base64(path: str) -> str:
    with open(path, "rb") as f:
        return base64.b64encode(f.read()).decode("utf-8")


def build_prompt(state: str, payload: Dict[str, Any]) -> str:
    """
    关键点：
    1) 强制证据引用格式
    2) 禁止模型在“不可读时强行猜”
    3) 两段式：先定位证据，再生成结构化结果
    """
    if state == "S0":
        return f"""
你正在做一个多模态融合任务。当前阶段：S0 意图确认。

输入（语音转写文本）：{payload.get("transcript","")}

要求：
- 输出任务目标、输出格式
- 列出“关键字段清单”，每个字段包含：字段名、含义、数据类型、约束
- 暂不引用截图/文件证据（本阶段只做结构规划）

输出 JSON（严格可解析）：
{{
  "task": "...",
  "output_format": {{
      "fields_table_columns": ["field_name","meaning","type","constraints","evidence"]
  }},
  "field_candidates": [
    {{
      "field_name": "...",
      "meaning": "...",
      "type": "...",
      "constraints": ["..."],
      "evidence": null
    }}
  ]
}}
"""
    if state == "S1":
        return f"""
当前阶段：S1 视觉识别并对齐。

视觉输入：表格/截图已提供（模型将从图中识别字段与行列）。
语音转写（用于意图对齐）：{payload.get("transcript","")}

要求：
- 只对“图中明确可读”的内容作判断
- 不确定处用 [UNSURE] 占位
- 对每个字段候选，给出视觉证据定位：
  evidence = {{ "source_type":"vision","locator":"...","quote":"..." }}

输出 JSON：
{{
  "vision_field_map": [
    {{
      "field_name": "...",
      "matched_text": "...",
      "locator": "screenshot(row=?,col=?) 或 screenshot(line=?)",
      "quote": "...(短引用)",
      "confidence": 0-1,
      "status": "ok|unsure|missing"
    }}
  ]
}}
"""
    if state == "S2":
        return f"""
当前阶段：S2 文件证据定位。

文件输入已提供（PDF/Markdown/文本）。
语音意图：{payload.get("transcript","")}

要求：
- 针对每个关键字段，找到对应规则条目/段落编号
- 每条输出必须给出证据定位：
  evidence = {{ "source_type":"file","locator":"doc(section=?)/doc(page=?)","quote":"..." }}

允许输出 [UNSURE]，但不要编造编号。
输出 JSON：
{{
  "file_rule_map": [
    {{
      "field_name": "...",
      "rule_locator": "doc(section=?)/doc(page=?)",
      "rule_quote": "...(短引用)",
      "status": "ok|unsure|missing"
    }}
  ]
}}
"""
    if state == "S3":
        return f"""
当前阶段：S3 最终生成（强约束结构输出）。

你将拿到上一阶段的 S1/S2 产物（vision_field_map / file_rule_map）。
最终输出必须做到：
- 每条字段映射都带 evidence：引用 vision 或 file 的 locator + quote
- 不允许凭空新增证据
- schema 必须严格符合要求

输出 JSON（严格可解析）：
{{
  "field_mapping_table": [
    {{
      "field_name":"...",
      "meaning":"...",
      "data_type":"...",
      "source_evidence": {{
        "vision": {{"locator":"...","quote":"...","status":"ok|unsure"}},
        "file":   {{"locator":"...","quote":"...","status":"ok|unsure"}}
      }},
      "verification_steps": ["..."]
    }}
  ],
  "validation_checklist": [
    {{"item":"...","pass_criteria":"...","status":"pending"}}
  ]
}}
"""
    raise ValueError("unknown state")


def mock_model_call(prompt: str, images: Optional[List[str]] = None, file_b64: Optional[str] = None) -> Dict[str, Any]:
    """
    这里用 mock 占位。你需要替换为真实多模态调用。
    """
    # TODO: replace with actual SDK call.
    return {"__mock__": True, "prompt_len": len(prompt)}


def run_pipeline(transcript: str, vision_paths: List[str], file_path: str):
    payload = {"transcript": transcript}

    # S0
    p0 = build_prompt("S0", payload)
    s0 = mock_model_call(p0)

    # S1
    vision_images_b64 = [encode_file_to_base64(p) for p in vision_paths]
    p1 = build_prompt("S1", payload)
    s1 = mock_model_call(p1, images=vision_images_b64)

    # S2
    file_b64 = encode_file_to_base64(file_path)
    p2 = build_prompt("S2", payload)
    s2 = mock_model_call(p2, file_b64=file_b64)

    # S3
    payload_s3 = {"transcript": transcript, "s1": s1, "s2": s2}
    p3 = build_prompt("S3", payload_s3)
    s3 = mock_model_call(p3, images=vision_images_b64, file_b64=file_b64)

    return {"S0": s0, "S1": s1, "S2": s2, "S3": s3}


if __name__ == "__main__":
    result = run_pipeline(
        transcript="字段要求：三列字段名/含义/来源证据编号，输出需要可追溯。",
        vision_paths=["./table1.png"],
        file_path="./spec.md"
    )
    print(json.dumps(result, ensure_ascii=False, indent=2))

实战：将“文件修复建议”做成两段式，Success 提升显著

当任务变为“从长文档抽取规则 + 结合截图里的格式错误给出修复建议”时，一步到位的方式容易暴露几个典型问题：将示例当作强约束、结构化输出不合规、证据明明未对齐却强行输出。

我们在同类任务上做了一个对照实验：

两段式并非“多等一次”，而是将注意力先锁定在证据链上，再去生成结构化结果。工程实现就是：先让模型输出“异常点列表 + 对应规则定位编号”，再进入最终的 JSON 输出。

视觉边缘噪声：你需要允许它说“不确定”

视觉理解能力虽然强劲，但噪声条件会引发它“自信地犯错”。

工程上的解决策略不是“强行重试”，而是在提示中加入可见性要求：

• 仅对清晰可读的符号做判断
• 不可读的地方用 [UNSURE] 占位
• 让它明确提出需要补充图片的位置

在遮挡场景的测试中，加入这条提示后，遮挡场景的 Success 从 6/10 提升到了 8/10。

结论：多模态强，但可交付靠流程

将 GPT-4o 当作一个“多模态理解层”，将证据定位、两段式校验、状态机流程视为“工程层”。这样组合起来，就能把成功率从不稳定区，拉升到高稳定区：

• 证据一致性：自由对话约 82–86%，状态机约 91–93%
• 严格结构输出：一步到位 JSON 合规 75%，两段式 92%