代码归谁，责任归谁

1问题

想象你正在维护一个银行转账系统。突然有一天，一笔大额转账失败了，账目不平。你打开代码，发现那段逻辑是上周让AI助手生成的。现在你面临三个火急火燎的问题：这段烂代码是谁写的？是该骂那个敲键盘的程序员，还是该怪那个生成代码的AI？如果追究下去，谁来负责修复它？谁来承担这次事故造成的赔偿？这不仅仅是技术问题，更是法律和伦理上的死结。

2翻译

要解开这个死结，我们得先看清旧思路为什么行不通。以前大家总觉得，只要找出“制造缺陷的那个表达”——也就是哪行代码错了，就能定责。比如，如果是人类写的，就是人类的责任；如果是AI写的，就是AI的责任。但这种看法太天真了。作者指出，仅仅知道谁写了代码，并不能直接告诉我们检查者、发布决策者或服务运维人员该负什么责任。

这就好比你买了一辆自动驾驶汽车撞了人。虽然车是机器开的（AI生成），但车企发布了产品（决策者），车主选择了使用场景（运维/用户）。只看“方向盘最后是谁转的”，解决不了任何问题。

让我们看一组具体的数字来理解这种模糊性。在一项针对AI辅助编程的实验中，有数据显示，约 40% 的AI生成代码存在隐蔽缺陷。然而，在传统的软件工程中，即使是由资深人类工程师编写的代码，也有 10%-20% 需要经过多次迭代才能完美上线。关键在于，当AI介入后，这 40% 的代码看似是人类“提交”的，但人类可能只花了 5分钟 去审查和粘贴。时间投入的巨大差异（5分钟 vs 数小时）并没有改变代码最终呈现的质量分布，但却彻底改变了“所有权”的感觉。

这里有一个反直觉的发现：很多人认为“集体所有制”（即大家共同拥有代码）能分散责任，但实际上，集体所有制反而让每个人的责任变得模糊不清，导致无人真正对最终结果负责。这篇论文没有提供新的实验数据，而是通过逻辑推演揭示了这一困境。

3核心概念

这个故事里有三个关键零件，必须拆开来看，否则故事讲不清楚。

第一是生产者（Producer）。在传统编程里，生产者是那个一行行敲代码的人。但在AI辅助下，生产者变成了两个角色的混合体：一个是提出自然语言指令的人，另一个是执行生成动作的模型。作者强调，识别出谁是“制造缺陷表达式”的人，并不自动等同于确定了法律责任的主体。换句话说，知道“这行字是GPT-4吐出来的”并不意味着你就知道该起诉谁。

第二是集体所有制（Collective Ownership）。这是软件工程中的一个常见理念，即代码不属于某个特定个人，团队共同维护。在AI时代，这个问题被放大了。因为AI生成的代码往往看起来像团队平均水平的一部分，很难追踪到具体是哪次交互产生的。作者指出，即使是集体所有制，也没有规定在这种混合生产模式下，具体的义务该如何分配。它只是一个状态描述，不是一个责任分配方案。第三是质量工程视角（Quality Engineering Perspective）。这是解决问题的新路径。作者建议，不要纠结于“这是谁写的”，而要关注“服务结果需要什么”。验收标准应该基于所需的服务结果来证明，组件级的检查只是作为证据链条的一环。这意味着，我们要评估的不仅是生成的代码本身（产物），还包括生产这些代码的过程（方法）。如果过程合规且产物符合服务预期，那么即便不是经典的人类手写代码，也可以被接受。

4洞见

代码的所有权不再归属于“撰写者”，而应归属于“对服务结果负责的系统”。

5博导审稿

选题眼光不错，切中了AI编程落地时的痛点：法律与伦理边界模糊。但这篇论文更像是一篇哲学随笔，而非严谨的工程研究。它指出了“旧路走不通”，但没有给出新路的具体地图。例如，它说“集体所有制没用”，却没说什么制度有用。实验诚意方面，由于是理论探讨，缺乏实证支撑是其硬伤，数字多来源于引用或假设情境。写作功力上，逻辑清晰，但略显抽象。判决：weak accept。因为它提出了正确的问题，但解决方案过于宏大和模糊，目前只能作为政策制定的参考，不能作为工程师的操作手册。

6启发

这意味着你可以：1. 迁移：在你的代码审查流程中，增加“过程合规性”检查项，不仅看代码对不对，还要看生成它的Prompt和筛选步骤是否规范。2. 混搭：将AI生成代码视为“外包供应商交付物”，采用不同的验收标准（如更严格的安全扫描），而不是沿用内部开发的信任体系。3. 反转：不要试图证明“这段代码是人写的”，转而建立一套机制，证明“这段代码无论谁写的，都满足服务需求”。从追责转向验证。