ai-contract-platform/project-docs/AI合同平台-模板与Prompt专项审查及优化扩充方案-2026-08-28.md

# AI 合同平台：模板与 Prompt 专项审查及优化扩充方案

> 日期：2026-08-28
> 范围：当前本地前后端、PostgreSQL 实际资产、Chrome 系统管理员会话、源码及隔离测试。
> 承接：《AI 合同平台系统性产品、市场、架构与体验审查报告》（2026-08-22）。
> 性质：产品与工程审查，不是律师签字、法律效力保证或上线批准。

## 1. 结论与建议顺序

模板和 Prompt 确实是合同质量的基础，但当前更准确的质量链条是：

**输入事实 → 场景选择 → 模板/条款 → Prompt 与模型 → 法源检索 → 输出校验 → 版本与使用反馈。**

当前最值得投入的是打通并校准这条链，而不是直接批量增加模板和提示词。

本轮确认的核心问题：

1. **“模板起草”目前是确定性填空，不调用合同生成 Prompt。** 新增生成 Prompt 不会自动改善这个入口。
2. **源码资产与运行资产不一致。** 源码 46 个 Prompt；后台 47 个发布版本，全部为纯文本格式，未包含导入资产的结构化元数据。7 个同名 Prompt 内容与源码不同，另有一个源码资产包中不存在的 `legal_qa.default`。
3. **Prompt 渲染存在二次替换和静默回退。** 用户正文含变量形状或 JSON，可能改变输入或丢失专项提示。
4. **草稿/发布隔离存在缺口。** 同名同版本保存可影响运行版本；前端的“保存草稿”路径还可能让当前版本停用。
5. **模板净化仍有误删和遗漏。** 可能删除用户真实约定，也仍有给生成系统看的说明进入正文。
6. **模板规则大量停留在文字描述。** 金额、日期、争议解决方式等没有形成完整的机器校验。
7. **分类和业务语义需先纠正。** 承揽合同被标为“建设工程”，与该模板自身适用边界相反。

建议按以下顺序实施：

| 顺序 | 阶段 | 主要产出 |
| --- | --- | --- |
| 1 | TP-01 质量底座修复 | 渲染不改事实、不静默换 Prompt；保存草稿不影响发布；正文/说明分离 |
| 2 | TP-02 资产与输出契约统一 | Prompt 元数据、单一输出结构、内容哈希、版本与运行调用对应 |
| 3 | TP-03 高频模板结构化 | 先精修采购、服务、SaaS、委托、NDA、劳动、租赁、承揽 8 个场景 |
| 4 | TP-04 AI 辅助起草接入 | 用现有异步任务能力生成候选版本，保留原稿与差异 |
| 5 | TP-05 第一批扩充 | 新增 12 个高频场景包及对应审查路由 |
| 6 | TP-06 行业深化 | 再做 18 个行业场景，后续 30 个按真实需求排序 |

不需要双云、KMS 或新的模型供应商才能完成上述阶段。模型保持 `gpt-5.6-sol`。10 人可用性测试仍按用户要求暂缓；没有用户数据支持的行业优先级属于产品假设。

## 2. 本轮做了什么、没有做什么

### 已完成

- Chrome 验证管理员工作台、Prompt 中心和模板起草页可正常访问；采购向导为 24 个必填字段、4 步，每步最多 7 项。
- 盘点全部 30 个源码模板与 46 个源码 Prompt。
- 对全部模板运行“只填必填项”和“填写全部字段”两种渲染，共 60 组。
- 通过 PostgreSQL `READ ONLY` 事务查询 Prompt 资产与当前系统工作空间的统计信息。
- 运行原有模板测试 6 项和 Prompt/路由/导入相关测试 9 项，均通过。
- 新建可重复运行的专项审查脚本，14 个定向探针中 1 项通过、13 项暴露缺口。
- 制定分批 60 个新增场景包、14 个新增 Prompt 功能模块的待开发清单。

### 本轮未做

- 未修改业务代码、数据库内容、既有合同、模板发布状态或模型配置。
- 未在浏览器提交合同生成、保存 Prompt、发布或回滚操作。
- 未调用真实模型；没有新的法律准确率、耗时或成本结论。
- 新增场景和 Prompt 模块只是开发清单，尚未实现、导入或发布。
- 未把 AI 复核记作人类律师签字；未验证司法效力、第三方存证或真实双云 UAT。

