近日围绕"AI 将在三到六个月内写出 90% 的代码"的讨论再次引发技术圈热议。这个观点虽然听起来激进,但来自多位一线工程师的实践反馈已经显示,AI 在生产环境中承担绝大部分代码生成工作的场景并非遥远设想。本文以 Armin Ronacher 的实战写作为线索,结合工程落地经验与风险管理,展开对 AI 生成代码生态的系统性梳理,旨在帮助开发者理解如何把握机遇、规避风险并在日常工作中把 AI 变成可信的"助手"而非不可控的黑箱。文章既讨论工具与流程层面的具体做法,也覆盖架构、测试、运维与组织治理等方面的深层问题,便于从技术和管理两个维度落地应用。 从实践出发的优势总结可以非常直观。对一名资深工程师来说,以 OpenAPI 优先的方式定义接口规范,然后让 AI 基于规范生成服务端与客户端的初版实现,可以极大缩短迭代周期。
Armin 在一个以 Go 为核心、包含自定义 SDK、Python 与 TypeScript 客户端、以及 Pulumi 基础设施代码的项目中,累计产生约四万行代码,其中绝大部分由 AI 生成并通过人工审查合并到主干。这样的工作方式带来的直接收益包括研究与实现并行化、快速尝试多种实现路径、以及显著降低手工迁移与基础设施配置的时间成本。AI 对 SQL 的生成能力也是一大亮点,许多工程师在复杂查询或合并操作上记不住 MERGE、WITH 等语法,而生成式模型能迅速产出符合逻辑的原始 SQL,让工程师将精力集中在业务正确性与性能调优上。 不过,AI 并非万能。它在系统全局状态、并发控制、运行时边界条件以及长期可观测性方面仍存在明显短板。Armin 的经验强调了一个核心事实:无论代码由谁生成,工程师仍然要对最终产物负责。
AI 常常会引入不适合当前规模或架构的抽象,使用过时或不必要的第三方依赖,吞噬错误信息或者屏蔽堆栈追踪,导致系统变得难以排查。在多线程或 goroutine 场景中,模型容易忽视细致的并发语义或竞态条件,生成的"能跑"的方案在高并发或异常路径下往往会暴露严重问题。典型案例包括自研限流器在缺乏抖动(jitter)设计与持久化策略时表面上可用但在突发流量下崩溃,或是错误地在共享资源上进行非原子操作,从而引发数据一致性问题。 要把 AI 变成可靠生产力,需要从工程流程和心态上做出调整。首先,架构与 schema 仍然需要人工主导。在系统设计阶段坚持规范化的方法论,先完成数据模型、API 设计与边界定义,然后把这些 artifact 作为 AI 的"上下文",以减少模型在实现过程中重复造轮子或误用已有组件的风险。
OpenAPI-first 是一种有效策略:把接口规范作为单一事实来源,使用代码生成器由规范产出服务端骨架与客户端 SDK,AI 的任务则集中在实现业务逻辑、编写复杂 SQL 或补充边界条件测试上。这样可以让多个生成器或多种实现保持一致,降低后续维护成本。 其次,将 AI 的产出拆分为可审查的小步提交。Armin 推荐以 PR 尺寸为单位循环迭代,或采用"agent loop with finishing touches"的方法:先反复提示模型直到输出接近目标,然后人工收尾并修正不符合风格或可运行性的部分。另一种做法是"lockstep loop",即人工在更细粒度上编辑和引导模型。关键在于要根据任务复杂度与模型熟练度选择合适的合作节奏。
对于架构关键或并发敏感的模块,应坚持人工先行或严格审查策略,而对于重复性高、模板化的代码片段,可以更多依赖模型生成并通过自动化测试覆盖。 测试与可观测性必须被提升到优先级最高的位置。AI 在写测试方面常常力不从心,但却擅长搭建测试基础设施。通过推荐使用 testcontainers、数据库克隆策略或专门的集成测试执行环境,AI 可以帮助搭建稳健的测试体系。理想的流程包括单元测试、数据库迁移测试、集成测试与端到端流量回放。自动化回归测试对于 AI 生成代码尤为重要,因为模型在不考虑历史代码变更的情况下可能会生成与现有行为不一致的实现。
与此同时,保留详细的日志、堆栈追踪以及指标采集是不可或缺的。相比于把错误吞掉,设定强不变量并在断言失败时"轰然崩溃"的策略更有利于早期发现错误源,避免长期的隐患累积。 在依赖管理与第三方包选择上也要有明确的准则。生成式模型喜欢从互联网常见模式中抽取解决方案,因此会倾向于引用流行但可能过时的库。团队应定义允许使用的依赖清单、版本策略与安全审计流程。对外部库的许可协议与供应链风险必须进行检查。
CI/CD 流程中引入依赖扫描、安全漏洞检测以及自动化许可证合规检查,可以在代码合并前拦截大部分风险。 关于数据库与 SQL 的处理值得深入讨论。许多工程师长期依赖 ORM,因其便捷而忽略了在复杂查询或性能调优上会遇到的瓶颈。Armin 指出,对他而言,AI 帮助实现原生 SQL 的写作与迁移是一大变革。手写 SQL 的可读性与在数据库日志中的可追溯性,使得调试和性能分析变得更直接。AI 能快速生成复杂的 MERGE、CTE 与批量更新语句,从而让工程师在保留高性能特性的同时减少重复劳动。
然而,AI 生成 SQL 也需要严格验证执行计划与锁策略,避免在高并发或大数据量场景下导致长时间的表锁或全表扫描。 基础设施的代码化是另一个高回报领域。Armin 使用 Pulumi 和云服务脚本时,AI 帮助他在数天内完成原本需要数周的工作。云资源配置、IAM 策略、网络拓扑与监控报警的初版可以通过模型快速铺开,但这些配置必须服从公司的安全与成本控制政策。在生成 IAM 权限或网络访问策略时,要人工核验最小权限原则是否得到贯彻,并用基础设施代码审计工具进行合规检查。对于关键资源,建议引入手动审批环节而非全自动部署,降低误配置带来的风险。
团队协作和知识传承在 AI 驱动的项目中也需要新的实践。因为代码大量由模型生成,工程师需要把注意力从"写代码"转向"审查、解释与治理代码"。文档、代码注释与架构决策记录变得更加重要。将 API 规范、迁移历史、设计权衡和已知限制记录在中央知识库,使得未来的新成员或模型都能在合适的上下文中工作。代码评审不再只是风格层面的把关,而是变成一项系统性任务,包含运行时语义、资源使用、错误处理策略与安全隐患等方面。 法律与伦理层面的考量也不能忽视。
AI 生成的代码可能会引入受版权保护的实现细节,或违背某些开源许可的约束。组织应建立清晰的版权与许可审查流程,确保从模型输出到生产代码的每一步都满足法律合规要求。此外,在某些高敏感度的业务场景,如医疗、金融或安全关键系统,AI 生成代码的审查门槛应明显高于常规应用,必要时采取人工完全实现或限定模型输出范围的策略。 从长期视角看,AI 改变软件工程的角色分工是不可避免的。更多重复性、模板化与机械化的工作将被自动化,而工程师的价值将更多体现在系统设计、风险评估、复杂问题求解与跨团队协调上。招聘时对工程师的能力要求也会相应调整,除了编程能力,审查 AI 输出、编写高质量测试、进行故障排查与系统化思维将成为面试的重点。
最后给出若干可直接落地的实务建议。先把接口与数据模型当成权威事实来源,采用 OpenAPI-first 或类似契约驱动的方式;在 PR 级别控制 AI 的输出,将大改动拆解成小步提交并配合自动化测试;提升可观测性与日志记录的优先级,宁可显式失败也不要吞噬错误信息;对第三方依赖设定白名单与安全扫描机制;在并发、数据库事务与分布式一致性等关键场景坚持人工主导;为团队建立模型使用规范、版权与合规审查流程;对基础设施变更引入审批流程并使用 IaC 审计工具。 归根结底,AI 带来的并非替代,而是放大工程师能力的放大器。它让那些曾经耗时耗力的实现变得触手可及,使得快速验证与多方案尝试成为常态。但与此同时,工程师不能把责任交给模型。对系统行为的深刻理解、对不确定性的容忍、以及对安全与可维护性的坚持,依然是构建长期可运行系统的不二法门。
若能在设计、验证、代码生成与监控四个环节上建立稳固的流程与文化,AI 写出 90% 代码的现实将成为推动生产力跃迁的机遇,而非风险的放大器。 。
