docs/zh-CN/skills/product-capability

stars:0
forks:0
watches:0
last updated:N/A

产品能力

该技能将产品意图转化为明确的工程约束。

当问题不在于"我们应该构建什么？"，而在于"在开始实现之前，必须明确哪些条件？"时使用。

使用时机

  • 存在PRD、路线图项、讨论或创始人笔记，但实现约束仍然隐式未明
  • 某个功能跨越多个服务、仓库或团队，在编码前需要一份能力契约
  • 产品意图明确，但架构、数据、生命周期或策略影响仍然模糊
  • 高级工程师在评审中反复重申相同的隐藏假设
  • 你需要一份可跨工具链和会话复用的持久化工件

规范工件

如果仓库中存在持久化的产品上下文文件，例如 PRODUCT.md、docs/product/ 或程序规范目录，请在此处更新。

如果尚不存在能力清单，请使用以下模板创建：

  • docs/examples/product-capability-template.md

目标不是创建另一个规划栈，而是使隐藏的能力约束变得持久且可复用。

不可妥协的规则

  • 不要编造产品事实。明确标记未解决的问题。
  • 将用户可见的承诺与实现细节分开。
  • 明确指出哪些是固定策略、哪些是架构偏好、哪些仍待定。
  • 如果请求与现有仓库约束冲突，请明确说明，而非粉饰太平。
  • 优先使用一份可复用的能力工件，而非零散的临时笔记。

输入

仅读取必要内容：

  1. 产品意图
    • issue、讨论、PRD、路线图笔记、创始人消息
  2. 当前架构
    • 相关仓库文档、契约、模式、路由、现有工作流
  3. 现有能力上下文
    • PRODUCT.md、设计文档、RFC、迁移笔记、运营模式文档
  4. 交付约束
    • 认证、计费、合规、发布、向后兼容、性能、评审策略

核心工作流

1. 重述能力

将需求压缩为一个精确的陈述：

  • 用户或操作者是谁
  • 此功能上线后存在什么新能力
  • 因此带来了什么结果变化

如果此陈述薄弱，实现将会偏离方向。

2. 解析能力约束

提取实现前必须满足的约束：

  • 业务规则
  • 范围边界
  • 不变性条件
  • 信任边界
  • 数据所有权
  • 生命周期转换
  • 发布/迁移要求
  • 故障与恢复预期

这些往往是仅存在于高级工程师记忆中的内容。

3. 定义面向实现的契约

制定一份SRS风格的能力计划，包含：

  • 能力摘要
  • 明确的非目标
  • 角色与界面
  • 所需状态与转换
  • 接口/输入/输出
  • 数据模型影响
  • 安全/计费/策略约束
  • 可观测性与运维要求
  • 阻碍实现的未解决问题

4. 转化为执行

以精确的交接点结束：

  • 可直接实现
  • 需先进行架构评审
  • 需先明确产品细节

如有帮助，可指向下一个ECC原生通道：

  • project-flow-ops
  • workspace-surface-audit
  • api-connector-builder
  • dashboard-builder
  • tdd-workflow
  • verification-loop

输出格式

按以下顺序返回结果：

能力
- 一段重新陈述

约束条件
- 固定规则、不变项和边界

实现契约
- 参与者
- 界面
- 状态与转换
- 接口/数据影响

非目标
- 该通道明确不负责的内容

待定问题
- 仍需解决的阻碍或产品决策

交接
- 下一步应执行的操作及应由哪个ECC通道负责

良好成果

  • 产品意图已足够具体，无需在PR评审中重新发现隐藏约束即可实现。
  • 工程评审拥有持久化工件，而非依赖记忆或Slack上下文。
  • 生成的计划可在Claude Code、Codex、Cursor、OpenCode和ECC 2.0规划界面中复用。
    Good AI Tools