# 1. 开源贡献对职业发展的真实价值（技能提升、行业可见度、求职信号）如何量化？ A 开源贡献的技能提升价值无法评估，只能靠自我感觉 B 行业可见度只对少数顶级贡献者有意义 C 求职信号价值在于提供可被面试官公开验证的成果证据，而非仅靠自述 ✓ 正确答案 D 开源贡献的回报周期在所有维度上都是即时的
# 2. 从"用开源"到"贡献开源"的第一步应如何迈出——Good First Issue 的真实评估 A 先在自己真正使用的项目上跑通环境、读 CONTRIBUTING 并挑选质量合格的 Good First Issue，是靠谱的第一步 ✓ 正确答案 B 应该优先选择 star 最多的项目提交第一个 PR C Good First Issue 一定简单，不需要维护者配合 D 贡献数量越多就越能证明能力
# 3. 相比修 bug，文档、测试、issue 治理与社区运营类开源贡献对个人品牌与协作能力的杠杆如何评估与选择？ A 文档、测试与 issue 治理类贡献常能以较小投入换取更高的可见度与协作能力提升 ✓ 正确答案 B 只有核心代码贡献才对职业发展有杠杆 C 修 bug 数量是衡量社区影响力的唯一标准 D 社区运营贡献无法被量化，因此不值得投入
# 4. 如何平衡开源贡献与本职工作——时间分配、精力边界、知识产权风险 A 开源贡献越多越好，可以挤占主业时间 B 只要不写公司代码就完全没有知识产权风险 C 应主业优先，固定时段投入并严格控制精力边界，同时核对公司政策与许可证规避知识产权风险 ✓ 正确答案 D 参与开源一定会违反竞业限制
# 5. 从 Contributor 到 Committer/Maintainer 的真实路径与能力要求 A 只要提交大量 PR 就能自动晋升为维护者 B 维护者只需要会写代码，不需要沟通能力 C 晋升本质是信任积累与治理能力证明，需持续参与 review 和社区治理，而非单纯堆代码量 ✓ 正确答案 D 评审他人代码不会影响晋升机会
# 6. 开源项目的"健康度评估"（贡献者多样性、响应速度、治理成熟度）如何影响个人参与决策？ A 健康度只影响项目本身，不影响个人投入价值 B 响应速度慢说明项目很严谨，更值得投入 C 贡献者多样性、响应速度与治理成熟度共同决定投入的安全性与回报率，应优先投入健康项目 ✓ 正确答案 D 只有 star 数量决定是否值得参与
# 7. 从"用开源"到"提交第一个 PR"的完整路径如何走，怎么选项目、读源码、找 good-first-issue？ A 应该从头到尾通读整个项目源码再动手 B 先选真正在使用且健康度达标的项目，再定向读源码、评估 good-first-issue，跑通测试后提交，是完整靠谱的路径 ✓ 正确答案 C 任意找 star 多的项目提交代码即可 D 提交 PR 不需要读 CONTRIBUTING 文档
# 8. 开源贡献从一次性 PR 到 maintainer 的长期投入与回报如何评估？ A 开源贡献是单次交易，没有复利效应 B 投入越多回报必然越大 C 长期投入一定会有回报，不需要评估 D 要从一次性 PR 经持续贡献再到维护者分阶段投入，并多元化评估回报和设置止损点 ✓ 正确答案
# 9. 开源贡献从文档修复、issue 响应到核心模块维护的进阶路径中，如何选择项目与积累信任？ A 应该一开始就挑战核心模块以证明能力 B 信任只靠代码质量，与 issue 响应无关 C 应按文档、issue、测试到核心模块的由低到高风险顺序，每步积累信任后再进阶 ✓ 正确答案 D 文档修复贡献没有任何价值
# 10. 如何把设计评审参与、大型 feature、性能优化等开源贡献转化为面试中可验证的系统设计能力证据？ A 应把贡献类型映射到能力标签，用可点击的 PR、设计文档与 benchmark 数据作为可验证证据，并诚实区分主导与参与 ✓ 正确答案 B 只要说"我参与过开源项目"就够了 C 性能优化贡献不需要出示数据 D 面试中夸大主导角色更有利
# 11. 如何把开源贡献转化为简历与面试中的具体能力证据？ A 简历里写清楚"开源贡献者"即可 B 掩饰真实角色可以让简历更好看 C 应以项目条目写明负责模块、量化结果并附可点击链接，面试用 STAR 结构配合现场演示 ✓ 正确答案 D 贡献数量越多，能力证据越强
# 12. 开源贡献如何转化为面试与职业加分项（可验证的成果证据）？ A 只要贡献数量多就能加分 B 贡献与岗位无关也能加分 C 开源贡献只能写在简历底部作为补充 D 加分项在于可验证的具体成果，需按岗位匹配度沉淀并预设面试官追问 ✓ 正确答案
# 13. 开源贡献对职业的声誉积累、招聘机会与协作能力影响如何设计实际转化路径？ A 三条路径相互独立，只需专注其一 B 招聘机会只取决于简历，与声誉无关 C 声誉积累为招聘机会提供入口，协作能力又反哺声誉，可设计成"贡献-沉淀-变现"的闭环 ✓ 正确答案 D 协作能力无法通过开源锻炼
# 14. 开源项目选择如何综合评估活跃度、社区文化与技术方向，冷门高价值项目怎么识别？ A 应从活跃度、社区文化、技术方向三维综合评估，冷门高价值项目常表现为"被依赖但不出名" ✓ 正确答案 B 只选最流行的项目即可 C 冷门项目一定没有价值 D 社区文化不重要，只要活跃就行
# 15. 开源贡献如何核对项目许可证、CLA 与公司政策，避免法律与知识产权风险？ A 只要项目是开源的就可以随意贡献 B 需核对许可证、CLA 与公司政策三层，避免把公司专有信息带入并确认贡献授权 ✓ 正确答案 C GPL 许可证对贡献者没有影响 D CLA 只是流程，可以随意签署
# 16. 开源维护者的时间投入、issue 疲劳与社区治理挑战如何管理，退出机制怎么设计？ A 维护者只需要写代码，不需要处理 issue B 退出项目不需要任何交接 C 维护者应该响应所有 issue 才能做好 D 需用批量处理、设置边界与 delegate 管理时间和 issue 疲劳，并设计交接与归档等退出机制 ✓ 正确答案
# 17. 开源贡献入门如何通过 good-first-issue、文档改进与 bug 修复实操，避免无效贡献？ A 贡献越多越好，不管质量 B 应选真实可验证的问题、动手前先沟通确认方案、遵循 CONTRIBUTING 并跑通测试，避免刷数量的无效贡献 ✓ 正确答案 C 文档改进没有任何价值 D 不需要先复现 bug 就能直接修复
