大多数ICICI Bank的TPM候选人，在面试中都无法清晰地界定“技术”与“项目”的边界。他们不是被技术深度绊倒，就是被项目管理流于表面。
ICICI Bank，作为印度领先的私人银行，其技术项目经理的岗位的核心，不是你熟练掌握了多少敏捷框架，也不是你能画出多复杂的系统架构图，而是你在风险、合规、规模化的银行环境中，如何将技术策略转化为可执行、可度量、可交付的复杂技术项目。
一句话总结
ICICI Bank的TPM面试，核心在于检验你将复杂技术挑战转化为银行级解决方案的能力，不是孤立的技术专精，而是跨职能、高风险环境下的系统性交付。其考察重点是你在合规与规模化约束下，如何驱动技术决策、管理跨团队依赖，并最终实现业务价值，而不是仅仅停留在项目进度的报告或技术细节的罗列。
正确的判断是，ICICI Bank寻求的是一位能理解银行运营逻辑、具备深厚技术背景、并能有效在高度受控环境中领导技术变革的复合型人才，你之前可能以为的“技术牛人”或“项目专家”的单一视角，是错误的。
适合谁看
这篇裁决，是为那些致力于进入ICICI Bank，成为技术项目经理（TPM），并已具备至少5年以上相关技术项目管理经验的资深专业人士而写。如果你正在从纯软件开发、系统架构、DevOps工程，或者其他金融科技公司的项目管理岗位转型，希望在银行严谨、高风险、重合规的环境中寻求更广阔的职业发展，并且你对驱动大规模技术变革充满热情，那么这篇文章将为你揭示ICICI Bank在TPM人才甄选上的真实标准与隐含期待。
它不是为初级PM准备的指南，也不是为那些只关注表面技巧的投机者提供捷径，而是为有志于在印度金融科技前沿发挥领导作用、敢于面对复杂挑战的你，提供一份清晰的裁决书，帮助你校准方向，不再被面试中的常见误区所困扰。
ICICI Bank的TPM，究竟是技术还是管理？
ICICI Bank对TPM的定义，是一个典型的“不是非此即彼，而是两者兼顾”的裁决。绝大多数候选人在面试中，无法在技术深度和项目管理广度之间找到平衡点。
他们通常会犯一个错误：不是将自己定位成一个技术架构师，过度陷入技术细节的泥沼，就是在项目管理上泛泛而谈，未能体现银行特有的复杂性。正确的理解是，ICICI Bank的TPM，首先是一个技术领导者，其次才是一个项目管理者，但这个技术领导者的核心价值在于其对“可交付性”的深刻理解和驱动力。
想象一个真实的面试场景：面试官提出了一个关于“如何将传统核心银行系统迁移到云原生架构”的问题。一个常见的错误回答是，候选人会详细罗列出Kubernetes、微服务、CI/CD等一系列技术栈，甚至开始画出服务间调用关系图，这固然展现了技术知识，但这是架构师的工作，不是TPM的全部。这并非TPM在银行场景下最核心的考量。正确的回答，不是一味炫耀技术栈，而是将重点放在如何“管理”这场技术转型——不是单纯的技术迁移，而是业务连续性、数据安全、合规性、成本控制以及跨团队协作的“程序”管理。
你会讨论如何识别并缓解迁移过程中的关键技术风险（如数据一致性、回滚策略），如何与合规团队协商安全审计流程，如何协调多个业务部门和技术团队（例如核心系统团队、网络安全团队、开发团队）的资源与依赖，以及如何定义成功的指标，确保在不影响银行日常运营的前提下，逐步、可控地实现技术愿景。你的技术深度体现在你能预判并拆解技术难题，而不是亲自解决每一个技术细节。你的管理广度体现在你能将这些技术挑战转化为可执行的计划，并推动多方协作。
在一次内部Debrief会议中，一位资深招聘经理曾明确指出：“我们需要的TPM，不是一个能写出完美代码的工程师，也不是一个只会跟踪进度的PM。我们寻找的是那种能在技术方案初期就能预见潜在的系统级风险，并能与工程团队一起制定规避策略的人；是能在多个互不关联的项目之间，识别并管理关键技术依赖，避免‘惊喜’发生的人。
他们必须具备将高层战略转化为具体技术实现路径的能力，同时对银行内部的IT治理、风险控制和监管要求有深刻的认知。不是单纯的技术能力，而是将技术能力与银行特有的运行机制相结合的‘技术交付领导力’。”这表明，ICICI Bank的TPM，其职责是确保技术投资能够安全、高效地转化为业务价值，尤其是在一个对稳定性和安全性要求极高的金融环境中。
因此，你的技术能力体现在你能够与架构师和工程师进行有效对话，挑战技术方案的合理性、可扩展性和安全性，而不是盲目接受或直接设计。你的管理能力体现在你能够将这些技术对话转化为清晰的项目计划、风险矩阵和沟通策略，并在复杂的组织结构中推动决策和执行。
不是仅仅理解技术，而是利用技术洞察力来驱动复杂的项目和程序。不是仅仅管理项目，而是通过对技术的深刻理解来提升项目成功的可能性。
如何在系统设计轮展现你的技术深度？
在ICICI Bank的TPM面试中，系统设计轮绝不是让你充当架构师，画出最复杂的分布式系统图谱。绝大多数候选人会误以为这是一个纯粹的技术竞赛，试图展示他们对最新的云服务、微服务架构或大数据技术的掌握，但这是错误的判断。
ICICI Bank的考察重点，不是你对技术方案细节的完美设计，而是你作为TPM，在技术挑战面前，如何进行“权衡取舍”（Trade-off Analysis）并推动技术决策的能力。
设想一个场景：面试官要求你设计一个高并发、低延迟的支付网关。一个常见的错误是，候选人会立刻跳入技术细节，讨论消息队列的选型（Kafka vs RabbitMQ）、数据库的读写分离、缓存策略（Redis），甚至开始画出具体的API接口设计。这无疑展示了技术知识，但它忽略了TPM的核心职责：管理整个设计过程中的非功能性需求、风险和依赖。正确的做法，不是直接给出技术方案，而是首先澄清需求，尤其是那些隐藏在背后的业务目标和非功能性约束——例如，这个支付网关需要支持多少QPS？
单笔交易的延迟上限是多少？数据一致性模型要求什么级别？是否有特定的地域性合规要求？你甚至需要主动询问，是否有现有的基础设施限制，或者与哪些遗留系统必须集成。
接着，在阐述技术方案时，你不是提供一个单一的“最优解”，而是提出几种可能的架构选项，并对每种选项的优缺点进行深入的权衡分析。例如，在选择消息队列时，你可能会对比Kafka在高吞吐量下的优势与其复杂性，以及RabbitMQ在易用性上的考量，并结合银行场景下对消息可靠性和事务性的要求进行判断。你会讨论每种方案对成本、维护性、扩展性、安全性和合规性的影响。
你的技术深度体现在你理解这些技术选择背后的工程原理，并能预测它们在银行特定环境下的潜在问题。例如，当讨论数据存储时，不是仅仅说“用NoSQL”，而是能进一步探讨在强一致性要求下，如何平衡NoSQL的扩展性优势与关系型数据库的事务保障。
在一次与工程总监的面试中，他曾提出一个关于“如何确保支付交易的幂等性”的问题。一位优秀的TPM候选人，不是直接给出Redis锁或数据库唯一索引的方案，而是首先询问：“这个支付网关会处理哪些类型的交易？是否有跨银行、跨地域的复杂场景？我们对失败重试的策略是什么？
”然后，他会提出多种幂等性保障机制，并讨论每种机制在不同场景下的适用性、实现成本和潜在的性能影响。他甚至会主动提出，在银行环境中，幂等性不仅是技术问题，也涉及到账务核对和审计流程，需要与业务和风控团队紧密协作。这展示的不是简单的技术知识，而是将技术问题置于更广阔的业务和组织框架中进行思考的能力。
因此，系统设计轮的裁决标准是：你是否能像一位高级工程师一样理解技术原理，又像一位战略家一样进行权衡和决策。不是盲目地追求最新技术，而是选择最适合银行当前环境和未来发展路径的技术。不是简单地堆砌技术组件，而是能够清晰地阐述你的设计选择背后的理由，并预判其带来的挑战和机遇。
跨部门协作，你的影响力边界在哪里？
在ICICI Bank这样的庞大金融机构中，TPM的日常工作充斥着复杂的跨部门协作。你的影响力边界，不是由你的职级或头衔决定，而是由你驱动共识、解决冲突和推动决策的能力所界定。绝大多数候选人在这里会犯一个根本性错误：他们将“影响力”等同于“权威”，或者将“协作”等同于“顺从”。
这并非ICICI Bank对TPM的期望。正确的判断是，TPM的影响力源于你的技术洞察力、对业务目标的深刻理解以及你构建信任关系的能力，而非任何形式的直接命令。
考虑一个典型的场景：你负责一个跨业务线的新产品发布，该产品涉及到核心银行系统、风险管理、合规、市场营销和多个技术团队。在项目推进过程中，核心银行系统团队提出由于现有负载过高，无法在预定时间内支持新产品的某个关键功能。一个糟糕的TPM，可能会直接向管理层抱怨，或者试图强行要求核心系统团队加班。这不仅会造成团队间的摩擦，还会损害你的长期影响力。
正确的TPM，不是直接施压，而是首先深入了解核心系统团队的实际困难——是资源不足？是技术瓶颈？还是与其他更紧急的项目存在优先级冲突？
接着，你会利用你的技术背景和对业务目标的理解，主动与核心系统团队一起探讨替代方案：例如，是否可以采用某种中间件或API网关来解耦依赖，或者是否可以分阶段发布功能，将高负载功能延迟到第二阶段？你甚至会主动与业务团队沟通，解释技术瓶颈，并提出调整产品发布策略的建议。你不是简单地传递问题，而是带着解决方案和权衡选项去沟通。在一次ICICI Bank的资深TPM面试中，面试官提问：“如果你需要获取一个关键数据接口的访问权限，但数据团队认为风险过高，你会怎么做？
”一位优秀的候选人回答说，他会主动与数据团队的负责人预约会议，而不是通过邮件往来。在会议中，他会清晰地阐述获取该数据的业务价值，然后提出具体的风险缓解措施，例如数据脱敏、最小权限原则、访问日志审计机制，并邀请数据安全专家参与方案讨论。他甚至会主动提出，可以协助数据团队完成相关的安全评估文档，以加速流程。这展示了，TPM的影响力不是基于命令，而是基于专业、信任和主动解决问题的意愿。
在一次内部高管季度复盘会议上，VP曾强调：“我们的TPM，必须是团队间的‘胶水’和‘翻译机’。他们需要能够将业务需求翻译成技术语言，将技术限制翻译成业务可理解的风险和权衡。当不同的团队因为目标不一致而产生冲突时，TPM不是去站队，而是通过清晰的数据和逻辑，引导大家回归共同的业务目标，并找到符合银行整体利益的解决方案。
不是仅仅管理流程，而是通过建立人际网络和专业信任，来管理‘人’和‘共识’。”这揭示了TPM在银行内部的独特价值：作为非直接管理者的领导者，其影响力主要来自其沟通协调、问题解决和策略制定能力。
因此，你的影响力边界，不是你命令别人做什么，而是你如何通过清晰的沟通、深入的分析和建设性的解决方案，引导不同的团队达成共识并共同推动项目。不是仅仅被动地接受冲突，而是主动地预测并解决冲突。不是等待别人给你资源，而是通过展现价值和构建信任来争取资源。
风险管理与优先级，银行场景的特殊考量是什么？
ICICI Bank作为一家受严格监管的金融机构，其风险管理和优先级排序具有与一般科技公司截然不同的特殊性。绝大多数候选人，在回答相关问题时，会错误地沿用互联网公司的风险模型和优先级框架，例如仅仅强调技术故障或用户体验，而忽略了银行环境中最为关键的合规、安全和声誉风险。这并非ICICI Bank所期望的。
正确的判断是，银行的风险管理，首先是“生命线”管理，其次才是效率优化；优先级排序，首先是“合规红线”，其次才是业务价值。
设想一个场景：你负责一个旨在提升移动银行App用户体验的新功能开发。在测试阶段，发现了一个潜在的边缘情况bug，可能导致极少数用户在特定操作序列下，看到错误的账户余额显示，但并不会造成资金损失。一个常见的错误反应是，评估其影响用户体验的程度，并根据用户数量和修复成本来决定优先级。在互联网公司，这可能是一个中低优先级的bug。
但在ICICI Bank，正确的判断是，即使不会造成资金损失，任何与“账户余额”相关的显示错误，都可能触及“合规性”和“客户信任”的底线。这不仅仅是一个技术bug，更是一个潜在的“声誉风险”和“监管风险”。因此，它的优先级会被立即提升到最高。
在银行环境中，TPM在风险管理上，不是仅仅识别技术风险，而是要将技术风险与“业务风险”、“合规风险”、“声誉风险”和“操作风险”相结合进行评估。当你在管理一个项目时，你不仅仅需要关注项目进度、预算和资源，更需要持续评估其对银行核心运营稳定性、数据隐私、反洗钱（AML）、了解你的客户（KYC）等合规要求的影响。在一次内部风险委员会的TPM汇报中，一位TPM在讨论一个新产品的功能时，主动提出了“如果该功能被滥用，是否存在洗钱风险？
我们需要在产品设计初期就与风控团队紧密合作，嵌入反欺诈机制。”这展示了其对银行特殊风险的深刻理解。
对于优先级排序，ICICI Bank的TPM不是简单地依据业务价值或投入产出比来决定。首先，任何触及合规红线、可能导致监管罚款、损害客户信任或引发重大系统不稳定的项目或任务，都拥有最高优先级。其次，才是那些能够带来显著业务增长、提升客户满意度或优化运营效率的项目。在银行的日常运营中，你可能会发现，一个看似简单的系统维护任务，如果被标记为“监管要求”，其优先级会瞬间超越一个高ROI的新功能开发。
TPM需要具备这种洞察力，能够区分“重要”和“紧急”在银行语境下的独特含义。不是仅仅关注技术债务，而是将技术债务的清理与潜在的合规风险绑定。不是仅仅评估用户影响，而是将用户影响与声誉风险和监管风险联系起来。
因此，ICICI Bank的TPM在风险管理和优先级排序上的裁决标准是：你是否能将银行的“生命线”——合规、安全、信任——置于所有决策的核心。你不是一个纯粹的效率优化者，而是一个风险的守护者和合规的推动者。你对风险的识别和对优先级的判断，必须超越单纯的技术或业务视角，融入银行特有的运营哲学。
薪资谈判：ICICI Bank TPM的真实价值几何？
谈论ICICI Bank的TPM薪资，绝大多数候选人会犯一个错误：他们只是简单地将自己过去的薪资期望或互联网公司的薪资水平套用过来，未能理解银行对TPM价值评估的独特维度。这并非ICICI Bank的薪酬哲学。
正确的判断是，ICICI Bank对TPM的薪资结构，在基础薪资之外，更强调与项目交付、业务绩效及风险控制挂钩的浮动奖金，以及在资深职位上可能出现的长期激励计划。你的真实价值，不是由你纯粹的技术能力决定，而是由你在银行复杂、高风险环境中，成功驱动技术项目交付的能力所衡量。
对于一个在ICICI Bank有5-8年经验的资深TPM，其总包（Total Compensation）通常会落在每年INR 30-60 lakhs之间。具体拆解如下：
- 基础薪资 (Base Salary)：通常在INR 25-45 lakhs之间。这部分薪资取决于你的经验、过往业绩以及面试中展现出的综合能力。ICICI Bank在基础薪资上，会参照市场中同级别科技人才的水平，但也会考虑银行内部的薪酬体系和职级结构。
- 绩效奖金 (Performance Bonus)：通常占基础薪资的10%-20%。这部分是浮动的，与你的个人绩效、你所负责项目的成功交付情况、以及银行整体的年度业绩紧密挂钩。在银行，项目的成功交付不仅仅是上线，更重要的是其在上线后是否稳定运行、是否满足合规要求、是否真正带来了业务价值。
- 长期激励/RSU (Long-term Incentives/RSU)：在资深或管理层TPM职位上，可能会有少量的长期激励计划，但通常不像硅谷科技公司那样以股票（RSU）为主。如果存在，其价值通常占基础薪资的5%-10%，可能以绩效挂钩的现金奖励、或绑定银行内部特定目标达成度的形式发放。这部分的设计旨在鼓励TPM关注项目的长期影响和银行的整体发展。
在薪资谈判中，绝大多数候选人会过于关注基础薪资。但正确的策略是，不是只盯着Base，而是要突出你在驱动复杂技术项目、降低风险、确保合规性方面的过往成就，以此来影响你的总包。
例如，如果你曾成功领导一个涉及多部门、高风险的核心系统升级项目，并能用具体数据（如项目提前上线X周，避免了Y百万美元的潜在罚款，提升了Z%的系统稳定性）来量化你的贡献，这将极大地增强你的谈判筹码。你甚至可以讨论你如何通过技术方案优化，帮助银行节省了运营成本，或者如何通过创新技术提升了客户体验，带来了新的业务增长点。
在一次与ICICI Bank招聘负责人沟通时，他明确指出：“我们对TPM的薪资，反映的是他们为银行带来的‘价值保障’和‘增长驱动’。一个能够有效管理大规模技术风险，确保关键系统稳定运行的TPM，其价值远高于一个仅仅按时完成任务的PM。一个能够识别技术趋势并将其转化为银行创新产品的TPM，其增长潜力也更大。
不是仅仅看你过去拿了多少钱，而是看你如何在面试中证明你能为ICICI Bank创造多少价值，尤其是在我们这个对稳定性和创新都有极高要求的行业里。”这表明，ICICI Bank的薪酬体系，是对你在银行这个特殊生态系统中，技术领导力和项目交付能力的综合认可。
因此，薪资谈判的裁决是：你不是在谈一个普通的IT项目经理的薪水，而是在为一位在印度领先银行中，负责关键技术战略实施和风险控制的复合型人才争取价值。不是简单地提出数字，而是用你过往在银行或类似高风险行业中，成功管理复杂技术项目、规避重大风险、驱动业务增长的具体案例，来支撑你的薪资要求。
准备清单
- 深入研究ICICI Bank的最新技术战略与财报：理解其在数字化转型、云原生、AI/ML、数据分析、金融科技合作等方面的投入和方向。这能帮助你将面试中的技术问题与银行的战略目标关联起来，而不是泛泛而谈。
- 精炼你的“银行级”技术项目案例：挑选1-2个你领导过的最复杂的、涉及跨部门协作、高风险、高影响力的技术项目。准备好从项目背景、你的角色、挑战、解决方案、技术细节、风险管理、合规考量、最终成果（量化数据）等多个维度进行深入阐述。
- 熟练掌握系统设计与架构原理：特别是与金融服务相关的分布式系统、高可用性、数据一致性、安全性、微服务和API设计。但重点是阐述权衡取舍，而不是仅仅罗列技术栈。系统性拆解面试结构（PM面试手册里有完整的[系统设计与金融科技场景应用]实战复盘可以参考）。
- 准备好行为面试的故事集：围绕领导力、冲突解决、影响力、风险管理、优先级排序、失败案例等主题，准备好3-5个遵循STAR原则的详细故事，并确保每个故事都能体现你在银行或类似严谨环境下的独特经验。
- 理解银行的合规与风险框架：对RBI（印度储备银行）的监管要求、数据隐私（如GDPR/印度数据保护法）、网络安全标准、反洗钱（AML）、了解你的客户（KYC）等有基本认知。这能帮助你在回答问题时，体现你对银行特殊环境的敏感度。
- 模拟面试并寻求反馈：与同行或导师进行模拟面试，特别是针对系统设计和行为面试部分。请求他们提供严厉的反馈，以识别你在技术深度、沟通清晰度以及对银行场景理解上的盲点。
- 明确你的薪资期望与价值主张：基于你对ICICI Bank薪资结构的理解，以及你自身为银行带来的价值，形成一个合理的薪资预期范围，并准备好用具体成就来支撑你的价值主张。
常见错误
- 错误：将TPM等同于纯技术架构师或纯项目经理。
BAD：在系统设计轮，候选人花费大量时间画出复杂的微服务架构图，详细讨论Docker和Kubernetes的配置，但当被问及“如何管理这个架构在银行环境中的合规性审查周期”时，却支支吾吾，无法给出具体的流程和策略。这表明他将TPM角色理解为纯粹的技术设计，而非技术交付的领导者。
GOOD：在系统设计轮，候选人提出两种不同的架构方案，并明确指出每种方案在性能、成本、维护性以及“在印度银行业务中数据主权和隐私合规”方面的权衡。他会主动提出在设计初期就引入合规和安全团队参与评审，并讨论如何通过自动化测试和审计日志来持续满足监管要求。这展示了TPM在技术与管理、效率与合规之间的平衡裁决能力。
- 错误：在行为面试中，泛泛而谈，缺乏具体数据和银行场景的特异性。
BAD：当被问及“你如何解决跨团队冲突”时，候选人回答：“我总是尝试倾听各方意见，然后找到一个折衷方案，确保大家都满意。”这种回答过于模糊，缺乏具体情境和成果，也没有体现出银行环境下对稳定性和风险控制的特殊要求。
GOOD：当被问及同一问题时，候选人会讲述一个具体案例：“在我负责的移动银行App支付模块项目中，营销团队要求尽快上线一个新功能以抢占市场，而风险管理团队则坚持需要额外两周进行全面的安全压力测试。我不是简单地折衷，而是首先组织了一场多方会议，邀请了产品、工程、风险管理以及合规部门的代表。我向营销团队展示了如果仓促上线可能导致的潜在声誉和监管风险数据（例如，如果发生数据泄露，可能面临的罚款规模）。
同时，我与工程团队和风险管理团队合作，探索是否可以并行开展部分测试，或者将功能拆解，分阶段发布核心部分。最终，我们达成共识：将核心功能提前发布，但额外增加一周进行关键安全模块的强化测试，同时延迟次要功能。这个决策不是妥协，而是基于对银行声誉和合规风险的优先考量，最终项目在控制风险的前提下，如期交付了核心价值。”
- 错误：薪资谈判时，未能突出自己在银行场景下的独特价值。
BAD：候选人在收到offer后，直接提出：“我期望的Base是40 lakhs，因为我上一份工作就拿这么多。”这种谈判方式，仅仅基于个人历史薪资，未能体现出他在ICICI Bank这个特定环境中的独特价值。
GOOD：候选人在收到offer后，首先表达对机会的感谢，然后表示：“我对这份TPM角色在ICICI Bank的战略重要性有深刻理解，尤其是在推动大规模数字化转型和确保金融级稳定性方面。我在上一家公司（某金融科技公司）成功领导了一个高并发交易系统的开发，帮助公司在X个月内实现了Y%的用户增长，并确保了Z%的系统可用性，同时在合规性方面零事故。我相信这些经验，尤其是在风险规避和复杂系统交付方面的能力，能为ICICI Bank带来显著价值。
基于我过去在类似复杂金融科技环境中的贡献，并考虑到ICICI Bank在行业内的领导地位和该岗位的职责广度，我希望我的总包能达到XX lakhs，其中包含与项目绩效和银行整体业绩挂钩的浮动奖金。”这展示了他不仅了解市场行情，更重要的是，他能用具体成就和价值贡献来支撑自己的薪资要求。
准备拿下PM Offer？
如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。
FAQ
- ICICI Bank的TPM面试，对印度本地化经验有多看重？
ICICI Bank对印度本地化经验的看重程度，是远超你想象的。这不是简单的加分项，而是几乎成为了一种“必要条件”，尤其是在合规、风控和客户行为理解方面。许多候选人会错误地认为技术能力是普适的，但印度的金融监管环境（例如RBI的各种指令）、支付基础设施（如UPI）、以及独特的客户行为模式，都要求TPM具备深厚的本地洞察力。
例如，如果你能谈论你如何在一个项目中，考虑到印度农村地区的网络连接不稳定性，设计出离线优先的移动银行解决方案，或者如何处理与Aadhaar身份验证系统的集成挑战，这将比你单纯讨论云架构更具说服力。正确的判断是，本地化经验不仅关乎技术实施，更关乎在特定市场中识别和规避风险，以及驱动业务价值的能力。
- ICICI Bank的TPM职位，未来晋升路径是走向纯管理还是技术专家？
ICICI Bank的TPM晋升路径，并非“非黑即白”地走向纯管理或技术专家，而是倾向于“技术领导力”的深化与扩展。大多数人会认为TPM最终会转为管理PMO或成为纯粹的架构师，但这是对银行内部职级体系的误解。成功的TPM，其晋升往往是向上成为资深TPM、TPM主管，甚至是技术项目总监，这意味着你不仅要管理更
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。