用 Elsa Core 的 Feature Specification 模板编写高质量功能规格说明书

后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载本文以 elsa-core 仓库中.specify/templates/spec-template.md这一功能规格模板为骨架结合仓库内真实落地产物specs/013-user-tasks/spec.md与 Speckit 自动化工作流配置完整讲解如何编写一份可评审、可测试、可落地的 Feature Specification并说明它如何向下游的 implementation plan、tasks 清单与检查清单传导。读完本文你将掌握该模板每一节的填写要点、优先级与验收场景的写法以及它在仓库实际开发流程中的位置。模板在 Speckit 全流程中的位置.specify/templates/spec-template.md是 elsa-core 仓库中 SpeckitSpec Kit工具链的功能规格模板用于把一段自然语言的产品想法转化为结构化、可评审、可独立测试的功能规格说明书spec.md。从 workflow.yml 可以看到完整的 SDDSpec-Driven Development循环steps: - id: specify # speckit.specify → 生成 spec.md - id: review-spec # 人工评审 gatereject 则中止 - id: plan # speckit.plan → 生成 plan.md / research.md />**Feature Branch**: 013-user-tasks **Created**: 2026-08-17 **Status**: Approved for implementation仓库的init-options.json.specify/init-options.json显示当前项目以 codex 作为 AI 集成、使用 sequential 分支编号、以 AGENTS.md 作为上下文文件feature.json.specify/feature.json则把特性目录固定为specs/013-user-tasks——这解释了为什么specs/下每个特性001-shell-reload-api、002-graceful-shutdown……013-user-tasks都有一份遵循该模板的 spec.md。User Scenarios Testing以可独立测试的用户故事为 MVP 切片模板最强调的一节是User Scenarios Testing必填。其核心方法论写在注释中用户故事必须按重要性排序的用户旅程来编写并且每一条都必须可以独立测试——只实现其中一条也应当构成一个有价值的 MVP。模板给出的故事模板结构为标题 优先级P1 / P2 / P3P1 是最关键切片Why this priority解释该优先级背后的价值依据Independent Test用「可通过 [具体动作] 完整测试并交付 [具体价值]」句式描述独立验证方式Acceptance Scenarios用 Given / When / Then 三段式列出验收场景。对照真实案例 013-user-tasks/spec.md 的第 1 条用户故事### User Story 1 - Model and execute a user task (Priority: P1) **Independent Test**: Publish and run a workflow containing one User Task, complete it through REST, and verify the selected action and normalized form data resume the correct activity exactly once. **Acceptance Scenarios**: 1. **Given** a task with a direct assignee, **When** the activity executes, **Then** an Assigned task and matching bookmark are persisted and only the assignee or a manager can read protected content.可以看到模板中「Given…When…Then…」的占位符被替换成了可执行的验收标准状态变化、持久化约束、权限边界都写得可验证。真实 spec 还示范了 P1/P2 的合理分层——核心执行能力US1、任务收件箱US2、身份中性集成US3列为 P1外部门户完成US4与超时恢复US5列为 P2形成了明确的迭代路径。Edge Cases在写需求前先穷举边界模板专门保留了Edge Cases一节要求写出「当 [边界条件] 发生时会发生什么」「系统如何处理 [错误场景]」。这一节在 013-user-tasks/spec.md 中被填写为 10 条具体边界示范性极强无 assignee / candidates / invitations 的任务进入Unassigned仅管理员可见并记录告警释放任务立即撤销受保护内容访问回到Available或Unassigned操作 ID 复用且载荷相同时幂等载荷不同则冲突完成、超时、取消与 bookmark 移除的竞争通过 expected revision 与过渡态保证恰好一个终态胜出无法解析的配置表单阻塞完成并产生仅管理员可见的健康问题搜索永不扫描受保护的指令、任务数据、表单数据或完成数据。Edge Cases 是需求质量的试金石它们倒逼作者在动笔写功能需求前先把竞态、权限、失效路径想清楚也直接为下游 tasks 中的测试任务提供素材。Requirements功能需求编号与「待澄清」标记Requirements 节必填分为两部分Functional Requirements使用FR-###编号每条以 MUST 级别的强约束动词开头。模板给出了占位示例真实 spec 则写成了完整的 20 条例如- **FR-004**: Task status MUST follow Unassigned, Available, Assigned, transitional Completing/TimingOut/Cancelling, and terminal Completed/TimedOut/Cancelled states. - **FR-008**: The module MUST use opaque participant references composed of tenant, provider namespace, participant type, and external ID, with no required Elsa Identity dependency.模板还专门示范了如何标记不清楚的需求——用[NEEDS CLARIFICATION: ...]内联注明待澄清点而不是假装已经确定- **FR-006**: System MUST authenticate users via [NEEDS CLARIFICATION: auth method not specified - email/password, SSO, OAuth?]Key Entities可选当特性涉及数据时列出核心实体及其含义、关键属性与相互关系。真实案例中任务实体贯穿生命周期状态机Unassigned → Available → Assigned → Completing/TimingOut/Cancelling → Completed/TimedOut/Cancelled这正是 FR-004 在数据模型层面的落点并向下游>赞分享后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载相关推荐IsaacLab Docker 部署避坑指南从启动到跑通验证IsaacLab Docker 部署避坑指南从启动到跑通验证 拉完镜像、起好容器进去跑任务却发现 nvidia smi 找不到——问题几乎总出在宿主机驱动层人工智能强化学习机器人具身智能深度学习为 GitHub Copilot 编写 AI-Ready 规格说明书awesome-copilot Specification Agent 模式实战指南为 GitHub Copilot 编写 AI Ready 规格说明书awesome copilot Specification Agent 模式实战指南 本文文档知识库AI 技能/插件上一篇CSGuide计算机学习路线2025年最新版全栈学习指南从入门到精通下一篇如何快速实现高质量WebGL文字渲染TinySDF完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考