---
name: ba
version: "1.0.0"
category: workflow
description: "当用户输入/analyze、/audit、/doc命令，或需要业务流程分析、需求建模、PRD评审、5W1H分析时使用。不要用于代码实现、测试编写、架构设计。Use when users input /analyze, /audit, /doc commands, or need business process analysis, requirement modeling, PRD review, or 5W1H analysis. Do NOT use for code implementation, testing, or architecture design."
triggers:
  zh: ["业务分析", "需求分析", "需求建模", "5W1H分析", "MECE"]
  en: ["analyze", "audit", "doc", "business process analysis", "requirement modeling", "PRD review", "5W1H analysis"]
license: MIT
compatibility: Node.js >= 18, Java 11+
config: 
  - workflow-config.yaml
dependencies: 
  - baseline
metadata: 
author: "neuqik@hotmail.com"
created: "2026-06-16"
updated: "2026-06-16"
status: "stable"
---

# 业务分析 / Business Analysis

## Changelog / 版本履历
<!-- Track all changes to this skill. Update this table whenever you modify the skill. -->
| 日期 | 版本 | 变更摘要 |
|------|------|---------|
| 2026-06-16 | 1.0.0 | 规范化调整 |

## Description / 描述
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. 运用专业方法论进行需求分析和业务建模，输出结构化的业务分析结果，为后续功能点提取和开发规格生成提供基础。

## Triggers / 触发词
<!-- List keywords that should trigger this skill. These are used by routing systems like 'easy' to auto-select skills. -->
- English: 'analyze', 'audit', 'doc', 'business process analysis', 'requirement modeling', 'PRD review', '5W1H analysis'
- 中文: '业务分析', '需求分析', '需求建模', '5W1H分析', 'MECE'

## Capabilities / 能力
<!-- List specific capabilities this skill provides. Each item should be a concrete ability with brief explanation. -->
- 5W1H分析法 - 对每个需求进行Why/What/Who/When/Where/How六个维度的完整分析
- MECE原则应用 - 确保业务分析无遗漏、无重叠，相互独立且完全穷尽
- CRUD矩阵生成 - 分析实体与操作的对应关系(实体 × Create/Read/Update/Delete + 列表/导出)
- 多角度业务设计分析 - 从用户角度、部门架构角度、角色角度三个核心视角进行业务分析
- 业务建模 - 生成用例图、流程图、状态图等标准业务模型
- 业务规则提取 - 提取并分类硬性/软性规则，标注优先级和来源

## Dependencies / 依赖
<!-- List other skills, config files, or resources this skill depends on. Explain why each dependency is needed. -->
- baseline - 提供业务基线文档作为分析输入
- workflow-config.yaml - 配置多角度分析的触发条件和处理规则
- textutil/openpyxl/xlrd - 处理二进制文件格式(docx/xlsx/xls)

## Usage / 使用方式

### Invocation / 调用方式
This skill is typically invoked via the workflow router when trigger keywords are detected, or directly via expert invocation for specific business analysis tasks.

### Parameters / 参数
| 参数 | 类型 | 必填 | 说明 |
|------|------|------|------|
| prd_document | string | ✅ | PRD文档或业务需求描述文本 |
| user_perspective_docs | array | ❌ | 用户角度文档列表（用户需求说明、用户画像等） |
| dept_architecture_docs | array | ❌ | 部门架构文档列表（组织架构图、部门职能说明等） |
| role_perspective_docs | array | ❌ | 角色角度文档列表（角色权限表、岗位职责说明等） |

### Example / 示例
```
/ba prd_document="用户管理系统需求"
```

## Output Format / 输出格式
Business analysis report in Markdown format containing: overview, multi-perspective analysis, 5W1H analysis, use case analysis, process analysis, state analysis, CRUD matrix, business rules, enum coding conventions, permission matrix, risks & assumptions, and appendix with fact basis index.

## Configuration / 配置
The skill reads workflow-config.yaml for multi-perspective analysis settings:
- multi_perspective_enabled: boolean (default true)
- perspective_scan_timeout: number (default 30000ms)
- binary_file_handling: object with strategies for docx/xlsx/pdf

