30% 的开发者不信任 AI 代码法院却要求“行业通行措施”把 DORA 报告的信任缺口对上生成式 AI 的可靠性义务一条裂缝的两端2025 年的软件行业出现了一个耐人寻味的组合一边是调查显示 AI 已几乎普及另一边是法院开始要求 AI 服务提供者承担“可靠性”义务。这两件事看似分属技术和管理两个世界实际上指向同一个问题——当 AI 生成的产物直接进入生产环境谁来保证它是对的本文把两份公开材料并置来讨论这个问题一是 DORA 2025 年 AI 辅助软件开发状态报告中文译文见《[译]doraai 辅助软件开发状态报告》二是新华网报道《AI提供的信息不靠谱开发者要担责吗》。前者描绘了开发者群体内部的信任缺口后者确立了服务提供者在法律上的可靠性义务。把它们放在一起看你会发现团队无论对内对外需要的其实是同一套东西可验证的工程实践。DORA 报告采用普及了信任没跟上先看技术侧的数据。根据《[译]doraai 辅助软件开发状态报告》这份报告基于 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 日梁先生真的起诉了。法院的裁判要点有两层AI 不具有民事主体资格不能作出具有法律约束力的意思表示——AI 自己“承诺”的 10 万元赔偿当然不算数。生成式 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 的调研还是这份判决都在催促我们把控制系统升级上去。参考资料以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中资料内容与适用范围以原始页面为准。[\[译\]doraai 辅助软件开发状态报告](https://blog.fleeto.us/doraai)新华调查丨AI提供的信息不靠谱开发者要担责吗-新华网