**13/14 是针对已怀疑边界设计的缺陷探针结果，不能解释为“92.9% 的合同有问题”。** 原有测试全绿与这些缺陷同时存在，说明测试分布需要扩大。

## 3. 资产与真实运行盘点

### 3.1 模板

| 指标 | 结果 | 解释 |
| --- | ---: | --- |
| 源码模板/页面模板 | 30 / 30 | 通常一类一个模板，深度和行业变体不足 |
| 页面业务领域 | 6 | 商务、技术数据、投融资、用工、租赁工程物业、法律文书 |
| 必填变量总数 | 436 | 平均约 14.5 项/模板，不代表每份合同都填 436 项 |
| 可选变量总数 | 325 | 不少是复核说明、证据或合规信息，应与正文变量区分 |
| 60 组基础渲染 | 通过现有正文检查，必填哨兵值均保留 | 使用的是简单合成值，不能覆盖复杂真实输入 |
| 系统空间模板发布事件/编辑草稿/发布快照 | 0 / 0 / 0 | 当前使用源码资产的默认发布状态，不是本轮查到的显式审批发布证据 |

30 个模板中有催告、解除通知、授权、法律意见、股东会决议等法律文书，不应全部宣传为不同合同类型。文书与合同可以共享工作台，但不应强制共享同一种签署、履约、审查输出结构。

高频模板字段负担：采购 24、通用服务 14、SaaS 12、委托服务 7、保密 12、劳动 10、房屋租赁 11、承揽 16。分页降低了单屏负担，但没有降低用户要准备的信息总量。

### 3.2 Prompt

| 源码类别 | 数量 |
| --- | ---: |
| 合同/文书生成 | 31（通用 1 + 专项 30） |
| 合同审查 | 7（通用 1 + 领域 6） |
| 法律问答 | 1 |
| 业务辅助 | 4 |
| 条款推荐、措辞改写、法规影响 | 各 1 |
| 合计 | 46 |

运行数据库有 47 个已启用、已发布的 Prompt 版本。它们都是纯文本，因此前端无法按导入资产结构提取类型、场景、变量与输出 Schema；页面显示“47 已发布、0 类型、0 V1 Phase15”。这不是“后台没有 Prompt”，而是**资产内容与资产元数据未统一**。

同名但正文哈希不同的 7 项：

- `agency_distribution_default`
- `commission_service_default`
- `contract_generation_default`
- `demand_letter_default`
- `labor_service_default`
- `property_service_default`
- `software_saas_default`

另有额外的 `legal_qa.default`。后台默认选中它并标注“当前运行版本”，但法律问答代码优先选择 `legal_chat_default`；当前系统空间查到的 43 次问答记录也关联后者。**同名版本管理视图不等于任务的实际路由视图。**

当前系统空间历史 Trace 统计：法律问答 43 次、合同审查 4 次，分别关联 `legal_chat_default` 和 `contract_review_default`。这是该工作空间当前数据库的历史汇总，不代表其他隔离验收环境，也不能证明全部领域 Prompt 已做过真实模型验收。

### 3.3 模型配置的解释

读取服务设置确认：`provider_call_mode=codex_cli`、`codex_cli_model=gpt-5.6-sol`。数据库中仍有名为 `mock / legal-qa-mvp` 的默认配置记录，但当前代码按 `codex_cli` 选择开发适配器，不能仅凭这条记录认定实际调用的是 mock。

建议后台同时显示“配置记录”和“最终有效适配器/模型”，避免误导。此次没有修改这些配置，也未发起真实推理验证。

## 4. 当前链路和目标链路

### 当前实际链路

```text
模板起草页面
  → POST /templates/{id}/draft
  → 加载已发布模板/源码默认资产
  → 替换变量 → 删除可选片段/内部说明 → 正文规则检查
  → 新合同草稿

合同审查 / 法律问答
  → 按任务/合同类型选择已发布 Prompt
  → 检索法源 → 拼接 Prompt → gpt-5.6-sol 开发适配器
  → 解析与质量检查 → 返回结果 / fallback / 接管
```

证据：`sqlalchemy_template_orchestration.py:282` 的起草路径没有模型调用；`model_jobs.py:21` 的异步操作类型只有 `legal_qa`、`contract_review`，尚无 `contract_generation`。

### 建议目标

保留两种清晰标识的模式：