## Workflow / 工作流程
1. Step 0: Multi-Perspective Document Scan - Scan for user, department architecture, and role perspective documents
2. Step 1: Requirement Gathering - Collect all input documents and create raw requirement list
3. Step 2: 5W1H Analysis - Perform six-dimensional analysis for each requirement
4. Step 3: Business Modeling - Generate use case diagrams, process flows, and state diagrams
5. Step 4: CRUD Matrix Generation - Create complete operation matrix for all entities
6. Step 5: Business Rule Extraction - Extract and classify all business rules with sources
7. Step 6: Iterative Deepening (Optional) - Execute deeper analysis levels when requested

## Auto-Review / 自检清单
<!-- Checklist that should be automatically verified after skill execution. This helps ensure quality and completeness. -->
| # | 检查项 |
|---|--------|
| 1 | 每个需求是否完成完整的5W1H分析 |
| 2 | 业务实体是否有完整状态定义 |
| 3 | CRUD矩阵是否覆盖所有业务操作 |
| 4 | 业务规则是否标注优先级和来源 |
| 5 | 多角度文档是否执行了多角度分析 |
| 6 | 分析报告中的每个结论是否可追溯到源文档 |
| 7 | 用例图、流程图、状态图之间是否保持一致 |

# PDD-Business Analysis / 业务分析技能

## Core Concept / 核心概念

### 🇨🇳
运用专业方法论进行需求分析和业务建模，输出结构化的业务分析结果，为后续功能点提取和开发规格生成提供基础。

**输入**: 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

## 方法论工具箱 / Methodology Toolbox

### 🇨🇳
### 5W1H 分析法

| 维度 | 问题 | 分析要点 |
|------|------|---------|
| **Why** | 为什么做？ | 业务背景、目标、价值 |
| **What** | 做什么？ | 功能范围、业务内容 |
| **Who** | 谁来做？ | 角色划分、职责边界 |
| **When** | 何时做？ | 时间要求、里程碑 |
| **Where** | 在哪做？ | 使用场景、环境 |
| **How** | 怎么做？ | 实现方式、流程 |

### MECE 原则

确保业务分析无遗漏、无重叠: 相互独立(各分析项不交叉重叠) | 完全穷尽(覆盖所有业务场景)

**检验清单**: 子类别是否相互独立? | 所有类别是否覆盖完整? | 是否有遗漏的业务场景? | 是否有重叠的功能定义?

### CRUD 矩阵

分析实体与操作的对应关系(实体 × Create/Read/Update/Delete + 列表/导出)

### 多角度业务设计分析 / Multi-Perspective Business Design Analysis

**触发条件**: 当提供以下相关角度文档时，必须从不同角度出发进行业务设计分析，而非仅从单一角度考虑：

#### 三个核心分析视角

| 视角 | 英文 | 关注重点 | 分析产出 |
|------|------|---------|---------|
| **用户角度** | User Perspective | 用户体验、操作便捷性、界面交互、学习成本、错误容忍 | 用户旅程图、交互流程、痛点清单 |
| **部门架构角度** | Department Architecture Perspective | 部门职责边界、跨部门协作流程、审批层级、权限划分、组织适配 | 跨部门泳道图、RACI矩阵、组织架构适配表 |
| **角色角度** | Role Perspective | 角色权限矩阵、角色职责定义、角色间协作关系、角色切换场景 | 角色画像、权限矩阵、角色交互图 |

#### 分析流程

```
Step A: 识别可用视角文档
  ├── 存在用户角度文档？ → 提取用户旅程和痛点
  ├── 存在部门架构文档？ → 提取组织关系和协作流程
  └── 存在角色角度文档？ → 提取角色权限和职责边界

Step B: 交叉验证
  ├── 用户需求 vs 部门约束 → 识别冲突点并标注优先级
  ├── 角色权限 vs 组织架构 → 检查权限与部门职责是否一致
  └── 用户旅程 vs 角色切换 → 验证角色切换场景是否覆盖完整

Step C: 整合输出
  └── 在 5W1H 分析的 Who/How 维度中整合多角度发现的规则和约束
```

#### 多角度分析检查清单

- [ ] 是否已收集用户角度文档？若已收集，是否已提取关键旅程和痛点？
- [ ] 是否已收集部门架构文档？若已收集，是否已梳理跨部门协作规则？
- [ ] 是否已收集角色角度文档？若已收集，是否已定义完整的角色权限矩阵？
- [ ] 不同视角之间的规则冲突是否已识别并标注？
- [ ] 是否存在某个视角未被文档覆盖？是否标记为推断/待确认？
- [ ] 多角度整合后的业务规则是否保持了 MECE 原则（无遗漏、无重叠）？

