JetBrains应届生PM面试准备完全指南2026

大多数人对JetBrains PM的理解，止步于对IDE的表面使用。这是一种错觉。

一句话总结

JetBrains PM的筛选逻辑，不是考察你对产品的热情，而是你对开发者痛点的深刻洞察与技术共情；不是评估你背诵了多少PM框架，而是你如何将工程思维融入产品决策；不是看你简历上罗列的成就，而是你解决复杂技术问题的思维路径与结构化能力。

适合谁看

本指南面向那些拥有计算机科学或相关工程背景、对构建开发者工具抱有深度热情、并渴望在技术驱动型公司开启产品管理职业生涯的应届毕业生。如果你在大学期间有实际的软件开发项目经验，能够阅读并理解代码库，对IDE、编程语言、DevOps工具有着超越普通用户的理解，并且追求通过技术创新解决复杂问题，而非仅仅关注商业模式或用户增长，那么这份裁决书将为你校准方向。

这不是一份为纯商业PM或市场导向型PM准备的清单，而是为那些能与工程师在技术细节上深度对话、并从中提炼产品价值的技术PM量身定制。

JetBrains PM，究竟在寻找什么？

JetBrains PM职位的核心筛选标准，不是你如何描绘一个宏大的市场愿景，而是你如何精准拆解一个技术难题，并将其转化为用户真正需要的解决方案。面试官在寻找的，不是一个能够“管理产品”的人，而是一个能够“驱动产品进化”的人。这两种心智模式的差异是根本性的。

在JetBrains，产品经理的角色更像是一位“技术产品策略师”，而非“市场需求收集者”。他们期望你具备与工程师平等对话的能力，能够理解底层架构的复杂性，并在技术限制中找到创新的空间。

例如，在一次内部产品评审会议上，关于是否支持一个新的编程语言特性，面试官并非想听你引用市场报告，而是希望你能够从语言设计哲学、编译器实现难度、以及对现有用户工作流的影响等多个维度进行分析，并给出基于技术权衡的优先级判断。这不是一份简单的“用户想要什么”的反馈，而是“技术上可行且对核心用户价值最大化”的决策。

其招聘流程的初期，HR或招聘经理对简历的筛选，不是看你是否有知名大厂实习经历的光环，而是看你是否展现出对技术产品的“痴迷”。一个在个人项目中深入参与过开源社区、贡献过代码，或者自行开发过小型开发者工具的候选人，其信号强度远高于那些仅仅在知名公司担任过通用型PM实习、却无法深入技术细节的人。

我们曾在一个应届生简历的debrief会议上讨论过，一位候选人即便没有Tier 1公司实习，但他的简历上详细描述了他如何优化了一个特定编译器的性能，并为此阅读了大量底层代码，这远比那些泛泛而谈“调研用户需求，制定产品路线图”的描述更能引起工程团队的兴趣。

公司文化深处，JetBrains崇尚的是“工程师为工程师打造工具”的理念。这意味着PM必须能够站在工程师的视角思考问题。面试中的产品设计环节，不是让你凭空想象一个酷炫的功能，而是让你针对一个具体的IDE痛点，比如“如何优化大型代码库的索引速度”，或者“如何提高调试体验的效率”，提出一个切实可行的技术解决方案，并能解释其背后的技术原理。

面试官会深入追问你的方案是否考虑了多语言支持、插件生态兼容性、性能开销等技术细节。他们不是在考察你的UI/UX设计能力，而是在考察你将复杂技术问题转化为简洁用户体验的能力。这份能力，植根于对工程的深刻理解，而非仅仅停留在用户界面的美观层面。

因此，你必须在面试中展现出对JetBrains产品线的深入理解，不仅仅是作为用户，更是作为潜在的产品贡献者。不是简单地陈述你喜欢IntelliJ IDEA的哪些功能，而是你如何设想可以进一步改进某个特定功能，提高开发者的工作效率，并能阐述其技术实现的可能性与挑战。这种深度的、技术驱动的洞察力，才是JetBrains PM职位真正的敲门砖。

简历与初筛：不是经验堆砌，而是信号提炼？

