企业官网建设流程全解析

• 后端
• 工作流自动化
• 流程编排
• 低代码

本文以 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 仓库中 Speckit（Spec Kit）工具链的功能规格模板，用于把一段自然语言的产品想法转化为结构化、可评审、可独立测试的功能规格说明书（spec.md）。

从 workflow.yml 可以看到完整的 SDD（Spec-Driven Development）循环：

steps: - id: specify # speckit.specify → 生成 spec.md - id: review-spec # 人工评审 gate，reject 则中止 - 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 / P3）：P1 是最关键切片；
• 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 在数据模型层面的落点，并向下游>赞分享

• IsaacLab Docker 部署避坑指南：从启动到跑通验证

  IsaacLab Docker 部署避坑指南：从启动到跑通验证 拉完镜像、起好容器，进去跑任务却发现 nvidia smi 找不到——问题几乎总出在宿主机驱动层

  人工智能强化学习机器人具身智能深度学习

• 为 GitHub Copilot 编写 AI-Ready 规格说明书：awesome-copilot Specification Agent 模式实战指南

  为 GitHub Copilot 编写 AI Ready 规格说明书：awesome copilot Specification Agent 模式实战指南 本文

  文档知识库AI 技能/插件