Verify Deliver

Safety Rules

参见 _shared/core/safety-rules.md

关键补充：本技能不新增破坏性操作。校验是只读的；修复写新文件；删除旧文件必须先验证新文件可打开且内容正确。

先验证后交付 (Verify Before Deliver)

用户的最高频纠正（历史统计：纠正类消息 900+ 次）集中在三条：先自己完整测试验证，解决所有问题再汇报；要真实执行，不要只描述；交付前必须自己全面验证。本技能把这三条固化成可执行的交付前协议。

五步交付协议

Step 1 真实执行（不做"口头交付"）
   任何任务的产出必须是磁盘上的真实产物：编译出的 PDF、渲染出的 SVG/PNG、
   生成的 xlsx/docx、写好的代码文件。禁止用"我已经写好了思路/我会做X"代替执行。

Step 2 校验清单（对产物运行可复现的检查）
   a) 可打开性：docx/xlsx/pdf/图片/HTML 用对应库重新打开不报错；
   b) 内容正确性：关键字段（姓名、数字、奖项、引用、编号）与源核对一致；
   c) 格式保真：字体、字号、合并单元格、页眉页脚、表格边框未被破坏；
   d) 完整性：批处理无文件丢失、无覆盖错误；文档无多余改动；
   e) 一致性：同一数据在 表格/正文/报告 三处数字完全一致。

Step 3 修复循环
   发现任何问题 → 修复 → 重新校验 → 直到清单全绿。禁止带病交付。

Step 4 无损确认
   涉及覆盖/删除原文件时：新文件先通过校验，再动原文件；
   或先备份原文件。宁可多留备份，不可丢失数据。

Step 5 汇报（先结论后证据）
   汇报顺序：①交付了什么（路径）②通过了哪些校验 ③做过哪些修复
   ④遗留风险（若有）。不要先说过程，先说可用的结果。

校验清单模板（按产物类型）

文档类（docx/xlsx/doc）

• Document(path) / load_workbook(path) 能打开，无损坏
• 合并单元格填充位置正确（读取回填文本核对）
• 签字行/尾部保留（如"负责人签字""年 月 日"未被覆盖）
• 字体为预期（宋体/微软雅黑/宋体小四 等）
• 数字与用户确认口径一致

表格/图片类（xlsx/图）

• 行数、类别计数与预期一致（写脚本统计后断言）
• 图片旋转后文字方向正确（OCR 复核）
• 命名规范符合约定（正则校验文件名）
• 原文件备份存在（若覆盖过）

代码类

• 测试通过（pytest 限定范围，禁无范围全量跑）
• lint/格式通过（ruff）
• 关键路径真实执行过（不是静态分析过）

数字口径铁律（通用）

1. 与源核对时发现矛盾，列出证据链（各自出处），不要静默选一个。
2. 以用户最后确认的口径为准，用户给的数字优先级最高。
3. 需要区分统计的（如软著"一作/参与"、论文"一作/通讯/参与"、奖项"国家级/省级/校级"）必须分开，不混计。

Anti-Patterns

文件结构

skills/verify-deliver/
├── README.md
├── SKILL.md
├── rules/
│   ├── checklists.md    # 各产物类型校验清单
│   ├── fix-loop.md      # 修复-重验循环协议
│   └── reporting.md     # 汇报顺序与话术
└── scripts/
    └── verify.py        # 通用校验工具（docx/xlsx/pdf/图片/文本一致性）

版本历史