大模型补全需求文档的保结构与防幻觉实操教程

一、教程目标

本教程要解决的是一个高频但常被低估的问题：用大模型补全需求文档时，如何让模型严格遵守”只做扩展、不做改写”的边界。

具体要达成的效果有四个：

1. 输入 A、B、C、D 四项功能，输出必须是 A/A1、A2、A3，B/B1，C/C1、C2，D/D1、D2 这样的纯扩展结构，一级项数量、名称、顺序完全不变；
2. 建立一套机器可校验的输出契约，让”是否篡改结构”从主观感受变成可量化指标；
3. 把截图里的表格内容转成 Markdown 时，保证”截图里有什么才写什么”，缺失内容标注为待确认，而不是编造；
4. 形成一套排查思路，当模型反复”自作主张”时，能快速定位是指令问题、上下文问题还是模型能力问题。

二、适用场景与目标读者

典型适用场景包括：

• 产品经理把功能列表交给模型补充验收标准、边界条件、异常流程；
• 需求评审前需要把口头/会议结论结构化为文档；
• 把设计稿、系统截图、表格截图转换为可提交给开发的结构化描述（Markdown 表格、字段清单）；
• 需要批量处理多条需求、并保持文档格式统一的技术文档维护工作。

目标读者是产品经理、需求分析师、后端与前端开发者、技术负责人。你不需要有机器学习背景，但需要理解”提示词是可编程的输入”这一基本观念。

三、前置准备

开始之前请准备以下物料与环境，缺一项都会显著降低成功率：

1. 一份”骨架文件”：你自己写的功能清单，要求每项有稳定的唯一编号（如 F-01），编号是后续所有校验的锚点。
2. 补全规则说明：哪些字段必须补（触发条件、输入校验、异常分支、数据口径、权限要求），哪些字段不要补（技术选型、排期）。
3. 原始素材：截图、表格、日志片段。截图尽量用原始分辨率导出，避免二次压缩导致文字边缘模糊。
4. 模型访问方式：可通过云服务控制台开通通用大模型服务（例如在百度智能云的模型服务页面按需开通），或使用企业内部已接入的模型网关。多模型并存对交叉验证很有价值。
5. 一份小规模评测集：10~20 条真实需求输入及其”正确输出”。这是后面量化验证与排查的基础，没有它就无法判断改了提示词之后是变好还是变差。

四、问题定位：模型为什么会”自作主张”

先把现象归因清楚，再谈对策。实践中三类问题最常出现：

现象	本质原因	对策方向
删掉 B 项、合并 C 与 D	模型在做”语义压缩”，认为你的结构冗余	强化结构冻结指令 + 输出契约校验
凭空增加 E 项并解释 E = B + C3	模型的补全目标偏向”给出更有价值的结论”，倾向推导而非填充	明确禁止新增一级项，禁止推导性说明
截图里没有的功能被识别为”存在”	视觉识别偏差叠加语言模型的先验补全	要求逐单元格置信度标注，缺失必须显式留空
明确否认后仍然坚持”就在图中”	对话上下文里已有它自己的错误结论，形成自我强化	新开一轮对话、只提供截图与最小化问题

关键结论：不要试图靠一次提示词解决所有问题。结构与幻觉是两个独立缺陷，需要分别用”契约约束”和”证据约束”处理。

五、实施步骤

步骤 1：冻结需求骨架，给每一项分配稳定编号

做法：把原始功能清单整理成带唯一 ID 的表格或列表，一级项的顺序即最终顺序。

为什么：编号是校验的唯一可靠依据。如果输入本身没有稳定 ID，模型在改写时你很难自动判断”它删了哪一项”。

注意事项：一级项的 ID 一旦确定，在整个补全过程中不允许重新编号。后续所有轮次都引用同一套 ID。

F-01 登录与认证
F-02 组织架构管理
F-03 消息通知
F-04 数据导出

步骤 2：编写”只补全、不改写”的指令

这是整个教程的核心。指令需要显式声明角色、输入、输出与禁止项。禁止项要写成可判定的规则，而不是”请保持结构”这类模糊表述。

【角色】你是需求文档的补全助手，不是需求评审专家。
【输入】我提供的功能清单，编号与顺序即为最终结构。
【任务】仅为每个一级项补充下列字段：触发条件、输入校验、
       异常分支、数据口径、权限要求、验收标准。
【硬约束】
1. 一级项的 ID、名称、数量、顺序必须与输入完全一致；
2. 禁止删除、合并、拆分、重命名任何一级项；
3. 禁止新增任何一级项；如认为缺失某功能，只在文末
   "待确认建议"区列出，不得直接写入主体；
