// 仲裁者模式设计器。设计以"真相即服务"为核心的商业模式： 提供可验证的真实信息和判断，让用户相信每个数字都是真的。 基于《AI确定性商业模式》概念卡。
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | p6b-arbiter-mode-designer |
| description | 仲裁者模式设计器。设计以"真相即服务"为核心的商业模式： 提供可验证的真实信息和判断，让用户相信每个数字都是真的。 基于《AI确定性商业模式》概念卡。 |
设计一个"每个数字都是真的"的产品，让用户为可验证的真实信息付费。
行业 + 用户痛点 + 可验证的信息类型。
示例输入：
行业: 金融投资
用户: 个人投资者
痛点: "市面上太多虚假信息，不知道该信谁"
可验证信息: 公司财务数据、监管文件、行业报告
任务：明确产品承诺提供哪些类型的可验证信息。
输出：
真相范围:
information_types: ["可提供的信息类型"]
verification_methods: ["验证方法"]
sources: ["信息来源"]
limitations: ["不能保证的范围"]
任务：让用户能够验证每个信息的真实性。
输出：
验证机制:
transparency_level: "透明度等级"
traceability: "是否可追溯到原始来源"
third_party_verification: "是否有第三方验证"
user_audit: "用户是否可以自己验证"
update_frequency: "信息更新频率"
任务：建立产品的可信度和权威性。
输出：
权威背书:
data_sources: ["数据来源及其权威性"]
partnerships: ["合作伙伴"]
certifications: ["认证和合规"]
expert_review: "是否有专家审核"
methodology: "信息处理方法论"
任务：将真相服务转化为可持续的收入。
收费方式：
收费模式:
- 订阅制: "无限次验证服务"
- 按次计费: "每次验证收费"
- 分级服务: "基础信息免费，深度验证付费"
- 企业服务: "定制化验证解决方案"
arbiter_mode_design:
input:
industry: "行业"
user_pain: "用户痛点"
verifiable_info: ["可验证信息类型"]
truth_scope:
types: ["信息类型"]
methods: ["验证方法"]
sources: ["来源"]
limits: ["限制"]
verification:
transparency: "透明度"
traceability: "可追溯性"
third_party: "第三方验证"
user_audit: "用户自审"
update_freq: "更新频率"
authority:
sources: ["数据来源"]
partners: ["合作伙伴"]
certifications: ["认证"]
experts: "专家审核"
methodology: "方法论"
pricing:
model: "收费模式"
tiers: ["服务等级"]
unit: "计费单位"
value_proposition: "价值主张"
moat:
data_flywheel: "数据飞轮"
brand_trust: "品牌信任"
network_effects: "网络效应"
switching_cost: "转换成本"
设计：
仲裁者模式的核心不是信息本身，而是信息的可验证性。
仲裁者模式的核心逻辑是：不让 AI 去"创造"新东西，而是让 AI 去"检验"已有的东西。 它不生产内容，它只是内容的质检员。它不回答"什么是正确的"，而是回答"这个说法是不是正确的"。
与传统搜索/查重的区别：
| 维度 | 传统搜索 | 传统查重 | 仲裁者模式 |
|---|---|---|---|
| 输出 | 匹配结果 | 相似度分数 | 验证结论 + 证据链 |
| 信息判断 | 不判断真假 | 不判断对错 | 明确说"这是真的"或"存疑" |
| 数据源 | 全网索引 | 文本比对 | 权威数据源白名单 |
| 可追溯性 | 链接（可能失效） | 文本片段 | 完整证据链 + 置信度 |
仲裁者模式的技术核心：任何结论都必须经过至少三个独立权威源的交叉比对。
工作流程：
用户提交内容 → 查询权威数据源白名单 → 多源并行比对
→ 各方说法一致 → 输出验证结论（置信度 99%+）
→ 存在分歧 → 标记冲突，人工或高级别验证处理
→ 无相关数据 → 标注"无法验证"，不猜测
关键原则：AI 在这里的角色不是"创造"，而是"搬运"和"比对"——它只是权威数据的校验员。任何数据冲突都会被标记，而非由 AI 自行判断。
每一次验证结果，都必须清楚地告诉用户：这个结论是从哪来的。
证据面板要素：
核心价值：客户买的不是 AI 的"智能"，而是 AI 的"可靠"。可靠的核心就是可追溯——你让我相信这个结论？先让我看看你是怎么得出这个结论的。
在法律、医疗、金融等高度监管行业，溯源透明化还有额外价值：审计追溯。当监管机构来检查时，企业需要证明自己的决策有依据，仲裁者模式的溯源能力完美满足合规需求。
| 业务核心 | 更值钱的能力 | 典型场景 |
|---|---|---|
| 创造价值 | 生成 | 营销文案、代码开发、图片创作 |
| 避免损失 | 验证 | 合同审查、医疗决策、投资判断 |
验证更值钱的行业共同特点：错误成本极高。 一份合同漏掉一个条款可能损失数百万，一次误诊可能危及生命。在这些场景下，"确定性"不是奢侈品，而是必需品。
| 护城河维度 | 具体表现 |
|---|---|
| 数据飞轮 | 每次验证产生反馈数据 → 模型优化 → 准确率提升 → 更多用户 → 更多数据 |
| 品牌信任 | "经过 XX 验证"成为行业可信度标签 |
| 权威数据源 | 独家或深度合作的数据源是核心壁垒 |
| 审计追溯 | 合规价值随使用时间累积，转换成本极高 |
明确产品承诺提供哪些类型的可验证信息。
自检四问：
输出：
truth_scope:
information_types: ["可提供的信息类型"]
verification_methods: ["验证方法"]
sources: ["权威数据源白名单"]
limitations: ["不能保证的范围"]
建立技术架构，确保每个结论都经过多源比对。
架构设计要点：
输出：技术架构文档 + 数据源清单 + 冲突处理规则
让每个验证结论都可追溯、可审计。
证据面板设计：
验证结论: "条款 X 在加州法律下存在风险"
置信度: 97.3%
证据来源:
[1] 加州民法典第 XX 条 (权重: 高)
[2] 2023 年 Smith v. Jones 案判例 (权重: 中)
[3] ACCA 合规指南 (权重: 中)
未覆盖源: [联邦法规数据库 - 未找到相关信息]
输出：UI 原型 + 证据面板规范 + 置信度计算规则
建立产品的可信度和权威性。
权威背书四要素：
输出：合作伙伴清单 + 认证路径 + 专家顾问团
将真相服务转化为可持续的收入。
定价策略（类似公证费模式）：
| 模式 | 适用场景 | 定价逻辑 |
|---|---|---|
| 按次计费 | 低频高价值验证 | 每次验证固定费用，复杂验证价格更高 |
| 订阅制 | 高频使用的企业用户 | 年费无限使用，量越大单价越低 |
| 批量折扣 | 大规模验证场景 | 验证量越大单价越低，符合规模经济 |
| 分级服务 | 不同深度需求 | 基础查询免费，深度验证付费 |
关键心理差异：
确保验证越多，产品越好，形成正循环。
飞轮路径：
用户提交验证 → 系统验证并记录 → 发现新的风险模式
→ 更新验证规则 → 准确率提升 → 吸引更多用户
→ 更多验证数据 → 更多风险模式 → 更强的验证能力
场景：一家 LegalTech 创业公司要为中型律所（50-200 名律师）打造 AI 合同风险验证平台，对标 Harvey AI（$110 亿估值）但面向中小客户。
输入：
行业: 法律
用户: 中型律所律师
痛点: "审查合同太慢，但不敢完全信任 AI 的判断"
可验证信息: 合同条款风险、判例引用、合规性
执行流程：
定义真相范围：
设计多源交叉验证架构：
设计溯源透明化：
建立权威背书：
设计收费模式：
输出：
arbiter_mode_design:
input:
industry: "法律"
user_pain: "合同审查慢但不敢信任 AI"
verifiable_info: ["合同条款风险", "判例引用", "合规性"]
truth_scope:
types: ["合同风险条款", "判例法引用", "监管合规"]
methods: ["多源交叉验证", "置信度评估"]
sources: ["Westlaw", "LexisNexis", "SEC EDGAR", "州法院数据库"]
limits: ["不覆盖国际法", "数据截至日期限制"]
verification:
transparency: "高 - 每个结论附证据面板"
traceability: "是 - 可追溯到原始判例和法规"
third_party: "法律数据库提供商交叉验证"
user_audit: "律师可自行查阅引用来源"
update_freq: "每日同步法规变化"
authority:
sources: ["Westlaw", "LexisNexis"]
partners: ["ABA 技术评估合作伙伴"]
certifications: ["ABA 技术评估认证"]
experts: "5 人法律专家顾问团"
methodology: "3 源交叉验证 + 冲突标记 + 置信度分层"
pricing:
model: "订阅制 + 分级服务"
tiers: ["基础版 $299/月", "专业版 $799/月", "企业版 $2,999/月起"]
unit: "按律师数/月"
value_proposition: "$500/份合同验证 vs 人工 $20,000/份"
moat:
data_flywheel: "强 - 每次验证产生风险模式数据"
brand_trust: "可建 - '合同安全守门人'定位"
network_effects: "中 - 验证规则随使用量优化"
switching_cost: "高 - 律所工作流深度集成"
场景：一家 FinTech 公司要为个人投资者打造金融信息验证平台，帮助识别市面上的虚假信息和误导性报告。
输入：
行业: 金融投资
用户: 个人投资者
痛点: "市面上太多虚假信息，不知道该信谁"
可验证信息: 公司财务数据、监管文件、行业报告、分析师评级
执行流程：
定义真相范围：
设计多源交叉验证架构：
设计溯源透明化：
建立权威背书：
设计收费模式：
输出：
arbiter_mode_design:
input:
industry: "金融投资"
user_pain: "虚假信息泛滥，不知道该信谁"
verifiable_info: ["公司财务数据", "监管文件", "行业报告", "分析师评级"]
truth_scope:
types: ["上市公司财务数据", "监管处罚", "分析师评级", "交易所公告"]
methods: ["多源交叉验证", "异常检测", "历史一致性检验"]
sources: ["SEC EDGAR", "Bloomberg", "交易所公告", "公司 IR 页面"]
limits: ["不覆盖非上市公司", "不提供投资建议"]
verification:
transparency: "高 - 每个数据点标注来源"
traceability: "是 - SEC 文件编号 + 公告日期"
third_party: "SEC EDGAR 官方数据 + Bloomberg 交叉"
user_audit: "用户可自行查阅 SEC 文件原文"
update_freq: "实时同步交易所公告，日频同步 SEC 文件"
authority:
sources: ["SEC EDGAR", "Bloomberg"]
partners: ["SEC 注册投资顾问"]
certifications: ["SEC RIA 合规认证"]
experts: "3 位 CFA 持证人审核"
methodology: "2 源交叉 + 异常突变检测 + 历史偏差分析"
pricing:
model: "免费增值 + 订阅制"
tiers: ["免费版（3次/日）", "投资者版 $19.99/月", "专业版 $99.99/月"]
unit: "按用户/月"
value_proposition: "每天 $0.66 获得可验证的金融真相"
moat:
data_flywheel: "强 - 验证反馈优化异常检测模型"
brand_trust: "可建 - '金融信息守门人'定位"
network_effects: "中 - 用户举报形成社区验证网络"
switching_cost: "中 - 投资者习惯和历史数据积累"
| 误判 | 错误认知 | 正确做法 |
|---|---|---|
| 过度承诺 | "我们的 AI 保证 100% 准确" | 诚实标注置信度和局限性，宁可说"无法验证"也不猜测 |
| 验证不足 | "声称可验证但用户无法实际验证" | 每个结论必须附带可查阅的证据链 |
| 数据渠道单一 | "依赖单一数据源，风险集中" | 至少 3 个独立权威源交叉验证 |
| 混淆验证与生成 | "AI 生成了一段看起来像验证报告的内容" | 严格区分：验证是从已有数据比对，生成是创造新内容 |
| 忽视审计需求 | "验证结果够用就行" | 提供完整审计日志，满足监管合规要求 |