benchmark-due-diligence

基准案例尽职调查

选取一个用户羡慕的基准案例——某位创始人、KOL、公司或产品，其成功看起来光鲜得可疑——并拆解分析，最终落脚于**“这对我意味着什么”**，而不是写一份中立报告。这份交付成果要回答三件事，而均衡的简报从来不会回答：这份成功有多少是真实的，又有多少是营销泡沫？其中有多少是可复制的方法，又有多少是运气或时机？具体来说，委托方能从中采取什么行动？

这是 deep-research 的对抗式、面向决策的近亲。deep-research 致力于构建可信的世界图景，而这项技能则假定图景经过夸大，除非有证据证明并非如此，并将经得起审视的部分转化为委托方自己的行动。

重要：以内联方式运行，绝不使用 context: fork

这项技能是一个编排器——它会启动并行的资料收集与核查 Agent（通过 Workflow 工具或 Task Agent），也可能调用其他技能（deep-research、osint-investigate、qcc）。子 Agent 无法再启动子 Agent，也无法调用技能。设置 context: fork 会悄无声息地破坏整个扇出流程。不要添加 context 字段。（osint-investigate 文档中也说明了同一限制——这是硬性运行规则，并非偏好。）

保护委托方的唯一规则：两条注入通道

Agent 接触到的所有内容都必须通过且仅通过两条通道传递。将两者分开，是这项技能中最重要的纪律：

通道	内容	注入对象
FACTS	已核实的有关基准案例的公开事实（关系、所有权归属，以及标记为 ⚠️ to-verify 的关键声明）	所有 Agent——资料收集、核查、综合分析
COMMISSIONER_CONTEXT	委托方的私人实际情况——真实资源、客户名称、战略意图，以及他们实际可以利用的条件	仅限最终映射 Agent（第 4 阶段）

**为什么这一区分不可妥协：**资料收集和核查 Agent 会使用输入内容执行外部 WebSearch。如果委托方的客户名称或策略泄露到这些提示词中，就会被拿到公开网络上搜索——这会造成隐私泄露。映射阶段确实需要知道“委托方是谁”；资料收集阶段则绝不能看到这些信息。应将此要求写入编排流程（参见 references/workflow_orchestration_template.md），不要指望在运行过程中靠记忆来遵守。

阶段 0 — 以证据而非表象夯实基础（在启动任何 Agent 之前完成）

浪费 12 个 Agent 并行执行的最快方式，就是把它们建立在你凭表象推断出的基础之上。反复出现的两种失败模式都曾让实际运行功亏一篑：

1. 根据名称／域名推断实体之间的关系。“他们的内容在 academy.example.com 上，而且他们是创始人，所以他们肯定拥有那个社群”——但实际上，他们只是受邀嘉宾。域名相同、名称相似或同时出现都只是观察结果，并不能证明所有权。把任何 A↔B 关系当作事实之前，都要先用权威来源核实。
2. **把委托方的客户当成委托方的资产。**如果委托方为某个加速器／品牌提供服务，那么这个加速器就是客户的资产——委托方无法利用它的受众或资金。把基准对象的策略照搬到委托方实际无法掌控的资源上，只会构筑空中楼阁。

因此，在启动并行任务之前，先用证据（而非感觉）确认：

• 基准对象真实的实体关系图谱——谁拥有谁，谁只是合作伙伴／嘉宾。不要根据名称推断。
• 核心宣传数据的归属——基准对象的整体叙事通常都建立在一个亮眼数据上（“让产品 X 的用户数从 0 增至 100 万”）。他们是创始人，还是已离职的增长负责人？这是首要核实目标；将其写入 FACTS，并标上 ⚠️。
• 委托方真正掌控的资源——区分自有资产与客户／合作伙伴的资产。

将结果写入 FACTS（公开部分）和 COMMISSIONER_CONTEXT（私密部分）。基础不牢，下游 Agent 就会个个信心满满地犯错。

四阶段编排

使用 Workflow 工具（首选——确定性扇出，参见 references/workflow_orchestration_template.md 中可直接填写的模板）或 Task Agent。根据用户对详尽程度的要求调整 Agent 数量（快速阅读时分析几个维度，深入审查时使用 6 个以上，并进行多轮投票验证）。

阶段 1 + 2——按维度进行收集 → 验证，作为流水线执行（每个维度的收集一完成，就立即开始验证；不设置全局屏障）：