#### 多角度冲突处理规则

| 冲突类型 | 处理方式 | 优先级 |
|---------|---------|--------|
| 用户需求 vs 部门约束 | 标注冲突，由部门约束优先，同时在风险中记录用户体验影响 | P0 |
| 角色权限 vs 组织架构 | 以组织架构为准，标注权限差异作为待确认项 | P1 |
| 用户旅程 vs 角色切换 | 补充缺失的角色切换场景，标注为推断 | P2 |
| 跨部门流程 vs 单角色操作 | 以跨部门流程为准，确保每个部门都有明确的责任人 | P1 |

> 🇺🇸 English version: see [references/methodology-toolbox-en.md](references/methodology-toolbox-en.md)

## 分析流程 / Analysis Flow

### 🇨🇳
### Step 0: 多角度文档扫描（前置步骤）
在执行标准分析前，先扫描是否存在以下角度的相关文档：
- **用户角度文档**: 用户需求说明、用户画像、用户调研报告、UX设计稿
- **部门架构角度文档**: 组织架构图、部门职能说明、跨部门协作规范、管理层级文件
- **角色角度文档**: 角色权限表、岗位职责说明、审批权限矩阵、角色定义文档

如存在任一角度的文档，执行「多角度业务设计分析」流程（见方法论工具箱）。

### Step 1: 需求收集
PRD文档原文 | 业务流程描述 | 业务规则文档 | 现有系统截图/文档 | 竞品分析资料 | 用户角度文档 | 部门架构文档 | 角色角度文档 → 输出:原始需求清单

### Step 2: 5W1H 分析

对每个需求进行六维分析:
- **Why**: 业务背景/核心价值/成功标准
- **What**: 功能描述/范围边界/不做事项
- **Who**: 发起角色/参与角色/审批角色/受益角色（**如存在角色角度文档，则以此为准进行角色映射**）
- **When**: 开始时间/结束时间/周期特性(实时/周期/事件)
- **Where**: 使用场景/使用环境/接入方式（**如存在用户角度文档，则以此为准定义使用场景**）
- **How**: 实现方式/关键流程/技术约束（**如存在部门架构文档，则需考虑跨部门协作流程和审批层级**）

### Step 3: 业务建模

**a. 用例图(Use Case Diagram)**: 参与者+用例+关系
  - **多角度补充**: 如果存在用户角度文档，参与者需包含最终用户；如果存在角色角度文档，参与者按角色划分；如果存在部门架构文档，需标注跨部门参与者

**用例模板**:
```markdown
### UC-[编号]: [用例名称]
**参与者**: [主要参与者]
**前置条件**: [进入系统前的状态]
**基本流程**: 1.[步骤1] → 2.[步骤2] → 3.[步骤3]
**扩展流程**: [条件A]:[扩展1] | [条件B]:[扩展2]
**异常流程**: [异常1]:[处理方式]
**涉及角色**: [角色1], [角色2]  (如有角色角度文档)
**涉及部门**: [部门1], [部门2]  (如有部门架构文档)
**用户影响**: [用户体验影响描述]  (如有用户角度文档)
```

**b. 流程图(Process Flow)**: 开始→判断条件→分支处理→循环→结束
  - **多角度补充**: 如存在部门架构文档，使用泳道图标注各部门职责；如存在角色角度文档，标注每个步骤的执行角色

**c. 状态图(State Diagram)**:

**状态定义模板**:
```markdown
### 实体状态机
**实体**: [实体名称]
| 状态 | 代码 | 含义 | 可转入 | 操作角色 | 可见部门 |
|------|------|------|--------|---------|---------|
| 草稿 | DRAFT | 初始状态 | SUBMITTED | 创建者 | 本部门 |
| 已提交 | SUBMITTED | 已提交待审核 | APPROVED,REJECTED | 审核人 | 相关部门 |
| 已审批 | APPROVED | 审批通过 | ARCHIVED | 审批人 | 全部门 |
| 已拒绝 | REJECTED | 审批拒绝 | DRAFT | 审核人 | 本部门 |
```