大多数应届生认为，简历是用来堆砌所有项目和实习经历的，仿佛数量越多，机会越大。这是一种严重的误解。对于JetBrains而言，简历的本质功能不是展示你的广度，而是提炼你的深度信号。招聘经理在平均6-8秒的扫视中，不是在寻找一份“完美”的简历，而是在寻找那些能立即触发“技术共鸣”的关键词和叙述方式。

初筛阶段，HR或招聘经理关注的核心，不是你曾在大厂从事了哪些“高大上”的项目，而是你如何在这些项目中，具体体现了对开发者工具的理解、对技术复杂性的拆解能力，以及对用户（即开发者）痛点的解决意愿。例如，如果你参与了一个数据科学平台项目，泛泛地写“负责用户调研，定义产品需求”是无效的。

正确的表达方式应是：“在[数据科学平台]项目中，深入研究了数据科学家在[特定模型训练/部署环节]的痛点，发现现有[某开源工具]在[性能/易用性]方面存在不足。主导设计并实现了[一个特定功能/模块]，通过[具体技术手段，如引入异步处理/优化UI交互]，将[特定操作]的效率提升了X%，有效解决了[痛点]，并撰写了[技术文档/API示例]以赋能开发者。”

这里的关键是“具体技术手段”、“提升了X%”、“解决了[痛点]”、“赋能开发者”。这些词汇直接触及了JetBrains的招聘心智。他们不是在寻找一位通用型PM，而是一位对技术有深入理解、能够为工程师赋能的PM。

你的简历必须像一份技术产品说明书，清晰地阐述你解决了什么技术问题，使用了什么技术栈，以及最终带来了什么价值。不是罗列你使用过的所有工具，而是聚焦于你如何用这些工具解决了问题。

我曾参与过一个应届生PM的简历评估，一位候选人简历上写着“熟悉Python、Java、C++”，但没有具体项目支撑，这被视为弱信号。而另一位候选人则描述了他在一个编译器前端项目中，如何使用LLVM IR优化代码生成，并在GitHub上开源了部分代码。

即便他没有知名公司的实习经历，但后者明确展现了其工程实践能力和对底层技术的兴趣，这在JetBrains看来，是强有力的正向信号。

因此，你的简历必须剔除一切冗余信息，将重点放在：

  1. 你解决过的具体技术问题（最好是与软件开发、工具链、系统优化相关的）。
  2. 你在这个问题中扮演的具体角色和贡献（强调技术决策与实现）。
  3. 你通过何种技术手段实现了这些贡献。
  4. 最终带来的技术或用户价值（量化或具体描述）。

这不是一份个人成就的展览，而是一份精准瞄准JetBrains技术PM需求的功能说明书。你的每一条项目描述，都应该能让一位资深工程师或技术PM一眼看出你的技术深度和解决问题的潜力。

技术与产品交叉：如何证明你的工程根基？

JetBrains的PM面试，尤其是在技术轮次，其深度远超一般公司。他们考察的不是你是否能“理解”工程师在说什么，而是你是否能“参与”工程师的讨论，甚至能提出有价值的技术见解。这轮面试的本质，不是评估你是否能写出完美的代码，而是判断你是否具备产品化思维下的工程判断力。

面试官会深入到你简历上提及的技术项目细节，或给出开放性的技术产品设计题。例如，他可能不会直接问你LeetCode难题，而是让你设计一个“文件索引服务”，或者“代码补全引擎的架构”。你必须能够清晰地阐述其核心组件、数据流、性能瓶颈、可扩展性考量，并能讨论不同技术方案的优劣权衡。

这不是一个简单的系统设计题，而是一个融合了产品目标、用户体验和工程实现的综合考察。你可能需要讨论如何为这个服务设计API，如何保证其在百万级代码库中的响应速度，以及如何处理多语言和多文件类型的兼容性。

在一个真实的面试场景中，我们曾让候选人设计一个“分布式代码分析工具”。一位候选人仅仅罗列了常见的分布式系统组件（如消息队列、负载均衡），但无法深入解释为何选择这些组件，以及它们如何解决代码分析的特定挑战，例如如何处理增量分析、如何减少网络传输开销等。这被视为“背诵框架，缺乏深度理解”。

而另一位候选人则从代码分析的语义理解、AST（抽象语法树）构建、以及如何将分析任务拆解到不同计算节点等技术细节入手，并提出了基于版本控制系统差异化分析的优化思路。他甚至讨论了在不同的编程语言场景下，可能需要不同的分析引擎和数据结构，展现了对复杂技术问题的深刻洞察。