4. 禁止推导、评价、总结性文字，输出只包含要求的字段；
5. 无信息可补时，字段值填 "待确认"，不得编造数值、
   阈值、时限等具体业务参数。
【输出格式】严格按我给的 Markdown 模板，不加代码块外解释。

为什么禁止项要写成规则：模型对”禁止新增一级项”这类可枚举约束的遵守率，明显高于对”不要自作主张”这类抽象约束。

步骤 3：定义机器可校验的输出契约

自然语言约束需要配一道硬校验。推荐让模型输出 JSON（或结构严格的 Markdown），再用脚本比对骨架。

{
  "items": [
    {
      "id": "F-01",
      "name": "登录与认证",
      "details": {
        "trigger": "…",
        "validation": "…",
        "exception": "…",
        "data_scope": "…",
        "permission": "…",
        "acceptance": ["…", "…"]
      }
    }
  ]
}

校验逻辑（伪代码）：

function verify(inputSkeleton, output):
    errors = []
    inIds  = inputSkeleton.ids()
    outIds = output.items.map(i => i.id)
    # 1. 数量与顺序
    if inIds != outIds:
        errors.push("结构漂移: 期望 %s, 实际 %s" % (inIds, outIds))
    # 2. 逐项检查字段完整性
    for item in output.items:
        for field in REQUIRED_FIELDS:
            if field not in item.details or item.details[field] == "":
                errors.push("%s 缺少字段 %s" % (item.id, field))
        # 3. 占位符合规（允许"待确认"，不允许编造具体值）
        for field, value in item.details:
            if looksLikeFabricatedNumber(value) and not sourced(value):
                errors.push("%s.%s 疑似编造数值: %s" % (item.id, field, value))
    return errors

这一步的价值在于：把”我觉得它乱改”变成”校验报出 3 处结构漂移”，从而支持自动重试。

步骤 4：分批补全，控制单次上下文规模

一次性把 40 个功能项丢给模型，是结构漂移最常见的诱因之一——输出长度受限，模型会自发做删减。

建议做法：

• 开发/小规模阶段：按一级项分批，每批 3~5 项，逐批补全后合并；
• 生产/批量阶段：把骨架与批次映射表存入配置文件，由脚本驱动循环调用，每批独立校验，失败自动重试（建议最多 3 次，重试时附上失败原因）。

批次划分示意：

batch_1: [F-01, F-02, F-03]
batch_2: [F-04, F-05]
# 每批单独调用，最后按 id 排序合并，保证全局顺序与原始骨架一致

注意：合并环节必须以原始骨架为基准排序，不要按模型返回顺序拼接，否则顺序漂移难以发现。

步骤 5：截图转 Markdown 的可信流程

针对”截图里的表格转 Markdown”，请把流程拆成”识别”与”确认”两步，并强制引入置信度。

第 1 步，图像预处理：按原始比例放大到清晰可读，必要时裁剪为单行/单区域，减少跨行错位。

第 2 步，识别并强制标注不确定性：

【任务】把截图表格转为 Markdown 表格。
【约束】
1. 只允许输出截图中可见的文本，逐单元格照抄，不改写措辞；
2. 模糊、遮挡、无法辨认的单元格填 [不可辨认]；
3. 截图中不存在的行或列一律不得出现；
4. 每个单元格附置信度：高 / 中 / 低；
5. 表格之外不得输出任何说明文字。
【输出格式】
| 列1 | 列2 | 列3 | 置信度 |

第 3 步，交叉校验：同一张图换一次问法再识别一遍（例如先问”逐格朗读内容”，再问”生成表格”），两次结果不一致的单元格标为”低置信度”，交由人工确认。

第 4 步，人工确认低置信度单元格。这一步不可省略：视觉识别的错误无法通过提示词完全消除，只能通过复核兜底。

重要原则：当模型声称某功能存在于图中而你不确定时，不要在同一轮对话里反复争辩。已有错误结论会污染上下文。正确做法是重新发起一次独立会话，只提供图像与最小化提问，若两次独立结果一致才采信。

步骤 6：人工复核与版本回流

补全结果不是终点。建议流程：

1. 自动生成”变更清单”：新增了哪些字段、哪些字段填了”待确认”、哪些低置信度单元格待确认；
2. 人工只审变更清单，不做全文重读，节省时间；
3. 确认后的内容回写到骨架文件的版本化副本（每次补全生成新版本号），保留原始骨架作为基线；
4. 把本轮的人工修正抽样加入评测集，作为下一轮提示词优化的依据。

六、关键配置项说明

模型服务通常暴露以下通用推理参数，配置时需理解其含义与风险：

