AI 辅助软件开发：机会、风险与质量控制

基于 AI 的编程工具如今已被软件开发者广泛使用。编程助手可以根据简短描述编写函数、解释旧代码、生成测试，甚至在几小时内搭出完整的原型应用。还出现了一个新词：氛围编程（vibe coding），即不断向 AI 下达指令并接受结果，却不真正阅读生成的代码，以此构建应用。

对于正在或准备开发软件的企业主来说，这带来了实际的问题：项目是否应该便宜得多、快得多？供应商使用 AI 是否安全？部分代码由机器编写时，如何保证应用质量？本文坦诚地讨论其中的机会与风险，以及您应当向内部团队或开发合作伙伴提出的质量控制要求。

要点摘要

• AI 能加快开发中的某些环节，尤其是常规代码、文档和测试，但并不能取代分析、设计和审查
• AI 生成的代码看起来可能正确，却隐藏安全漏洞、错误的业务逻辑或来源不明的依赖
• 快速原型不同于生产系统，后者必须安全、可维护并能承受负载
• 需要坚持的质量控制包括人工代码审查、自动化测试、安全扫描和明确的数据政策
• 选择供应商时，要问他们如何使用 AI，而不只是问是否使用

究竟改变了什么

软件开发并不只是敲代码，它包括理解业务流程、整理需求、设计数据和架构、编码、测试、上线和维护。AI 最擅长编写模式成熟的代码，例如录入表单、简单报表，或对接文档完善的 API。它还能协助编写测试、解释缺少文档的旧代码，以及起草技术文档。

仍然需要人来判断的部分包括：理解业务真正需要什么、决定能沿用多年的数据结构、在速度与安全之间权衡，以及处理只有熟悉运营的人才知道的例外情况。因此，一份好的软件需求文档变得更重要，而不是更不重要。AI 执行指令很快，错误的指令同样会很快产生错误。

企业可获得的真实机会

更快的原型与创意验证

在大笔投入之前，企业可以在短时间内看到可点击、可试用的原型。这在以学习而非发布最终产品为主要目标的验证阶段非常有帮助。由于尝试多种方案的成本下降，MVP 的做法也变得更可负担。

团队时间投入到更重要的事情上

当重复性工作由 AI 协助完成时，资深开发者就有更多时间用于系统设计、代码审查和与用户沟通。结果不一定是项目价格大幅下降，但往往能在同样预算内获得更完整的范围、更多的测试或更频繁的迭代。

维护和改造老系统

许多企业依赖的老应用，其最初的开发者早已离开。AI 可以帮助阅读和解释这些代码、为现有行为编写测试，并支持逐步迁移到更新的技术。这对正在规划遗留系统现代化的企业很有意义。

需要了解的风险

看似正确却不安全的代码

AI 模型从大量公开代码中学习，其中也包括不安全的示例。因此，生成的代码在简单测试中可能运行正常，却存在输入校验薄弱、数据库查询易受注入、遗漏权限检查，或把密钥直接写进代码等问题。多份安全行业报告发现，未经审查的 AI 生成代码中这类漏洞相当常见。各项研究的具体数字不同，但结论一致：AI 代码必须像人写的代码一样严格审查，甚至更严格。

虚构的依赖与供应链风险

AI 有时会推荐名称看似合理却并不存在的软件库，或已经过时的版本。攻击者利用这一点，用经常被 AI 臆造的名称注册恶意软件包。每个新依赖都需要核查来源、维护者和声誉，这与依赖与软件供应链安全的做法一致。

细微的业务逻辑错误

代价最高的错误往往不是技术错误，而是被错误转换的业务规则。税额取整、折扣顺序、加班计算或负库存规则，看似简单却充满例外。AI 会用听起来合理的假设填补空白。如果没有人对照公司的实际做法核查这些假设，错误要等数据积累后才会暴露。

难以维护的代码

靠不断给 AI 打补丁式下指令构建的应用，往往会堆积不一致的代码：同一问题用不同模式解决、函数重复、结构无人规划。对原型来说这可以接受；对要使用多年的系统而言，这种技术债会让之后的每次修改都更慢、更有风险。真正的成本会在上线后的维护阶段显现。

数据泄露与代码归属

