值得注意的是，这一研究成果已有实际落地产品——Vibelf - Scratch Copilot，为全球教育工作者和学生提供 AI 驱动的 Scratch 编程辅助服务，让编程学习变得更加智能化和个性化，致力于帮助青少年提升计算思维。

研究背景与问题

虽然像 Scratch 这样的创意编程平台已经让编程变得更容易接触，但将想象中的创意转化为功能代码对许多年轻学习者来说仍然是一个重大障碍。尽管 AI 编程助手在成人程序员中显示出巨大潜力，但专门针对儿童块状编程环境的工具却非常稀少。

近期研究表明，5-10 岁是儿童编程教育的关键发展窗口期。传统观念认为”9 岁才能有效学习计算思维”，但最新的集群随机对照试验证实，年龄适配的编程干预能同步提升 5-10 岁儿童的计算思维技能和执行功能，且低龄儿童（5-7 岁）表现出更强的认知可塑性。

研究方法与数据

Scratch Copilot 研究

研究团队开发了 Cognimates Scratch Copilot 工具，并进行了探索性定性评估：

• 参与者：18 名国际儿童（年龄 7-12 岁）
• 研究方法：定性评估分析
• 功能特性：实时支持创意构思、代码生成、调试和资源创建
• 核心技术：通过自然语言对话直接集成 Scratch 的可视化编程语言

编程干预的年龄效应研究

另一项关于《编程干预的年龄效应：探究5-10岁儿童计算思维与执行功能的协同发展》的大规模研究采用集群随机对照试验设计：

• 参与者：437 名儿童（一年级 273 人，四年级 164 人）
• 年龄范围：5-10 岁（一年级 5-7 岁，四年级 8-10 岁）
• 干预时长：8 小时 Code.org 平台编程课程
• 评估工具：Tower of London、NEPSY-II 抑制子测试、数字 Stroop 测试
• 研究设计：多中心集群随机对照试验（CONSORT 标准）

主要研究发现

AI 助手的支持效果

1. 创意构思支持：AI Copilot 在关键创意编程过程中提供了有效支持，特别是在创意构思和调试方面
2. 儿童主动性：儿童积极协商 AI 的使用，通过适应或拒绝建议来保持创意控制，展现出强烈的主体性
3. 学习机会：在处理 AI 局限性和错误的过程中产生了学习机会
4. 有效指导率：AI 助手在约 70% 的情况下提供了有用的指导，其余 30% 的复杂情况仍需要人工帮助或儿童自主解决问题

年龄相关的认知发展效果

基于 437 名儿童的大规模研究发现了显著的年龄差异效应：

计算思维能力提升

研究证实，年龄适配的编程干预能同步提升 5-10 岁儿童的计算思维（Computational Thinking, CT）技能：

• 算法思维强化：通过编程训练优化问题解决策略，儿童学会将复杂问题分解为可执行的步骤序列
• 逻辑推理能力：编程过程中的条件判断和循环结构训练显著提升了儿童的逻辑思维能力
• 抽象思维发展：从具体的积木编程到抽象的计算概念，儿童的抽象思维能力得到系统性提升
• 模式识别增强：通过识别和应用编程模式，儿童的模式识别和泛化能力显著改善

编程技能提升

• 一年级生：编码准确性提升 1.53 个标准差，编程计划时间缩短效果显著（d=1.18）
• 四年级生：编码准确性提升 1.84 个标准差，学习效率更高但自动化进步较小（d=0.34）

执行功能改善

• 计划能力：一年级生 ToL 测试准确性提升 1.44 个标准差，四年级生为 0.91 个标准差，低龄组计划时间减少 33%
• 抑制功能：一年级生 NEPSY-II 测试抑制错误减少 80%（d=0.80），四年级生减少 38%（d=0.38）；Stroop 测试同样显示低龄组优势（d=1.10 vs 0.44）

关键发现总结

• 计算思维核心效益：编程教育被证实为培养 21 世纪”新式读写能力”的有效途径，能系统性提升儿童的计算思维能力
• 低龄优势效应：5-7 岁儿童在抑制功能改善上表现出更强的认知可塑性，为”早期干预窗口期”理论提供了新证据
• AI 增强效应：AI 编程助手不仅支持编程技能学习，更能通过智能交互增强儿童的计算思维和创意自效能
• 认知迁移效应：编程训练的认知效益能迁移到执行功能等其他认知领域，体现了计算思维的跨领域价值
• 设计张力：在提供有用的脚手架支持和培养独立解决问题能力之间存在设计张力

设计指导原则

基于两项研究的综合发现，提出了设计儿童 AI 编程助手和编程教育的关键原则：

AI 编程助手设计原则

1. 优先考虑青少年主体性：确保儿童在 AI 交互中保持控制权
2. 批判性交互：鼓励儿童批判性地评估 AI 建议
3. 支持性脚手架：在提供帮助的同时不削弱独立思考能力
4. 问题驱动教学法：采用问题驱动的方式来支持创意问题解决
5. 文化适应性：根据儿童的文化背景调整响应内容

年龄适配教育策略

1. 早期干预优势：充分利用 5-7 岁儿童的认知可塑性窗口期，提供更多抑制功能训练
2. 差异化教学：针对不同年龄组设计不同的学习目标和评估标准
   • 低龄组（5-7 岁）：重点培养计划能力和抑制功能，利用其高可塑性
   • 高龄组（8-10 岁）：注重编程技能的精确性和效率提升
3. 适应性设计：根据不同年龄和技能水平调整支持策略和认知负荷

技术创新

Scratch Copilot 的核心技术创新已在Vibelf - Scratch Copilot中得到完整实现：

核心技术特性

• 直接集成：与 Scratch 的可视化编程语言直接集成
• 自然语言交互：通过自然语言对话提供支持
• 实时助手：提供实时的创意构思、代码生成、调试和资源创建支持
• 儿童友好设计：专门为 6-16 岁儿童设计的界面和交互方式

Vibelf - Scratch Copilot 产品创新亮点

• 🎯 AI 驱动的个性化学习：智能 AI 伴侣分析学习模式并实时适应，为每个学生创建个性化学习路径
• 👥 多角色支持系统：支持学生/教师/家长三种角色切换，提供全方位的学习生态支持
• 🚀 200+ 一键交互功能：涵盖游戏、数学、物理、字符串等多个领域的丰富交互模板
• 🧠 计算思维培养：基于研究发现的计算思维提升效果，Vibelf 系统性培养四大核心 CT 技能：
  • 分解思维（Decomposition）：引导儿童将复杂问题拆解为可管理的子问题
  • 模式识别（Pattern Recognition）：帮助识别问题中的规律和相似性
  • 抽象思维（Abstraction）：培养从具体实例中提取通用概念的能力
  • 算法设计（Algorithm Design）：训练设计解决问题的步骤序列
