30% 的开发者不信任 AI 代码，法院却要求“行业通行措施”：把 DORA 报告的信任缺口对上生成式 AI 的可靠性义务

发布时间：2026/10/27 2:05:07
30% 的开发者不信任 AI 代码，法院却要求“行业通行措施”：把 DORA 报告的信任缺口对上生成式 AI 的可靠性义务

30% 的开发者不信任 AI 代码，法院却要求“行业通行措施”：把 DORA 报告的信任缺口对上生成式 AI 的可靠性义务

一条裂缝的两端

2025 年的软件行业出现了一个耐人寻味的组合：一边是调查显示 AI 已几乎普及，另一边是法院开始要求 AI 服务提供者承担“可靠性”义务。这两件事看似分属技术和管理两个世界，实际上指向同一个问题——当 AI 生成的产物直接进入生产环境，谁来保证它是对的？

本文把两份公开材料并置来讨论这个问题：一是 DORA 2025 年 AI 辅助软件开发状态报告（中文译文见《[译]dora：ai 辅助软件开发状态报告》），二是新华网报道《AI提供的信息不靠谱，开发者要担责吗》。前者描绘了开发者群体内部的信任缺口，后者确立了服务提供者在法律上的可靠性义务。把它们放在一起看，你会发现团队无论对内对外，需要的其实是同一套东西：可验证的工程实践。

DORA 报告：采用普及了，信任没跟上

先看技术侧的数据。根据《[译]dora：ai 辅助软件开发状态报告》，这份报告基于 2025 年 6 月 13 日至 7 月 21 日期间的定性研究与全球调研，几个关键发现值得细读：

  • 采用几乎普及，但信任不足：90% 的受访者在工作中使用 AI，超过 80% 认为它提升了生产力，但仍有30% 的人表示对 AI 生成的代码几乎没有信任。报告明确指出，这说明“验证与批判性能力”仍然关键。
  • 吞吐量上升，稳定性下降：与上一年相比，采用 AI 提升了软件交付的吞吐量，但同时降低了交付的稳定性。用报告的话说，团队在加速，但底层系统尚未能应对这样的交付效率。
  • 需要系统化建设：DORA 的 AI 能力模型识别了七个基础实践（如明确的 AI 政策、健康的数据生态、用户中心化），它们能够放大 AI 对组织绩效的积极影响。

报告里引用的加州大学伯克利分校研究也很说明问题：眼动追踪数据显示，在解释复杂代码这类需要深层理解的任务中，开发者对 AI 聊天的视觉关注度不足 1%，而在安装依赖等机械性任务中接近 19%。换句话说，开发者并非盲目信任 AI——他们在自己能验证的领域用得欢，在难以验证的领域本能地回避。

报告作者给出的诊断很直接：当 AI 显著加速软件开发时，我们的控制系统——也就是开发者自身——也必须随之加速。30% 的不信任，本质上不是“AI 太差”，而是团队现有的验证手段跟不上 AI 的生成速度。

杭州互联网法院：法律侧给出了“行业通行措施”标准

再看法律侧。新华网报道《AI提供的信息不靠谱，开发者要担责吗》记录了一个很有代表性的案件：用户梁先生发现某 AI 应用提供的信息有误，AI 却坚称无误，甚至“承诺”赔偿 10 万元并建议他去杭州互联网法院起诉。2025 年 7 月 25 日，梁先生真的起诉了。

法院的裁判要点有两层：

  1. AI 不具有民事主体资格，不能作出具有法律约束力的意思表示——AI 自己“承诺”的 10 万元赔偿当然不算数。
  2. 生成式 AI 服务提供者应履行两项义务：服务功能的显著提示说明义务（采取有效提示措施，让公众认知 AI 的功能局限），以及功能可靠性的基本保障义务（采取行业通行技术措施，不断提高生成内容的准确性和可靠性）。

本案中，该应用已在页面醒目位置提示“内容仅供参考，请仔细甄别”，法院经调查确认开发者“确实采用了可行的技术手段，力求降低错误发生”，最终认定其无过错、不构成侵权，驳回了原告请求。

报道中法官肖芄的解释点出了关键：基于当前生成式 AI 几乎不可避免会出现信息偏差，界定开发者是否有过错，就要考查其“是否使用了当前行业内通行并被证明有效的措施，来提升技术可靠性，降低错误发生的概率”。换句话说，法律并不要求 AI 永远正确——它要求你用了行业中通行的、被证明有效的措施去降低错误概率，并且明确告诉用户它可能出错。

