AI原生工作报告2026

从信任鸿沟到可靠协作的十个关键词 我们正在经历一场前所未有的协作革命。人与AI之间，正在生长出一种全新的信任关系，它不来自完美，而来自持续的校准与驾驭。这份报告用十个关键词，记录我们正在走的那条学习曲线。 目录 序言 信任鸿沟：可靠不等于不出错，可靠是出错之后还能接住 人设计环境，AI在环境中执行；核心范式跃迁 人类工程师始终是这场演出的导演 关键词2记忆 关键词7多智能体 精确遗忘比完美记忆更重要 用好一个，再用多个，可以打开更大的世界 关键词8加法偏见 关键词3技能 最好用的，是自己持续维护的skills 加法是能力，减法是智慧。 关键词4评估 可靠的评估与反馈是方向盘，是质量的前提 关键词5上下文 关键词10知识工程 方法会过时，工具会迭代，最终留下什么 停止把你的人生故事放进去 研究团队 产品支持黄广民孔德远汪晟杰设计支持崔昭 序 信任鸿沟：可靠不等于不出错，可靠是出错之后还能接住。 每个用AI的人都在走一条学习曲线。从惊艳到怀疑，从怀疑到找到自己的节奏。这条路没有捷径，但有方法。我们从这里开始聊。 司晓 腾讯副总裁腾讯研究院院长 这是一个隐蔽的成本转移：AI把“写”的工作量砍下来了，但把“查”的负担顶上去了。查的成本一旦超出预期，人们的反应不是更仔细地查，是不查了。嘴上的不信任是安全的。手上的放行才危险。 84%采用vs 29%信任 为什么用了≠用好了 2023年，全球最大开发者社区Stack Overflow的年度开发者调查显示AI编程工具的信任度是40%。两年后，采用率从70%升到了84%。信任度降到了29%。用得越多，信得越少。为什么我们很少见到一个技术是这样的？ 更自信，但更差 除了上述的行为失控，还有更麻烦的感知失真，也就是说，你甚至不知道自己的判断已经偏了。斯坦福大学DanBoneh团队在CCS 2023（计算机安全顶会）上发了一项随机对照实验。用AI助手的参与者在多数安全编程任务中写出了更多不安全的代码。写出不安全代码的那批人，对AI的信任评分反而更高。你越觉得它帮了你，它越可能在坑你。这时候你可能会说，经验丰富的开发者是否可以避免这个问题？AI安全评估机构METR在2025年做了另一个实验。16名经验丰富的开源开发者，在自己贡献多年的仓库上干活，用的是前沿模型。结果：实际慢了19%。自我感觉快了20%。感知和现实之间差了39个百分点。研究团队也指出，在不熟悉的代码库或简单任务上，AI可能确实有帮助。但在高质量标准和复杂隐含要求的场景下，验证和整合AI输出的开销把速度收益吃回去了。两种情况下，人们对自身表现的判断都偏向乐观。要么留下了风险代码，要么增加人工检查，反而导致效率下降。用了，并不一定等于用好了。 这个不是简单的信任问题。Stack Overflow自己的分析给了一个精准的判断：这是一条学习曲线，伪装成了信任问题。这句话值得琢磨。以当前AI应用最广的领域为例，软件工程师的职业训练建立在确定性上。写同样的函数，传同样的参数，得到同样的结果。然而，当AI来了。同一个问题问两遍，两个答案，两种结构，两套取舍方案。都能跑。对于严谨的工程师来说，这样的特性，需要一个适应过程。这种感受不是程序员独有的。律师期望同一条法规的检索结果稳定一致，医生期望同一组指标指向确定的诊断方向，金融分析师期望同一套参数产出可复现的估值。概率性系统进入确定性职业的地盘，遇到的不是能力质疑，是一种更原始的不适：认知摩擦。但信任低，不意味着人们在验证。就目前来说，人们对于AI的信任偏差并没有形成体系的方法论来约束它，利用好它。 300行代码，居然全错 96%不信，48%不查 在更多的真实场景里呢？一位工程师在FDA（美国食药监局）监管的医院基础设施中用ClaudeCode，AI写了300行OpenTofu基础设施代码。语法完美。逻辑表面合理。通过了验证流程。但是，它引用的资源和配置，有很大一部分是编的，事实上并不存在。在许多专业领域当中，AI应用需要更为谨慎，因为在基础模型预训练阶段，这些资源配置和边界条件，没有在训练数据中覆盖。大量的实际应用，是需要做边界判断的，不是仅仅考虑语法逻辑，语法AI早就会了。AI知道语法。不 另一组非常矛盾的行为数据。代码质量平台Sonar的调查揭了一组更值得琢磨的数字：96%的开发者不完全信任AI代码的功能正确性。但只有48%的人在提交前始终检查。几乎所有人都说“我不信”，一半人说完就点了提交。为什么不查？不是因为懒。38%的开发者觉得审查AI代码比审查人类代码更费力。为什么更费力？AI产出“看起来正确但不可靠”，不像语法错误会让构建直接失败，AI写出来的是看着合理的逻辑，bug藏在里面，需要更高的专业判断力才能揪出来。 曲线：第一阶段，形成。初次接触，基于能力线索建立期望，通常偏高。第二阶段，冲击。一个可见错误，信任断崖式下降。人对AI的容错度比对人低得多，研究者称之为“完美自动化图式”，你下意识觉得机器就应该是对的，有幻觉即不可用。第三阶段，修复。解释为什么出错，指出系统边界。信任部分恢复。意外的发现在第三阶段：修复后的信任可以超过初始基线。经历过错误并被正确解释的信任，比从未经历过错误的信任更结实。研究者称之为“信任加速悖论”。你信任一个医生，不是因为他从来没误诊过，而是因为你见过他发现误诊后怎么纠正、怎么坦诚、怎么调整方案。可靠不等于不出错。可靠是出错之后怎么处理。所以，我们应该做的，从来不是追求完全信息、零幻觉、零失败，而是设计“可控失败+透明修复”的流程。 知道的是这个FDA环境下哪些资源存在、哪些配置合规、哪些边界不能跨越。这不是知识问题，是判断力问题——它不理解上下文，不理解后果，不理解地“如果这样做会怎样”。法律合规、金融审计、医疗决策、科研创新，同一种困境。训练数据覆盖不了特定环境的边界条件。它不知道自己不知道。而语法完美但语义虚构的产出，恰恰最难被发现，因为它通过了所有表面的检验。 一个必经的过程，失败后的信任比从未失败的更强 如何重建信任，更准确的说，应该沿着学习曲线与AI更好的协作，我们再来看首尔国立大学做的两个实验，样本分别为189人和294人。他们发现信任不是一个静态指标，而是一条有形状 可控性的分寸在哪里 OpenClaw等Agent工具。原因正是这个分寸：我们的研究日常复杂度高，需要在过程中持续审查、持续介入，IDE形态让我们留在驾驶座上。而对大多数白领场景，Wordbuddy的对话形态更友好、上手更快。工具没有高下，匹配你需要的控制粒度就是对的。另外，配套的一个脑电实验发现，长期使用AI的人在神经和行为层面持续表现不佳。研究者管这叫“认知债务”。你以为在省力，其实在预支判断力。过度依赖还有个副作用：开发者花时间调提示词，而不是和同事讨论问题。跟机器对话多了，跟人对话就少了。因此，我们还会在人机协作的过程中，有意识的保留人工讨论环节与比例，以确保AI和人之间的互动的同频共振，维护人的判断力、理解力，实现对AI的可持续的驾驭能力。这是一个健康的人机协作组织应具备的长期能力。 软件工程顶会FSE2026的一篇论文提出了依赖-控制二维框架。22名开发者访谈，信任问题可以用两个轴来画：纵轴是依赖程度，横轴是控制程度。“甜点”在平衡控制与适当依赖的交叉点。具体什么样？AI生成初始测试场景，开发者改进，测试驱动开发的迭代中AI和人交替工作，人始终在驾驶座上。Vibe coding（氛围编程，即“你来写我不管了”）在矩阵的另一端。你交出了控制权，同时也交出了理解力。不同的工具形态天然推向不同的依赖水平。关键不在于用哪个工具，而在于使用过程中你保留了多少主动检查和决策的环节。经常有朋友问，研究院为什么选了面向开发者的CodeBuddyIDE，而不是对话式的 并不是简单推广，就有回报 为什么要写这份报告。 过去一年，我们和很多团队聊过，发现大家遇到的困惑高度相似，不缺工具，但不确定怎么用对。我们自己也在摸索，踩过不少坑。把这些经验和教训整理出来，是希望AI带来的效率红利不只属于少数技术团队，而是能被更多人、更多组织真正用上。信任鸿沟不是一个需要解决然后翻篇的问题。它会一直在那儿。这不是坏事。对一个概率性系统保持警觉，本身是健康的。问题从来不是“你信不信AI”，而是“你的信任是否经过校准”。理解这种张力是第一步。 把镜头再拉远一点，组织层面的故事更让人难受。以下是一组权威数据，MIT斯隆管理学院的数据：95%的企业AI试点未产生可衡量的业务回报。88%的组织在用AI，但仅7%真正整合进了业务流程。BCG（波士顿咨询）和哥伦比亚商学院发现了高管和员工之间的感知断层：76%的高管认为员工对AI充满热情，实际只有31%的一线员工有此感受。42%的高管层承认AI采用正在“撕裂公司”。31%的员工承认主动破坏AI推广。 《福布斯》技术委员会给了另一个视角，四类抵触，每一种都是组织在发出信号：一、工具抵触：试过了，发现不好用。比如，法律团队拒绝用合同分析AI，可能不是守旧，是出于保护公司的优先级。二、策略抵触：AI部署的位置和价值位置不匹配。半数预算流向销售和营销工具，但数据显示最高回报来自组织、后台自动化。三、信任抵触：领导层说“AI是来增强你的”，同时宣布裁员目标。很难让员工信服，这不是恐技心理，是对矛盾信号的理性回应。四、能力抵触：只有44%的人接受过AI培训，甚至57%的人不愿告诉团队自己在用AI，怕暴露自己“用了但不确定用得对”。MIT研究者的总结一语中的：规模化的核心障碍不是基础设施、不是监管、不是人才，是学习。 接下来，我们会通过〸个关键词展开讨论。 参考文献： 1.Stack Overflow, "Mind the Gap: Closing the Developer AI Trust Gap", 2026-02-18.https://stackoverflow.blog/2026/02/18/closing-the-developer-ai-trust-gap/↩2.Sonar, "The AI Trust Gap: Why Code Verification Matters", 2026-01-22.https://www.sonarsource.com/blog/ai-coding-trust-gap3.Perry N, Srivastava M, Kumar D,BonehD, "Do Users Write More Insecure Code with AIAssistants?", ACM CCS 2023.https://arxiv.org/abs/2211.036224.METR, "Measuring the Impact of Early-2025 AI on Experienced Open Source DeveloperProductivity", 2025-07-10.https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/5.HeinanCabouly, "The AI Wrote 300 Lines of Infrastructure Code—None of It Was Real",2026-04-15.https://medium.com/@heinancabouly/the-ai-wrote-300-lines-of-infrastructure-code-none-of-it-was-real-4cf3fd7c0a4a6.Han J, "Trust Formation, Error Impact, and Repair in Human–AI Financial Advisory",Behavioral Sciences 15(10), 2025.https://doi.org/10.3390/bs151013707.Ferino