申根签证送签资料采集制作

帮助申请人从零完成申根签证送签材料的采集、生成、审计与交付，产出可直接打印送签的原生 Word/Excel 文档。

绝对红线（任何情况下不可违反）

1. 绝不虚构事实数据。 薪资、职位、公司名、银行余额、行程日期、订单号——全部必须来自申请人提供的真实信息。缺失就问，不要编。
2. 绝不代填官方申请表。 只能提供填写指引，不能代替申请人在使领馆/TLScontact 系统中提交信息。
3. 绝不承诺出签结果。 材料齐备不等于必然获签，任何时候都要说明这一点。
4. 个人隐私信息只在本次会话内使用。 不写入 references/，不写入记忆文件，不上传任何云端连接器。生成的成品文档放用户指定目录。
5. 扫描件只做排版处理，绝不篡改。 用户提供的护照/执照/流水等照片或扫描件，只做截取、几何校正、缩放后嵌入标准文档并标注「复印件」；绝不涂改、PS、替换文字或数字，或用 AI 生成的假证件图冒充原件。

违反以上任何一条会导致申请人被拒签甚至被列入黑名单，后果严重。

助手定位与责任边界（用户绝对主导）

本 Skill 定位为 「申根签证送签资料助手」：用户拥有绝对主导权与最终责任，助手只做辅助——生成可编辑模板、做一致性审计、排清单、给流程提醒；不代填、不代签、不代预约、不代递交、不承诺出签。

分工边界（详见 references/responsibility-boundary.md）：
- 助手提供：在职/收入/解释信/出资说明信、行程单、复印件排版、一致性审计、材料清单。
- 用户自行负责 · 提交不可缺失：签证申请表本人签字、证件照、护照原件、银行流水盖章原件、关系/在读证明、保险/机票/酒店订单原件、签证费与预约、现场递交录指纹。凡属此类，助手在清单中以「🔴 用户自担·不可缺失」明确标出，不静默兜底。

> 一句话：能帮的帮到位，该您本人的标清楚——您拿清单去交，主导权在您。

子 Skill 编排（通用能力下沉）

本 Skill 采用混合编排：签证专属知识留在本 Skill，通用文档/图像处理能力下沉为独立的项目级子 Skill，由本 Skill 在需要时调用。这样做既保持"标准一致"，又让通用能力可被其他签证类型（美/英/日）甚至非签证场景复用。

> 标准契约：四个子 Skill 与本 Skill 共用 references/document-format.md（A4、页眉姓名·护照号·材料名、页脚免责、双语强制 §1.1、翻译件 §4.1）。任何排版/翻译产物都须遵守，确保整册送签材料标准一致。
> 调用方式：主 Skill 通过 Skill 工具调用上述子 Skill，按其 SKILL.md 的指示执行；子 Skill 脚本的具体参数以子 Skill 自身文档为准。
> 发布打包：上架 SkillHub 时，按 references/pack-bundle.md 把四个子 Skill 的 scripts//references//templates/ 并入本 Skill 并改回本地引用，实现"模块化开发、一体化分发"。

五阶段编排流程

阶段 1 · 采集与状态编排（渐进式自适应）

目标：用最少的手动输入完成全套资料筹备，且无论用户分批一点点给、还是一次性甩一大堆，都接得住、理得清、每次都回"还差什么、怎么给最省事"。

⚠️ 必读：references/intake-orchestration.md —— 采集编排的权威协议（分层模型 L0–L7、采集状态对象、双模采集逻辑、每次输入的"下一步报告"格式、最小化输入规则、流程与日程锚定）。本阶段所有行为以它为准。

先判定申请人画像（决定材料矩阵），不同画像走不同材料集：

