当前软件工程领域正经历一场罕见的范式倒置：过去数十年，行业追求的核心目标是 “确定性”—— 构建每次运行行为一致的系统；而如今，概率性的 AI 智能体被层层叠加在这一基础之上，以惊人的规模和速度生成代码。但现实是，绝大多数现有基础设施根本不是为这种模式设计的，AI 驱动开发正暴露出现有工作流中的每一处漏洞，引发效率、安全与稳定性的多重挑战。
一、AI 编码时代的现实问题：效率与风险并存
AI 生成代码已成为行业常态，但随之而来的是一系列亟待解决的问题。2025 年 GitClear 研究显示，近 7% 的代码提交包含 AI 生成代码，而 “代码 churn”（两周内被重写或删除的代码）比例较 AI 普及前翻倍，意味着大量 AI 生成代码因适配性差需反复修改，反而增加无效工作量。安全层面的隐患更令人担忧：对 100 多个大语言模型的 80 项特定编码任务分析发现，45% 的 AI 生成代码存在安全漏洞，实际业务中，五分之一的首席信息安全官（CISO）报告曾发生由 AI 生成代码直接引发的重大安全事件。尽管 AI 带来的开发速度提升真实存在，但这种速度是以牺牲系统稳定性为代价的，形成 “快而不优” 的困境。
二、AI 的 “放大效应”：加剧流程优劣差异
斯坦克在长期 DevOps 实践中发现，AI 具有 “放大一切” 的特性：若团队本身具备规范的开发流程（如标准化环境、清晰的依赖管理），AI 能进一步提升效率与质量；反之，若原有流程混乱（如多版本环境共存、依赖追踪缺失），AI 会将这种混乱放大。这与 DORA 年度 DevOps 报告的长期结论一致 —— 成功的团队往往通过减少变量（如统一操作系统、编程语言）来降低复杂度，而 AI 智能体同样遵循这一逻辑。当 AI 在 “Python 版本跨设备统一、依赖锁定可追溯” 的一致环境中工作时，能高效聚焦核心任务；但如果被迫应对 17 种不同配置的细微差异，大量 Token 会被浪费在解决 “环境异常” 上（如依赖安装失败、命令适配问题），而非实现业务需求。例如，某团队因未统一开发环境，AI 生成的代码在开发者本地能运行，却因生产环境缺少特定库函数频繁报错，最终花费数倍时间调试环境，抵消了 AI 带来的效率提升。
三、确定性悖论：概率性 AI 与确定性基础设施的冲突
长期以来，计算机科学将 “确定性” 视为终极目标，而如今，无法保证两次输出一致的概率性 AI 工作负载，正运行在为可预测性设计的系统之上，形成尖锐矛盾。斯坦克提出的解决方案是 “尽可能保持技术栈的确定性”：若能让 80% 的基础设施处于确定性状态（如环境配置统一、依赖版本锁定、编译工具就绪），AI 智能体需处理的变量会大幅减少，无需将上下文窗口浪费在 “依赖为何安装失败”“构建命令为何无效” 等问题上，转而专注核心开发任务。例如，当 AI 尝试编译代码时，若环境中已预装 ImageMagick、完整编译器及 libc 依赖树，就能直接推进开发；反之，缺少基础工具会导致 AI 陷入 “试错式调试”，既消耗 Token 又延误进度。
四、关键突破口：规范需求描述与强化验证机制
AI 驱动开发迫使行业重新重视两项长期被低估的能力 ——需求描述（Specification） 与验证（Validation） 。前者要求清晰界定 “要构建的内容”，后者则需要可靠的方法验证 “是否达成目标”。斯坦克观察到，具备产品管理或产品工程背景的人员，在使用 AI 智能体时往往更高效，因为他们习惯从需求、成功标准、权衡取舍的角度思考，擅长追问 “为何做出该选择” 并根据逻辑调整方向，能为 AI 提供更精准的开发指引。
验证环节则是软件工程长期的核心难题，QA（质量保障）长期被低估，却在 AI 时代愈发关键 ——AI 无法解决 “软件是否满足用户实际需求” 的问题，反而因概率性输出让验证更具挑战性：需要将 AI 生成的不确定结果，与确定性需求进行比对。例如，AI 生成的支付模块代码可能语法正确，但未满足 “交易失败时自动退款” 的业务规则，若缺乏严格验证，极易引发生产事故。
五、安全与可控：从 “信任” 到 “验证与管控”
斯坦克提出一个重要观点：“应默认 AI 生成的代码具有潜在风险，直至证明其安全”。并非因为 AI 存在恶意，而是 AI 每日生成数千行代码时，人工无法逐行审计，必须转变管控思路 —— 若无法在开发阶段全面把关，就需在运行阶段强化控制。运维人员、SRE（站点可靠性工程师）及平台团队需掌握更全面的生产环境可见性：实时监控运行内容、完整追踪依赖关系、明确每个工件的来源（Provenance）。
可复现性（Reproducibility） 在此过程中至关重要：当能通过数学方式证明 “本地测试的工件与生产运行的工件完全一致”（相同输入、输出及依赖闭环），就能做出更明智的决策 —— 例如，若本地已运行单元测试且无变更，CI 阶段可省略重复测试；若能将测试覆盖范围与代码变更关联，可跳过无关测试套件，既提升效率又保障安全。
六、未来方向：构建以可复现性为核心的基础设施
当前行业正处于拐点：已有规范流程的团队借助 AI 获得巨大生产力提升，而原本流程混乱的团队则 “加速陷入困境”。支撑 AI 驱动开发的基础设施，需从源头构建可复现性，而非事后通过扫描工具或审计补充。具体而言，需实现三大目标：开发环境在 Mac 与 Linux 系统间保持一致、所有依赖被追踪并锁定、每个工件的来源可追溯。只有这样，AI 智能体才能成为 “效率倍增器”，而非 “混乱制造者”。
针对团队的实践建议，斯坦克提出三点核心方向：
- 极致标准化：减少变量是提升性能的关键。锁定技术栈、在所有平台强制一致环境、消除配置偏差（如 Python 版本不匹配的问题，在 AI 规模化生成代码后会放大 10 倍）；
- 将验证嵌入全流程：AI 生成代码速度远超人工审核，不能依赖事后手动审查。需在工作流中内置自动化测试，不仅验证 “代码能否运行”，更要验证 “是否满足需求”，将 CI/CD 流水线作为安全网，在生产部署环节设置严格管控门；
- 将可复现性视为基础设施：将环境一致性作为核心基础设施需求，当能证明本地、CI 与生产环境完全一致时，可彻底解决 “在我机器上能运行” 的行业痛点，为叠加概率性 AI 工作负载奠定确定性基础。
最终，斯坦克强调：“AI 编写大部分代码已成事实，问题不在于此，而在于我们的基础设施能否跟上节奏”。只有构建适配 AI 时代的确定性基础设施，才能充分释放 AI 的效率潜力，同时规避安全与稳定性风险。
原创文章，作者：王 浩然，如若转载，请注明出处：https://www.dian8dian.com/ai-zheng-zai-bian-xie-dai-ma-dan-ni-de-ji-chu-she-shi-neng
