公文编写（worktool-gongwen-writing）

这个技能在做什么

把「写公文」从一次性对话变成可追溯的编制工程：

• 第一步先定工作根目录（阶段 -1）：首次启动问用户要一个目录，在其下建 knowledge（知识库）/ output（输出文件）/ src（参考文件）三个子目录；没确认过就不往下走（init-task 会挡住）；
• 需求先问清、后落库 → 每个任务有正式的任务记录；
• 一任务一文件夹：工作根目录由用户定（首次启动时问，见阶段 -1），其下三个子目录分工——knowledge 知识库、output 输出文件、src 参考文件；任务建在 <根>/output/<公文名称>/，该公文全部产物（提纲、md、docx、评估 json/html、建议）都在这个文件夹里，绝不散落；
• 成稿后的评估检测完全离线、隐私优先：逐节评估、跨节呼应度、评估报告 HTML、交付自检全部不联网——脚本入口会直接剥夺进程的 socket 联网能力（不是"约定不联网"），正文与参考资料不会离开本机；评估报告是单文件自包含 HTML，无 CDN / 无外部字体 / 无远程图片；
• 去 AI 味、反假大空：判据不是"像不像人写的"，而是逐句可核——一句里有没有主体、动作、结果、时限。充实度里的「去AI味」维度会用规则表逐句匹配（万能过渡、空转句式、空洞意义、有力支撑、含糊其辞，加排比凑字/副词堆砌/黑话堆砌/长定语堆叠），把废句连"位置＋原词＋所在句＋怎么改"列成清单；改完自动给出与上一版的分数对比；
• 先出提纲 + 每节 ≤50 字摘要让用户改到满意，再基于摘要成文（避免几万字返工）；
• 每一版先出 Markdown（在对话里秒开、逐轮改），定稿后才出 Word；过程版正文用 {{Sx}} 角标标注每处内容的出处，成文后定稿时角标与参考文献表自动剥离，交付版干净无引用标记；
• 每次改完内容都自动重评一遍：record-report 一落盘就会跑「逐节完整度/充实度评估 + 跨节呼应度检查」，返回里直接带上与上一版的分数对比，并自动生成一份单文件 HTML 评估报告（report-vN.assess.html，断网可开、可打印、可随版本归档）；模型要做的不是"记得跑脚本"，而是把结论讲清楚并把评估报告打开给用户看；
• 成文后逐节评完整度/充实度，指出哪一节薄、薄在哪个维度，并给出来自本机已有材料（任务 facts / 已归档参考件 / 本地知识库）的补强材料；
• 再做一次跨节呼应度检查：开头承诺的事结尾有没有落点、前一章提的问题后文有没有逐条回应、各章之间有没有承接表述、术语是否前后统一、有没有跨节重复——发现脱节就给出可执行的修改建议（多数组内低分不必强改，脚本会给判读提示）；
• 每生成一版都是新版本，旧版本永不覆盖，且每版都记录「基于哪一版生成」「生成前用户提了哪些建议」；
• 未上传模板时，按 GB/T 9704-2012 直接排版到 Word（页边距、三号仿宋、每面 22 行每行 28 字、奇偶页不同页码全部落地）。

环境准备（首次使用，幂等）

PY=/Users/black/.venv-gongwen/bin/python
[ -x "$PY" ] || { /Users/black/.workbuddy/binaries/python/versions/3.13.12/bin/python3 -m venv /Users/black/.venv-gongwen \
  && /Users/black/.venv-gongwen/bin/pip install -q python-docx lxml; }
$PY -c "import docx;print('ok')"

脚本目录（下文记作 $SK）：

SK=~/.workbuddy/skills/worktool-gongwen-writing/scripts

> 装好环境后的第一件事不是建任务，是定工作根目录（阶段 -1）。先跑
> $PY $SK/task_store.py workspace，看返回的 needs_setup。

目录约定（工作根目录 + 三个子目录，根目录由用户指定、可随时改）

工作根目录不是写死的——首次启动时问用户要（见阶段 -1），拿到后在其下建三个子目录，各干一件事：

根目录的当前值与三个子目录的实际路径，一律以命令输出为准，不要凭记忆写死：

$PY $SK/task_store.py workspace                                # 状态：needs_setup / root / 三个子目录
$PY $SK/task_store.py workspace --init "/工作根目录"            # 首次设定，或改到别处
$PY $SK/task_store.py workspace --reconfigure                  # 清掉确认，下次启动重新问（不动文件）
$PY $SK/task_store.py config                                   # 看生效值（含 config.json 原文）

路径优先级：环境变量 → 单项覆盖（config --set knowledge_root=…）→ <工作根目录>/<子目录名>。
老配置只写了 output_root / knowledge_root 也能跑（会从它们的共同父目录反推根目录），不必强行迁移。

翻参考文件与知识库：

$PY $SK/task_store.py list-knowledge [--search 消防]           # 两个目录都列，where 字段标来源

--template / --ref 只写文件名即可——脚本会先按路径找，找不到就依次去 src → knowledge
按「相对路径 / 文件名」匹配（返回里的 template_from / refs_from 会说明取到了哪个目录）。
模板与参考文档会被复制进任务文件夹的 source/ 存档。

> 本机当前的根目录是 /Users/black/AI/write（knowledge / output / src 都已就位）。
> 下面示例里的路径都按它写；用户改过根目录就以 workspace 的输出为准。

任务文件夹结构（<公文名称> 就是文件夹名，同名冲突自动加 -2 / -3）：

<工作根目录>/output/<公文名称>/
├── task.json                 任务记录（全部填报字段，extra.sources[] 是引注键的唯一登记处）
├── format-config.json        排版配置（模板抽取结果 或 GB/T 9704 默认）
├── source/                   上传的模板与参考文档原件
├── outline/outline-vN.json|.md     提纲与摘要（每版都留）
├── report/report-vN.json           报告内容模型（正文带 {{Sx}} 引注标记；附件放顶层 appendix[]）
├── report/<日期>_<名称>_vN.md       过程版 Markdown（快速评审用，带角标 + 文献表）
├── report/<日期>_<名称>_vN.docx     定稿 Word（角标与文献表已剥离）
├── report/report-vN.eval.json      逐节评估 + 扩展建议
├── report/report-vN.coherence.json 前后呼应度检查 + 脱节改进建议
├── report/report-vN.assess.html    **评估报告（HTML，给人看、可交付）**
├── report/report-vN.assess.json    评估摘要底稿（含与上一版对比，供重渲染/复算）
├── notes/suggestions-*.json        生成前用户提的修改建议（原话）
├── notes/advice-report-vN.json     逐节扩展建议（模型填写，已合并）
├── notes/advice-coherence-vN.json  呼应度改进建议（模型填写，已合并）
└── manifest.json             版本索引 + 血缘

> --task 传的就是文件夹名（＝公文名称），不再有 T20260929-001 这种编号。
> 名字里有 / \ : * ? " < > | 会被自动剔除（实际文件夹名以 init-task 返回的 task_id 为准）。
> 下文命令里统一用这两个变量：

T="关于全市消防安全专项整治工作情况的报告"   # ＝文件夹名（= init-task 返回的 task_id），--task 传它
# 本次任务文件夹：机器上**当前生效**的输出库根目录 + 任务名（换过根目录也能取对，别写死）
OUT="$($PY $SK/task_store.py config | $PY -c 'import json,sys;print(json.load(sys.stdin)["effective"]["output_root"])')"
TD="$OUT/$T"

