| name | generate-business-docs-from-code |
| description | 从代码或笔记中生成稳定的中文业务文档。适用于用户要求输出业务背景/核心功能模块/关键业务规则/快速记忆卡片/常见问题，或要求“小白都能看懂/不要代码/不要技术细节/不要涉及任何代码”。适配任意页面与任意领域，重点把页面展示、用户操作流程、业务规则翻译成业务语言。 |
Generate Business Documentation from Code
Purpose
把技术实现/接口/页面行为，转换成任何“小白”都能看懂的中文业务文档，用于：
When to Use
Apply this skill when:
- User asks to "理解这块业务" / "分析一下业务"
- Preparing for interviews about a project
- Creating documentation for non-technical audiences
- Documenting business logic for knowledge sharing
Hard Requirements（必须遵守）
1) 只写中文、只讲业务
- 输出必须是中文。
- 禁止输出任何代码/伪代码/接口参数结构/函数名/类名/文件路径/技术栈名词堆砌。
- 可以提到“前端展示/后端存储/保存/校验/定时任务”这种业务能理解的表达，但不要写实现细节。
2) 面向小白：一句话 + 痛点 + 解决方案
- 每个模块先用一句话解释“它解决什么问题”。
- 解释“为什么要做”（痛点），再解释“怎么解决”（策略/配置/规则）。
3) 固定结构输出（稳定）
- 必须按下面模板输出，章节不缺失，除非用户明确说不需要某章。
- 每章尽量使用短句 + 列表 + 表格（业务表格即可）。
4) 错误与边界只用业务语言描述
- 例如“项目不存在/重复/超过数量/格式不合法/不支持某数据类型”等，用提示语描述，不要写错误码、异常栈。
How to Extract Business Facts（从代码/页面提取信息的方法）
当允许阅读代码时，重点关注并提炼为业务语言：
- 页面上有哪些表单项/开关/下拉选择/按钮（对应业务配置）
- 用户操作路径（点击顺序、保存、失败提示）
- 校验规则（为什么要校验、校验失败会怎样）
- 关键枚举/状态（用中文讲清楚含义）
- “为什么这样设计”（例如策略衰减、占比限购、特殊模式）
Output Template（必须使用）
输出用 markdown，但不要包含任何代码块（```）。
一、业务背景
一句话概括：用一句话说明“这是一个什么后台/工具，用来解决什么行业问题”。
业务痛点（按需选择，列 3-6 条）：
- 黄牛抢票
- 代拍业务
- 异常订单
- 地域失衡
- 其他：结合你从页面/配置项推断的痛点
解决方案（讲清“可配置”与“组合策略”）：
- 说明有多少类策略（例如 20+ 种）以及“每个项目可独立启用”的特点
- 说明运营人员的工作方式：按项目特点组合配置
二、核心功能模块
用“模块一/模块二/模块三 ……”组织，每个模块都要包含：
表格格式（示例）：
| 配置项 | 做什么 | 适用场景/备注 |
|---|
| 风控禁购 | 高风险用户直接禁止购买 | 热门项目必开 |
三、关键业务规则
至少覆盖：
- 什么是策略衰减？为什么要做？（用业务语言解释）
- 特殊模式差异（如 Uutix）：它是什么、对配置有什么影响
- 校验规则的业务意义：为什么要这些校验，防止什么风险
- 百分比显示/存储差异（如有）：用“展示更直观/存储更精确”解释，不写计算细节
四、快速记忆卡片
用“概念 → 一句话”格式，列 6-12 条：
- 风控禁购：……
- 策略衰减：……
- 黑名单：……
- 收货限购：……
- 占比限购：……
- 单场次限购：……
- 退款禁购：……
五、常见问题
至少给出 3-8 个 QA：
- Q：讲讲某模块的业务定位？
- Q：有哪些关键业务规则？
- Q：为什么要做某个限制/校验？
Style Checklist（输出前自检）
