Vendor Summit Report

Build an executive-oriented deep-dive report for a major data/AI vendor conference — Snowflake Summit, Databricks Data+AI Summit, Microsoft Build, Google Clo...

haiyangchen@haiyangchenbj

Install

openclaw skills install @haiyangchenbj/vendor-summit-report

vendor-summit-report

为数据/AI 厂商大会（Snowflake Summit、Databricks DAIS、Microsoft Build、Google Cloud Next、AWS re:Invent 等）生成面向行业内参/高管视角的深度专题报告。一次产出三个口径一致的版本：淡色 HTML + 完整 MD + 企微推送版。

When to use

触发条件（满足任一即用）：

用户要求为某个厂商大会做"深度专题报告""专题报告""summit report""大会报告"
用户明确说"等 X 大会过后用这个/这套做报告""按上次 Snowflake 那个结构做"
已有一份同类报告，需要为新大会复刻同样的结构和视觉风格

典型场景：Snowflake Summit 报告做完后，Databricks DAIS 结束 → 用同一套结构产出 DAIS 报告。

核心设计哲学（务必遵守，这是反复打磨出来的）

内参视角，不是研究报告：以事实为基础，有自己的洞察，但不做满篇解读。判断/洞察先行，产品是支撑。
洞察先行，产品支撑：章节顺序是「判断 → 观察 → 产品 → 案例 → 竞争 → 买方建议 → 行业 → 总结」。观察排在产品前面。
观察层与产品层严格分工（关键，否则会重复）：
- 观察层只讲「怎么看 / 意味着什么」——纯判断，不写产品参数/数字（HTML 里也不用 .num）
- 产品层只讲「是什么 / 数字」——客观事实
- 同一个数字（举例：Snowflake 报告里的准确率 24%→86%、账户数——你的报告里换成本次大会的数字）只能出现在产品层，观察层用"详见产品章节"指代
禁止元沟通语言：全文不出现"我们的 XX""本报告认为"等过程性/自指表述。
开头留存门：前两段必须先让读者知道大会或厂商交付了什么、缺了什么、为什么值得继续读；法人链条、合同、底层基础设施只保留能直接解释核心判断的 1–2 句，其余移入产品／边界章节。前三段仍在解释签约流程而没有给出命题，视为开头失焦，必须重写。
同行范式不能被边界清单吞掉：如果研究材料里出现可迁移的产品范式、架构选择或技术路线（如语义层进入治理目录、Agent 控制平面、上下文工程），必须形成独立的观察或产品条目。区域不可用清单、合规结构和预算竞争只能作为证据域，不能替代同行读者要带走的技术判断。
导航不抢首屏：不放独立的大 TOC 卡片；顶栏导航用 2 字短标签；Hero 紧凑；让"核心判断"成为打开页面的第一视觉焦点。
表格非必须不用：能用叙述/卡片替代就替代；确需表格时优先紧凑横条（fact-strip）或可折叠表。
淡色风格：浅底白卡蓝色强调，参见模板 CSS 变量。
结构可复用，内容不可复制（最重要的一条）：这个 skill 复用的是结构骨架 + 视觉风格 + 写作纪律。每场大会的具体内容——洞察、分析框架、行业延伸的切入角度——必须从本次大会实际发布的内容重新推导。模板里出现的任何特定分析框架（如 Snowflake 报告里的"多层治理生态""数据重力论"）都是上一份报告的产物，是示例不是填空模板。做新报告时：先看这场大会真正讲了什么、抛出了什么行业级命题，再顺着它做合理延伸。宁可延伸角度不同，也不要把旧框架硬塞进来凑格式。
阅读友好优先于文字密度：每节先给结论，再给证据。禁止 200 字以上的裸段落——一律拆成「判断句标题 + 导语 + 要点行」。这是 2026-09-11 版式重构确立的契约，详见下节。
对外中立：报告面向外部读者，不出现内部策划语境、内部人名、内部主张代号。厂商的公开词汇（如某厂商官方提出的架构名）可以使用，但必须有厂商公开视角支撑。

分析师机构标准（Gartner/Forrester 级，2026-07 从 FFA 报告六轮打磨沉淀，务必遵守）

