Coroid 采用规格驱动开发：从规划到测试、审核，规格说明始终与某项工作绑定，确保各个阶段都基于同一套成功定义开展工作。
无需从一句话描述出发、边写代码边确定细节，Coroid 会将需求转化为明确的范围、排除项和验收标准。该文档将成为计划、实现、测试和最终审核的唯一依据。
什么是规格驱动开发？
规格驱动开发是一种基于约定的、可测试的成果描述来构建软件的方式。规格说明会明确哪些内容会发生变更、哪些不会变更、适用哪些约束条件，以及审核人员如何判断工作是否达标。
它区分了容易混淆的两类决策：
- “规格说明”定义了何为成功。
- “实施计划”定义了如何实现它。
这种拆分方式让你能在编写代码前修正范围，而无需过早指定实现方式。在 Coroid 中，你还可以启用可选的SDLC 工作流以便在规划启动前先审批意图和规格说明。
Coroid 中的工作流程运作方式
- **描述预期成果。**向 Coroid 提供所需的结果、相关背景信息以及任何约束条件或非目标项。
- **审核规格说明。**在任务的“规格说明”标签页中检查范围、排除项和验收标准。
- **批准计划。**架构师会将约定的成果转化为有序的实施步骤。
- **构建并验证。**开发人员和 QA 智能体将依据同一套标准实现变更，并证明各项承诺的行为均符合要求。
- **审核 pull request。**交付的变更会将计划、测试结果、发现内容和依据反馈至最初的规格说明中。
最终可实现从产品意图到代码及审核人员可见的依据的全链路追溯。详见任务如何转化为 pull request以查看完整的执行路径。
为何需要这一额外步骤
像“为用户查询功能添加缓存”这样的指令至少有四种合理的实现方式，且没有明确的交付定义。智能体会从中任选一种，能否选中你期望的方案全凭运气。
规格说明会在实施开始前明确这一选择，此时修改方案的成本最低。
它还能为验证工作提供测试依据。没有验收标准的话，“这是否有效？”就会退化为“测试是否仍通过？”，这类问题的说服力要弱得多。
规格说明包含的内容
| 组成部分 | 回答的问题 |
|---|---|
| 范围 | 将会发生哪些变更 |
| 超出范围的内容 | 特意排除的内容，防止变更范围无限制扩张 |
| 验收标准 | 任何人如何判断工作是否达标 |
| 背景信息 | 适用的约束条件、惯例和先前决策 |
你可以在任务“规格说明”标签页中阅读和编辑它，该流程所需的描述性文本和支持性背景信息详见描述你的需求.
实操示例：从简要需求到可测试的规格说明
假设原始需求如下：
Add caching to the user lookup so repeated requests are faster.该需求明确了预期成果，但留下了一些未解决的重要选择。一份实用的规格说明会将这些选择转化为边界条件和校验规则：
Scope
- Cache successful user lookups by user id for 60 seconds.
- Invalidate the cached entry when the user record is updated.
Out of scope
- Do not cache failed lookups.
- Do not change the public signature of getUser.
Acceptance criteria
- Two lookups for the same user id within 60 seconds call the data source once.
- Updating that user invalidates the existing cache entry.
- A cache miss preserves the current result and error behavior.此时计划环节可选择实现方式，QA 可将相关标准转化为测试用例，审核人员也能将 pull request 与承诺的行为进行对比。
怎样的验收标准才算合格？
它们必须能被未参与沟通的人员校验。
较差的示例：
Caching works correctly and performance is improved.优秀的示例：
- Repeated lookups for the same user id within 60s hit the cache, verified
by a test asserting the data source is called once across two lookups.
- Cache entries are invalidated when the user record is updated.
- A cache miss behaves identically to today, including error handling.
- No change to the public signature of `getUser`.第二个版本为开发智能体指明了构建方向，为 QA 智能体指明了测试方向，也为你指明了在 pull request 上需核查的内容；第一个版本则让上述决策均处于开放状态。
范围界定与标准制定同等重要
pull request 规模过大的最常见原因并非智能体超出了需求范围，而是规格说明未明确需求的边界。
如果你不希望相关模块在过程中被重构，务必明确说明。“不要更改调用点”是一条合理且有用的限定条件。
常见的规格说明误区
| 误区 | 更好的做法 |
|---|---|
| 描述实现方式而非预期成果 | 阐明行为和约束条件，再让计划环节选择实现方式 |
| 使用“快速”“安全”或“正常运行”等表述 | 将其替换为可观测的阈值、行为或测试用例 |
| 遗漏非目标项 | 明确列出必须保持原样的相邻代码、接口或行为 |
| 合并无关的成果 | 拆分工作任务，确保单个任务能生成可审核的 pull request |
| 直接复制工单而未核实前提条件 | 补充代码库无法体现的上下文信息和决策内容 |
当你对其有异议时
修改它。规格说明在实施启动前是一份动态文档，修改它的成本远低于修正据此生成的代码。
如果规格说明显示该工作实际包含两个独立部分，可将其拆分为两个任务。每个任务应生成一个可让单人一次性审核完毕的 pull request。
后续流程说明
对于超出小型变更范畴的需求，相关规格说明会转化为具体计划。详情请参阅：任务、计划、迭代和流程该部分会说明在编写代码前，工作是如何拆分及获批的。
常见问题解答
规格说明与技术设计是一回事吗？
不是。规格说明定义了所需的结果及边界；而技术设计或实施方案则阐述了实现该结果所采用的架构和步骤。
所有变更都需要 lengthy 的规格说明吗？
不需要。对于简单且明确无歧义的小变更，仅需寥寥数行范围描述和验收标准即可。规格说明的作用是消除实质性不确定性，而非增加繁琐流程。
谁应该审批规格说明？
对最终结果负责的人员需确认范围及标准符合团队需求。若相关约束条件会影响成果交付，技术、安全或合规领域的审批人也可参与审批。
工作启动后规格说明还能修改吗？
可以修改，但需生成新版本，并触发对相关计划及工作的审核。若擅自更改范围却未留痕，就会切断需求与最终交付的 pull request 之间的关联依据。