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. 当前链路和目标链路

当前实际链路

模板起草页面
  → 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 指南 方法。当前仍使用明确指定的 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 数量目标的正确口径

本轮创建的 扩充清单 包含：

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

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

8.2 第一批 12 个

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

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

8.3 第二、三批的行业范围

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

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

8.4 模板来源策略

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

官方示范文本也需要结合具体交易补充修改；不能把导入或 AI 改编版本标成“官方认可本平台”或“无需核对即可签署”。该边界也见 市场监管总局的介绍。不批量抓取或转载商业合同库的受限内容。

9. 评测与发布验收

9.1 分层评测

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

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

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：30 模板清单、46 Prompt 清单、47 运行资产哈希、14 探针结果与只读统计。
• 证据说明与运行命令。
• 专项审查脚本。
• 模板测试结果：6 通过。
• Prompt 相关测试结果：9 通过。
• 行业扩充与 Prompt 模块清单：规划资产，未实施。

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