这四条是"内参综述"升级为"analyst research note"的关键。缺任何一条，报告都会退回到"厂商 friendly coverage"的水平。

只陈述不发指令——报告正文禁止祈使句/说教句，不教读者怎么读。
- ❌"发布与规划必须分清""评估这套叙事需先分清""必须先厘清 X""应当注意 Y"
- ✅ 改陈述句："本届 3 项发布落在当下、Flink 3.0 落在未来路线，二者兑现进度不同"
- 同类要删的还有元信息/思考痕迹："需要厘清的第一个事实…""这是最容易被忽略/战略层级最高的表述""前述观察的事实支撑""印证：…"（"印证"是替读者下判断）。直接给结论+证据，让事实说话。
vendor 数据必须加 caveat——所有性能/规模数字（2-6x、67%、百万 QPS、账户数等）若来自厂商或其客户，必须标注 vendor-reported / customer-reported + "未经独立验证/基准测试"，并建议以自有负载 POC 验证。禁止裸引官方"显著优于竞品 X"（如"显著优于 Ray/Daft"）。核心判断区加一句"数据来源说明"，客户实证表列头标"（vendor/customer-reported）"并加"分析师注"。
必须有 So-What（分角色买方建议）——这是 analyst research 区别于会议综述的灵魂。独立章节"对买方的建议"，按角色给可执行判断：
- 数据平台负责人 / AI 平台负责人 / 采购 / 竞品厂商（含国内云厂商）
- 典型判断：未 GA 的产品不押生产关键路径先做 POC；MCP 等接口按跨平台通用标准选型避免单一厂商锁定；合同里要求 Keynote 性能数字可复现基准；竞品对标不经济时找对方尚未建壁垒的维度切入。
预测用置信度 + 年份措辞——忌"必然/一定/难撼/逻辑自洽/决定性收窄"等绝对词。改为带概率和时间窗的 Strategic Planning Assumption（SPA）："到 20XX 年底，X 场景的 Y 占比上升，置信度中等偏高"。结论区放一条明确的 SPA。

阅读版式契约（2026-09-11 确立，硬性）

报告的绝大部分价值取决于读者是否真的读进去。这一节把"版式"从审美问题变成可核查的契约。

三段式（每个条目必须满足）

判断句标题 + 导语 + 要点行。三者缺一即视为该条目未完成。

判断句标题（.card-h）：必须可独立读懂，是判断而不是名词短语。不加句号。
- ✅"被本地化的只有讲故事的人，不是数据的地基"
- ❌"产品全景""竞争格局""关于本体架构"
导语（.lead）：交代背景与事实基础，2-4 行，字重稍轻。
要点行（.pts li）：单条控制在 1-2 行，可扫读。并列要点用列表，不要写成连续段落。

组件清单

组件	类名	用途	判据
条目卡	`.card`（内含 `.card-num`）	观察、产品、买方条目的统一骨架	一条独立判断成条时用
判断句标题	`.card-h`	结论先行	只看标题能获得完整判断
导语	`.lead`	背景与事实	条目开头交代事实基础
要点行	`.pts > li`	并列事实/论据，方点标记	一屏内可扫读
数字强调	`.num`	tabular-nums 加粗	只出现在产品层与事实层
引述块	`.pull` / `.pull-lead`	承担判断的单句；`.pull-lead` 用于节首	该条目的结论句
独立判断行	`.judg`	不依附卡片的判断	段末结论
限定条	`.lim` + `.lim-t`	边界、风险、口径 caveat	有需要显式标注的限制
小字注	`.note`	数据来源、口径不可比声明	caveat 集中出现处
状态徽标	`.badges > .badge`（`.b-ga` / `.b-prev` / `.b-arch`）	GA / 预览 / 架构层	替代原来的括号前缀
流程条	`.flow > .flow-step` + `.flow-arrow`	步骤、阶梯、管线	有先后或递进关系
优劣势双列	`.swot` + `.swot-col.pro` / `.con`	优势与风险并列	把顿号长句拆成条目
分层栈	`.layer-stack > .layer`	层间存在包含或依赖关系	见下方判据
SPA 块	`.spa`	带年份与置信度的预测	总结区一条

