@zhanlucode/zl-darwin-arm64 1.5.87028

package/bin/zhanlu-plugins/lingji-beta-assistant/skills/beta-requirement-decomposer/SKILL.md

@@ -0,0 +1,348 @@
+---
+name: beta_requirement_decomposer
+description: |
+  beta 环境需求拆解技能，将 beta 环境（演示/测试环境）中的初始需求（RR）按层级拆解为可执行的 Story → Task 结构，并支持将拆解结果创建到 lingji-beta 平台。支持双模式数据源：MCP 拉取或本地文档读取。当用户提到"拆解需求""需求拆解""拆成Story""拆成Task""拆分需求""生成Story文档""拆成用户故事""beta环境拆解""演示项目拆解"等场景时触发。与 `requirement-decomposer` 的差异：固定使用 lingji-beta MCP、双模式数据源（MCP/本地）、输出到 prd/decompose/ 目录、文件名带 Beta_ 前缀、字段基于实际 beta 数据结构调整（description 三小节作为核心拆解源）、支持回写 lingji-beta 平台创建 Story/Task。
+---
+
+# beta 环境需求拆解
+
+> 将 beta 环境中的初始需求（RR）按层级拆解为可执行的 Story → Task 结构。支持双模式：
+> 1. **MCP 拉取模式**：从 lingji-beta 拉取 RR 的 description 三小节作为拆解源
+> 2. **本地文档模式**：读取用户提供的 prd/requirements_Beta_*.md 类需求文档
+>
+> 拆解结果默认写入 `prd/decompose/` 目录，命名 `Beta_{项目}_{Key}_{拆解}_{YYYYMMDD}.md`；可选调用 lingji-beta MCP 将 Story/Task 实际创建到平台。
+
+## 核心原则：拒绝过度拆解
+
+需求拆解之前，必须理解以下原则，这决定了输出质量：
+
+**一个 Story = 一个独立可交付的用户价值。一个 Task = 一个可独立完成的具体开发动作。**
+
+- 不要为了"覆盖每个验收标准"而把同一个用户价值拆成多个 Story
+- 不要把共享的前置条件（如"登录+选择助手"）单独拆成一个 Story，而是让每个 Story 都包含自己的前提条件
+- 不要把"设计"单独拆成一个 Task，设计工作应融入实现任务中
+- 一个 Epic 拆 2-4 个 Story 为宜（不是越多越好）
+- 一个 Story 拆 2-4 个 Task 为宜（不是越多越好）
+
+**beta 环境特殊约束：**
+- `description` 字段包含【需求背景】/【需求价值】/【需求详情】三段，**【需求详情】是核心拆解源**（对应原 skill 的"需求描述"），【需求价值】用于推导验收标准
+- beta 环境无独立 `acceptanceCriteria` 字段，验收标准**必须从【需求详情】推导**
+- 平台上的类型映射：`RR` → 初始需求（Epic），`US` → 用户故事（Story），`Task` → 任务
+
+## 工作流程
+
+### 步骤 1：识别数据源模式
+
+判断本次拆解的数据源：
+
+| 用户说法                                  | 触发模式             |
+| ----------------------------------------- | -------------------- |
+| "拆解 RR20260119400340" / "拆解演示项目下我的需求" | **MCP 拉取模式**     |
+| "拆解 D:/path/to/需求文档.md" / 提供具体文件路径    | **本地文档模式**     |
+| 仅说"拆解需求"，无明确数据源              | **询问用户**         |
+
+#### 模式 A：MCP 拉取模式
+
+调用 lingji-beta MCP 工具链：
+
+1. `lingji-beta__getProjectList` — 解析项目名 → projectId
+2. `lingji-beta__listWorkItems` — `issueType=RR` 拉取初始需求列表
+3. `lingji-beta__getWorkItemDetail` — **对每条候选 RR 调用一次获取 description**（含【需求背景】/【需求价值】/【需求详情】三段）
+
+**筛选条件：**
+- 项目：精确/模糊匹配 `domain_id.name` 或 `project.title`
+- 状态：默认 `Analyse`（分析），可指定 `Plan`（规划）
+- assignee：当前用户邮箱（客户端过滤）
+
+> ⚠️ description 字段仅 `getWorkItemDetail` 接口返回。必须对每条候选 RR 调用一次以获取【需求详情】用于拆解。
+
+#### 模式 B：本地文档模式
+
+读取用户提供的 Markdown 文档路径，识别需求列表表格（每行包含 `需求Key` / `类型` / `需求描述` 等字段）。
+
+**预期文档格式：** 与 `beta-requirements-gather` skill 输出的 `需求列表_Beta_*.md` 结构一致；或与 `beta-requirement-analysis` skill 输出的 `Beta_{Key}_{标题}.md` 结构一致。
+
+**核心拆解字段：**
+- 模式 A：从 `description` 解析【需求详情】段
+- 模式 B：从表格的 `需求描述` 字段读取（无 `验收标准` 字段时，从 `需求描述` 推导）
+
+### 步骤 2：完善需求内容
+
+检查每个 RR 的核心字段——**【需求详情】** 和 **【需求价值】** ——是否足够清晰、可操作。如果字段本身已经描述良好，直接跳到步骤 3。
+
+当字段模糊或不完整（如三段均为占位符文本），检查是否存在 `beta-requirement-analysis` skill。如果存在，询问用户是否使用该 skill。
+
+- **如果用户同意使用**：先执行 `beta-requirement-analysis` skill（**从该 skill 的流程第 4 步开始**），基于扩写后的三段内容重新执行步骤 2 验证
+- **如果用户选择不使用**：直接在拆解文档中标注"⚠️ 来源 RR 的【需求详情】内容不足，拆解结果为推测性占位"，但仍按现有内容继续拆解
+
+### 步骤 3：执行拆解（三选一）
+
+> 以下模式 A、B、C **三选一**，根据输入 RR 的层级（RR = Epic）和用户要求确定具体模式。
+
+#### 模式 A：RR（Epic）→ US（Story）
+
+- **方法参考**：`epic-to-story-methodology.md`（与原 skill 一致，核心原则通用）
+- **核心拆解源**：从 RR 的 `description` 解析【需求详情】段
+- **验收标准推导**：从【需求详情】的每个功能点提取"操作场景 + 预期结果"格式
+- **模板参考**：`epic-to-story-template.md`（按 beta 字段结构适配，见本文件末尾）
+
+#### 模式 B：US（Story）→ Task
+
+- **方法参考**：`story-to-task-methodology.md`
+- **核心拆解源**：从 US 的 `description` 解析【需求详情】段
+- **模板参考**：`story-to-task-template.md`
+
+#### 模式 C：RR（Epic）→ US（Story）→ Task（全链路）
+
+- **方法参考**：`epic-to-story-methodology.md` + `story-to-task-methodology.md`
+- **模板参考**：`epic-to-story-to-task-template.md`
+- **注意**：分两步执行，先将 RR 拆解为 Story，再将 Story 拆解为 Task，两步不可并行
+
+#### 模式 D：US（Story）→ 优化现有 Task
+
+当用户已有 Story 但 Task 拆分不合理时，调用 `lingji-beta__queryWorkItemTree` 获取 Story 下的现有 Task 列表，合并去重后再优化拆分。
+
+### 步骤 4：生成拆解文档
+
+按照模板生成 Markdown 文档，**必须使用 `write` 工具将文档写入文件**。如果目录不存在，需先创建。
+
+**输出路径：** 当前项目 `prd/decompose/` 目录
+
+**文件名格式：** `Beta_{项目名}_{父需求Key}_{拆解}_{YYYYMMDD}.md`
+
+示例：
+- `Beta_演示项目_RR20260616628399_拆解_20260618.md`
+- `Beta_演示项目_US20260119400341_拆解_20260618.md`
+
+**文档结构：**
+
+```markdown
+# beta 环境需求拆解文档
+
+## beta 环境元信息
+
+| 字段 | 值 |
+|---|---|
+| 环境标识 | beta |
+| 数据源模式 | MCP 拉取 / 本地文档 |
+| 拆解人 | 任博婕妤 (renbojieyu@cmss.cmcc) |
+| 拆解日期 | 2026-06-18 |
+| MCP 来源 | lingji-beta |
+| 父需求 | RR20260616628399 |
+| 拆解层级 | RR→US / US→Task / RR→US→Task |
+
+## 项目信息
+
+- **空间名称**: 演示项目
+- **项目编码**: e13a682906ef49518812e2b95318d87b
+- **项目名称**: 演示项目
+- **产品名称**: 演示项目
+
+## 父需求摘要
+
+| 字段 | 值 |
+|------|-----|
+| 需求Key | RR20260616628399 |
+| 标题 | 需求代码一致性分析 |
+| 类型 | RR-初始需求 |
+| 负责人 | 任博婕妤 (renbojieyu@cmss.cmcc) |
+| 提出人 | 程龙 (chenglong2@cmss.cmcc) |
+| 优先级 | 高 |
+| 业务背景 | [从 description 提取【需求背景】] |
+| 需求价值 | [从 description 提取【需求价值】] |
+| 需求详情 | [从 description 提取【需求详情】，核心拆解源] |
+
+---
+
+## 拆解结果
+
+### Story 1.1: {Story名称}
+
+| 字段 | 值 |
+|------|-----|
+| 需求Key | {RR-Key}-S1 |
+| 标题 | {Story标题} |
+| 类型 | US-用户故事 |
+| 负责人 | [继承自父需求] |
+| 提出人 | [继承自父需求] |
+| 优先级 | [继承自父需求] |
+| 业务背景 | [继承自父需求] |
+| 需求价值 | [继承自父需求] |
+| 需求详情 | [拆解后的需求详情] |
+| 验收标准 | [从需求详情推导的可验证条目] |
+| 故事点 | [1/2/3/5/8/13] |
+| 计划开始时间 | [继承自父需求] |
+| 计划结束时间 | [继承自父需求] |
+| 期望完成时间 | [继承自父需求，若无则填"未提供"] |
+| 关联项目 | 演示项目 |
+| 关联迭代 | [继承自父需求，若无则填"未提供"] |
+| 父需求 | {RR-Key} |
+| 状态 | 初始 |
+```
+
+### 步骤 5：询问是否回写 lingji-beta 平台
+
+使用 `question` 工具询问用户是否将拆解结果回写到 lingji-beta 平台创建为实际 Story/Task 记录：
+
+```
+是否将拆解结果回写到 lingji-beta 平台？
+回写操作将使用 createWorkItem 接口按层级关系创建 Story/Task 记录，
+并自动关联父需求、子需求关系。
+```
+
+选项：
+- 确认回写（创建 Story/Task 记录）
+- 仅生成拆解文档（不回写）
+
+如果用户选择"仅生成拆解文档"，流程结束。
+
+### 步骤 6：执行回写（创建 Story/Task 记录）
+
+调用 lingji-beta MCP 的 `createWorkItem` 接口（批量创建）。
+
+**回写策略：**
+
+| 场景          | 操作                                                                       |
+| ------------- | -------------------------------------------------------------------------- |
+| RR → US       | 批量创建 N 个 Story，`category=US`，`parent_id=父RR的id`，`us2rr=父RR的id` |
+| US → Task     | 批量创建 N 个 Task，`category=Task`，`parent_id=父US的id`                  |
+| RR → US → Task | 先创建 Story，再创建 Task（两步不可并行）                                   |
+
+**调用参数（每条 createWorkItem）：**
+- `projectId`: 项目 ID
+- `domain_id`: 项目 domain_id
+- `number`: 自动生成，格式 `{父需求Key}-S{序号}` 或 `{父需求Key}-T{序号}`
+- `title`: Story/Task 标题
+- `type`: `requirement`（US）或 `task`（Task）
+- `parent_id`: 父需求 ID
+- `assignee.user_id`: 继承自父需求
+- `description`: HTML 格式的三小节（【需求背景】/【需求价值】/【需求详情】，未拆解的字段直接复用父需求）
+- `priority`: 继承自父需求
+- `workload_man_day`: 估算工时（Story 默认 2.0，Task 默认 1.0）
+- `convolution_plan_hours`: 估算工时（与 workload_man_day 换算）
+- `plan_iteration`: 继承自父需求
+- `status`: `Start`（初始）
+
+**回传 description 拼装规则：**
+
+回传内容 = AI 拆解后的 `【需求背景】`（继承父需求） + AI 拆解后的 `【需求价值】`（继承父需求） + AI 拆解后的 `【需求详情】`（核心拆解），按以下 HTML 格式拼装：
+
+```html
+<p><strong>【需求背景】</strong></p>
+<p>{背景内容}</p>
+
+<p><strong>【需求价值】</strong></p>
+<p>{价值内容}</p>
+
+<p><strong>【需求详情】</strong></p>
+<p>{作为{角色}，我想要{能力}，以便于{价值}。}</p>
+<p>1. {验收标准 1}</p>
+<p>2. {验收标准 2}</p>
+...
+```
+
+#### 6.1 展示回写结果
+
+所有 Story/Task 创建完成后，展示结果：
+
+```
+✅ 拆解结果回写完成
+
+| 类型 | 父需求 | 需求Key | 标题 | 创建结果 |
+|------|--------|---------|------|----------|
+| US | RR20260616628399 | RR20260616628399-S1 | {Story 1 标题} | ✅ 已创建 |
+| US | RR20260616628399 | RR20260616628399-S2 | {Story 2 标题} | ✅ 已创建 |
+```
+
+如果某条 Story/Task 创建失败，标注失败原因并建议用户手动处理。
+
+## 输入
+
+### 模式 A：MCP 拉取模式输入
+
+用户需提供以下任一标识：
+- 需求 Key（如 `RR20260616628399`）
+- 项目名（如"演示项目"）+ assignee 邮箱（默认当前用户）
+- 标题关键词（如"一致性"）
+
+### 模式 B：本地文档模式输入
+
+用户需提供 Markdown 文档的绝对路径，文档需包含：
+- **项目信息**：空间名称、项目编码、项目名称
+- **需求列表**：每个需求以表格形式呈现，含 `需求Key`、`类型`、`需求描述` 字段
+- **类型映射**：`初始需求` → RR（Epic），`用户故事` → US（Story），`任务` → Task
+
+| 表格中 `类型` 字段的值 | 对应层级        | 拆解目标        |
+| ---------------------- | --------------- | --------------- |
+| 初始需求 / RR          | **Epic**        | → US（Story）   |
+| 用户故事 / US          | **Story**       | → Task          |
+| 任务 / Task            | **Task**        | 不再向下拆解    |
+
+**核心拆解字段：**
+- 模式 A：从 `description` 解析的 `【需求详情】` 段（**仅 getWorkItemDetail 返回**）
+- 模式 B：从表格的 `需求描述` 字段（无 `验收标准` 字段时从 `需求描述` 推导）
+
+## 输出
+
+### 本地拆解文档
+
+- 保存路径：`prd/decompose/`
+- 文件名：`Beta_{项目名}_{父需求Key}_{拆解}_{YYYYMMDD}.md`
+- 文档头部包含 beta 环境元信息块
+- 每个 Story/Task 独立表格区块
+
+### 平台记录（可选）
+
+调用 `createWorkItem` 在 lingji-beta 平台创建 Story/Task 记录，包含：
+- 完整字段（继承父需求）
+- description 三小节（HTML 格式）
+- 父子关联（parent_id）
+- 状态为初始（Start）
+
+## 规则
+
+- 仅对 `description` 的 `【需求详情】` 段（或本地文档的 `需求描述` 字段）执行拆解
+- 验收标准**必须从【需求详情】推导**（beta 环境无独立字段）
+- 未提供的字段统一填写"未提供"或"无"
+- 保持原始信息完整，不得删减任何内容
+- 时间字段保持原始格式，不做任何转换
+- 人员姓名后附带邮箱地址的，保留完整信息，不得省略
+- 需求 Key 自动生成，格式为 `{父需求Key}-S{序号}` 或 `{父需求Key}-T{序号}`，序号从 1 开始递增
+- 父需求字段填写原 RR 或 US 的 Key
+- **回写平台时**：必须先验证父需求存在于平台（通过 getWorkItemDetail），避免创建孤儿 Story/Task
+- **占位符检测**：若 RR 的 description 三段均为占位符（如与标题重复、长度<5字等），拆解结果需标注"⚠️ 推测性占位"，并建议先执行 `beta-requirement-analysis` 优化
+
+## 字段映射参考（基于 lingji-beta 实际数据）
+
+| 拆解文档字段           | MCP 数据字段                          | 说明 |
+| ---------------------- | ------------------------------------- | ---- |
+| 需求Key                | `number`（自动生成 `{父Key}-S{序号}`）|      |
+| 标题                   | `title`                               |      |
+| 类型                   | `category` + `type`                   | US: `requirement` / Task: `task` |
+| 状态                   | `status.code`                         | 默认 `Start` |
+| 优先级                 | `priority.display_value`              | 继承父需求 |
+| 负责人                 | `assignee.user_name`                  | 继承父需求 |
+| 提出人                 | `submitted_by[0].user_name`           | 继承父需求 |
+| 业务背景               | `description` 中 `【需求背景】` 段     | 继承父需求 |
+| 需求价值               | `description` 中 `【需求价值】` 段     | 继承父需求 |
+| 需求详情               | `description` 中 `【需求详情】` 段     | **核心拆解源** |
+| 验收标准               | 从 `【需求详情】` 推导                | beta 环境无独立字段 |
+| 故事点                 | `story_point.display_value`           | US 字段，Task 不需要 |
+| 计划工时(人天)         | `workload_man_day`                    | Story 默认 2.0，Task 默认 1.0 |
+| 计划开始时间           | `plan_start_date`                     | 继承父需求 |
+| 计划结束时间           | `plan_end_date`                       | 继承父需求 |
+| 关联项目               | `project.title`                       | 继承父需求 |
+| 关联迭代               | `plan_iteration.title`                | 继承父需求 |
+| 父需求                 | `parent_id` → 反查 `number`           |      |
+
+## 注意事项
+
+- **数据源选择**：拆解前必须确认数据源模式（MCP 拉取 or 本地文档）
+- **description 三小节处理**：必须对每条候选 RR 调用 `getWorkItemDetail` 解析【需求背景】/【需求价值】/【需求详情】；HTML 标签需清理
+- **占位符检测**：若父 RR 的三段内容均为占位符，拆解结果标注"⚠️ 推测性占位"并建议先执行 `beta-requirement-analysis`
+- **回写平台为可选项**：必须经用户确认后才能调用 `createWorkItem`，避免误创建
+- **类型码映射**：`RR` → 初始需求（Epic），`US` → 用户故事（Story），`Task` → 任务
+- **状态码映射**：`Start` → 初始，`Analyse` → 分析，`Plan` → 规划，`Doing` → 实现，`Delivered` → 交付，`Checking` → 验收，`Finish` → 完成
+- **回写后状态**：新建的 Story/Task 默认为 `Start`（初始）状态
+- **父子关系**：Story 的 `parent_id` = 父 RR 的 `id`，`us2rr` = 父 RR 的 `id`；Task 的 `parent_id` = 父 US 的 `id`
+- **方法论文件复用**：核心拆解方法（epic-to-story-methodology.md、story-to-task-methodology.md）与原 skill 共享；模板需按 beta 字段结构适配

