外包交付团队的软件质量治理：AI生成代码与AI功能

本指南面向与外包或离岸开发团队合作并对其交付成果负责的创始人、CTO、产品负责人和采购负责人。本指南说明如何在甲乙双方之间划分质量职责、如何编写可测试的验收标准、如何将安全纳入这些标准、如何治理AI辅助工程并测试AI功能、如何运行发布就绪门控、应监控哪些交付健康指标，以及治理节奏在实践中的具体形式。

本指南目录

• 外包交付时的质量归属
• 可测试的验收标准
• 安全作为验收标准
• AI辅助工程：治理输出，而非工具
• 测试AI功能
• 发布就绪门控
• 难以造假的交付健康指标
• 跨时区有效运作的治理节奏
• 印刷电商案例
• 权衡与常见错误
• 质量治理检查清单
• 本集群计划中的指南
• 本指南的局限性
• 常见问题
• 本指南的编写方式
• 下一步

外包交付时的质量归属

外包转移的是工作，而非问责责任。客户、监管机构和董事会评判的是你的产品，无论代码由谁编写。因此，良好的治理要将甲方必须做出的决策与应由供应商负责的事项明确分开，并在每个边界要求提供凭证。

无论何种合作模式，这一划分都成立。固定总价项目与专属开发团队之间的区别在于谁承担估算风险，而非谁对质量负责。

可测试的验收标准

与外包团队的大多数质量争议，始于双方理解不同的用户故事。当验收标准足够具体，使一位从未参加过规划会议的测试人员也能判定通过或失败时，这些争议便可避免。

一种实用格式是：给定某一起始情境，当用户执行某操作时，则某结果可见。例如：给定一位已登录且保存了两个收货地址的客户，当其结账时，则两个地址均显示，且默认地址已预选；若支付失败，订单保留在购物车中，并显示清晰的错误提示。

良好的验收标准具备五个特征：

• 可观察。描述人或自动化测试可见的行为，而非意图。
• 有边界。说明限制条件，如文件大小、关注的响应时间及支持的浏览器或设备。
• 包含失败场景。说明出错时的处理方式，而不仅限于成功路径。
• 数据已明确。列出测试该故事所需的角色、记录和边界情况。
• 非功能需求已说明。无障碍性、性能和安全需求出现在验收标准或共享完成定义中，而非在无人阅读的独立文档里。

将故事级验收标准与适用于每个故事的完成定义配合使用：代码已评审、自动化测试已添加并通过、安全检查已运行、文档已更新，且变更已部署到甲方可使用的测试环境。完成定义使质量不再依赖个人投入。

在故事进入迭代之前批准验收标准，而不是在测试阶段。没有已批准验收标准的故事不具备开始条件，无论其看起来多么紧急。

安全作为验收标准

在外包交付中，安全失败的原因在于它被当作最后阶段的工作，而非从一开始就作为需求。两个公开框架帮助甲方无需从头编写即可说明需求。

• OWASP应用安全验证标准（ASVS）。OWASP将ASVS描述为测试Web应用技术安全控制的基础、安全开发需求列表，以及可用于采购合同的参考。5.0.0版是当前稳定版本。甲方可根据自身风险选择相应需求，并在验收标准中引用。
• NIST安全软件开发框架（SSDF），SP 800-218。SSDF将安全开发实践分为四个领域：组织准备、软件保护、安全软件生产和漏洞响应。它为甲方提供了一套共同词汇，用于询问供应商的工作方式，而不仅仅是交付内容。

在实践中，要求供应商针对每次发布说明：哪些安全需求在范围内、代码如何评审、运行了哪些扫描及其结果、哪些发现项已修复，以及哪些作为风险被接受并由谁接受。