• 收集 Agent——保持客观立场。每条发现都必须附带来源 URL 和 source_kind（对象自述/营销 与 第三方独立信源 与 混合）。任何未找到的信息都记录在 gaps 中——绝不靠猜测填补。
• 验证 Agent——采取对抗性、默认持怀疑态度的立场。为每条主张评定 L1–L4 级别，并给出判定：坐实 / 大体可信 / 存疑 / 证伪-水分。任务是主动搜寻证伪证据，尤其是醒目主张（标志性数据、“#1 排名”、融资金额、用户数量）。bubble_summary 要指出该维度中最严重的水分。

评级标准、source_kind、判定结果和两种 JSON 架构 → references/evidence_grading_rubric.md。

典型维度（根据基准对象类型——个人 / 公司 / 产品——进行调整）：

1. 对象背景 + 醒目主张的归属（水分审查的首要目标）
2. 企业基础信息——实体、成立时间、融资 / 估值
3. 核心产品 / 业务的真实指标——用户数量、营收、排名、奖项，并与第三方来源交叉核实
4. 运营策略拆解——平台矩阵、用户画像、内容类型、如何借用他人受众，以及个人 IP 如何为产品导流
5. 对比样本——结构相似的同行或平行路径
6. 行业背景 + 这一类运营策略通常如何取胜和如何失败

阶段 3——综合分析：尽职调查结论（单个 Agent，使用所有判定结果）：

1. 真实关系图谱（纠正阶段 0 中常见的误读）
2. 水分揭穿表——主张 | 证据级别 | 判定 | 一句话依据，按水分从多到少排序
3. 运营策略拆解——具体、可复制的做法
4. 归因拆分（核心）——成功中产品、市场时机、个人 IP 营销和运营各占多少？给出百分比范围及理由，并明确区分可复制的方法与运气 / 时机 / 不可迁移的先天优势。

阶段 4——综合分析：对委托方意味着什么（单个 Agent；使用阶段 3 的结果 + COMMISSIONER_CONTEXT）：

1. 资源映射表——基准对象的运营策略要素 × 委托方的实际资源；为每个单元格标记 ✅ 可借鉴 / ⚠️ 不可复制（运气 / 时机）/ 🔄 已在做 / 🚫 水分，勿照搬，并用一句话说明
2. 落地切入点——委托方具体如何运用（其 to-B 服务 / 自有 IP / 工具）
3. 行动清单 + 未决问题（仍未确认的事项）

归因权重及四标签映射框架 → references/attribution_and_resource_mapping.md。

不要重复构建已有内容

这项技能的优势在于对抗性水分揭穿 + 归因 + 委托方映射这几层。底层管道并不新颖——应重复利用：

• 扇出式收集 / 来源治理——借鉴 deep-research 的主 Agent + 子 Agent 模式。（此处的独特之处在于怀疑式验证立场和 L1–L4 水分评级，而非并行处理。）
• 个人对象身份 / 足迹核查——调用 osint-investigate（ACH 假设矩阵、Bellingcat 式线索转向），而不是重新推导身份归属。
• 中国大陆企业登记 / 融资信息——调用 qcc 技能系列查询工商数据。
• 社交平台运营策略数据——agent-reach CLI 覆盖 B站 / 小红书 / 抖音 / YouTube / X。

运行前必读

• references/evidence_discipline_traps.md — 常见陷阱（仅凭表象推断关系、归因标题中的说法、混淆客户端与资产、先打好基础再展开调查、分级而非二元判断、隐私泄露），并附有真实的复盘案例。请先阅读；实际运行中出问题往往就出在这里。
• references/evidence_grading_rubric.md — L1–L4、source_kind、结论，以及收集和验证的 schema。
• references/attribution_and_resource_mapping.md — 归因权重 + 四标签映射 + 落点框架。
• references/workflow_orchestration_template.md — 可直接填写的 Workflow 脚本，已接入 FACTS / COMMISSIONER_CONTEXT 注入拆分。

下一步

尽职调查结论准备就绪后，建议自然的后续步骤（可选，绝不自动运行）：

Due-diligence teardown is done.

Options:
A) Render it as a shareable PDF report — pdf-creator (Recommended if this goes to a partner/team)
B) One dimension needs deeper neutral background — deep-research on that sub-topic
C) No thanks — the markdown teardown is enough