### Step 4: CRUD 矩阵生成
实体 × 创建/读取/更新/删除/列表/导出 的完整操作矩阵
  - **多角度补充**: 每个操作标注允许的角色和可见的部门范围

### Step 5: 业务规则提取

| 规则ID | 规则描述 | 约束类型 | 优先级 | 来源视角 | 来源文档 |
|--------|---------|---------|--------|---------|---------|
| BR-001 | [规则描述] | 硬性/软性规则 | P0/P1/P2 | 用户/部门/角色 | [文档引用] |

**权限类规则子模板**（当业务涉及多角色、多层级数据可见性时使用）: 描述行级权限(谁看哪些行)、列级权限(谁看哪些字段)、聚合级权限(谁可下钻到哪个粒度)。每级权限标注数据范围等价条件（SQL WHERE 子句或自然语言描述）。

### Step 6: 迭代深化（可选增强）

**触发条件**: 用户要求「继续详细拆解」「进一步深化」「落实到具体业务点」时执行。

**标准深化路径**: 从粗到细逐层推进，每层在前一层基础上增加粒度：

| 层级 | 深化方向 | 产物增量 |
|------|---------|---------|
| L1 系统级 | 定义系统边界、5W1H | 系统定义文档 |
| L2 模块级 | 拆解为功能模块，逐个分析 | 功能需求清单 |
| L3 角色级 | 为每个角色定义首屏指标 | 逐角色指标表 |
| L4 人员级 | 为每个具体岗位定义指标（结合组织架构表） | 逐人逐业务线指标表 |
| L5 场景级 | 注入特殊业务场景，逐场景分析 | 特殊场景分析文档 |
| L6 链路级 | 为每个指标定义下钻路径→底层业务数据 | 指标-下钻全链路映射表 |
| L7 整合级 | 合并碎片文档为权威终版 | 终版需求规格书 |

**触发 EXEC-BA-006 规则**: 当前层级未完成时跳转到下一层 → 🟡 WARN → 建议「当前层级尚未完整覆盖，是否继续深化当前层级？」 / When user requests deepening but current level is incomplete → suggest completing current level first

> 🇺🇸 English version: see [references/analysis-flow-en.md](references/analysis-flow-en.md)

## 输出规范 / Output Specification

### 🇨🇳
### 业务分析报告结构
1. **概述**: 文档信息(模块编号/名称/日期/版本) | 业务背景 | 目标与价值
2. **多角度视角分析**（如有相关文档）: 用户角度分析 | 部门架构角度分析 | 角色角度分析 | 视角冲突与整合
3. **5W1H分析**: 详见Step 2
4. **用例分析**: 详见Step 3.a
5. **流程分析**: 详见Step 3.b
6. **状态分析**: 详见Step 3.c
7. **CRUD矩阵**: 详见Step 4
8. **业务规则**: 详见Step 5（含来源视角标注）
9. **枚举编码约定**: 每个枚举必须给出显示名(中文)+编码值(英文snake_case小写)
10. **权限矩阵**: 角色×状态×操作的操作权限矩阵（整合角色角度和部门架构角度）
11. **风险与假设**: 风险(ID/描述/影响/概率/应对) | 假设(ID/描述/验证方式)
12. **附录**: 术语表 | 参考文档 | **事实依据索引**（格式：`| 代码 | 文件路径 | 用途 |`，列出所有引用的源文件编码）

### 🇺🇸
### Business Analysis Report Structure
1. **Overview**: Document info (module number/name/date/version) | Business background | Goals & value
2. **Multi-Perspective Analysis** (if related docs exist): User perspective analysis | Department architecture perspective analysis | Role perspective analysis | Perspective conflicts & integration
3. **5W1H Analysis**: See Step 2
4. **Use Case Analysis**: See Step 3.a
5. **Process Analysis**: See Step 3.b
6. **State Analysis**: See Step 3.c
7. **CRUD Matrix**: See Step 4
8. **Business Rules**: See Step 5 (with source perspective annotations)
9. **Enum Coding Conventions**: Each enum must provide display name (Chinese) + code value (English snake_case lowercase)
10. **Permission Matrix**: Role × State × Operation permission matrix (integrating role perspective and department architecture perspective)
11. **Risks & Assumptions**: Risks (ID/description/impact/probability/mitigation) | Assumptions (ID/description/verification method)
12. **Appendix**: Glossary | Reference documents | **Fact Basis Index** (format: `| Code | File Path | Purpose |`, listing all referenced source file codes)