这种深度，来源于你对工程实践的长期投入，而不是临时的突击学习。你必须能够向面试官证明，你不仅仅是一个产品的“用户”，更是一个产品的“制造者”。

你理解技术栈的限制，知道工程实现的复杂性，并且能在这些限制和复杂性中找到产品创新的机会。例如，在讨论一个新功能时，你不是简单地说“用户想要这个”，而是能从工程成本、技术可行性、以及对现有系统影响的角度，提出一个更具建设性的、技术上更优雅的实现方案。

薪资方面，JetBrains应届生PM的整体薪酬结构通常包括三部分：基本工资（Base Salary）、年度奖金（Annual Bonus）和股权激励（RSU/Stock Options）。对于在欧洲或美国招聘的应届生PM，一个竞争力的范围可能是：基本工资在$90,000-$130,000美元之间，年度奖金通常为基本工资的10%-15%（即$9,000-$19,500美元），股权激励每年约$20,000-$50,000美元（通常分3-4年归属）。

因此，总现金薪酬（Base + Bonus）可能在$99,000-$149,500美元，而总包薪酬（Total Compensation）则在$119,000-$199,500美元之间。这个薪资水平在技术型公司中极具竞争力，反映了JetBrains对技术PM的重视。

面试流程通常包括：

  1. HR电话筛选（15-30分钟）： 考察基本背景、职业兴趣、对JetBrains的了解。
  2. Hiring Manager/产品负责人电话面试（45-60分钟）： 深入探讨简历项目、PM基础概念、对开发者工具的理解。
  3. 技术产品设计/系统设计面试（60分钟）： 核心技术轮，考察产品化思维下的工程判断力，如前所述。
  4. 产品策略/用户洞察面试（60分钟）： 考察如何发现开发者痛点、优先级排序、产品路线图规划。
  5. 跨职能协作/行为面试（60分钟）： 考察沟通、影响力、解决冲突、团队协作能力。
  6. 高管/VP面试（45-60分钟）： 综合评估候选人与公司文化的契合度、长期潜力。

每一轮都旨在层层递进地验证你的技术深度、产品广度以及与JetBrains文化相符的特质。

产品设计与用户洞察：为开发者打造工具的独特视角？

为开发者设计产品，与为普通消费者设计产品，其核心逻辑存在根本性差异。这种差异不是简单的目标用户不同，而是用户心智模式、需求表达方式和产品价值衡量标准的根本性重塑。在JetBrains的面试中，产品设计轮次不是让你展示如何创造一个“令人愉悦”的体验，而是如何打造一个“高效、强大、无缝融入工作流”的工具。

面试官会给你一个具体的开发者场景，比如“设计一个更好的版本控制系统集成体验”，或者“如何改进代码重构功能”。你的任务不是描绘一个精美的UI界面，而是深入剖析开发者在这些场景下的真实痛点，并提出基于技术理解的解决方案。

一个常见的错误是，候选人会从通用用户体验原则出发，如“简化操作流程”、“提供清晰的反馈”。这些没错，但对于开发者工具而言，更关键的是“减少上下文切换”、“提高代码理解效率”、“自动化重复性任务”。

例如，在一次产品设计面试中，有候选人提出，为了简化版本控制，应该提供一个图形化界面，让用户拖拽文件进行合并。这听起来很直观，但对于资深开发者而言，他们更关心的是如何通过命令行或快捷键快速解决冲突，如何在IDE内直接查看差异并进行精细化调整，以及如何与他们已有的Git工作流无缝衔接。一个更好的回答会是：“现有图形化合并工具在处理复杂三方合并时仍需手动干预，且在大型代码库中性能表现不佳。我的方案会集中在：1. 增强IDE内置的差异视图，允许开发者直接在代码行级别进行更智能的合并决策，例如通过AI辅助识别语义冲突而非仅仅语法冲突。

  1. 引入一种更高效的冲突解决机制，允许开发者定义常用合并策略，并能一键应用。3. 优化底层文件系统监听和索引，确保在频繁切换分支时，IDE能快速刷新状态，减少等待时间。这并非是提供一个全新的交互方式，而是优化核心痛点，让开发者能够更快、更精准地解决问题。”

