Copilot 编写了代码，但归属谁？工程团队可能忽视的治理缺口

一位工程师打开 Copilot 来帮助为客户的网站起草代码。几秒钟内，他们就收到本来手动编写需要花费大量时间的代码。对于许多优化网站的网页开发者和企业来说，常常会想：这段代码可靠么？是否安全？在实施前是否需要审查？这些问题都归结为一个核心疑问：谁将对 AI 辅助的编码负责？更重要的是，生产力提升的归属是谁？

如果 AI 使工程团队在相同时间内完成更多工作，那么每个人都能从这份经济价值中受益。这可能是开发者节省时间，雇主从节省的工时中获得更多价值，或客户在付费后仍有余暇获得服务。无论节省的时间如何带来收益，最关键的是工作如何被治理和定价。

AI 与编码正变得不可避免

AI 编码工具正迅速获得关注，并进入主流开发领域。根据 2025 Stack Overflow Developer Survey，84% 的受访者已经在或计划在其开发流程中使用 AI 工具。

尽管在网页开发者的工作流中引入 AI 正变得越来越普遍，但人们仍对其可靠性持保留态度。同一调查发现，46% 的受访者对 AI 输出的准确性缺乏充分信心，约有 66% 的人将 AI 解决方案“几乎正确，但并不完全”视为令人沮丧的来源。

正在形成的 AI 编码争论更多关注其可靠性，而不是代码是否创造更多价值以及谁应对其保证负责。

AI 正打破工时与产出之间的关系

软件开发的报酬始终基于工程产出与工程投入密切相关的假设。然而，生成式 AI 现在使这一等式变得复杂。

一项涉及 95 名开发者的受控实验发现，使用 GitHub Copilot 的参与者完成特定的 JavaScript HTTP 服务器任务的速度比未使用者比未使用者快 55.8%。

这表明 AI 能加速开发，且可能不牺牲质量。但这些数据之所以成功，仅因为实验采用了极其特定的编程任务。虽然任务完成更快，这并不意味着 Copilot 能让整个工程组织的生产力提升 55.8%。

另一项研究阐明了这一观点。涉及 96 名全职 Google 软件工程师的试验发现，使用 AI 的开发者完成企业级任务约需 96 分钟，而未使用的则需 114 分钟。研究人员的调整后估计显示，完成时间约减少了 21% 的完成时间缩短。然而，研究并未探讨 AI 代码的质量，也未涉及对技术依赖的公平性问题。

也有证据表明 AI 会放慢编码速度。METR 的随机研究涉及 16 位经验丰富的开源开发者，他们在熟悉的代码库中处理了 246 个真实问题。使用 2025 年初可用的工具，包括 Claude Sonnet 3.5、3.7 和 Cursor Pro，他们完成任务的时间大约延长了 19%，尽管许多人原本认为这些工具会节省时间。

这些研究共同颠覆了 AI 能让开发者更快工作的预期。相反，它使提供网页服务的企业以及接受服务的客户的开发者时间和价值变得更不可预测。

鲜有人谈论的定价难题

时间与材料（T&M）是网页开发中常用的采购软件模式，因为它解决了行业中反复出现的一个问题：项目的不断演进。

采用此模式，客户无需在开发开始前定义每个功能或任务，而是可以随着项目的进展和变化，为工程时间付费。

然而，AI 正在给这一经验证的模式带来阻碍。由于报酬直接与工程工时挂钩，更高效的开发时间可能导致客户的计费工时减少。如果 AI 能在更短时间内实现相同结果，技术可以为客户创造价值，但计费工时的减少意味着提供者的收入下降。

解决方案并不是鼓励开发者放慢工作速度。T&M 模式如今在定价和激励设计上面临结构性问题。仅凭时薪来决定价值可能受到限制。买家可能清楚每个工程小时的成本，却仍不确定实现预期结果所需的总投资。

随着 AI 改变工程生产力，问题可能会从以下方面转变：

• “开发者每小时的成本是多少？” → “当所需的开发者工时减少时，价值会发生什么变化？”

METR 的研究结果使这个问题更加复杂。如果开发者认为自己可以节省时间，而实际上却花费更久，那么 AI 的采用或感知的生产力提升都不足以证明其财务价值。这就是为何组织需要能够衡量实际发生情况的治理机制。

治理缺口有四个所有者

讨论 AI 辅助开发的治理需要超越仅规范开发者可使用工具的政策。

工程组织应定义至少四种所有权类型。

1. 代码的所有权归谁？

AI 能生成实现代码，但它不能成为免除责任的借口。仍需有人对代码进行审查、测试和批准，直至其进入生产阶段。

2. 风险的所有权归谁？

更快的代码只有在不导致其他问题时才有价值。AI 生成代码的实证研究发现，所检查的 Python 代码片段中有 29.5% 存在安全漏洞，JavaScript 代码片段中有 24.2% 存在安全漏洞。研究还发现这些漏洞涉及 43 个通用弱点枚举（CWE）类别。

然而，研究发现，将静态分析警告反馈给 Copilot Chat 可修复高达 55.5% 的已识别安全问题。该研究展示了 AI 能产生并解决编码问题，但组织需要相应的流程来确定如何验证其输出。

NIST’s SP 800-218A通过在其安全软件开发框架中加入针对生成式 AI 和双用途基础模型的最佳实践，体现了这一原则。

3. 生产力提升的所有权归谁？

从一开始的商业协议对于确定谁应获得效率提升至关重要。AI 可以帮助客户降低支出，使团队交付更多软件，或在项目结束时不产生任何财务收益。

始终不变的是需要透明的流程以及交付质量合规的工作。

4. 优先级决策的所有权归谁？

AI 可以让功能生成更便宜、更快速，但它无法决定这些功能是否必要。

事实上，开发能力的提升可能使优先级决策更加重要。当团队能够更快地构建和实验时，仍需有人判断哪些成果值得投入预算，哪些想法应被放弃。

AI 治理正成为财务问题

这些问题使 AI 治理日益重要。设想有两家开发合作伙伴收取相似的时薪。

一家将 AI 融入强大的工程流程，并显著更快实现所需成果，而另一家则耗时更长。仅比较时薪并不能让买家了解他们将采用的流程。

买家需要评估：

• 预期总投资
• 超支责任
• AI 生成工作质量控制
• 效率提升的分配方式

如果双方有意识地接受服务中的不确定性，T&M 仍可对双方有用。当需求和交付物稳定时，固定价合同也可行。

但 AI 也使得探索替代结构变得值得。一种做法是设定最高财务上限，同时保持范围灵活。随后，可在该模型内根据业务价值对功能进行优先级排序。

如果工程效率提升，收益可以转化为额外的产品功能，而非额外的计费时间。商业激励应与工程激励保持一致，尽可能高效地创造更有用的软件。

相同的 AI 对话

工程领袖需要了解商业激励如何影响交付。财务和采购团队需要充分了解 AI 辅助工程，以评估所宣称的效率是否带来可衡量的价值。

这意味着成熟的 AI 治理不能仅止步于已批准的模型清单、安全控制、数据政策或代码审查要求。它还需涉及责任、财务风险、优先级以及生产力提升的所有权。

但还有第二个所有权问题，对技术预算的影响可能更大：当 AI 改变软件构建速度时，价值的创造或损失归谁所有？

能够决定更快的工程是否真正产出更好产品、掌控投资并实现可衡量业务成果的组织，将能够在竞争中保持领先。

如果你的开发团队明天采用 AI，你当前的治理和商业模型是否还能告诉你它是否提升了交付的价值？