• 📊 智能课堂工具：包含课程设计、图表分析、PDF 导出、历史记录、文本选择聊天等完整教学工具链

完整的智能课堂工具链，包含课程设计、分析和管理功能

研究意义

两项研究的综合发现为儿童编程教育和 AI 助手设计提供了重要洞察：

理论贡献

• 认知发展理论：证实了 5-10 岁是编程教育的关键窗口期，挑战了传统的”9 岁门槛”观念
• AI 交互理论：首次系统性地探索了 AI 在儿童创意编程中的作用机制
• 年龄差异效应：发现低龄儿童在认知可塑性方面的独特优势

实践价值

• 计算思维培养：研究证实编程教育是培养 21 世纪”新式读写能力”的关键途径，能够系统性提升儿童的计算思维能力，这种能力在数字化时代具有与传统读写能力同等重要的地位
• 教育政策：为制定年龄适配的编程教育标准提供科学依据，特别是在计算思维核心技能培养方面
• 技术开发：为教育技术开发者提供具体的 AI 助手设计指导，重点关注计算思维能力的智能化培养
• 课程设计：支持差异化教学策略的制定和实施，针对不同年龄段的计算思维发展特点
• 商业化成功：Vibelf - Scratch Copilot 的成功落地证明了基于计算思维培养的 AI 编程教育具有巨大的市场价值和可行性
• 规模化应用：已服务全球数千名用户，验证了计算思维培养的实际效果和可规模化应用的潜力

未来方向

• 大规模应用：为 AI 编程助手的规模化部署提供理论基础
• 跨文化研究：探索不同文化背景下的儿童编程学习模式
• 长期追踪：研究编程教育对儿童认知发展的长期影响
• 产品生态扩展：Vibelf 正在构建更完整的 AI 编程教育生态，包括企业级解决方案和专业培训咨询服务
• 智能化升级：持续优化 AI 模型，提供更精准的个性化学习体验和更丰富的创意编程支持

结论

本文通过深入分析两项重要研究，揭示了 AI 辅助编程教育在儿童计算思维培养和认知发展中的关键作用。研究明确证实，编程教育是培养 21 世纪”新式读写能力”的有效途径，能够系统性提升儿童的计算思维能力，包括分解思维、模式识别、抽象思维和算法设计等核心技能。

精心设计的 AI 工具结合年龄适配的教学策略，不仅能够支持儿童的编程学习，还能在保持其创意主体性的同时显著提升计算思维和认知能力，这种认知效益还能迁移到执行功能等其他认知领域。

Vibelf - Scratch Copilot 作为这一理论研究的成功实践，展现了从学术研究到商业产品的完美转化。通过 AI 驱动的个性化学习、系统性的计算思维培养、多角色支持系统和丰富的交互功能，Vibelf 不仅验证了研究发现的实用性，更为全球数千名用户提供了高质量的计算思维培养体验。

随着人工智能技术的不断发展，AI 辅助编程教育将在培养下一代数字原住民的计算思维和创新能力方面发挥越来越重要的作用。计算思维作为数字化时代的核心素养，其培养价值已得到充分验证。这项研究为 AI 在儿童编程教育中的应用提供了重要的理论基础和实践指导，标志着 AI 编程助手从成人领域向儿童教育领域的重要扩展，更为计算思维教育的规模化发展奠定了坚实基础。

References

1. Vibelf - Scratch Copilot AI 编程教育平台
2. Scratch Copilot: Supporting Youth Creative Coding with AI - Stefania Druga (Google DeepMind) & Amy J. Ko (University of Washington)
3. 编程干预的年龄效应：探究 5-10 岁儿童计算思维与执行功能的协同发展
4. AI-Assisted Programming for Children
5. Scratch Programming Language
6. Google DeepMind Research
7. University of Washington - Human-Computer Interaction
8. IDC 2025 Conference

你只需将 HTML 文档类型声明 <!DOCTYPE html> 替换为 <!DOCTYPE aigc>，主体内容则是你网页的提示词，例如，“一个类 YouTube 的网站，展示搞笑的猫短视频”。

如果你购买了下一代搭载了 Google 自研 AI 芯片的 Google Chromebooks，你的用户甚至可以在无需联网的情况下访问你的网址，即刻浏览由 Google 强大的多模态大模型 Gemini 生成的网页内容。

Google 对此的愿景是：无论有什么创意，你都可以轻易向世人用更丰富的形式展示你的作品。假设你是一个诗人，你的网站提示词就是你的诗，而你的用户可以看到 AI 根据诗生成的视频。假设你是个编剧，你的剧本直接变成影片；假设你是画家，你的画展自动有多国语言的注解。等等，知识的传播和创造将变得从未有之容易，人的创作潜力真正展现出无限可能。

与此同时 OpenAI 也在测试同样功能的 React 组件 <OpenAIView>，两者的目标都是让自家的大模型接管网页开发和内容生成。从论文内容来看 Google Chrome <!DOCTYPE aigc> 功能更强大些，以下来看看两者的差异性：

实现原理

Google Chrome <!DOCTYPE aigc> 基于 Google Gemini 大模型生成内容，WebSocket 加载，以 Chrome 作为渲染载体。

例子

<!DOCTYPE aigc>
Show me a YouTube-like website
 that shows short funny cat videos.

OpenAI 的 React 组件 <OpenAIView> 基于 OpenAI 的大模型生成内容，微前端加载，以 React 作为渲染容器。

例子

//...
export default function MyApp() {
  return (
    <OpenAIView>
    Show me a YouTube-like website 
    that shows short funny cat videos.
     </OpenAIView>
  );
}

内容生成

Google Chrome <!DOCTYPE aigc>：

• 文本、图片、视频、动画等 HTML 网页元素 100%支持；
• 支持可交互游戏，通过 Canvas+WebGL+WASM 实现；
• 支持动态更新，按需更新网页中的模块；
• 支持 Single Source of Truth，严格根据提供的在线数据 API 解析并生成内容；

OpenAI 的 React 组件 <OpenAIView>：

• 文本、图片、视频等 React 组件生态支持的元素；
• 不支持可交互游戏；
• 不支持动态更新；
• 不支持 Single Source of Truth；

可用性

Google Chrome <!DOCTYPE aigc>：

• 提示词输入支持：文本、图片、视频、网址等；
• 支持跨平台，但仅限于 Chrome，不兼容其他浏览器；
• 装备 Google AI 芯片的 Chromebook 支持离线浏览；
• 全球可用；

OpenAI 的 React 组件 <OpenAIView>：

• 提示词输入仅支持文本；
• 支持跨平台，兼容任何浏览器；
• 不支持离线；
• 仅欧美地区；

