requirement
需求分析(doc 文档框架 / interrogate 极刑审问)
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/doccker/cc-use-exp/HEAD/.claude/commands/requirement.md -o ~/.claude/commands/requirement.mdrequirement.md
根据参数选择模式: - `/requirement doc [功能]` → 生成需求文档框架 - `/requirement interrogate [功能]` → 需求极刑审问,挖掘逻辑漏洞 - `/requirement [功能]` → 默认生成文档框架(同 doc) 参数值:「$ARGUMENTS」 --- ## 模式 1:doc(默认) 根据以下信息,生成需求文档框架。 请按照以下模板结构生成,根据实际需求填充内容: --- # [功能名称] 需求文档 作者:wwj 版本:v1.0 日期:[当前日期] 状态:草稿 --- ### 一、背景 <!-- [注释] 简要描述业务背景、问题或机会 --> [背景描述] **所有改动仅对 [范围] 生效,不影响 [其他范围]。** --- ### 二、功能清单 | 序号 | 功能模块 | 功能点 | 优先级 | |------|---------|-------|--------| | 1 | [模块] | [功能点] | 高/中/低 | --- ### 三、[模块1名称] #### 3.1 界面变化 | 变化项 | 原显示 | 新显示 | |--------|-------|--------| | [变化项] | [原] | [新] | #### 3.2 功能说明 **[功能名称]** **触发条件**:[条件描述] **输入/模板字段**: | 字段名 | 是否必填 | 说明 | |--------|---------|------| | [字段] | 是/否 | [说明] | **处理规则**: - 规则1 - 规则2 --- ### 四、[模块2名称] #### 4.1 界面术语变化 | 系统原显示 | 新显示 | |-----------|--------| | [原] | [新] | #### 4.2 新增字段 | 字段 | 说明 | |------|------| | [字段] | [说明] | #### 4.3 处理逻辑 ``` [流程或规则描述] ``` **示例**: | 输入 | 处理 | 输出 | |------|------|------| | [输入] | [处理] | [输出] | --- ### 五、业务流程 ``` ┌─────────────────────────────────────────┐ │ [流程名称] │ ├─────────────────────────────────────────┤ │ 第一步:[步骤名称] │ │ ┌─────────────────────────────────┐ │ │ │ 1. [操作1] │ │ │ │ 2. [操作2] │ │ │ └─────────────────────────────────┘ │ │ ↓ │ │ 第二步:[步骤名称] │ │ ┌─────────────────────────────────┐ │ │ │ 1. [操作1] │ │ │ │ 2. [操作2] │ │ │ └─────────────────────────────────┘ │ └─────────────────────────────────────────┘ ``` --- ### 六、验收清单 #### 6.1 [模块1] - [ ] [验收点1] - [ ] [验收点2] #### 6.2 [模块2] - [ ] [验收点1] - [ ] [验收点2] #### 6.3 约束条件 - [ ] [约束1,如"仅对XX生效"] - [ ] [约束2,如"不影响其他XX"] --- ### 七、非功能需求(如需要) | 需求类型 | 要求 | |---------|------| | 性能 | [要求] | | 兼容性 | [要求] | | 安全性 | [要求] | --- **文档版本历史** | 版本 | 日期 | 作者 | 说明 | |------|------|------|------| | v1.0 | [日期] | wwj | 初稿 | --- ## 模式 2:interrogate 你是一位**极度苛刻的高级系统架构师和产品总监**。你的任务不是帮用户完善需求,而是**挑战和质疑**。 ### 第一步:逻辑漏洞扫描 无情地指出需求中的问题: - 逻辑不通的地方 - 状态缺失(失败了怎么办?网断了怎么办?超时了怎么办?) - 权限定义模糊 - 边界条件未定义 ### 第二步:数据流拷问 针对核心功能,质问数据是如何流转的: - 数据从哪里来?存到哪里? - 并发场景怎么处理? - 数据一致性怎么保证? - 缓存策略是什么? ### 第三步:生成深度调研问卷 基于以上分析,生成《深度需求调研表》: - 问题必须具体 - 给出 A/B/C 选项供选择 - 标注哪些是必须回答的 ### 输出格式 ```markdown ## 🔴 逻辑漏洞 1. **[问题标题]** - 问题描述:... - 潜在风险:... ## 🟡 数据流疑点 1. **[疑点标题]** - 当前理解:... - 需要澄清:... ## 📋 深度需求调研表 ### 必答问题 **Q1:[问题]** - A. [选项A] - B. [选项B] - C. 其他(请说明) ### 建议回答 **Q2:[问题]** - A. [选项A] - B. [选项B] ``` ### 重要提示 - **不要**直接生成 PRD 或需求文档 - **只**生成问卷和质疑 - 用户回答问卷后,再使用 `/requirement doc` 生成正式需求文档
当设计或修改 REST API 响应结构、处理 API 返回值,或生成 Excel/CSV/PDF/对账文件等下游产物时触发。防止 API 设计缺陷导致的字段错位、类型歧义,以及生成产物时关键字段缺失但静默成功的问题。
网关/代理/WAF/CDN 中间件的安全关键词匹配实现规范,防止纯子串匹配误判正常响应内容中的技术术语(如 Cloudflare、502、error)
当 API/任务可能执行超过 10 秒(批量数据处理、远程 API 批量调用、全表扫描、跨租户聚合)时触发。防止同步接口被网关 30s 超时切断、用户重复点击触发并发、状态缓存内存泄漏等问题。提供异步任务状态机标准模板。
当用户操作 .sh、Dockerfile、Makefile、.yml、.yaml 文件,或在 Markdown 中编写 bash 代码块时触发。提供 Bash 编写规范。
前后端接口契约安全规范,适用于接口新增或调整、联调、列表分页异常与临时兼容治理;用于避免响应结构漂移被前端兼容长期掩盖。
当设计或修改 REST API 响应结构、处理 API 返回值,或生成 Excel/CSV/PDF/对账文件等下游产物时触发。防止 API 设计缺陷导致的字段错位、类型歧义,以及生成产物时关键字段缺失但静默成功的问题。
网关/代理/WAF/CDN 中间件响应判定与关键词匹配安全规范。适用于 proxy/gateway/waf/cdn/nginx/openresty/rewrite/redirect 等代码,防止把正常长正文中的 Cloudflare、502、bad gateway、error 等技术术语误判为上游错误。
当 API/任务可能执行超过 10 秒(批量数据处理、远程 API 批量调用、全表扫描、跨租户聚合)时触发。防止同步接口被网关 30s 超时切断、用户重复点击触发并发、状态缓存内存泄漏等问题。提供异步任务状态机标准模板。