| name | horizontal-vertical-analysis |
| description | 横纵分析法（Horizontal-Vertical Analysis）深度研究方法论。
融合了索绪尔的历时-共时分析（diachronic-synchronic）、社会科学的纵向-横截面研究设计、商学院案例研究法与竞争战略分析的核心思想。
适用于对产品/工具/公司/技术/人物进行系统性深度研究。
核心是双轴分析：纵轴追踪从诞生到当下的完整生命历程（以叙事故事呈现），横轴在当下时间截面上与竞品/同类进行系统性横向对比，最后交叉两条轴产出独到洞察。
研究完成后配合 obsidian-research-precipitation skill 将报告沉淀到 Obsidian 知识库。
触发关键词：深度研究、深入研究、横纵分析、对比分析、竞品分析、横向对比、纵向分析、发展历程、来龙去脉、深度对比、系统研究、全面分析、vs、对比、区别、研究一下、深入分析、是怎么发展起来的、review、compare、深度调研、系统梳理、全景分析
|
横纵分析法
方法论溯源
横纵分析法融合了语言学中的历时-共时分析（Saussure）、社会科学中的纵向-横截面研究设计、商学院案例研究法、以及竞争战略分析的核心思想，形成了一套适用于产品/公司/概念/人物的通用研究框架。核心原则不变：纵向追时间深度，横向追同期广度，最终交汇出判断。
适用范围
- 产品/工具（如 Hermes Agent、Cursor、Claude Code）
- 公司/组织（如 Anthropic、OpenAI）
- 技术概念（如 MCP协议、RAG、Agent框架）
- 人物（如行业关键人物）
零、前置准备
明确研究对象
拿到研究任务后，确认以下信息：
- 研究对象：具体的产品名/公司名/概念名/人名
- 类型：产品、公司、概念、人物、还是其他？
- 研究动机（可选）：为什么要研究它？最近发生了什么？
- 特别关注点（可选）：有没有特别想深入的方向？
如果信息已经足够明确，直接开始，不需要追问。
不同研究对象的侧重点
核心框架不变，但侧重点不同：
| 类型 | 纵轴侧重 | 横轴侧重 |
|---|
| 产品 | 版本迭代、技术路线演变、用户增长、关键产品决策 | 功能对比、性能对比、用户体验、定价 |
| 公司 | 创始团队、融资历程、战略转向、组织变革、关键人事变动 | 商业模式差异、市场份额、营收对比、组织架构差异 |
| 概念 | 起源（谁提出、基于什么理论/需求）、如何流行、争论和演变 | 与相近概念的区别、适用场景、不同阵营的论证 |
| 人物 | 个人经历、职业轨迹、关键决策、成长曲线、公开言论变化 | 与同领域其他人物的对比（风格、成就、影响力、路线选择） |
一、联网信息收集
横纵分析法的研究质量完全取决于信息的丰富度和准确性。必须联网搜索，不能仅靠已有知识。信息收集阶段宁可多搜，不要因为信息不够导致后面的分析浮于表面。
并行搜索策略
使用 delegate_task 并行搜索来提高效率。建议分工：
- 子Agent 1 — 纵向信息：起源、创始人背景、发展历程、关键事件、版本迭代、融资、战略转向、危机
- 子Agent 2 — 横向信息：竞品识别、各竞品特点和用户口碑、行业对比评测、市场份额
- 子Agent 3（复杂对象才需要）：补充信息，如创始人深度背景、行业环境变化、用户社区讨论
子Agent联网工具使用指南（直接写入每个子Agent的prompt中）：
你需要联网获取信息。使用以下工具：
- browser_navigate + browser_snapshot：访问具体网页，获取详细内容
- terminal：执行搜索命令（推荐使用 codex CLI 进行网页采集）
- web-collection skill：如果已安装，优先加载它获取结构化网页内容
搜索策略：
- 多次搜索、多个关键词组合，不要只搜一次就放弃
- 一手来源优于二手来源：官方博客 > 权威媒体原创报道 > 转载/聚合
- 找到具体URL后用 browser 工具深入提取页面内容
- GitHub项目搜索可用 terminal 执行 gh search repos 或直接浏览 GitHub
学术类研究对象必查arxiv：
curl -s "https://export.arxiv.org/api/query?search_query=all:关键词&max_results=10"
信息来源优先级
| 信息类型 | 一手来源 |
|---|
| 产品更新/技术决策 | 官方博客、GitHub Release Notes、创始人推文/帖文 |
| 融资/商业数据 | 公司官方公告、SEC/工商文件 |
| 用户口碑 | GitHub Issues、Reddit讨论、Twitter/X、知乎、V2EX |
| 行业分析 | 权威媒体原创报道（非转载） |
| 学术/技术原理 | arXiv论文、Google Scholar、学术会议论文集 |
⚠️ 警惕循环印证：多个媒体引用同一个错误会造成"看起来有多个来源"的假象。尽量追溯到原始出处。
信息充分性自检
搜索完成后检查：
- 纵向：能讲出一个完整的故事吗？有没有明显的信息断层？
- 横向：竞品列表完整吗？有没有遗漏主要玩家？每个竞品的信息够做对比吗？
- 来源：关键事实有可靠来源支撑吗？有没有只靠单一来源就下判断的？
信息不够就再补搜。不要凑合。
二、纵向分析（Diachronic / Longitudinal）
沿时间轴，完整还原研究对象从诞生到现在的发展全貌。这是报告的主体部分，篇幅应该最重。
内容要求
起源追溯：诞生的背景是什么？基于什么技术/理念/需求而来？创始团队或核心推动者是谁？这些人之前做过什么，为什么是他们来做这件事？当时的行业环境是什么样的？有没有某个关键事件或灵感直接促成了它的诞生？
诞生节点：明确的首次发布/成立/提出时间，最初的形态和定位，跟现在有什么不同。
演进历程：从诞生到现在，按时间顺序梳理所有关键节点。包括但不限于：
- 重大版本更新
- 融资事件
- 团队变动
- 战略转型
- 技术架构变化
- 用户规模里程碑
- 重大合作或收购
- 公关危机或争议事件
决策逻辑：在每个关键节点上，尽可能还原决策背后的原因。
- 为什么选了A而不是B？
- 当时面对的约束条件是什么？
- 哪些早期决策「锁定」了后来的发展方向、难以逆转？
- 什么机制让它越走越深（网络效应、生态绑定、技术栈选择等）？
阶段划分：把整个历程自然分为几个阶段（萌芽期、快速增长期、转型期等），每个阶段有核心特征和核心矛盾。
叙事要求
- 不要写成干巴巴的年表
- 用故事的方式把发展史串起来
- 让读者能感受到因果关系和时代脉络
- 越详细、越多元越好，把相关的人物、事件、背景信息都拽进来
- 纵向部分要有故事弧线，有起承转合
- 知识是「聊着聊着顺手掏出来」的，不要「下面我来给大家科普一下」
篇幅
6,000-15,000字。历史越长、节点越多的对象靠近上限，新生事物靠近下限。核心原则是把故事讲完整、讲透，每个关键节点都值得展开，不要为了压缩而跳过重要细节。宁可写长写细，也不要蜻蜓点水。
三、内容准确性校验（强制环节，不可跳过）
核心原则：没有经过校验的内容，不能写进报告。
这一环节在纵向分析完成之后、横向分析开始之前执行。校验不通过，不得进入横向分析。
信息采集阶段搜到的内容，可能包含：过时信息（某个功能已在最新版本中被修改/移除）、错误关联（把竞品的功能张冠李戴）、幻觉（模型自信地输出了不存在的细节）、过期数据（融资额、用户数等信息会变化）。
校验的目标不是"再搜一遍"，而是对已经写进报告的具体断言，逐一核对原始来源。
校验范围
以下类型的内容，必须经过官方来源核对：
| 类型 | 核对来源 | 示例 |
|---|
| 工具/产品功能特性 | 官方文档、Changelog、Release Notes | "Arc Search 的 Browse for Me 是默认搜索模式" |
| 版本特性 / 支持范围 | 官方 Changelog、GitHub Releases、文档版本标记 | "Gemini 3 在 Search 中支持实时生成交互工具" |
| 模型支持范围 | 官方模型列表页、API 文档 | "Claude 3.5 Sonnet 支持 200K context" |
| 已知限制 / Issues | GitHub Issues（open/closed）、官方 Known Issues 页 | "browser-use 的 extract 命令尚未实现" |
| 定价 / 套餐内容 | 官方 Pricing 页（截图或实时访问） | "Flipbook 终身版 $199" |
| 融资 / 公司数据 | 官方公告、Crunchbase、Tracxn（优先官方） | "Common Knowledge 处于 pre-seed 阶段" |
| 技术架构细节 | 官方技术博客、论文、GitHub README | "Flipbook 使用 Modal 作为 GPU 后端" |
校验流程
Step 1：提取待校验断言清单
在纵向分析写作完成后，从已写出的内容中提取所有具体断言（不带文献引用的陈述句），形成清单。例如：
[ ] 断言1：Arc Search 的 Browse for Me 是 iOS/Android 版本的默认搜索模式
[ ] 断言2：Flipbook 使用 LTX Studio 的视频模型，优化后支持 1080p/24fps
[ ] 断言3：Google AI Mode 于 2025年3月5日推出
Step 2：逐一核对原始来源
对每个断言，按以下优先级核对：
- 一手来源（最可信）：官方文档、Changelog、GitHub Release Notes、官方博客、创始人直接发言
- 可验证的二手来源：权威媒体原创报道（需确认不是转载/聚合）
- 社区来源（需交叉验证）：Reddit、Twitter/X、知乎——单一社区来源不足以支撑关键断言
具体操作（在主Agent中用 browser 工具执行）：
对关键断言，用 browser_navigate 访问官方文档/Changelog 页面，
用 browser_snapshot 获取页面内容，确认断言与官方描述一致。
对于 GitHub 项目，访问 Release 页面或 README 的 Features 章节。
对于模型支持范围，访问官方 API 文档的 Models 页面。
Step 3：处理校验结果
| 校验结果 | 处理方式 |
|---|
| 断言与官方来源一致 | 保留，在报告中标注来源 |
| 断言与官方来源不一致（过时/错误） | 删除或修正，并在报告中标注"截至YYYY-MM-DD的最新信息" |
| 断言无法找到官方来源确认 | 标注为「暂缺官方确认」或「社区反馈显示」，不得作为确定性结论 |
| 某个功能/特性在 GitHub Issues 中标记为已废弃/已修复 | 更新断言，反映最新状态 |
Step 4：特别关注 GitHub Issues
对于开源工具/框架，以下 Issue 状态会直接影响报告的准确性：
- open issues：标记为"已知限制"或"暂不支持"的功能，报告中不能写成"支持"
- closed issues：标记为"已修复"的问题，报告中不能写成"存在该bug"
- milestone/issues 中的 Roadmap：未来计划不能写成"已实现"
核对方法：
# 查看 open issues（含 bug 标签）
terminal: curl -s "https://api.github.com/repos/{owner}/{repo}/issues?state=open&labels=bug&per_page=20"
# 查看 closed issues
terminal: curl -s "https://api.github.com/repos/{owner}/{repo}/issues?state=closed&per_page=20"
或直接用 browser 访问 GitHub 项目的 Issues 页面，搜索关键词（如 "extract command"、"support for xxx"）。
校验完成标准
进入横向分析之前，必须确认：
校验不通过的常见后果（反面案例）
| 错误类型 | 反面案例 | 正确做法 |
|---|
| 过时信息 | 写着"browser-use 支持 extract 命令"，但实际上 CLI 的 extract 尚未实现 | 先查 GitHub Issues，确认后再写 |
| 错误关联 | 把 A 产品的功能写到 B 产品的分析里 | 每个竞品的功能描述，必须访问该产品的官方页面确认 |
| 幻觉数据 | "Flipbook 有100万用户"（实际无公开数据） | 搜不到的数据写"暂缺"，不编造 |
| 版本混淆 | "GPT-4 支持 128K context"（实际是 GPT-4-turbo） | 核对官方模型文档，区分基础模型和 turbo/vision 变体 |
四、横向分析（Synchronic / Cross-sectional）
以当前时间点为切面，将研究对象与同赛道的竞品/同类进行全面对比。
首先判断竞品情况（三种场景）
场景A：无直接竞品 → 跳过逐一对比，改为分析：它为什么没有竞品？是品类太新、壁垒太高、还是市场太小？未来最可能从哪个方向冒出竞争者？有没有间接替代方案或上一代解决方式可以参照？控制在3,000字左右。
场景B：少量竞品（1-2个） → 逐一深入对比，每个竞品展开详细分析。
场景C：竞品充分（3个及以上） → 选取最具代表性的3-5个进行对比，其余简要提及。每个主要竞品至少展开1,500字以上的独立分析，不要一笔带过。
对比维度（根据研究对象类型灵活调整，但至少覆盖以下方面）
-
核心差异对比
- 技术路线/核心方法论/底层逻辑
- 产品形态/商业模式/组织结构
- 目标用户/受众/适用场景
- 核心优势与明显短板
- 定价策略/资源投入/规模体量
-
用户视角
- 每个竞品的真实用户口碑如何？
- 社区评价、使用体验中被提及最多的优点和槽点
- 用户实际使用方式和官方定位有没有偏差？
- 对比不要写成参数对照表的文字版，要讲清楚每个竞品「活成了什么样」，用户选它的真实理由是什么
-
生态位分析
- 在整个赛道的版图中占据什么位置？
- 填补了什么空白，还是在跟谁正面竞争？
- 当前格局是百花齐放、两强争霸、还是一家独大？
-
趋势判断
- 基于横向对比，研究对象在竞争格局中的走向是什么？
- 机会和风险各是什么？
篇幅
3,000-10,000字。竞品越多越长。
五、横纵交汇洞察
这是整篇报告的精华段。把纵向发展脉络和横向竞争格局结合起来，给出综合性的、新的判断。不要写成前面内容的缩写版。
需要回答的核心问题
- 历史如何塑造了当下的竞争位置：纵向历程中的哪些决策和事件，决定了它今天在横向对比中的位置？
- 竞品的纵向对比：如果把主要竞品也放到时间线上看，它们的起源和演变路径有什么不同？这些不同如何导致了今天各自的特点？
- 优势的历史根源：今天的每个核心优势，能追溯到历史上的哪个节点或决策？
- 劣势的历史根源：今天的每个核心劣势，能追溯到哪个历史决策？当初的「好决策」有没有变成今天的包袱？
- 未来推演：基于纵向趋势和横向竞争格局，给出三个剧本——
- 最可能的剧本：顺着现有轨迹，最自然的走向
- 最危险的剧本：什么情况下会出大问题
- 最乐观的剧本：什么情况下会超预期
- 每个剧本要有逻辑支撑，不是拍脑袋
篇幅
1,500-3,000字。
六、写作风格
这不是一份冷冰冰的咨询报告，而是一篇让人能从头读到尾的深度研究。写作风格需要在「研究报告的严谨」和「优质深度报道的可读性」之间找到平衡点。
核心风格元素
节奏感：句子时长时短，段落之间跳跃自然。不要每段都一样长，一句话自成一段制造重量感的技巧可以用。好的节奏像波动，每次围绕主线偏出去一点，再用一句「扣主线句」拉回来。
叙事驱动，不是罗列驱动：纵向部分要有故事弧线，有起承转合。比如一个产品为什么在某个时间点突然爆发，背后的铺垫是什么，转折是什么。不要写成「2023年1月发布了A，2023年3月发布了B」这种流水账。
层层剥开的修辞：不直接讲结论，用「现象→表面解释→更深的追问→核心洞察」的方式展开。让读者参与到思考过程中。
回环呼应：开头或纵向部分埋的细节和钩子，在交汇洞察或结尾callback回来。前后因果的闭合感，是让报告从「信息流」变成「作品」的关键。
敢下判断：鼓励给出观点和洞察，但每个观点必须有事实支撑。先摆事实，再给判断。是推测的明确标注。表达判断时用「我认为」「我的判断是」这种承认主观性的姿态，而不是居高临下的定论。
结构与格式
- 研究报告需要清晰的章节结构和导航，不能一口气顺下来不加小标题
- 可适当使用对比表格辅助，但核心分析必须是文字论述
- 引用来源用
> 引用块或脚注标注
用人话写
避免套话和空洞概括。用具体的细节和例子代替概括性陈述。
❌ 不要写：「该公司在这一阶段实现了快速增长」
✅ 要写：「从2024年中期的1000万美元ARR到2025年底的10亿美元，增长曲线几乎是垂直的」
绝对禁区
以下AI味标记无论什么文体都要避免：
- 套话：「首先...其次...最后」「综上所述」「值得注意的是」「不难发现」
- 空洞形容词：「赋能」「抓手」「打造闭环」「全方位」「多维度」
- 教科书开头：「在当今AI快速发展的时代」「随着技术的不断进步」
- 高频踩雷词：「说白了」「意味着什么？」「这意味着」「本质上」「换句话说」「不可否认」
- 空泛工具名：不说「AI工具」「某个模型」，要说具体名字
- 编造场景：如果某个信息搜不到，诚实标注「该信息暂缺」，绝不编造
七、输出格式与交付
报告结构模板
封面信息
├── 研究时间
├── 所属领域
└── 研究对象类型
一、一句话定义
[用一句话说清楚这个东西是什么]
二、纵向分析：从诞生到当下
[完整的纵向叙事，6000-15000字]
三、横向分析：竞争图谱
[横向对比分析，3000-10000字]
四、横纵交汇洞察
[交叉分析和未来推演，1500-3000字]
五、信息来源
[所有引用的来源列表，标注URL和访问时间]
沉淀到 Obsidian
报告完成后，配合 obsidian-research-precipitation skill 将报告按规范沉淀到 Obsidian 知识库：
- 确定分类子目录（AI-agents/、LLMs/、Dev-tools/、Tech-concepts/、Companies/）
- 使用 kebab-case 英文文件名
- 添加标准 frontmatter（title、keywords、type、created、status、研究对象）
八、篇幅要求（自适应调整）
| 部分 | 字数范围 | 说明 |
|---|
| 纵向分析 | 6,000-15,000字 | 报告主体，不要蜻蜓点水 |
| 横向分析 | 3,000-10,000字 | 视竞品数量调整 |
| 横纵交汇 | 1,500-3,000字 | 精华段，给出新判断 |
| 全文总计 | 10,000-30,000字 | 不要怕长，深度和完整度是价值所在 |
核心原则：写到该停的地方自然停，绝不能因篇幅焦虑而牺牲信息密度。
九、执行流程
Step 1: 信息采集（纵向）
- 确定研究对象，明确研究边界
- 使用并行子Agent搜索起源信息：创始团队、诞生背景、首次发布
- 按时间线搜索演进历程的关键节点
- 搜集决策背景信息（访谈、博客、公告等一手来源）
- 整理时间线素材
- 执行信息充分性自检，不够就补搜
Step 2: 信息采集（横向）
- 识别竞品/同类，判断属于场景A/B/C
- 搜集每个竞品的核心信息
- 搜集用户口碑、社区评价（GitHub issues、Reddit、Twitter/X、知乎、V2EX等）
- 整理对比维度数据
- 执行信息充分性自检
Step 3: 分析与写作（纵向部分）
- 完成纵向分析叙事写作
Step 4: 内容准确性校验（强制）
【强制要求】此步骤不可跳过。纵向分析写完后，必须执行内容准确性校验（第三节），校验通过后方可进入横向分析。
执行内容准确性校验（详见第三节「三、内容准确性校验」）：
- 提取纵向分析中产出的所有具体断言，形成待校验清单
- 对清单中每个断言，逐一访问官方文档/Changelog/GitHub Issues 进行核对
- 根据校验结果修正或标注内容（与官方来源不一致的必须删除或修正）
- 确认所有校验项通过后，方可继续
校验不通过，不得进入 Step 5。
Step 5: 分析与写作（横向部分 + 交汇洞察）
- 完成横向对比分析
- 完成横纵交汇洞察（含三剧本推演）
- 全文通读，执行质检清单
Step 6: 沉淀交付（自动触发）
【强制要求】 完成报告写作后，必须自动调用 obsidian-research-precipitation skill 将报告沉淀到 Obsidian。这是横纵分析法知识积累的关键环节，每次分析后都要执行，不可跳过。
执行步骤：
-
加载 obsidian-research-precipitation skill
skill_view(name='obsidian-research-precipitation')
-
按照该 skill 的规范执行沉淀：
-
确认沉淀成功：
- 输出保存路径和文件名
- 确认文件已成功写入
- 示例输出：
✅ 研究内容已成功沉淀到 Obsidian：/Users/Joy/SynologyDrive/Obsidian/research/Dev-tools/perry-typescript-compiler-analysis.md
-
异常处理：
- 如果目录不存在，先创建目录再写入
- 如果同名文件已存在，在文件名后加版本号（如
v2）
- 如果遇到权限问题，提示用户检查目录权限
检查清单：
十、质检清单
交付前自检：
【内容准确性校验 — Step 4 完成度】
【整体质量】