Netbase公开的安全实践包括：安全代码评审和版本控制、传输中的TLS加密和静态的AES加密、基于角色的访问控制、管理后台的MFA、漏洞扫描和渗透测试，以及灾难恢复；NDA、DPA和SLA可按需提供，贡献者均在NDA约束下工作。Netbase持有信息安全管理的ISO 27001认证和SOC 2 Type II认证。其遵循欧洲数据隐私的GDPR对标方法、医疗数据处理的HIPAA对标方法，以及面向美国客户群的CCPA合规实践。上述内容适用于Netbase自身的运营和工作实践，不对客户产品或托管进行认证，客户自身的合规仍需独立评估。

AI辅助工程：治理输出，而非工具

大多数外包团队现在使用AI助手起草代码、测试和测试数据。禁止使用往往不切实际，而盲目信任则更糟糕。对其产出进行治理，采用与任何其他变更相同的凭证要求。

AI在质量工作中有实用价值：基于已批准的验收标准起草测试用例、生成合成边界数据而非复制生产记录、对失败测试和重复缺陷报告进行归类，以及在人工评审前标记高风险变更。每项都是由指定工程师或测试人员确认的草稿。

风险是具体的，因此管控措施也可以具体：

• 验证代码而非需求的测试。从代码生成的测试天然通过。要求测试可追溯到验收标准，并像审查代码一样仔细审查测试。
• 看似合理但不安全的代码。生成的代码可能重复过时或不安全的模式。将安全代码评审和扫描保留在每次变更的完成定义中，无论代码由谁或何物编写。
• 数据发送至错误位置。约定哪些AI工具已获批准，确保代码、密钥和个人数据不会发送至清单之外的工具或会对其进行训练的模型。
• 问责不明确。合并变更的工程师对其负责。「AI写的」不是可接受的风险。

在完成定义中增加一行：AI生成的代码和测试已由指定人员评审并批准。

测试AI功能

助手、分类器或推荐功能对相同输入不会每次给出相同答案，因此通过/失败标准需要不同的形式。验收变为在约定评估集上的量化结果。

在每次发布时记录模型和提示词版本，因为提供商的模型更新可能在不改变任何代码的情况下改变结果。

发布就绪门控

发布就绪门控是一个简短的会议或检查清单，用于决定候选版本是否可以交付给客户。其价值在于提前确定所需凭证，使决策不仅依赖于信心。

保持门控与变更相称。小修复可依据自动化凭证通过；涉及数据迁移或更改结账流程的发布则需要完整清单。记录每次门控决策，包括以已接受风险方式发布的版本，以便日后发现趋势。

难以造假的交付健康指标

指标帮助甲方在交付问题演变为延误上线之前发现它。当指标变成团队以牺牲产品为代价进行优化的目标时，指标就会造成伤害。

DORA研究项目定义了五个软件交付性能指标：变更前置时间（从提交到生产环境部署）；部署频率；失败部署恢复时间；变更失败率（需要立即干预的部署占比）；以及部署返工率（由生产事故引发的计划外部署占比）。这些指标共同平衡速度与稳定性，因此比任何单一数字都更难造假。

最后三行是常见补充项，并非DORA指标。审查趋势而非单一数值，并综合阅读各指标。频繁部署但频繁失败的团队不健康；因极少发布而从不失败的团队同样不健康。在缺乏产品、架构和风险背景的情况下，切勿以原始数字比较供应商或团队。

跨时区有效运作的治理节奏

节奏将指标和门控转化为决策。Netbase公开的治理模型包括：每周评审、KPI仪表盘、专属客户经理和项目经理、用于日常沟通的Slack或Zoom，以及客户仪表盘。其交付生命周期包含六个步骤：探索与战略对齐；团队组建与架构规划；以成果为导向里程碑的敏捷执行；模块化和产品化组件；培训、上线和优化；以及持续支持与共建。团队规模从3人到30人不等，涵盖业务分析师、项目经理、解决方案架构师、开发人员、QA和UI/UX设计师；工作通常在探索后1至2周内启动。支持覆盖周一至周六，周日休息，交付沟通使用英语。AI工具按项目选定并与客户约定。

甲方可参考的节奏：

有关本节奏背后的测试和质量实践，请参阅Netbase的质量工程与测试服务。

印刷电商案例