组件判据（容易用错的两个）

.layer-stack 的使用边界：只有当层与层之间存在包含或依赖关系（上层依赖下层提供的能力）时才用。若各参与方是并列或竞争关系，改用 .cmp-table 或 .swot。跨厂商的生态分层若由分析者归纳而非厂商自述，必须在同段加一句说明视角来源。
.pull 与 .judg：.pull 依附于某个条目、是该条目的结论；.judg 用于板块级的独立判断，不归任何条目。二者不要连用堆在同一段。

反模式（出现即返工）

200 字以上的裸段落
.card-h 写成名词短语
同一板块内所有内容都上卡片，形成"卡片墙"；条目少于 3 条时用连续段落加要点行即可
观察层出现 .num 承载产品数字
要点行单条超过 2 行（说明该拆成两条，或应写进导语）

固定 8 段结构

#	章节	内容	视觉形式
01	核心判断	1 句核心命题 + 战略前提 + 4 个 takeaway + 关键数字 fact-strip + 数据来源说明（一句 vendor caveat）	verdict 卡 + takeaway 网格 + fact-strip + `.note`
02	具体观察	4-5 个纯洞察（怎么看/意味着什么），无产品参数，无祈使/说教句	`.card` × N：card-num「观察 01…N」+ `.card-h` 判断句 + `.lead` + `.pts`，结论句用 `.pull`
03	产品全景	5 个战略级产品叙述（数字在此，标 GA/Preview 状态）+ 其余产品可折叠表 + 产品栈分层	`.card`（`.badges` 状态徽标 + `.card-h` + `.lead` + `.pts` + `.lim`）+ details 折叠表 + `.layer-stack`
04	客户实证	4-5 个生产环境案例，列头/节首标"（vendor/customer-reported）" + 分析师注	`.customer-grid` + `.info-box` 分析师注（内含 `.pts`）
05	竞争格局	对比表 + 收敛判断 + 主场≠客场 + 优势风险。分析角度按本次大会实际竞争态势定	`.cmp-table` + `.comp-row`（优势风险用 `.swot` 双列）
06	对买方的建议（So-What）	分角色可执行建议：数据平台/AI平台/采购/竞品厂商	`.buyer-grid` × 4（`.brole` + `.bjudg` 判断句 + `.pts`）
07	行业延伸	本次大会引出的行业级命题（角度随会而变）+ 2-4 个待验证问题	`.pull-lead` + `.pts` + `.judg` + 视命题选 `.cmp-table` / `.layer-stack` + `.q-item`（qnum + qh + p）
08	总结	一页式收束 + 短期/中期/长期三层判断 + 一条 SPA（带年份+置信度）	`.summary-hero` + `.pts` + `.pull` + `.judgment` 网格 + `.spa`

⚠️ 05/07 段的分析框架是内容不是模板。Snowflake 报告用了"数据重力论""多层治理生态"——那是 Snowflake Summit 的实际命题所引出的。做别家大会时，丢掉这些具体框架，从本次大会真正抛出的行业命题重新提炼延伸角度（Databricks 可能是开放湖仓/Lakehouse 标准之争、微软可能是生产力 Agent 的组织渗透，等等）。 ⚠️ 05 段必须保留"主场≠客场"这一层：厂商在其主场市场的优势，外推到其他市场需要额外证据。缺这一层，竞争格局会变成把厂商自述的定位当结论。 ⚠️ 06 段"对买方的建议"是分析师标准的硬性要求（见上方分析师机构标准第 3 条），不可省略。角色和建议内容按本次大会实际情况定，但四类角色框架保持。

Steps