安全性

Google Chrome <!DOCTYPE aigc>：

• 支持加密，通过加密提示词防止他人盗用，Chrome 会校验提示词的加密 hash 与域名的匹配，保证你的网站内容总是独一无二的。
• 支持隐私策略，用户浏览的内容都是无法追踪的；

OpenAI 的 React 组件 <OpenAIView>：

• 不支持加密；
• 不支持隐私策略；

References

• OpenAI React component playground

TTM 的实证研究

数据使用了微软内部的事故管理系统，从2018年至2020年的20个大规模在线服务系统中收集了事故数据，包括事故的文本描述、讨论记录、缓解时间等信息，共计约2.7万条。

事故生命周期的的时间分布

• 事故生命周期中的时间分布，包括事故的开始时间、结束时间、持续时间和缓解时间。
• 发现事故的开始时间和结束时间的分布呈现出明显的周期性，即事故在工作日和工作时间更多发生，而在周末和非工作时间更少发生。
• 发现事故的持续时间和缓解时间的分布呈现出长尾特征，即大多数事故可以在较短的时间内结束或缓解，但少数事故需要较长的时间。
• 发现事故的持续时间和缓解时间与事故的严重性、影响范围、类型、来源、所属服务和所属团队有显著的差异，即不同属性的事故的时间分布有不同的特点。

影响 TTM 的因素

• 发现事故的文本描述和讨论记录中反映了事故处理过程中的一些挑战和障碍，例如信息不足、沟通不畅、协作不协调等。
• 发现事故的挑战和障碍对事故缓解时间有一定的影响，例如信息不足会导致事故缓解时间延长，沟通不畅会导致事故缓解时间缩短，协作不协调会导致事故缓解时间波动等。

预测 TTM 的方法 TTMPered

论文提出了一种基于深度学习的事故缓解时间预测方法，称为 TTMPred。评估 TTMPred 的有效性和性能时使用了微软四个大规模、不同类型的在线服务系统的事故数据，包括 Azure DevOps、Azure SQL、Azure Storage 和 Office 365。

• TTMPred 在所有评价指标上都显著优于对比方法，说明TTMPred能够有效地利用事故的文本描述和讨论记录中的语义信息和时序信息，实现对事故缓解时间的准确预测。
• TTMPred 在不同的事故属性上都表现出稳定的性能，说明TTMPred具有良好的泛化能力，能够适应不同的事故场景。
• TTMPred 的两层注意力机制能够有效地捕捉事故文本中的关键信息，提高事故表示的质量。
• TTMPred 的连续损失函数能够有效地平衡预测值和真实值之间的绝对误差和相对误差，以及预测时间点和事故结束时间点之间的时间差，优化模型的预测性能。

References

• 缓解时间 (TTM)
• 如何做好Postmortem？

• 多种因素影响 MCR 的采用。 在行业中，它的采用受到文化、产品、工具、开发过程和团队的影响。 在开源项目中，影响更多的是人文和社会方面，尤其是黑客伦理。
• 在开源项目中，平均有一个或两个审阅请求的审阅者。 总的来说，小的代码改动和长篇大论的审查请求描述更容易吸引审查者。 开发人员更愿意邀请有经验的审阅者。
• 审阅者表示困惑，通常是由于缺少基本原理、对非功能性需求的讨论以及对代码不熟悉。在开源项目中，每个请求平均有两到三个审阅意见。 新人往往会受到更多关注。
• 当涉及熟悉代码的经验丰富的作者、经验丰富且积极且高度一致的审阅者时，审阅请求的完成时间会更短。
• 被接受的代码更改通常由经验丰富的开发人员编写，并包含带有积极情绪的审查反馈。 考虑到审查反馈分析，放弃代码更改的主要原因是重复和缺乏反馈。
• 审查代码更改后，产品质量往往会提高。 更多地参与代码审查、审查活动的更多经验以及审查者更熟悉项目也是降低发布后缺陷可能性的因素。
• 编程经验可能会影响审查人员在代码检查期间的注意力和脑力劳动。 在审查代码时，与语言处理和数学相关的特定大脑区域会增加活动，有经验的开发人员倾向于将编程语言视为自然语言。
• MCR 和结对编程在成本方面是可以互换的，除非在测试驱动开发中采用后者——在这种情况下，MCR 的成本更低。
• 单元测试比 MCR 发现更多的故障，但后者在检测和隔离缺陷的潜在来源方面需要更少的时间。
• 静态分析工具提出的警告很少在代码审查期间被删除。 依赖于持续集成的上下文、频繁构建的项目和状态为 passed 的自动构建，与审查者的参与度增加有关。

MCR 流程

MCR 有多种目的，其中最主要的是提高代码质量和发现缺陷。此外，MCR 还可以促进知识共享、团队协作、学习新技能、遵循编码标准等其他目的。

• MCR 的过程：MCR 的过程通常包括以下几个步骤：
  • （1）代码作者创建并提交一个代码变更请求（Code Change Request），并指定一个或多个代码审查者；
  • （2）代码审查者接受或拒绝该请求，并在合适的时间对代码变更进行检查和评估；
  • （3）代码审查者给出他们对代码变更的意见、建议或批评，并与代码作者进行沟通和讨论；
  • （4）代码作者根据代码审查者的反馈修改并更新他们的代码变更；
  • （5）代码审查者确认修改并批准或拒绝最终版本的代码变更；
  • （6）如果批准，则将代码变更合并到主分支；如果拒绝，则重新开始整个过程。
• MCR 的角色：MCR 有两个主要角色：代码作者（Code Author）和代码审查者（Code Reviewer）。代码作者是指创建并提交代码变更请求的人，他们负责编写高质量且符合规范的代码，并根据反馈进行修改。代码审查者是指检查并评估代码变更请求的人，他们负责发现并指出问题，给出有用且友好的意见，并与作者进行沟通和协作。
• MCR 的工具：MCR 有多种工具可以支持其实施，其中最常用的是基于 Web 的协作平台，如 GitHub、GitLab、Bitbucket 等。这些工具可以提供以下功能：
  • （1）创建、管理和跟踪代码变更请求；
  • （2）展示和比较不同版本的代码变更；
  • （3）添加注释、评论或建议到特定行或区域；
  • （4）发送通知或提醒到相关人员；
  • （5）集成其他工具或服务，如静态分析器、测试框架、持续集成系统等。
