@alanwang-merit/meritdata-platform-skill-package 1.0.10 → 1.0.12

package/skills/requirement-low-level-check/references//344/275/216/347/272/247/351/227/256/351/242/230/346/243/200/346/237/245/346/270/205/345/215/225.md

@@ -1,210 +0,0 @@
-# 需求设计低级问题检查清单
-
-本清单覆盖需求文档和设计文档中常见的低级问题，分为 **6 大类 60+ 项**，用于在正式评审前发现明显的低级问题。
-
----
-
-## 一、命名规范问题
-
-### 1.1 术语不一致
-
-- [ ] 同一概念在不同章节使用不同术语（如"用户"和"账号"混用）
-- [ ] 中英文混用且无对应表（如"用户/User"在同一段落出现 3 次以上）
-- [ ] 同一字段在不同表中命名不一致（如 `userName` 和 `user_name`）
-- [ ] 同一接口在不同文档中命名不一致
-
-### 1.2 命名错误
-
-- [ ] 英文单词拼写错误（如 `recieve` → `receive`）
-- [ ] 大小写不一致（如 `GetUser` 和 `getUser`）
-- [ ] 缩写不统一（如 `ID` 和 `Id` 混用）
-- [ ] 使用拼音命名（如 `yonghu` 代替 `user`）
-
-### 1.3 命名不专业
-
-- [ ] 使用 `temp`、`test`、`abc`、`xxx` 等临时命名
-- [ ] 使用 `data1`、`data2`、`info1`、`info2` 等无意义编号
-- [ ] 中文命名或拼音首字母命名（如 `yhxx`）
-
----
-
-## 二、数字/单位问题
-
-### 2.1 数字错误
-
-- [ ] 同一数字在不同章节不一致（如"100 万用户"和"1000 万用户"）
-- [ ] 同一时间数字不一致（如"30 秒"和"3 秒"）
-- [ ] 百分比总和不为 100%
-- [ ] 数量级明显不合理（如"用户数 100 亿"）
-
-### 2.2 单位缺失
-
-- [ ] 数字无单位（如"容量 100"，未说明是 KB/MB/GB）
-- [ ] 时间无单位（如"超时 3"，未说明是秒/分钟/小时）
-- [ ] 金额无单位（如"价格 100"，未说明是元/美元）
-
-### 2.3 单位不一致
-
-- [ ] 同一概念在不同章节使用不同单位（如 KB 和 MiB）
-- [ ] 时间单位混用（如"30 秒"和"0.5 分钟"虽然相等，但风格不一致）
-
-### 2.4 范围错误
-
-- [ ] 边界值不明确（如"长度 1-20"，未说明是字符还是字节）
-- [ ] 边界值不合理（如年龄范围 -1 到 200）
-- [ ] 数量范围冲突（如列表显示 20 条，但接口返回 50 条）
-
----
-
-## 三、状态/枚举问题
-
-### 3.1 枚举不完整
-
-- [ ] 状态机缺少必要状态（如订单状态缺少"已取消"）
-- [ ] 状态转换缺少必要路径（如"待支付"无法直接到"已完成"）
-- [ ] 枚举值遗漏常见值（如性别只有"男/女"，缺少"未知"）
-
-### 3.2 枚举值错误
-
-- [ ] 同一枚举在不同章节使用不同值（如状态名"启用"和"激活"）
-- [ ] 枚举值含义不明确（如状态"P"，未说明代表什么）
-- [ ] 枚举值含义冲突（如"启用"和"激活"指同一状态）
-
-### 3.3 枚举命名
-
-- [ ] 枚举值使用数字编码（如 `1`、`2`、`3`，无对应说明）
-- [ ] 枚举值命名风格不统一（如 `ENABLED`、`enabled`、`Enabled` 混用）
-
----
-
-## 四、流程/逻辑问题
-
-### 4.1 流程断裂
-
-- [ ] 主流程图缺少开始/结束节点
-- [ ] 主流程缺少关键分支（如异常分支、超时分支）
-- [ ] 流程步骤顺序颠倒（如先返回结果再处理数据）
-- [ ] 流程图与文字描述不一致
-
-### 4.2 逻辑矛盾
-
-- [ ] 前置条件与流程描述矛盾（如前置条件说"用户未登录"，但流程中又"校验用户信息"）
-- [ ] 输入输出与处理逻辑矛盾（如输入有 3 个字段，输出只有 2 个字段）
-- [ ] 异常处理与正常流程矛盾（如正常流程不报错，异常处理又说"网络异常时重试"）
-
-### 4.3 边界遗漏
-
-- [ ] 缺少空值/空集合处理说明（如搜索结果为空时怎么办）
-- [ ] 缺少并发场景说明（如两个用户同时操作同一数据）
-- [ ] 缺少超时处理说明
-- [ ] 缺少重复提交/重复点击处理说明
-- [ ] 缺少权限不足场景说明
-
----
-
-## 五、文档规范问题
-
-### 5.1 版本问题
-
-- [ ] 版本号格式不统一（如同时出现 `V1.0`、`1.0`、`v1.0.0`）
-- [ ] 版本号倒退或重复
-- [ ] 版本更新记录与文档内容不一致
-- [ ] 缺版本更新记录
-
-### 5.2 结构问题
-
-- [ ] 章节编号不连续（如 1.1 后直接到 1.3）
-- [ ] 章节层级混乱（如 H2 后直接 H4）
-- [ ] 章节顺序不合理（如先讲非功能性需求，再讲功能需求）
-- [ ] 引用章节号错误（如"详见 3.2"，实际是 3.3）
-
-### 5.3 格式问题
-
-- [ ] 中英文标点混用（如同时使用 `，` 和 `,`）
-- [ ] 中英文数字混用（如"1个"和"一个"在同一段落）
-- [ ] 全角/半角符号混用（如 `（）` 和 `()`）
-- [ ] 列表编号格式不统一
-
-### 5.4 表述问题
-
-- [ ] 出现绝对化词汇（"完美"、"零缺陷"、"完全覆盖"、"100%"、"肯定"）
-- [ ] 出现模糊表述（"可能"、"或许"、"基本上"、"大概"）
-- [ ] 长句超过 50 字未拆句
-- [ ] 一段话超过 200 字未分段
-- [ ] 拼写/语法错误
-
-### 5.5 图表问题
-
-- [ ] 流程图缺少图例说明
-- [ ] 流程图与文字描述不一致
-- [ ] 表格表头说明不清
-- [ ] 表格数据明显错误（如行列数不一致）
-- [ ] 图片/图表无标题或标题错误
-
----
-
-## 六、安全/合规问题
-
-### 6.1 敏感信息
-
-- [ ] 明文出现密码、token、密钥等敏感信息
-- [ ] 示例数据使用真实个人信息（如真实手机号、身份证号）
-- [ ] 错误信息泄露内部实现细节（如 SQL 语句、堆栈信息）
-- [ ] 日志中打印敏感字段
-
-### 6.2 权限问题
-
-- [ ] 接口缺少权限校验说明
-- [ ] 数据缺少访问控制说明
-- [ ] 缺少越权场景说明（水平越权/垂直越权）
-
-### 6.3 审计合规
-
-- [ ] 缺少操作日志说明
-- [ ] 缺少数据保留期限说明
-- [ ] 缺少个人信息保护说明
-- [ ] 缺少合规要求说明（如等保、GDPR）
-
-### 6.4 SQL/数据安全
-
-- [ ] 缺少 SQL 注入防护说明
-- [ ] 缺少 XSS 防护说明
-- [ ] 缺少敏感数据加密说明（存储加密/传输加密）
-- [ ] 缺少数据备份与恢复说明
-
----
-
-## 附：常见低级错误 Top 20
-
-| # | 错误类型 | 示例 |
-|---|---------|------|
-| 1 | 中英文标点混用 | "接口，返回：success" |
-| 2 | 数字无单位 | "超时 3" |
-| 3 | 时间单位歧义 | "响应时间 < 3" |
-| 4 | 同一概念命名不一致 | "用户/账号/客户"混用 |
-| 5 | 英文单词拼写错误 | "recieve" |
-| 6 | 缺少异常分支 | 主流程只描述正常情况 |
-| 7 | 边界值缺失 | "长度 1-20"没说字符还是字节 |
-| 8 | 章节编号不连续 | 1.1 直接到 1.3 |
-| 9 | 状态枚举不全 | 订单状态缺"已取消" |
-| 10 | 流程图与文字不一致 | 流程图先 A 后 B，文字先 B 后 A |
-| 11 | 前置条件自相矛盾 | 前置说未登录，流程又校验用户 |
-| 12 | 出现绝对化词汇 | "完全覆盖所有场景" |
-| 13 | 出现模糊表述 | "可能会失败" |
-| 14 | 缺少版本更新记录 | 文档无版本记录章节 |
-| 15 | 缺少空值处理 | "查询结果为空时"未说明 |
-| 16 | 缺少并发说明 | 两个用户同时操作未说明 |
-| 17 | 缺少超时说明 | 接口超时未说明 |
-| 18 | 明文出现敏感信息 | 示例密码 123456 |
-| 19 | 错误信息泄露内部 | 错误信息含 SQL 语句 |
-| 20 | 缺少权限说明 | 接口未说明权限校验 |
-
----
-
-## 使用说明
-
-本清单应作为**正式评审前的快速预检工具**，由评审人员按清单逐项检查，10-15 分钟内完成。
-
-- 适用于：需求文档、设计文档评审
-- 不适用于：架构决策、代码细节
-- 检查时机：正式评审前 1 天，发送检查结果给作者预修改

