施工方案评审·云端版
下载地址
https://www.zhengdianxue.com/wp-content/uploads/skills/org-09tvxwmg--construction-plan-review-cloud.zip将提示词发送给你的 AI 安装该 skills
请根据 https://skillhub.cn/install/skillhub.md,安装 @org-09tvxwmg/construction-plan-review-cloud。施工方案合规评审助手 · 云端版(SkillHub Pay Skill:X402 对话内闭环支付,0.01 元/次,支付授权由 weixinpay 插件在对话内完成)。当用户要求评审/审查/把关/审阅施工方案、报审稿、专项方案时使用。适用:覆盖全部 9 类危大工程专项施工方案——基坑工程、模板支撑体系工程、起重吊装及安装拆卸工程、脚手架工程、拆除工程、暗挖工程、建筑幕墙安装工程、人工挖孔桩工程、钢结构安装工程。
依据:《危险性较大的分部分项工程安全管理规定》(住建部令第 37 号)、《危险性较大的分部分项工程专项施工方案编制指南》(建办质〔2021〕48 号)、《危险性较大的分部分项工程专项施工方案严重缺陷清单(试行)》(建办质〔2024〕63 号)。交付:评审报告 docx(预审概况 + 逐章检查项评定 + 问题定位与修改建议 + 审核结论 + 整改清单)。
计费:0.01 元/次 · 对话内直接付款,无需跳转
阅读全文 (展开查看完整说明)
概述
定位
本技能是「施工方案评审专家」的云端分发形态:评审引擎(规则库 + 预筛算法)托管在自有服务器,脚本/规则库永不外发;端用户拿到本技能即可评审,无需安装连接器、无需配置环境。评审智能(合规核查规则 + 报告模板 + Few-Shot)全部内嵌于本技能(SKILL.md 薄 + references 按需加载)。
架构:
用户方案 → 本技能编排 → 付费端点(云端 paid_review,https://mcp.sleeplessrealm.cn)→ 402(X402 支付授权:weixinpay_pay 拉起微信支付 AI 专属卡)→ 查单履约(预筛+校验+docx)→ 交付服务器端点契约见
references/api-spec.md;付费端点契约见下文步骤 0(官方 X402 四步),以本文件为准。
服务端点(后端服务)
本技能为 SkillHub Pay Skill:源文件依赖后端服务,脱离后端无法独立使用。全部评审能力(预筛 + 结构校验 + 工单生成 + docx 渲染)均由下述自有后端服务提供,客户端脚本与规则库不随包外发。
| 项 | 值 |
|---|---|
| 服务地址(业务端点 · 唯一) | https://mcp.sleeplessrealm.cn/api/v1/skills/paid_review/review |
| 基础 URL | https://mcp.sleeplessrealm.cn |
| 请求方式 | POST(Content-Type: application/json) |
| 传输协议 | JSON over HTTPS(443 · Let's Encrypt 证书自动续期) |
| 鉴权 | 业务调用由 Authorization: Bearer <temp_token> 标识(api_client.py 自动签发与续期,端用户零配置);X402 支付挑战本身不要求鉴权 —— 任何调用者发起首次请求都必须能看见 402 支付要素 |
| 支付触发标识 | 未获支付授权时返回 HTTP 402,响应头同时携带 WeixinPay-Required(X402 payment_code)与 X-Out-Trade-No,响应体含 WeixinPay 提示块 |
| 计费 | ¥0.01 / 次(与服务端 402 账单金额一致 · 微信支付 AI 专属卡对话内代扣,无需跳转) |
服务登记信息(平台 / 第三方核验用,与表单登记项一一对应)
| 字段 | 值 |
|---|---|
| 服务名称 | 施工方案合规评审(云端) |
| 服务类型 | 按次调用(WeChat Pay · X402 协议) |
| 服务地址 | https://mcp.sleeplessrealm.cn/api/v1/skills/paid_review/review |
| 请求方式 | POST · Content-Type: application/json |
| 服务单价 | 0.01 元/次(与服务端 402 账单金额一致) |
| 服务描述 | 上传施工方案全文,云端引擎逐条核查并返回评审结果与工单 |
| 请求示例 | curl -i -X POST -H 'Content-Type: application/json' -d '{}' https://mcp.sleeplessrealm.cn/api/v1/skills/paid_review/review |
链路自检(官方验收口径):上述请求示例在未支付状态下必须返回 HTTP 402,且响应头同时含 WeixinPay-Required 与 X-Out-Trade-No、响应体含 WeixinPay 块。返回 401 / 404 / 其它状态码一律视为「后端支付服务不可核验」。
内部支撑接口(非 X402 挑战链,仅本技能脚本调用,勿作服务地址登记):/api/v1/issue-token(令牌签发)、/api/v1/skills/paid_review/render_docx(报告渲染)—— 均相对上述基础 URL 拼接。
调用统一由
scripts/api_client.py发起,Base URL 默认取上述域名(环境变量REVIEW_API_BASE可覆盖)。完整接口契约见
references/api-spec.md。
触发条件
用户表达评审施工方案意图(评审/审查/把关/审阅施工方案、报审稿、专项方案等),或要求使用"云端版/分发版"评审能力时触发。
依赖声明(SkillHub Pay Skill · 官方 X402 对话内闭环)
本技能为 SkillHub 付费技能(Pay Skill),支付走官方 X402 对话内闭环,由 scripts/api_client.py 承载:
- 付费端点:
POST https://mcp.sleeplessrealm.cn/api/v1/skills/paid_review/review(基础 URLhttps://mcp.sleeplessrealm.cn); - 未获支付授权 →
HTTP 402,响应头携带WeixinPay-Required(X402 payment_code)与X-Out-Trade-No,
body 含 WeixinPay 提示块;api_client.py 读取响应头并将二者写入 402 信封(<--out>.pending402.json);
- 支付授权由
weixinpay_pay(paymentCode)在对话内完成(微信支付 AI 专属卡),无需跳转、无需扫码; - 支付成功后按同一参数重试(Headers 带
WeixinPay-Required+X-Out-Trade-No)→ 服务器查单 → 200 履约。
官方链路(SkillHub《升级为 Pay Skill》):
「① 企业服务生成微信支付订单 → ② 用 SkillHub 开发者密钥签名,调用 X402 AI 预下单换取
payment_code→ ③ 通过
WeixinPay-Required返回给 Agent → ④ Agent 向用户申请支付授权,然后继续获取付费内容」
工作流程
0.0 付费(官方 X402 四步 · 顺序不可乱)
端部 AI 收到 退出码 42(402 付费门禁)时,严格按以下四步执行:
- 付费前置检查:确认当前环境已安装
weixinpay插件。
未安装 → 明确告知用户「当前 Agent 暂不支持微信支付付费能力,请更换支持的环境后重试」,终止流程(不降级、不绕过、不伪造凭证)。
- 读取支付参数:从 402 信封取
payment_code(=响应头WeixinPay-Required,脚本已代读,HTTP 头大小写不敏感)
与 out_trade_no(=响应头 X-Out-Trade-No)——两者都必须保存。
- 向用户申请支付授权:以
payment_code作为paymentCode调用weixinpay_pay,
在对话内拉起微信支付授权(官方 AI 专属卡)。调用前先在同一条消息里向用户说明:本次评审为云端服务,收取 0.01 元服务费,付款后自动继续(严禁无声弹卡)。
- 支付成功后重试(⚠️ 最易遗漏的一步):以与第 2 步完全一致的参数重新调用同一接口,
Headers 同时携带 WeixinPay-Required + X-Out-Trade-No(脚本参数 --out-trade-no <out_trade_no>,脚本自动带双头)→ 服务器微信查单 SUCCESS → 200 履约。不重试将永远拿不到评审结果。
任一环节失败(未装插件 / 用户取消 / 服务器未下发 WeixinPay-Required)→ 告知用户并停止。
重试返回异常码时的处理(SkillHub Pay 约定,必须照做)
| 返回 code | 含义 | Agent 必须怎么做 |
|---|---|---|
NOT_PAID | 支付尚未到账(刚付完很常见) | 等待 3–5 秒后带同样的 X-Out-Trade-No 再次重试,最多 3 次;严禁重新下单(重下单会生成新订单,用户已付的那笔再也取不到内容) |
REFUNDED | 商户服务异常,已自动全额退款 | 告知用户「该服务暂时无法提供内容,已自动退款至原支付账户」,立即终止流程——不得重试、不得重新发起支付 |
FULFILL_AND_REFUND_FAILED | 业务失败且退款也失败(最坏情况) | 记录 out_trade_no,提示用户联系客服人工处理,立即终止流程 |
退出码契约
| 码 | 含义 | AI 应如何处理 |
|---|---|---|
| 0 | 履约成功(200) | 继续评审编排(步骤 2 起) |
| 1 | 业务/校验失败(非 402) | 报错并停止 |
| 3 | 鉴权失败(拿不到端点 token) | 报错并停止,⚠️ 不可当作付费门禁处理 |
| 42 | 402 付费门禁 | 执行上述官方四步(信封含 payment_code / out_trade_no) |
⚠️ 42 与 3 必须区分:3 是鉴权失败(
resolve_token),与 402 无关。
调用形态
# 第 1 次:请求资源(未支付预期 exit 42,信封落盘 result.json.pending402.json)
python "<本技能根>/scripts/api_client.py" paid_review --plan-text "<方案全文.txt>"
[--type "<方案类型>"] [--slices-dir "_slices"] [--no-baselines] --out "result.json"
# 第 2 次:支付授权成功后重试(脚本自动携带 WeixinPay-Required + X-Out-Trade-No 双头)
python "<本技能根>/scripts/api_client.py" paid_review --plan-text "<方案全文.txt>"
--out-trade-no "<信封 out_trade_no>" --out "result.json"--slices-dir 上送切片目录,使服务器生成的工单路径与本地对齐;--no-baselines 省约 1.4 MB/次双基线传输(ch2 比对改走服务器 --server,见 4.3)。
履约结果消费:200 后 data.content 含 prefilter(预筛)/ validation(校验明细)/ task_books(服务器工单)/ 可选 docx_b64;api_client.py 自动落盘 16 份任务书 + _task_books.json。自步骤 2 起逐段消费。
订单标识与残留清理
out_trade_no属订单标识:禁复述 / 禁入日志 / 禁入交付物;脚本在流程结束时自动清理运行时信封。- 402 字段(
payment_code/out_trade_no/amount)一律以服务器返回为准,客户端不臆造、不硬编码。 - 用户取消或未完成支付 → 明确告知「本次评审需 0.01 元服务费,完成付款后即可继续」,
不中断其他能力(图片识别等本地环节照常)。
1. 本地读取方案
用户提供方案 .docx 本地路径 → 用 scripts/extract_plan_text.py 提取全文(段落+表格保序、行号化,供评审引用页码)。
python "<本技能根>/scripts/extract_plan_text.py" --input "<方案.docx>" --output "_plan_fulltext.txt"1b. 图片识别环节(强制 · 反幻觉查图底座 · 零视觉架构)
解析后、付费请求前必走(防止"判缺图前未查图"反幻觉漏洞;2026-08-24 固化,同步自原专家包节点2b)。本技能采用"零视觉"架构:图片环节零视觉子智能体——证据链 = 正文图注(唯一权威)+ 连接器 OCR(二次印证)。(评审三底线"不审图",判"有无 XX 图"以正文图注为准,OCR 佐证防图文不符):
# ⓪ docx 内嵌图提取(必做前置)
python "<本技能根>/scripts/extract_docx_images.py" --docx "<方案.docx>" --out-dir "_方案附图"
# ① 图源归集:docx 内嵌图 + 独立图纸 → image_catalog.json(缺图/孤儿双向预警)
python "<本技能根>/scripts/image_check.py" --plan-dir "<方案所在目录>" --fulltext "_plan_fulltext.txt"
--docx-images-dir "_方案附图" --out "image_catalog.json"
# ② 单次前置分类(先筛有用,再扫描):
# exclude(计算书附图/效果图,不看也不扫) / ocr(图注强证据=有用→扫描) /
# skip(弱证据=示意/照片/流程等,不看也不扫;无证据=存疑默认不看,入存疑清单交章节评审按需补看)
# 宽度(display_ratio)仅作参考字段,不作为准入依据(实测宽度会放进照片)
python "<本技能根>/scripts/image_filter.py" --catalog "image_catalog.json" --docx "<方案.docx>"
# ③ 只对 filter_decision=ocr 的【有用图】跑 xParse 连接器 OCR(free 路由,不占主模型配额):
# xparse-cli --profile workbuddy task run --files '<待OCR图目录>/*' --api auto
# (先复制/改名 stem=catalog file stem,或导出后用 --map 映射;导出 md 到 _ocr_result/)
# ④ 合并 OCR 结果 → 证据分级收尾(零视觉):confirmed-by-ocr(OCR 直接确认) /
# confirmed-by-ocr-caption(残留印证,图注×OCR双重证据) / ocr-only-evidence(仅正文图注单层,
# 评审按正文图注引用即可) —— 不生成任何视觉任务书
python "<本技能根>/scripts/merge_ocr_results.py" --catalog "image_catalog.json" --ocr-dir "_ocr_result" [--map "_ocr_map.json"]⚠️ 步骤 ⓪ 不可省略(2026-08-30 事故修复):
image_check.py的图源 A 不解压 docx,只消费一个已提取好的图片目录。若跳过 ⓪,它会静默报告"docx 内嵌截图 0 张"——
实测某方案 docx 实含 132 张图,跳过 ⓪ 时输出 0 张 ⇒ catalog 闸门被绕过,
九章评审子智能体据此误判"方案无图",正是图片识别环节要防的事故。
extract_docx_images.py同时产出_docx_media_rid_map.json(每张图在正文的段落定位),供评审结论引用"图在正文哪一段"。
⚠️ 不派发任何图片识别子智能体(本技能不审图)。旧路径
gen_image_agent_prompts.py --fallback-only/merge_image_observations.py保留但不再用于评审流水线(deprecated)。章节评审的"反幻觉查图"改为:判"方案无 XX 图"前必须以正文图注为准 grep 全文(图注在chN_plan.txt里可检索),catalog 的 OCR 记录(ocr_text/admission)作二次印证;禁止凭"没看图"断言缺图——图注是证据,OCR 是佐证。
闸门:①前置分类即唯一证据判定(image_filter):图注强证据(平面/布置/剖面/断面/大样/节点/监测/详图/构造)才进 OCR;弱证据(示意/照片/流程/计算书/附录等)与无证据图在扫描前拦截(实测 45→22 张扫描量);②证据分级收尾(merge_ocr):confirmed-by-ocr / confirmed-by-ocr-caption(双重证据)/ ocr-only-evidence(仅图注单层,评审按正文图注引用)——零视觉智能体;③判"方案无 XX 图 / 未提供 XX 图"前必须查正文图注 + catalog OCR 记录,禁止凭正文未见断言缺图;④OCR 判型只作"存在性+图名"印证,参数精确值仅采信结构化表格(table_ok)输出;⑤存疑清单(admission=uncertain)默认不看,由章节评审"必备图核查清单"按需补看承接。
本地执行、不额外计费。图片观察结果(image_catalog.json)可作为
params传入付费端点(服务器 prefilter 消费)或用于客户端展示。
2. 服务器履约结果消费 · 预筛展示(Stage0)
付费端点履约结果 content.prefilter(服务器执行,客户端展示预筛概览;逐章深度走查见步骤 4)→ 客户端直接展示:
- 类型识别 + 危大判定(依 37 号令附件1+2 / 504号细则独立判定)
- 参数级筛选:逐行五态标签(保留_强制 / 保留_涉及 / 保留_通用 / 筛除_留痕 / 待核实)
- 章分配:动态定位九章边界,产出各章条文子集
3. 服务器履约结果消费 · 校验明细展示
付费端点履约结果 content.validation(服务器执行)→ 客户端直接展示校验明细:
- 结构校验 C0-C4 + S2①/S4 + 一票否决 + 落明细 + schema + ch4 过松 + S0.5 工艺适用性(与 /validate 闸门同规则集)
- 明细逐条呈现,保留修改示例(出处+位置+完整修改文本),供整改清单直接使用
4. 端部九章评审编排(付费履约后 · 复用 prep 流水线 · 评审推理在端部)
数据边界:付费履约返回
content.prefilter(含chapter_slices:当次适用条文子集,按 48 号文九章中文章名分组)+content.validation(12 闸门)。端部只拿到当次适用子集;评审推理(LLM 逐章走查)在 WorkBuddy 端执行(token 用户可控)。本步骤复用已测流水线,端部切片与服务器chapter_slices契约一致。
4.0 解包 prefilter(履约信封嵌套解包:data.content.prefilter → 顶层 prefilter.json):
python "<本技能根>/scripts/extract_prefilter.py" --result result.json --out prefilter.json4.1 九章切片:prep_slices.py 消费 prefilter.json 的 chapter_slices(键=工程概况/编制依据/施工计划/施工工艺技术/施工安全保证措施/施工管理及作业人员配备分工/验收要求/应急处置措施/计算书及图纸,逐字对齐服务器九章口径),产出 _slices/chN_rows.json(跳过筛除_* 双保险)+ chN_plan.txt(动态章边界)+ 对象参数表.json + slice_meta.json:
python "<本技能根>/scripts/prep_slices.py" --prefilter prefilter.json --plan _plan_fulltext.txt --outdir _slices4.2 任务书生成(优先消费服务器工单):prep_subagent_tasks.py 为 ch1~ch8 各生成评审 + 自检任务书(ch9 走硬节点不派发)。工单默认已由服务器生成(步骤 0 履约响应 content.task_books,api_client 已自动落盘 _task_books.json),本步仅消费落地:
python "<本技能根>/scripts/prep_subagent_tasks.py" --slices-dir _slices --outdir _slices --from-server "<履约结果.json 或 _task_books.json>" [--image-catalog image_catalog.json]--from-server 指向步骤 0 的 --out 履约结果(或落盘的 _task_books.json):只消费服务器工单(单源真相、路径自动对齐本地 slices-dir);文件缺失/解析失败必须阻断报错(exit 3)——工单只由服务器派发,端部禁止本地生成兜底。
4.3 ch2 硬节点(编制依据三态比对 · 优先服务器比对):派发 ch2 评审子智能体前必跑——①主代理/Agent 读 _slices/ch2_plan.txt 抽取方案引用规范清单写 01b_citations_ch2.json;②跑比对引擎产 ch2_reconciler_out.json,ch2 子智能体消费它(禁自行上网/自造规范号):
python "<本技能根>/scripts/ch2_standards_reconciler_cloud.py" --citations 01b_citations_ch2.json --ch2-rows _slices/ch2_rows.json --server --out _slices/ch2_reconciler_out.json--server(A2):三态比对改由服务器 /reconcile_ch2 完成(配合步骤 0 --no-baselines 省约 1.4 MB/次),结果与端部本地比对逐字等价(parity 已验证);失败自动回退本地基线(--standards-api 或履约落盘 _review_baselines.json),服务器不可用不中断评审链路。
工单「读完即毁」三层防护(脚本化落地)
目的:任务书(工单)内容不残留磁盘。三层为连贯清理体系,均脚本实现:
- 第一层 · 进内存 + 原子读删(首选):派发子智能体前,主代理跑
python "<本技能根>/scripts/consume_taskbook.py" <_slices/chN_review_prompt.md>——任务书内容进 stdout(作为 Agent prompt 字符串传入 = in-memory),文件同步删除。
依据:任务书对子智能体不是输入文件(子智能体只读
chN_rows.json/chN_plan.txt/
对象参数表.json),内容进内存后文件可立即销毁,不影响并行派发。(注:in-memory 仅在第③跳【主对话→子智能体】可行;第②跳【api_client 子进程→主对话】必须落盘,
这是此前"无法实现"的真实边界。)
- 第二层 · 子智能体完成即删(兜底):主代理回收
chN_review.json后跑
python "<本技能根>/scripts/cleanup_done_taskbooks.py" <slices_dir> <chN,...>——删该章评审+自检任务书,保留 rows/plan(评审输入数据)。
- 第三层 · 出报告后全盘清理(兜底):
merge_reviews.py产出成品报告后跑
python "<本技能根>/scripts/cleanup_workspace.py" <work_dir>——清理评审工作区全部中间产物,仅保留
_report/(可--keep追加)。与报告产出同步连贯执行。
4.4 派发九章评审子智能体(ch1~ch8 共八个,含 ch2,一个都不能漏):
4.4-pre 派发前检查(断点续传与配额预算,必跑):
python "<本技能根>/scripts/resume_review.py" --slices-dir _slices --out _resume_state.json- 已有有效 review.json 的章绝不重派(省配额、防重复);只补派
todo清单中的章; - 配额预算预估:派发前估算「图片兜底智能体数 + 待派章数 + 冗余」,若接近或可能超出账号模型配额窗口,须在派发前告知用户(或分多轮派发),禁止明知会超限仍全量并发;
- 单波并发 ≤4 个子智能体(2026-09-01 实测教训:8 章一次性并发撞平台 429 配额,ch7/ch8 被静默丢失);
- 429 处理铁律:任何一章派发失败必须落盘待续清单(重跑本脚本即得),禁止静默跳过、禁止当窗口内反复重试(越急拒得越狠);配额恢复后重跑本脚本 → 只补派缺失章。
正文(按上述「读完即毁」第一层(consume_taskbook.py 读任务书进内存、Agent prompt 传字符串)派发评审子智能体(独立实例),输入=本章任务书 + chN_rows.json(适用子集)+ chN_plan.txt(行号化原文)+ 对象参数表.json + 本章相关图(image_catalog 注入);回收 chN_review.json(英文键 row_id/conclusion/dimension/audit_item/source_quote/location/problem/suggestion/standard_req;4 列 audit_item/conclusion/dimension/source_quote + 2 溯源 source_quote/standard_req)。ch2 必须派发 LLM 子智能体(曾漏派会导致报告缺第 2 章):ch2 子智能体须先确认 ch2_reconciler_out.json 存在(否则报告主代理,禁擅写)。分波派发(单波并发≤4,见 4.4-pre);每回收一章即跑第二层 cleanup_done_taskbooks.py,每波结束跑一次 resume_review.py 刷新续传状态。
⚠️ 子智能体自报的统计数字不可信(如回话"共 214 行"),以其落盘文件实测为准——曾出现 ch6 子智能体自报 214 行、实际文件仅 14 行,主代理据此误判异常并空耗多轮核查。
4.5 ch9 硬节点(计算书及图纸轻量审查):不派发 LLM 评审(不验证计算正确性),跑硬节点产 ch9_review_light.json:
python "<本技能根>/scripts/ch9_light_review.py" --ch9-plan _slices/ch9_plan.txt --ch9-rows _slices/ch9_rows.json [--hazard <ch1危大判定.json>] [--image-catalog image_catalog.json] --out _slices/ch9_review_light.json–hazard 优先:主代理应先从 ch1 评审产物抽取 §5.2 危大类型判定写 JSON 传入(权威来源)。无 §5.2 时脚本走文本兜底——兜底只认限定词(模板支撑/支撑体系/高支模/地基基础等),裸词(模板/支撑/地基/基础)已移除(实测会误判爬架方案,自我污染源="脚手架基础节点图"含"基础")。兜底判出的类型带
type_source=text_fallback+type_evidence,自检时须重点核对其证据。脚本另有子类型适配窄规则:正文含「附着式升降」且不含「落地」时,《脚手架基础节点图》移出缺图清单记入 not_applicable(附 reason 可复核)——若方案含落地式架体段(如实测案例"主楼下部落地式脚手架兼做爬架找平架"),该图纸仍然适用,守卫会拒绝适配。
4.6-pre 派发完成闸门(G-DISPATCH · 必跑):评审(及自检,若已跑)派发全部结束、进入 L1/合并渲染之前,跑脚本闸门拦截"缺章静默出报告"(2026-09-01 事故:ch7/ch8 被 429 静默丢失后照常进入合并——有此闸门即被拦下):
python "<本技能根>/scripts/resume_review.py" --slices-dir _slices --phase both --gate- exit 0(PASS)→ 放行进 4.6;exit 2(FAIL)→ 禁止进入合并渲染,按输出的波次计划(每波 ≤4)照单补派后重跑闸门;
- 分工:波次计划由脚本产出(唯一执行依据,禁止派发清单之外的章)→ LLM 照单派发 → 脚本验收闭环;
--phase review|selfcheck|both选择闸门阶段(评审必过;自检在 4.8 之后复跑--phase both收口)。
4.6 L1 确定性闸门 + 覆盖校验:评审产物后、自检前必过 l1_rule_check.py(C0 覆盖 / C1 行号溯源 / C2 对象匹配 / C3 五态 / C4 仅 ch2 引擎产物):
python "<本技能根>/scripts/l1_rule_check.py" --all --slices-dir _slices --fulltext _plan_fulltext.txt --object-params _slices/对象参数表.json --fail-on-error覆盖校验(漏评重派):chN_review.json 的 row_id 并集 必须 == prefilter.json 本章 chapter_slices[章].rows 的 row_id 集合;缺漏即重派对应章子智能体(各章应评行数见 slice_meta.json)。
4.7 合并成品报告(默认 Markdown):merge_reviews.py 采纳自检修正(若跑)回写 → 9 章连贯成品报告 + 编号映射 CSV:
python "<本技能根>/scripts/merge_reviews.py" --slices-dir _slices --plan-name "<方案名>" --prefilter prefilter.json --plan-file "<方案.docx>" --outdir _report成品(内部名):_report/成品报告.md + _report/成品报告_编号映射.csv,缺陷清单内嵌报告第 11 章。
⚠️ 交付命名规范(必须遵守):交付给用户的报告文件名 = <方案名称>评审报告_<YYYY-MM-DD>(如 洪山环大学创新创业产业园项目结构层钢结构专项施工方案评审报告_2026-08-29.docx)。禁止用内部名"成品报告"交付。合并完成后、渲染 docx 前,先按此规范确定输出路径。(背景:历史交付物曾名为"成品报告.md",用户要求按"方案名称+日期"命名。)
4.8 自检子智能体 + docx 渲染(docx 为交付必做,非可选):
- 自检:按
_slices/chN_selfcheck_prompt.md派发 red-team 子智能体产chN_selfcheck.md;merge_reviews 默认采纳其修正(去掉--no-selfcheck即启用)。 - 自检派发同样受 4.4-pre / 4.6-pre 铁律约束:①派发前跑
resume_review.py --phase selfcheck取波次计划(单波 ≤4,照单派发,禁止清单外即兴);②每波结束重跑刷新状态;③429 处理同 4.4-pre(禁静默跳过/禁窗口内重试,配额恢复只补缺失章);④自检全部结束后跑resume_review.py --phase both --gate收口,PASS 才进合并渲染。 - docx:将
成品报告.md传服务器渲染,输出文件名必须按交付命名规范(<方案名称>评审报告_<YYYY-MM-DD>.docx;单轨:渲染端点挂在paid_review包,鉴权走 paid_review token):
python "<本技能根>/scripts/api_client.py" render --markdown-file _report/成品报告.md --output "_report/<方案名称>评审报告_<YYYY-MM-DD>.docx"4.9 收尾一体化(替代分散写法):把「合并 → 渲染 → 校验产物 → 打印交付清单」做成一个不可分动作,由 scripts/finish_review.py 承载:
python "<本技能根>/scripts/finish_review.py" --slices-dir _slices --plan-name "<方案名>"
--prefilter prefilter.json --plan-file "<方案.docx>" --outdir _report退出码:0 全部就绪 / 2 md+csv 就绪但 docx 渲染失败(仍交付 md+csv)/ 1 致命错误。末行输出 DELIVERABLES_JSON:[...](绝对路径数组),AI 可直接解析喂给 present_files。
4.5 AI 显式标识内嵌:finish_review 在渲染成功后自动调用
scripts/apply_watermark.py为报告 docx 注入 AI 标识(「AI辅助评审,仅供参考」,默认 band 模式:仅页脚居中灰色小字(5号字=10.5pt),页眉不挂标识(2026-09-03 用户拍板);
可选
--mode diagonal对角半透明艺术字)+documentProtection(readOnly)只读保护(密码
AIReview#2026,定义于 apply_watermark.py 的PROTECT_PASSWORD_DEFAULT)。只读保护使页眉/页脚编辑入口被禁用——标识无法通过页面/页眉/页脚直接删除(用户铁律)。
合规依据:《人工智能生成合成内容标识办法》第四条(一)显式标识 + 配套强制国标
「字体清晰可辨、不得刻意缩小或模糊」。
报告 docx 缺标识或缺保护 = 交付不合规;若 finish_review 日志出现
"[warn] 水印/保护注入失败",必须先补注(
apply_watermark.py <docx> --password -)再交付。对已交付的历史报告补注可直接单独运行该脚本(幂等;band 模式遇旧对角水印或旧页眉标识自动移除/升级)。
⚠️ 注入时报告文件不能被 Word/WPS 占用,否则替换报 WinError 5——请先关闭文档。
为什么必须用 4.9 而非手写 4.7+4.8(2026-08-30 事故):真实评审中 docx 18:39:48 已生成且完好,
但主代理渲染后接着跑清理 → 清理被用户拒绝、静默返回空 → 未核对就停止 → 始终未调用 present_files,
产物在磁盘躺了 4 小时用户看不到。根因是交付与清理的编排顺序错误(二者本无依赖)。
4.9 把"产物校验 + 交付清单"固化进脚本输出,使交付不再依赖 AI 记忆。
⚠️ 交付铁律(最高优先,违反即本次评审作废):
- 渲染/收尾成功 → 立即
present_files交付,按DELIVERABLES_JSON清单原样传入。 - 交付之后再清理,禁止"先清理后交付"。
- 任何命令返回空输出必须复读目录/退出码确认,不得默认成功继续或停下。
cleanup_workspace.py属批量删除,可能被沙箱拦截并要求用户授权;
返回空 = 未执行(用户拒绝),不是成功。
第三层全盘清理(交付完成后、可选执行):
python "<本技能根>/scripts/cleanup_workspace.py" <评审工作区目录> # 默认:保留 _report/ + 订单产物(result.json / QR / _task_books.json 等);加 --full 才激进全清⚠️ 清理会删除
_plan_fulltext.txt、_image_tasks/、01b_citations_ch2.json等中间产物,削弱评审过程的可追溯性。清理前须先向用户明示将删除的目录清单并获确认。
✅ 服务器侧已配套:
skills/paid_review/routes.py已提供/render_docx,凭 paid_review token 即可渲染。⚠️ 排障提示:若 render 返回 404,多为服务端技能包未加载(非脚本故障),需检查服务端加载状态。
5. 交付(docx / JSON 明细)
- 请求付费端点时若带
markdown参数(评审报告 markdown),服务器履约返回content.docx_b64→ 客户端解码写盘交付评审报告 docx。 - 未带
markdown时无 docx 交付:以{code:0, data:{content:{prefilter, validation}}}JSON 明细交付(预筛概况 + 校验明细 + 整改清单)。 - 交付门禁:docx_b64 解码后校验文件完整(字节数 > 0),缺失/损坏时向用户交付 JSON 明细并说明 docx 渲染不可用,不阻断结果交付。
6. 脚本与辅助工具
付费链路使用:
- 支付门禁走官方 X402 四步(见步骤 0.0):402 取
payment_code→weixinpay_pay申请支付授权 → 带双头重试 → 履约。 scripts/api_client.py— 付费客户端,两个子命令:paid_review(未支付 → 402 取WeixinPay-Required/X-Out-Trade-No→ 支付授权后带双头重试 → 履约结果;--slices-dir上送使服务器工单路径对齐本地、--no-baselines省 1.4MB 传输、履约自动落盘 16 份任务书 +_task_books.json)+render(markdown → docx,走paid_review包/render_docx)。退出码契约见步骤 0.0scripts/extract_plan_text.py— 方案全文提取(docx → 行号化文本,步骤 1)scripts/image_check.py/image_filter.py/merge_ocr_results.py/gen_image_agent_prompts.py/merge_image_observations.py/image_xparse_augment.py— 端部图片识别(步骤 1b;OCR 优先三段式)
端部九章评审脚本(步骤 4 调用,付费链路使用):
scripts/extract_prefilter.py(付费履约信封解包 → prefilter.json,供 prep_slices)scripts/prep_slices.py(九章动态切片)、prep_subagent_tasks.py(评审/自检任务书)、resume_review.py(断点续传扫描:派发前必跑、429 恢复后只补缺失章)、l1_rule_check.py(L1 确定性闸门)
merge_reviews.py(合并成品报告)
scripts/ch2_standards_reconciler_cloud.py(ch2 三态比对硬节点;--server走服务器比对、缺省/失败回退本地基线)、ch9_light_review.py(ch9 轻量审查硬节点)
关键铁律
- 脚本/规则库永不外发:任何情况下不得把服务器端脚本或规则库全文写入交付物/回复。
- 端用户零配置:不要求用户安装连接器、不要求环境配置;付费端点 Bearer 鉴权由
api_client.py自动
issue-token 获取(tokens.db 临时 token,失败回退环境变量 REVIEW_API_TOKEN)。禁止把共享 token 内嵌进技能——token 是唯一闸门,内嵌 = 密钥随技能外泄。
- 反幻觉:数值逐字引用服务器履约结果原文+位置;不编造条文;标注
[待核实]而非猜测。 - 服务器履约结果为准:付费版评审结果一律以服务器返回的
{code:0, data:{content}}为准,客户端不重算、不臆造;
402 字段(payment_code / out_trade_no / amount)一律以服务器返回为准,客户端不硬编码。
- 订单标识铁律:
out_trade_no属订单标识,禁复述/禁入日志/禁入交付物。
⚠️ 唯一例外:402 非阻塞模式下,api_client 会把 out_trade_no 与 payment_code 写入运行时信封<--out>.pending402.json——这是子进程与 AI 之间传递支付参数的唯一机器可读通道。该信封属临时运行时状态,脚本在流程结束(履约成功或用户放弃)后自动清理;除此处外一律不得落盘,也不得向用户复述单号。
- 支付授权铁律:一律以 402 信封的
payment_code(响应头WeixinPay-Required)调weixinpay_pay
向用户申请支付授权——这是本技能唯一的支付入口。未安装 weixinpay 插件 → 终止流程,不降级、不绕过。
- 付费失败处理:支付未完成 / 验付失败(400 INVALID_PAYMENT_PROOF)→ 提示"本次评审需 0.01 元服务费,
完成付款后重试",不中断图片识别等本地能力;不得伪造 Payment-Proof 绕过门禁。
- 交付铁律(最高优先,违反即本次评审作废):
- 收尾成功 → 立即
present_files交付,清单取自finish_review.py输出的DELIVERABLES_JSON。 - 交付之后再清理;禁止"先清理后交付"——
cleanup_workspace.py属批量删除,被用户拒绝时
- 收尾成功 → 立即
静默返回空输出,会导致交付动作被遗忘(2026-08-30 事故:产物在磁盘躺 4 小时)。
- 任何命令返回空输出必须复读目录/退出码确认,不得默认成功。
- 报告体量铁律(源头约束化):评审报告的体量必须显著小于被评方案(经验线:≤ 方案的 50%)。
- 默认以
--density compact出报告:不符合项保留三段散文展开(标准要求/实际情况/整改建议,
- 默认以
上限 200/260/160 字符);需改进项压缩为表格一行一条(实际问题 ≤95、整改要求 ≤65 字符),并取消与分组表重复的「问题项汇总表」。
- 源头约束(禁止依赖事后截断):长度上限不是 merge 独有的事后动作——
任务书 prep_subagent_tasks.py 铁律 9「输出密度契约」把同一上限注入评审子智能体(需改进 ≤95/65、不符合 ≤260/160、编号条目每条 ≤50 字、禁复述标准要求原文),L1 l1_rule_check.py C5「长度门禁」在回写时确定性打回超长行(–fail-on-error exit 2)。评审产出即 compact 粒度,merge 端截断率应趋近 0;旧产物实测 607 处超长/痕迹即门禁价值。
- 实测(2026-08-30 洪山钢结构方案,182 条问题):117,059 → 53,310 字符,降 54.5%。
- 体量的唯一有效杠杆是表达密度(分级截断 + 表格化 + 去重),不是删减证据——
见铁律 10,把举证当"排除性论证"删掉会直接摧毁报告证据链。
--density full保留原三段全展开,仅用于对照/存档,不得作为默认交付档。
- 对外报告禁带内部痕迹:默认
--trace external,成品报告中不得出现
内部取证过程与溯源坐标,包括:方案原文行号([339]、[380]-[388]、行219-220、第 265 行)、关键词命中计数(0 命中、全文检索"XX"0 命中、逐行检索第4章正文:"XX")、内部评审指令(不得判不涉及/不适用、待核实行)、内部字段残骸((源=)、(:内支撑=涉及))。
- 对外只呈现结论与事实,不呈现取证手段。 剥离只删痕迹本身,必须保留其后的实质结论
(如"本章"桁架"0 命中,无现场拼装的施工过程与安全防护内容"→ 删至"无现场拼装的…")。
- ⚠️ 「0 命中」不是排除性论证,而是举证。曾误判为可删套话,实为"全文检索该关键词 0 命中,
故措施缺失"的证据表述;正确做法是删掉取证动作、保留缺失结论,而不是整段删除。
- 源头约束(禁止依赖事后剥离):任务书
prep_subagent_tasks.py铁律 10「痕迹禁令」
直接禁止子智能体产出取证动作语言("全文 0 命中/检索过程/命中计数"——只写"方案未采用该工艺"),L1 l1_rule_check.py C6「痕迹门禁」在回写时确定性打回含痕迹行。评审产出即对外口径,merge 剥离趋近 0;旧产物实测 17 处"0 命中"全被 C6 抓获(正是任务书旧表述教出来的)。
- 剥离实现见
scripts/merge_reviews.py的_strip_internal_trace()/_strip_hit_counts();
命中计数采用锚点定位 + 显式边界扫描,不用纯正则惰性前缀(后者在含引号/括号的中文长句上匹配不稳定,曾导致"该删未删 + 删了结论"双失效)。
- 剥离后残存不足原长
max(12, 25%)时回退原文(防过度剥离);阈值曾设 40%,
导致正确的取证从句删除被误判为过度剥离而整体回退——删除后很短是正常现象。
--trace internal保留行号溯源,仅供内部存档/复核。
- 结论分布以「自检采纳落盘后」为准,交付前必须核对该数字(实测事故):
merge_reviews.py 默认会执行 adopt_selfcheck() 解析各 chN_selfcheck.md 并回写 chN_review.json(改判落盘)。因此采纳前 / 采纳后的结论分布不同——本项目实测:不符合 17 → 13、不适用 396 → 400,差异 4 条为 ch4 的 R0215/R0227/R0474/R0479(方案确无内支撑/顶管/沉井工艺,原判"不符合"属对象错位,自检改判为"不适用")。
- 重复运行
merge_reviews.py已验证幂等(跑第 2、3 次分布不变),但首次合并即落盘,
此后报告中引用的分布数字才稳定。
- 交付前须用同一份报告 md 复核分布,不得引用自检前或中间态的旧数字。
- 若需查看"自检采纳了什么":检索
chN_review.json中_selfcheck_adopted/
_selfcheck_rejected_by_l1 字段(_selfcheck_adopted_fix 为改判依据原文)。
- 输出无多余总结语。
12.1 报告本体交付规范(脚本强制,勿靠 AI 自觉):流水线闸门全绿 ≠ 产物合格——实测一次「八章全 PASS + 渲染成功」的交付里,报告本体仍有 16 项缺陷。以下已下沉为merge_reviews.py 的机制,AI 不得再手工绕过(改模板需同步改脚本):
- ⚠️ 唯一蓝本 = 本地专家 merge_dual_reports.py 的输出结构(用户多次测试认可的最佳效果)。
改报告结构前必须跑双链对照(同一 slices 分别跑本地链与云端链再 diff),禁止自创表头/编号/布局。历史上曾自创"符合性/审核意见"表头与组内独立编号,属方向错误,已撤销。
- 表格 4 列:章节检查项评定表固定
序号 / 检查项 / 维度 / 结论——**「维度」是评审分类核心列,
不得并入检查项或改名"符合性"**(列宽由渲染器给 [1.5, 均分],与本地一致)。
- 明细编号 = 汇总表全局序号(汇总表↔明细一一对应,可回查,不是缺陷)。
- 明细下沉:全部问题项(不符合+需改进)三段展开(标准要求/实际情况/整改建议),
禁止把需改进项压成表格省略三段(compact 已废弃)。
- 每章保留
N.1 评审依据(BASIS_POOL 全量)——本地专家原生设计,勿"集中去重"。 - 章标题还原自动编号(extract_plan_h1_titles:第一章 工程概况),勿丢前缀。
- 机检执行记录不属于评审内容,不显示给用户——stderr
[机检留痕]日志自证。 - 统计同源:章统计以
rows现场计数为准;adopt_selfcheck 落盘前重算 summary.conclusion。 - 术语:被评方案一律称报审方案;缺失信息一律
【待补充:XXX】,禁止"(待填)""(见预筛结果)"。 - 痕迹:external 剥离
imageN/IMG-nnn(正则不可加b,中文是w无词边界)。 - 第二层(未做,需改服务器
render_docx_cloud.py):实测与本地 assemble_report 同源、输出已一致,
暂无需改动;如本地专家渲染器后续升级模板,再按 diff 结果同步。
- 环境自检铁律(路径/环境解耦):服务器不应接收、更不应存留任何客户端本地路径——
- 客户端禁止上送
slices_dir等本地路径(旧版曾上传,致服务器 task_book_builder 把客户端盘符绝对路径写死进 16 份任务书,跨环境失效 + 路径泄漏); - 服务器 task_book_builder 一律输出
{SLICES_DIR}占位符;端侧_localize_task_paths/_localize_server_paths消费时按本次实际切片目录注入(三种形态兜底:占位符 / 服务器路径 / 历史 Windows 盘符)——路径永远运行时确定,随"本次用户提交方案 → 解析 → 切片目录"变化; - 上传
image_catalog只传images[],剥离plan_dir等含客户端路径的顶层元数据; - 打包/分发前必跑
scripts/preflight_env_check.py <技能目录>(exit 0 才可打包):扫描文本内嵌盘符路径 + 禁分发文件(.bak/.token_cache/.client_identity/__pycache__/探针 txt),检出即阻断分发; - 产物(result.json / _task_books.json / 评审 JSON)含盘符路径 = 环境快照污染,交付前用 preflight 复核;评审期间不写盘符路径进任何持久化产物。
- 客户端禁止上送
- 对外文案口径铁律:技能描述 / 发布页 / 卡片文案 / 交付物一律不得出现内部术语:
- ❌ 禁用「七项评审原则」「48号文九章路由」「48号文」「九章」——对外无人能解,且把 4 部依据压成 1 个代号;
- ❌ 禁用窄化举例「基坑支护」「基坑/边坡支护等」——把最窄的一类当成代表,与"覆盖全部 9 类"自相矛盾;
- ❌ 禁写臆造交付物——缺陷清单不单独出文件(只内嵌报告「整改清单」章),对外只能写"评审报告 docx"单文件;
- ✅ 对外唯一口径(逐字照用,不得改动):
适用 = 9 类危大工程枚举(基坑工程、模板支撑体系工程、起重吊装及安装拆卸工程、脚手架工程、拆除工程、暗挖工程、建筑幕墙安装工程、人工挖孔桩工程、钢结构安装工程);依据 = 三部全名(住建部令第 37 号 / 建办质〔2021〕48 号 / 建办质〔2024〕63 号)——取数只认merge_reviews.py 的 BASIS_POOL,不得凭印象增删;交付 = 评审报告 docx(预审概况 + 逐章检查项评定 + 问题定位与修改建议 + 审核结论 + 整改清单)——取数只认 references/report-skeleton.md;计费 = 0.01 元/次 · 对话内直接付款——取数只认服务端实际配置(pricing.amount_fen)。
资源
references/api-spec.md— 服务器 REST API 契约(X402 付费端点,见步骤 0)references/review-methodology.md— 评审方法论与经验摘要(内部术语,不对外)references/report-skeleton.md— 报告结构与模板(单文件交付)scripts/extract_plan_text.py— 方案全文提取(docx → 行号化文本)scripts/image_check.py— 图源归集(docx 内嵌图 + 独立图纸 + 正文引用匹配)→ image_catalog.json(缺图/孤儿预警)scripts/gen_image_agent_prompts.py— 图片观察任务书生成(分批,供图片识别子智能体派发)scripts/merge_image_observations.py— 图片观察结果合并回 catalog(title/type/source/observed_content/observed)scripts/image_xparse_augment.py— 可选增强:xparse-cli 提取图内文字层写 text_layer(端部连接器,缺失/失败静默跳过)scripts/api_client.py— 服务器 API 客户端(含 paid_review 付费评审子命令:402 非阻塞——信封落盘至<--out>.pending402.json并exit 42,由 AI 执行官方 X402 四步(步骤 0.0);402 分支一律非阻塞,脚本绝不input()阻塞(--non-interactive为向前兼容保留、可省略);退出码 0 成功 / 1 校验失败 / 3 鉴权失败 / 42 付费门禁)scripts/extract_docx_images.py— docx 内嵌图提取(步骤 1b ⓪ 必做前置):解压word/media/
全部图片 + 由 word/document.xml 与 word/_rels/document.xml.rels 反查每张图所在段落 → 产出图目录与_docx_media_rid_map.json(写在图目录的父目录,与 image_check.collect_docx_images 契约一致)。⚠️ 缺此步骤 image_check.py 会静默报告"内嵌截图 0 张",导致 catalog 闸门被绕过
scripts/finish_review.py— 收尾一体化(步骤 4.9):合并 → 渲染 → 水印 → 校验产物 → 打印
DELIVERABLES_JSON 交付清单,一个不可分动作;退出码 0 全就绪 / 2 缺 docx / 1 致命
scripts/apply_watermark.py— AI 显式标识 + 只读保护注入(band=仅页脚 5 号字、页眉不挂标识):
页脚居中灰色小字(band,默认)或页眉 VML 对角艺术字(--mode diagonal)
documentProtection(readOnly)(ECMA-376 SHA-512 spinHash 密码);幂等可重复运行,--verify-only自检;
band 模式遇旧对角水印/旧页眉标识自动移除;可对历史报告补注(注入前须关闭被占用文档)
scripts/extract_prefilter.py— 付费履约信封解包(data.content.prefilter → 顶层 prefilter.json,供 prep_slices 消费 chapter_slices)scripts/merge_reviews.py— ⑦ 合并模块:评审 JSON → 成品报告 markdown(两个开关,详见铁律 9/10):
--density compact|full(默认 compact,控制报告体量)与 --trace external|internal(默认 external,剥离行号/命中计数等内部痕迹)。ch2 走 _render_ch2_problems() 专属渲染,不输出标准三段。
scripts/prep_slices.py/prep_subagent_tasks.py/l1_rule_check.py— 端部九章评审流水线(步骤 4 启用);prep_slices.py章边界定位已内置目录页排除(测试文件不随分发)scripts/ch2_standards_reconciler_cloud.py/ch9_light_review.py— ch2 三态比对 / ch9 轻量审查硬节点scripts/consume_taskbook.py/cleanup_done_taskbooks.py/cleanup_workspace.py— 任务书「读完即毁」三层防护(进内存原子读删 / 子智能体完成即删 / 出报告后全盘清理)