• MCR 的挑战：
  • 选择合适的审查者：审查者的选择会影响MCR的效率和效果，因为不同的审查者可能有不同的专业知识、可用性、工作负载、兴趣等。如果选择了不合适的审查者，可能导致审查时间过长、审查质量低下、审查冲突频繁等问题。
  • 保持审查参与度：审查参与度是指代码作者和代码审查者在MCR过程中的积极性和主动性。高参与度可以促进MCR的沟通、协作和信任，从而提高MCR的效果和质量。然而，保持高参与度并不容易，因为MCR可能受到多种因素的影响，如时间压力、工作优先级、人际关系等。
  • 编写有效的评论：评论是指代码审查者对代码变更给出的意见、建议或批评。有效的评论可以帮助代码作者改进他们的代码，并提高MCR的效果和质量。然而，编写有效的评论并不容易，因为评论需要考虑多种因素，如内容、形式、语气、时机等。
  • 处理多样化的代码变更：代码变更是指代码作者对原有代码所做的修改或添加。多样化的代码变更是指代码变更在大小、类型、复杂度、风格等方面有所不同。处理多样化的代码变更是一项挑战，因为不同的代码变更可能需要不同的审查策略、方法和工具。
  • 评估MCR的影响：MCR的影响是指MCR对软件产品和软件过程所产生的正面或负面的结果。评估MCR的影响是一项挑战，因为MCR的影响可能难以量化或隔离，而且可能受到多种因素的干扰或混淆。

改进 MCR 的提案

提案是指支持 MCR 的技术和工具，它们可以帮助代码审查者和作者更好地进行 MCR，可提高 MCR 的效率、效果和质量，以及减少 MCR 的成本和复杂性。提案可以分为以下几种类型：

• 代码审查者推荐器：这种提案旨在为代码变更找到合适的审查者，考虑到审查者的专业知识、可用性、工作负载、兴趣等因素。例如，ReviewBot 是一个基于机器学习的代码审查者推荐器，它使用代码变更的特征和历史数据来预测最佳的审查者。
• 代码检查支持：这种提案旨在帮助代码审查者检测代码变更中的缺陷、风险、坏味道等问题，使用静态分析、动态分析、规则检测等方法。例如，Code Defect AI 是一个基于深度学习的代码缺陷检测工具，它使用自然语言处理和图神经网络来识别代码中的潜在错误。
• 代码质量评估：这种提案旨在帮助代码审查者评估代码变更的质量，使用软件度量、复杂度分析、可维护性指标等方法。例如，Code Quality Advisor 是一个基于软件度量的代码质量评估工具，它使用多个维度来衡量代码变更的可读性、可测试性、可理解性等属性。
• 代码变更可视化：这种提案旨在帮助代码审查者可视化代码变更的结构、语义、影响等信息，使用图形化界面、颜色编码、交互式操作等方法。例如，ChangeScribe 是一个基于自然语言生成的代码变更摘要工具，它使用语法树和程序依赖图来生成描述代码变更目的和影响的自然语言句子。
• 代码变更摘要：这种提案旨在帮助代码审查者快速了解代码变更的主要内容和目标，使用自然语言生成、信息抽取、文本摘要等方法。例如，ChangeScribe 是一个基于自然语言生成的代码变更摘要工具，它使用语法树和程序依赖图来生成描述代码变更目的和影响的自然语言句子。
• 代码审查指导和反馈：这种提案旨在帮助代码审查者和作者提高MCR的效果和质量，使用教育性提示、建议性评论、积极性奖励等方法。例如，Review Assistant 是一个基于教育性提示的代码审查指导工具，它使用机器学习和自然语言处理来生成针对不同类型问题的个性化提示。

对源代码 (OSC) 保密的做法

• OSC-1：使用本地环境变量。本地环境变量是在应用程序外部定义的动态对象，用于避免将密码存储在 VCS 或配置 (config) 文件中，是实践者力荐的。
• OSC-2：将密码移动到配置文件。使用模板配置文件可以减少将密码签入 VCS 的机会，从而防止潜在的密码泄露。
• OSC-3：忽略敏感文件。为避免提交敏感文件，所有数据库都应包含一个 .gitignore 文件
• OSC-4：为客户端应用程序添加服务器端实现。为了避免在客户端应用程序中获取保密数据，服务端将使用适当的加密并为客户端获取数据，从而消除了在客户端应用程序中保存密码的必要性。

安全存储密码 (SSC) 的实践

• SSC-1：使用外部密码管理系统。管理密码的实践中最推荐的方案，外部密码管理系统最大限度地减少人工参与创建、分发和维护密码。这些系统可以根据开发人员所在的团队分配权限，可使开发人员的密码失效，可设置动态密码，可设置基于租约的密码管理。例如 HashiCorp Vault, AWS KMS 和 Knox。
• SSC-2：存储加密的密码。使用加密工具的好处是实施不需要额外的基础设施，避免对密码进行 Base64 编码，必须安全地管理加密密钥（远离 VCS）并且不用基于角色的机密访问控制。
• ` SSC-3：私有数据库不安全。`由于数据库可以克隆到新机器上，因此数据库历史中存在的密码将传播到克隆的数据库。只有一个被破坏的开发者帐户或一个错误的配置就足以访问私有数据库中存在的所有密码。

限制密码泄露的做法 (LSE)

• LSE-1：使用临时密码。临时密码可以通过终止访问来防止以前未被发现的数据泄露成为威胁，需要正确轮换和重新分配密码。
• LSE-2：限制 API 访问和权限。还应设置 API 密钥使用的每日限制。因为攻击者经常在他们的范围内使用密码，所以检测他们何时恶意地这样做可能具有挑战性。通过限制对密码的访问和许可来限制损害和横向移动。
• LSE-3：撤销机密并清理 VCS 历史记录。密码不会通过在另一次提交中删除它们而被完全删除，因为密码将保留在 VCS 历史记录中。最佳做法是在使用工具扫描 VCS 历史记录之前关闭所有拉取请求。GitHub 建议使用 git rebase 因为合并可以引入一些受污染的历史。
• LSE-4：审核所有上传到 VCS 的代码并查看 VCS 审核日志以查找可疑活动。

避免意外密码提交 (ASC) 的做法

• Asc-1：使用 VCS 扫描工具。不建议依赖代码审查来检测密码，建议运行 VCS 扫描工具，将 VCS 扫描工具与持续集成或持续部署，例如 TruffleHog、Gitrob 和 git-all-secrets。
• ASC-2：显式添加文件。在 VCS 显式添加文件，应避免使用通配符命令 (git add -A, git add ., add *) 。
• ASC-3：在提交之前使用 VCS 钩子检查文件。为了防止密码被推送到 VCS 数据库中，建议使用 VCS 在特定操作之前或之后执行脚本。钩子可用于在提交之前或拉取之后分别过滤和涂抹密码，每个开发者都需要单独设置 VCS 钩子。

管理部署中密码的实践 (MSD)