两个世界，同一个答案

把两份材料并置，会发现一个巧妙的对应关系：

组织内部（DORA 视角）组织外部（法院视角）
30% 开发者不信任 AI 代码用户可能因错误信息受损而起诉
需要“验证与批判性能力”需要“行业通行技术措施”
交付稳定性下降是组织风险过错认定以是否尽保障义务为准

对内，团队需要一个能让人信任 AI 产出的验证流程；对外，提供 AI 能力的服务方需要能证明自己采取了通行措施并做了显著提示。这不是两套工作，而是同一套工程实践的两个面向。

具体怎么做：给团队的建议

1. 把“验证”做成流程，而不是美德。DORA 报告指出的吞吐量升、稳定性降，最直接的解药就是强化交付管线的自动化验证：测试覆盖、静态检查、渐进式发布。AI 生成得越快，验证管线就越需要快——否则你只是在更快地生产风险。

2. 让 AI 的行为可配置、可约束。报告提到，大多数 IDE 已支持切换行内建议开关、启用“仅按需”模式、调整建议风格；代码库级的配置文件与关联文档也能帮助 AI 助手遵循既定规范。团队应把这些配置纳入统一管理，而不是留给每个人自行摸索。

3. 区分任务的“验证成本”。伯克利研究的启示是：机械性任务（样板代码、依赖安装）验证成本低，可以放心用 AI；解释性、理解性任务验证成本高，团队应明确要求人工深度介入，而不是一刀切地“全面拥抱”或“全面禁止”。

4. 如果你对外提供 AI 功能，提示要显著、措施要留痕。参照杭州互联网法院的裁判逻辑：“内容仅供参考，请仔细甄别”这类醒目提示，加上可证明的技术手段投入，构成了无过错认定的基础。反之，如果你的产品界面让用户误以为 AI 输出等同于专业意见，风险就转到了你这边。

5. 用价值流管理放大局部收益。DORA 报告特别强调，价值流管理（VSM）通过可视化和改进从创意到客户的工作流，是 AI 的“倍增器”，能确保局部效率提升真正转化为产品质量和团队效能——而不是变成稳定性债务。

适用范围与局限

这套讨论有明确的边界，值得说清楚：

  • 案件本身较特殊。新华报道指出，本案中原告未因误导性信息遭受明显的人身财产损失，且其使用的是通用生成式 AI 应用，而非行业化应用或搭载 AI 的机器人。受访法律界人士也认为，要求 AI 开发者一概为生成内容的准确性负责“既不现实也不合理”。因此不能把本案判决直接外推为“AI 出错服务商永远免责”。
  • DORA 数据是调研结论，不是因果证明。30% 的不信任和稳定性下降是特定时期全球调研的发现，具体到某个团队，情况可能不同——但“验证能力必须跟上生成速度”这个方向性判断，与十余年 DORA 研究的整体脉络是一致的。
  • 技术局限是客观存在的。报道中业内人士指出，当前生成式 AI 基于词元预测，底层架构不变则信息偏差不可避免；还引用清华大学沈阳团队报告称多个热门大模型事实性幻觉率超过 19%，以及“数据集中仅 0.01% 和 0.001% 的虚假文本，模型输出的有害内容也会分别增加 11.2% 和 7.2%”的训练测试案例。这既解释了为什么法律不苛求绝对准确，也解释了为什么 30% 的开发者不信任并非杞人忧天。

结语

DORA 报告的 30% 不信任，和法院要求的“行业通行措施”，其实是同一个时代的两面。对开发者个人，答案是把批判性验证当作新的核心技能；对团队，答案是把验证做成管线和平台能力；对服务提供者，答案是显著的提示加上可证明的技术投入。共同点是：责任既不能推给模型，也不能推给用户，只能落在一套可验证、可留痕的工程实践上。

AI 把开发速度提到了 50 英里每小时，而我们的控制系统还停留在步行时代——无论是 DORA 的调研还是这份判决，都在催促我们把控制系统升级上去。

参考资料

以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中；资料内容与适用范围以原始页面为准。

  • [\[译\]dora：ai 辅助软件开发状态报告](<https://blog.fleeto.us/doraai>)
  • 新华调查丨AI提供的信息不靠谱，开发者要担责吗-新华网