- **快速模板起草**：输入结构化事实，确定性拼装，速度快且内容可控。
- **AI 辅助起草/完善**：自然语言需求提取、缺失信息问答、行业条款选择、候选版本与修改解释。

AI 模式复用已有后台任务、幂等、取消、重试、历史、质量检查及接管能力。若失败，保留原始填空草稿并显示降级原因；不能把降级结果显示为模型已成功完成。

## 5. 已确认缺陷与整改要求

优先级是本次专项内部排序，不改写原项目 P0/P1 编号。

### F-01：Prompt 二次解释用户数据与静默回退｜阻断级

**证据**：`prompts.py:133、171` 先替换双花括号，再替换单花括号，普通路径还对已经插入数据的完整字符串执行 `.format()`。

隔离复现：

- 用户正文 `原文保留 {counterparty}` 被改成 `原文保留 被替换的公司`。
- 正文包含 `接口格式 {"amount": 100}` 时，“专项约束”消失，使用通用 Prompt。
- 导入 JSON 资产路径也存在二次替换。

**整改**：仅扫描原始模板一次；替换值作为不可再次解释的数据。模板编译与输入校验提前完成；专项模板不合法时返回明确错误和可追踪降级原因，不能无提示退回通用模板。

**验收**：中英文花括号、JSON、模板形状字符串、长正文均保持原始事实；运行 Trace 必须匹配实际使用的模板与内容哈希。

### F-02：“保存草稿”可影响发布版本｜阻断级

**证据**：`persistence/prompts.py:59` 按名称和版本原位更新；前端 `ai-prompts/page.tsx:259、268` 编辑副本仍保留原版本号，保存时发送 `enabled=false`。

隔离 SQLite 复现两个路径：

1. API 默认 `enabled=true` 时，同名同版本的新内容立即成为运行内容，状态仍为 published，发布历史仍只有 1 条。
2. 按前端载荷保存 `enabled=false` 后，该已发布 Prompt 不再能被运行查询选中。

**整改**：发布版本不可原位更改；创建独立 draft ID/新版本；普通保存不得修改发布指针或 enabled；发布/回滚使用原子事务及内容哈希；同版本冲突返回明确错误。

**验收**：正在执行的任务固定 Prompt 快照；保存、取消编辑、并发发布、回滚均不影响无关版本。前端“编辑副本”必须真的创建副本。

### F-03：清理逻辑可能删除真实合同内容｜阻断级

**证据**：`contract_templates.py:308、403、442` 在替换用户值后按标点删除句段。

- `甲方{{甲方}}备注{{补充说明}}。` 只填甲方时，整句连同必填甲方被删。
- 用户填写 `业务系统不得泄露商业秘密`，因命中“系统不得”，真实保密约定被整句删除。

**整改**：将正文条款、可选条件块、内部操作说明分离；在插入用户内容前处理结构化模板，不能用用户文本中的词语决定整句删除。短期增加关键值保留校验，遇到无法安全处理的混合句段明确提示修正，而不是交付残缺正文。

**验收**：必填值不能静默消失；可选块省略要有解释；输入中的“系统不得”等正常业务用语保留；现有 30 个模板无回归。

### F-04：内部说明仍进入正文，检查又误伤正常内容｜高

采购模板实际渲染后仍存在“不得默认生成”“不得自动生成”“必须由业务和法务确认”等写给起草系统的操作语句。相似标记在股权转让、居间、采购、承揽 4 类渲染中可见。

同时，`contract_body_quality.py` 把普通 `【特别提示】` 判为未填写占位符，却漏过 `{{尚未闭合`。

**整改**：先迁移资产结构，不继续无限扩展关键词删除表；对真实占位符使用结构化类型/编译结果识别。未闭合语法必须拦截，正常法律强调样式可保留。对正文/说明分类仍不确定的内容放进审阅区，不直接删除或写入签署正文。

### F-05：发布校验可放过无法渲染的模板｜高

`lifecycle_helpers.py:356` 把未知变量设为 warning；隔离样本校验 `valid=true`，随后起草却抛出未声明变量异常。

**整改**：未知变量、语法错误、必填/可选重复定义设为编译错误；发布前运行必填、全字段、空可选、边界输入样本；校验结果绑定待发布内容哈希，不能拿旧结果发布新内容。

### F-06：金额、日期与互斥规则未实际执行｜高