• MSD-1：在 CI/CD 中使用密码变量。从 CI/CD 脚本中删除硬编码的密码，并使用构建/部署系统的密码变量。
• MSD-2：使用配置管理系统。不同机器的配置由配置管理系统 (CMS) 工具从一个集中位置进行协调，可以使用确保每台机器接收正确配置的相同机制将密码分发到特定机器。
• Msd-3：为每个环境使用不同的密码。避免在多个环境中使用相同的密码，这样暴露一个环境的密码就不会危及其他环境。生产环境的密码应该不同于开发或预生产环境。将生产环境的密码仅限于一小部分所有者，以避免失败的风险。
• MSD-4：将点文件保存在根目录之外。在部署过程中将点文件（例如 .git, .gitignore, .config）移出根目录。应该对生产服务器上的点文件应用适当的访问限制，以避免泄露密码。如果.git文件夹没有保存在根目录之外，那么提交更改的整个历史就会暴露给攻击者。

执行密码保护政策 (OEP) 的组织实践

组织可以采用一般做法在 VCS 中为开发人员实施政策。这些一般做法可以最大限度地减少漏洞，从而有助于避免泄露密码。

• OEP-1：严格管理开发者权限。组织应遵循最小特权原则。组织不应授予开发人员超出所需范围的权限，例如更改数据库可见性和添加外部贡献者。如果数据库包含密码，则有权更改数据库可见性的开发人员越多，失败的风险就越高。
• OEP-2：强制执行 2FA 身份验证。为了防止通过不安全的开发者帐户泄露源代码，建议强制执行 2FA 身份验证。
• OEP-3：需要提交签名。恶意用户可以通过伪装成其他人将可利用代码推送到 VCS 中，并通过更改 VCS 中的用户名和电子邮件地址来保持无法追踪。对于代码合并的验证和可追溯性，可以使用提交签名，这是一种密码代码签名技术。提交签名是通过 GPG 完成的，签名的提交会获得一个“已验证”标志。恶意用户的提交很容易被追踪，因为提交不会有“已验证”标志。
• OEP-4：添加 Security.md 文件。添加 Security.md 以正式记录与安全相关的过程和程序，例如令牌可访问性、身份验证要求和漏洞报告。这安全 Security.md 可以作为开发人员的有用参考，也可以作为组织安全期望的集中空间。
• OEP-5：实现单点登录。可以通过利用 SAML SSO 明确提供对资源的权限来管理对 VCS 资源（例如特定数据库和拉取请求）的访问。SAML SSO 还允许设置经批准的身份提供者，这使组织能够强制开发人员使用组织的帐户而不是私人拥有的 VCS 帐户进行登录。
• OEP-6：禁用 Fork。Git Fork 功能允许开发人员复制数据库，并且对测试和沙盒很有用。Fork 可以向公众泄露密码。每一次 Fork，风险都会呈指数增长，从而导致一系列安全漏洞。

当代日志框架（Contemporary Logging Framework）

论文将软件监控的日志技术映射到四个维度和13个分支：

• 日志工程（Log Engineering）：关注如何在软件系统中插入、维护和优化日志语句。它包括以下分支：
  • 日志语句生成（Log Statement Generation）：关注如何自动地或半自动地在代码中插入日志语句。
  • 日志语句更新（Log Statement Update）：关注如何自动地或半自动地更新已有的日志语句，以适应代码变化或需求变化。
  • 日志语句优化（Log Statement Optimization）：关注如何提高日志语句的质量和效率，例如减少冗余、增加信息量、降低开销等。
• 日志基础设施（Log Infrastructure）：关注如何在软件系统中收集、存储和传输日志数据。它包括以下分支：
  • 日志收集（Log Collection）：关注如何从不同的源头（例如服务器、客户端、容器等）获取日志数据，并将其转换为统一的格式。
  • 日志存储（Log Storage）：关注如何在不同的介质（例如文件、数据库、云服务等）存储日志数据，并保证其可用性和安全性。
  • 日志传输（Log Transmission）：关注如何在不同的网络环境下传输日志数据，并保证其可靠性和实时性。
• 日志分析（Log Analysis）：关注如何从日志数据中提取有用的信息和知识。它包括以下分支：
  • 日志解析（Log Parsing）：关注如何从非结构化或半结构化的日志数据中提取结构化的字段，例如时间戳、级别、消息等。
  • 日志聚类（Log Clustering）：关注如何将相似或相关的日志条目分组在一起，以便于进一步的分析或可视化。
  • 日志异常检测（Log Anomaly Detection）：关注如何从日志数据中识别出异常或错误的情况，例如系统崩溃、性能下降、配置错误等。
  • 日志故障诊断（Log Fault Diagnosis）：关注如何从日志数据中定位和解释故障的原因，例如代码缺陷、资源竞争、依赖问题等。
  • 日志行为建模（Log Behavior Modeling）：关注如何从日志数据中抽象出系统或用户的行为模式，例如状态机、工作流、用户画像等。
• 跨领域应用（Cross-Domain Applications）：关注如何将软件监控的日志技术应用到其他领域或场景中。它包括以下分支：
  • 软件测试与调试（Software Testing and Debugging）：关注如何利用日志数据来辅助软件测试与调试过程，例如生成测试用例、检测回归错误、重放执行轨迹等。
  • 软件安全与隐私（Software Security and Privacy）：关注如何利用或保护日志数据来提高软件系统的安全性与隐私性，例如检测恶意攻击

TD 类型

• 设计债 (21.99%)：是指违反良好设计原则和实践。 这种欠债可以通过分析源代码来发现。 例如，使用代码审查技术或静态代码分析工具。
• 测试债 (19.94%)：是指与测试问题。 例如，未执行的计划测试或低测试覆盖率。
• 代码债 (14.66%)：是指在源代码中发现的对代码的可读性和可维护性产生负面影响的问题。 例如，过于复杂的方法或不存在的编码标准。 为了消除代码债，需要进行代码重构。
• 架构债 (10.70%)：是指影响架构要求（例如，性能、可维护性、健壮性等）的系统架构问题。 例如，违反模块化原则或分离不佳会导致系统的进一步演进、维护和扩展出现重大问题。
• 文档债 (9.09%)：是指在软件项目的文档中发现的问题，包括文档缺失。 它是通过查找不一致、缺失、不充分或不完整的文档来发现。 例如，技术文档已过时，无法反映系统的实际状态。
• 需求债 (8.80%)：是指约定的需求与软件产品中实际实现的需求之间的差距。 例如，这可以表现为部分实现的要求或仅针对某些情况定制的要求。
• 流程债 (4.11%)：是指低效流程。 例如，随着时间的推移，流程发生了变化，现有的做法不再有效。
• 基础设施债 (2.93%)：是指如果存在于组织中会显着降低团队交付优质产品的基础设施问题。 例如，使用过时的工具或推迟定期软件或系统更新。
• 缺陷债 (2.79%)：是指发现的已知缺陷，但修复被推迟或从未修复。 推迟修复的决定可以在系统中积累大量的 TD。
• 人力债（1.32%)：是指与人有关的问题。 例如，缺乏需要额外培训或特定技能和知识。 与人相关的问题要复杂得多，它们涉及直接影响生产力和人们满意度的社会组织因素。