这里体现的不是对表面用户需求的响应，而是对深层开发者行为模式和技术习惯的洞察。开发者是理性且高效的用户群体，他们不追求花哨的功能，而是追求能真正提升生产力的工具。你的产品设计必须体现出对“开发者心流”（Flow State）的理解——如何减少中断，保持专注，让代码编写和调试过程尽可能流畅。这不是关于“用户想要什么”，而是关于“如何让开发者变得更强大”。

因此，在产品设计面试中，你需要：

  1. 精准定位开发者痛点： 不是泛泛而谈，而是结合具体场景，剖析开发者在某个环节面临的技术或效率挑战。
  2. 提出基于技术理解的解决方案： 你的方案必须在技术上可行，并能解释其实现原理和潜在的工程挑战。
  3. 权衡设计决策： 讨论不同方案的优劣，包括性能、可扩展性、学习成本、对现有生态的影响等。
  4. 展示对“开发者心流”的追求： 你的设计目标是帮助开发者更高效、更专注地完成工作。

这是一种将技术理解、用户同理心和产品思维深度融合的能力，而非简单的功能堆砌。

跨职能协作：PM在JetBrains的真实影响力？

在JetBrains，产品经理的影响力不是通过“发布命令”来实现的，而是通过“赢得信任”和“建立共识”来驱动。这不是一个由PM主导、工程师执行的模式，而是一个由PM提供愿景、工程师共同塑造的协作环境。你的核心任务不是告诉工程师“做什么”，而是与他们一起探索“如何做得最好”。

面试中，行为问题或情景题会深入考察你如何处理跨职能冲突、如何建立信任、以及如何在没有直接管理权的情况下推动项目进展。例如，面试官可能会问：“如果你与工程团队在某个技术实现方案上存在分歧，你会如何处理？”一个无效的回答是：“我会坚持我的产品需求，并向上级汇报。”这体现的是僵硬和冲突，而非协作。

正确的回答应是：“首先，我会深入了解工程团队提出替代方案的技术原因和顾虑，例如性能、可维护性、未来扩展性等。不是简单地驳回他们的意见，而是主动寻求技术细节的解释。然后，我会将这些技术限制与最初的产品目标和用户价值进行重新权衡。例如，如果工程师认为我的方案会导致严重的性能问题，我会与他们一起探索是否有折衷方案，既能满足核心用户需求，又能规避技术风险。

我会通过数据、用户反馈和竞争对手分析来支持我的论点，但更重要的是，我会展示我愿意理解并尊重工程专业的态度。目标不是‘我赢’，而是‘我们共同找到最佳方案’。这种方式曾在[具体项目]中，帮助我们从[最初低效方案]转向[更优方案]，既满足了用户需求，又避免了潜在的技术债。”

在JetBrains，PM的日常工作是与一支由高度自治、技术精湛的工程师组成的团队紧密合作。这些工程师通常对自己正在解决的问题有着深刻的理解和强烈的见解。

因此，你的影响力不是来自你的职位头衔，而是来自你的技术洞察力、你清晰的沟通能力、以及你与团队建立的互信关系。你必须能够用工程师理解的语言交流，能够识别并尊重他们的专业判断，并在必要时，用数据和逻辑而非权威来引导讨论。

一个Insider场景是：在一次关于新功能发布后的Bug修复优先级排序会议上，PM提出的修复方案与测试团队发现的严重性报告存在出入。PM不是简单地推翻测试团队的发现，而是主动邀请测试工程师一起分析Bug的复现路径和影响范围，并与开发团队共同评估修复的复杂性和风险。

最终，PM能够综合技术实现难度、用户影响和发布窗口，做出一个让各方都信服的优先级调整。这不是PM单方面的决策，而是多方专业意见的整合与平衡。

因此，你的面试准备必须包括思考你如何：

  1. 建立技术信用： 通过深入理解技术细节，赢得工程团队的尊重。
  2. 有效沟通与说服： 不只是阐述需求，更是解释需求背后的Why，并能用数据和逻辑支撑。
  3. 解决冲突与达成共识： 将冲突视为寻找最佳方案的机会，而非个人观点的对抗。
  4. 赋能团队： 帮助工程师理解产品愿景，让他们感受到自己的工作对产品成功的关键作用。

PM在JetBrains的真正影响力，体现在你能够在技术复杂性、用户需求和商业目标之间找到那个优雅的平衡点，并带领团队共同走向成功。

