Feature Specification_AI Agent skill-PHP中文网

Feature Specification

Polar Sponsor

爱发电赞助

.NET 9.0

立即下载

将人物角色文档转化为详细的包含验收标准的功能规格。用于将用户需求转化为可实现规格、编写用户故事、定义验收标准或准备开发功能。

特性规格( Meta- Skill).

功能概述

特性规格( Meta- Skill).是一项面向实际任务的技能，主要用于Bridge persona 文档和开发；此技能将用户需求、疼痛点和在人名中识别的行程转换成结构化的, impme。

核心要点

它将相关步骤、工具调用和结果整理方式集中到统一流程中，帮助使用者更快完成目标并减少重复操作。
使用时应结合输入条件选择合适的执行方式，核对必要参数、依赖环境与输出内容，并按原始要求处理异常情况。
该技能适合需要稳定复用相关能力的场景，可作为自动化工作流的一部分，也便于后续检查、调整和扩展。

使用与执行

从功能定位来看，该技能强调把分散的操作要求整理成清晰、可复用的处理流程，使用户能够围绕既定目标快速准备输入、选择执行方式并获得结构化结果。实际使用前应先确认任务范围、数据来源、运行环境、必要权限和关键参数，再依据技能说明逐步执行；

结果检查与注意事项

若输入条件不完整，应先补齐信息或采用保守配置，避免因错误假设导致结果偏离需求。执行过程中需要关注工具调用是否成功、接口或依赖是否可用、输出格式是否符合预期，并对异常提示、缺失字段和边界情况进行处理；涉及批量任务时，还应保存进度，避免中断后重复操作。

功能规格说明（元技能）

衔接用户画像文档与开发工作。该技能将用户画像文档中识别出的用户需求、痛点及用户旅程，转化为结构清晰、可落地实施的功能规格说明，并附带明确的验收标准。

安装

OpenClaw / Moltbot / Clawbot

npx clawhub@latest install feature-specification

目的

用户画像文档定义了谁和为什么；功能规格说明则定义了什么以及做到何种程度才算合格。本技能弥合二者之间的鸿沟：

从用户画像中的痛点和旅程中提取可执行的功能点
结构化需求描述，使开发者能精准理解需构建的内容
明确定义验收标准，使测试人员能准确判断验证要点
在编写第一行代码前即消除范围模糊性

适用场景

用户画像文档已存在（docs/PERSONA.md 或 docs/personas/）之后
新功能或新产品开发启动之前
功能需求缺乏明确验收标准时
干系方对“完成”标准存在分歧时
将用户反馈转化为开发任务时

功能规格说明模板

每个功能规格说明均须采用以下结构。请将规格文档存放在 docs/specs/ 或 docs/features/ 目录下。

# 功能：[功能名称]

