| name | hv-analysis |
| description | 横纵分析法（Horizontal-Vertical Analysis）深度研究Skill。由数字生命卡兹克提出，融合了索绪尔的历时-共时分析、社会科学的纵向-横截面研究设计、商学院案例研究法与竞争战略分析的核心思想。
当用户想要系统性研究一个产品、公司、概念、技术或人物时使用。核心是双轴分析：纵轴追踪从诞生到当下的完整生命历程（以叙事故事呈现），横轴在当下时间截面上与竞品/同类进行系统性横向对比，最后交叉两条轴产出独到洞察。最终产出一份排版精美的HTML研究报告，并在交付时询问用户是否要部署到 hv-reports 仓库。
触发词包括但不限于：横纵分析、研究一下、帮我分析、深度研究、做个研究、调研一下、竞品分析、帮我看看这个东西怎么样、这个产品/公司/概念是怎么回事、帮我摸清楚、帮我搞懂、帮我做个deep research。
即使用户只是说"帮我了解一下XX"或"XX是什么来头"，只要上下文暗示需要系统性的深度研究（而非简单的概念解释），都应该触发。也适用于用户丢来一个产品名、公司名、技术名词说"帮我研究一下这个"的场景。
不要用于简单的名词解释（用户只是问"XX是什么"）、不要用于公众号写作（那个用khazix-writer）、不要用于纯标题摘要生成（用wechat-title）。
|
横纵分析法深度研究
方法论溯源
横纵分析法由数字生命卡兹克（Khazix）提出，融合了语言学中的历时-共时分析（Saussure）、社会科学中的纵向-横截面研究设计、商学院案例研究法、以及竞争战略分析的核心思想，形成了一套适用于产品/公司/概念/人物的通用研究框架。核心原则不变：纵向追时间深度，横向追同期广度，最终交汇出判断。
你正在执行一次横纵分析法深度研究。最终产出一份排版精美的HTML研究报告（单文件，CSS内联）。
前置准备
环境准备
- 确认输出格式：本Skill最终产出为单个自包含HTML文件，所有CSS样式内联在
<style>标签中，无需外部依赖。
- 写作风格：本Skill已内置完整的写作风格指南（见下文"写作风格"部分），无需额外加载其他skill。
- 本地输出目录：生成好的 HTML 报告，默认优先保存到
D:\调研
- 如果目录不存在，先创建
- 只有当用户明确指定了别的本地目录时，才覆盖这个默认值
- 最终回复里优先给出
D:\调研\<文件名>.html 这个本地路径
明确研究对象
拿到用户输入后，确认以下信息。如果用户已经给得足够明确（比如"帮我用横纵分析法研究Hermes Agent"），不需要追问，直接开始：
- 研究对象：具体的产品名/公司名/概念名/人名
- 类型：产品、公司、概念、人物、还是其他？
- 研究动机（可选）：为什么要研究它？最近发生了什么？
- 特别关注点（可选）：有没有特别想深入的方向？
第一步：联网信息收集
这个方法论的质量完全取决于信息的丰富度和准确性。必须联网搜索，不能仅靠已有知识。研究报告的价值在于深度和完整度，所以信息收集阶段宁可多搜，不要因为信息不够导致后面的分析浮于表面。
并行搜索策略
使用子Agent并行搜索来提高效率。建议的分工：
- 子Agent 1 — 纵向信息：研究对象的起源、创始人背景、发展历程、关键事件、版本迭代、融资、战略转向、危机
- 子Agent 2 — 横向信息：竞品识别、各竞品的特点和用户口碑、行业对比评测、市场份额
- 子Agent 3（复杂对象才需要）：补充信息，如创始人深度背景、行业环境变化、用户社区讨论（GitHub issues、Reddit、Twitter/X、知乎等）
子Agent联网工具使用指南（直接写入每个子Agent的prompt中）：
每个子Agent的prompt中必须包含以下联网指引：
你需要联网获取信息。使用以下工具：
- WebSearch：用于搜索发现信息来源，获取摘要和关键词结果
- WebFetch：当已知具体URL时，用于从页面定向提取内容
- 如果用户环境中安装了 web-access skill（检查路径
/mnt/.claude/skills/web-access/SKILL.md 是否存在），优先加载它并遵循其指引，它提供更强的浏览器CDP能力
- 搜索策略：先用WebSearch发现信息来源和线索，找到具体URL后用WebFetch深入提取
- 多次搜索、多个关键词组合，不要只搜一次就放弃
- 一手来源优于二手来源：官方博客 > 权威媒体原创报道 > 转载/聚合
- 学术类研究对象必查arxiv：如果研究对象涉及学术概念、算法、AI模型、技术范式等，必须通过arxiv API获取相关论文。调用方式：
curl -s "https://export.arxiv.org/api/query?search_query=all:关键词1+AND+all:关键词2&max_results=10"，或用WebFetch访问同一URL。返回XML格式，包含标题、作者、摘要、发布日期、PDF链接。可按需调整关键词组合和结果数量。找到关键论文后，用WebFetch读取论文页面（https://arxiv.org/abs/论文ID）获取更多细节。
prompt要描述目标（"获取""调研""了解"），不要用暗示具体手段的动词（"搜索""爬取"），让子Agent自主判断最佳获取方式。
信息来源优先级
一手来源优于二手来源，多个媒体引用同一个错误会造成循环印证假象：
| 信息类型 | 一手来源 |
|---|
| 产品更新/技术决策 | 官方博客、GitHub Release Notes、创始人推文 |
| 融资/商业数据 | 公司官方公告、SEC/工商文件 |
| 用户口碑 | GitHub Issues、Reddit讨论、Twitter/X、知乎帖子 |
| 行业分析 | 权威媒体原创报道（非转载） |
| 学术/技术原理 | arXiv论文（export.arxiv.org/api/query）、Google Scholar、学术会议论文集 |
信息充分性自检
搜索完成后检查：
- 纵向：能讲出一个完整的故事吗？有没有明显的信息断层？
- 横向：竞品列表完整吗？有没有遗漏主要玩家？每个竞品的信息够做对比吗？
- 来源：关键事实有可靠来源支撑吗？有没有只靠单一来源就下判断的？
信息不够就再补搜。不要凑合。
第二步：纵向分析（Diachronic / Longitudinal）
沿时间轴，完整还原研究对象从诞生到现在的发展全貌。这是报告的主体部分，篇幅应该最重。
内容要求
起源追溯：它诞生的背景是什么？基于什么技术/理念/需求而来？创始团队或核心推动者是谁？这些人之前做过什么，为什么是他们来做这件事？当时的行业环境是什么样的？有没有某个关键事件或灵感直接促成了它的诞生？
诞生节点：明确的首次发布/成立/提出时间，最初的形态和定位，跟现在有什么不同。
演进历程：从诞生到现在，按时间顺序梳理所有关键节点。包括但不限于：重大版本更新、融资事件、团队变动、战略转型、技术架构变化、用户规模里程碑、重大合作或收购、公关危机或争议事件。
决策逻辑：在每个关键节点上，尽可能还原决策背后的原因。为什么选了A而不是B？当时面对的约束条件是什么？哪些早期决策"锁定"了后来的发展方向、难以逆转？什么机制让它越走越深（网络效应、生态绑定、技术栈选择等）？
阶段划分：把整个历程自然分为几个阶段（萌芽期、快速增长期、转型期等），每个阶段有核心特征和核心矛盾。
篇幅
6000-15000字。历史越长、节点越多的对象靠近上限，新生事物靠近下限。核心原则是把故事讲完整、讲透，每个关键节点都值得展开，不要为了压缩而跳过重要细节。宁可写长写细，也不要蜻蜓点水。
第三步：关键时间轴（新增）
在纵向分析叙事结束后，插入一个交互式时间轴，将纵向分析中的关键事件可视化呈现。
时间轴内容
从纵向分析中提取所有关键事件，每个事件一个节点：
- 时间点：精确到年月（或年月日）
- 事件标题：简短概括（1行）
- 关键决策/影响：1-2句话，说明这个节点的核心决策或影响（可从纵向分析的"决策逻辑"部分提炼）
- 详情内容（点击展开）：该事件的详细背景、前因后果、相关数据等（从纵向分析正文中提炼，约100-200字）
交互设计
- 默认只显示：时间点 + 事件标题 + 关键决策/影响（1-2句话）
- 点击节点可展开详情，显示更完整的背景说明
- 再次点击可收起
- 时间轴用竖线连接，节点用圆点标记
与纵向分析的关系
时间轴不是替代纵向分析，而是补充呈现。纵向分析负责讲清楚"为什么"和"怎么回事"（叙事深度），时间轴负责让读者一眼看清"什么时候发生了什么"（时间清晰度）。两者内容对应，但功能不同。
第四步：横向分析（Synchronic / Cross-sectional）
以当前时间点为切面，将研究对象与同赛道的竞品/同类进行全面对比。
首先判断竞品情况
分三种场景处理：
场景A：无直接竞品。 如果研究对象是全新品类或独占性极强的领域，跳过逐一对比，改为分析：它为什么没有竞品？是品类太新、壁垒太高、还是市场太小？未来最可能从哪个方向冒出竞争者？有没有间接替代方案或上一代解决方式可以参照？
场景B：少量竞品（1-2个）。 逐一深入对比，每个竞品展开详细分析。
场景C：竞品充分（3个及以上）。 选取最具代表性的3-5个进行对比，其余简要提及。
对比维度
根据研究对象的类型动态选择对比维度，但至少覆盖以下方面：
核心差异对比：技术路线/核心方法论/底层逻辑、产品形态/商业模式/组织结构、目标用户/受众/适用场景、核心优势与明显短板、定价策略/资源投入/规模体量。
用户视角：每个竞品的真实用户口碑如何？社区评价、使用体验中被提及最多的优点和槽点分别是什么？用户实际的使用方式和官方定位有没有偏差？对比不要写成参数对照表的文字版，要讲清楚每个竞品「活成了什么样」，用户选它的真实理由是什么。
生态位分析：在整个赛道的版图中，研究对象占据什么位置？填补了什么空白，还是在跟谁正面竞争？当前格局是百花齐放、两强争霸、还是一家独大？
趋势判断：基于横向对比，研究对象在竞争格局中的走向是什么？机会和风险各是什么？
篇幅
3000-10000字。场景A控制在3000字左右，场景C每个主要竞品至少展开1500字以上的独立分析，不要一笔带过。
第五步：核心对比汇总表（新增）
在横向分析叙事结束后（或中间适当位置），插入一个结构化对比汇总表格，将横向分析的核心差异一目了然地呈现。
表格内容
根据研究对象类型动态选择对比维度，常见维度包括（不限于）：
- 技术路线 / 核心方法论
- 产品形态 / 商业模式
- 目标用户 / 适用场景
- 核心优势
- 明显短板
- 定价策略
- 生态锁定程度
- 学习曲线
- 生产可靠性
表格设计
- 行：对比维度（根据研究对象动态选择 5-8 个最相关的维度）
- 列：研究对象 + 各主要竞品
- 单元格内容：简短概括（1-2句话），避免堆砌参数
- 表格是"骨架"，横向分析正文是"血肉"——读者先看表格抓重点，再读正文理解细节
与横向分析的关系
汇总表格不是替代横向分析的叙事内容，而是提炼和汇总。横向分析负责讲清楚每个竞品"活成了什么样"（叙事深度），汇总表格负责让读者快速抓取"谁和谁差在哪"（对比清晰度）。
第六步：横纵交汇洞察
这是整篇报告的精华段。把纵向发展脉络和横向竞争格局结合起来，给出综合性的、新的判断。不要写成前面内容的缩写版。
需要回答的核心问题：
- 历史如何塑造了当下的竞争位置：纵向历程中的哪些决策和事件，决定了它今天在横向对比中的位置？
- 竞品的纵向对比：如果把主要竞品也放到时间线上看，它们的起源和演变路径有什么不同？这些不同如何导致了今天各自的特点？
- 优势的历史根源：今天的每个核心优势，能追溯到历史上的哪个节点或决策？
- 劣势的历史根源：今天的每个核心劣势，能追溯到哪个历史决策？当初的「好决策」有没有变成今天的包袱？
- 未来推演：基于纵向趋势和横向竞争格局，给出三个剧本——最可能的、最危险的、最乐观的，每个剧本要有逻辑支撑。
篇幅
1500-3000字。
写作风格
这不是一份冷冰冰的咨询报告，而是一篇让人能从头读到尾的深度研究。写作风格需要在「研究报告的严谨」和「卡兹克的可读性」之间找到平衡点。
从卡兹克文风中借鉴的核心元素
以下风格元素直接应用到报告写作中（详细定义请参考 khazix-writer skill）：
节奏感：句子时长时短，段落之间跳跃自然。不要每段都一样长，一句话自成一段制造重量感的技巧可以用。好的节奏像波动，每次围绕主线偏出去一点，再用一句「扣主线句」拉回来。
叙事驱动，不是罗列驱动：纵向部分要有故事弧线，有起承转合。比如一个产品为什么在某个时间点突然爆发，背后的铺垫是什么，转折是什么。不要写成"2023年1月发布了A，2023年3月发布了B"这种流水账。
知识是「聊着聊着顺手掏出来」的：在讲述过程中自然地带出背景知识，不要「下面我来给大家科普一下」。
敢下判断：鼓励给出观点和洞察，但每个观点必须有事实支撑。先摆事实，再给判断。是推测的明确标注。表达判断时用「我觉得」「我的判断是」这种承认主观性的姿态，而不是居高临下的定论。
层层剥开的修辞：不直接讲结论，用"现象→表面解释→更深的追问→核心洞察"的方式展开。让读者参与到思考过程中。
文化升维：在交汇洞察部分，连接到更大的文化/哲学/历史参照物。不是硬凑的升华，是「聊着聊着自然想到了」的感觉。
回环呼应：开头或纵向部分埋的细节和钩子，在交汇洞察或结尾callback回来。前后因果的闭合感，是让报告从「信息流」变成「作品」的关键。
不从卡兹克文风中借鉴的元素
以下元素适合公众号文章但不适合研究报告，需要克制：
- 过强的口语化：报告可以有聊天感，但不要满篇「这玩意」「不是哥们」「太牛逼了」。偶尔点缀可以，但密度要比公众号文章低很多。
- 去小标题化：公众号文章追求一口气顺下来不加小标题。研究报告不一样，1-3万字的内容如果没有清晰的结构和导航，读者会迷路。报告需要清晰的章节结构。
- 标点禁令可以放松：公众号文章禁用冒号和破折号。研究报告中可以正常使用，因为报告需要的是信息传达效率。但「」的使用习惯可以保留。
- 固定尾部：不要加公众号的三连/星标尾部。
绝对禁区（依然适用）
以下AI味标记无论什么文体都要避免：
- 套话："首先...其次...最后"、"综上所述"、"值得注意的是"、"不难发现"
- 空洞形容词："赋能"、"抓手"、"打造闭环"
- 教科书开头："在当今AI快速发展的时代"、"随着技术的不断进步"
- 高频踩雷词："说白了"、"意味着什么？"、"这意味着"、"本质上"、"换句话说"、"不可否认"
- 空泛工具名：不说"AI工具"、"某个模型"，要说具体名字
- 编造场景：如果某个信息搜不到，诚实标注「该信息暂缺」，绝不编造
用人话写
避免咨询公司式的套话和空洞概括。用具体的细节和例子代替概括性陈述。比如不要写「该公司在这一阶段实现了快速增长」，而要写「从2024年中期的1000万美元ARR到2025年底的10亿美元，增长曲线几乎是垂直的」。
第七步：生成HTML报告
报告写完后，生成一个自包含的HTML文件。
HTML 文件规范
- 单文件：所有CSS样式内联在
<style>标签中，所有JavaScript内联在<script>标签中，不依赖任何外部文件
- 响应式设计：适配桌面和移动端阅读
- 中文优化：字体栈需兼顾 Claude 风格标题与中文排版。标题优先使用
Copernicus，其次 Tiempos Headline；若本机没有授权字体，则回退到 Cormorant Garamond、EB Garamond。正文优先 Styrene B / StyreneB，否则回退 Inter 与中文系统字体
HTML 结构模板
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>[研究对象] - 横纵分析法深度研究报告</title>
<style>
</style>
</head>
<body>
<div class="layout">
<aside class="sidebar">
<nav class="toc">...</nav>
</aside>
<div class="content">
<header class="cover">
<h1>[研究对象名称]</h1>
<p class="subtitle">横纵分析法深度研究报告</p>
<p class="meta">研究时间：... | 所属领域：... | 研究对象类型：...</p>
</header>
<section id="definition">...</section>
<section id="longitudinal">...叙事段落...</section>
<section id="timeline">
<h2>关键时间轴</h2>
<div class="timeline">
<div class="timeline-node" onclick="toggleDetail(this)">
<div class="timeline-dot"></div>
<div class="timeline-content">
<span class="timeline-date">YYYY.MM</span>
<h3>事件标题</h3>
<p class="timeline-summary">关键决策/影响（1-2句话）</p>
<div class="timeline-detail">
<p>详细背景、前因后果...</p>
</div>
</div>
</div>
</div>
</section>
<section id="cross-sectional">...叙事段落...</section>
<section id="comparison-table">
<h2>核心对比汇总</h2>
<table class="comparison-table">
<thead>
<tr>
<th>对比维度</th>
<th>[研究对象]</th>
<th>竞品A</th>
<th>竞品B</th>
...
</tr>
</thead>
<tbody>...</tbody>
</table>
</section>
<section id="insights">...</section>
<section id="sources">...</section>
</div>
</div>
<script>
function toggleDetail(node) {
node.classList.toggle('expanded');
}
</script>
</body>
</html>
CSS 排版规范
- 桌面端布局：使用单左栏导航 + 单正文列布局。左侧是较窄的固定导航栏，右侧是居中的正文阅读列。推荐整体宽度 1100px-1300px
- 目录：桌面端仅保留左侧一个固定目录，始终可点击跳转；不要再生成右侧 TOC。移动端回落到正文顶部
- 封面区：封面不要单独横跨整页，应放在正文列顶部，并与正文共用同一居中宽度
- 导航层级关系：进入页面时，视觉最高优先级必须是封面，不是目录。目录不得抢在封面上方占据首屏主位。
- 优化后的目录形态：优先使用“正文左上角悬浮小按钮 + 点击展开下拉面板”的目录，而不是常驻左侧大栏。默认收起，只露轻量按钮；展开后可点击跳转，再次点击或点击外部区域可收起。
- 目录不占正文流：目录应悬浮在正文之上或贴附正文左上角，默认状态不占据文档流空间，不能把正文挤出大片留白，不能在封面与正文之间制造大面积空档。
- 正文完全居中：正文列必须始终保持视觉中心，不因目录展开/收起发生横向偏移；目录只是浮层，不应改变正文列宽、对齐方式或起始位置。
- 目录宽度控制：目录按钮与展开面板都要克制，避免出现厚重的“管理后台侧栏”观感。按钮只承载导航入口，展开面板宽度以够读目录为准，不要为了说明文字牺牲画面呼吸感。
- 移动端目录：移动端优先退化成角落悬浮按钮或正文顶部轻量按钮，不要保留占宽度的大栏目录。
- 配色：
- 主标题：#1a5276（深蓝）
- 副标题：#1e8449（绿色）
- 正文：#2c3e50（深灰）
- 时间轴线：#2e86c1（浅蓝）
- 表格表头：#1a5276 背景 + 白色文字
- 引用块：左侧3pt深蓝竖线 + 浅灰背景
- 标题字体：优先
Copernicus、其次 Tiempos Headline；若不可用，则自动回退 Cormorant Garamond、EB Garamond、Georgia, serif
- 正文字体：优先
Styrene B / StyreneB；若不可用，则回退 Inter, "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", "WenQuanYi Micro Hei", sans-serif
- 使用原则：标题与章节标题用 serif 字体，正文、导航、表格说明用 sans 字体。若用户不商用且本机已有正版授权字体，可直接使用正版；若没有，则必须自动回退到近似字体，不能卡死在单一商业字体上
- 正文：16px，行距1.8，两端对齐
- 时间轴：竖线2px，节点圆点16px，左右交替排列（桌面端），悬停效果
- 表格：全宽、斑马纹行、hover高亮、响应式横向滚动（移动端）
- 封面区：大标题36px，副标题20px，底部装饰分隔线，整体文本居中
文件命名和交付
HTML文件命名为 [研究对象名称]_横纵分析报告.html。
默认保存位置规则：
- 优先保存到
D:\调研
- 如果用户本轮明确指定了别的路径，才使用用户指定路径
- 若同时需要在当前工作目录保留一份中间文件，可以保留，但最终交付路径仍优先指向
D:\调研
第八步：交付后询问是否部署到 hv-reports
报告 HTML 生成完成后，最终回复中必须追加一段简短询问：
要不要部署到 hv-reports 仓库并发布成可访问网页？
规则
- 未经用户明确同意，不自动部署
- 用户同意后，再执行 GitHub 部署动作
- 默认目标仓库为公开仓库
hv-reports
- 仓库 GitHub 地址固定为：
https://github.com/lucianwhy/hv-reports
- 仓库 clone 地址固定为：
https://github.com/lucianwhy/hv-reports.git
- GitHub Pages 首页固定为：
https://lucianwhy.github.io/hv-reports/
- 默认托管方式为 GitHub Pages
- 默认路径形式为 单仓库 + 每篇报告一个子路径
部署约定
- 仓库根目录为站点首页，用于展示全部报告列表
- 单篇报告线上 URL 形式固定为：
https://lucianwhy.github.io/hv-reports/<slug>/
- 每篇报告发布到一个独立 slug 路径，例如：
brain-computer-interface/openai/tsmc/
- slug 应尽量简短、清晰、可读
- 若 slug 冲突，先询问用户或自动追加短后缀避免覆盖
部署执行步骤
用户明确同意部署后，按下面顺序执行，不要自由发挥：
- 找到本地仓库
hv-reports
- 优先使用本地工作副本；当前常见路径是
C:\Users\24858\Documents\Codex\2026-05-19\hv-reports
- 若路径变化，先通过搜索目录或
git remote -v 确认仓库身份，不要猜
- 检查仓库状态
- 先看
git status --short
- 若仓库中已有与本任务无关的未提交改动，不得覆盖或回滚
- 只允许新增本次报告目录、更新
reports.json，以及在本次任务明确要求时更新 skills/hv-analysis/SKILL.md / README.md
- 生成 slug
- 使用简短英文 slug
- 落地路径必须是
<repo>/<slug>/index.html
- 复制报告文件
- 将生成好的 HTML 报告复制到
hv-reports/<slug>/index.html
- 更新首页索引
- 修改
hv-reports/reports.json
- 新增一条记录，字段至少包括：
title、slug、date、summary
- 默认把新报告插在列表顶部
- 这一步不是可选项；GitHub Pages 首页必须同步更新
- 如本次任务涉及 skill 规则调整
- 同步更新仓库里的
skills/hv-analysis/SKILL.md
- 如果仓库说明文档也受影响，再更新
README.md
- 提交前复核范围
- 用
git diff -- <目标文件> 或等价方式确认只包含本次需要提交的文件
- Git 提交与推送
git add 仅添加本次目标文件- 写清晰 commit message
- 推送到
origin/main
- 返回结果时必须同时给出
- GitHub 仓库地址：
https://github.com/lucianwhy/hv-reports
- Pages 首页：
https://lucianwhy.github.io/hv-reports/
- 单篇报告地址：
https://lucianwhy.github.io/hv-reports/<slug>/
报告与仓库双向更新规则
- 如果只是发布新报告：更新
reports.json + 新增 <slug>/index.html
- 如果本地输出目录规则变化：同步更新本地 skill 与仓库版 skill
- 如果这次顺手修正了方法论或部署规范：除了发布报告，还要同步更新仓库内
skills/hv-analysis/SKILL.md
- 如果这些规范对仓库使用说明也有影响：再同步更新
README.md
- 原则是：本地正在用的 skill 和仓库公开版 skill 不能长期漂移
成功交付后的默认话术要求
当报告生成成功时，回复中除报告文件路径外，还应补一句：
要不要我顺手把这份报告部署到 hv-reports，生成一个可分享网页链接？
不同研究对象类型的适配
核心原则不变（纵向追时间深度，横向追同期广度），但侧重点不同：
研究产品时：纵轴重点关注版本迭代、技术路线演变、用户增长曲线、关键产品决策；横轴重点关注功能对比、性能对比、用户体验、定价。对比表格维度侧重：技术架构、功能特性、性能指标、定价模式、生态集成。
研究公司时：纵轴重点关注创始团队、融资历程、战略转向、组织变革、关键人事变动；横轴重点关注商业模式差异、市场份额、营收对比、组织架构差异。对比表格维度侧重：商业模式、市场定位、营收规模、核心团队、融资历程。
研究概念时（技术范式、商业模式、文化现象）：纵轴重点关注概念的起源（谁提出的、基于什么理论/需求）、如何流行起来、经历了哪些争论和演变；横轴重点关注与相近概念的区别、各自适用场景、不同阵营的论证。对比表格维度侧重：核心定义、理论基础、适用场景、优势局限、代表实践。
研究人物时：纵轴重点关注个人经历、职业轨迹、关键决策、成长曲线、公开言论变化；横轴重点关注与同领域其他人物的对比（做事方式、风格、成就、影响力、路线选择差异）。对比表格维度侧重：核心成就、方法论、影响力、风格特点、代表观点。
篇幅总览
| 部分 | 字数范围 | 说明 |
|---|
| 纵向分析 | 6,000 - 15,000字 | 报告主体，不要蜻蜓点水 |
| 横向分析 | 3,000 - 10,000字 | 视竞品数量调整 |
| 横纵交汇 | 1,500 - 3,000字 | 精华段，给出新判断 |
| 全文总计 | 10,000 - 30,000字 | 不要怕长，深度和完整度是价值所在 |
质检清单
交付前自检：
