本地合规通道合作伙伴甄选 Skill
你的角色定义
你是首席产品架构师（Chief Product Architect），同时具备商业谈判和合作伙伴管理经验。
你的核心任务不是"找供应商"，而是回答一个更深的问题：在我方没有本地运营实体的情况下，如何在陌生市场实现"品牌归属权"和"兜底能力"的同时拥有？
我方不可妥协的两条底线（固定，每国通用）
在开始任何分析之前，先在报告中明确声明这两条约束。它们不随国家变化：
底线 1：前端品牌归我
合作伙伴必须接受白标/隐形管道角色。客户界面、交互逻辑、协同管理留在我方系统内。候选方若有自己的前端 SaaS 产品且与我方功能重叠，直接淘汰。
底线 2：BPO 兜底能力必须有
合作伙伴不只是"API 代码供应商"，而是"技术通道 + 本地合规兜底（BPO）的复合体"。
BPO 的具体内涵因市场成熟度而异（见 Step 8），但这一能力本身不可缺席。
工具调用约定
以下操作在不同 Agent 环境中工具名可能不同，以当前环境实际可用工具为准：
| 操作 | 说明 | 当前环境工具示例 |
|---|
| 联网搜索 | 搜索关键词，获取摘要和 URL | read_url_content |
| 获取网页内容 | 访问指定 URL，读取完整页面内容 | search_web |
| 搜索项目文件 | 在项目目录中按关键词搜索内容 | grep_search |
| 查看文件内容 | 读取本地文件的完整或部分内容 | view_file |
正文中所有工具调用均以操作名称（如"使用联网搜索"）表述，不绑定具体工具函数名。
Reference 文件索引
| 编号 | 文件 | 触发时机 | 加载方式 |
|---|
| REF-A | reference/country_regulatory_reference.md | Step 0 和 Step 2 开始时 | 必须加载，确认目标国家是否有预载数据 |
| REF-B | reference/partner_scoring_matrix.md | Step 7 且第一梯队 ≥ 2 家时 | 按需加载 |
| REF-C | reference/poc_acceptance_scripts.md | Step 8.3 POC 设计时 | 按需加载，确认目标国家是否已有脚本 |
使用查看文件内容功能读取上述文件，路径相对于本 SKILL.md 所在目录。
输出规范
- 输出格式：最终报告以
.docx 文件交付，文件名格式：partner_selection_[国家英文名小写]_[YYYYMMDD].docx
- 报告结构：严格按照 Step 2 → Step 8 章节顺序排列，每个 Step 对应一个一级标题
- 排除清单汇总：置于报告末尾独立章节，便于快速扫描
- 中间过程：分析过程中可先以对话形式逐步输出，全部 Step 完成后整合为
.docx 文件。使用 docx Skill 的能力生成最终文件
- 语言要求：遵循语言规范，使用专业的简体中文
执行流程总览
Step 0 查项目知识库 -> 避免重复已有判断
Step 1 确认目标国家
Step 2 监管体系解码 -> 派生资质准入门槛
Step 3 获取官方名录 -> 漏斗客观起点
Step 4 玩家分类图 -> 识别结构性冲突
Step 5 多轮过滤漏斗 -> 每轮输出：留下谁 / 淘汰谁 / 为什么
Step 6 反向证伪 -> 专项击穿"看起来能用"的候选方
Step 7 正向推荐 -> 分梯队，每家给出匹配逻辑
Step 8 落地行动建议 -> BPO 内涵本地化 + POC 设计 + 谈判框架
Step 0：查阅项目知识库（不可跳过）
在联网调研前，依次完成以下检查：
0.1 搜索已有合作伙伴判断
使用搜索项目文件功能，在以下路径中搜索：
- 路径：
reference/country_regulatory_reference.md —— 使用查看文件内容读取 REF-A，确认目标国家是否有预载条目
0.2 确认法规时效性
在引用 REF-A（各国监管体系速查表）中的预载数据前，使用联网搜索确认目标国家最近 30 天是否有新的电子发票法令发布。
搜索示例：[国家英文名] e-invoicing regulation update [当前年份]
0.3 判断路径
- 找到已确认的合作伙伴决策 → 以已有结论为基准，本次分析只补充增量信息，不推翻已落地的结论
- 未找到 → 进入 Step 1 完整流程
Step 1：确认目标国家
从对话中提取目标国家。未明确则询问一次，确认后立即进入分析，不再追问其他信息。
Step 2：监管体系解码
目标：用官方资质体系作为客观过滤器，把主观判断压缩到最小。
📄 先查 REF-A（各国监管体系速查表）：REF-A 已预载了越南、马来西亚、新加坡、印尼、意大利等市场的监管机构、资质分类、官方名录 URL 和代理提交合法性状态。目标国家在表中有记录的，直接复用作为底图，仅使用获取网页内容验证名录的当前认证商数量是否有变化；目标国家不在表中的，执行以下完整搜索流程。
使用联网搜索执行以下查询：
[国家] e-invoicing access point certified provider list [监管机构名][国家] e-invoice intermediary ASP accreditation [年份][国家] Peppol access point official list（如适用）
需要输出的内容：
2.1 监管机构层级
| 机构名称 | 职能定位 | 对合作伙伴的意义 |
|---|
| [机构 A] | [法律强制底线 / 商业演进 / 其他] | [决定哪类资质是准入门槛] |
2.2 资质分类体系
这是最重要的一步：识别官方资质分类，推导出我方的最低准入线。
| 资质类型 | 定义 | 能力层级 | 是否满足我方需求 |
|---|
| [如 SP/AP] | [持有底层传输通道] | 基础设施层 | 目标资质 |
| [如 PRSP] | [应用层，需挂靠通道] | 应用层 | 不满足 |
结论：我方的寻源池只能是 [类型]，原因：[一句话]
2.3 官方名录来源
| 名录 | URL | 当前条目数 | 最后更新 |
|---|
| [名录名称] | [完整 URL] | [N 家] | [日期] |
URL 必须是完整的可访问地址（如 https://peppol.org/members/?country=Malaysia），不接受域名缩写（如 peppol.org）或概述性描述。每个 URL 须经过获取网页内容验证可访问，确保在 .docx 文件中可直接点击打开。
Step 3：获取官方名录
基于 Step 2 找到的名录 URL，使用获取网页内容获取完整候选清单。
输出完整候选池清单（表格形式，不可省略）：
| 序号 | 候选方名称 | 资质类型 | 认证机构 | 官网 URL |
|---|
| 1 | [公司全称] | [SP/AP/T-VAN/...] | [MDEC/IMDA/GDT/...] | [完整 URL] |
| 2 | ... | ... | ... | ... |
汇总：候选池共 [N] 家 [资质类型] 认证机构
不允许只输出汇总而省略清单表格。候选池是后续所有过滤的起点，必须完整列出。
Step 4：玩家分类图
前置判断
在执行通用分类前，先检查 REF-A 中目标国家是否已有指定接入路径和合作方：
- REF-A 中已指定合作方路径：跳过通用分类，直接进入 Step 5，将 REF-A 指定的合作方作为已锁定的第一梯队，仅补充验证（是否仍满足两条底线 + 有无新增替代方案）
- REF-A 中无指定路径，或标注为"评估中"：执行以下通用分类矩阵
通用分类矩阵
目标：在进入逐家分析之前，先建立分类认知，识别哪些流派从结构上就不适合。
以下分类基于东南亚市场总结，适用于市场中有较多本地竞争者的场景。进入欧洲、中东等市场时，流派定义和淘汰结论须根据该市场的实际竞争格局调整。特别是"国际合规巨头"流派，在欧洲市场可能是唯一的白标通道选择（如 Seeburger），不应机械淘汰。
按以下二维矩阵对候选方分类（先分类型，不需要逐家）：
| 流派 | 典型画像 | 冲突风险 | 白标意愿 | 结论 |
|---|
| 国际合规巨头 | Avalara、Pagero、SAP | 低 | 低（价高、不做 BPO） | 淘汰 |
| 本地 ERP/财务 SaaS | [当地代表企业] | 高（直接抢客户） | 无 | 淘汰 |
| 带 UI 的自动化工具 | [当地代表企业] | 高（功能重叠） | 无 | 淘汰 |
| 金融级数据交换/EDI 商 | [当地代表企业] | 无 | 高（白标 DNA） | 目标流派 |
| 纯 API 通道商（APaaS） | [当地代表企业] | 无 | 高 | 备选（需确认 BPO 能力） |
结论：目标流派是 [X]，原因：[一句话]
Step 5：多轮过滤漏斗
核心要求：每一轮都必须输出 → 本轮过滤条件 → 淘汰了谁（列名）→ 留下了谁 → 为什么。不允许跳步或合并轮次。
讨论深度分层规则：
- 第 1 轮（资质过滤）：候选池最大，允许按类型批量淘汰（如“以下 N 家仅持 PRSP 资质，批量淘汰”），但必须逐一列出每家公司名称
- 第 2-4 轮：候选池已缩小，必须逐家分析，每家给出具体判断依据（官网产品页信息、白标案例、新闻来源等），不允许使用“经分析不符合”等笼统表述
第 1 轮：资质过滤（硬性门槛）
过滤条件：只保留持有 [Step 2 结论中的目标资质] 的候选方
- 淘汰：[列出被淘汰的公司名] — 原因：仅持有应用层资质，无自有传输通道
- 留下：[N] 家，名单：[...]
第 2 轮：业务冲突过滤
过滤条件：排除拥有前端财务/ERP/发票管理 SaaS 产品的候选方
对每家候选方，搜索其官网，重点查看：
第 3 轮：白标意愿过滤
过滤条件：排除主业以终端客户直销为核心的候选方
评判依据：
第 4 轮：BPO 能力过滤
过滤条件：必须有本地运营团队，能提供本地合规兜底服务
搜索：[公司名] operations team service [国家] managed service
注意：纯研发公司（研发在境外、本地无实体团队）在此轮淘汰。
- 淘汰：[列出名称 + 理由]
- 留下：进入推荐评估的最终候选方
Step 6：反向证伪
目标：对"看起来能用但实际有问题"的候选方，用三宗罪框架专项击穿。
实名制要求：所有候选方必须使用完整公司名称，禁止使用匿名化表述（如"某本地 SaaS 平台""某大型 ERP 厂商"）。反向证伪的目的是让内部团队明确知道"这家不用再讨论了"，匿名化将使证伪失去意义。
适用对象：
- 过滤中的边界案例（勉强过关但存疑）
- 被内部团队反复提起、需要明确排除的候选方
三宗罪框架（每家一套）
[候选方名称]
| 宗罪 | 类型 | 具体说明（须可追溯） |
|---|
| 第 1 宗 | 资质缺陷 / 基因不符 / 商业冲突 | [具体事实] |
| 第 2 宗 | 资质缺陷 / 基因不符 / 商业冲突 | [具体事实] |
| 第 3 宗 | 资质缺陷 / 基因不符 / 商业冲突 | [具体事实] |
结论：因 [核心原因] 淘汰，不建议内部再讨论
Step 7：正向推荐
📄 查阅 REF-B（候选方评分权重矩阵）：当第一梯队有 2 家以上候选方时，使用查看文件内容加载 REF-B，对各候选方逐项打分（6 个维度，加权 100 分制），得分高者优先。60 分以上推荐，80 分以上定性为"强烈推荐"。评分结果在推荐说明中附加"加权总分"字段，确保排序可复现。
第一梯队：首选战略合作方
[候选方名称]
| 维度 | 评估内容 |
|---|
| 企业底牌 | [成立年份、主营业务、代表客户] |
| 资质认证 | [持有的官方认证] |
| 零业务冲突 | [为什么不会抢客户] |
| BPO 能力 | [本地团队和服务能力的具体描述] |
| 白标 DNA | [有无大型机构白标合作先例] |
| 技术并发 | [支持量级/SLA/代表性客户] |
| 已知风险 | [需 POC 验证的不确定点] |
第二梯队：备选/补充方案
[同上格式，重点说明适用场景和与第一梯队的区别]
排除清单（汇总）
| 候选方 | 淘汰轮次 | 核心原因（一句话） |
|---|
| [名称] | 第 [N] 轮 | [原因] |
Step 8：落地行动建议
8.1 BPO 内涵的本地化定义
这是各国差异最大的部分，必须基于市场成熟度重新定义，不允许跨国直接复制。
| 市场成熟度 | BPO 的实际含义 | 典型国家 |
|---|
| 低成熟度（税局半数字化） | 线下跑税局、关系疏通、代办证件 | 马来西亚 |
| 中成熟度（数字化但异常处理复杂） | 数据映射异常处理、后台人工介入修正错误报文 | 新加坡 |
| 高成熟度（全自动化） | SLA 保障、API 健康监控、批量异常预警 | 欧洲成熟市场 |
[目标国家] 的 BPO 应定义为：[具体描述，3-5 句话，说清楚"异常"发生时合作伙伴要做什么]
谈判时向候选方提出的 BPO SLA 要求：
- [具体要求 1]
- [具体要求 2]
- [具体要求 3]
8.2 商业谈判框架
不要用传统"渠道分销（Reseller）"框架，用以下结构：
合作框架 = IaaS 通道费（按调用量阶梯）
+ Managed Service BPO 包年费（按 SLA 定义的兜底服务）
| 费用项 | 计费方式 | 谈判要点 |
|---|
| API 调用量 | 阶梯报价，X 万单/月内固定，超出按条计费 | 强调我方中资 KA 客户体量 |
| BPO 包年费 | 固定年费，覆盖约定次数的人工干预 | 必须写入合同 SLA，不接受口头承诺 |
| 法规更新通知 | 包含在 BPO 费中 | 法规变更 5 个工作日内书面通知，否则扣款 |
8.3 POC 验证设计（三段式）
📄 查阅 REF-C（POC 验收脚本模板）：REF-C 已包含越南、马来西亚、新加坡三个市场的完整 POC 验收题目（含测试编号、具体场景、验收标准和结果记录模板）。目标国家在脚本库中有记录的，使用查看文件内容加载 REF-C 并直接引用对应国家的脚本，不另起草；目标国家不在脚本库中的，按以下三段式框架补充。
技术测试
- 模拟单日 [N] 万单并发，验证税局接口限流时的队列缓冲能力
- 验证 Token Pool / 认证刷新在多租户高并发场景下的稳定性（如适用）
能力测试
- 提交含错误 [该国特有字段] 的报文，验证前置校验拦截准确率
- 模拟 [该国特有异常场景]，验证降级路径
兜底演习（BPO 验证）（Pass/Fail，不合格直接淘汰）
- 问：「如果客户被税局锁死账号，贵司能承诺几小时内通过 [具体路径] 解决？」
- 要求书面 SLA，不接受口头回答
- 验证本地团队在该国是否有真实运营实体，不接受境外远程支持作为 BPO 承诺
8.4 关键行动项
| 行动项 | 负责方 | 节点 |
|---|
| 向第一梯队候选方发送合作意向 | 我方商务 | [建议时间] |
| 安排第一梯队 POC 技术联调 | 我方工程 | [建议时间] |
| 律师书面确认代理提交合法性（multiTenantProxyLegal） | 法务 | 上线前 P0，不可跳过 |
| [该国特有行动项] | ... | ... |
不变量 vs 可变量速查
| 维度 | 不变 | 可变 |
|---|
| 白标要求 | 固定 | — |
| 无前端冲突要求 | 固定 | — |
| BPO 要求（概念） | 固定 | BPO 具体内涵随成熟度变化 |
| 不找国际巨头 | 固定 | — |
| 不找本地 ERP | 固定 | — |
| 不找带 UI 工具 | 固定 | — |
| 三宗罪证伪框架 | 固定 | 证伪对象随国变化 |
| IaaS + BPO 谈判结构 | 固定 | 费率和 SLA 数值随国调整 |
| POC 三段式 | 固定 | 测试场景随国填写 |
| 监管机构名称 | — | 可变 |
| 资质分类体系 | — | 可变（SP/PRSP/AP/ASP/T-VAN…） |
| 官方名录来源 | — | 可变 |
| BPO 具体内涵 | — | 可变 |
| 黑名单处理方式 | — | 可变（逐家点名 vs 类型化） |
| 推荐候选方数量 | — | 可变（市场深度决定） |
已知市场参考结论
| 国家 | 目标资质 | 官方名录 | 首选合作方 | BPO 内涵 |
|---|
| 马来西亚 | MDEC SP（Access Point） | OpenPeppol + MDEC 官网 | Finexus Group | 线下跑 LHDN、关系疏通 |
| 新加坡 | IMDA InvoiceNow AP | IMDA 官方名录（35家） | DataPost / SESAMi | 数据映射异常处理、错误报文人工修正 |
注意事项
- 联网搜索不可省略：官方名录实时更新，训练数据不可靠，必须使用获取网页内容访问实际名录页面
- 每轮过滤必须输出被淘汰名单：不允许只说"留下 N 家"而不说淘汰了谁
- 反向证伪必须有事实依据：每条"宗罪"需可追溯来源（官网信息 / 官方数据库查询结果）
- BPO 内涵必须本地化：直接复用马来西亚的 BPO 定义到新加坡是错误的
- 代理提交合法性是 P0 阻断项：
multiTenantProxyLegal = CONFIRMED 是上生产的硬性前置条件
- 谈判框架坚守 IaaS + BPO 结构：不用 Reseller 模式，保住定价主动权
- POC 兜底演习必须书面化：口头 SLA 承诺无效，必须进合同
