到2028年，企业会把AI编程工具的执行记录纳入验收

我把这句话写在 2026 年 8 月：到 2028 年底，AI 编程工具的执行记录会成为一部分企业验收和审计流程里的正式材料，而不再只是开发者排查问题时临时打开的调试日志。

我这样想，首先来自做轨迹分析时看到的实际差异。在一组 250 个用例里，同一个最终分数可能对应完全不同的过程：有的任务只是漏掉了最后一次检查，有的任务反复读取同一文件，直到上下文接近上限；有的最终答案看起来完整，实际执行时却没有遵守最初约束。只保存用户问题和最终回答，无法区分这些情况，也看不出一次失败究竟应该由模型、工具配置还是工作流承担责任。

外部标准也已经开始补这一块。OpenTelemetry 的生成式 AI 语义约定中，已经出现 invoke_agent、invoke_workflow 和 execute_tool 等操作，并为工具调用参数、结果和异常定义了记录方式。它目前仍在持续发展，离各家实现完全一致还有距离，但说明行业正在尝试用统一语言描述 Agent 做过的事情。NIST 的 AI 风险管理框架及配套材料，也一直强调测试、评估、验证、确认和部署后的持续监测。这些要求落到能够修改代码、运行命令的 AI 编程工具上，仅看最终文本显然不够。

我认为推动这件事的主要力量不会是开发者想看更漂亮的图表，而是企业要回答几类很现实的问题：一段代码是谁改的，AI 在修改前读取了哪些文件，它是否接触了不该接触的数据，调用外部工具时传出了什么，测试为什么没有发现问题，事故发生后能不能复现当时的路径。只要 AI 从建议者变成实际执行者，这些问题就不会因为模型效果变好而消失。

为了避免几年以后凭印象解释“我当时说对了”，我给这项预测设定五个可以检查的迹象。到 2028 年 12 月 31 日，如果其中至少三个已经普遍出现，就说明这件事基本成为现实：

1. 主流企业级 AI 编程产品默认提供任务级执行记录或回放，而不是只保留对话。
2. 企业采购、安全审查或研发合规流程明确要求保存工具调用、文件变更和运行结果。
3. 通用遥测规范已经稳定覆盖 Agent、工作流和工具调用，并被多家主要产品采用。
4. 评测平台能够导入不同模型和不同 Harness 的轨迹，用统一结构比较失败原因。
5. AI 编程引发的生产事故复盘，会把执行轨迹作为证据，而不只展示提示词和最终输出。

反过来，如果届时大多数产品仍然只向企业提供输入、输出和一张笼统的成功率报表，采购与安全流程也没有提出更细的记录要求，那我今天的预测就是错的。也可能出现另一种结果：完整记录确实存在，但因为成本、隐私或信息量过大，只在少数高风险行业使用。那只能算部分成立，不能把个别案例当成行业共识。

我暂时把复盘日期定在 2028 年最后一天。两年多的时间足以让今天还在发展的规范走过一轮落地，也足以看清企业究竟把轨迹当成调试功能，还是当成正式的工程凭证。到时候回来补上结果。