`ContractTemplateVariable` 只有名称、标签和 required；`validation_rules` 是字符串清单。采购样本中“数量 10、单价 100 元、总价 1 元、日期 2026-02-30、仲裁与法院同时选择”仍可渲染成功。

这是**没有执行模板自述的规则**，本次并未据此判断某个真实合同的法律效力。

**整改**：建立 typed fields 与机器规则：Decimal 金额/币种/含税口径、日期与期限、主体类型、枚举、数组、条件必填、字段依赖和互斥。金额差额允许真实折扣、税额等解释，但要显式记录；不要机械认定所有差额违法。

### F-07：多个版本的审查输出契约互相矛盾｜高

实际 7 个审查 Prompt 要求 `basic_info、clauses、risk_summary、review_opinion、rendered_report` 等旧结构；运行附加指令要求 `summary、risk_level、risk_items`，后端又 `extra=forbid`。

两套约束同时存在，模型可能遵守旧格式而被新解析器拒绝。**本轮验证了契约冲突，未测量由此造成的真实模型失败比例。**

**整改**：输入 DTO、输出 Schema、提示词输出说明、解析器、前端展示由同一个版本化契约生成/引用；新建兼容迁移版本，不直接覆盖历史资产。

源码 46 个 Prompt 的输出 Schema 都存在未定义 `items` 的数组字段，说明这些 Schema 还不能充当完整严格校验规范；不能把“有 output_schema 字段”等同于运行时已强制约束。

### F-08：无风险、证据不足和商业风险未被正确区分｜高

`ProviderContractReviewPayload` 要求至少一个风险项；附加指令要求每项必须有检索法源，未获支持的发现不得输出。

这可能导致“未发现明确风险”无法作为有效结果，也会压制单纯由合同自身可观察的矛盾，例如价格汇总不一致。这里的实际遗漏率尚未通过新模型样本评测。

**整改**：区分 `legal_risk`、`contract_inconsistency`、`negotiation_preference`；分别记录法源、合同原文定位和商业理由。增加 `no_findings`、`insufficient_evidence`、`incomplete_review`，不把它们混成 low risk。零风险项只有在审查范围完整、依据状态明确时才可正常结束。

不能为放宽范围而取消来源约束；应把“无依据的法律判断”与“无需援引法条的文本矛盾”分开处理。

### F-09：立场、行业、交易阶段没有成为一等输入｜高

审查请求没有 `party_position` 字段；渲染器固定为中立立场。采购、通用服务、委托、承揽、居间、催告、解除通知 7 类只走通用候选；其余领域映射也仍较粗，例如销售被放在渠道/加盟领域。

**整改**：输入明确我方角色、行业、合同阶段、地区、金额口径和企业 Playbook 版本。立场用于解释可谈判安排，不得改变事实或屏蔽强制规则。先建立精确路由，再增加 Prompt。

### F-10：承揽被标成建设工程｜高

`contract_templates.py:240` 把 `works` 显示成“建设工程”。Chrome 实际显示“承揽合同模板 · 建设工程”；源码模板明确写“建设工程不适用本模板”。

**整改**：既有 `works` 兼容保留并显示为承揽；真正的建设工程使用独立类型与资产。核对前端分类、检索、审查路由和历史统计映射，不批量改写既有合同类型而不留迁移记录。

### F-11：源码草案默认等于已发布，缺少发布证据｜高

`apply_template_lifecycle_state()` 在没有事件时默认 published。当前系统空间未发现模板发布事件或快照，页面却显示全部 30 个已发布，其中源码版本仍为 `LEGAL_REVIEW_DRAFT_*`。

不能从“无事件”断言从未有人看过这些文本，但**没有本轮可核验的内容审批/评测发布凭据**。

**整改**：区分内置演示资产、可编辑草稿、内部试用、受控发布和停用；旧数据迁移保留来源，不伪造历史审批。新增资产默认 draft，不能丢进当前自动 published 的目录就算上线。

### F-12：字段用途与适用边界没有独立建模｜中高

采购的 `特殊监管说明` 仅位于“使用边界”章节，而正文提取器会截去该章节。因此它没有进入渲染正文；这可以是正确设计，但必须作为风险路由输入被明确消费，而不能只作为表单上的一个普通可选值。

本轮确认它不参与正文渲染，并且起草函数没有执行相应监管分流；未声称该值在整个系统所有存储位置都丢失。