package/skills/requirement-pm-review/SKILL.md

@@ -1,181 +0,0 @@
----
-name: requirement-pm-review
-description: 需求评审（产品经理视角）| 触发条件：PM视角评审、产品经理评审、专业需求评审、多维度需求评审 | 以专业产品经理视角对需求文档进行多维度评审，无固定检查单，关注商业价值、用户场景、产品逻辑、可行性等PM核心关注点
-author: maohan
-source: project
-date_added: "2026-07-08"
-risk: low
----
-
-# 需求评审（产品经理视角）
-
-本技能以**专业产品经理视角**对需求文档进行**发散性、多维度评审**，与基于检查单的 `requirement-review` 互补：
-- **requirement-review**：基于检查单逐项打分的**形式审查**
-- **requirement-pm-review**：基于PM专业能力的**发散性实质审查**
-
-> ⚠️ **重要**：本技能强调**发散性思考**，不局限于下方列出的 9 大维度。
-> 评审时应充分发挥产品经理的专业能力，**根据具体需求文档的实际情况，自主识别值得评审的维度**，从不同角度、不同层次审视需求的质量和可行性。
-
----
-
-## 使用方法
-
-1. 加载评审报告模板 `references/PM评审报告模板.md`
-2. 以专业产品经理身份多维度审视需求文档
-3. 输出评审报告
-
----
-
-## PM 多维度评审框架（参考维度，非限制）
-
-> ⚠️ **以下 9 大维度仅作为参考框架，不是评审的全部**。PM 评审应充分发挥专业能力，**根据需求文档的实际情况，自主识别值得评审的维度**，进行发散性思考。
-
-### 1. 商业价值
-
-- 解决的是真问题还是伪需求？
-- ROI 是否合理（投入 vs 预期收益）？
-- 目标用户是否清晰、规模是否合理？
-- 商业变现路径是否清晰？
-- 与公司战略目标是否一致？
-
-### 2. 用户场景
-
-- 目标用户画像是否清晰？
-- 核心使用场景是否完整覆盖？
-- 用户痛点描述是否真实、可验证？
-- 用户旅程是否合理、流畅？
-- 是否考虑了不同用户角色的差异？
-
-### 3. 产品逻辑
-
-- 业务逻辑是否自洽、无矛盾？
-- 边界场景是否考虑周全？
-- 异常流程是否合理？
-- 状态机是否完整（无缺失状态、循环依赖）？
-- 核心数据流是否清晰？
-
-### 4. 功能设计
-
-- 功能是否最小可行（MVP）？
-- 是否有功能过度设计？
-- 是否有功能缺失（漏掉关键能力）？
-- 功能优先级是否合理？
-- 功能间耦合度是否合理？
-
-### 5. 体验设计
-
-- 交互流程是否简洁？
-- 是否有明显的体验痛点？
-- 是否有不必要的复杂操作？
-- 错误提示和引导是否友好？
-- 是否考虑了无障碍/可访问性？
-
-### 6. 数据与指标
-
-- 关键指标（北极星指标）是否定义？
-- 数据埋点是否考虑？
-- 转化漏斗是否清晰？
-- A/B 测试方案是否需要？
-- 成功度量标准是否可量化？
-
-### 7. 可行性
-
-- 技术实现是否可行？
-- 时间排期是否合理（是否过于激进）？
-- 资源投入是否足够？
-- 依赖方是否明确、是否可控？
-- 风险点是否识别全面？
-
-### 8. 风险与依赖
-
-- 业务风险有哪些？（如合规、政策、用户体验）
-- 技术风险有哪些？（如性能、稳定性、安全）
-- 外部依赖有哪些？（如第三方系统、合作方）
-- 风险应对方案是否合理？
-- 回滚方案是否考虑？
-
-### 9. 长期演进
-
-- 此次需求是否考虑了未来扩展？
-- 是否会形成技术债务？
-- 与产品整体规划是否一致？
-- 是否有清晰的迭代路径？
-- 是否有可衡量的"下一步"计划？
-
-### 其他可能的评审维度（PM 自主判断）
-
-除了上述 9 大维度外，PM 还可从以下角度发散评审（仅举例）：
-
-- **竞品分析**：竞品是如何做的？我们的差异化在哪？
-- **用户增长**：是否有助于拉新、留存、转化？
-- **品牌调性**：是否符合品牌定位？
-- **运营策略**：上线后如何推广和运营？
-- **成本结构**：研发成本、运营成本、用户成本？
-- **法律合规**：是否涉及隐私、知识产权、行业监管？
-- **团队能力**：现有团队是否有能力承接？
-- **时机判断**：现在做是否合适？市场窗口期？
-- **替代方案**：是否有更优的解决方案？
-- **跨部门影响**：对其他团队/业务线有什么影响？
-
----
-
-## 评审原则
-
-### PM 视角的 4 个核心立场
-
-1. **用户代言人** - 始终站在用户角度思考
-2. **商业代言人** - 始终关注商业价值和 ROI
-3. **产品守护者** - 守住产品调性和设计原则
-4. **协作促进者** - 平衡多方诉求，推动达成共识
-
-### PM 评审的 5 个关键问题
-
-1. **Why** - 为什么要做？（商业价值）
-2. **For Whom** - 为谁做？（目标用户）
-3. **What** - 做什么？（核心功能）
-4. **How** - 怎么做？（实现方案）
-5. **So What** - 做完会怎样？（效果度量）
-
----
-
-## 与 requirement-review 的区别
-
-| 维度 | requirement-review | requirement-pm-review |
-|------|---------------------|------------------------|
-| 评审方式 | 基于检查单逐项打分 | 多维度深度分析 |
-| 评审角度 | 形式审查（结构、完整性） | 实质审查（价值、逻辑、可行性） |
-| 输出形式 | 详细打分表 | 重点问题+改进建议 |
-| 适用场景 | 标准化流程、形式合规 | 专业把关、决策参考 |
-| 评审角色 | 任意评审员 | 产品经理视角 |
-
----
-
-## 适用场景
-
-- 需求评审会的**专业把关**
-- 重大需求上线前的**专业审视**
-- 多方协作时**PM 视角补位**
-- 需求方案决策的**参考输入**
-
-## 不适用场景
-
-- 日常快速预检（使用 `requirement-low-level-check`）
-- 形式合规审查（使用 `requirement-review`）
-- 详细技术评审（使用 `design-review`）
-
----
-
-## 输出格式
-
-根据模板 `references/PM评审报告模板.md` 生成评审报告，输出后保存到 `docs/PM需求评审报告-项目名-日期.md`
-
----
-
-## 触发场景
-
-- "PM视角评审"
-- "产品经理评审"
-- "专业需求评审"
-- "多维度需求评审"
-- "PM审视需求"
-- "产品视角评估"

