能力域 G
学习适应与持续成长
面对未知、反馈与挫折，能力如何发生可验证的变化。
查看这个能力域如何映射到阶段要求。 打开能力模型
先选一项能力。每类只预览三题，进入后按考察重点分批阅读；预览不代表重要性排名。
97 道问题 · 4 项能力
学习迁移19
把一个领域学到的东西用到新问题上。
- 你需要在两周内接手一个没有文档、原负责人已离开的结算流程。你会怎样搭建学习路径、控制误操作风险并确认自己能独立处理？
- 你完成了系统学习，但项目中的判断方式和结果没有变化。你会如何判断问题出在练习、反馈还是应用场景？
- 一次移动端版本在特定机型上出现崩溃，你参与了修复。之后会如何把这次经验迁移到测试和发布流程？
- 新的移动系统版本改变了后台运行限制，你读过文档但还没有在产品中应用。你会如何验证自己掌握了变化？
- 你曾定位一个后台任务导致的耗电问题，团队希望将经验用于其他功能。你会如何提炼可复用的方法并避免机械照搬？
- 你从单一移动平台转到多平台项目，已有经验部分适用，部分可能造成错误假设。你会如何学习和验证？
- 一次移动应用辅助功能评审发现屏幕阅读器和动态字体问题。你会如何让这些经验影响今后的实现？
- 你学习了一款新的移动性能分析工具，想判断它是否比现有方法更快、更准确。你会如何验证？
- 一次研究发现用户在表单中常误解状态提示。你会如何判断这是局部问题还是可迁移的设计原则？
- 你从消费产品转到企业软件，用户角色、购买者和使用场景都不同。你会如何调整已有访谈方法？
- 那次失败给你留下了什么对未来有用的经验？之后在哪个项目里用上了，效果怎样？
- 团队完成了新的安全培训，考试通过率接近 100%，但敏感配置错误仍持续发生。你会如何检查培训是否迁移到实际操作并决定改进方式？
- 你接手一个陌生的合规产品领域，需要三个月内参与路线图决策。你会如何选择学习材料、实践任务和反馈来源？
- 你学习了一种新的分析或交付方法，并开始在项目中使用。你会怎样判断它真的改善结果，而不只是让自己更有把握？
- 你过去依赖的一套需求评审流程曾经很有效，但业务节奏变快后，它开始延误小型改动。你会怎样区分方法中的核心原则和已经不合时宜的步骤，并验证调整结果？
- 从一个项目里提炼出的方法，你后来在哪个很不一样的问题上又用到了？这次用法和第一次有什么不同？
- 你学会了一种新的故障复盘方法，想推广给团队。除了做一次分享，你会怎样设计练习和后续观察，判断大家是否能在真实事故中正确使用？
- 讲一次你面对完全陌生的领域的经历。你怎样建立知识地图，又怎样验证自己真的会用了，而不只是看过？
- 你在前一家公司学会了高效的交付方法，但当前团队使用不同技术、合规要求和协作节奏。你会如何判断哪些部分可迁移？
当前目标在这里暂无匹配题。 ·
结构化复盘28
用事实、判断、行动与结果检查自己。
- 你考虑从核心产品研发转到可靠性工程岗位，以拓宽技术影响范围，但短期内不会改变职级。你会如何确定这次横向转变的学习目标和判断是否成功的证据？
- 晋升反馈认为你的工作质量可靠，但影响仍局限在个人交付。你如何把这条反馈转成下一阶段的尝试，并判断自己是否真的扩大了影响？
- 一次高风险决策取得了好结果，但关键假设后来被证伪，成功部分依靠偶然。你会如何复盘并改变下次决策？
- 你优化了启动流程后，启动时间指标改善，但同期还上线了缓存和服务端变化。你会如何复盘个人方案的影响？
- 应用商店审核拒绝了新版本，团队认为规则不清且上线计划受影响。你会如何复盘准备、沟通和验证流程？
- 你参与设计离线缓存，离线成功率提升但同步冲突和客服咨询增加。你会如何复盘方案并决定后续？
- 同类旧版本兼容问题再次发生，之前复盘已增加测试但仍漏掉实际用户组合。你会如何检查此前的改进措施为何没有奏效？
- 小范围发布阶段的崩溃率略有上升，但团队继续扩大用户范围，随后出现大范围投诉。你会如何复盘当时的判断？
- 原型测试反馈积极，但功能上线后实际使用率很低。你会如何检查研究情境、招募样本、产品实现和上线条件之间的差异？
- 团队完成了多个视觉方案，但用户核心任务仍无法顺畅完成。你会如何判断探索方向、问题定义或验证方式哪里出了偏差？
- 新设计系统发布后，各产品团队仍保留旧组件，理由包括灵活性不足和迁移成本。你会如何复盘推广方式？
- 产品上线后发现低视力用户无法完成关键任务，原研究招募未覆盖这类人群。你会如何复盘研究决策并修正流程？
- 评审中收到了很多建议，团队全部采纳后界面更加复杂，但没有重新验证用户任务。你会如何复盘反馈处理？
- 成员完成学习目标并获得证书，但在项目中的独立处理能力没有提升。你会如何复盘目标设计？
- 你制定了一个季度学习计划并按时完成课程，但实际工作中仍需要他人帮助。你会如何判断计划哪里脱离了工作需要？
- 那个失败的项目，在什么条件下有可能成功？这些条件当时能不能得到，你现在会怎么设计才有更大的成功可能？
- 做复盘时，你怎样避免避重就轻、替换定义，或把事实说得比实际更好？
- 复盘里提出的改进，后来真的被执行了吗？每一项改进有没有负责人、时间点和验证的方式？没有执行的，原因是什么？
- 讲一次你的判断被事实推翻的经历。当时哪些判断是合理的，哪些信号被忽略了，之后你具体改变了什么？
- 选一个你最近完成的项目做复盘：原先想达成什么，实际发生了什么，下一次你会保留、改变或停止什么？
- 说一件你做错的事。你怎么看待它：它给你留下的是一条经验、一项收益，还是只是个教训？之后哪一次具体行为真的不一样了？
- 一次部署差点将敏感数据写入公开日志，但自动检查阻止了发布，没有客户受到影响。有人认为没有事故就不需要复盘。你会如何处理？
- 说一个没有成功的项目，它为什么失败？哪些原因是直接的，哪些是更根本的，其中有多少和你自己的判断有关？
- 如果用同样的资源把这个项目重做一次，你会怎么做？会得到更多收益，还是更早止损？
- 团队准确找到了事故根因，也记录了改进建议，但几个月后操作习惯没有变化。你会如何评价复盘是否成功？
- 一次项目因市场需求不足而取消，团队积累的技术能力仍可复用。你会如何决定保留、迁移或停止相关投入？
- 你根据复盘改了代码审查方式，团队缺陷率暂时持平。你会如何判断改变是否有效、样本是否足够或机制是否错误？
- 你多次低估工作量，团队最终加班完成，因此项目表面上没有延期。你会怎样还原预测误差及其隐性成本？
当前目标在这里暂无匹配题。 ·
韧性与恢复26
挫折之后如何求助、恢复并继续改进。
- 你在客户演示中展示了过期数据，客户据此质疑团队的报告可信度。你会如何处理当下影响、修复信任并恢复工作的节奏？
- 一个发布周期结束后你发现自己开始漏看细节、睡眠变差，团队也把临时加班当成常态。你会怎样恢复并判断需要个人调整还是组织改变？
- 你连续三次依靠逐个催办推动跨团队任务，结果每次短暂改善后又回到原状。你如何判断是执行力度不足还是方法本身不合适，并选择下一步？
- 你负责的移动版本发布后导致部分用户无法启动应用，团队正在回滚。你会如何在高压下恢复、沟通并继续改进？
- 移动平台突然调整权限政策，团队已投入的方案无法按原计划发布。你会如何应对挫折并重新规划？
- 连续两个版本被应用商店审核阻塞，团队成员感到努力没有回报。你会如何恢复节奏并找到可控的下一步？
- 移动应用在少数设备上反复出现问题，团队开始依赖临时加班验证。你会如何恢复可持续的处理方式？
- 你决定跳过一项移动端兼容验证，发布后造成回归。问题已修复，但你对后续决策变得过度谨慎。你会如何恢复？
- 招募合作方临时取消研究，团队仍需对关键体验做决定。你会如何处理失望并找到可靠替代证据？
- 重要评审否决了你投入数周的设计方向，理由是用户证据不足。你会如何消化反馈并决定接下来的探索？
- 你负责的项目未能达到目标，投入已经结束，相关团队对后续方向失去信心。你会如何恢复工作并推动下一步？
- 你负责的问题经过几次尝试仍未解决，时间压力和挫败感都在增加。你会如何调整行动、寻求支持并判断下一步？
- 你发现自己连续几周只能靠加班维持交付，质量尚未明显下降，但已经开始回避复杂任务。你会怎样判断何时求助以及需要什么支持？
- 一次复盘中你收到很尖锐但包含事实的批评，情绪尚未恢复，第二天还要同一批人共同交付。你会怎样处理反馈与合作？
- 你投入几个月准备的一次技术方案评审被拒绝，反馈只有“还不够成熟”，也没有明确改进路径。你会怎样继续推进自己的判断？
- 你连续数周在高优先级任务间切换，原定工作不断被打断，重要事项开始遗漏。你会怎样恢复可持续的推进方式？
- 你带领团队推进的方向因公司战略调整被整体取消，之前的成果短期内无法继续使用。你会怎样消化变化并重建下一步的工作节奏？
- 面试官直接质疑你的成果，说它主要是运气，或者主要是团队其他人的功劳。你怎么回应？
- 回想一次你的方案被否定或事情没做成的时候。你怎样把事实、解释和情绪分开，又是在什么时候向别人求助的？
- 面试中遇到一道没准备过的题，你一时卡住了。接下来你会怎么做？
- 一段高压期持续了好几周。你怎样判断自己该坚持，还是已经在无效消耗，并据此调整？
- 你连续两次提出的方案都被关键决策者否决，团队已经开始质疑你的判断。你会怎样复盘两次结果、决定是否继续推动这个问题，并恢复团队对下一步工作的信心？
- 一位成员每次都能在危机中顶住并交付，但恢复时间越来越长，日常错误开始增加。你会如何回应？
- 你推动的方案已被多个团队采用，随后发现关键假设不成立，继续执行会增加返工。你会怎样及时纠正？
- 你长期在复杂项目中表现良好，一次公开失误后开始只选确定性高的任务。你会如何恢复判断并逐步重建信心？
- 团队经历多周故障和夜间值班，你仍需要决定一次数据迁移是否执行。你会怎样管理疲劳、寻求复核并调整决策边界？
当前目标在这里暂无匹配题。 ·
自驱24
没人要求时如何设定目标并持续推进。
- 你被邀请承担带人职责，但最有成就感的工作仍是解决复杂技术问题。你会用什么事实判断该尝试管理、继续专家路径，或先做一段有限授权的实验？
- 你发现一个内部流程可以自动化，但团队本季度已有明确承诺。你会怎样验证潜在价值、估计维护成本，并决定是提出试点、等待还是放弃？
- 新岗位没有清晰的前三个月目标，团队也忙于日常工作。你会如何发现最值得负责的问题并与主管校准？
- 你设定了长期能力目标，但日常紧急任务总把学习和改进挤掉。你会如何设计可持续的推进机制？
- 团队近期多次被旧系统兼容问题拖慢，但没人负责改进。你会如何决定是否投入时间并推动学习？
- 移动平台的隐私权限与审核要求持续变化，团队没有固定培训。你会如何安排持续学习并及时应用？
- 团队没有明确的无障碍改造项目，但你发现常用流程对动态字体用户不友好。你会如何判断并推动改进？
- 你对跨端框架感兴趣，但现有产品未必需要迁移。你会如何决定学习投入并判断是否值得应用？
- 产品路线图没有安排体验改进，你从用户反馈中发现某个流程长期困惑。你会如何决定是否主动探索？
- 团队计划进入新的用户群，暂时没有研究资源。你负责设计，但不想直接套用现有模式。你会如何开始？
- 你每季度都会学习新技术，但同事不清楚这些投入如何改善团队工作。你会如何调整学习选择？
- 项目因一个外部依赖反复受阻，却没有明确负责人。你可以推动调查，但没有权限代表对方作决定。你会如何行动？
- 团队很少进行正式绩效反馈，你不确定过去半年是否提升了独立解决问题的能力。你会如何自我校准？
- 你提出一项能减少团队手工工作的改进，但日常交付已很满。你会如何安排推进节奏？
- 同一周内，客户支持要求你修一个不稳定问题，直属负责人希望你完成已承诺的功能，另一个团队邀请你参加一个可能减少后续返工的评审。你会怎样决定先做什么，并让未被满足的人理解你的选择？
- 你的职责没有变化，但新增了临时请求、例行维护和长期改进目标，全部完成已不现实。你会怎样定义个人工作预算并让相关方知情？
- 制定下一个周期的目标时，你觉得最难的是什么？你怎样让目标变成可以检查的行动？
- 你发现一个长期没人跟进的维护问题：它还没有造成事故，但修复需要数天，短期内也不容易展示成果。你会怎样判断是否投入时间、如何争取空间，以及怎样设定停止或升级条件？
- 没有人要求的时候，你最近主动设定并推进了一个什么目标？你是怎么判断它值得投入的？
- 你负责改善内部数据质量，目前没有统一的缺陷数量或比例作为起点，业务也没有要求具体指标；但错误正在影响几个下游团队。你会如何定义目标和验证进展？
- 组织没有明确的晋升时间表，你仍希望持续成长。你会如何选择学习、影响力和交付目标，避免只追逐可见度？
- 加入一个远程团队后，你的工作很少被直接观察，难以知道能力提升是否有效。你会怎样为自己建立反馈机制？
- 工作内容已经熟练但组织暂时没有新岗位，你希望继续成长又不能忽略当前责任。会怎样设计下一阶段？
- 你已经能稳定完成当前职责，但经理没有给出下一职级的具体要求。你会怎样收集证据、选择挑战并校准进步？
当前目标在这里暂无匹配题。 ·