用途
该技能由产品遥测工程师角色使用，目标是为“给产品添加分析埋点”撰写一份简短、有说服力的商业论证文档，让决策者能在5分钟内读完并给出肯定答复。
核心框架：商业论证不是关于“添加追踪”，而是关于解锁团队已经在付费使用的分析工具。多数 B2B SaaS 团队付费购买了分析平台，却因为输入的数据不正确而无法从中获得答案。埋点修复的是输入，从而让分析投资产生回报。
该技能位于主遥测生命周期之外，是位于一切之前的“说服”步骤：
business-case → model → audit → design → guide → implement ← feature updates
主要能力
- 产出 .telemetry/business-case.md，一份面向利益相关者的文档，展示团队当前看不到的内容、正确埋点能为已付费分析工具解锁什么，以及借助 AI 辅助工具所需的工作量之小。
- 识别盲点：以分析工具因数据缺失而无法回答的问题形式呈现，按产品类型（B2B SaaS、B2C/消费级、通用）定制。
- 框定正确埋点能解锁的能力，定位为“解锁团队已投入的分析投资”，而非新的技术项目。
- 描述所需工作：审计现状、设计理想追踪方案、实施三步，强调 AI 辅助处理最难部分，人工只需审查和调整。
- 预判并回应常见反对意见。
- 给出低承诺的下一步建议。
使用方式
前置条件：无。该技能可独立运行，通常是第一个运行的技能，先于任何技术遥测工作。
可选上下文：如果 .telemetry/product.md 存在，读取它以让论证具体且贴合产品；如果不存在，通过对话收集足够上下文。
流程：
-
理解产品。若存在 .telemetry/product.md，读取并提取产品类别、主要价值动作、用户类型、实体模型、技术栈，并呈现发现。若不存在，询问2-3个问题，例如“你的产品用一句话说做什么？”“这份商业论证是给谁的？”（工程负责人、创始人、PM、董事会）“你们今天有任何分析吗，还是从零开始？”
-
识别盲点。这是最有说服力的部分，以分析工具因数据不在而无法回答的问题形式呈现。按产品类型定制：
B2B SaaS：哪些账户有流失风险？（无参与度数据）；哪些功能驱动升级？（使用与扩展无关联）；新账户是否达到价值，还是在引导阶段停滞？（无激活追踪）；哪些账户会受益于外联？（无参与度评分）。
B2C/消费级：用户在关键流程中在哪里流失？（无漏斗数据）；哪些功能实际被使用，哪些建了却被忽略？（无采用数据）；什么驱动留存而非一次性使用？（无队列分析）。
任何产品：新用户达到核心价值动作需要多长时间？哪些集成/功能与留存相关？你是在构建用户真正想要的功能，还是在猜测？当使用限制被触及时，用户是升级还是离开？
不要全部列出——挑选对该产品最有冲击力的4-6个。
- 框定正确埋点能解锁什么。定位为解锁团队已投入的分析投资，而非新的技术项目。分析工具本身没问题，输入的数据才是问题。一旦正确的数据流动起来，工具终于能交付：分析工具可以浮现高风险账户（CS 能在账户流失前行动，而非之后，因为参与度信号终于流动）；分析工具可以显示扩展机会（看到哪些账户触及限制或使用高级功能——驱动收入的数据）；引导可见性变得真实（价值实现时间、激活里程碑、流失点——分析工具需要的数据来显示用户在哪里停滞）；功能采用可见（分析工具终于能回答“哪些功能被谁使用？”——让路线图决策基于数据而非直觉）；账户级细分生效（按实际行为分组账户——因为驱动细分的使用数据准确）。
选择与产品和受众最相关的3-4个。创始人关心收入保护，PM 关心功能采用，CS 负责人关心账户健康可见性，工程负责人关心范围和维护负担。
给利益相关者的关键信息：这不是购买另一个工具，而是让你已经付费的工具真正发挥作用。
- 描述涉及什么。关键信息：这不是一个大项目。AI 辅助工具处理最难的部分——审计现有内容、设计应存在的内容、生成实现代码。人工工作是审查和微调，而非从零构建。三步：审计已有内容（AI 扫描代码库，产出当前追踪的完整清单——哪些已埋点、哪些缺失、哪些配置错误，耗时几分钟而非几天）；设计理想追踪方案（传统上最难的部分——决定追踪什么、包含哪些属性、如何命名、如何为下游分析组织数据。AI 通过将最佳实践模式应用于产品特定领域处理约80%，团队审查和调整——是一次对话，不是一个项目）；实施（追踪代码遵循成熟模式——要么基于系统中已有内容，要么采用推荐实践。AI 生成实现代码（类型化事件定义、SDK 封装、投递基础设施），团队审查、集成和测试）。
它不是什么：不是重写——追踪调用是对现有代码路径的轻量添加；不是数据仓库项目——分析平台处理存储和可视化；不是手动规范练习——AI 辅助设计消除空白页问题。
阅读 references/effort-guide.md 获取工作量估算。
- 回应常见反对意见。预判并先发制人：
“我们已经有分析工具”——正是如此，它们没有交付价值，因为输入的数据不完整或不一致。这修复输入，让你在 Amplitude/Mixpanel/PostHog 的投资真正产生回报。
“我们以后再加”——以后永远不会来。而且追溯性埋点无法恢复历史数据。每一周没有正确数据流动，就是一周你永远看不到的用户行为——也是你的分析工具闲置的一周。
“我们可以直接查数据库”——数据库查询显示状态，而非行为。你无法从数据库表重建用户旅程、测量价值实现时间或看到功能采用模式。分析工具可以——但前提是正确数据在流入。
“工作量太大”——AI 辅助工具处理审计、方案设计和代码生成。人工工作是审查和微调——几天，而非几周。持续成本是每个功能几分钟。
“我们还没有足够用户”——这正是开始的时候。早期数据塑造产品决策。等到你有规模时，你会希望从第一天就有基线数据。
“隐私顾虑”——现代分析可以完全匿名。无需 PII——用户 ID 和行为事件对大多数分析已足够。
挑选该受众最可能的2-3个反对意见，不要全部包含。
-
推荐下一步。以清晰、低承诺的下一步结束：审计现有内容（AI 扫描代码库，几分钟内产出当前追踪清单）；设计追踪方案（AI 为产品生成最佳实践方案，团队审查和调整）；实施（AI 遵循代码库约定生成追踪代码，团队集成和测试）。框定为低工作量且增量式。第一步只需几分钟并产生即时价值（了解你今天拥有什么）。
-
撰写文档。写入 .telemetry/business-case.md。文档应：不超过2页（更长就不会被读）；针对该产品具体（不要泛泛的“分析很好”论证，使用产品的实际功能、用户类型和商业模式）；结构化便于浏览（标题、要点、一两个表格，决策者会略读）；对工作量现实（AI 让这很快——可信地说出来，带具体细节）。
输出结构：
Product Telemetry: Business Case for [Product Name]
The Problem: What Our Analytics Can't Tell Us
[4-6个分析工具无法回答的具体问题——因为输入的数据错误或缺失]
What Proper Instrumentation Unlocks
[3-4个一旦正确数据流动分析工具终于能做的事。框定为“Analytics can surface X”而非“We can see X”。]
What's Involved
[三步：审计、设计、实施。AI 处理繁重工作。人工工作是审查和集成。不是新工具——修复喂给已有工具的数据。]
Getting Started
[低承诺的第一步——审计只需几分钟，显示今天实际流向分析的内容 vs 应该有的内容]
保持紧凑。商业论证是开启对话的一页纸，不是全面的项目计划。
行为规则
- 解锁，而非交付。技能修复输入的数据——不替代分析工具。将结果框定为“你的分析终于能浮现 X”而非“你将能看到 X”。我们启用他们已付费的工具。
- 具体，而非泛泛。每个论证都应引用该产品的实际功能、用户或商业模式。“你的分析无法显示哪些账户在流失，因为没有参与度数据流动”胜过“分析提供可见性”。
- 商业语言，而非技术。受众是决策者。说“保护收入”而非“降低流失率”。说“你的分析工具终于能显示哪些功能驱动升级”而非“将功能采用与扩展 MRR 关联”。
- 对工作量现实。AI 工具确实让这很快——说出来。但要具体：“设计80%自动化，你审查和调整”是可信的。“这很简单”不是。
- 简短。文档必须不超过2页。如果你无法在2页内说明，论证就不够清晰。
- 写入文件，在对话中总结。将商业论证写入 .telemetry/business-case.md。在聊天中显示3-4行摘要。不要粘贴整个文档。
- 呈现决策，而非 deliberations。用户应看到完成的商业论证，而非撰写过程。
生命周期
business-case → model → audit → design → guide → implement ← feature updates
下一阶段：商业论证获批后，建议 product-tracking-model-product——构建结构化产品模型作为追踪设计的基础（例如“model this product”“build product model”）。
适用场景
适用于需要向决策者（工程负责人、创始人、PM、董事会）论证为产品添加遥测与分析埋点价值的场景，尤其是团队已付费购买分析平台但数据输入不完整或不一致时。可作为遥测工作的第一步独立运行。
限制
资料未提供具体的收费、价格、平台支持范围或效果保证信息。该技能依赖 AI 辅助工具处理审计、设计和代码生成，实际效果取决于具体产品与代码库情况。文档要求不超过2页，且需针对具体产品定制。