메뉴
"PDD框架下的业务分析Skill，运用专业方法论进行需求分析和业务建模。当用户输入/analyze、/audit、/doc等命令，或需要对业务流程、管理制度、Excel表单进行专业分析时触发。支持中文触发：业务分析、需求分析、需求建模、5W1H分析、MECE、流程分析。"
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | pdd-ba |
| description | "PDD框架下的业务分析Skill，运用专业方法论进行需求分析和业务建模。当用户输入/analyze、/audit、/doc等命令，或需要对业务流程、管理制度、Excel表单进行专业分析时触发。支持中文触发：业务分析、需求分析、需求建模、5W1H分析、MECE、流程分析。" |
运用专业方法论进行需求分析和业务建模,输出结构化的业务分析结果,为后续功能点提取和开发规格生成提供基础。
输入: PRD文档/业务需求描述/流程说明 | 输出: 业务分析报告/用例图/流程图/状态图/CRUD矩阵 | 不负责: 代码实现/测试编写/架构设计
Applies professional methodology for requirement analysis and business modeling, outputting structured business analysis results as the foundation for subsequent feature extraction and development spec generation.
Input: PRD documents / Business requirement descriptions / Process specifications | Output: Business analysis report / Use case diagrams / Flowcharts / State diagrams / CRUD matrix | NOT responsible for: Code implementation / Test writing / Architecture design
| 维度 | 问题 | 分析要点 |
|---|---|---|
| Why | 为什么做？ | 业务背景、目标、价值 |
| What | 做什么？ | 功能范围、业务内容 |
| Who | 谁来做？ | 角色划分、职责边界 |
| When | 何时做？ | 时间要求、里程碑 |
| Where | 在哪做？ | 使用场景、环境 |
| How | 怎么做？ | 实现方式、流程 |
确保业务分析无遗漏、无重叠: 相互独立(各分析项不交叉重叠) | 完全穷尽(覆盖所有业务场景)
检验清单: 子类别是否相互独立? | 所有类别是否覆盖完整? | 是否有遗漏的业务场景? | 是否有重叠的功能定义?
分析实体与操作的对应关系(实体 × Create/Read/Update/Delete + 列表/导出)
| Dimension | Question | Analysis Points |
|---|---|---|
| Why | Why do it? | Business background, goals, value |
| What | What to do? | Feature scope, business content |
| Who | Who does it? | Role division, responsibility boundaries |
| When | When to do? | Time requirements, milestones |
| Where | Where to do? | Usage scenarios, environment |
| How | How to do? | Implementation approach, process |
Ensure business analysis is complete and non-overlapping: Mutually Exclusive (analysis items don't overlap) | Collectively Exhaustive (covers all business scenarios)
Checklist: Are sub-categories mutually exclusive? | Are all categories fully covered? | Any missing business scenarios? | Any overlapping feature definitions?
Analyze entity-operation mapping (entity × Create/Read/Update/Delete + List/Export)
PRD文档原文 | 业务流程描述 | 业务规则文档 | 现有系统截图/文档 | 竞品分析资料 → 输出:原始需求清单
对每个需求进行六维分析:
a. 用例图(Use Case Diagram): 参与者+用例+关系
用例模板:
### UC-[编号]: [用例名称]
**参与者**: [主要参与者]
**前置条件**: [进入系统前的状态]
**基本流程**: 1.[步骤1] → 2.[步骤2] → 3.[步骤3]
**扩展流程**: [条件A]:[扩展1] | [条件B]:[扩展2]
**异常流程**: [异常1]:[处理方式]
b. 流程图(Process Flow): 开始→判断条件→分支处理→循环→结束
c. 状态图(State Diagram):
状态定义模板:
### 实体状态机
**实体**: [实体名称]
| 状态 | 代码 | 含义 | 可转入 |
|------|------|------|--------|
| 草稿 | DRAFT | 初始状态 | SUBMITTED |
| 已提交 | SUBMITTED | 已提交待审核 | APPROVED,REJECTED |
| 已审批 | APPROVED | 审批通过 | ARCHIVED |
| 已拒绝 | REJECTED | 审批拒绝 | DRAFT |
实体 × 创建/读取/更新/删除/列表/导出 的完整操作矩阵
| 规则ID | 规则描述 | 约束类型 | 优先级 |
|---|---|---|---|
| BR-001 | [规则描述] | 硬性/软性规则 | P0/P1/P2 |
PRD document text | Business process descriptions | Business rule documents | Existing system screenshots/docs | Competitive analysis materials → Output: Raw requirement list
Six-dimensional analysis for each requirement:
a. Use Case Diagram: Actors + Use cases + Relationships
Use Case Template:
### UC-[ID]: [Use Case Name]
**Actors**: [Primary actor]
**Preconditions**: [State before entering system]
**Basic Flow**: 1.[Step 1] → 2.[Step 2] → 3.[Step 3]
**Alternative Flows**: [Condition A]:[Alt 1] | [Condition B]:[Alt 2]
**Exception Flows**: [Exception 1]:[Handling]
b. Process Flow: Start → Decision → Branch processing → Loop → End
c. State Diagram:
State Definition Template:
### Entity State Machine
**Entity**: [Entity Name]
| State | Code | Meaning | Transitions To |
|-------|------|---------|---------------|
| Draft | DRAFT | Initial state | SUBMITTED |
| Submitted | SUBMITTED | Pending review | APPROVED, REJECTED |
| Approved | APPROVED | Review passed | ARCHIVED |
| Rejected | REJECTED | Review rejected | DRAFT |
Complete operation matrix: Entity × Create/Read/Update/Delete/List/Export
| Rule ID | Rule Description | Constraint Type | Priority |
|---|---|---|---|
| BR-001 | [Rule description] | Hard/Soft rule | P0/P1/P2 |
必须遵守: 每个需求必须有明确的5W1H分析 | 每个业务实体必须有状态定义 | CRUD矩阵必须覆盖所有业务操作 | 业务规则必须标注优先级
避免事项: ❌ 遗漏关键业务流程 | ❌ 状态定义不完整或不互斥 | ❌ 业务规则与实际业务不符 | ❌ 用例与流程描述不一致
MUST comply: Every requirement MUST have complete 5W1H analysis | Every business entity MUST have state definitions | CRUD matrix MUST cover all business operations | Business rules MUST be marked with priority
Avoid: ❌ Missing critical business flows | ❌ Incomplete or non-exclusive state definitions | ❌ Business rules not matching actual business | ❌ Inconsistency between use cases and process descriptions
| 协作技能 | 协作方式 | 传入数据 | 期望输出 |
|---|---|---|---|
| pdd-main | 流程调度 | 分析请求 | 业务分析报告 |
| pdd-extract-features | Sequential | 分析报告 | 功能点矩阵 |
| pdd-generate-spec | Sequential | 分析报告 | 开发规格 |
| Collaborating Skill | Collaboration Mode | Input Data | Expected Output |
|---|---|---|---|
| pdd-main | Workflow scheduling | Analysis request | Business analysis report |
| pdd-extract-features | Sequential | Analysis report | Feature matrix |
| pdd-generate-spec | Sequential | Analysis report | Development spec |
违规示例: ❌ 在业务分析中直接设计数据库表结构 | ❌ 因为"登录功能很简单"而跳过其5W1H分析 | ❌ 编造PRD中未提及的业务规则 | ❌ 用例图中显示的操作在流程图中没有对应步骤 | ❌ 使用非标准术语而不在术语表中定义
合规示例: ✅ 对每个需求执行完整的5W1H分析并记录到报告中 | ✅ 输出用例图和流程图时保持参与者与操作的一致性 | ✅ 所有业务规则都标注来源(如"源自PRD第3章第2节") | ✅ 在术语表中明确定义所有专业词汇 | ✅ 使用MECE原则检验功能点分类是否完整且互斥
Violation Examples: ❌ Designing database table structures directly in business analysis | ❌ Skipping 5W1H analysis because "login is simple" | ❌ Fabricating business rules not mentioned in PRD | ❌ Operations in use case diagram have no corresponding steps in flowchart | ❌ Using non-standard terms without defining them in glossary
Compliance Examples: ✅ Execute complete 5W1H analysis for each requirement and record in report | ✅ Maintain consistency between actors and operations when outputting use case and process diagrams | ✅ Cite sources for all business rules (e.g., "from PRD Ch.3 Sec.2") | ✅ Define all technical terms clearly in glossary | ✅ Use MECE principle to verify feature classification is complete and mutually exclusive
| # | Trap / 陷阱 | Question / 请问自己 | Action / 应该怎么做 |
|---|---|---|---|
| 1 | "这个需求很明显,不用写那么详细" "This requirement is obvious, no need for detail" | 明显的需求也可能有隐含的业务规则和边界条件 | 至少完成最小化的5W1H分析模板,确保覆盖关键维度 |
| 2 | "PRD已经写得很清楚了,我总结一下就行" "PRD is clear enough, I'll just summarize" | 总结会丢失细节,后续技能需要完整的分析结果作为输入 | 按照标准模板逐项填写,而非概括性总结 |
| 3 | "这个流程图画起来太费时间" "Flowcharts take too much time" | 流程图是后续功能点提取的关键输入,缺失会导致遗漏 | 使用mermaid语法快速生成,确保至少覆盖主流程和异常分支 |
| 4 | "状态定义差不多就行" "State definitions are good enough" | 不完整的状态定义会导致状态机实现缺陷 | 确保每个状态都有明确的转入/转出条件和触发事件 |
| 5 | "用户没提这个规则,但我认为应该有" "User didn't mention this rule, but I think it should exist" | 编造业务规则会导致实现与实际需求不符 | 将推断标记为"假设"并请用户确认,不得直接作为确定规则 |
常见陷阱 / Common Traps:
Trigger Handling / 触发处理流程: 🔴 CRITICAL → 立即停止,报告问题详情,等待指示 | Stop immediately & report details, wait for instructions 🟡 WARN → 记录警告到分析日志,尝试自动修复,在最终报告中标注 | Log warning, attempt auto-fix, annotate in final report 🔵 INFO → 记录信息,正常继续 | Log info, continue normally
"PDD熵减智能体，持续监控和偿还技术债务，防止系统腐化。当用户需要代码清理、文档更新、技术债务管理、架构对齐、熵减、垃圾回收、清理技术债务时自动触发。即使用户只说'熵减'、'清理技术债务'或'垃圾回收'，也应触发此Skill。支持中文触发：熵减、技术债务、代码清理、文档更新、架构对齐、垃圾回收。"
根据开发规格实现功能点代码的核心Skill。当用户想要开始编码实现、根据规格文档生成代码、实现功能点时调用此Skill。此Skill会自动调用pdd-template-engine生成基础代码框架，然后由software-engineer补充业务逻辑。即使只有规格文档没有明确说'实现'，只要涉及代码生成、功能开发，都应触发此Skill。支持中文触发：实现功能点、编码实现、开始编码、功能开发、代码实现、PDD实现。
PRD驱动开发的主入口Skill，协调整个开发流程。当用户想要基于PRD文档进行功能开发、从需求文档生成代码、执行PDD方法论流程、开发业务模块、实现完整功能、'搞个功能'、'资产转让'、'国有产权转让'、'帮我搞个资产转让的功能'时必须调用此Skill。即使用户没有明确说'使用PDD'，只要涉及PRD文档、需求文档、功能点开发、规格文档、模块开发、根据文档开发、业务功能实现、'开发ZCCZ'、'我想开发'、'搞个功能'等场景，都应触发此Skill。此Skill会自动协调pdd-ba、pdd-extract-features、pdd-generate-spec、pdd-implement-feature等子Skill完成从需求分析到代码交付的完整流程。注意：单一接口设计、调试问题、文档查询等场景不应触发此Skill。支持中文触发：PRD驱动开发、PDD开发、功能开发、启动PDD。
"交通事故责任评估与判定专业技能。当用户需要交通事故责任分析、事故现场照片评估、交通法规咨询、事故责任划分、法律依据查询时触发此技能。适用于车辆碰撞事故、行人事故、非机动车事故等各类道路交通事故的责任认定场景。无论用户使用'交通事故'、'车祸'、'责任判定'、'交通法规'、'事故定责'等何种表述，只要涉及交通事故评估或责任认定，均应调用此技能。支持中文触发：交通事故、车祸、责任判定、交通法规、事故定责、责任划分、事故评估、追尾、碰撞、违章、赔偿。"
自动化重构专家技能，将收集到的质量改进任务转化为具体的代码操作。当用户需要代码重构、消除重复、简化复杂度时自动触发。即使用户只说'重构代码'、'消除重复'或'简化代码'，也应触发此Skill。支持中文触发：重构代码、消除重复、简化复杂度、自动重构、代码重构、PDD重构。
代码质量专家，整合Martin Fowler重构技术和GoF设计模式，帮助开发者系统性地提升代码质量。当用户询问代码审查、重构、设计模式、代码异味、SOLID原则或软件架构改进时触发此技能。支持中文触发：代码质量、代码审查、重构、设计模式、代码异味、SOLID原则、架构改进。