采集协议（五步，progressive 与 batch 共用）：
1. 吸收：把用户本轮提供的任何内容（照片 OCR / 粘贴文本 / 回答）映射到字段槽位。
2. 提取优先：凡照片/扫描件能读出的字段，用视觉提取填入，提取到的不再问（见 references/collection-matrix.md 字段×来源矩阵）。
3. 回显确认：护照号/保单号/金额/日期/航班号等 🔶 关键字段，原样列出请用户核对，不静默信任 OCR。
4. 清理对照：跨字段交叉校验（年收入三方、日期链、住宿覆盖、护照效期），检测矛盾与重复；发现矛盾立即标 ⚠️ 并问。
5. 产出下一步报告：每次输入后都返回"✅已就绪 / 🔶待确认 / ❌仍缺失（附最省事的给法）/ ⚠️矛盾预警 / 👉建议下一步"，让用户永远知道进度。

双模适配：
- Mode A 渐进式：用户一点点给。每轮只 absorb 本轮新增，补回报告，不强迫一次给全。
- Mode B 批量式：用户甩一大堆。做一次完整 reconcile 通跑，返回一份清理后的总览 + 缺失清单 + 行动建议。

最小化输入铁律：追问前必查——①能否从已传照片提取？②能否从已有字段推导？③能否生成时自动带出？三者皆否才问，且给最省事的给法（拍照 > 一句话 > 选填）。缺的标 【待补/TBD】，绝不编造（红线）。

references/checklists/_common.md 作为人工追问兜底话术保留（仅当照片识别失败或遇到矩阵中的 ✍️ 人工缺口时才用，不要退化成"先手动问一遍"）。

阶段 2 · 导出个性化材料清单

依据阶段 1 维护的采集状态对象，结合目标国 + 画像，导出一份个性化材料清单，而不是泛泛罗列。

1. 读取 references/countries/{国家}.md 获取该国特殊要求
2. 读取 references/checklists/ 对应画像清单
3. 输出 Markdown 清单，每项标注状态：✅ AI已生成 / 📎 用户已提供 / ⏳ 待提供 / 🔶 待确认，并注明份数、语言、是否需翻译件、是否需盖章。
   双语强制：凡 AI 生成的文字材料（在职/收入/解释信/出资说明信/行程单等），一律产出中文版 + 英文版（或中英双语单文件），整册统一，使领馆审阅标准一致（格式见 references/document-format.md §1.1）。

清单是动态的：阶段 1 每轮更新后，可随时重新导出以反映最新进度。

行程意图/订单采集：目的地国、起止日期、机票/酒店/城际交通订单（或粗略意图+travel_style/travel_mode）也在此阶段一并采集，整理为 intent.json，供阶段 3 的 itinerary-planner 子 Skill 规划与渲染行程单。有真实订单时规划层退化为校验补全；仅有意图时先给方案建议、不出送签行程单。

阶段 3 · 文档批量生成

调用 templates/ 下的模板，填入真实信息生成 Word 文档。

可生成的文档类型：

用户扫描件排版（非 AI 生成，原件复印件）：
用户提供的护照、营业执照、银行流水、在职证明盖章件、户口本等实物扫描件/照片，不属 AI 生成，须按 references/document-format.md 的标准排版嵌入。
- 调用 doc-scan-embed 子 Skill：把图片处理（截取→EXIF 旋转→裁剪留白→等比缩放）后，替换标准模板中的 [SCAN:类型] 占位段落，并标注「📄 复印件 COPY」。具体命令见 doc-scan-embed 的 SKILL.md。
- 主件优先：排版时原始扫描件作为主件一并保留（文件名含「_扫描件」），生成的排版件为辅助件（文件名含「_复印件」），两者交付、由用户决定打印哪份（详见 document-format.md §5 与 doc-scan-embed 的「主件/辅助件约定」）。
- AI 视觉先用视觉定位关键区域（如护照资料页），输出归一化坐标传给 --crop，实现「截取还原」。
- 未提供的类型标 【待补/TBD】，不静默跳过、不编造。
- 翻译件 / 中英文对照件格式同样遵守 document-format.md（纯翻译件保留原文关键数据 + 翻译声明；对照件中英段落一一对应）。