研究阶段：用 WebSearch / WebFetch 收集大会的：① 全部产品公告（逐条核实 GA/Preview 状态）② 财务背景（最近一期财报）③ 客户案例（带业务结果数字，记录数字来源=vendor 还是 customer）④ 竞争对手同期动作 ⑤ 分析师观点。逐条确认发布日期在窗口内，单一信源需交叉验证。大会材料优先现场稿而非会前预告稿（预告常把"下一代版本"模糊带过，现场才讲清"已发布 vs 规划路线"的分野——FFA 案例：预告用"Flink 3.0"，现场才明确 2.0=Cloud Native 已发布、3.0=Agent Native 规划）。
提炼核心判断：用一句话回答"这家厂商在赌什么"。提炼 4 个 takeaway。核心判断区加一句"数据来源说明"（会上性能/规模数字为 vendor/customer-reported，未经独立验证）。
写 5 个观察：每条一个洞察，纯判断，剥离所有产品参数。只陈述不发指令——不写"必须分清 X""需先厘清 Y"这类祈使/说教句，不写"需要厘清的第一个事实""印证：…"这类元信息/思考痕迹。每条同时给出判断句标题（可独立读懂，见阅读版式契约），再展开导语与要点行。
整理产品全景：挑 5 个战略级产品做叙述（含数字），逐条标 GA/Public Preview/Private Preview/规划状态，状态用 .badges 徽标而非括号前缀；其余进折叠表。产品栈分层若确实存在包含关系，用 .layer-stack。 4.3 写"对买方的建议"（So-What，必做）：分四类角色给可执行判断——数据平台负责人 / AI 平台负责人 / 采购 / 竞品厂商（含国内云厂商）。内容按本次大会实际情况定，但典型逻辑：未 GA 不押生产先 POC、接口按通用标准选型避免锁定、合同要求可复现基准、竞品找对方未建壁垒的维度切入。每角色先给一句判断（.bjudg），再给 2-4 条要点。 4.5 提炼行业延伸角度（不要套旧框架）：问自己——这场大会真正抛出了什么行业级命题？是标准之争、范式迁移、生态卡位、还是某个能力成为新门槛？顺着它做延伸。只有当本次大会内容确实指向"分层结构且层间存在依赖"这类命题时，才用 .layer-stack；参与方是并列竞争关系时改用 .cmp-table 或 .swot。 4.7 总结区放一条 SPA：带年份+置信度的 Strategic Planning Assumption，忌"必然/难撼/决定性"等绝对词。
生成三版：
- 复制 @templates/report-template.html 作为 HTML 基础，替换内容（保留 CSS、导航逻辑、reveal 脚本、全部阅读组件样式）
- 复制 @templates/report-template.md 作为完整 MD
- 复制 @templates/wecom-template.md 作为企微版基础
- 三口径同步铁律：MD 改完不等于口径统一。每轮修订收尾必须做一次跨文件关键串计数比对——<h1> 主副标题 / hero 副标题 / 抬头 / 关键事实表 / 表格口径 / caveat 句，逐项在三个文件里对同一字符串计数，数量不一致即漏改（2026-09-11 教训：HTML 的 <h1> 副标题漏同步一轮才发现）。 5.5 HTML 版式落地（三段式切分）：把已成稿的叙述按阅读版式契约切分——每段识别判断句→提升为 .card-h，事实背景→.lead，并列论据→.pts，结论句→.pull，caveat→.lim/.note。此步只做切分与强调，不改写文字。改版后必做两项核验：① 结构配平（section/div/article/ul/li/p/table/tr/td/strong/b/span/details/h3 逐一 open=close）；② 内容零丢失——改版前 dump 纯文本快照，改版后按字符级 diff，差异须逐条归入「引号规范 / 标点随分块调整 / 新增结构标签 / 已知修正」四类，出现第五类即回滚排查。
企微版规范：分隔符用中文冒号"："，禁止竖线"｜"；分节标记统一 ▍；结构=核心判断（含 vendor caveat）+五观察+产品全景+竞争+对买方的建议+待验证问题+总结（含 SPA）；结尾固定"完整报告见 HTML 附件。"；同样禁祈使句/绝对词。
- 字节预算按内容密度分层（硬上限 4,096 字节，用 len(text.encode('utf-8')) 实测，不要目测字符数）：
  - 单场发布会、单一产品线：≤ 2,500 字节
  - 常规大会、两条产品线或一个战略概念：≤ 3,500 字节
  - 信息密度极高（多产品线 + 多案例 + 买方分角色建议同时成立）：3,500–3,900 字节