导致 TD 的 8 大原因

结论：

• Deadline、未采用良好做法、缺乏经验和压力是招致 TD 的最可能原因。这些原因很可能是计划不当、缺乏明确定义的流程或无效的项目管理。
• 基础设施原因最有可能导致架构债，而导致构建或可用性债的可能性较小。开发问题原因更有可能导致代码或设计债，但不太可能导致测试债。外部因素更容易导致基础设施债。 规划和 管理和方法原因更容易导致测试债。

8 大原因：

1. 规划和管理：同时处理不同的客户和项目、行为不当、领导不力。
2. 开发问题：缺乏质量、遗留系统、遗留工件。
3. 方法论：未执行测试，任务分配不佳。
4. 缺乏知识：缺乏经验、上下文。
5. 人：过度自信，不分享知识，缺乏团队沟通。
6. 组织：缺乏培训，项目缺乏优先级。
7. 外部因素：付款动态、停产的依赖。
8. 基础设施：技术、工具、平台选择不足，所需基础设施不可用。

TD 的影响

结论：

• TD 的存在最有可能导致交付延迟、可维护性低并产生返工需求。 这些影响还会导致长期影响，最有可能造成经济损失。
• TD 的代码和测试类型可能分别导致内部和外部质量问题。 同时，需求债很可能导致规划和管理问题。 此外，缺陷债与人相关的问题有关。

6 大影响：

1. 规划与管理：增加成本，增加投入。
2. 外部质量：低质量、低性能、低可维护性。
3. 内部质量：代码可读性差，维护量增加。
4. 人：客户或用户不满意，缺乏知识。
5. 开发问题：代码重用率低，易处理性低。
6. 组织：财务损失，公司形象受损。

References

• We invested 10% to pay back tech debt; Here’s what happened
• How to Best Use MTT* Metrics to Optimize Your Incident Response

论文绘制的开源软件供应链攻击分类树

它是一个攻击树的形式，包含了五个主要的攻击目标：代码贡献、版本控制系统、构建系统、分发平台和下游用户，每个攻击目标下面有多个攻击向量，即具体的攻击方法，每个攻击向量也有一个或多个与之相关的缓解措施。

• 代码贡献：攻击者试图通过提交恶意代码或修改已有代码来影响开源项目的功能或安全性。这种攻击可能涉及以下工具或方法：
  • 利用恶意账户或盗取合法账户来提交代码变更。
  • 利用代码审查机制的缺陷或不足来绕过检查。
  • 利用依赖关系混淆或欺骗来引入恶意依赖。
  • 利用代码库中的隐蔽通道或后门来控制或损害目标系统。
• 版本控制系统：攻击者试图通过篡改版本控制系统（VCS）中的数据或配置来破坏开源项目的完整性或可信度。这种攻击可能涉及以下工具或方法：
  • 利用恶意账户或盗取合法账户来修改VCS中的代码、元数据、分支、标签等。
  • 利用VCS中的漏洞或错误配置来执行任意命令、访问敏感信息、删除数据等。
  • 利用VCS中的历史记录重写功能来擦除痕迹或伪造历史记录。
• 构建系统：攻击者试图通过操纵构建系统中的数据或配置来影响开源项目的构建过程和结果。这种攻击可能涉及以下工具或方法：
  • 利用恶意账户或盗取合法账户来修改构建系统中的构建脚本、配置文件、环境变量等。
  • 利用构建系统中的漏洞或错误配置来执行任意命令、访问敏感信息、删除数据等。
  • 利用构建系统中的缓存污染功能来注入恶意代码或依赖到构建结果中。
• 下游用户：攻击者试图通过利用下游用户的行为或信任来诱导他们下载或执行恶意包或版本。这种攻击可能涉及以下工具或方法：
  • 利用社交工程学技巧，例如发送钓鱼邮件、伪造身份、制造紧急情况等，来诱骗下游用户点击恶意链接或附件。
  • 利用拼写错误或相似的包名或域名，例如 Typosquatting，来欺骗下游用户下载错误的包或版本。
  • 利用下游用户对开源项目的信任，例如使用默认密码、不检查签名、不验证来源等，来植入恶意代码或依赖到包或版本中。
  • 利用下游用户对开源项目的需求，例如使用过时的包、缺少安全更新、寻求新功能等，来推荐恶意包或版本给下游用户。

论文总结的 33 个缓解措施