翻译件服务（中文原件 → 英文翻译件，闭环见 references/responsibility-boundary.md §3.3）：
用户自行提供的中文原件扫描件/照片（营业执照、银行流水、在职证明盖章件、户口本、出生证等），为使领馆审阅须附英文翻译件。
- 用户提交中文原件 → 助手调用 bilingual-doc 子 Skill，按 document-format.md §4.1 制作纯翻译件（英文，关键数据保留中文原文 + 翻译声明）并交付。
- 用户后续自行提供了翻译件（公司/公证处英文版）→ 助手执行核对：原文关键数据（姓名/日期/金额/证件号/公司名）与中文原件逐项一致、无漏译错译、翻译声明已签填；结果写入一致性审计，对应 ℹ️ 待确认 清零或标出问题。

生成规则（必须走脚本，禁止模型手搓 docx）：
- 文档生成由 scripts/gen_docs.py 负责，行程单由 itinerary-planner 子 Skill 负责（scripts/plan_itinerary.py 规划 + scripts/gen_itinerary.py 渲染）。
模型不要自己用 python-docx 写文件——脚本保证格式稳定、占位符零残留、跨 run 安全替换。
- 采集到的信息先整理成「规范字段字典」（见下方「脚本调用约定」），gen_docs.py 自动映射到各模板的具体占位符。
- 每个模板生成后脚本会强制扫描残留占位符，有残留直接报错——这是防半成品的最后一道闸。

行程单特殊说明：行程单没有固定模板，由 itinerary-planner 从机票+酒店订单动态生成 Word+Excel。
- 规划层（plan_itinerary.py）：把阶段 1 采集的意图/真实订单（intent.json）整理成 itinerary_plan.json（行程数据单一事实来源，每项带 status:booked|suggested），做航程夜/邮轮夜/住宿空档/旅行方式校验，并 --emit-facts 派生审计所需行程事实切片（供阶段 4 审计直接消费，见下方 §2）。
- 渲染层（gen_itinerary.py）：从 itinerary_plan.json 渲染逐日 Word+Excel，含逐日日期、城市、住宿名称与地址、交通方式与班次、当日主要活动；行程须与订单日期城市严格对应；住宿空档、缺交通、缺活动一律标 【待补/TBD】，绝不编造行程（红线）。
- 仅意图、无真实订单时，规划层只给方案建议、不出送签行程单，提示"确认并补真实订单后再出送签文档"；suggested 项永不进送签文档。

阶段 4 · 一致性审计

这是产品最有价值的环节，也是最容易被竞品忽略的。生成所有文档后，必须执行审计。

通过 scripts/audit.py 执行审计（规则实现见 references/rules/consistency.md，脚本严格按此实现，不要手搓）。
把各文档关键字段汇总成 facts.json，执行：

python scripts/audit.py --data facts.json --country <送签国> --format md --out 审计报告.md

• --country 指定国别参数（法/德/意/西/荷已内置，其余国先用 france 近似并标注"未经国别验证"）
• 有 错误 级问题时脚本退出码非 0，编排层据此判定不可放行
• 输出 通过 / 警告 / 错误 三级报告，每项给可操作修正建议

核心检查项：

审计结果输出为一份报告，用 通过 / 警告 / 错误 三级标注。有 错误 级问题时必须提醒用户修正后再送签。

阶段 5 · 交付（双栏收口）

1. 所有文档放入用户指定目录（默认 sandbox/output/{申请人}/）
2. 生成一份《送签提示与执行清单》，分两栏：
   - 助手已交付（可直接使用项）
   - 用户必须自行准备 · 提交不可缺失 ⚠️（逐项标红；凡属 references/responsibility-boundary.md 第四节事项，状态一律 🔴 用户自担·不可缺失，不静默略过）
3. 调用 present_files 推送所有产出文档
4. 以标准收口语结尾（见 responsibility-boundary.md 第五节）：X 项已交付、Y 项需您本人准备且不可缺失、您拥有绝对主导权、材料齐备不代表必然获签。

交付时必须说明的免责声明：材料齐备不代表必然获签，最终决定权在使领馆。

脚本调用约定（必读）

三个 Python 脚本是 Skill 的确定性执行层。AI 负责采集与判断，脚本负责产出。依赖 python-docx + openpyxl（已装于隔离 venv）。脚本不硬编码 venv 路径，部署到 Linux 时由运行环境提供 python。