- 超预算的删减顺序：先删「客户实证」，再删「待验证的问题」，不可删「对买方的建议」
- 分角色建议是字节黑洞，四个角色各留 40-60 字，超过就说明该内容应留在 HTML 里
机械复核（格式与红线）：检查观察层是否混入产品数字（去重）；检查是否有元沟通语言/祈使句/绝对词；检查 vendor 数字是否都有 caveat、买方建议章节是否存在、SPA 是否带置信度；检查 .card-h 是否都是判断句、有无残留裸段落；检查章节编号无 off-by-one（.sec-no 与注释编号一致）；HTML 用浏览器预览确认首屏是核心判断而非导航。grep 复核残留：必须分清|需先分清|印证：|必然|难撼|逻辑自洽|决定性。红线配额：破折号 —— 全篇 ≤ 5、对举句（"不是…而是""而非"）≤ 3。注意 .card 类文献里的破折号常紧邻 </strong>/</span>，MD 与 HTML 不能共用同一组替换锚点，必须分别 dump 命中后逐条判定。 7.5 reader-fit 阅读测试（推荐，机制取自 tech-content-review-panel §Step R）：机械复核保证的是"没有违规"，reader-fit 保证的是"读者真的读得懂"。适用于本类报告，审核文档与报告同目录落盘，命名 <报告名>_reader-fit审核.md。
- R0 定位锁：先写清文类（厂商大会深度专题）/ 主读者（企业侧数据与 AI 平台决策者）/ 阅读任务（判断是否以及何时评估该厂商）/ 中心命题 / 刻意排除的内容 / 深度层级。定位锁是后续分级判据，不能省。
- R1 选 3-4 个代表角色：本类报告不选投资人、媒体编辑、泛读者（与定位不兼容）。优先选：企业决策者（数据平台或 AI 平台负责人）、领域专家（同类技术负责人）、运行时与治理工程师、跨域行业读者。
- R2 统一五问：① 中心命题用一句话是什么？② 哪一段你最先跳过？③ 哪句断言你觉得证据不足？④ 哪个数字你不敢引用？⑤ 读完你会做什么（或什么都不做）？
- R3 按定位兼容性分级：must-fix（不改则读者采信错误，多数是定位类风险）/ suggested / optional / reject-park（与定位不兼容的意见，显式搁置并说明理由）。
- R4 冲突显式记录：多角色意见冲突时不要折中，写清冲突点与取舍依据。
- R5 限定修订范围：只改 must-fix + suggested，不重写全文。修订不得改写内容，只允许切分、强调、调序、补 caveat。
- 优先级顺序：factual correctness → positioning integrity → core comprehension → technical depth → elegance → distribution preference。
- 高频共识障碍（本类报告实测）：① 表格与标题层的断言强度强于正文与观察层口径，读者会采信更硬的那一侧——表格里的口径必须与正文同级；② 多口径并行时 caveat 只写在一份材料里，另外两份读者看不到；③ 竞争格局若只写厂商自述定位，读者会当成结论。
交付：deliver_attachments 交付三个文件（HTML 第一、MD 第二、企微第三）。如需推送，复用项目 push_*.py 脚本模式（WeComChannel + GitHubPagesChannel）：照抄一份现成 push_*.py（如 push_ffa_report.py），只改 md_path/html_path/GITHUB_REMOTE_PATH/commit 文案；企微走正式群前按"对外操作先确认"跟用户核对渠道与目标群；GitHub Pages 部署到 analyst-perspectives/<slug>.html 独立路径，不覆盖日报 index.html。Pages 上传成功不等于立即可访问，构建期间返回 404，需轮询（每次 10 秒，交叉验证一个已知可用路径先确认 Pages 本身正常）。

模板文件

@templates/report-template.html — 淡色 HTML 全量模板（CSS 变量、固定导航、fact-strip、verdict 卡、全套阅读组件、layer-stack、scroll reveal、nav active 脚本）。文件头有复用清单、必须替换项、版式契约、组件判据四段说明。
@templates/report-template.md — 完整 MD 模板（8 段结构参照）
@templates/wecom-template.md — 企微推送版模板（▍ 分节、中文冒号、字节预算分层，正文实测约 3.7K 字节）