• 采样温度：取值范围通常为 0~2。需求补全属于强约束任务，建议 0~0.3。温度越高，越容易出现”创造性增删”。
• 核采样阈值（top_p）：与温度配合控制候选词范围，约束型任务建议 0.1~0.5。
• 最大输出长度：设得过大容易导致冗长发散，设得过小会导致模型自行截断或删减项。建议按批次规模估算：每批 5 个一级项预留 3000~4000 token 量级。
• 系统指令与用户指令分工：把不变的硬约束放系统指令，把每批的具体骨架放用户消息，便于复用与版本管理。
• 结构化输出模式：若平台提供 JSON 模式或 schema 约束能力，优先开启，可在生成阶段就压制格式漂移。是否可用需以你所接入服务的实际文档为准。
• 重试与超时：设置 2~3 次重试并携带错误原因，避免无信息重试。

风险提醒：不要为了”一次生成完整文档”而无限调大输出长度和上下文，这通常同时放大成本与结构漂移概率。

七、结果验证：怎么判断做对了

用四个可量化指标替代主观判断：

1. 结构一致率 = 通过骨架校验的批次数 / 总批次数。目标：> 98%。
2. 字段完整率 = 已填字段数 / 应填字段数。未达 100% 是允许的（可填”待确认”），但空字符串不允许。
3. 占位合规率 = 标注为”待确认”的字段数 / 无信息支撑字段总数。该值偏低意味着模型在编造。
4. 视觉识别准确率 = 与人工标注一致的单元格数 / 总单元格数。低置信度单元格应 100% 进入人工复核队列。

验证方法：把评测集跑一遍，记录改造前后四项指标。若结构一致率没有提升，问题多半不在提示词，而在批次过大或缺少硬校验环节。

八、常见问题与排查

问题	可能原因	排查思路
一级项被删/被合并	单批输入项过多、输出长度不足	减小批次到 3~5 项，提高输出上限
凭空新增功能项	指令中缺少可判定的禁止项	增加”禁止新增一级项”并要求放入独立”待确认建议”区
补出具体数值（如”3 秒内响应”）	未约束业务参数编造	明确要求无依据填”待确认”，并在校验脚本中标记未溯源的数值
截图识别反复出错	上下文已被错误结论污染	新开会话、最小化提问、两次独立结果一致才采信
输出格式忽好忽坏	未启用结构化输出、模板不稳定	固定模板并版本化，启用平台的结构化输出能力
同一输入多次结果差异大	采样温度过高	温度降至 0~0.3，固定随机种子（如平台支持）
多轮后文档越改越乱	每次都在上一次输出上追加修改	每轮都以原始骨架为基线重新生成，人工确认后再落库

九、优化建议

成本控制：优先分批而非整篇生成，失败只重试失败批次；对骨架与规则部分做提示缓存；简单补充任务可用较小规格模型，复杂推理与跨模块一致性判断再用大规格模型，形成分级路由。

稳定性：把提示词模板纳入版本管理，每次修改都跑评测集；对模型服务设置超时、重试与降级策略；关键文档生成保留人工卡点，不要让自动流程直接进入发布环节。

安全合规：需求文档常含业务敏感信息，上传前应做脱敏（客户名、金额、内网地址、账号信息），并确认所用模型服务的数据处理策略满足企业合规要求。企业内部接入建议走统一网关，便于审计与配额管理。

可维护性：把”骨架文件 + 补全规则 + 输出契约 + 校验脚本 + 评测集”作为一个整体资产维护。这套资产的价值远高于任何单条提示词，换模型时可以整体迁移。

选型建议：与其争论某个模型绝对更强，不如建立自己的评测集横向对比。多模型交叉验证是一种实用手段——对同一输入取多个模型结果，一致部分高置信采纳，分歧部分人工确认。模型能力会持续变化，而评测集与流程资产是稳定投入。

十、总结

本教程的核心观点是：需求补全任务的难点不在”生成得好不好”，而在”边界守不守得住”。要把这件事做稳，靠的不是寻找一条万能提示词，而是三层结构：

1. 骨架层：稳定编号的原始功能清单，作为唯一基准；
2. 契约层：可判定的禁止项 + 结构化输出 + 自动校验脚本，把”别乱改”变成可检测的错误；
3. 证据层：截图类输入强制标注置信度并人工复核，视觉错误不靠争辩解决，靠独立复核解决。

后续可以继续深入的方向包括：把校验脚本接入 CI 流水线做文档回归检查、基于评测集自动搜索提示词变体、以及为不同文档类型（需求、接口、测试用例）建立各自的输出契约模板。如果你在企业环境落地，建议在云服务控制台统一管理模型接入、配额与日志审计，把这套流程做成团队可复用的标准工具链。