交付节奏：record-report 默认只出 md；确认定稿后 finalize-report 才排 Word。
record-report --docx 可一步到位（内容已确认、不需要再评审时用）。

评估报告是 HTML：每次评估都自动生成 report-vN.assess.html（单文件、零外部依赖、离线可开、
带打印样式），把它连同结论一起呈现给用户——见阶段 4D。

阶段 -1 · 首次启动：先把工作根目录定下来（任何事之前）

每次技能启动，第一件事都是跑这一条，看工作根目录确认过没有：

PY=/Users/black/.venv-gongwen/bin/python; SK=~/.workbuddy/skills/worktool-gongwen-writing/scripts
$PY $SK/task_store.py workspace

返回里 needs_setup: true 就说明还没问过用户。这时候不要接着往下走——
不要建任务、不要生成提纲、不要拿默认路径硬开工。要先把下面这句话问了：

> 「这份公文的工作根目录放在哪？我会在它下面建三个子目录：knowledge（知识库，
> 放沉淀下来的范文、体例规范、素材条目）、output（输出文件，每份公文一个文件夹）、
> src（参考文件，你丢进来的模板、往年同类文、素材原件）。以后想换随时说一声。」

拿到目录后一步到位（会当场建齐三个子目录，幂等；已存在的只登记、不清空）：

$PY $SK/task_store.py workspace --init "用户给的工作根目录"

输出里会报：三个子目录哪些是 created（新建的）、哪些是 existed（本来就有）、
dropped_overrides（因改根而失效的老的单项路径覆盖）。把 existed 念给用户听——
如果他给的目录里本来就有旧内容，让他知道技能看到了、且一个字没动。

用户还没想好放哪 → 先给候选，别催

workspace 在未确认时会自动扫几个常见位置（当前目录、~/AI、~/Documents、~/Desktop
及其一级子目录），返回 detected[]：其下已存在 2 个以上同名子目录的目录按命中数排序。
把它们连同各自的 found 一起摆给用户挑（"/Users/black/AI/write 下面已经有 knowledge、
output、src 了，就用它吗？"），比空口问一句"你想放哪"好答得多。

探测只是给提示，不自动选——最终以用户确认为准。实在不想选就给个建议路径，别把问题抛回去。

随时改根目录

$PY $SK/task_store.py workspace --init "/新的工作根目录"   # 改到别处，三个子目录跟着走
$PY $SK/task_store.py workspace --detect                   # 重新扫一遍候选
$PY $SK/task_store.py workspace --reconfigure              # 清掉"已确认"，下次启动重新问（不动任何文件）
$PY $SK/task_store.py config                               # 看当前生效值
$PY $SK/task_store.py config --set root="/新目录"           # 与 workspace --init 等价

改根目录 = 三个子目录整体跟着走：老的单项覆盖（output_root / knowledge_root /
src_root）会被清掉并报在 dropped_overrides 里——否则用户换了根却发现产物还落在旧地方。
原有目录与文件一个都不搬、不删，只改配置、只新建缺的目录。

> 想只把某一个子目录挪到别处（比如知识库故意放共享盘），那就在改完根之后单独指：
> config --set knowledge_root=/共享盘/公文知识库。优先级：环境变量 → 单项覆盖 → <根>/<子目录名>。

没确认根目录会怎样

• init-task 会直接挡住并返回 success: false / error: workspace_not_configured，
  提示先去 workspace --init。用户这一次就把目录说了的话，可以 init-task ... --root <目录>
  一步登记并开工。
• 其它命令在 stderr 打一行 [WARN] 工作根目录尚未确认…，不阻止执行（评估、看任务这些只读动作
  不该被卡），但看到这行就说明该去问了。

离线与隐私（成稿后评估检测的硬约束）

成稿后的「评估检测」＝ 逐节评估（evaluate.py）+ 跨节呼应度（coherence.py）+
评估报告 HTML（build_assess_report.py）+ 交付自检（verify_docx.py），全程完全离线。

这一条是能力剥夺，不是把"别联网"写进口头约定：技能里所有脚本的入口都会调用
gongwen_lib.enforce_offline()，把出网的三个入口全部换成直接抛错——
socket.socket.connect / connect_ex / sendto（AF_INET / AF_INET6）、socket.create_connection、
socket.getaddrinfo / gethostbyname*（DNS）、ssl.SSLContext.wrap_socket（TLS）。
本机 IPC（AF_UNIX 本地套接字）照常放行——那是本机进程间通信，不是联网。
即使代码或依赖里混进了联网调用，也会当场 RuntimeError: [离线模式] … 失败，
而不会悄悄把正文或参考资料发出去；正常运行时 blocked_calls 应为 0（一次都没尝试出网）。

唯一的例外通道：用户在评估之外明确要求"去公网找补强材料/政策原文"时，
那是独立于评估的单独动作，且必须：

1. 用户显式授权（不要在评估流程里顺手联网）；
2. 由 GONGWEN_ALLOW_NETWORK=1 显式放行（否则脚本会拒绝执行）；
3. 结果只进建议区（web_findings），标注来源与口径，经用户逐条确认后才可能进正文；
4. 该结果不改变离线评估的结论——评估报告里会如实标出"联网已放行"。

> 检查当前环境的隐私模式：$PY $SK/task_store.py config（会打印 offline 相关项），
> 或看任一评估返回值里的 assessment.offline（enforced / blocked_calls / reason）。

阶段 0 · 任务填报（信息不足就引导，别猜）

先算缺口、再提问——不要凭常识替用户补字段。用 intake.py 把"还缺什么"算出来：

PY=/Users/black/.venv-gongwen/bin/python; SK=~/.workbuddy/skills/worktool-gongwen-writing/scripts
$PY $SK/intake.py                                   # 什么都不知道时，从哪问起
$PY $SK/intake.py --fields-json '{"genre":"通知"}'   # 已填一部分，看还缺什么
$PY $SK/intake.py --genre 请示                       # 附该文种专项追问
$PY $SK/intake.py --task "$TD"                       # 盘点已有任务还缺什么

必填字段（缺一个都别开工）：报告名称 / 文种 / 行文方向 / 场景 / 发文机关 / 主送机关 / 篇幅目标。

> intake.py 的输出就是要念给用户听的话：每条问题都带 why（为什么问）与 example（答案长什么样）。
> 提问时把「为什么问」一起说出来——用户知道这个问题影响什么，才会认真回答。
> 完整清单见 references/task-fields.md 第 6 节；文种专项追问见第 6.8 节。

建任务前先翻参考文件（<根>/src）与知识库（<根>/knowledge）——用户把模板、往年同类文、
素材都放在那里，别一上来就要用户上传：

$PY $SK/task_store.py list-knowledge --search 消防     # 按名称/相对路径关键词找

找到相关的就把文件名直接传给 --template / --ref（不用给全路径，脚本会去库里取）。
库里没有、用户又想给新的，才请用户上传。

然后引导用户确认格式模板与参考文档，并说明：

> 「有格式模板就按你的模板排版；没有的话我按 GB/T 9704-2012 党政机关公文格式排（二号小标宋标题、三号仿宋正文、每面 22 行每行 28 字、单双页页码分置）。参考文档给我内容素材——内容我只用你给的、以及你确认过的公开事实。」