这三个模板是 Snowflake Summit 2026 的成品。复用它们的：CSS/样式、阅读组件、章节骨架、导航逻辑、写作纪律、企微格式。替换掉它们的：所有厂商名、产品、数字、案例、洞察，以及 05/06/07 段的具体分析框架。样式和结构不要动，内容全部换新。

Pitfalls

硬套旧框架（最严重）：把 Snowflake 报告的"多层治理生态""数据重力论"原样搬进别家大会的报告，为了凑齐 07 段而生拉硬拽。这些是内容不是模板——必须从本次大会实际内容重新提炼延伸角度。宁可换个完全不同的行业命题，也不硬塞。
观察与产品重复：最常见的坑。观察写了"7100 账户/24→86%"，产品又写一遍 → 读者读两遍。务必让观察只讲判断，连 .num 都不用。
大段文字堆砌（2026-09-11 新增）：整段 200-300 字的连续叙述，读者扫读时抓不到要点。这是"报告看起来专业但没人读完"的主因。必须切成判断句标题 + 导语 + 要点行。
判断句标题写成名词短语：.card-h 写"产品全景""本体架构"等于浪费了最容易读到的一行。要写成可独立读懂的判断。
章节编号 off-by-one：HTML 模板历史上出现过注释写 07、.sec-no 显示 06 的问题。改版后逐个 section 核对注释编号与 .sec-no 一致。
三口径只改一份：MD 改完就以为统一了，HTML 的 <h1> 副标题、hero 副标题、表格口径还留着旧版。收尾必须做跨文件关键串计数比对。
table 口径比正文硬：表格里写"已整合"，正文写"收购刚完成"，读者信表格。表格与正文的断言强度必须同级。
导航占首屏：不要加独立 TOC 大卡片；Hero 不要太高。
企微版超 4096 字节：必须实测 len(text.encode('utf-8'))，超了按分层的删减顺序处理，别目测、别先删买方建议。
企微版用了竖线：必须用中文冒号"："。
产品状态写错：GA/Public Preview/Private Preview/Alpha 必须逐条核实，别想当然。
元沟通语言混入："我们的报告""本文认为"等一律删除。
祈使/说教句混入（分析师标准硬伤）："X 必须分清""需先厘清 Y""应当注意 Z"——在教读者怎么读，删掉改陈述句。"印证：…"是替读者下判断，也删。
vendor 数字裸引（credibility 归零）：2-6x/67%/百万 QPS 等直接当客观事实写、或裸引官方"显著优于竞品"，没有 vendor/customer-reported + 未独立验证 caveat。Gartner/Forrester 会直接判整篇不可信。
缺买方建议（退回会议综述）：只描述格局不给"买方该干嘛"。So-What 分角色建议是 analyst research 的灵魂，不可省。
预测用绝对词："必然/一定/难撼/逻辑自洽/决定性收窄"——降调为带置信度+年份的 SPA。
竞争格局缺"主场≠客场"：把厂商在主场市场的优势直接当成其在别的市场也成立，读者会当成结论采信。
路径打错：项目目录是 data-ai-daily-brief（注意不是 daili）。
竞争格局与观察雷同：如果观察里讲了"数据重力/模型商品化"，竞争格局的同主题要换角度（如讲"三家数据形态分歧"），避免重复。
把「判断句标题」执行成名词并列：两个抽象名词并列、字数合格、语气像结论，不代表读者能读出对象—关系—方向。标题单独抽出时必须回答「谁与谁发生什么关系，哪一侧受限，结果是什么」；如「被动适配与主动多云」应继续压成「接入既有云，不能自建区域」。
证据先于命题的开头：先讲签约主体、底层云和法律流程，三段后读者仍不知道厂商交付了什么、缺了什么。前两段先给反常事实、客户价值与核心判断，法人结构只留能解释判断的最少信息。
边界清单吞掉产品范式：不可用功能清单与合规结构很容易写得扎实，却把语义层进入治理目录、Agent 控制平面、上下文工程等同行可迁移路线压成背景句。范式必须独立成条，数字再放产品事实层。
用 .layer-stack 呈现并列关系：层与层之间不是包含/依赖关系时，分层栈会误导读者以为存在架构承继。并列或竞争关系用 .cmp-table / .swot。