package/bin/zhanlu-plugins/lingji-beta-assistant/skills/beta-requirement-decomposer/references/epic-to-story-methodology.md

@@ -0,0 +1,122 @@
+# Epic → Story 拆解方法论
+
+## 目标
+
+将每个 Epic 拆分为可被单个 Agent 在一次开发中完成的 User Story。
+
+关键约束：每个 Story 都是独立可交付的用户价值，Story 之间不应过度拆分。
+
+## 核心原则
+
+### 1. 以"用户操作闭环"为拆分单位，而非以"功能点"或"验收标准"为拆分单位
+
+一个 Story 应该覆盖用户完成一个完整操作的端到端体验。不要拆开"展示"和"操作"——它们属于同一个 Story。
+
+**反面示例（过度拆分）：**
+
+- ~~Story 1: 需求展示~~（只展示，没有操作价值）
+- ~~Story 2: 需求评审~~（只有评审，没有前置展示）
+- 这其实是同一个用户流程的两个步骤，应合并
+
+**正面示例（合理拆分）：**
+
+- Story 1: 需求拉取与自动评审 —— 从展示到评审的完整流程
+- Story 2: 评审结果同步回平台 —— 将评审结果回传到上游
+
+### 2. 不要在 Story 中引入共享前置依赖
+
+每个 Story 都应包含自己的前提条件。不要为了"消除重复"而把"登录并选择助手"拆成一个前置 Story。
+
+**反面示例：**
+
+- ~~Story 0: 建立灵畿a助手连接（没有其他 Story 的前提）~~
+- 这会变成一个无价值的"基础设施" Story
+
+**正面示例：**
+
+- Story 1: "前提：用户登录AI IDE并在Agent模式选择灵畿a助手"——直接在 Story 描述中包含
+- Story 2: 同样包含同样的前提条件——这是重复但正确的
+
+### 3. 以"业务价值流"为主要拆分维度，次要按"技术实现"拆分
+
+优先按用户能感知到的业务价值来分 Story：
+
+- "审核工作流" = 一个 Story（拉取→评审→同步）
+- "优化工作流" = 一个 Story（拉取→优化→同步）
+- "拆解工作流" = 一个 Story（拉取→拆解→同步）
+
+## 拆分步骤
+
+### 步骤 1：提取业务价值流
+
+阅读 Epic 的 `需求描述`，从中提取用户能感知到的独立价值。每个价值流对应一个 Story。
+
+判断标准：
+
+- **独立可验证**：完成后用户能明显感觉到"这个功能可以用"
+- **有明确起点和终点**：从用户触发到结果交付形成闭环
+
+### 步骤 2：为每个 Story 编写完整的用户故事格式
+
+```
+**需求描述：**
+
+作为 {角色}，
+我想要 {能力}，
+以便于 {价值/收益}。
+
+**验收标准：**
+1. {具体可验证的预期结果1}
+2. {具体可验证的预期结果2}
+...
+```
+
+编写要求：
+
+- 需求描述：把 Epic 中分散的多个用户故事场景合并为一个连贯的用户故事
+- 验收标准：从 Epic 的多个用户故事中提取所有可验证点，**完整写入**这个 Story 的验收标准
+- 不要为了"每个验收标准对应一个 Story"而拆分——一个 Story 可以有多个验收标准
+
+### 步骤 3：命名
+
+格式：`{核心功能} + {关键场景}`
+
+好的示例：
+
+- "需求拉取与自动评审"
+- "评审结果交互修改与平台同步"
+- "需求优化与智能建议"
+
+避免的命名：
+
+- ~~"需求展示模块"~~（不完整，不是用户价值）
+- ~~"API对接设计"~~（这是技术任务，不是用户故事）
+- ~~"系统优化"~~（过于模糊）
+
+### 步骤 4：验证
+
+完成拆分后，逐一检查：
+
+- [ ] 每个 Story 是否是独立可交付的用户价值？
+- [ ] Story 之间是否有不必要的拆分？（如果两个 Story 必须一起使用才有意义，考虑合并）
+- [ ] 每个 Story 是否包含自己的前提条件，不依赖其他 Story？
+- [ ] Epic 中的所有功能是否都被覆盖了？
+- [ ] Story 数量是否在 2-4 个？（超过 4 个考虑合并，少于 2 个说明功能本身很简单）
+
+## 数量指导
+
+一个 Epic 建议拆分为 **2-4 个 Story**。
+
+- 少于 2 个：正常，简单 Epic 可能只需要 1 个 Story
+- 2-4 个：理想范围
+- 超过 4 个：检查是否有相邻 Story 可以合并
+
+## 常见陷阱
+
+| 陷阱                                          | 应对方式                                        |
+| --------------------------------------------- | ----------------------------------------------- |
+| 把"展示"和"操作"拆成两个 Story                | 合并为"展示与操作"一个 Story                    |
+| 为了消除重复而提取共享前置 Story              | 每个 Story 都包含自己的前提条件                 |
+| 一个验收标准对应一个 Story                    | 一个 Story 可以有多个验收标准                   |
+| Story 命名像技术任务                          | 改为从用户视角描述用户价值                      |
+| Epic 里明明有 3 个用户故事却拆出 5-6 个 Story | 检查是否在过度拆分，3 个用户故事最多对应 3-4 个 |