## Guardrails / 安全护栏

### 🇨🇳
**必须遵守**: 每个需求必须有明确的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 | **If multi-perspective documents exist, MUST execute multi-perspective analysis; MUST NOT skip**

**Avoid**: ❌ Missing critical business flows | ❌ Incomplete or non-exclusive state definitions | ❌ Business rules not matching actual business | ❌ Inconsistency between use cases and process descriptions | ❌ **Having multi-perspective documents but analyzing from only one perspective** | ❌ **Ignoring any existing user, department architecture, or role perspective document**

## 与其他技能协作 / Skill Collaboration

### 🇨🇳
| 协作技能 | 协作方式 | 传入数据 | 期望输出 |
|---------|---------|---------|---------|
| **pdd-baseline** | Sequential（上游） | 原始业务文件集 | 业务基线文档（条款/角色/流程/制度/约束） |
| **pdd-main** | 流程调度 | 分析请求 | 业务分析报告 |
| **pdd-extract-features** | Sequential（下游） | 分析报告 | 功能点矩阵 |
| **pdd-generate-spec** | Sequential（下游） | 分析报告 | 开发规格 |

### 🇺🇸
| Collaborating Skill | Mode | Input Data | Expected Output |
|--------------------|------|------------|-----------------|
| **pdd-baseline** | Sequential (upstream) | Raw business document set | Business Baseline Document (clauses/roles/processes/policies/constraints) |
| **pdd-main** | Flow scheduling | Analysis request | Business analysis report |
| **pdd-extract-features** | Sequential (downstream) | Analysis report | Feature matrix |
| **pdd-generate-spec** | Sequential (downstream) | Analysis report | Development spec |

***

## Iron Law / 核心铁律

### 🇨🇳
1. **方法论驱动分析**: 必须使用5W1H、MECE、CRUD等标准方法论进行分析,不得凭直觉或经验随意输出分析结果。
2. **不越界做技术决策**: 业务分析的产出是业务层面的描述(用例、流程、规则),不涉及具体技术实现方案、数据库设计或接口定义。
3. **完整性优先于速度**: 每个需求必须完成全部六个维度的5W1H分析,不得因为"看起来简单"而跳过某些维度。
4. **可追溯性保障**: 分析报告中的每个结论都必须能追溯到PRD文档原文或用户提供的业务资料,不得编造不存在业务规则。**追溯规范**: 每条结论标注 `[文件代码 §条款序号]` 格式的源引用（如 `[S01 §第12条]`）；输出文档末尾须附带「事实依据索引」表，列出所有引用的源文件代码、文件路径、用途。
5. **模型一致性**: 用例图、流程图、状态图之间必须保持一致,同一实体在不同图中的行为描述不得矛盾。
6. **多角度强制覆盖**（新增）: 当用户提供了用户角度、部门架构角度、角色角度的相关文档时，必须从这三个角度分别进行分析，并在分析报告中体现多角度整合结果。不得以"与核心流程无关"为由跳过任一角度。

**违规示例**: ❌ 在业务分析中直接设计数据库表结构 | ❌ 因为"登录功能很简单"而跳过其5W1H分析 | ❌ 编造PRD中未提及的业务规则 | ❌ 用例图中显示的操作在流程图中没有对应步骤 | ❌ 使用非标准术语而不在术语表中定义 | ❌ **全篇PRD无一条源文件引用，无法验证结论来源** | ❌ **存在组织架构图但未分析部门协作规则** | ❌ **存在角色权限表但未在权限矩阵中体现** | ❌ **仅从技术实现角度分析而忽略用户旅程**

**合规示例**: ✅ 对每个需求执行完整的5W1H分析并记录到报告中 | ✅ 输出用例图和流程图时保持参与者与操作的一致性 | ✅ 所有业务规则都标注来源(如"源自PRD第3章第2节") | ✅ 在术语表中明确定义所有专业词汇 | ✅ 使用MECE原则检验功能点分类是否完整且互斥 | ✅ **扫描并整合用户、部门、角色三个角度文档的分析结果** | ✅ **在状态图中标注每个状态的操作角色和可见部门**