$PY $SK/task_store.py init-task \
  --name "关于全市消防安全专项整治工作情况的报告" \
  --genre 报告 --direction 上行 \
  --issuer "XX市应急管理局" --addressee "XX市人民政府" \
  --scenario "向市政府汇报阶段性成效" --target-chars 6000 \
  --template ~/模板.docx --ref 2025年消防整治报告.docx \
  --fields ~/fields.json          # 或 --fields-json '{"purpose":"..."}'

--name 就是任务文件夹名：脚本会在 <工作根目录>/output/ 下建
<公文名称>/，该公文后续所有产物（提纲、md、docx、评估 json/html）都落在这个文件夹里。
同名时自动加 -2，不会覆盖既有任务。

返回 task_id（＝实际文件夹名，后续 --task 传它）、task_dir、format_source
（template 或 gbt9704）、format_missing（模板里没抽到、已回落到国标的项）、
knowledge_dir 与 knowledge_files（库里现有参考资料，一眼看出还能用哪些）。
把 format_missing 念给用户听，不要默默回落。

建完把 T 与 TD 记牢（T 就是返回的 task_id），后面命令都用它们。

阶段 1 · 需求引导（渐进式，一轮 3~5 条，别一次抛完）

引导原则：问缺口里优先级最高的，而不是把清单念一遍。 用户只丢一句话时，
一次问 40 条只会得到"你看着办"。

1.1 四轮问答（答一轮、落库一轮）

每轮取 intake.py 输出的 ask_now（最多 5 条），把 why 一起讲，答完立即落库：

$PY $SK/task_store.py update-task --task "$T" --fields-json '{"facts":[...],"must_exclude":[...]}'
$PY $SK/intake.py --task "$TD"          # 每轮落库后再算一次，看下一轮该问什么

1.2 什么时候可以停止追问

• 必填齐备（intake.py 的 ready_to_start 为 true）即可开工；
• 用户说"没有/不知道"→ 写进 open_questions，正文标 【待补充】，不要反复追问同一件事；
• 用户赶时间（"快出个稿"）→ 只问 A 组必填 + C 组事实清单，其余用文种惯例补齐，
  并在回复里显式声明补了什么，请用户回看纠正。

1.3 文种专项追问（通用清单覆盖不到的，问与不问差别最大）

intake.py --genre <文种> 会自动附上这些；要点如下（完整版见 references/task-fields.md 第 6.8 节）：

• 请示：请示事项（一件事一份文）／理由依据／拟办意见／上级此前是否表过态／有无时限压力；
• 报告：工作报告·情况报告·答复报告？（答复报告要写对应上级文号）／上级布置的文号与时限／要不要写问题建议；
• 通知：通知类型（发布·批转·转发·指示·会议·任免）／执行主体／执行时限／要不要反馈／转发的原文件标题文号；
• 批复：对应请示的标题与文号／批复结论／附加要求；
• 函：函类型（商洽·询问·答复·告知）／双方层级／希望对方做什么何时回；
• 纪要：会议名称时间地点主持人／出席列席范围／议题／议定事项／责任分工与时限；
• 通报：通报类型／典型对象（名称须准确）／事实与经过／处理或表彰决定／对各单位的要求；
• 意见：指导性还是实施性／指导对象与范围／实施期限／主要措施与保障措施；
• 决定：决定事项逐项／依据／生效时间／奖惩或处置措施；
• 实施方案：总体目标与量化指标／实施范围／时间步骤／组织保障／经费／考核督导；
• 工作总结：总结周期／主要任务／逐项完成情况／经验与不足／下一年度打算；
• 周报：报送周期与截止时点（覆盖上周几到本周几、几点前交）／报送对象与用途／有无固定栏目或上一期周报可参照／本周完成事项逐条给事实／下周计划与卡点、需要协调事项；
• 调研报告：调研背景目的／方法与样本／主要发现／问题与原因／对策建议；
• 汇报材料：汇报场合／听取人及其关切／时长篇幅／必须讲到的重点；
• 讲话稿：讲话人身份／场合与听众／时长（约 200~250 字/分钟）／核心口径／语言风格。

文种别名自动归一：用户写的文种名常与规范名不一致（"工作周报"、"领导讲话稿"、"工作方案"、"述职报告"），
intake.py 内置别名表会自动归到规范键再取专项追问，genre_input 保留用户原写法（回读确认时不改用户的说法）。
别名表见 references/task-fields.md 第 6.8.1 节；认不出的自定义文种按原名处理，用通用清单兜住。

周报是唯一每周重复生成的文种，口径与其它文种不同（篇幅 300~800 字、栏目前后周必须一致、
必写卡点与需协调事项、不写"经验与不足"、不加红头）。写法与评估口径见
references/task-fields.md 第 6.8.2 节与 references/quality-rubric.md 第 5.1 节——
别拿工作总结的尺子量周报，否则每周出稿都会刷一堆误报。

问完回读一遍确认清单（"我理解要写的是…，正文只会用这些数据：…，对吗？"），得到确认再进下一阶段。

阶段 2 · 提纲与摘要（关键闸门）

产出 outline.json，规则：

• 覆盖报告的所有标题（按 一、 / （一） 两层或三层）；
• 每个末级小节必须有摘要，且 ≤50 个汉字——这是「内容承诺」，正式报告要逐条兑现；兑现不了就在这一步删掉；
• 每节给 target_chars，合计 ≈ 目标篇幅；
• 想写但没数据的地方写进 open_questions，不要写进摘要里含糊带过。

周报（及月报/日报等按周月重复出的文稿）另有一条：结构要复用上一期，不要每周重新设计。
栏目名一旦固定就不再改——读者靠它做周与周的横向对比，结构漂移等于周报白写。
归档方式二选一，先跟用户确认：① 每周一个任务文件夹（文件夹名含期次，标题里就带期次；
栏目复用靠把上一期 outline/outline-v2.json 复制到新任务、改期次与各节 summary 再 record-outline）；
② 一个任务文件夹持续出版本（文件夹名不含期次，期次写进导语，换来周与周的血缘与分数对比）。
之所以不能两全，是因为 _record() 会把交付文档的标题无条件设成任务文件夹名，
而 --based-on 只是血缘元数据、不跨任务解析（详见 references/task-fields.md 第 6.8.2 节）。

结构照抄 assets/outline.example.json，然后：

$PY $SK/task_store.py record-outline --task "$T" --from outline.json \
  --suggestions "第三章改成从三个维度剖析" "第四章拆成两节"

（首版不传 --based-on；改版时 --based-on outline-v1。）

脚本会硬拦超过 50 字的摘要（errors 非空即拒绝写入）。把生成的 outline-vN.md 内容在对话里完整展示，让用户逐轮改。
用户每改一轮 → 生成新版 outline-vN+1，--based-on 指上一版，--suggestions 填用户上一轮的原话。
摘要没获用户明确点头，不进入阶段 3。

阶段 3 · 正式成文（先出过程版 Markdown）

按已确认的提纲写 report.json（结构照 assets/report.example.json）：

• lead 写缘由与引导语；sections 必须与提纲末级节 id 一一对应；tail.closing_phrase 用文种惯用结语（报告「特此报告。」/ 请示「妥否，请批示。」/ 通知「特此通知。」/ 工作总结「以上总结，请审阅。」/ 周报「本周情况如上，请审阅。」，见 references/genres-and-structure.md）；
• meta 填齐署名、成文日期、附件说明、附注、抄送、印发机关与日期；
• 正文只写公文体：层次序数只能 一、 （一） 1. （1），段首空二字，禁止 Markdown（#、**、-、--- 会被直接拦下）；
• 每个具体数字/文号都必须来自任务里的 facts 或已确认的公开事实；没有就改成定性表述或标 【待补充】。

