关于 business-analysis
business-analysis 是一套将业务目标转化为技术实现文档的分析规范,面向产品、业务和开发团队。它强调先分析约束与需求,再通过流程图和模板产出文档,并要求将成果保存到项目根目录的 docs/ 文件夹。
主要功能
- 01先分析约束差距与需求
- 02按步骤梳理逻辑和边界情况
- 03使用 Mermaid 绘制流程图
- 04提供 PRD、BRD 和用户故事模板
- 05将文档保存到 docs/ 文件夹
适用场景
- 01将新功能需求整理为产品规格
- 02为复杂流程梳理路径和边界情况
- 03编写面向业务或开发团队的文档
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ kienhaminh/ anti-chaotic --skill business-analysis安装后在 Claude Code 中输入/business-analysis确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
references/best-practices/diagrams.mdreferences/domains/ai-agent.mdblockchain-dapp.mdecommerce.mdeducation.mdfintech.mdfnb.mdhealthtech.mdinternal-tools.mdmarketplace.mdsaas.mdreferences/workflows/collaboration.mdscripts/verify_mermaid.pytemplates/brd.mdchange-request.mdprd-functional.mduse-case.mduser-story-detailed.md详细介绍
业务分析标准
此技能定义了弥合抽象业务目标与具体技术实现之间差距的标准。
🧠 核心思维与理念
重要
文档输出位置:所有生成的文档(PRD、BRD、技术规范、用户故事等)必须保存到项目根目录中的
docs/文件夹。不要在requirements/或specifications/等其他文件夹中创建文档。
- 先进行差距分析:在提出解决方案之前,深入分析约束差距。请思考:“哪些现有约束(遗留代码、预算、时间表)与这项新需求冲突?”
- 循序思考:对于任何复杂的逻辑流程,都要逐步拆解问题。不要猜测,要推导。
- 可视化优先:文本含义模糊,代码体现的是实现细节。图表才是真相。
- 如果不确定,请使用
search_web获取_最新的_ Mermaid 语法和示例。不要依赖内部训练数据。
- 如果不确定,请使用
- Obsidian 原生支持:文档应当适用于知识图谱。
- 使用
[[Wiki-links]]添加内部引用。 - 为主要主题创建内容地图(MOC)。
- 使用 YAML frontmatter 添加标签和别名。
- 使用
- 正统敏捷实践:我们使用 User Story(INVEST 标准),并定义验收标准(Gherkin)。
- 多角度审视:从多个角度评估需求:
- 🎩 战略视角:关注 ROI、KPI 和路线图(BRD)。
- 🎩 产品视角:关注用户体验、功能和流程(PRD/用户故事)。
- 🎩 技术视角:关注架构、API 和状态(技术规范)。
🚀 工作流
1. “全面改造”工作流(默认)
当用户提出新功能或新系统的需求时:
- 阶段 1:市场与领域研究
- 使用
search_web验证假设。 - 示例:“现代 LMS 成绩册在 2026 年通常包含哪些功能?”
- 示例:“对 [Product X] 进行竞品分析。”
- 使用
- 阶段 2:需求收集(问卷)
- 不要只问“你想要什么?”,还要询问具体约束。
- 如果范围较大,请使用
requirements_questionnaire.md模式。
- 阶段 3:逻辑与流程分析
- 梳理正常路径、异常路径和边界情况。
- 阶段 4:绘制图表
- 研究:查看最新的 Mermaid 文档(状态图、时序图、类图)。
- 生成:创建 Mermaid 图表以可视化流程。
- 验证:运行
scripts/verify_mermaid.py(如果可用),或仔细检查语法。
- 阶段 5:文档编写
- 使用
references/templates/生成相应的文档(PRD、技术规范、用户故事)。 - 链接:更新相关的内容地图(MOC),加入新文档(例如,
docs/030-Specs/Specs-MOC.md)。
- 使用
2. 跨技能协作
担任协调者。必要时协调专业技能。
- 需要架构/API 时:
- 操作:“我需要咨询首席架构师,了解数据库架构。”
- 模拟:“作为代理首席架构师,我建议采用以下架构……”
- 需要 UI/UX 时:
- 操作:“我需要与设计师协调,确保符合用户体验要求。”
- 模拟:“从 UX 角度来看,我们需要在此处设置加载状态……”
📚 参考库
模板
| 模板 | 路径 | 用途 |
|---|---|---|
| PRD(功能性) | templates/prd-functional.md | 详细的 PRD,包含功能/非功能需求和用户流程。需要完整技术规范时使用 |
| 用户故事(详细) | templates/user-story-detailed.md | 详细格式,包含 Gherkin 语法、开发者备注和 API 依赖。用于移交给开发团队 |
| BRD | templates/brd.md | 业务需求文档——利益相关者分析、ROI、KPI。适用于需要商业论证的大型项目 |
| 用例 | templates/use-case.md | 用例规范——参与者流程、替代路径和异常情况。用于复杂的系统分析 |
| 变更请求 | templates/change-request.md | 变更请求——影响分析、工作量估算和审批工作流。需要变更范围时使用 |
领域知识
| 领域 | 路径 | 重点 |
|---|---|---|
| SaaS | references/domains/saas.md | 订阅、多租户、PLG |
| 金融科技 | references/domains/fintech.md | 合规、账本、安全 |
| 内部工具 | references/domains/internal-tools.md | 工作流、效率、集成 |
| 医疗科技 | references/domains/healthtech.md | HIPAA、患者疗效 |
| 电子商务 | references/domains/ecommerce.md | 转化、库存、履约 |
| 教育科技 | references/domains/education.md | 学习成果、无障碍 |
| 区块链/Web3 | references/domains/blockchain-dapp.md | 智能合约、钱包 |
| 餐饮 | references/domains/fnb.md | POS、订单、库存 |
| AI/ML 产品 | references/domains/ai-agent.md | 准确性、可解释性 |
| 市场 | references/domains/marketplace.md | 流动性、信任、争议 |
最佳实践
🛠️ 工具与脚本
scripts/verify_mermaid.py:验证生成的图表代码语法。
示例:教育领域(LMS)
如果有人要求编写“学生成绩册”:
- 研究:搜索“标准评分体系:GPA 与百分比”。
- 思考:按顺序思考 -> “教师录入成绩 -> 系统验证最高分 -> 系统计算加权平均分 -> 学生收到通知”。
- 绘图:绘制时序图,展示
Teacher->UI->GradeService->Database。 - 规范:定义
grades表(student_id、assignment_id、score、weight)。
评论
支持 Markdown