# 1. 学习节奏（Learning Pace）的真实工程经验 A 突击式高强度学习最有效 B 学习节奏应可持续、稳定、反馈调整，把学习变成习惯而非热情驱动 ✓ 正确答案 C 学习节奏越猛越好 D 学习节奏与持续性无关
# 2. 内部知识分享（Internal Sharing）的真实工程边界 A 分享越多越好，无需控制时间 B 内部知识分享应经验导向、文档沉淀、定期按需，控制内容价值与时间成本 ✓ 正确答案 C 分享只需讲理论 D 内部知识分享与团队无关
# 3. 年度复盘（Year Review）的真实结构 A 年度复盘只需回顾成功的事 B 年度复盘按"回顾-结果-原因-经验-规划"做，客观诚实、数据支撑、落出行动 ✓ 正确答案 C 年度复盘只需写流水账 D 年度复盘无需规划来年
# 4. GitHub Sponsors 申请的真实流程 A 申请流程含申请、完善资料、接入与运营，但成功靠项目影响力与社区认可 ✓ 正确答案 B 只要申请就能获得赞助 C 赞助收入是开源的主要收入 D 赞助与项目价值无关
# 5. 写作作为学习的真实工程价值（Learning by Writing） A 写作只是记录，不促进学习 B 写作学习是搬运 C 写不出来就说明不擅长写作 D 写作通过输出与重构加深理解、暴露盲点、沉淀知识，是主动的高层次学习 ✓ 正确答案
# 6. 学习 vs 工作的真实时间分配 A 工作与学习完全对立 B 学习应挤压所有工作时间 C 工作是最好的学习场景，应工作中学、学了用，业余学面向未来的内容，平衡精力 ✓ 正确答案 D 学习与职业目标无关
# 7. 学习投入（Learning Investment）的真实回报曲线 A 学习投入回报是线性的 B 学习投入应追求短期回报 C 平台期代表学习失败 D 学习投入回报是"初期慢、平台期、复利"的非线性，需耐心坚持并重视长期复利 ✓ 正确答案
# 8. 学习时间的机会成本（Opportunity Cost）真实评估 A 学习时间有限，应评估目标相关、长期价值与投入产出比，聚焦高价值学习 ✓ 正确答案 B 学的东西越多越好，无需取舍 C 机会成本与目标无关 D 学习无需考虑取舍
# 9. 年度学习主题（Yearly Theme）的真实选择方法 A 一年学越多主题越好 B 年度主题越空泛越好 C 年度主题应结合现状、目标、趋势与热情，聚焦可落地，分解执行并复盘 ✓ 正确答案 D 年度主题与职业规划无关
# 10. 技术博客的长期价值如何体现（品牌/机会/知识沉淀），写作投入与产出的权衡怎么评估？ A 技术博客短期就能带来回报 B 技术博客数量越多价值越大 C 技术博客长期价值在品牌、机会与知识沉淀，是长期复利，需质量优先、持续更新 ✓ 正确答案 D 技术博客与个人品牌无关
# 11. 主题完成度（Completion）的真实评估 A 完成度评估要有可衡量目标、成果导向、分阶段衡量与复盘对照 ✓ 正确答案 B 完成度凭感觉判断即可 C 投入时间多就代表完成度高 D 完成度无需验证
# 12. 学习疲劳（Learning Fatigue）的真实早期信号 A 疲劳时硬撑学习效率更高 B 疲劳只是意志力问题 C 学习疲劳信号是注意力、效率、情绪、动力与身体的变化，应及时休息、调整节奏 ✓ 正确答案 D 学习疲劳无需理会
# 13. 学习目标过载（Overload）的真实管理 A 目标越多学习效果越好 B 过载是意志力问题 C 目标过载应通过聚焦、优先级、分解与减法管理，用"少而精"替代"多而散" ✓ 正确答案 D 目标过载无需调整
# 14. CONTRIBUTING.md 如何降低外部贡献门槛（环境搭建/编码规范/提交流程），维护者如何保持其更新？ A CONTRIBUTING.md 只写项目简介 B CONTRIBUTING.md 覆盖环境搭建、编码规范、提交流程以降低门槛，并需随版本与反馈更新 ✓ 正确答案 C CONTRIBUTING.md 无需更新 D CONTRIBUTING.md 与贡献门槛无关
# 15. 基金会赞助（如 Apache/CNCF 项目）如何带来治理经验与社区背书，参与成本与回报如何评估？ A 基金会赞助没有任何成本 B 基金会赞助带来治理经验与社区背书，但需承担治理流程、时间与控制权成本，需权衡 ✓ 正确答案 C 基金会赞助会降低项目可信度 D 基金会赞助与治理无关
# 16. Good First Issue 选题的真实评估 A Good First Issue 应规模小、难度低、清晰、有引导、低风险，既是新手入门也是维护者降低门槛的设计 ✓ 正确答案 B 复杂 issue 也可作为 Good First Issue C Good First Issue 无需引导 D Good First Issue 与难度无关
# 17. Issue / PR 响应时间（Response Time）的真实基准 A 响应时间越慢越好，让贡献者耐心 B 响应时间与贡献者体验无关 C 响应时间因项目而异，但"及时首响 + 实质反馈"比快速解决更重要，让贡献者感到被认可 ✓ 正确答案 D 只需快速关闭，无需反馈
# 18. Issue 响应（Triage）的真实优先级排序 A 优先级排序看影响面、严重度、频率与成本收益，用标签、模板与跟踪高效处理 ✓ 正确答案 B 所有 Issue 优先级相同 C 越早提交的 Issue 越优先 D Triage 无需流程
# 19. PR（Pull Request）提交流程的真实工程经验 A PR 越大越好，一次提交所有改动 B PR 无需测试 C 高质量 PR 应小而有界、描述清晰、有测试，并先沟通、响应评审、迭代同步 ✓ 正确答案 D PR 提交后无需响应评审
# 20. 版本发布（Release）的真实工程经验 A 版本发布应遵循语义化版本、维护变更日志、充分测试、自动化发布，并提前沟通破坏性变更 ✓ 正确答案 B 版本发布无需变更日志 C 破坏性变更无需提前通知 D 版本发布与质量无关
# 21. 破坏性变更（Breaking Change）的真实沟通 A 破坏性变更应提前通知、弃用周期、迁移指引、版本标识，透明地帮助用户迁移 ✓ 正确答案 B 破坏性变更无需提前通知 C 破坏性变更应突然发布 D 破坏性变更与用户无关
# 22. 贡献者多样性（Diversity）的真实评估 A 多样性评估看构成、贡献类型、参与分布与新贡献者，提升靠降低门槛、包容与多样贡献路径 ✓ 正确答案 B 多样性只看贡献者数量 C 多样性只指代码贡献者 D 多样性无法提升
# 23. 项目活跃度（Activity）的真实衡量指标 A Star 多就代表项目活跃 B 活跃度只看代码行数 C 活跃度看提交、发布、Issue/PR 处理与维护者活跃，避免虚荣指标，综合多指标看趋势 ✓ 正确答案 D 活跃度与维护者无关
# 24. Open Source Friday 等企业内部开源时间的真实效果 A 开源时间只是名义福利 B 开源时间能贡献生态、员工成长与品牌，需时间保证、目标边界、支持认可以及处理好知识产权 ✓ 正确答案 C 开源时间与业务无关 D 开源时间无需边界
# 25. Star、Watch、Clone 的真实意义 A Star 多代表项目活跃且好用 B Star 反映知名度、Watch 反映持续关注、Clone 反映实际使用，应区分含义并综合判断 ✓ 正确答案 C 三个指标意义相同 D Clone 反映知名度
# 26. 多维护者（Co-Maintainer）协作的真实经验 A 多维护者无需分工，共同处理即可 B 多维护者无需文档 C 多维护者冲突无法解决 D 多维护者协作靠分工、共识、决策机制、透明沟通与文档沉淀，以项目利益化解冲突 ✓ 正确答案
# 27. 维护者倦怠（Maintainer Burnout）的真实信号 A 维护者倦怠信号是动力、情绪、行为与健康变化，应对靠分担负担、设定边界、寻求支持 ✓ 正确答案 B 维护者倦怠无需处理 C 维护者倦怠是维护者自己的问题 D 倦怠只影响维护者自己
# 28. 贡献优先级（Curation）的真实沟通 A 贡献优先级沟通应明确方向、透明偏好、尊重拒绝、建设性反馈，让贡献有的放矢 ✓ 正确答案 B 维护者应拒绝所有方向外的贡献 C 拒绝贡献无需理由 D Curation 与方向无关
# 29. 贡献被拒绝（Rejection）的真实处理 A 被拒绝说明不再适合开源 B 贡献被拒应先理解原因、寻求反馈、可改进再提交、尊重决定，把拒绝当学习机会 ✓ 正确答案 C 被拒绝后应坚持强求 D 评审反馈无需理会
# 30. 采用者（Adopter）的真实识别 A 下载量就代表采用者数量 B 采用者只看 GitHub Star C 采用者应通过下载、使用证据、依赖、企业采用与生态多渠道综合识别 ✓ 正确答案 D 采用者无法识别
# 31. 商标（Trademark）转让与保护的工程边界 A 开源项目无需保护商标 B 商标与企业无关 C 商标权与代码许可相同 D 商标需用政策规范使用、防止滥用混淆、与代码许可分开、转让时合规，开源越成功越需保护 ✓ 正确答案
# 32. 治理委员会（TCC、PMC）的真实决策机制 A 委员会由一人独断决策 B 治理委员会决策通常"共识优先、投票兜底、透明记录"，需代表多方、流程明确 ✓ 正确答案 C 委员会决策无需透明 D 委员会决策与社区无关
# 33. 用户通知（User Notification）的真实工程边界 A 用户通知只需在 changelog 写一行 B 用户通知要按类型、渠道、时机、内容管理，安全与破坏性变更及时多渠道通知，内容可行动 ✓ 正确答案 C 安全漏洞应不公开 D 用户通知与发布无关
# 34. 项目归档（Archive）的真实工程流程 A 归档应直接删除项目 B 归档后可继续误导用户 C 归档无需告诉用户 D 归档应公告、设只读、标注文档、提供迁移指引、保留历史，做到透明尊重 ✓ 正确答案
# 35. 项目退出（Project Sunset）的真实决策 A 项目退出应综合权衡资源、使用、替代、热情与技术过时，诚实评估，有价值时优先交接 ✓ 正确答案 B 一旦投入就不可退出 C 项目退出无需考虑用户 D 项目退出只需一纸公告
# 36. CNCF TAG 的参与如何获得跨项目治理视野，个人在 TAG 中的贡献与收获如何评估？ A 参与 CNCF TAG 能通过会议、文档、评审获得跨项目治理视野，需评估时间投入与收获匹配 ✓ 正确答案 B TAG 参与只适合基金会 CTO C TAG 参与与个人成长无关 D TAG 是单一项目的事
# 37. 项目移交（Project Handover）的真实工程经验 A 移交只需转移代码 B 项目移交核心是知识转移与平稳过渡，靠文档交接、权限转移、过渡期与社区沟通 ✓ 正确答案 C 移交后无需支持 D 移交与社区无关
# 38. 主题深度（Deep Dive）vs 主题广度（Survey）的真实取舍 A 只需深度，无需广度 B 深度与广度按阶段与目标取舍，用"T 型"结构平衡——一个深度立足、多个广度扩展 ✓ 正确答案 C 广度永远优于深度 D 深度与广度不可兼得
# 39. 教学他人（Teaching Others）的真实学习深度 A 教学是单向付出，自己无收获 B 教学只适合记忆类知识 C 教学通过主动输出、暴露盲点、重构理解带来深层学习，是"教是最好的学" ✓ 正确答案 D 教学无法检验理解
# 40. 依赖健康（Dependency Health）的真实边界 A 依赖引入后无需维护 B 依赖越多越好 C 依赖健康应评估活跃度、安全、许可、维护者，并定期升级、监控、关键依赖冗余、慎重引入 ✓ 正确答案 D 依赖健康与安全无关
# 41. 开源维护者（Maintainer）的真实责任边界 A 维护者职责含代码、评审、治理、社区，但有权设定时间、范围与权限边界并保护自己 ✓ 正确答案 B 维护者应对用户负无限责任 C 维护者应 24/7 在线 D 维护者无权限可言
# 42. 贡献者协议（CLA、DCO）的真实签署边界 A CLA 是授权项目使用，DCO 是声明贡献权，按项目要求签署，公司员工需处理雇主授权 ✓ 正确答案 B CLA 与 DCO 完全相同 C 所有项目都用 CLA D 贡献者协议无需理解
# 43. CNCF、Apache、Linux 基金会治理的真实差异 A 三大基金会治理完全一样 B 基金会治理与参与无关 C 所有基金会都用 Linux 内核模式 D CNCF 用 SIG/TAG、Apache 用 PMC 共识、LF 用 maintainer 分层，治理模式与文化不同 ✓ 正确答案
# 44. 维护者退出（Maintainer Exit）的真实过渡 A 退出应直接消失，无需交接 B 退出后项目无需延续 C 维护者退出应提前沟通、交接角色、知识转移、过渡期与权限处理，负责地平稳过渡 ✓ 正确答案 D 退出无需知识转移
# 45. 项目毕业（Graduation）的真实标准 A 毕业只需代码量大 B 毕业标准只有一条 C 毕业是终点，无需再维护 D 项目毕业需满足采用、社区、治理、可持续、质量与合规等标准，是成熟与背书的标志 ✓ 正确答案
# 46. 下载量（Download）真实使用与解读边界 A 下载量是最精确的使用指标 B 下载量反映使用规模与趋势，但"下载≠使用"、可刷、口径有差异，需结合多信号看趋势 ✓ 正确答案 C 下载量一定真实 D 下载量无需结合其他信号
# 47. 维护者继承（Succession）的真实边界 A 继承只有在维护者离开时才考虑 B 继承人选随便选即可 C 维护者继承应主动培养接班人、扩大维护者池、交接规划，确保项目不依赖单点 ✓ 正确答案 D 继承无需知识沉淀
# 48. 维护者激励（Maintainer Incentive）的真实边界 A 维护者只靠情怀就能持续 B 激励不足维护者也会坚持 C 维护者激励是认可、成长、职业价值、社区与赞助的多元组合，需多元、尊重、可持续 ✓ 正确答案 D 维护者激励只有金钱
# 49. 治理冲突（Governance Conflict）的真实处理 A 冲突只能靠强权解决 B 冲突无需记录 C 冲突应私下解决 D 治理冲突应沟通优先、机制解决、仲裁兜底、对事不对人、公正透明，建设性化解 ✓ 正确答案
# 50. 治理结构（Governance Structure）的真实演进 A 治理结构一旦确定就不变 B 治理演进无需共识 C 治理越复杂越好 D 治理结构随项目规模演进，从个人到委员会、松散到规范，需适配阶段、渐进、透明 ✓ 正确答案
# 51. 退出公告（Sunset Notice）的真实结构 A 退出公告只需一句话 B 退出公告只需告知停止 C 退出公告无需说明原因 D 退出公告应含声明、原因、影响、时间表、迁移指引与感谢，透明、清晰、可行动 ✓ 正确答案
# 52. Apache 项目孵化的提案、导师与毕业评估流程是怎样的，个人参与的价值与投入如何评估？ A Apache 孵化只需提交代码 B Apache 孵化无需导师 C Apache 孵化流程是提案、导师、孵化、毕业评估，个人参与价值在治理经验与背书，需评估投入 ✓ 正确答案 D 孵化毕业只需代码量大
# 53. 退出与社区信任（Trust）的真实关系 A 负责的退出（透明、交接、善后）维护信任，突然消失损害信任，退出要当作项目延续的规划 ✓ 正确答案 B 退出必然损害信任 C 退出方式与信任无关 D 退出后无需善后