去 AI 味 / 反假大空（写作时就要做到，不靠事后洗稿）

判据：一句里有没有主体、动作、结果、时限。 不是"读起来像不像人写的"——
凡是不能被核实的一句话，就是废话，无论它多通顺。

落笔时守住五条：

1. 不写万能过渡。删掉「综上所述／由此可见／值得注意的是／不难看出／换言之」，
   直接从事实、数据或结论起句。
2. 不用空转开头。「随着…的不断发展」「在当今…的大背景下」一律换成具体时间 + 具体事实。
3. 不写空洞意义。「具有重大意义」「发挥了重要作用」「再上新台阶」「注入新动能」
   ——要么改成可核实的结果（做了什么、达成什么指标），要么删。
4. 一句只留一个程度副词。「切实、大力、全面、有效、持续、不断、进一步、深入、扎实」
   八个一起上只会稀释信息；留一个，其余落成数字与动作。
5. 排比宁少不凑。「新思路、新举措、新成效」「规范化、标准化、精细化」
   必须项项可落地，凑不出来的项直接删。

把"加强/提升/完善/推进"换成人话：谁 + 做什么 + 到什么程度 + 什么时候。
黑话换机关日常说法：赋能→培训/支撑，抓手→具体措施，闭环→办结并回访，顶层设计→由谁统一制定。

正反例（照这个手感写）：

> 成文后、写进正文前先自检一遍（规则表逐句匹配，会告诉你哪句要改、改成什么）：
>
> bash > $PY $SK/deai.py report.json # 整篇按节审计 > $PY $SK/deai.py --text "<一段草稿>" # 单段自检 >
>
> record-report 也会自动跑这一项，结果在 assessment.ai_flavor，
> HTML 评估报告里有「去 AI 味 / 反假大空」专节（逐条清单：位置 / 类型 / 命中词 / 所在句 / 怎么改）。
> 完整规则表与改写对照见 references/quality-rubric.md 第 3.1 节。

引注角标（过程版溯源，必做）

凡引用公开来源的段落，在段末标 {{Sx}}（多来源写 {{cite:S16,S17}}）。
Sx 必须是 task.json 的 extra.sources[].id——未登记的键会被校验直接拦下，这是防编造的硬闸门。

需要引注的地方：数据与成效、会议/论坛发言、政策文号与条款、厂商或机构预测、他单位案例。
不需要引注的：本单位的思路、任务、保障措施等自我表述。

{"id": "2.2", "paras": ["…使人工策略配置工作量锐减90%。{{S4}}",
                        "…平均溯源时间由原来的1小时压缩至10分钟。{{cite:S4,S5}}"]}

参考文献节写成新式 refs[]（单一事实来源，不必在报告里再抄一遍来源信息）：

{"id": "5", "level": 1, "heading": "附：主要参考资料", "role": "references",
 "paras": [], "refs": [{"key": "S1", "text": "标题，出版者，日期。https://…"}]}

refs[] 可留空但节必须存在——脚本会回落到 task.json 的 extra.sources[] 自动生成文献表。

附件（表格、清单、评测汇总等）

附件不是正文的"节"，用报告顶层的 appendix[] 承载，结构同 sections 的节点：

{"appendix": [{
  "id": "A1", "label": "附件一", "name": "当前大语言模型在网络安全领域的能力评估",
  "paras": ["本附件汇总公开渠道可查证的……（导语，可带 {{Sx}} 角标）"],
  "children": [
    {"level": 2, "heading": "一、多场景对比评估",
     "tables": [{"caption": "表1  国内外主流大模型网络安全能力横向对比（公开评测汇总）",
                 "header": ["评估场景", "评测来源与口径", "主要发现", "判读"],
                 "rows": [["进攻侧｜CTF 类攻防任务", "NYU CTF Bench……{{S28}}", "……{{S28}}", "……"]]}]},
    {"level": 2, "heading": "二、综合判断与选型建议", "paras": ["……", "……"]}
  ]}]}

节点可用的键：paras / tables（caption+header+rows）/ children[]（递归，可再带表格）。
渲染规则（md 与 docx 已对齐，不用手调）：

• 附件说明排正文之后（附件：1. XXX，多件时逐条列出）；没有显式写 meta.attachments 时，
  脚本自动从 appendix[].name 生成；
• 附件正文另页起排于版记之后：标识「附件一」三号黑体顶格，附件标题居中；
• 附件不进逐节评分（它不是正文的节），也不计入 body_chars——评估结果里单独给
  appendix_count / appendix_chars（含子节与表格单元格）/ appendix_prose_chars（只算段落）。

> 附件里的数字同样是"事实"，同样不许编造。 附件的表格是外部评测数据的密集区，
> 每个型号名、分数、百分比都要有登记来源；evaluate.py 的 unverified_facts 会扫描附件全文
> （含子节与表格单元格）。查不到的格子宁可留白，并在导语里写明口径（如"未列出的模型或场景
> 表示在公开渠道未检索到该口径结果"），不要用其它口径的数字填空。

记录本版（默认只出 Markdown）

$PY $SK/task_store.py record-report --task "$T" --from report.json \
  --based-on-outline outline-v2 --based-on-report report-v1 \
  --suggestions "第三部分补基层监管力量的具体表现" "把空话改成可执行表述"

一条命令完成：校验（含引注键合法性）→ 分配新版本号 → 存 report-vN.json → 渲染
report/<日期>_<名称>_vN.md（角标渲染成上标 [n]、文末自动生成编号文献表）→ 写 manifest 血缘
→ 自动跑评估（写 report-vN.eval.json / report-vN.coherence.json）
→ 自动生成评估报告 HTML（report-vN.assess.html + 摘要 report-vN.assess.json）。
把 md 内容展示给用户逐轮改；改到用户点头为止，再定稿。

> 修订后必评估（用户明确要求，不要静默跳过）：返回值里的 assessment 字段就是
> 这一版的评估结论——节数、综合/完整度/充实度均值、判定分布、需要动手的节、未核实事实、
> 呼应度均值与需改进项，以及与上一版的对比（delta / changed_sections；
> 首版则标为"首版基线"）。同时已生成 HTML 评估报告（assessment.html 给出路径）。
> 每次回复都要按阶段 4D 的八点把结论讲给用户听，并把 HTML 评估报告打开给用户看，
> 不能只贴 JSON，也不能因为"这次只改了一句话"就省略。
> 用 --no-eval 可跳过（仅批量生成时用）；用 assess 可单独重跑评估并重新出 HTML。

> 不要再跑一次 record-report 来"重新生成 md"——那条命令永远分配新版本号
> （--force 只表示"校验不通过也强行记录"）。只想重渲染 md 视图用 refresh-md，
> 只想重看评估结论用 assess。

定稿出 Word

$PY $SK/task_store.py finalize-report --task "$T" --version report-v2 [--red-header]

不修改内容，只排 Word：引注角标与参考文献节在此刻被自动剥离，交付版干净无引用标记。
--force 用于该版已定稿、仅需按新排版配置重排（finalize-report --force 与
record-report --force 语义不同，见"坑与对策"）。
需要内容与 Word 一步到位时用 record-report --docx。

