メニュー
横纵分析法深度研究 skill，用于系统性研究一个产品、公司、概念、技术或人物，并产出排版精美的 PDF 研究报告。仅在用户需要深度研究、横纵分析、竞品分析、系统调研或明确要研究报告时使用。不要用于简单名词解释、普通代码分析、bug 排查、公众号文章写作、SEO 审计、文档/PPT 转换或轻量问答。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | hv-analysis |
| description | 横纵分析法深度研究 skill，用于系统性研究一个产品、公司、概念、技术或人物，并产出排版精美的 PDF 研究报告。仅在用户需要深度研究、横纵分析、竞品分析、系统调研或明确要研究报告时使用。不要用于简单名词解释、普通代码分析、bug 排查、公众号文章写作、SEO 审计、文档/PPT 转换或轻量问答。 |
Use this skill on demand for deep research reports, not for every analysis request.
Trigger it when the task clearly involves one of these goals:
Do not trigger it for:
XX 是什么 when the user only needs a direct answerkhazix-writer when the final output is an articleThe deciding question is the real work, not just the file extension:
hv-analysiskhazix-writer方法论溯源 横纵分析法由数字生命卡兹克（Khazix）提出，融合了语言学中的历时-共时分析（Saussure）、社会科学中的纵向-横截面研究设计、商学院案例研究法、以及竞争战略分析的核心思想，形成了一套适用于产品/公司/概念/人物的通用研究框架。核心原则不变：纵向追时间深度，横向追同期广度，最终交汇出判断。
你正在执行一次横纵分析法深度研究。最终产出一份排版精美的PDF研究报告。
scripts/md_to_pdf.py（基于WeasyPrint），用于将最终Markdown报告转为排版精美的PDF。确保依赖已安装：pip install weasyprint markdown --break-system-packages。拿到用户输入后，确认以下信息。如果用户已经给得足够明确（比如"帮我用横纵分析法研究Hermes Agent"），不需要追问，直接开始：
这个方法论的质量完全取决于信息的丰富度和准确性。必须联网搜索，不能仅靠已有知识。研究报告的价值在于深度和完整度，所以信息收集阶段宁可多搜，不要因为信息不够导致后面的分析浮于表面。
使用子Agent并行搜索来提高效率。建议的分工：
子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、学术会议论文集 |
搜索完成后检查：
信息不够就再补搜。不要凑合。
沿时间轴，完整还原研究对象从诞生到现在的发展全貌。这是报告的主体部分，篇幅应该最重。
起源追溯：它诞生的背景是什么？基于什么技术/理念/需求而来？创始团队或核心推动者是谁？这些人之前做过什么，为什么是他们来做这件事？当时的行业环境是什么样的？有没有某个关键事件或灵感直接促成了它的诞生？
诞生节点：明确的首次发布/成立/提出时间，最初的形态和定位，跟现在有什么不同。
演进历程：从诞生到现在，按时间顺序梳理所有关键节点。包括但不限于：重大版本更新、融资事件、团队变动、战略转型、技术架构变化、用户规模里程碑、重大合作或收购、公关危机或争议事件。
决策逻辑：在每个关键节点上，尽可能还原决策背后的原因。为什么选了A而不是B？当时面对的约束条件是什么？哪些早期决策"锁定"了后来的发展方向、难以逆转？什么机制让它越走越深（网络效应、生态绑定、技术栈选择等）？
阶段划分：把整个历程自然分为几个阶段（萌芽期、快速增长期、转型期等），每个阶段有核心特征和核心矛盾。
6000-15000字。历史越长、节点越多的对象靠近上限，新生事物靠近下限。核心原则是把故事讲完整、讲透，每个关键节点都值得展开，不要为了压缩而跳过重要细节。宁可写长写细，也不要蜻蜓点水。
以当前时间点为切面，将研究对象与同赛道的竞品/同类进行全面对比。
分三种场景处理：
场景A：无直接竞品。 如果研究对象是全新品类或独占性极强的领域，跳过逐一对比，改为分析：它为什么没有竞品？是品类太新、壁垒太高、还是市场太小？未来最可能从哪个方向冒出竞争者？有没有间接替代方案或上一代解决方式可以参照？
场景B：少量竞品（1-2个）。 逐一深入对比，每个竞品展开详细分析。
场景C：竞品充分（3个及以上）。 选取最具代表性的3-5个进行对比，其余简要提及。
根据研究对象的类型灵活调整，但至少覆盖以下方面：
核心差异对比：技术路线/核心方法论/底层逻辑、产品形态/商业模式/组织结构、目标用户/受众/适用场景、核心优势与明显短板、定价策略/资源投入/规模体量。
用户视角：每个竞品的真实用户口碑如何？社区评价、使用体验中被提及最多的优点和槽点分别是什么？用户实际的使用方式和官方定位有没有偏差？对比不要写成参数对照表的文字版，要讲清楚每个竞品「活成了什么样」，用户选它的真实理由是什么。
生态位分析：在整个赛道的版图中，研究对象占据什么位置？填补了什么空白，还是在跟谁正面竞争？当前格局是百花齐放、两强争霸、还是一家独大？
趋势判断：基于横向对比，研究对象在竞争格局中的走向是什么？机会和风险各是什么？
3000-10000字。场景A控制在3000字左右，场景C每个主要竞品至少展开1500字以上的独立分析，不要一笔带过。
这是整篇报告的精华段。把纵向发展脉络和横向竞争格局结合起来，给出综合性的、新的判断。不要写成前面内容的缩写版。
需要回答的核心问题：
1500-3000字。
这不是一份冷冰冰的咨询报告，而是一篇让人能从头读到尾的深度研究。写作风格需要在「研究报告的严谨」和「卡兹克的可读性」之间找到平衡点。
以下风格元素直接应用到报告写作中（详细定义请参考 khazix-writer skill）：
节奏感：句子时长时短，段落之间跳跃自然。不要每段都一样长，一句话自成一段制造重量感的技巧可以用。好的节奏像波动，每次围绕主线偏出去一点，再用一句「扣主线句」拉回来。
叙事驱动，不是罗列驱动：纵向部分要有故事弧线，有起承转合。比如一个产品为什么在某个时间点突然爆发，背后的铺垫是什么，转折是什么。不要写成"2023年1月发布了A，2023年3月发布了B"这种流水账。
知识是「聊着聊着顺手掏出来」的：在讲述过程中自然地带出背景知识，不要「下面我来给大家科普一下」。
敢下判断：鼓励给出观点和洞察，但每个观点必须有事实支撑。先摆事实，再给判断。是推测的明确标注。表达判断时用「我觉得」「我的判断是」这种承认主观性的姿态，而不是居高临下的定论。
层层剥开的修辞：不直接讲结论，用"现象→表面解释→更深的追问→核心洞察"的方式展开。让读者参与到思考过程中。
文化升维：在交汇洞察部分，连接到更大的文化/哲学/历史参照物。不是硬凑的升华，是「聊着聊着自然想到了」的感觉。
回环呼应：开头或纵向部分埋的细节和钩子，在交汇洞察或结尾callback回来。前后因果的闭合感，是让报告从「信息流」变成「作品」的关键。
以下元素适合公众号文章但不适合研究报告，需要克制：
以下AI味标记无论什么文体都要避免：
避免咨询公司式的套话和空洞概括。用具体的细节和例子代替概括性陈述。比如不要写「该公司在这一阶段实现了快速增长」，而要写「从2024年中期的1000万美元ARR到2025年底的10亿美元，增长曲线几乎是垂直的」。
报告写完后，使用本Skill自带的 scripts/md_to_pdf.py 脚本将Markdown转为排版精美的PDF。
[研究对象]_横纵分析报告.mdpip install weasyprint markdown --break-system-packagespython [skill目录]/scripts/md_to_pdf.py input.md output.pdf --title "研究对象名称" --author "数字生命卡兹克"
md_to_pdf.py 已内置完整的CSS排版方案，无需手动调整：
"Droid Sans Fallback", Helvetica, Arial, sans-serif，自动处理中英文混排为了让脚本正确解析并生成最佳PDF效果：
# 标题 作为报告标题（会自动用于封面）> 研究时间：... | 所属领域：... | 研究对象类型：... 格式写元信息行，会被提取到封面## 作为主要章节标题（纵向分析、横向分析、横纵交汇等）### 和 #### 作为子章节> 语法**文本**在Markdown稿件末尾加上：
封面页
目录
一、一句话定义
[用一句话说清楚这个东西是什么]
二、纵向分析：从诞生到当下
[完整的纵向叙事，6000-15000字]
三、横向分析：竞争图谱
[横向对比分析，3000-10000字]
四、横纵交汇洞察
[交叉分析和未来推演，1500-3000字]
五、信息来源
[所有引用的来源列表]
PDF文件命名为 [研究对象名称]_横纵分析报告.pdf，保存到用户的工作目录中。
核心原则不变（纵向追时间深度，横向追同期广度），但侧重点不同：
研究产品时：纵轴重点关注版本迭代、技术路线演变、用户增长曲线、关键产品决策；横轴重点关注功能对比、性能对比、用户体验、定价。
研究公司时：纵轴重点关注创始团队、融资历程、战略转向、组织变革、关键人事变动；横轴重点关注商业模式差异、市场份额、营收对比、组织架构差异。
研究概念时（技术范式、商业模式、文化现象）：纵轴重点关注概念的起源（谁提出的、基于什么理论/需求）、如何流行起来、经历了哪些争论和演变；横轴重点关注与相近概念的区别、各自适用场景、不同阵营的论证。
研究人物时：纵轴重点关注个人经历、职业轨迹、关键决策、成长曲线、公开言论变化；横轴重点关注与同领域其他人物的对比（做事方式、风格、成就、影响力、路线选择差异）。
| 部分 | 字数范围 | 说明 |
|---|---|---|
| 纵向分析 | 6,000 - 15,000字 | 报告主体，不要蜻蜓点水 |
| 横向分析 | 3,000 - 10,000字 | 视竞品数量调整 |
| 横纵交汇 | 1,500 - 3,000字 | 精华段，给出新判断 |
| 全文总计 | 10,000 - 30,000字 | 不要怕长，深度和完整度是价值所在 |
交付前自检：
Use this skill when the task is specifically about AI search, AI Overviews, LLM citations, answer-engine optimization, or improving visibility in AI-generated answers. Good fit for AEO, GEO, LLMO, AI citations, zero-click AI visibility, and optimization for ChatGPT, Perplexity, Claude, Gemini, or similar systems. Do NOT use as the default for broad SEO audits or for pure schema implementation.
在创造性产品或设计工作之前使用此技能：创建新功能、构建新组件、添加新能力，或有意改变既定产品行为。在实现前先探索用户意图、需求和设计。不要用于 bug 修复、测试失败、构建失败、回归修复、恢复已有行为，或预期行为已经明确的实现任务；这些情况优先使用 systematic-debugging、test-driven-development 和 verification-before-completion。
Unified Impeccable frontend design skill. Use when the goal is to design, build, redesign, or improve a frontend interface — web pages, landing pages, dashboards, product UI, app shells, components, forms, settings, onboarding, empty states, responsive behavior, typography, spacing, layout, color, motion, UX copy, accessibility, or UI-perceived performance. Also use for Impeccable command-style requests aimed at frontend work, such as `impeccable craft`, `shape`, `init`, `document`, `extract`, `critique`, `audit`, `polish`, `bolder`, `quieter`, `distill`, `harden`, `onboard`, `animate`, `colorize`, `typeset`, `layout`, `delight`, `overdrive`, `clarify`, `adapt`, `optimize`, `live` (`teach` is only a deprecated alias for `init`). Do NOT use for backend or non-frontend code audits, docs, or reviews; live-site design-language extraction; static poster or cover art; HTML slide decks; PowerPoint / PDF / Word / spreadsheet deliverables; or specialized React/Next performance work.
遇到 bug、测试失败、构建失败、生产事故或异常行为时使用；在提出修复方案之前先找根因，不要凭直觉打补丁。 / Use for bugs, test failures, build failures, production incidents, or unexpected behavior — investigate the root cause before proposing a fix; do not patch symptoms.
在实现新功能、有意的行为变更，或非平凡 bug 修复时使用——先写一个会失败的测试，再写实现代码。例外：一次性原型、生成代码、配置文件、单行 trivial 修改、纯文案/排版/样式调整，以及没有可测行为的改动。 / Use when implementing new features, intentional behavior changes, or non-trivial bug fixes — write a failing test before implementation. Exceptions: throwaway prototypes, generated code, config files, trivial single-line patches, copy / typography / pure style edits, and changes with no testable behavior.
当确实需要与当前工作区隔离时使用，例如并行开发、临时 hotfix、PR 检查、多方案实验或执行大型实现计划。不要作为日常小修、普通 bug 修复、只读调查或单文件改动的默认流程。