SDLC 工作流程

从需求意图到正式发布的受管控生命周期，以及可在规划启动前添加的可选审批节点。

Coroid 覆盖了完整的软件开发生命周期，而非仅局限于构建环节。其中大部分流程可自动执行；仅有一个可选节点，仅当工作重要性足以需要额外把关时才会启用。

可选的SDLC工作流程

在新任务表单的高级设置项下，有一个对应的复选框：

使用SDLC工作流程（可选）——在规划前先审核需求意图与规格说明。若无需此步骤，可直接根据需求简述启动规划。

该选项默认处于关闭状态。关闭该选项时，需求简述会直接进入规划阶段；启用后则会先生成并审批两项内容：

只有这两项内容获批后，才会启动规划流程。

当打造错误产品的成本较高、需求提出者不会自行审核规划方案，或需求简述中包含你希望提前确认并达成共识的假设时，可启用此功能。

若需求简述本身已表述清晰，则无需启用。对常规工作增设额外审批环节只会徒增阻碍而无实际益处——且无论是否启用该功能，规划审批步骤仍会正常执行。

完整生命周期分为五个阶段，每个阶段都会产出供下一阶段使用的凭证。

环节	具体流程	状态
定义	模糊的需求会被转化为获批的意图、相关决策、假设及成功衡量标准。	测试版
可视化	可选的用户界面构思方案，经细化后获批作为设计指导。	测试版
交付	计划被拆解后由智能体执行。	可用
验证	需求会对应到任务、检查项、评审结果以及拉取请求变更中。	可用
优化	监控、修复与评估会将回归问题转化为下一周期的任务。	可用

「定义」与「可视化」目前正处于开发阶段。「交付」「验证」和「优化」已应用于当前所有任务，无论是否开启审批节点。

审批会绑定到工件的特定版本。修改已获批的工件会生成新草稿，而非悄悄更改已约定的内容。

这正是审批具备实际意义的原因。如果审批仅关联到“规格说明”本身而非其特定版本，那么后续文档内容的变动都会被视为已获批，这根本算不上真正的审批。

产品、设计、技术、安全及发布相关职责可独立分配，因此负责审批安全影响的人员未必是负责审批范围的人员。

在每个环节生成证据的目的是便于追溯完整的pull request：此项变更对应此任务，该任务源自此需求，而需求又来自已获批的意图。

正是这一链条让自主交付过程可被审计。缺少它的话，虽有可运行的代码，却无法说明为何这就是你要求的产品。

SDLC工作流和计划属于不同的审批节点：

你可以选用其中一种、两种或都不用。相比事后审核不符合预期的完整pull request，这两种方式成本更低。