质量治理在缺陷会造成销售损失的地方最为关键。在印刷电商中，客户往往在一次会话中完成在线设计、确认校样和支付，因此编辑器损坏、页面加载缓慢或支付失败都会终止订单。这就是为什么Web to Print平台需要针对设计、校样和结账流程的验收标准，而不仅仅是后台页面，也说明了为什么印刷与包装行业是践行发布纪律的高要求场所。

USticker。对于USticker，Netbase交付了一个电商支付增强项目。公开的结果为：设计工具用户的转化率提升40%，六个月内完成设计数量提升32%，留存率提升25%，线上订单收入提升15%，页面加载时间缩短21%。这些数字描述的是整个项目的情况，系该客户报告的数据，其中40%仅适用于设计工具的用户。这些数据表明，电商产品的发布门控应保护的指标：转化率、完成率和速度。阅读USticker案例。

权衡与常见错误

• 门控过多。对每次变更进行繁重审批会减慢交付，并促使团队将高风险发布打包在一起。根据变更大小调整门控。
• 将指标当作目标。依据部署次数或缺陷数量对团队进行薪酬或排名会诱导造假。使用指标提出更好的问题。
• 将安全留到最后。上线前一周的渗透测试发现问题时已太晚，难以妥善修复。将需求纳入验收标准。
• 仅凭演示验收。好的演示展示的是顺畅路径。要求测试也覆盖失败场景。
• 仅供应商持有代码库。如果代码和流水线仅存在于供应商账户中，治理就依赖于信任。将其保存在你自己的账户中。
• 构建后更改验收标准而不说明。后期更改验收标准是正常的，但属于范围变更；应如实记录，以便公正评估估算和质量。
• 已接受风险无具名负责人。每个发布到生产环境的开放发现项都需要一个接受它的责任人和一个重新审视的日期。

质量治理检查清单

• 每个故事都有可测试的验收标准，包含失败场景。
• 共享完成定义涵盖评审、测试、安全检查和文档。
• 安全需求参考公开标准，如OWASP ASVS。
• 供应商能够根据NIST SSDF等框架解释其实践。
• 发布就绪门控明确凭证及每项的签署人。
• 回滚已经过测试，而非仅凭假设。
• 交付健康指标以趋势形式追踪并每周评审。
• 代码、流水线和文档存储在你控制的代码库中。
• 支持时段、优先级规则和升级联系人已书面记录。
• 事故引发无责复盘，并有有责任人的行动项。
• AI生成的代码和测试由指定人员使用已批准工具评审。
• AI功能根据版本化评估集验收，并在每次模型或提示词变更时重新运行。

本集群计划中的指南

本主题下设更深入的指南。已发布两篇：向软件开发合作伙伴提出的安全问题和验收标准与发布就绪检查清单。计划中的内容：外包交付的软件质量工程策略和如何衡量工程交付健康度。在这些内容发布之前，上述各节涵盖了要点。

本指南的局限性

本指南是Netbase交付经验中的实践指导，并非原创研究或法律建议。OWASP、NIST和DORA作为公开框架引用，并非合规声明。AI相关章节描述的是快速发展领域中的当前实践，而非量化结果。Netbase的安全实践以实践形式描述，不对任何控制措施的有效性作出声明，其认证适用于Netbase自身的运营。USticker的结果系针对整个项目的报告，取决于该客户的基准和市场。

本指南的编写方式

Netbase编辑团队基于Netbase已发布的交付、治理和安全页面、USticker案例研究以及OWASP、NIST和DORA的公开指南撰写本指南。David（CEO）审核了每一项Netbase相关事实。外部来源均附有访问日期。起草使用了AI辅助（Claude）。本指南旨在帮助甲方在将工作外包的同时，对质量保持问责。

下一步

分享你当前外包交付的治理方式、令你担忧的发布内容以及任何合规需求，我们将预约解决方案评审，为你制定适合的验收、发布和指标实践。你也可以查看相关服务或浏览更多Netbase洞察。

相关服务与解决方案