package/skills/requirement-pm-review/references/PM/350/257/204/345/256/241/346/212/245/345/221/212/346/250/241/346/235/277.md

@@ -1,223 +0,0 @@
-# PM 视角需求评审报告 — [项目名] V1.0
-
-**评审对象**：[需求文档名称] V1.0
-**评审日期**：YYYY-MM-DD
-**评审视角**：产品经理
-**评审依据**：[业务背景资料]
-
----
-
-## 一、总体判定
-
-**[通过 / 有保留通过 / 不通过]**
-
-**核心结论**：
-- 优点：xxx
-- 风险：xxx
-- 建议：xxx
-
----
-
-## 二、9 大维度评估
-
-### 1. 商业价值
-
-**判定**：[强/中/弱]
-
-**评估要点**：
-- 解决的是真问题还是伪需求？
-- ROI 是否合理？
-- 目标用户规模和变现路径是否清晰？
-
-**关键发现**：
-- 优点：xxx
-- 风险：xxx
-- 建议：xxx
-
-### 2. 用户场景
-
-**判定**：[清晰/部分清晰/不清晰]
-
-**评估要点**：
-- 目标用户画像是否清晰？
-- 核心场景是否完整覆盖？
-- 用户痛点是否真实可验证？
-
-**关键发现**：
-- 优点：xxx
-- 风险：xxx
-- 建议：xxx
-
-### 3. 产品逻辑
-
-**判定**：[严谨/部分严谨/不严谨]
-
-**评估要点**：
-- 业务逻辑是否自洽？
-- 边界场景是否考虑周全？
-- 状态机是否完整？
-
-**关键发现**：
-- 优点：xxx
-- 风险：xxx
-- 建议：xxx
-
-### 4. 功能设计
-
-**判定**：[合理/部分合理/过度/缺失]
-
-**评估要点**：
-- 功能是否最小可行（MVP）？
-- 是否有功能过度设计或缺失？
-- 优先级是否合理？
-
-**关键发现**：
-- 优点：xxx
-- 风险：xxx
-- 建议：xxx
-
-### 5. 体验设计
-
-**判定**：[优秀/良好/一般/差]
-
-**评估要点**：
-- 交互流程是否简洁？
-- 错误提示和引导是否友好？
-- 是否有明显的体验痛点？
-
-**关键发现**：
-- 优点：xxx
-- 风险：xxx
-- 建议：xxx
-
-### 6. 数据与指标
-
-**判定**：[完善/部分完善/缺失]
-
-**评估要点**：
-- 关键指标是否定义？
-- 数据埋点是否考虑？
-- 成功度量标准是否可量化？
-
-**关键发现**：
-- 优点：xxx
-- 风险：xxx
-- 建议：xxx
-
-### 7. 可行性
-
-**判定**：[可行/部分可行/风险高]
-
-**评估要点**：
-- 技术实现是否可行？
-- 时间排期是否合理？
-- 资源投入是否足够？
-
-**关键发现**：
-- 优点：xxx
-- 风险：xxx
-- 建议：xxx
-
-### 8. 风险与依赖
-
-**判定**：[可控/部分可控/风险高]
-
-**评估要点**：
-- 业务/技术/外部风险是否识别？
-- 风险应对方案是否合理？
-- 回滚方案是否考虑？
-
-**关键发现**：
-- 优点：xxx
-- 风险：xxx
-- 建议：xxx
-
-### 9. 长期演进
-
-**判定**：[清晰/部分清晰/不清晰]
-
-**评估要点**：
-- 是否考虑了未来扩展？
-- 是否会形成技术债务？
-- 是否有清晰的迭代路径？
-
-**关键发现**：
-- 优点：xxx
-- 风险：xxx
-- 建议：xxx
-
----
-
-## 三、关键问题清单（按重要性排序）
-
-| # | 重要性 | 维度 | 问题 | 建议 |
-|---|--------|------|------|------|
-| 1 | 高/中/低 | 商业/用户/逻辑/功能/体验/数据/可行/风险/演进 | xxx | xxx |
-| 2 | xxx | xxx | xxx | xxx |
-| 3 | xxx | xxx | xxx | xxx |
-
----
-
-## 四、亮点
-
-需求文档做得好的一面（PM视角）：
-- **商业洞察**：xxx
-- **用户理解**：xxx
-- **产品思维**：xxx
-- **落地能力**：xxx
-
----
-
-## 五、改进建议
-
-### 5.1 必须修改（阻塞）
-
-1. xxx
-2. xxx
-
-### 5.2 建议修改（非阻塞）
-
-1. xxx
-2. xxx
-
-### 5.3 优化建议
-
-1. xxx
-2. xxx
-
----
-
-## 六、5 个关键问题的回答
-
-1. **Why（为什么要做）**：
-   - 答：xxx
-
-2. **For Whom（为谁做）**：
-   - 答：xxx
-
-3. **What（做什么）**：
-   - 答：xxx
-
-4. **How（怎么做）**：
-   - 答：xxx
-
-5. **So What（做完会怎样）**：
-   - 答：xxx
-
----
-
-## 七、最终结论
-
-**通过条件**：
-- 关键问题清单中的"高"重要性全部修复
-- "中"重要性至少 80% 修复
-
-**下一步行动**：
-1. xxx
-2. xxx
-3. xxx
-
----
-
-**评审人**（PM视角）：xxx
-**评审日期**：YYYY-MM-DD