• M1: 使用安全的编程语言和工具可以防止或减轻由于编程语言或工具本身的漏洞或限制而导致的攻击，例如缓冲区溢出、内存泄露、格式化字符串等。
• M2: 使用静态和动态分析工具可以防止或减轻由于代码中的错误或漏洞而导致的攻击，例如逻辑错误、输入验证、内存管理等。
• M3: 使用代码审查工具和流程可以防止或减轻由于代码质量不高或存在恶意代码而导致的攻击，例如代码复杂度、风格一致性、安全性规范等。
• M4: 使用代码签名和加密技术可以防止或减轻由于代码被篡改或窃取而导致的攻击，例如数字签名、哈希校验、对称加密、非对称加密等。
• M5: 使用代码质量和安全性指标可以防止或减轻由于使用不可信赖的开源项目或贡献者而导致的攻击，例如代码覆盖率、漏洞数量、维护频率、信誉评分等。
• M6: 使用代码依赖管理工具可以防止或减轻由于使用过时或有漏洞的依赖项而导致的攻击，例如依赖项版本控制、更新提醒、漏洞扫描等。
• M7: 使用代码托管平台的安全功能可以防止或减轻由于代码托管平台被入侵或滥用而导致的攻击，例如双因素认证、访问控制列表、分支保护、合并请求等。
• M8: 使用多因素身份验证和授权机制可以防止或减轻由于身份被冒用或权限被滥用而导致的攻击，例如密码加盐哈希、验证码、令牌、角色分配等。
• M9: 使用强密码和密钥管理工具可以防止或减轻由于密码或密钥被破解或泄露而导致的攻击，例如密码生成器、密码管理器、密钥生成器、密钥存储器等。
• M10: 使用恶意软件检测和防御工具可以防止或减轻由于恶意软件感染系统而导致的攻击，例如杀毒软件、防火墙、沙箱、隔离环境等。
• M11: 使用网络安全监控和防火墙工具可以防止或减轻由于网络攻击或拦截而导致的攻击，例如端口扫描、数据包嗅探、分布式拒绝服务、跨站脚本等。
• M12: 使用安全的通信协议和渠道可以防止或减轻由于通信内容被窃听或篡改而导致的攻击，例如安全套接字层、传输层安全、超文本传输协议安全、虚拟专用网络等。
• M13: 使用安全的开发环境和设备可以防止或减轻由于开发环境或设备被感染或损坏而导致的攻击，例如操作系统更新、驱动程序更新、硬件加密、物理锁等。
• M14: 遵循最低特权原则和最小暴露原则可以防止或减轻由于过多的特权或暴露而导致的攻击，例如最小化代码库访问权限、最小化系统访问权限、最小化网络访问权限、最小化数据共享等。
• M15: 遵循开源许可协议和法律规定可以防止或减轻由于违反开源许可协议或法律规定而导致的攻击，例如遵守版权声明、遵守免责声明、遵守贡献者协议、遵守隐私政策等。
• M16: 遵循开源社区的最佳实践和指南可以防止或减轻由于不符合开源社区的标准或期望而导致的攻击，例如遵守代码风格指南、遵守文档编写指南、遵守测试编写指南、遵守发布流程指南等。
• M17: 建立并维护开源项目的信誉和声誉可以防止或减轻由于开源项目被质疑或抵制而导致的攻击，例如建立并展示项目的愿景、目标、价值、成就等。
• M18: 建立并维护开源项目的透明度和可追溯性可以防止或减轻由于开源项目被隐藏或篡改而导致的攻击，例如公开并记录项目的活动、决策、变更、问题等。
• M19: 建立并维护开源项目的活跃度和响应度可以防止或减轻由于开源项目被遗弃或忽视而导致的攻击，例如定期并及时地更新项目的代码、文档、测试、版本等。
• M20: 建立并维护开源项目的多样性和包容性可以防止或减轻由于开源项目被排斥或利用而导致的攻击，例如欢迎并支持来自不同背景和经验的贡献者、用户和利益相关者等。
• M21: 建立并维护开源项目的合作性和互信性可以防止或减轻由于开源项目被分裂或背叛而导致的攻击，例如建立并遵守项目的规则、道德、文化、社区等。
• M22: 选择并使用可信赖的开源项目和贡献者可以防止或减轻由于使用不可信赖的开源项目或贡献者而导致的攻击，例如评估并验证开源项目和贡献者的信誉、声誉、透明度、可追溯性、活跃度、响应度、多样性、包容性、合作性和互信性等。
• M23: 选择并使用可信赖的包管理器和仓库可以防止或减轻由于使用不可信赖的包管理器或仓库而导致的攻击，例如评估并验证包管理器和仓库的安全性、可靠性、稳定性、性能等。
• M24: 选择并使用可信赖的构建工具和流程可以防止或减轻由于使用不可信赖的构建工具或流程而导致的攻击，例如评估并验证构建工具和流程的正确性、完整性、一致性、效率等。
• M25: 选择并使用可信赖的测试工具和流程可以防止或减轻由于使用不可信赖的测试工具或流程而导致的攻击，例如评估并验证测试工具和流程的覆盖度、有效性、敏感度、鲁棒性等。
• M26: 选择并使用可信赖的发布工具和流程可以防止或减轻由于使用不可信赖的发布工具或流程而导致的攻击，例如评估并验证发布工具和流程的安全性、兼容性、兼容性、用户友好度等。
• M27: 定期更新开源项目的依赖项和版本号可以防止或减轻由于使用过时或有漏洞的依赖项或版本号而导致的攻击，例如跟踪并应用依赖项和版本号的更新、修复、改进等。
• M28: 定期检查开源项目的漏洞报告和修复方案可以防止或减轻由于忽略或延迟处理开源项目的漏洞而导致的攻击，例如订阅并关注漏洞报告和修复方案的来源、内容、影响等。
• M29: 定期备份开源项目的代码库和数据集可以防止或减轻由于开源项目的代码库或数据集被破坏或丢失而导致的攻击，例如使用可靠的备份工具和媒介、设置合理的备份频率和保留期限等。
• M30: 定期审计开源项目的代码库和数据集可以防止或减轻由于开源项目的代码库或数据集被隐藏或篡改而导致的攻击，例如使用专业的审计工具和方法、设置合理的审计频率和标准等。
• M31: 及时报告并修复发现的漏洞或异常行为可以防止或减轻由于漏洞或异常行为被利用或扩散而导致的攻击，例如使用合适的报告渠道和格式、使用合适的修复工具和方法等。
• M32: 及时通知并帮助受影响的下游用户或组织可以防止或减轻由于下游用户或组织被感染或损害而导致的攻击，例如使用合适的通知渠道和内容、提供合适的帮助资源和建议等。
• M33: 参与并支持开源社区的安全倡议和活动可以防止或减轻由于开源社区的安全意识或能力不足而导致的攻击，例如参与并支持开源软件基金会、开源安全联盟、开源安全峰会等。