准备清单

  1. 深度研究JetBrains产品线： 不仅仅是使用，更是深入理解每个产品的目标用户、核心价值主张、技术栈和独特卖点。例如，IntelliJ IDEA是如何通过代码分析、重构工具、版本控制集成等功能，解决Java开发者的痛点？ReSharper又是如何提升.NET开发体验的？不是A产品的用户，而是B产品的研究者。
  2. 系统性拆解面试结构： 针对JetBrains的每一轮面试（HR筛、PM/HM面、技术产品设计、系统设计、行为面、高管面）的考察重点和常见问题进行针对性准备。PM面试手册里有完整的JetBrains技术PM实战复盘和案例分析可以参考，帮助你构建结构化的应对策略。
  3. 强化技术基础与系统设计能力： 复习数据结构、算法、操作系统、网络等基础知识。重点准备如何设计可扩展、高性能、高可用的软件系统，尤其关注与开发者工具相关的系统，如编译器架构、代码分析引擎、分布式构建系统等。不是背诵概念，而是理解原理并能应用。
  4. 构建开发者视角的产品故事： 准备2-3个你实际参与过的项目，重点突出你如何从开发者角度发现问题，如何运用技术知识提出解决方案，以及最终带来的效率提升或技术创新。不是泛泛而谈的PM经验，而是聚焦技术PM的独特价值。
  5. 练习技术产品设计与优先级排序： 针对JetBrains可能提出的场景题，如“设计一个新功能以提高代码审查效率”，练习从用户痛点、技术可行性、工程成本、商业价值等多个维度进行分析和权衡，并给出清晰的优先级排序。不是凭空想象，而是基于数据和技术常识。
  6. 准备行为面试案例： 针对“如何处理与工程师的分歧”、“如何推动一个复杂技术项目的进展”等问题，准备具体的STAR（Situation, Task, Action, Result）案例，强调你在协作、影响力、解决问题方面的能力。不是空泛的理论，而是具体的实践经验。
  7. 模拟面试与反馈： 寻找有经验的技术PM进行模拟面试，尤其是针对技术产品设计和系统设计轮次。获得真实反馈，发现盲点并迭代改进。不是自我感觉良好，而是通过外部视角发现不足。

常见错误

  1. 将JetBrains视为通用型互联网公司面试：

BAD: 候选人面试时，大谈特谈用户增长、市场份额、商业模式创新，并以消费者产品（如社交媒体、电商平台）的案例来佐证自己的产品思维。在产品设计环节，提案过于注重UI美观和“酷炫”功能，却无法深入解释其背后的技术实现复杂性或对核心开发者工作流的真正影响。在描述项目经验时，强调“我成功地将用户转化率提升了X%”，但无法具体说明是通过哪些技术优化实现的。

GOOD: 候选人开场即表达对IDE、编程语言、编译器等底层技术的浓厚兴趣，并能列举JetBrains特定产品（如CLion、GoLand）如何解决了某个技术痛点。在产品设计环节，他会针对一个具体的开发效率问题（如“如何优化大型项目中的模块依赖管理”）提出解决方案，并能深入讨论如何通过静态分析、AST解析、增量编译等技术手段实现。

在项目经验分享中，他会详细描述在某个开源项目中，如何通过重构代码库、优化算法，提升了特定功能的性能X%，并展示了对技术细节的掌握。他理解JetBrains PM的价值不是在商业策略，而在于技术赋能。

  1. 技术理解停留在表面，无法深入：

BAD: 当被问及某个技术概念（如“什么是微服务架构？”或“如何优化数据库性能？

”），候选人只能给出教科书式的定义或泛泛而谈的解决方案（“采用缓存”、“分库分表”），但当面试官追问具体实现细节、不同技术方案的权衡、或在特定场景下的适用性时，便支吾其词，无法给出深入的见解。例如，在设计一个代码索引服务时，他只提到“用哈希表”，却无法讨论如何处理不同语言的语法解析、如何增量更新索引、以及如何处理大规模代码库的内存和IO瓶颈。

GOOD: 候选人不仅能清晰定义技术概念，更能结合实际项目经验，阐述其优缺点及适用场景。当被问及微服务架构时，他会结合在某个项目中遇到的扩展性问题，讨论为何选择微服务，以及在服务间通信、数据一致性、监控等方面遇到的挑战及解决方案。

