千名 GitHub 开发者直言：急需高效软件开发与环境影响量化方案

开发者深知高效软件至关重要，但许多人缺乏明确的路径来识别浪费、量化改进效果，并据此推动优化落地。 这项由 GitHub 与耶鲁大学气候变化传播项目联合开展的新调查得出了上述结论，共调研了 1,039 名 GitHub 用户。八成受访者表示，他们希望借助工具编写更节能的代码。将近同样多的开发者期望获得降低软件环境足迹的最佳实践，而近 75% 的人则希望找到评估软件或开发流程环境影响的方法。 现在有机会将这种兴趣转化为常规的工程工作流：识别不必要的计算消耗，提出变更建议，进行测试，最终由维护者决定哪些改动可以上线。

开发者关注气候变化及 AI 的环境影响

该调查对象为美国的 GitHub 月活跃用户，内容涵盖气候变化、AI、软件效率以及科技行业组织在环保方面的责任。 调查结果清晰地反映出了这种关切：

• 79% 的受访者表示担心全球变暖。
• 71% 担心 AI 系统的环境影响，包括其能源与水资源消耗及碳排放。
• 75% 认为雇主应积极采取行动减少自身的环境影响。

这些结果描述的是受访者的观点，而非对 AI 或任何特定软件系统实际环境足迹的测量。样本来自选择接收营销信息的 GitHub 用户，因此结果不应被视为能代表所有开发者或 GitHub 用户。 这些发现确实表明，许多开发者正在思考其所构建和使用的系统对环境产生的影响。

GitHub 用户与更广泛的美国成年人口存在差异

在与耶鲁大学具有全国代表性的《美国人心中的气候变化》调查使用相同问题的对比中，GitHub 用户对气候变化表示出了比美国成年人大众更深的担忧。

GitHub 用户更倾向于认为全球变暖正在发生（86%，而美国成年人为 68%），这至少对他们个人有一定重要性（82%，对比 65%），以及至少会造成中等程度的个人损害（68%，对比 45%）。他们也更倾向于预期未来世代将面临至少中等程度的损害（82%，对比 68%），并表示对全球变暖感到担忧（79%，对比 66%）。

关于数据解读的一点说明：本报告数据基于自愿选择接受营销邮件的 GitHub 用户非概率样本，因此调查结果描述的是受访者而非开发者整体。与美成年人数据的差异反映了人口结构和调查设计的不同。

问题不在于缺乏兴趣，而在于缺乏切实可行的行动路径

仅有 10% 的受访者认为他们的软件开发和编写方式对减少个人环境足迹有巨大影响。另有 28% 认为影响中等，63% 则认为影响较小。

与此同时：

• 80% 对编写能效更高代码的工具感兴趣。
• 78% 希望学习减少软件环境足迹的最佳实践。
• 74% 对衡量软件或开发流程的环境影响感兴趣。
• 70% 对参与专注可持续性的开源项目感兴趣。

开发者们在软件开发领域寻求的，与他们在其他工程领域期待的一样：实用的工具、可靠的度量以及可审查的改进。

开放式的调查回复提供了不少具体需求。受访者希望获得帮助，来估算仓库和 CI/CD 工作流的资源占用、找出不必要的 GitHub Actions 运行、提升代码效率，以及对比 AI 与其他计算需求来源。还有几位受访者提醒，没有证据就不要随意宣称环保效益。

最后这一点很重要。更快的代码确实能减少资源消耗，但仅凭运行时间并不能证明能耗或排放降低了。硬件、工作负载、地区、时间和电力来源都会影响结果。开发者需要与声明相匹配的实测数据。

从看得见、测得到的浪费入手

软件效率本来就是优秀工程实践的一部分。它能降低基础设施成本、提升性能、减少延迟、释放容量。当改进在交付相同结果的前提下减少了计算量，也就能降低能耗。

一个实用的切入点，是在以下四个领域寻找可量化的浪费：

1. 代码：重复计算、低效算法、不必要的内存分配，或本可缓存的高开销操作。
2. 数据：过度抓取、无边界查询、缺少缓存，或本应批量执行的数据库调用。
3. 网络和 I/O：重复请求、本可改为事件驱动的轮询、过大的负载，或缺少压缩。
4. 前端：不必要的渲染、过早加载的屏外资源，或本可使用更小格式的媒体。

选用哪个指标取决于具体改动。执行时间、CPU 使用率、内存分配和网络传输量都可以作为计算需求的有效代理指标，但各有局限，所以要说明你测了什么、没测什么。

举个例子：一个把 O(n²) 搜索替换为 hash-map 查找的 pull request，应该附上代表性工作负载的前后对比数据、可复现测试的命令，以及内存或可维护性方面的权衡。这比在没有数据支撑的情况下宣称改动“更环保”更有说服力。

用 agent 找机会，而不是替你做最终决定

在大型仓库中寻找效率优化点可能很耗时。GitHub Agentic Workflows 可以帮助自动化搜索，同时让维护者保持掌控。

开源的Daily Efficiency Improver 工作流可扫描代码仓库，识别代码、数据、网络、I/O 及前端性能方面的优化机会。它优先处理可量化的改进项，运行仓库的测试，并生成附带证据与权衡说明的草稿 Pull Request，供维护者审阅。该工作流本身不会合并任何变更。

你可以通过 GitHub CLI 将该工作流添加到仓库：

gh extension install github/gh-aw 

gh aw add-wizard githubnext/agentics/efficiency-improver

启用定时工作流前，请审查其权限、配置、模型调用、预期运行频率及可能的计算成本。建议先在合适的测试仓库中试用或手动运行。在所有推荐方案均获得基准测试和测试用例支持之前，应将其视为假设。

高质量的 Pull Request 应回答以下五个问题：

1. 工作流发现了哪些浪费？
2. 哪个指标能代表预期改进效果？
3. 基线值是多少？
4. 该变更是否保留了功能与质量？
5. 维护者需要考虑哪些权衡？

AI 可协助开发者搜索、测试并记录潜在改进方案。但人类仍需判断证据是否可靠，以及该变更是否适合纳入代码库。

让效率成为工程闭环的一部分

当效率优化契合开发者现有的工具与决策流程时，最易长期维持。仓库级工作流可发现优化机会，草稿 Pull Request 展示具体修复方案，基准测试与单元测试验证其有效性，维护者随后决定接受、修改或拒绝该变更。

这一闭环正是调研受访者所期待的实际支持：工具、测量手段，以及从关切到代码的落地路径。

阅读 GitHub 与 Yale 气候变化传播计划联合发布的《软件开发者谈气候变化、AI 与可持续软件》完整报告。随后在合适的仓库中试用Daily Efficiency Improver，并审阅其分析结果。

作者