当开发者把代码、示例数据或文档粘贴到 AI 服务中时，这些信息就离开了公司环境。请确保制定规则：哪些数据可以发送、可以使用哪些 AI 服务，以及这些服务是否会用输入数据训练模型。在合同方面，要明确代码归属以及第三方组件的责任，这些应写入软件开发合同。

值得落实的质量控制

AI 并没有改变构建优质软件的基本原则，但让这些原则变得不容妥协。以下做法应当成为内部团队和供应商共同的标准。

1. 01无论代码来源如何，每次代码变更在合并前都由熟悉系统的开发者审查
2. 02重要业务规则的自动化测试在每次变更时通过 CI/CD 流水线运行
3. 03静态安全扫描和依赖检查自动运行，高危问题必须修复
4. 04密钥和凭证存放在密钥管理工具中，绝不写进代码
5. 05架构、数据结构和重要技术决策由负责的人员记录成文
6. 06制定书面政策，规定可以使用哪些 AI 服务以及可以向其发送哪些数据
7. 07上线前由业务用户进行验收测试，覆盖真实场景和例外情况

上面第二、三条是基础。有了自动化测试与 CI/CD，无论是人还是 AI 引入的错误，都更有可能在到达用户之前被发现。而 UAT 则确保系统真正符合团队的工作方式，而不仅仅是通过技术测试。

向潜在供应商提问

如今几乎所有开发团队都以某种形式使用 AI。更有用的问题是他们如何加以控制。在评估方案时，可结合更通用的软件公司选型清单使用以下问题。

• 团队使用哪些 AI 工具，是否有书面的使用政策
• 代码审查流程如何进行，由谁负责批准变更
• 包含哪些自动化测试，您能否查看测试结果
• 如何检查第三方依赖的安全性和许可证
• 项目期间哪些公司数据可能被发送到 AI 服务，如何防止泄露
• 项目结束时代码和文档归谁所有
• AI 节省的时间如何体现在进度、范围或费用上

对过于美好的承诺要保持警惕，例如几天内交付完整的 ERP，或价格远低于常规却没有任何解释。编码速度并不是决定项目周期的唯一因素。需求讨论、数据迁移、培训和流程调整仍然需要时间，而这些恰恰是最常导致软件项目失败的环节。

借助 AI 自己开发：什么时候合理

一些企业主会想在没有开发团队的情况下，借助 AI 自己开发应用。对于使用者少、不存储敏感数据、出问题也容易替换的简单内部工具，这种做法可能是合理的，类似于使用低代码或无代码平台，例如内部报价计算器或简单的登记表单。

而对于存储客户数据、处理支付、连接财务系统或作为运营核心的应用，风险就完全不同。一旦出现安全问题或计算错误，影响会波及客户、税务和声誉。此时，让资深开发者审查架构、安全和业务逻辑，是值得的投入。

对项目成本和进度的影响

企业主期望项目变便宜是很自然的。实际上，节省最明显的是真正重复性的部分。需求分析、用户体验设计、与老系统集成、数据迁移和用户辅导等环节变化不大。因此，看待 AI 影响的健康方式是问：同样的预算能多得到什么——更完整的测试、更规范的文档，还是与用户更频繁的迭代。

要做出切合实际的预算估算，可参考计算软件项目的真实成本一文中的框架，再与供应商讨论哪些部分确实因 AI 而加快，哪些没有。

常见问题

可以要求供应商完全不用 AI 吗？

可以，但通常没有必要。更重要的是确保有代码审查、测试和数据政策。全面禁止很难监督，还可能放弃真实的好处；而明确的质量控制，无论使用什么工具都能保护您。

如果我不懂技术，怎样判断代码质量？

要求看得见的证据：自动化测试报告、安全扫描摘要和架构文档。对于金额较大的项目，可考虑在上线前请独立第三方进行审查。

结论

借助 AI 进行软件开发是一项真实的变化，只要管理得当，就能让企业受益：原型更快、常规工作减少、老系统更容易理解。但如果缺乏审查、测试和明确的数据政策，AI 也会让错误来得更快。

衡量成功的标准与 AI 时代之前相同：应用安全、符合业务运作方式、可维护，并能在未来多年持续演进。请选择把 AI 当作提升质量的工具，而不是绕过质量的捷径的团队。