### 🇺🇸
1. **Methodology-Driven Analysis**: MUST use standard methodologies (5W1H, MECE, CRUD) for analysis. NEVER output results based on intuition or experience alone.
2. **No Technical Decision Overreach**: Business analysis outputs are business-level descriptions (use cases, processes, rules). Must NOT involve specific technical implementations, database designs, or API definitions.
3. **Completeness Over Speed**: Every requirement MUST complete all six dimensions of 5W1H analysis. NEVER skip dimensions because something "looks simple".
4. **Traceability Guarantee**: Every conclusion in the analysis report MUST be traceable to PRD document text or user-provided business materials. NEVER fabricate non-existent business rules. **Citation Format**: Annotate every claim with `[Source Code §Clause]` (e.g. `[S01 §Art.12]`); the output document MUST include a "Fact Basis Index" table listing all referenced source file codes, paths, and purposes.
5. **Model Consistency**: Use case diagrams, flowcharts, and state diagrams MUST remain consistent. The same entity's behavior must not contradict across different diagrams.
6. **Multi-Perspective Mandatory Coverage** (New): When user provides documents from user, department architecture, and role perspectives, MUST analyze from all three perspectives and reflect multi-perspective integration results in the analysis report. MUST NOT skip any perspective on grounds of "irrelevant to core process."

**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 | ❌ **Entire PRD with zero source file citations, making conclusions unverifiable** | ❌ **Having org chart but not analyzing department collaboration rules** | ❌ **Having role permission table but not reflecting in permission matrix** | ❌ **Analyzing only from technical implementation perspective while ignoring user journeys**

**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 | ✅ **Scan and integrate analysis results from user, department, and role perspective documents** | ✅ **Mark operating roles and visible departments for each state in state diagrams**

***

## Rationalization Table / 合理化防御表

| # | Trap / 陷阱 | Question / 请问自己 | Action / 应该怎么做 |
|---|-------------|------------------|------------------|
| 1 | "这个需求很明显,不用写那么详细"<br>"This requirement is obvious, no need for detail" | 明显的需求也可能有隐含的业务规则和边界条件 | 至少完成最小化的5W1H分析模板,确保覆盖关键维度 |
| 2 | "PRD已经写得很清楚了,我总结一下就行"<br>"PRD is clear enough, I'll just summarize" | 总结会丢失细节,后续技能需要完整的分析结果作为输入 | 按照标准模板逐项填写,而非概括性总结 |
| 3 | "这个流程图画起来太费时间"<br>"Flowcharts take too much time" | 流程图是后续功能点提取的关键输入,缺失会导致遗漏 | 使用mermaid语法快速生成,确保至少覆盖主流程和异常分支 |
| 4 | "状态定义差不多就行"<br>"State definitions are good enough" | 不完整的状态定义会导致状态机实现缺陷 | 确保每个状态都有明确的转入/转出条件和触发事件 |
| 5 | "用户没提这个规则,但我认为应该有"<br>"User didn't mention this rule, but I think it should exist" | 编造业务规则会导致实现与实际需求不符 | 将推断标记为"假设"并请用户确认,不得直接作为确定规则 |
| 6 | "组织架构跟功能设计关系不大"<br>"Org structure isn't relevant to feature design" | 忽略部门架构会导致跨部门审批流程设计缺陷 | 必须基于组织架构文档分析跨部门协作规则 |
| 7 | "角色权限以后再说"<br>"Role permissions can be figured out later" | 角色权限是业务规则的核心输入，延后分析会导致返工 | 如有角色文档，必须在第一步就完成权限矩阵分析 |

**常见陷阱 / Common Traps**:
1. **"表面分析"陷阱**: 只描述"做什么"而不深究"为什么"和"怎么做" → 强制完成5W1H全部分析,特别是Why和How维度
2. **"技术前置"陷阱**: 过早引入技术实现细节 → 始终保持业务视角,技术决策留给后续技能
3. **"模型脱节"陷阱**: 用例、流程、状态图各自独立绘制未进行交叉验证 → 在输出前强制执行模型一致性检查清单
4. **"术语泛滥"陷阱**: 大量使用专业术语但不提供定义 → 强制维护术语表,首次出现时必须定义
5. **"单视角"陷阱**: 仅从功能角度分析而忽略用户、部门、角色的多角度约束 → 强制扫描多角度文档并整合分析