• 原则1：选择一个编码风格指南——并坚持使用它。编码风格指南是一套规定代码的格式、命名、缩进等方面的规范，它可以提高代码的可读性和一致性。选择一个编码风格指南并坚持使用它可以帮助开发者和用户更容易地理解和维护代码，以及避免潜在的错误。建议使用现有的编码风格指南或工具，如 PEP8、tidyverse、BlueStyle 等。
• 原则2：考虑使用集成开发环境。集成开发环境是一种集合了代码编辑、调试、运行、测试等功能的软件应用，它可以提高开发者的效率和便利性。考虑使用集成开发环境可以帮助开发者更容易地编写和管理代码，以及利用其提供的各种辅助功能，如自动补全、语法高亮、错误检测等。建议使用适合所用语言或领域的集成开发环境，如 PyCharm、RStudio、VS Code 等。
• 原则3：尽可能减少复杂性。复杂性是指代码在结构、语义、逻辑等方面的难度或复杂度，它可以影响代码的可读性和可维护性。尽可能减少复杂性可以帮助开发者和用户更容易地理解和修改代码，以及提高代码的效率和可靠性。建议使用简洁和表达力强的代码，避免重复或冗余的代码，利用语言特性或库函数等方法。
• 原则4：根据需要重构代码。重构代码是指在不改变代码外部行为的前提下，改善代码内部结构或质量的过程，它可以提高代码的可读性和可维护性。根据需要重构代码可以帮助开发者和用户更容易地组织和扩展代码，以及提高代码的灵活性和可维护性。建议使用模块化和可复用的代码，使用函数、类、模块等结构来封装代码逻辑，遵循单一职责原则、开闭原则等设计原则。
• 原则5：防御式编程。防御性编程或防御性设计：主动考虑⽤⼾与代码的意外交互。是指在编写代码时考虑到可能出现的错误或异常情况，并采取相应的措施来处理或避免它们的方法，它可以提高代码的正确性和鲁棒性。防御式编程可以帮助开发者和用户更容易地发现并修复错误，以及提高代码的效率和可靠性。建议使用异常处理、断言、日志、契约等方法。
• 原则6：遵循已有的编写单元测试的模式。单元测试是指针对代码中的最小可测试单元，如函数、类、模块等，进行独立的测试，以验证其功能或行为是否正确的方法，它可以提高代码的正确性和可测试性。遵循已有的编写单元测试的模式可以帮助开发者和用户更容易地编写和执行单元测试，以及提高单元测试的质量和一致性。建议使用现有的单元测试框架或工具。
• 原则7：在开发周期中创建测试。在开发周期中创建测试是指在编写代码的同时或之前，就开始编写相应的测试，以验证代码是否满足预期或需求的方法，它可以提高代码的正确性和可维护性。在开发周期中创建测试可以帮助开发者和用户更容易地检测并修复错误，以及提高代码的可靠性和可扩展性。建议使用敏捷开发或测试驱动开发等方法。
• 原则8：确保足够的测试覆盖率。测试覆盖率是指代码中被执行到或覆盖到的部分占总代码量的比例，它可以反映代码的可测试性和可信度。确保足够的测试覆盖率可以帮助开发者和用户更容易地评估并提高代码的质量和安全性，以及降低出错或漏洞的风险。建议使用现有的测试覆盖率工具或服务。
• 原则9：设置端到端和回归测试。端到端测试是指针对整个系统或流程进行完整的模拟用户操作或场景来验证其功能或行为是否正确的方法，它可以提高系统或流程的正确性和完整性。回归测试是指针对已修改或更新过的代码进行重复执行已有的测试来验证其功能或行为是否仍然正确的方法，它可以提高代码的稳定性和兼容性。设置端到端和回归测试可以帮助开发者和用户更容易地保证系统或流程的质量和安全性，以及降低出错或漏洞的风险。建议使用现有的端到端和回归测试工具或服务，如 Selenium、Cypress、TestCafe 等。
• 原则10：自动化你的软件测试工作流。自动化你的软件测试工作流是指使用工具或服务来自动执行、管理、报告你的软件测试，而不需要人工干预或监督的方法，它可以提高软件测试的效率和便利性。自动化你的软件测试工作流可以帮助开发者和用户更容易地进行频繁和及时的软件测试，以及提高软件测试的准确性和可追溯性。建议使用现有的自动化软件测试工具或服务，如 GitHub Actions、Travis CI、Codecov 等。

技能模型

OSS 中的技能包括硬技能和软技能的组合。 技能的主要类别是技术技能、工作方式、解决问题、贡献类型、项目特定技能、人际交往能力、外部关系、管理和特征。

• 技术技能（technical skills）：包括编程语言、框架、工具、测试、调试、版本控制、持续集成/部署、安全性、性能优化等。
• 工作风格（working styles）：包括沟通、协作、反馈、学习、适应性、自我管理等。
• 问题解决（problem solving）：包括分析、创新、逻辑、批判性思维等。
• 贡献类型（contribution types）：包括代码贡献（如添加功能或修复错误）、文档贡献（如编写或更新文档）、报告错误或建议改进（如提交问题或请求）、审查代码或文档（如提供意见或批准更改）、参与讨论或社区活动（如回答问题或分享经验）等。
• 项目特定技能（project-specific skills）：包括项目背景知识（如项目的目标和历史）、项目规范知识（如项目的结构和风格）、项目工具知识（如项目使用的特定工具和平台）等。
• 人际技能（interpersonal skills）：包括礼貌和尊重他人的观点和经验，同理心和理解他人的需求和情感，信任和建立良好的关系，冲突管理和妥善处理分歧等。
• 外部关系（external relations）：包括推广和宣传OSS项目，协调和合作OSS项目之外的人或组织，寻找并利用外部资源，保护OSS项目的利益等。
• 管理（management）：包括决策和制定OSS项目的目标和计划，组织和分配OSS项目的任务和角色，监督和评估OSS项目的进度和质量，激励和培养OSS项目的贡献者等。
• 特征（characteristics）：包括热情和对OSS项目有兴趣和动力，自信和对自己有信心并敢于尝试新事物，耐心和对OSS项目有长期的承诺并能够忍受不确定性等。

提升技能

贡献者通过阅读博客、在社交媒体和会议上关注 OSS 人物、向同行学习以及为 OSS 项目做出贡献来提高技能。 技能的增长受到贡献者兴趣、OSS 团队的需求、可用资源和确定的改进领域的影响。 大多数贡献者都在积极采取措施提高他们的技能，并根据他们必须提供的技能加入项目。

OSS 贡献者有以下几种提高技能的动机和方式：

• 学习新知识：OSS贡献者通过参与不同的项目和任务来学习新的技术、工具、框架、语言等。
• 解决问题：OSS贡献者通过解决自己或他人遇到的问题来提高自己的技能，比如修复bug、优化性能、增加功能等。
• 参与社区活动：OSS贡献者通过参与社区的各种活动来提高自己的技能，比如讨论、协作、评审、培训等。

OSS 贡献者是如何评估自己的技能水平和进步的：

• 反馈：OSS贡献者通过收到其他人的反馈来评估自己的技能，比如代码审查、问题评论、合并请求等。
• 成果：OSS贡献者通过观察自己的成果来评估自己的技能，比如完成任务、解决问题、提高质量等。
• 比较：OSS贡献者通过与其他人或自己过去的水平进行比较来评估自己的技能，比如参考优秀代码、学习先进技术、回顾历史记录等。

OSS 贡献者提升技能遇到的几种挑战：

• 时间：OSS贡献者往往缺乏足够的时间来提升自己的技能，因为他们需要平衡工作、生活和其他责任。
• 资源：OSS贡献者往往缺乏合适的资源来提升自己的技能，比如文档、教程、指导等。
• 信心：OSS贡献者往往缺乏信心来提升自己的技能，因为他们可能觉得自己不够好、不被欢迎或不被认可。

展示技能

贡献者展示他们的技能，维护者评估 GitHub 上的潜在贡献者。 贡献者分享技能以改善职业前景并展示专业知识。 贡献者发现技能可用于招聘、评估贡献、引导新人加入社区以及寻找专家。

OSS 贡献者有以下几种展示技能的方式：

• 贡献：OSS贡献者通过参与不同类型和规模的项目来展示自己的技能，比如编写代码、修复错误、撰写文档等。
• 交流：OSS贡献者通过与其他人沟通和协作来展示自己的技能，比如提问、回答、评论、建议等。
• 展示：OSS贡献者通过使用可视化和元数据来展示自己的技能，比如徽章、标签、图表、简历等。