人工智能正在摧毁我们所说的“信任”

一句话看懂：一篇来自 terriblesoftware.org 的评论指出，AI 让代码、文档和答复变得唾手可得，也让人可以在完全不理解内容的情况下交出”成品”，团队协作中默认的信任前提正在被破坏。这不是工具能力问题，而是协作流程和职业承诺需要重新定义。

事件核心：发生了什么

作者用 1900 年代初美国从马车转向汽车的阶段做类比：技术已经换代，人的习惯还没跟上，适应过程本身就痛苦。他描述的具体变化是，过去收到 PR（代码合并请求）或方案文档时，默认对方至少读过、做过功课；现在这个默认不再成立。于是他评审时的第一个问题从”这个改动好不好”变成了”作者到底理解自己发过来的东西吗”。

他承认自己也曾把一份 AI 生成的修复直接合入而没有真正理解，修复本身正确，但他没有验证。文中还提到一些可识别的信号，比如”是的——真正的关键点在于……”这类措辞会让他起疑；追问一个具体问题时收到另一段明显由 AI 生成、却没回答问题的解释，会直接降低他对该作者后续提交的信任度。

为什么重要

信任在工程协作里的实际作用是省步骤：信任一个人，就可以只看需要第二双眼睛的部分，而不必重走他的整个调研过程。AI 大模型把”产出”和”理解”解耦之后，评审成本被推高，团队整体吞吐反而可能下降。对行业而言，这意味着代码评审、技术文档、设计评审这些流程的默认假设需要重写；对企业而言，”署名”的含义、以及如何区分”已验证的成品”和”待讨论的早期想法”，会成为协作规范的一部分。

对用户/开发者/创作者的影响

开发者被建议在提交前先读自己的 diff、想清楚 bug 为什么发生、这个修复为什么有效，并主动说明测了哪些场景。使用 Claude、ChatGPT 等工具没有问题，但在把答案转发给同事前，要自己判断它是否切题、是否过长。评审方也可以直接追问”你测了哪些用例””是什么让你得出这个建议”，这类问题应当被视为正常而非冒犯。