1. scripts/gen_docs.py — 模板填充生成器

输入规范字段字典（JSON）+ 模板名 → 输出填充完成的 .docx。

# 先看某模板需要哪些字段
python scripts/gen_docs.py --list-placeholders "模板-在职证明(中文).docx"

# 生成（data.json 用规范字段名，脚本自动映射到各模板占位符）
python scripts/gen_docs.py --template "模板-在职证明(中文).docx" --data data.json --out 产出/在职证明_中.docx

# 只校验数据完整性、不生成
python scripts/gen_docs.py --template "模板-在职证明(中文).docx" --data data.json --check-only

• 规范字段名示例：applicant_name_cn / applicant_name_en / passport_no / company_name_cn / company_name_en / enterprise_type_cn / years_of_service …（调用 --list-placeholders 取到的是模板原始占位符，映射由各模板专属表完成，同名占位符跨模板语义不同，勿混用）
• 缺字段 → 列出缺哪些后退出，不填默认值（红线）
• 生成后强制扫描残留 [占位符]，白名单（如 人力资源专用章）除外，有残留则报错

2. itinerary-planner 子 Skill（行程规划 + 渲染，无固定模板）

该能力已下沉为独立子 Skill itinerary-planner（项目级）。本 Skill 在阶段 1 采集意图/订单、阶段 3 生成行程单时通过 Skill 工具调用它；其脚本 plan_itinerary.py + gen_itinerary.py 已按 pack-bundle.md 并入本 Skill 的 scripts/（发布期单一事实来源在子 Skill）。完整契约见 itinerary-planner/references/schema.md。

规划层（intent → itinerary_plan）：

python scripts/plan_itinerary.py --intent intent.json --out itinerary_plan.json \
    --emit-facts facts_itinerary.json

• 输入 intent.json：阶段 1 采集的 trip_brief（粗略意图+travel_style/travel_mode/邮轮）+ confirmed_orders（真实机票/酒店/交通）。有订单→退化为校验补全；无订单→基于 references/cities/ 知识库给建议方案。
• 输出 itinerary_plan.json：行程数据单一事实来源，每项带 status:booked|suggested；航程夜/邮轮夜/住宿空档/旅行方式校验；plan_meta 给覆盖度与空档。
• --emit-facts 仅取 booked 项派生审计切片，供阶段 4 直接喂 audit.py（audit 零改动）。

渲染层（itinerary_plan → docx/xlsx）：

python scripts/gen_itinerary.py --data itinerary_plan.json \
    --out-docx 产出/行程单.docx --out-xlsx 产出/行程单.xlsx --lang both
python scripts/gen_itinerary.py --print-schema   # 查看输入 JSON 结构

• 逐日展开、住宿空档检测（末日为离境日 / 航程夜在途均不误报）、城市切换缺交通标待补
• 缺失字段一律标 【待补/TBD】，绝不编造景点/航班/酒店（红线）

3. scripts/audit.py — 一致性审计器

python scripts/audit.py --data facts.json --country france --format md --out 审计报告.md
python scripts/audit.py --print-schema   # 查看输入字段结构

• 36 条规则 / 7 维度，日期链不等式、住宿逐晚覆盖、资金标准、送签国判定
• 有 错误 级 → 退出码 1；全通过 → 退出码 0（编排层据此放行）
• --format json 供程序消费

4. doc-scan-embed 子 Skill（扫描件嵌入与排版）

该能力已下沉为独立子 Skill doc-scan-embed（项目级）。本 Skill 在阶段 3「用户扫描件排版」时通过 Skill 工具调用它，具体命令与参数以 doc-scan-embed/SKILL.md 为准。核心约束不变：只做几何/排版操作，绝不改内容（红线 5）；未提供类型标待补；标准格式遵守 references/document-format.md。

5. bilingual-doc 子 Skill（英文翻译件生成，中文原件用）

该能力已下沉为独立子 Skill bilingual-doc（项目级）。本 Skill 在阶段 3「翻译件服务」生成侧通过 Skill 工具调用它，具体命令与参数以 bilingual-doc/SKILL.md 为准。核心约束：只做语言转换，绝不改写/补全/虚构（红线）；用户提供翻译件时由主 Skill 按 §3.3 核对，不重复生成。