**整改**：变量分为正文事实、条件控制、解释说明、证据材料四类；适用/排除边界机器可读，按条件显示专项路径。

### F-13：行业覆盖宽、单场景深度不足｜中高

多数类型只有一个模板，没有买卖双方、签约阶段、交易结构、行业和地区组合。物流仓储、设备维保、广告设计等常见 B2B 场景未形成独立入口；建设工程看似覆盖，实际资产不适用。

**整改**：采用“基础合同类型 + 行业条款包 + 立场 + 阶段 + 地区/监管条件”。不复制几百份只有标题不同的长文；扩充范围详见第 8 节和 JSON 清单。

### F-14：质量、法源与业务覆盖指标尚未连接｜中

目前数量、版本和规则数量可见，但管理员难回答：“哪个场景最近表现差、实际用了哪个 Prompt、需要修改什么、修改后是否改善？”部分 Prompt 内硬编码法条编号，与检索法源更新有漂移风险；本轮未逐条认定其引用错误。

**整改**：展示任务路由、近 30 天调用、失败原因、样本覆盖、内容版本、法律来源及核验时间；法条编号和有效性由可追溯法源资产维护。模板/Prompt 每次发布与其评测结果绑定。

## 6. 推荐的产品与技术设计

### 6.1 模板资产结构

每个场景至少包含以下可机器读取的部分：

| 部分 | 作用 |
| --- | --- |
| manifest | 稳定 ID、名称、基础类型、行业、地区、版本、状态、来源 |
| applicability | 适用条件、排除条件、特殊监管路径 |
| fields | 字段类型、标签、示例、条件必填、敏感程度、默认值来源 |
| clauses | 正文条款块、显示条件、条款依赖/互斥、可编辑区域 |
| instructions | 起草解释、风险提示、AI 操作要求；不进入签署正文 |
| evidence | 模板/Prompt/法源/Playbook 版本与内容哈希 |
| fixtures | 正常、缺项、反例、对抗、边界样本及预期结果 |

采用渐进迁移：先让旧模板经适配器正常工作，再迁移 8 个高频场景；不一次重写全部合同数据。签署用正文可继续输出 HTML/Word，但富文本必须转义或净化，不能信任模型返回的任意 HTML。

### 6.2 Prompt 组织

建议分成共享任务规则、场景/行业规则、结构化输入、检索来源和单一输出契约。输入中的合同条款、附件文字、URL 或“忽略前述要求”均按资料处理，不成为新的运行指令。

