贯通完整的软件生命周期

沿系统追踪一项功能

编程助手可以帮助产出实现。软件交付系统还必须决定做什么、验证结果、发布软件，并支持其使用。AI 可以协助这些活动，但决策仍然存在。

考虑一个虚构请求：经理需要客户导出。首先应问为什么需要导出。定期报表可能以更少的数据暴露满足需要。过早接受功能名称，可能造成不必要的工作。

接下来要明确边界。哪些用户可以导出哪些记录？需要哪些字段？文件会去哪里？这些决定会影响实现和必要检查。

在阶段之间保留证据

如果每个阶段收到的上一阶段说明都不完整，生命周期就会变得不可靠。工单只写“添加导出”，PR 增加一个端点，运维人员却接收到没有负责人的服务。

在阶段之间建立明确关联：

此表是一种实用教学模型。组织可以使用不同阶段名称，也可以合并活动。即使工作流高度自动化，也要保留这些决策。

让验证对应需要

对于导出功能，文件下载成功是一项检查。另一项检查确认经理不能导出其他组织的记录。第三项检查确认所需字段集合。这些检查对应不同要求。

不要从绿色测试标志推断整体安全。明确检查覆盖什么，以及什么尚未验证。NIST 的 SSDF 将安全开发描述为贯穿生命周期的实践，而非最后的一次扫描。阅读框架。

发布决定应使用即将部署版本的证据。如果审查后代码改变，确定哪些检查和决定需要重新执行。交付流程必须明确保留这种对应关系。

在最初设计中纳入运维

决定服务负责人如何发现导出失败、异常请求模式或不可接受的响应时间。不要为了方便排查，就把导出的客户数据写入日志。

监控应帮助负责人采取行动。Google 的 SRE 指南区分服务症状与内部原因，并解释有效信号的重要性。参见监控指南。

在事件发生前规划恢复。明确谁可以停止功能、恢复服务并说明影响。部署完成意味着进入这些职责，而不是结束工作。

用反馈改变下一次决策

发布后，检查经理是否使用导出功能，以及它是否解决了最初问题。审查事件、支持问题和维护投入。将重要发现转化为更新后的要求或工作。

这种关联使完整生命周期的软件工厂区别于一组代码生成器。评估系统能否在整个过程中保留意图和证据。探索交互式生命周期，查看每项决定。