package/bin/zhanlu-plugins/lingji-beta-assistant/skills/beta-requirement-decomposer/references/epic-to-story-template.md

@@ -0,0 +1,93 @@
+# Story 输出模板
+
+## 文档头部
+
+```markdown
+# [项目名称] - 需求拆解文档
+
+## 项目信息
+- 空间名称: [填写空间名称]
+- 项目编码: [填写项目编码]
+- 项目名称: [填写项目名称]
+- 产品名称: [填写产品名称]
+```
+
+## 每个 Epic 区块
+
+```markdown
+---
+
+## Epic-{Epic序号}: {key}-{Epic标题}
+```
+
+## 每个 Story 区块
+
+```markdown
+### Story {Epic序号}.{Story序号}: {Story名称}
+
+| 字段 | 值 |
+| ----------- | ---------------- |
+| 需求Key | [自动生成，格式：{父需求Key}-S{序号}] |
+| 标题 | [Story标题] |
+| 类型 | 用户故事 |
+| 负责人 | [继承自父需求] |
+| 提出人 | [继承自父需求] |
+| 优先级 | [继承自父需求] |
+| 业务背景 | [继承自父需求，若无则填写"无"] |
+| 需求描述 | [拆解后的需求描述] |
+| 验收标准 | [拆解后的验收标准] |
+| 计划开始时间 | [继承自父需求] |
+| 计划结束时间 | [继承自父需求] |
+| 期望完成时间 | [继承自父需求，若无则填写"无"] |
+| 关联产品/业务平台类型 | [继承自父需求] |
+| 选择对应产品/业务平台 | [继承自父需求] |
+| 关联项目 | [继承自父需求] |
+| 关联版本 | [继承自父需求，若无则填写"无"] |
+| 迭代 | [继承自父需求，若无则填写"无"] |
+| 父需求 | [父需求Key] |
+```
+
+## 分隔符
+
+每个 Epic 之间用 `---` 分隔。
+
+## 完整示例
+
+```markdown
+# 研发大模型关键技术研发（2025） - 需求拆解文档
+
+## 项目信息
+- 空间名称: 研发大模型关键技术研发
+- 项目编码: R2511D2DC03
+- 项目名称: 研发大模型关键技术研发（2025）
+- 产品名称: 研发大模型
+
+---
+
+## Epic-1: CMSSR2511D2DC03-873 需求代码一致性检查
+
+### Story 1.1: Git提交信息需求代码一致性校验
+
+| 字段 | 值 |
+| ----------- | ---------------- |
+| 需求Key | CMSSR2511D2DC03-873-S1 |
+| 标题 | Git提交信息需求代码一致性校验 |
+| 类型 | 用户故事 |
+| 负责人 | 张三 |
+| 提出人 | 李四 |
+| 优先级 | P0 |
+| 业务背景 | 无 |
+| 需求描述 | 作为 一名开发人员，我想要 在推送（Push）代码到仓库时，系统能自动分析我的 Git 提交信息中的需求描述（如 Jira ID 或任务标题）与实际提交的代码变更是否匹配，以便于 我能及时发现并修正描述错误，确保代码库中每个提交都准确对应业务需求，避免后续维护混乱和代码审查（Code Review）的低效。 |
+| 验收标准 | 1、用户在push代码时，系统自动解析git提交信息中的需求标识；2、若检测到需求与提交代码不一致，系统向用户发出提醒提示；3、提醒信息清晰说明不一致的具体内容。 |
+| 计划开始时间 | 2026-04-27 16:00:00 |
+| 计划结束时间 | 2026-05-21 16:00:00 |
+| 期望完成时间 | 无 |
+| 关联产品/业务平台类型 | 产品 |
+| 选择对应产品/业务平台 | 研发大模型 |
+| 关联项目 | 研发大模型关键技术研发（2025）(R2511D2DC03) |
+| 关联版本 | 无 |
+| 迭代 | 无 |
+| 父需求 | CMSSR2511D2DC03-873 |
+
+---
+```