保持 Prompt 与代码一起版本化，输入经类型校验，发布时运行代表性样本；这是本方案采用的 [OpenAI Prompt 指南](https://developers.openai.com/api/docs/guides/prompting) 方法。当前仍使用明确指定的 `gpt-5.6-sol`，不因重构自动换模型。

推荐的输入关键项：`document_kind、contract_type、industry、party_position、jurisdiction、transaction_stage、facts、missing_facts、template_snapshot、playbook_snapshot、retrieved_sources`。

推荐输出：`draft_document、missing_fields、assumptions、risk_notes、source_bindings、change_explanations、quality_findings`。签署正文与系统解释分别保存；事实未提供时不擅自补齐金额、日期、主体或历史行为。

不把这些模块设计成十几次顺序模型调用。通常合并为一次起草请求，复杂或高风险场景再增加独立检查；金额与日期等确定性规则不必消耗模型。

### 6.3 起草体验

1. 先选“想办什么事”，按自然语言推荐 1–3 个候选，并解释不适用条件。
2. 首屏只问决定合同结构的 5–7 项事实，允许保存和形成明确标记未完成的草稿。
3. 金额、日期、付款计划、争议路径改为结构化控件；不让用户在一大段文本中自行拼装。
4. 根据事实展开必要细节，企业主体可复用；AI 识别值显示来源并允许修改。
5. 新候选版本展示差异、依据和待确认事项；保留确定性初稿与上一版。
6. 缺项提示分成“可稍后补”“签署前必须补”“该模板不适用”；不把所有提示都变成阻断。
7. 未通过交付检查的合同可以继续编辑，但不能伪装成已完成审查或可直接签署。

不要只把 24 项分成 4 页后仍宣传“7 个问题完成”；统计首次预览、补全、可交付三个时间点。

### 6.4 AI 优先与必要接管

按用户偏好，常规信息提取、条款选择、事实一致性、来源匹配、风险解释和版本比较默认自动执行。接管集中在事实无法确认、来源冲突、无适用模板、特殊资质或重大法律不确定性，而不是每份普通草稿都要求人工逐项签字。

AI 检查结果须如实记录为 AI；同一个模型自评与生成可能共享盲点，应结合确定性规则、对照样本和后续专家校准。没有足够证据时明确显示“待确认”，而不是自动写“法务已同意”。

## 7. 优先精修的 8 个现有场景

| 场景 | 首批重点 | 自动检查重点 |
| --- | --- | --- |
| 采购 | 货物行项目、税价、验收与付款条件 | 数量价格、交付日期、账户变更、争议路径 |
| 通用/技术服务 | 服务范围、交付物、边界、变更单 | 范围/验收/付款是否相互对应 |
| SaaS | 授权量、期限、续费、数据退出、SLA | 费用期间、服务补偿、数据删除/交接 |
| 委托服务 | 授权事项、指示变更、利益冲突 | 授权范围与履约行为一致 |
| NDA | 单向/双向、信息范围、披露权限 | 接收方/披露方角色、期限和例外 |
| 劳动 | 合同类型、岗位、期限、报酬与地区 | 日期与期限、条件必填；按已核验规则判断 |
| 房屋租赁 | 住宅/商业用途、费用、交还 | 租期、租金频率、押金、修缮责任 |
| 承揽 | 材料、成果、模具图纸、验收、转承揽 | 与工程明确区分，成果与标准对应 |

精修不等于仅增加篇幅。每个场景要有正例、缺项例、矛盾例、相反立场例、特殊条件例，并明确“完成了什么、仍不支持什么”。

## 8. 行业与数量扩充方案

### 8.1 数量目标的正确口径

本轮创建的 [扩充清单](template-prompt-expansion-backlog-20260828.json) 包含：

- 第一批 12 个新增场景；若全部验收并保留现有资产，场景数由 30 到 42。
- 第二批 18 个，累计目标 60。
- 第三批 30 个，累计目标 90；按真实需求、专业边界和内容供给决定实际进入顺序。
- 14 个新增 Prompt 功能模块，包括 6 个起草辅助模块和 8 个专项审查模块。

以上均为规划数，不是已发布数。行业变体按“场景包”计数，不虚增基础合同法律类型；长期目标是可组合覆盖，不承诺穷尽所有行业、地区、监管条件和交易结构。

### 8.2 第一批 12 个

货物运输、仓储、设备经营租赁、设备维保、委托加工/定作、广告制作发布、市场推广、平面品牌设计、软件运维、商铺租赁、劳动合同变更、合同补充变更。

这些场景贴近原报告中的成长型企业客户定位，能复用采购、服务、租赁、承揽等既有基础；该排序仍需后续使用量与用户需求验证。

### 8.3 第二、三批的行业范围

第二批深化冷链、电商仓配与代运营、直播营销、餐饮连锁、检测、技术咨询/转让、数据提供/标注、会展、企业培训、人力资源服务、商业物业、装修/建设工程、企业融资与债权管理。

第三批覆盖农业、食品、住宿旅游、家政养老、体育与预付消费、房地产、工程专业服务、能源节水、新能源、环保、医疗器械/医药、跨境贸易、公共采购、法律财税与文化传媒。强监管领域独立建模，不用“通用服务”冒充已经覆盖。

### 8.4 模板来源策略

优先核对国家和地方主管部门公开示范文本、企业授权历史文本、既有优质模板；每次改编记录来源、适用地区、版本和变更点。市场监管总局的 [合同示范文本库](https://htsfwb.samr.gov.cn/) 提供按地区、分类和年份检索的官方入口，可作为扩充的来源之一。

官方示范文本也需要结合具体交易补充修改；不能把导入或 AI 改编版本标成“官方认可本平台”或“无需核对即可签署”。该边界也见 [市场监管总局的介绍](https://www.samr.gov.cn/xw/zj/art/2023/art_565d7b08b2bd4921bb093a12a49f4853.html)。不批量抓取或转载商业合同库的受限内容。

## 9. 评测与发布验收

### 9.1 分层评测

| 层级 | 内容 | 建议最低要求 |
| --- | --- | --- |
| 编译/结构 | 变量、条件块、依赖互斥、输出 Schema、元数据 | 可发布资产全部通过 |
| 确定性质量 | 日期金额、正文污染、必填值保留、分类、发布隔离 | 本次 13 个缺口修复并新增针对性回归 |
| 场景覆盖 | 每个场景正常/缺项/边界/对抗/立场样本 | 每新增场景至少 10 例；第一批 12 个至少 120 例 |
| 真实模型 | 起草/审查输出、引用、完整性、事实保持 | 每新增场景至少 3 例；第一批至少 36 例，不是统计上充分的上线保证 |
| 用户体验 | 首次预览、可交付耗时、补问轮次、放弃原因 | 按实际用户旅程统计，不能仅测渲染函数耗时 |

先冻结样本和预期，再比较旧版本与候选版本；保留独立未参与调参的测试集。按场景、风险、立场、输入长度分别看结果，不以总体平均值掩盖某一行业的失败。该做法参考 [OpenAI 评测指南](https://developers.openai.com/api/docs/guides/evaluation-best-practices)，本项目使用本地评测资产，不依赖特定云端评测产品。

### 9.2 建议的试点门槛（目标，不是已达成）

- 发布的确定性测试 100% 通过；未知变量、静默删事实、版本越界为阻断项。
- 真实模型样本的结构有效率至少 99%、关键事实保持率至少 99%、虚构来源为 0；小样本必须同时展示分子/分母，不能只报百分比。
- 每条法律结论可追溯到支持它的具体来源；“有引用”不等于“引用支持结论”。
- 重大风险漏检用冻结的对照案例测量；未识别出的风险不能靠模型自报低风险算通过。
- 起草中位总耗时目标仍为 3 分钟；拆分填写、排队、推理、校验、重试，超时不静默重试制造重复任务。
- “可交付率”分母包含失败、降级和接管任务，不能仅统计成功返回的内容。
- 保留开发/测试通道，生产真实用户开放仍遵守现有产品发布条件；本报告不解除此前上线边界。

## 10. 可直接进入开发的任务单

| 任务 | 工作范围 | 验收重点 | 依赖 |
| --- | --- | --- | --- |
| TP-01A | Prompt 单次替换，明确输入错误，去掉无声回退 | F-01/F-07 相关反例；原有路由仍可用 | 无 |
| TP-01B | Prompt draft/published 隔离与前端编辑副本 | 保存不换运行版本；并发与回滚 | 无 |
| TP-01C | 模板安全编译、说明分离、质量检查 | F-03/04/05；30 模板渲染回归 | 无 |
| TP-02 | 统一资产 manifest 与输出契约、可追踪迁移 | 新旧内容差异、版本哈希、运行路由一致 | TP-01A/B |
| TP-03 | typed fields、机器规则、8 个精品场景、承揽纠偏 | 条件字段、异常金额日期、适用边界 | TP-01C |
| TP-04 | 异步 AI 起草、候选版本、差异与降级 | 幂等/取消/重试，原稿不变 | TP-02/03 |
| TP-05 | 第一批 12 场景、6 起草模块、采购/服务/制造/物流等路由 | 120 确定性例 + 至少 36 真实模型例 | TP-02/03/04 |
| TP-06 | 场景质量看板与后续行业批次 | 无结果搜索、成功率、修订率与需求排序 | TP-05 |

第一轮建议只处理 TP-01A/B/C，并完成承揽标签与旧审查输出契约的纠偏。先恢复“输入不被悄悄修改、保存草稿不影响运行、正文可追溯”的可信基础，再扩充内容。

## 11. 证据、复现命令和后续交接

- [完整审查证据 JSON](../docs/qa/template-prompt-audit-20260828/evidence.json)：30 模板清单、46 Prompt 清单、47 运行资产哈希、14 探针结果与只读统计。
- [证据说明与运行命令](../docs/qa/template-prompt-audit-20260828/README.md)。
- [专项审查脚本](../yuqei-infra/scripts/audit-template-prompt-foundations.py)。
- [模板测试结果](../docs/qa/template-prompt-audit-20260828/contract-tests.xml)：6 通过。
- [Prompt 相关测试结果](../docs/qa/template-prompt-audit-20260828/ai-tests.xml)：9 通过。
- [行业扩充与 Prompt 模块清单](template-prompt-expansion-backlog-20260828.json)：规划资产，未实施。

代码定位均基于本轮开始时的工作区版本；后续修复会改变行号。此次仅新增报告、清单、只读审查工具和证据，未提交或推送 Git，也没有动现有合同和发布内容。