## 元数据
- **优先级：** [Must / Should / Could / Won't]
- **目标用户画像：** [来自用户画像文档中的画像名称]
- **状态：** Draft | Review | Approved | In Progress | Complete
- **预估工作量：** [T恤尺码：XS / S / M / L / XL]

## 问题陈述
[直接引用该功能所解决的用户画像痛点。
可引用或链接至用户画像文档中的相关章节。]

## 解决方案描述
[对该功能作用及其如何解决问题的高层描述。
2–4 句话，不含具体实现细节。]

## 用户故事

- 作为一个 [用户画像]，我希望 [执行某操作]，以便 [获得某收益]。
- 作为一个 [用户画像]，我希望 [执行某操作]，以便 [获得某收益]。

## 验收标准

### 场景：[主流程描述]
- **Given** [前提条件]
- **When** [用户操作]
- **Then** [预期结果]

### 场景：[替代路径描述]
- **Given** [前提条件]
- **When** [用户操作]
- **Then** [预期结果]

### 场景：[错误情况描述]
- **Given** [前提条件]
- **When** [无效操作]
- **Then** [错误处理结果]

## 边界情况
- [ ] [边界情况 1 — 描述及预期行为]
- [ ] [边界情况 2 — 描述及预期行为]

## 非功能性需求
- **性能：** [响应时间、吞吐量、负载目标]
- **可访问性：** [WCAG 等级、键盘导航支持、屏幕阅读器兼容性]
- **安全性：** [认证要求、数据敏感性、输入校验]
- **浏览器/设备：** [支持矩阵]

## 依赖项
- [本功能所依赖的其他功能或系统]
- [必需的外部 API 或服务]

## 不包含范围
- [明确列出本功能不涵盖的内容]
- [防止开发过程中范围蔓延]

## 设计参考
- [指向原型图、线框图或设计系统组件的链接]
- [如有，附上截图或示意图]

编写有效的用户故事

用户故事将用户画像需求与开发者任务连接起来。请遵循 INVEST 原则：

准则	含义	检验问题
独立性（Independent）	不依赖其他用户故事的执行顺序	能否单独构建并发布？
可协商性（Negotiable）	细节可在协作中进一步讨论	是否作为对话起点而非最终契约？
价值性（Valuable）	为用户画像带来实际价值	用户画像是否在意此功能？
可估算性（Estimable）	团队可对其工作量进行估算	范围是否足够清晰以评估规模？
小粒度（Small）	可在单次迭代中完成	能否在一个 Sprint 内交付？
可测试性（Testable）	具备明确的通过/失败判定标准	测试人员能否据此编写测试用例？

优质 vs 劣质用户故事示例

劣质示例	问题所在	优质示例
“用户可以登录”	未指定用户画像，未说明收益	“作为一位回流客户，我希望使用邮箱登录，以便查看我的订单历史”
“让它变快”	表述模糊，不可验证	“作为一位使用 3G 网络的移动用户，我希望商品列表在 2 秒内加载完成，以免放弃当前页面”
“添加后台管理面板”	以解决方案为导向，未说明问题背景	“作为一家门店经理，我希望无需开发人员协助即可更新商品价格，以便每日响应市场变化”
“处理错误”	缺乏具体上下文	“作为一位结账用户，我希望在支付失败时获得清晰反馈，以便判断应重试还是更换银行卡”
“实现缓存”	属于实现细节，而非用户价值故事	“作为一位重复访问者，我希望此前浏览过的页面能瞬时加载，以获得更灵敏的浏览体验”

验收标准模式

模式 1：主流程（Happy Path）

Given 一位已登录且购物车中已有商品的客户
When 点击“去结算”
Then 页面跳转至支付页，且购物车摘要可见

模式 2：边界条件（Boundary Conditions）

Given 购物车中已有 100 件商品（已达上限）
When 用户尝试添加第 101 件商品
Then 显示提示：“购物车已达上限——请移除一件商品后再添加”
And 该商品未被加入购物车

模式 3：错误情况（Error Cases）

Given 用户正在提交注册表单
When 邮箱字段填写内容为 “not-an-email”
Then 表单显示内联校验提示：“请输入有效邮箱地址”
And 表单未提交
And 输入焦点自动移至邮箱字段

模式 4：状态流转（State Transitions）

Given 一笔订单状态为 “Processing”
When 仓库将其标记为已发货
Then 订单状态更新为 “Shipped”
And 客户在 5 分钟内收到发货确认邮件
And 订单详情页可见物流单号

模式 5：反向 / 安全（Negative / Security）

Given 一位非账户所有者的用户
When 尝试通过直接 URL 访问 /account/settings
Then 返回 403 Forbidden 响应
And 此次访问请求被记录到日志中

优先级框架

采用 MoSCoW 优先级法，并以用户画像影响为锚点：

优先级	标签	定义	用户画像对齐
P0	Must	缺少此项，产品无法使用	阻碍用户画像的核心目标达成
P1	Should	具有显著价值，推迟实施代价高昂	解决 Top-3 痛点之一
P2	Could	锦上添花型功能，提升体验	优化次要用户旅程
P3	Won't	明确推迟（本版本不实现）	低频需求或小众场景

优先级制定流程：

列出所有候选功能
将每一项映射至对应用户画像的痛点或旅程步骤
依据用户画像影响（而非技术兴趣）分配 MoSCoW 标签
验证：所有 P0 功能组合后，是否足以支撑目标用户画像的基本可用性？
持续裁剪范围，直至所有 P0 功能均可在既定周期内完成

规格说明反模式

反模式	示例	修正方式
模糊需求	“系统应具备良好的用户体验”	定义可衡量标准：“任务在 3 次点击内完成”
遗漏边界情况	仅描述主流程	补充边界、错误及并发使用等场景
缺失验收标准	“实现搜索功能”	为每种场景补充 Given/When/Then
以方案冒充需求	“使用 Redis 实现缓存”	陈述真实需求：“重复查询响应时间 < 50ms”
未关联用户画像	“用户可导出数据”	明确指出是哪类用户画像、为何需要导出
范围无界	“支持全部文件格式”	明确限定格式：“PDF、CSV、XLSX”
隐含假设	默认认证机制已存在，但未明示	显式列出所有依赖项：系统、API、功能、数据源等