在代码索引服务设计中，他会讨论不同索引结构（如倒排索引、Trie树）的优劣，如何利用LSP（Language Server Protocol）进行语义分析，以及如何设计一个多级缓存系统来优化查询性能，甚至能估算不同方案的资源消耗。他展现的是对工程原理的深刻理解和实践经验。

  1. 沟通缺乏结构化与逻辑链条：

BAD: 候选人在回答问题时，思路跳跃，语言冗长，缺乏清晰的逻辑框架。在描述一个复杂问题时，没有先阐明问题背景和目标，而是直接跳到细节，导致面试官难以理解其论点。在给出解决方案时，没有先提出核心观点，再进行论证，而是想到哪里说到哪里，缺乏说服力。例如，在产品设计环节，他可能直接开始描述UI元素，而不是先定义问题、用户、目标、约束。

GOOD: 候选人始终遵循结构化沟通的原则。在回答任何问题前，会先简要概括核心观点，然后通过“背景-问题-方案-影响”或“why-what-how”的逻辑链条进行展开。例如，在产品设计题中，他会首先明确“问题是什么”、“目标用户是谁”、“我们想达成什么”，然后提出“我的核心设计理念是什么”，接着深入阐述“具体功能如何实现”，最后总结“带来的价值和潜在风险”。

他的语言简洁、精准，能引导面试官理解其思考过程，而非让面试官去猜测。这种结构化能力，是技术PM在高压决策环境中保持清晰思维的关键。

FAQ

  1. 没有CS背景能进入JetBrains PM吗？

裁决是：难度极高，但不绝对。JetBrains PM职位的核心是技术驱动。没有CS背景，意味着你在理解编程语言、软件架构、算法等核心技术概念上存在天然壁垒，这在与工程师深度沟通、理解开发者痛点时将是巨大障碍。

我们曾面试过一些非CS背景的候选人，即便他们在产品思维和沟通能力上表现出色，但一旦涉及到系统设计、技术可行性分析，或对底层开发工具的理解，便会暴露出短板。这不是对个人能力的否定，而是JetBrains PM角色对技术深度的硬性要求。如果你没有CS背景，必须通过自学、大量编程实践、参与开源项目等方式，弥补技术知识的空白，并且能够在面试中展现出超越常人的技术理解力和实践经验，否则被筛掉的概率极大。

  1. JetBrains PM的日常工作和FAANG有什么不同？

裁决是：JetBrains PM的日常工作更深入技术细节，更聚焦于“赋能开发者”而非“用户增长”或“商业变现”。在FAANG，PM可能需要更多地关注A/B测试、用户增长指标、市场分析、商业模型设计，其产品通常面向广大的消费者或企业用户。而在JetBrains，你的核心用户是开发者，你的日常工作会围绕如何优化IDE、编译器、版本控制工具、云开发环境等，以提升开发者的效率和体验。

这意味着你可能需要花大量时间研究最新的编程语言特性、开发工具趋势、与工程师进行技术方案的深入讨论、甚至阅读和理解代码库。你的成功不是通过DAU（日活跃用户）或营收增长来衡量，而是通过开发者生产力的提升、工具使用体验的优化、以及对开发者社区的影响力来体现。

  1. 如何准备System Design面试？

裁决是：System Design面试的准备，不是背诵标准答案，而是培养结构化思考复杂技术问题的能力。对于JetBrains，这更偏向于“技术产品系统设计”。你需要掌握分布式系统的核心概念（如一致性、可用性、可伸缩性、容错性），但更重要的是，学会将这些概念应用于开发者工具的特定场景。例如，一个“代码补全服务”的系统设计，你需要考虑如何处理高并发、低延迟、多语言支持、增量更新、以及如何与IDE无缝集成。

准备时，应多练习分析JetBrains现有产品或类似开发者工具的架构，理解其设计背后的权衡。不是简单罗列组件，而是深入解释为何选择这些组件，它们如何协同工作，以及在不同技术约束下如何进行取舍。多进行模拟面试，并要求面试官深入追问技术细节，以暴露和弥补你的知识盲区。

准备好系统化备战PM面试了吗？

获取完整面试准备系统 →

也可在 Gumroad 获取完整手册。