---
name: product-feature-catalog
version: 1.0.0
description: |
  基于产品事实与证据生成结构化功能列表、模块树和版本能力矩阵。用于产品规划、
  售前交流、招标附件或交付范围梳理；重点回答产品有什么功能、谁使用、产生什么
  结果，不负责撰写技术参数或长篇方案。
allowed-tools:
  - Read
  - Grep
  - Glob
compatibility: Markdown；建议配合 product-evidence
---

# 产品功能列表

## 必要输入

- `product-evidence.json`，至少包含 `product`、`features`、`limitations`。
- 输出用途：内部全量、公开产品、指定版本或投标范围。
- 目标受众和所需粒度：模块、功能或子功能。

没有事实清单时不要自行拼凑：先用 `product-evidence` 建立并校验清单，或输出输入
缺口清单等待补齐；任何情况下都不得根据产品名称猜测功能。

## 生成流程

1. 按版本、公开级别和用途筛选功能。
2. 建立“产品域 → 一级模块 → 功能 → 子功能”层级，层级只服务导航，不凑数量。
3. 每条功能写清用户角色、触发动作、系统行为和可观察结果。
4. 标注 `released`、`beta`、`planned`、`deprecated`，规划能力不能混入现有功能。
5. 补充版本范围、依赖、限制和证据 ID。
6. 合并同义功能，拆开一行中包含多个独立用户动作的复合功能。

## 输出

复制并填写 `templates/feature-catalog.md`。默认输出两部分：

1. 面向读者的功能目录，只保留必要列。
2. 追溯附表，保留功能 ID、状态、证据和限制，供内部审核。

## 写作规则

- 功能名使用“对象 + 动作”或稳定名词，不用“强大、智能、高效、全方位”。
- 功能说明写能力边界，不写架构实现、性能参数和竞争结论。
- “支持”后必须接具体对象或动作，避免“全面支持”“灵活支持”。
- 同一功能在不同版本有差异时拆行或使用版本矩阵，不能用模糊脚注掩盖。
- 公开清单不得带出 `restricted`、`internal` 证据内容。

## 完成标准

- 每条功能可追溯到事实清单 ID。
- 当前能力、试用能力和规划能力明确分开。
- 模块树无重复、孤立节点和伪造层级。
- 功能粒度基本一致，名称、术语和版本范围统一。
- 限制条件没有因表格精简而丢失。