***

## Red Flags / 红旗警告

### Layer 1: Input Guards / 输入防护
- **INPUT-BA-001**: PRD文档为空或内容少于100字 → 🔴 CRITICAL → 终止并提示用户提供有效的PRD文档 / Terminate and prompt user to provide valid PRD document
- **INPUT-BA-002**: PRD文档格式无法解析(非文本/Markdown) → 🔴 CRITICAL → **二元文件处理策略**: docx 文件使用 `textutil -convert txt` 提取文本；xlsx/xls 使用 `openpyxl`/`xlrd` 提取表格数据；PDF 和图片文件需用户提供文字版或 OCR 转换，无法自动提取 → 提示用户提供文本版本或 OCR / Binary file handling strategy: docx → `textutil -convert txt`; xlsx/xls → `openpyxl`/`xlrd`; PDF/images → request text version or OCR from user. Cannot auto-extract.
- **INPUT-BA-003**: 用户只提供了需求标题而无详细描述 → 🟡 WARN → 尝试通过对话收集更多信息,基于有限信息进行分析但标注不确定性 / Try to gather more info via conversation, analyze with limited data but mark uncertainty
- **INPUT-BA-004**: 检测到用户/部门/角色角度文档但未在多角度分析中使用 → 🔴 CRITICAL → 重新分析并整合多角度视角 / Re-analyze and integrate multi-perspective views
- **INPUT-BA-005**: 用户在分析过程中提供了新的业务材料（增量输入） → 🟡 WARN → 需执行以下步骤: ①扫描新材料与已有分析的冲突点；②标注每条新信息为「增量/覆盖」；③识别是否影响已输出的结论 → 输出增量变更摘要 / When user provides new materials mid-analysis: ①Scan conflicts with existing analysis; ②Mark each new item as [新增/Incremental] or [覆盖/Override]; ③Identify impact on already-output conclusions → Output incremental change summary

### Layer 2: Execution Guards / 执行防护
- **EXEC-BA-001**: 跳过5W1H任一维度的分析 → 🔴 CRITICAL → 补充完整后再继续 / Complete missing dimensions before continuing
- **EXEC-BA-002**: 业务规则未标注优先级(P0/P1/P2) → 🟡 WARN → 补充优先级标注,默认设为P1 / Add priority labels, default to P1
- **EXEC-BA-003**: CRUD矩阵未覆盖所有已识别的实体 → 🔴 CRITICAL → 补充遗漏实体的CRUD分析 / Add CRUD analysis for missing entities
- **EXEC-BA-004**: 状态机的状态转换缺少触发事件或条件 → 🟡 WARN → 补充转换条件说明 / Add transition condition descriptions
- **EXEC-BA-005**: 存在多角度文档但分析报告未包含多角度整合结果 → 🔴 CRITICAL → 补充多角度分析章节 / Add multi-perspective analysis section
- **EXEC-BA-006**: 当前深化层级未完成覆盖时跳转到下一层 → 🟡 WARN → 建议先完成当前层级 / Jumping to next deepening level when current level is incomplete → suggest completing current first

### Layer 3: Output Guards / 输出防护
- **OUTPUT-BA-001**: 业务分析报告缺少风险与假设章节 → 🔴 CRITICAL → 补充风险识别和假设声明 / Add risk identification and assumption statements
- **OUTPUT-BA-002**: 报告中的结论无法追溯到源文档 → 🟡 WARN → 补充引用来源或标记为推断 / Add citation sources or mark as inference
- **OUTPUT-BA-003**: 术语表中有未定义的术语 → 🟡 WARN → 补充术语定义或替换为通俗表达 / Define terms or replace with plain language
- **OUTPUT-BA-004**: 多角度分析中缺少视角冲突与整合说明 → 🔴 CRITICAL → 补充视角冲突识别和整合策略 / Add perspective conflict identification and integration strategy
- **OUTPUT-BA-005**: 同一主题的子文档超过 5 个 → 🔴 CRITICAL → 必须合并为一份权威文档（命名标注「终版」），旧文档标记为历史参考。合并后的权威文档须包含完整内容，读者不需要翻阅其他子文档 / When >5 sub-documents exist for the same topic: MUST merge into one authoritative document (labeled "Final"). Old docs marked as historical. The merged document must be self-contained.

**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