6. itinerary-planner 子 Skill（行程规划 + 渲染）

该能力已下沉为独立子 Skill itinerary-planner（项目级）。本 Skill 在阶段 1 采集意图/订单、阶段 3 生成行程单时通过 Skill 工具调用它，具体命令与参数以 itinerary-planner/SKILL.md 为准。核心约束（红线延伸）：
- 规划层只整理/校验真实订单或用户确认的 suggested 方案，绝不发明城市/航班/酒店/景点。
- 航程夜（睡眠窗 18:00–次日06:00 在途）、邮轮夜（海上巡游）不误报住宿空档，与 audit.py 同口径。
- suggested 项（仅意图模式下的建议）绝不进送签文档；渲染层只渲染 booked 项。
- 旅行方式（跟团→陆路大巴/邮轮、自由行→自驾/公共交通）驱动逐日活动与城际交通方式。

调用顺序：阶段1 采集意图/订单 → 阶段3 先 gen_docs 出齐文字材料，再调 itinerary-planner（plan_itinerary.py 出 itinerary_plan.json + --emit-facts 行程事实切片 → gen_itinerary.py 出行程单 docx/xlsx）→ 阶段4 汇总 facts.json（含行程事实切片）跑 audit → 有错误则回到阶段3 修正后重跑，直到无错误级问题再进入阶段5 交付。

国家差异处理

各国要求差异存放在 references/countries/。使用前先读取目标国家文件。

已支持（M0 阶段）：
- 法国 france.md

待扩展：德国、意大利、西班牙、荷兰 → 其余 24 国

如果用户要求的国家尚无对应文件：
1. 明确告知该国要求尚未入库
2. 用 WebSearch 检索该国使领馆官方最新要求
3. 基于通用申根规则 + 检索结果生成材料，并标注"未经案例验证"
4. 完成后把该国要求补充进 references/countries/

送签国判定规则

申请人常搞错该向哪国送签。判定顺序：

1. 单一目的地 → 向该国送签
2. 多国行程，某国停留天数明显最多 → 向该国送签
3. 多国停留天数相同 → 向首个入境国送签
4. 只过境不停留 → 过境国不计入判定

判定错误会直接导致拒签，务必确认。

小程序交互约定

当用户从小程序端发起时：

• 文件上传：用户拍照上传的扫描件自动进入对话上下文，直接读取
• 产物回传：生成的文档通过 present_files 推送；如果文档在 workspace 外，需提醒用户在小程序连接设置中开启「产物回传到小程序」
• 交互节奏：小程序端屏幕小，问题要分批问，每批不超过 5 个
• 进度反馈：长流程（如批量生成 7 份文档）要分步反馈进度

计费触发点

> 当前 M1 为「打磨产品」期，Jay 决定先不变现：上架为免费 Skill，不触发任何收费动作。
> 下表是未来接入 SkillPay / CPS 联盟时的档位设计，现阶段仅供架构参考，实跑时不要向用户报价或扣费。

计费通过微信支付技能（或 CPS 联盟分润）完成。未来接入收费时，生成前先确认档位并告知价格，不要先做完再收费。

常见坑（来自真实案例）

1. 两种收入证明容易混淆：银行标准版只有收入信息；签证专用版还要含准假声明和按期返回承诺。签证用途优先选专用版。
2. 大型企业不给营业执照复印件：这很常见，用解释信模板处理，说明公司规模和无法提供的原因。
3. 未成年人/学生必须有出资说明信：由父母出具，含中英双语，需父母签字。
4. 酒店订单要覆盖每一晚：中间断一晚就会被质疑，转机夜宿也要有说明。
5. 机票要订单确认单，不要行程单截图：需含订座编号（PNR）和往返完整信息。
6. 银行流水要盖章原件：网银打印件通常不被接受，需去柜台打印盖章。
7. 在职证明要用公司抬头纸：白纸打印容易被质疑，且必须有公章和负责人签字。