交付前必须自检 + 深度检测：

$PY $SK/verify_docx.py $TD/report/*_v2.docx --format-config $TD/format-config.json

50 余项检查、按文种条件启用，分两层（普通非红头、无附件的文种实际执行 43 项；
带附件时会追加附件标识另页起排/顶格/黑体/排在版记之后/内容紧随等 5 项，
--red-header 时追加发文字号与签发人 2 项。脚本汇总行里的「共 N 项」就是本次实际执行的项数，
不要拿它跟固定数字对不上就以为漏检）：

• 第一层（浅层，"配置有没有落地"）：纸张尺寸 / GB/T 9704 A4 / 页边距 4 项 / 文档网格 /
  Normal 样式 / 标题字号居中 / 正文字体字号 / 行距固定值 / 首行缩进 / 页码域 / 奇偶页不同页码 /
  打开即刷新域 / 无 Markdown 残留 / 层次序数合法 / 无占位符 / 待补充清零 /
  过程版引注角标已移除 / 参考文献节已移除 / 跨页重复表头 / 附件标识（另页起排·顶格·黑体·排在版记之后·内容紧随）。
• 第二层（深度，"落地的细节对不对"）：版心回算（每行字数×每面行数）/ 标题字体 / 标题 keepNext /
  层次序数字体分派（一、黑体／（一）楷体／1.仿宋加粗） / 序数配对连续（正文与各附件各自编号，
  二级三级在各自上级块内重新计数） / 序数层级无跳级 / 序数段缩进 / 正文缩进一致性 /
  未用空格代替缩进 / 中文里混用半角标点 / 数字用法（公历阿拉伯数字、年份写全）/ 无全角空格 /
  无连续空段落 / 段末无多余空格 / 表格内字体字号一致 / 成文日期格式 / 署名与日期配对 /
  主送机关冒号 / 正文字体族合法 / snapToGrid=0 / 页码一字线 / 版记要素 / 附件说明左空二字 /
  版头要素（红头时的发文字号与签发人，--red-header 或自动探测）。

FAIL 一律不许交付，WARN 要在回复里说明。自检通过后再把 docx 呈现给用户。

检测出问题就纠正（尤其当 docx 不是本技能直排、而是用户给的往年文或模板稿时）：

$PY $SK/fix_docx.py $TD/report/*_v2.docx -o $TD/report/*_v2.fixed.docx   # 输出新文件并自动复检
$PY $SK/fix_docx.py <某个旧稿.docx> --dry-run                            # 先看会改什么，不写文件
$PY $SK/fix_docx.py <某个旧稿.docx> --in-place                           # 就地修（先备份 .bak）
$PY $SK/fix_docx.py <某个旧稿.docx> --only indent,punct,seqfont          # 只修指定项

铁律：纠正只动排版，一个字都不动。 可自动修复的 16 项见下节。
修完脚本会自动再跑一遍同样条件的全部自检并给出「纠正前 FAIL → 纠正后 PASS」的对照，
把这个对照连同结论讲给用户听。仍有 FAIL 的（脚本改不了的，如内容层面的日期缺失、
发文字号未提供）必须如实列出，不许粉饰。

阶段 4 · 评估：逐节打分 + 跨节呼应度 + 呈现给用户

> 这一阶段现在是自动跑的：record-report 落盘时已经执行了 4A 与 4B，结果在返回值的
> assessment 里（也写进了 report-vN.eval.json / report-vN.coherence.json）。
> 所以本节你要做的是三件事：① 读结论 → ② 需要时补填建议（4C）→ ③ 按 4D 的套路呈现给用户。
> 下面 4A/4B 的命令在单独重跑时用（例如只改了建议、或要回评历史版本），
> 一般不必再手工执行一遍。

4A 逐节评估（这一节自己够不够厚）

$PY $SK/evaluate.py $TD/report/report-v2.json \
  --task $TD/task.json --outline $TD/outline/outline-v2.json \
  --out $TD/report/report-v2.eval.json

> 也可以直接用 task_store.py assess --task "$T" --version report-v2：它会把 提纲从
> based_on_outline 自动解析出来（手工跑 evaluate.py 最容易漏传 --outline，
> 一旦漏传，打分口径就从"对标提纲承诺"退化成"只看节内自洽"，分数会明显不一致）。

对每一节给出：完整度（章节齐备/篇幅达标/摘要兑现/待补充清零/段落充分）与
充实度（数据密度/事实具体性/政策依据/结构条理/去AI味/可操作性），并列出 weak_dimensions。
evaluate.py 会先剥离引注角标与文献表再打分，所以分数与最终交付的 Word 口径一致
（另给 authored_body_chars 保留原稿字数供对比）。附件不计入 body_chars，单独给
appendix_count / appendix_chars / appendix_prose_chars——看到正文汉字数比预期少时先看这三项，
不要以为漏算了。
同时输出两类必须处理的东西：

• unverified_facts：正文与附件全文（含附件子节与表格单元格）里找不到出处的数字/文号/文件名
  → 逐条向用户交代，要么改要么确认；
  若该数值确有来源、只是没登进 task.json，把事实补进 facts[] 后加 --extra-corpus <facts.json>
  重跑即可归零（不要为了消告警直接删数字，详见 references/quality-rubric.md 第 7 节）；
• cliche_hits / ai_flavor：空话词命中与 AI 味清单（硬命中/软命中/堆砌，逐条带"命中词 + 所在句 + 怎么改"）
  → 空话词改写为"主体+动作+时限"的可执行表述；硬命中一条不留，软命中与堆砌按清单挑着改。

先做适格性判断，再决定补哪里（重要）：政策依据（只数书名号）、结构条理（只认「一是/二是」）、
可操作性（要求可操作句 ≥50%）三项在情况章、问题章、趋势章会系统性报 0 分，属误报——
不要被它牵着走把叙述体硬改成公文体。真正确认偏薄要看
篇幅达标／段落充分／摘要兑现／数据密度／事实具体性。
经验判据：完整度 ≥ 4.5 且 充实度 < 3.0 且薄弱项恰为那三项 → 大概率是误报叠加。
三种情况的处置与判据见 references/quality-rubric.md 第 5 节。

然后对 overall < 3.5 或 完整度 ≥ 4.5 而充实度 < 3.0 的节填 advice.json
（照 assets/advice.example.json）——补强材料必须来自本机已有材料，不许联网检索：

按优先级在本机找：① 任务 facts（用户已确认的事实）→ ② 任务文件夹 source/ 里已归档的参考件
（extract_source_text 能读 docx/txt/md/csv/json/html）→ ③ 本地知识库
工作根目录下的 src 与 knowledge（先 list-knowledge，两个目录都会列）。找不到就照实写
「本机材料中没有该口径数据，建议由业务处室提供」，不要用联网结果或凭印象的数字填。

$PY $SK/evaluate.py $TD/report/report-v2.json \
  --task $TD/task.json --outline $TD/outline/outline-v2.json \
  --advice advice.json --out $TD/report/report-v2.eval.json

呈现率与归档：advice_gaps 必须为空（它列出 overall < 3.5 但没填 advice 的节）；
advice.json 归档到 notes/advice-report-vN.json，评估结果留在 report/report-vN.eval.json。

> n 节偏薄：2.1（充实度 2.4，缺数据密度与政策依据）、4.2（可操作性 1.8）……
> 建议扩展：2.1 补分类整改成效并注明统计时点；4.2 补信用惩戒的依据与执行主体。
> 补强材料（离线取自本机，需你确认后才进正文）：①《…》（来自 source/2025年消防整治报告.docx）
> 要点：…；注意：该数据为全国口径，与本市不可直接比照。

> 用户在评估之外明确要求联网找素材时，才单独走一次联网检索（需
> GONGWEN_ALLOW_NETWORK=1 放行），结果只进建议区、需用户逐条确认——见「离线与隐私」章节。
> 评估本身不因联网而改变口径。

4B 跨节呼应度检查（这一篇前后接不接得上）

逐节打分是"单节内部"的质量；呼应度看的是节与节之间——开头承诺的事结尾有没有落点、
前章提的问题后章有没有逐条回应、各章开头有没有承接、术语前后是否统一、有没有跨节重复。

$PY $SK/coherence.py $TD/report/report-v2.json \
  --task $TD/task.json --outline $TD/outline/outline-v2.json \
  --out $TD/report/report-v2.coherence.json

六项指标 + 一个均值：lead_tail（开头↔结尾）、chapter_chain（相邻章主题词前向呼应）、
problem_solution（问题章逐点核对方案章）、transition（章首承接表述 + 回指词）、
terms（同物异名、简称先于全称）、duplication（跨节重复句）。

读法（重要，别只看分数）：

• 这三项用同报告内相对口径标定（lead_tail 10%／chapter_chain 12%／problem_solution 12%），
  不是绝对标准——跨节词汇重合天然低于同节内部。看每项的 evidence 里写的"同报告内参考线"。
• 真正可操作的是清单：unanswered_points（问题章里在方案章找不到词汇对应的要点）、
  missing_in_tail、missing_next、chapters_without_transition、chapters_without_lead、
  short_before_full、duplicates。分数只用来定位，改什么看清单。
• 有些低分不必强改：lead_tail 的"缘由段↔结语段"用词本就不同；
  chapter_chain:2→3 若低是因为问题章没复现前一章的系统名，那是体裁要求（复现反而让两章分工混乱）；
  terms 的"合称 vs 分称"常被误判为同物异名。每项都带 hint 教怎么读。
• 分数是提示性指标，不是判决。模型必须自己回读原文确认，再决定改不改——
  并且要明确写出"这条属误报，不必改"及理由，不要为了消数把词硬塞进正文。

改进建议必须由模型填写（脚本只出客观信号，不拍脑袋）。照 assets/coherence-advice.example.json：

{"items": {
  "problem_solution": {"expand_this": "…", "suggestions": ["…"], "rewrite": "改后示例句"},
  "terms": {"no_change": true, "reason": "经核对为『合称』，非简称先于全称，不必改"}
}}

$PY $SK/coherence.py $TD/report/report-v2.json --task $TD/task.json \
  --advice coherence-advice.json --out $TD/report/report-v2.coherence.json

advice_gaps 必须为空；建议归档到 notes/advice-coherence-vN.json。

4C 建议补填与归档（把 advice_gaps 清零）

脚本只出客观信号（哪节偏薄、哪项脱节、缺哪个维度），"该补什么内容"必须由模型填写——
从本机已有材料里找（任务 facts / 任务文件夹 source/ 已归档参考件 / 本地知识库
工作根目录下的 src 与 knowledge），不许联网检索（见「离线与隐私」）：
照 assets/advice.example.json（逐节）与 assets/coherence-advice.example.json（逐项）两个模板。

> 写 JSON 时的引号纪律（踩过坑）：建议正文里若要引用词语，必须用中文引号 “ ”，
> 绝不要用 ASCII 双引号 "——它会把 JSON 字符串提前闭合，assess --advice 直接报
> JSONDecodeError，且报错位置落在字符串中间、看不出真正原因。实测两种形态都出现过：
> ① 引号后面紧跟中文（如 说"预判/反映"）→ Expecting ',' delimiter: line N column M；
> ② 引号后面紧跟逗号或句末（如 都"有词"而、把"预判"硬塞）→ 才可能报 Expecting value: line 1 column 1。
> 别只检查 line 1：见到 JSONDecodeError 就先在建议文件里搜 ASCII 双引号
> （grep -n '"' advice.json 数一下引号是否为偶数），比盯报错行号快得多。写完必跑一次：
> python -c "import json,sys;json.load(open(sys.argv[1]));print('ok')" advice.json
> 另：报告章节里若要写"存在的主要问题""下一步工作打算"这类带引号的词，同理只能用中文引号。

判据：evaluate.py 的 advice_gaps 与 coherence.py 的 advice_gaps 双双为空，才算评估闭环。
注意这两个 advice_gaps 现在始终存在（它是"overall < 3.5 但没填建议的节"的清单，不再只在传了
--advice 时才出现）——所以它非空就是真的还没填，不是"这个功能没开"。

把建议回灌给 assess，让这一次评估自带建议与缺口状态：

$PY $SK/task_store.py assess --task "$T" --version report-v2 \
  --advice notes/advice-report-v2.json \
  --coherence-advice notes/advice-coherence-v2.json

--use-cache 只在报告内容一行未改时才复用上次结论（按内容指纹 content_hash 判定）；改了正文会自动重算，
不要为了省时间硬加这个开关。

归档：建议进 notes/advice-report-vN.json 与 notes/advice-coherence-vN.json；评估结果留在
report/report-vN.eval.json 与 report/report-vN.coherence.json，两者的摘要同步进 manifest.json。

4D 呈现给用户（每次修订后的固定动作）

这一节是硬性的。 record-report / finalize-report 的返回值里带 assessment（因为评估是自动跑的），
只要它存在，就必须按下面八点整理成人话发给用户——不要只贴 JSON，也不要静默跳过。
只在批量跑脚本、明确不需要看结论时才用 --no-eval。

评估报告是 HTML，必须打开给用户看。 每次评估都会生成
report/report-vN.assess.html（路径就在 assessment.html），把它随结论一起呈现（打开预览），
用户才能自己逐节翻、按需打印或随版本归档。HTML 里包含：KPI 卡、隐私模式（完全离线 /
拦截出网次数）、与上一版对比、判定分布、逐节明细表（含承诺摘要与薄弱维度）、
需要动手的节（补强建议 + 离线补强材料）、呼应度六项与相邻章明细、改进建议与"判定为不必改"的理由、
真实性核对、公文要素覆盖、行动清单，以及报告末尾的隐私与离线声明。

只想换一套建议重出 HTML（内容没变）时，不必重跑评估：

$PY $SK/build_assess_report.py report/report-v2.eval.json \
  --coherence report/report-v2.coherence.json \
  --summary   report/report-v2.assess.json \
  --task      $TD/task.json \
  -o          report/report-v2.assess.html

> --summary 可省，改用 --prev-eval report-v1.eval.json（可再配 --prev-coherence）
> 让脚本现算对比——对比口径与 assess 完全一致（都走 gongwen_lib.eval_delta()），
> 不会出现"对话里说 +0.4、HTML 里说别的"这种两处不一致。
> HTML 渲染失败不会连累评估：评估结果仍照常返回，只是 html 为空并在 html_error 里记原因，
> 此时要如实告诉用户"评估结论已出，但 HTML 渲染失败"。

1. 本版总评：mean_overall + 判定分布（verdict_counts：充分/基本可用/明显偏薄/不合格 各几节）+ 参评节数。
   只看均值会掩盖极端节，分布必须念出来。
2. 与上一版对比（delta_vs / delta / changed_sections）：哪几节升了、哪几节降了、各升降多少。
   首版没有前版可比，直接写「首版基线」并给出绝对分数，不要凭空编一个"提升"。
3. 需要动手的节：weak_sections / thin_sections 逐节列出薄弱维度与具体补法——这是行动项，不是分数播报。
4. 未核实事实：unverified_facts（逐条给出处或改写）——这属"数字能不能站住"，
   与第 8 点的 AI 味分属两件事，别混着说。
5. 前后呼应度：coherence_mean + coherence_metrics 各项分 + coherence_weak（需改进项）；
   判定为误报的必须明写"属误报，不必改"及理由。
6. 开放项：element_missing_required（必备要素缺失，如未署发文机关）、advice_gaps /
   coherence_advice_gaps（还没填建议的缺口）、以及仍需用户拍板的事（补数据、某口径要不要采用）
   单独列出，别混进分数里。
7. 隐私模式：说一句 assessment.offline 的状态——「本次评估完全离线（拦截出网 N 次）」；
   若显示"联网已放行"（用户显式设了 GONGWEN_ALLOW_NETWORK=1），必须如实说明，
   并提醒正文/参考件的隐私边界。不要在评估里联网，也不要为省事放行联网。
8. 去 AI 味：ai_flavor.score + severity（硬命中／软命中／堆砌各几条）+ 逐条清单
   （位置、命中词、所在句、怎么改）。硬命中一律要求改掉，一条不留；软命中与堆砌说清"改哪几处"，
   不要求全清。若上一版也有这项，把 delta.ai_flavor 一起报（升了多少／降了多少）。
   有硬命中时不能只念分数，至少把前几条原词念出来——用户要看到"哪句要改"。

跨节这一节的呈现照这个形状写：

> 前后呼应度均值 4.27（v1 为 3.11）
> 实质脱节：第三部分 19 个要点中 8 个在第四部分没有落点，集中在「自主与可控的平衡」「智能体越权风险」「模型能力边界」——建议 4.1 补自主可控、4.2 第二条点名"前沿模型对攻击链识别通过率不足半数"的现状。
> 第 1→2 章衔接偏弱（主题词覆盖率 0.081，参考线 0.12）：第 2 章未回指第 1 章的政策要求，建议 2.1 首段把政策与公司动作接起来。
> 判定为误报、不建议改：2→3 章覆盖低是因为问题章没复现前一章的系统名，属体裁要求。

4E 评估外来稿（别人写的稿，不是本技能产出的）

用户丢来一份 docx 说「评估一下」时走这条链路。与自产稿的差别全在没有原始提纲、没有登记过的事实上：

1. 建档时把原稿登记成 --ref（进 source/），--genre 走文种别名归一（如「实践锻炼总结报告」→工作总结），
   并在 --fields-json 里写 evaluation_only:true 与 source_kind:"外来稿"——提醒后续不代改内容。
2. record-outline 用「反向还原提纲」：节 id 与标题照原文，summary 按「这个标题应当兑现什么」写
   （不要照抄正文措辞），target_chars 按体裁常例给（一级 400／二级 300／三级 200），合计 ≈ 全文汉字数。
   在 open_questions 里写明「本提纲为反向还原，非作者原始提纲」。
3. report.json 忠实转录，一字不改：文字、数字、标点照原稿；原稿没有的要素（成文日期、结语、
   参考文献节）就留空——留空本身就是评估要指出的要素缺口，不要替它补上。
4. assess → 填两份 advice → assess --advice 再跑一遍，与自产稿完全相同（两个 advice_gaps 必须为空）。
   不要对外来稿跑 finalize-report（那是替人成稿）；要动它的排版先 fix_docx.py --dry-run。

四个必须自己判断的口径陷阱（脚本照常报，但解读方式不同，别被牵着改正文）：

另有三项脚本查不到、要自己扫（外来稿常见，比 GB 细节更易被忽略）：

• 零宽空格 U+200B：从网页／聊天工具粘来的稿常有（实测一稿 7 处）。python -c "t.count('\u200b')" 一扫即知；
  它会让检索、目录、格式统一全部失效。清理见 docx-ooxml-direct-fix 技能。
• 称谓混用：同一主体多种写法（如「河北信通公司」15 次 /「河北公司」15 次 /「河北电力」2 次）——
  数一遍出现次数再决定要不要提，别凭印象说。
• 成文日期缺失：外来稿常缺，且正文里的会议日期会被 verify_docx 误认成成文日期；报的时候要写清「是缺，不是写错」。

顺手核该文种骨架齐不齐（references/genres-and-structure.md §2）：缺章比句子写得差重要得多——
实测一稿最值得说的一条就是「五章里没有『存在问题／不足』这一章」。

阶段 5 · 定稿、改稿与新版本

定稿：用户确认 md 内容后 finalize-report 出 Word（角标与文献表此时剥离），
跑 verify_docx.py 自检，再把 docx 呈现给用户。定稿信息记进 manifest 与 md 状态行。

改稿：用户提修改意见时：

• 对某一历史版本的事后评价 → add-suggestion --version report-v2 --text "..."，写入 notes/，不动既有内容；
• 作为生成下一版的依据 → 传给下一条 record-report --suggestions，会同时落进 manifest 与 notes/suggestions-report-vN.json；
• 只改了排版配置、要重排 Word → finalize-report --force；
• 只想重看 md → refresh-md（不新增版本）。

新版本号自动递增（report-v3），based_on_outline / based_on_report 记清血缘。旧 md、旧 docx 与旧 json 一律保留，用户可随时翻任意历史版本下载。

改进建议要闭环：下一版的 --suggestions 应与上一版的 advice-report-vN.json
和 advice-coherence-vN.json 对得上；上一版 ai_flavor 里的硬命中也要逐条对上——
这一版改了哪几条、还剩几条，在回复里说清楚。改完 record-report 会自动重跑两份评估并重出 HTML，
assessment.delta / changed_sections 就是前后分数对比（哪项升了、哪项判定为不必改）——
按阶段 4D 呈现（结论 + HTML）即可，不必再手工跑脚本，让用户看到改稿是否真的解决了问题。
旧的 assess.html 与旧 md/docx/json 一样保留，用户可随时翻任意历史版本的评估报告。

排版深度检测与纠正

verify_docx.py 负责查（50 余项按文种条件启用，浅层 + 深度两层），fix_docx.py 负责修（16 项自动修复）。
两者共用同一套判定口径，所以「修完再查」必然一致，不会出现「检测说好了、纠正说没改」的错位。

可自动修复的 16 项（fix_docx.py）

内容红线（写死在实现里，不是"尽量遵守"）

1. 不改写、不增删任何文字。字符级归一化只允许两类：去掉段首/段末空格、半角标点转全角
   ——两者都不改变语义；除此之外一个字都不动。
2. 不编造日期、机关名、数字。date 项只做 09 → 9 这种写法归一，不做日期推断。
3. 删段落只删完全空白的段，且要求不含图形/分页符/域；连续空段至少保留一个。
4. --in-place 前先备份 .bak；默认行为是另存 <原名>_fixed.docx，不动原件。
5. 修完自动复检并把「纠正前 → 纠正后」对照讲给用户；仍有 FAIL 的必须如实列出。

什么时候用它

• 本技能直排的 docx：一般 verify_docx.py 就该全绿；出现 FAIL 说明 build_docx.py 有回归，
  用 fix_docx.py 兜底后回头查生成逻辑，不要把纠正当成常态。
• 用户给的往年文 / 别处转来的稿：先 --dry-run 看会改什么，念给用户确认，再正式修。
• 模板稿：模板往往只带版式不带 GB 细节，--format-config 传模板抽出的配置，
  让纠正按模板口径走（而不是硬套国标）。
• 只想改某一项：--only indent,punct，避免动到不该动的部分。

硬纪律（违反即返工）

1. 不编造。政策文号、统计数字、会议名称、领导姓名职务、媒体报道，一律不得臆造。查不到就写「未检索到可引用的公开数据，建议由业务处室提供」。
2. 材料只进建议区。正文只用任务 facts 与用户上传/确认的材料；要把任何材料（本机参考件或用户授权后的联网结果）写进正文，必须用户逐条确认，并在正文加来源标注。
3. 引用必登记。正文里 {{Sx}} 的每个键都必须在 task.json 的 extra.sources[]（或报告 refs[]）里有登记条目；未登记会被校验拦下。
4. 过程版带角标、正式版不带。每一版先出 md（角标 + 文献表供逐处溯源）；定稿 Word 时角标与文献表必须被剥离，verify_docx.py 会查这两项。
5. 每节摘要 ≤50 字，且必须在正式报告里兑现。
6. 新版本绝不覆盖旧版本；每版必记 based_on 与「生成前的用户建议」。要"重出同一版视图"用 refresh-md，不要重跑 record-report。
7. 交付前必跑 verify_docx.py，FAIL 不许交付。coherence.py 的 advice_gaps 与 evaluate.py 的 advice_gaps 都必须为空。
8. 低分不等于要改。适格性误报（政策依据/结构条理/可操作性、lead_tail 文体差异、chapter_chain 不复现专名）必须写清"判定为误报及理由"，不得为凑分把词硬塞进正文。
9. 模板优先：用户上传了模板就按模板抽出的 format-config.json 排；只有没模板才用 GB/T 9704。
10. 字体缺失要提醒：文档里写的是 仿宋_GB2312 / 楷体_GB2312 / 方正小标宋简体，macOS 常缺，要提示用户「Word 会字形替换，装字体后查看终稿」。
11. 附件不是正文的节。附件一律放顶层 appendix[]（渲染时另页起排于版记之后），不得塞进 sections。附件里的每个型号名/分数/百分比同样是事实，必须登记来源；查不到的格子留白并写明口径，不得拿其它口径的数字填空。
12. 修订后必评估、必展示。任何一次报告内容修订（record-report，以及改配置后重排的 finalize-report）都会自动重跑完整性/充实度与跨节呼应度评估，返回值里的 assessment 必须按阶段 4D 的八点呈现给用户（含与上一版的分数对比），并把自动生成的 report-vN.assess.html 打开给用户看。跳过仅在批量场景用 --no-eval；事后想补跑用 assess（会同时重出 HTML）。
13. 评估检测完全离线、隐私优先。逐节评估、呼应度检查、评估报告 HTML、交付自检一律不联网：
    ① 不要在评估阶段调用任何联网工具（搜索/网页抓取/浏览器等），补强材料只从本机材料取；
    ② 不要为了"方便"用 GONGWEN_ALLOW_NETWORK=1 绕开离线保护；
    ③ 不要把 report/ 里的 json/html 贴到在线预览器或任何外部服务去打开（本地打开即可）；
    ④ 评估产物只写本任务文件夹，不上传、不外发。
    用户在评估之外明确要求联网找素材时，才可单独放行一次（见「离线与隐私」），且结果只进建议区。
14. 去 AI 味、反假大空（用户明确要求）。每一版成文都要过一次「去 AI 味」自检，且硬命中一条不留：
    ① 不写万能过渡（综上所述／由此可见／值得注意的是…）、不写空转开头（随着…的发展）、
    不写空洞意义（具有重大意义／发挥了重要作用／注入新动能）、不写空洞支撑（提供了坚强保障）、
    不用含糊词（一定程度上／某种意义上）；
    ② 一句里程度副词最多留一个；排比项必须项项可落地，凑不出来的项删掉；
    ③ 行业黑话换机关日常说法（赋能→培训/支撑，抓手→具体措施，闭环→办结并回访）；
    ④ 不靠"读起来像不像人写的"自我判断——跑 deai.py 看清单，改完再跑一次确认命中消失；
    ⑤ 不要把规范表述当 AI 味删掉：文种结语（"特此报告。"）、引号内的上级原文/领导原话不算，
    必要表态可以留，但结论后面必须跟得住事实和数字。
15. 目录约定不许改：一切都挂在用户定的工作根目录下——参考资料与知识库只认 <根>/src 与 <根>/knowledge（先翻再问用户要），任务一律在 <根>/output/<公文名称>/ 下作业。根目录没确认过就先问用户（阶段 -1），别拿默认值硬开工；不要把任务建到当前工作目录、也不要自造 T20260929-001 之类的编号目录——init-task 会用公文原名建文件夹（同名自动 -2）。产品只落在这个任务文件夹里，不要散落到别处。
16. 信息不足必引导，不许猜字段。用户没给的信息（必填字段、事实数据、政策文号）一律先问：跑
    intake.py 算缺口 → 每轮问 3~5 条且把「为什么问」一起讲 → 答一轮落库一轮（update-task）。
    只有必填齐备才开工；用户答"没有/不知道"就写进 open_questions 并在正文标 【待补充】，
    不要反复追问同一件事。用户赶时间时只问必填 + 事实清单，其余用文种惯例补齐但必须显式声明补了什么。
    严禁凭常识把用户没说的事实、数字、文号"顺手补上"。
17. 交付前必跑深度检测；查出排版问题要纠正。verify_docx.py 的自检项（浅层 + 深度）里
    FAIL 一条都不许带出去；能自动修的用 fix_docx.py 修完再复检，把「纠正前 → 纠正后」对照讲给用户。
    纠正只动排版，一个字都不许改内容（允许的字符级归一化只有"去段首段末空格"与"半角标点转全角"）。
    修不了的（内容层面的缺失，如无发文字号、日期未给）如实列出，不许粉饰成"已通过"。

命令速查

> 下文 $T = 任务文件夹名（＝公文名称，即 init-task 返回的 task_id）；$TD = <工作根目录>/output/$T（本机当前是 /Users/black/AI/write/output/$T，实际以 task_store.py config 的 effective.output_root 为准）。

全部脚本用 /Users/black/.venv-gongwen/bin/python 运行。
上表所有命令都在离线保护下运行（脚本入口自动剥夺 socket 联网能力）；
唯一放行方式是显式 GONGWEN_ALLOW_NETWORK=1，仅在用户在评估之外单独要求联网时使用。

坑与对策

参考文件

与其它技能的衔接

• 需要在成稿上做 OOXML 级微调（单元格底纹、禁止跨页断行等本技能未覆盖的排版诉求）→ 用 docx-ooxml-direct-fix。
• 需要批量产出几十份长报告 → 用 batch-word-report-html2docx 的并发编排思路；本技能负责单份的合规与版本管理。
• 需要把成稿放入在线文档协作 → 转交 tencent-docs-routing。