很多人把 AI 生成代码的风险理解成“语法错误”。这类问题反而好处理编辑器会标红测试会失败接口会直接报错。真正难发现的是一段八九千字符的脚本经过工具调用、终端输出和网络传输后只剩下前半截却仍然是一段看起来完整、甚至能够运行的 JavaScript。如果缺失的是最后一个通知、补偿或权限判断故障不会立刻出现而会在某个业务分支里悄悄积累。为此我把 Microi吾码AI 的长源码保存过程拆成三道门先查内容污染再查异常缩短最后对不确定写入做远端回读。01静默截短为什么比报错危险报错是一条清晰证据静默截短却常常披着“成功”的外衣。比如AI 在读取超长文件时收到了一段被宿主压缩过的输出其中混入…676 tokens truncated…它又把这段展示文本当成原始源码提交。保存接口可能正常返回脚本前半段也可能语法闭合但业务真实意图已经丢失。另一种情况更隐蔽新版本确实是一段合法源码只是长度从 12,000 字符突然降到 3,000。单看语法、返回码和更新时间都无法证明这是有意重构还是上游把长内容截掉了。保存成功不等于保存了用户想保存的全部内容。02第一道门先识别“工具输出污染”源码字段里不应该出现工具运行包装信息。像Exit code:、Chunk ID:、Wall time:以及带有tokens truncated的省略提示都属于高风险信号。门禁不只扫描顶层字符串还要继续检查字符串化 JSON 中的嵌套源码字段否则污染可能藏在 payload 里面绕过检查。const suspicious [ /tokens? truncated/i, /…\s*\d\stokens? truncated\s*…/i, /^Exit code:/m, /^Chunk ID:/m, /^Wall time:/m, ] if (suspicious.some((rule) rule.test(source))) { throw new Error(拒绝保存源码疑似混入工具输出) }这里要避免另一个极端不能因为正常代码字符串中出现某个普通单词就误杀。规则应该针对稳定的包装格式并配套“合法引用字符串不阻断”的反例测试。安全门禁的价值不只是敢拦还要能解释为什么拦。03第二道门给“大幅缩短”设置比例闸门污染标记只能发现已知痕迹发现不了“干净但不完整”的源码。因此保存前还要读取远端现有版本比较新旧长度。当前实现采用一个保守边界远端源码至少 8,000 字符而新源码不足旧版本的 85% 时默认阻断。const isLargeRemote remoteSource.length 8000 const isSuspiciousDrop nextSource.length remoteSource.length * 0.85 if (isLargeRemote isSuspiciousDrop !confirmLargeReduction) { throw new Error(源码大幅缩短需显式确认后才能覆盖) }8,000 和 85% 不是“永远正确”的数学真理而是一道事故护栏它把高风险覆盖从默认动作改成需要明确表达意图的动作。远端源码较短时不启用该门也避免日常小改动被频繁打断。长度比较也不能替代差异审查。换行格式、格式化器和注释清理都会改变字符数所以门禁只负责把可疑操作停在写入之前再由调用者查看变更摘要。更稳妥的审计会同时记录目标资源、旧摘要、新摘要和缩短比例使后续复盘能够回答“比较的是哪一版”而不是只留下一句模糊的人工确认。04显式确认不是随手传一个 true真正需要重构、删掉废代码时当然应该允许大幅缩短。但确认值必须与目标绑定而不是一个可以被中间层默认填充的布尔值。工具侧支持传入完整 API Key或明确的执行口令调用者只有在读过差异、确认删减合理后才应该填写。更重要的是确认只豁免“长度异常”这一项不豁免污染检查、权限校验和保存后的回读。如果新源码里已经混入Chunk ID即使用户确实要删掉一半代码也不能让污染内容落库。每一道门负责不同风险不能用一次确认全部穿透。⚠️ 实践建议界面应展示旧长度、新长度、减少比例和目标资源标识审计日志只记确认事实与摘要不记录敏感源码全文。05第三道门超时后先回读别立刻再写一次写请求超时有两种可能服务端根本没收到或者服务端已经保存成功只是响应在途中丢失。此时直接重试会把一次不确定操作变成两次写入。正确做法是读取远端版本比较版本号、哈希或源码内容如果目标内容已经存在就把结果标记为“传输异常后回读恢复”而不是重复写。try { return await saveEngineCode(payload) } catch (error) { const remote await getEngineCode(payload.apiKey) if (sha256(remote.source) sha256(payload.source)) { return { Code: 1, RecoveredAfterTransportError: true } } throw error }这条原则不只适用于源码保存。配置发布、工作流更新和内容分发都存在相同的不确定窗口先确定远端事实再决定是否重试副作用。回读还必须绕开陈旧缓存命中保存接口对应的权威资源否则“读到旧值”会诱发重复写“读到本机缓存”又可能误报已经完成。若系统采用版本号则比较版本与内容摘要若没有版本号至少应使用规范化后的源码哈希并把恢复路径单独写入结构化结果方便监控区分正常成功与异常恢复。06这次验证了什么又没验证什么本轮对source-integrity.test.ts与microi-client-recovery.test.ts做了定向执行共 22 项测试全部通过覆盖污染标记、合法引用字符串、嵌套 JSON 扫描、异常缩短阻断与显式确认放行。关键断言还验证了未确认时保存调用次数为 0确认后才执行一次更新。这些测试同时包含正例与反例既证明已知污染会被拦截也证明普通业务字符串不会因为偶然出现相似单词而被误杀。异常缩短用例则直接观察更新函数的调用次数避免出现“界面提示阻断、后台其实已经写入”的假门禁。证据也有明确边界这是本地源码与确定性测试结果不是生产环境故障演练。原计划同步验证远端mci_demo但当前 MCP 返回NoLoginToken签名验证失败请重新登录因此本文没有虚构远端页面、截图或线上通过结论。官方站点和 MCP 文档当前可访问只能证明公开页面可达不能代替目标租户验收。07把“完整保存”变成一条可验收证据链一套可靠的 AI 长脚本保存流程至少应回答下面六个问题源码里是否混入截断提示、终端状态或工具包装文本嵌套 payload 中的源码字段是否也被扫描远端长源码是否发生超过阈值的异常缩短大幅删减是否由人明确确认并绑定到具体资源写入出现传输异常后是否先回读再决定重试测试报告、远端回读和生产验证是否被清楚区分AI 编程真正需要守住的不只是“生成得快”而是从上下文到工具、从传输到落库每一步都能证明内容没有少、没有脏、没有被重复覆盖。报错会提醒你停下来只保存一半却可能让团队带着错误的确定感继续向前。所以长源码的完成标志不是接口返回成功而是完整性门禁通过并完成远端事实回读。