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

package/skills/wayfinder/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: wayfinder
+description: Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
+disable-model-invocation: true
+---
+
+A loose idea has arrived — too big for one agent session, and wrapped in fog: the way from here to the **destination** isn't visible yet. Wayfinding is about finding that way, not charging at the destination. This skill charts the way as a **shared map** on the repo's issue tracker, then works its **decision tickets** — questions whose resolution is a decision, not slices of a build to execute — one at a time until the route is clear.
+
+The destination varies per effort, and naming it is the first act of charting — it shapes every ticket. It might be a spec to hand off and iterate on, a decision to lock before planning starts, or a change made in place like a data-structure migration. The map is domain-agnostic — engineering work, course content, whatever fits the shape.
+
+## Plan, don't do
+
+Wayfinder is **planning** by default: each ticket resolves a decision, and the map is done when the way is clear — nothing left to decide before someone goes and does the thing. The pull to just do the work is usually the signal you've reached the edge of the map and it's time to hand off. An effort can override this in its **Notes** — carrying execution into the map itself — but absent that, produce decisions, not deliverables.
+
+## Refer by name
+
+Every map and ticket is an issue, so it has a **name** — its title. In everything the human reads — narration, the map's Decisions-so-far — refer to it by that name, never by a bare id, number, or slug. A wall of `#42, #43, #44` is illegible; names read at a glance. The id and URL don't vanish — a name wraps its link — but they ride *inside* the name, never stand in for it.
+
+## The Map
+
+The map is a single issue on this repo's issue tracker, labelled `wayfinder:map` — the canonical artifact. Its tickets are child issues of the map.
+
+The map is an **index**, not a store. It lists the decisions made and points at the tickets that hold their detail; a decision lives in exactly one place — its ticket — so the map never restates it, only gists it and links.
+
+**Where the map, its child tickets, blocking, and frontier queries physically live is tracker-specific.** The issue tracker should have been provided to you — run `/setup-matt-pocock-skills` if not. Consult the tracker doc's "Wayfinding operations" section for how _this_ repo expresses them. If no tracker has been provided, default to the local-markdown tracker.
+
+### The map body
+
+The whole map at low resolution, loaded once per session. Open tickets are **not** listed — they are open child issues, found by query.
+
+```markdown
+## Destination
+
+<what reaching the end of this map looks like — the spec, decision, or change this effort is finding its way to. One or two lines; every session orients to it before choosing a ticket.>
+
+## Notes
+
+<domain; skills every session should consult; standing preferences for this effort>
+
+## Decisions so far
+
+<!-- the index — one line per closed ticket: enough to judge relevance, then zoom the link for the detail the ticket holds -->
+
+- [<closed ticket title>](link) — <one-line gist of the answer>
+
+## Not yet specified
+
+<!-- see "Fog of war": in-scope fog you can't ticket yet; graduates as the frontier advances -->
+
+## Out of scope
+
+<!-- see "Out of scope": work ruled beyond the destination; closed, never graduates -->
+```
+
+### Tickets
+
+Each ticket is a **child issue** of the map; the tracker's issue id is its identity. Its body is the question, sized to one 100K token agent session:
+
+```markdown
+## Question
+
+<the decision or investigation this ticket resolves>
+```
+
+Each ticket carries a `wayfinder:<type>` label — one of `research`, `prototype`, `grilling`, `task` (see [Ticket Types](#ticket-types)).
+
+A session **claims** a ticket by assigning it to the dev driving the map, **first**, before any work, so concurrent sessions skip it. That assignee _is_ the claim: an open, unassigned ticket is unclaimed.
+
+Blocking uses the tracker's **native** dependency relationship — essential because it renders the frontier _visually_ in the tracker's own UI, so the human sees what's takeable without opening the map. Only a tracker that lacks native blocking falls back to a body convention. A ticket is **unblocked** when every ticket blocking it is closed; the **frontier** is the open, unblocked, unclaimed children — the edge of the known.
+
+The answer isn't part of the body — it's recorded on resolution (see [Work through the map](#work-through-the-map)). Assets created while resolving a ticket are linked from the issue, not pasted in.
+
+## Ticket Types
+
+Every ticket is either **HITL** — human in the loop, worked *with* a human who speaks for themselves — or **AFK**, driven by the agent alone. A HITL ticket only resolves through that live exchange; the agent never stands in for the human's side of it (a grilling agent that answers its own questions has broken this).
+
+- **Research** (AFK): Reading documentation, third-party APIs, or local resources like knowledge bases to surface a fact a decision waits on. Resolved by a `/research` **subagent**. Use when knowledge outside the current working directory is required.
+- **Prototype** (HITL): Raise the fidelity of the discussion by making a cheap, rough, concrete artifact to react to — an outline, a rough take, a stub, or UI/logic code via the /prototype skill. Links the prototype as an asset. Use when "how should it look" or "how should it behave" is the key question.
+- **Grilling** (HITL): Conversation via the /grilling and /domain-modeling skills, one question at a time. The default case.
+- **Task** (HITL or AFK): Manual work that must happen before a *decision* can be made — nothing to decide, prototype, or research, but the discussion is blocked until it's done. Signing up for a service so its API can be judged, provisioning access, moving data so its shape can be seen. This is the one type that *does* rather than decides — and it earns its place by unblocking a decision, not by delivering the destination. The agent drives it alone where it can (AFK); otherwise it hands the human a precise checklist (HITL). Resolved when the work is done; the answer records what was done and any resulting facts (credentials location, new URLs, row counts) later tickets depend on.
+
+## Fog of war
+
+The map is _deliberately_ incomplete: don't chart what you can't yet see. Beyond the live tickets lies the **fog of war** — the dim view of decisions and investigations you can tell are coming but can't yet pin down, because they hang on questions still open. Resolving a ticket clears the fog ahead of it, graduating whatever's now specifiable into fresh tickets — one at a time, until the way to the destination is clear and no tickets remain.
+
+The map's **Not yet specified** section is where that dim view is written down: the suspected question, the area to revisit later. It's the undiscovered frontier _toward_ the destination — everything here is in scope, just not sharp enough to ticket. Write as loosely or as fully as the view allows; it doubles as a signpost for collaborators reading where the effort is headed.
+
+**Fog or ticket?** The test is whether you can state the question precisely now — _not_ whether you can answer it now.
+
+- **Ticket when** the question is already sharp — even if it's blocked and you can't act on it yet.
+- **Not yet specified when** you can't yet phrase it that sharply. Don't pre-slice the fog into ticket-sized pieces: it's coarser than a ticket, and one patch may graduate into several tickets, or none, once the frontier reaches it.
+
+**Not yet specified** excludes what's already decided (Decisions so far), what's already a live ticket, and what's out of scope (the next section).
+
+## Out of scope
+
+Fog only ever gathers _toward_ the destination. The destination fixes the scope, so work beyond it is **out of scope** — it isn't fog, and it doesn't belong in **Not yet specified**. It gets its own **Out of scope** section on the map: work you've consciously ruled out of _this_ effort. Scope, not sharpness, lands it here.
+
+Out-of-scope work never graduates — the frontier stops at the destination — so it returns only if the destination is redrawn, and then as a fresh effort, not a resumption.
+
+Ruling something out of scope is a scoping act, not a step on the route. When a ticket that already exists turns out to sit past the destination — mis-scoped in while charting, or exposed by a resolution — **close it** (a closed ticket is unambiguously off the frontier) and leave one line in the **Out of scope** section: the gist plus why it's out of scope, linking the closed ticket. It stays out of **Decisions so far**, which records the route actually walked — a scope boundary isn't a step on it.
+
+## Invocation
+
+Two modes. Either way, **never resolve more than one ticket per session** — with the exception of research tickets.
+
+### Chart the map
+
+User invokes with a loose idea.
+
+1. **Name the destination.** Run a `/grilling` and `/domain-modeling` session to pin down what this map is finding its way to — the spec, decision, or change. The destination fixes the scope, so it's settled first.
+2. **Map the frontier.** Grill again, **breadth-first** this time: fan out across the whole space rather than deep on any one thread, surfacing the open decisions and the first steps takeable now. **If this surfaces no fog** — the way to the destination is already clear, the whole journey small enough for one session — you don't need a map. Stop and ask the user how they'd like to proceed.
+3. **Create the map** (label `wayfinder:map`): Destination and Notes filled in, Decisions-so-far empty, the fog sketched into **Not yet specified**.
+4. **Create the tickets you can specify now** as child issues of the map — then wire blocking edges in a **second pass** (issues need ids before they can reference each other). Wiring sorts them into the frontier and the blocked; everything you can't yet specify stays in the fog — the **Not yet specified** section.
+5. **Fire the research subagents.** For each `research` ticket you just created, spin up a `/research` subagent to resolve it in parallel, capturing its findings on a throwaway `research/<name>` branch with a context pointer from the ticket.
+6. Stop — charting is one session's work; it hand-resolves nothing.
+
+### Work through the map
+
+User invokes with a map (URL or number). A ticket is **optional** — without one, you pick the next decision, not the user.
+
+1. Load the **map** — the low-res view, not every ticket body.
+2. Choose the ticket. If the user named one, use it. Otherwise take the first frontier ticket in order. **Claim it**: assign it to yourself before any work.
+3. Resolve it — **zoom as needed**: fetch the full body of any related or closed ticket on demand; invoke the skills the `## Notes` block names. If in doubt, use `/grilling` and `/domain-modeling`.
+4. Record the resolution: post the answer as a **resolution comment**, **close** the issue, and **append a context pointer** to the map's Decisions-so-far.
+5. Add newly-surfaced tickets (create-then-wire); graduate any fog the answer has made specifiable, clearing each graduated patch from **Not yet specified** so it lives only as its new ticket. If the answer reveals a ticket — this one or another — sits beyond the destination, **rule it out of scope** rather than resolving it on the route. If the decision invalidates other parts of the map, update or delete those tickets.
+
+The user may run unblocked tickets in parallel, so expect other sessions to be editing the tracker concurrently.

package/skills/wayfinder/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Wayfinder"
+  short_description: "Map a large effort as decision tickets"
+policy:
+  allow_implicit_invocation: false

package/skills/write-design-document-by-template/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: write-design-document-by-template
+description: 按模板编写设计说明书 | 触发条件：写设计文档、编写设计说明书、技术方案设计、系统设计 | 帮助按照标准模板编写完整的设计说明书
+metadata:
+  author: maohan
+  source: project
+  date_added: "2026-07-08"
+  risk: low
+---
+
+# 按模板编写设计说明书
+
+本技能帮助按照标准模板编写完整的设计说明书。
+
+---
+
+## 使用方法
+
+1. 加载模板文件 `references/设计说明书模板.md`
+2. 根据模板章节结构编写设计说明书
+3. 填充模板中的占位内容
+
+---
+
+## 模板结构
+
+设计说明书应包含以下章节：
+
+| 章节 | 说明 |
+|------|------|
+| 1. 版本更新记录 | 文档变更历史 |
+| 2. 引言 | 需求背景、定义、参考资料 |
+| 3. 整体架构设计 | 系统架构图、模块划分与职责、关键技术决策 |
+| 4. 功能设计 | 总体功能设计、模块设计、核心接口设计、功能实现设计 |
+| 5. 数据模型设计 | 数据模型定义、ER图设计、关键字段说明 |
+| 6. 非功能性设计 | 性能、安全、可靠性、兼容性、异常防护 |
+
+---
+
+## 编写要点
+
+### 版本更新记录
+- 记录文档的变更历史
+- 包含版本号、变更类型、变更内容、更新人和日期
+
+### 引言
+- **需求背景**：说明功能背景、开发目的、参与人员
+- **定义**：列出文档中使用的专门术语和外文缩写
+- **参考资料**：列出相关参考文档和资料
+
+### 整体架构设计
+- **系统架构图**：使用Mermaid或PlantUML绘制系统整体架构图，展示系统分层、核心组件、外部依赖
+- **模块划分与职责**：描述各模块划分及职责，明确模块边界清晰、低耦合、高内聚
+- **关键技术决策**：记录关键技术选型及决策依据（选型理由、替代方案、风险评估）
+
+### 功能设计
+- **总体功能设计**：整体功能点描述、功能模块结构、与其他模块的关系
+- **模块设计**：模块依赖关系、核心接口设计及清单（REST API端点、联动接口）、引用三方组件
+- **功能实现设计**：业务流程图、技术实现方案、约束与限制、部署结构、配置项设计、特殊场景、监控点、核心逻辑
+
+### 数据模型设计
+- **数据模型定义**：业务模型（不映射数据库）、数据库表实体（映射数据表）
+- **ER图设计**：使用ER图展示数据模型之间的关系（实体、属性、关系）
+- **关键字段说明**：对核心业务字段进行详细说明（字段名、字段类型、业务含义、约束条件）
+
+### 非功能性设计
+- **性能设计**：性能指标、优化方案
+- **安全设计**：认证/授权方案、操作审计、数据加密
+- **可靠性设计**：容错机制、数据恢复、异常处理
+- **兼容性设计**：浏览器兼容（如有）、操作系统兼容、数据库兼容、历史功能兼容
+- **异常场景防护**：重启数据恢复、网络异常留痕、未完成数据留痕
+
+### 工程化要求
+- **架构图清晰可读**：必须用 mermaid 绘制；分层清晰、组件职责明确，不能是纯文字或贴图
+- **数据模型完整**：业务模型 + 数据库表实体配对
+- **API契约规范**：端点表遵循 REST 规范
+- **与需求一致**：端点表、错误码、业务枚举等需要与需求保持一致
+- **非功能设计**：至少要包含安全设计
+- **架构亮点、约束贯彻、关键决策**：至少 2 条
+- **避免绝对化表述**：绝对不能出现"完美""零缺陷""完全覆盖"等绝对化词汇
+- **杜绝凑数内容**：一定要杜绝设计文档中大量文字填充但不解决实际问题
+
+---
+
+## 输出格式
+
+完成后，输出完整的 Markdown 格式设计说明书。
+
+---
+
+## 触发场景
+
+- "写设计文档"
+- "编写设计说明书"
+- "帮我设计技术方案"
+- "做一个系统设计"
+- "帮我写xxx的技术设计文档"

package/skills/write-design-document-by-template/references//350/256/276/350/256/241/350/257/264/346/230/216/344/271/246/346/250/241/346/235/277.md

@@ -0,0 +1,235 @@
+# 1 版本更新记录
+
+| 版本 | 类型 | 提交人 | 提交日期 | 更新内容 |
+| :---: | :---: | :---: | :---: | --- |
+| xxx | xxx | xxx | yyyy-mm-dd | xxx |
+
+**类型说明**：新建 / 修改 / 删除
+
+---
+
+# 2 引言
+
+## 2.1 需求背景
+
+说明此功能背景、需求背景、开发目的等，还可以列出参与人员等相关信息。
+
+## 2.2 定义
+
+列出本文件中用到专门术语的定义和外文首字母组词的原词组。
+
+## 2.3 参考资料
+
+列出相关参考文档和资料：
+- xxx
+- xxx
+
+---
+
+# 3 整体架构设计
+
+## 3.1 系统架构图
+
+使用 Mermaid 或 PlantUML 绘制系统整体架构图，展示：
+- 系统分层结构
+- 核心组件及其关系
+- 外部依赖系统
+
+```mermaid
+graph TD
+    A[xxx] --> B[xxx]
+    B --> C[xxx]
+```
+
+## 3.2 模块划分与职责
+
+描述系统各模块的划分及职责，需明确：
+- 模块边界清晰，职责单一
+- 模块间低耦合、高内聚
+- 模块间依赖关系
+
+| 模块名称 | 模块职责 | 依赖模块 |
+| --- | --- | --- |
+| xxx | xxx | xxx |
+
+## 3.3 关键技术决策
+
+记录关键技术选型及决策依据：
+
+| 技术选型 | 选型理由 | 替代方案 | 风险评估 |
+| --- | --- | --- | --- |
+| xxx | xxx | xxx | xxx |
+
+---
+
+# 4 功能设计
+
+## 4.1 总体功能设计
+
+### 4.1.1 功能描述
+
+整体功能点描述
+
+### 4.1.2 功能模块结构
+
+该功能和其他模块的关系，功能影响范围
+
+## 4.2 模块设计
+
+### 4.2.1 模块依赖关系
+
+描述当前模块和其他依赖模块之间的关系
+
+### 4.2.2 核心接口设计
+
+#### REST API 端点
+
+遵循 REST 设计规范，描述核心接口：
+
+| 接口名称 | 请求方法 | 接口路径 | 描述 |
+| --- | --- | --- | --- |
+| xxx | GET/POST/PUT/DELETE | xxx | xxx |
+
+#### 接口详细说明
+
+| **接口名称** | xxx |
+| ------------ | ---- |
+| **接口描述** | xxx |
+| **接口地址** | xxx |
+| **请求方法** | GET/POST/PUT/DELETE |
+| **请求参数** | xxx |
+| **成功响应** | xxx |
+| **失败响应** | xxx |
+| **超时时间** | xxx |
+
+#### 联动接口
+
+描述与外部系统/服务的联动接口：
+
+| 接口名称 | 接口类型 | 依赖系统 | 接口说明 |
+| --- | --- | --- | --- |
+| xxx | REST/RPC/MQ | xxx | xxx |
+
+### 4.2.3 引用三方组件
+
+列举当前功能特殊依赖的三方组件
+
+| 组件名称 | 组件版本 | 用途说明 |
+| --- | --- | --- |
+| xxx | xxx | xxx |
+
+## 4.3 功能实现设计
+
+### 4.3.1 业务流程设计
+
+描述当前功能的总体的业务需求，关键流程，尽可能的绘制业务流程图
+
+### 4.3.2 技术实现方案
+
+描述当前功能实现采用的技术，包括依赖的第三方技术，第三方技术介绍以及第三方技术解决的业务
+
+### 4.3.3 约束与限制
+
+描述当前功能所受的内部和外部条件的约束和限制说明
+
+### 4.3.4 部署结构设计
+
+当前功能特殊的环境部署要求
+
+### 4.3.5 配置项设计
+
+明确说明增加、删除、修改的配置项，评估配置项变更对历史功能的影响
+
+**配置示例**（如：Nacos、Apollo、配置文件等）
+
+### 4.3.6 特殊场景设计
+
+描述特殊场景及应对策略（如：环境未达条件、服务重启影响、基础服务依赖等）
+
+### 4.3.7 监控点设计
+
+关键监控指标（如：性能指标、业务指标、告警规则）
+
+### 4.3.8 核心逻辑说明
+
+核心代码逻辑说明、关键算法说明
+
+---
+
+# 5 数据模型设计
+
+## 5.1 数据模型定义
+
+**业务模型（不映射数据库）：**
+
+| 属性名 | 类型 | 描述 |
+| --- | --- | --- |
+| xxx | xxx | xxx |
+
+**数据库表模型（映射数据表）：**
+
+| 属性名 | 属性类型 | 字段名 | 字段类型 | 字段说明 | 是否主键 |
+| --- | --- | --- | --- | --- | --- |
+| xxx | xxx | xxx | xxx | xxx | 是/否 |
+
+## 5.2 ER 图设计
+
+使用 ER 图展示数据模型之间的关系：
+- 实体（Entity）
+- 属性（Attribute）
+- 关系（Relationship）
+
+```mermaid
+erDiagram
+    ENTITY1 ||--o{ ENTITY2 : relationship
+    ENTITY1 {
+        type field1
+        type field2
+    }
+    ENTITY2 {
+        type field1
+        type field2
+    }
+```
+
+## 5.3 关键字段说明
+
+对核心业务字段进行详细说明：
+
+| 字段名 | 字段类型 | 业务含义 | 约束条件 |
+| --- | --- | --- | --- |
+| xxx | xxx | xxx | xxx |
+
+---
+
+# 6 非功能性设计
+
+## 6.1 性能设计
+
+- 性能指标：xxx
+- 优化方案：xxx
+
+## 6.2 安全设计
+
+- 认证/授权方案：xxx
+- 操作审计：xxx
+- 数据加密：xxx
+
+## 6.3 可靠性设计
+
+- 容错机制：xxx
+- 数据恢复：xxx
+- 异常处理：xxx
+
+## 6.4 兼容性设计
+
+- 浏览器兼容（如有）：xxx
+- 操作系统兼容：xxx
+- 数据库兼容：xxx
+- 历史功能兼容：xxx
+
+## 6.5 异常场景防护性设计
+
+- 重启数据恢复：xxx
+- 网络异常留痕：xxx
+- 未完成任务数据留痕：xxx

package/skills/write-requirement-document-by-template/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: write-requirement-document-by-template
+description: 按模板编写需求说明书 | 触发条件：写需求文档、编写需求说明书、新建需求、开发新功能前需要文档化需求 | 帮助按照标准模板编写完整的需求说明书
+metadata:
+  author: maohan
+  source: project
+  date_added: "2026-07-08"
+  risk: low
+---
+
+# 按模板编写需求说明书
+
+本技能帮助按照标准模板编写完整的需求说明书。
+
+---
+
+## 使用方法
+
+1. 加载模板文件 `references/需求说明书模板.md`
+2. 根据模板章节结构编写需求说明书
+3. 填充模板中的占位内容
+
+---
+
+## 模板结构
+
+需求说明书应包含以下章节：
+
+| 章节 | 说明 |
+|------|------|
+| 1. 版本更新记录 | 文档变更历史 |
+| 2. 业务背景 | 需求产生的业务背景和目的 |
+| 3. 需求概述 | 影响范围、业务角色、主流程、约束条件 |
+| 4. 功能点描述 | 详细的功能说明 |
+| 5. 非功能性需求 | 性能、安全、可靠性、扩展性 |
+| 6. 兼容性要求 | 浏览器、分辨率、历史功能兼容性 |
+
+---
+
+## 编写要点
+
+### 版本更新记录
+- 记录文档的变更历史
+- 包含版本号、变更类型、提交版本、变更内容、更新人和日期
+
+### 业务背景
+- **现状痛点**：描述当前存在的问题，痛点必须含数据/事实（处理时间、错误率、成本等量化指标），且不能定性描述
+- **解决方向**：描述如何解决上述痛点，说明预期收益（时间缩短、错误率下降等）
+
+### 需求概述
+- **业务角色**：使用该功能的业务人员角色及其职责
+- **主流程**：用流程图或文字描述主要业务流程
+- **业务约束**：业务层面的限制条件，至少包含 3 条具体业务约束
+- **技术约束**：技术层面的限制条件（开发语言版本、数据库、中间件等）
+- **接口需求**：接口类型、接口用途、输入参数、输出参数、超时时间
+  - 端点表（API路径、请求方法、参数说明）
+  - 错误码（业务错误码、系统错误码）
+
+### 功能点描述
+- **功能脑图**：用脑图展示功能模块关系
+- **用户故事**：作为【角色】，我希望【操作】，以便【目标】，包含验收标准
+- **功能详细说明**：功能描述、前置条件、输入、处理逻辑、输出、异常处理、用户操作途径、界面交互
+  - 用户操作途径：说明用户通过哪些途径访问此功能（如：菜单入口、URL、API调用、消息触发等）
+
+### 非功能性需求
+- **性能**：接口响应时间、并发支持、数据处理能力、系统可用性
+- **安全性**：认证、授权、数据加密、审计、防护
+- **可靠性**：容错、恢复、备份、数据一致性
+- **扩展性**：横向扩展、纵向扩展、功能扩展
+- **可测试性**：单元测试、集成测试、Mock支持、测试数据
+- **可维护性**：日志、监控、配置、文档
+
+### 兼容性要求
+- **浏览器兼容性**：支持的浏览器版本
+- **分辨率兼容性**：支持的分辨率
+- **历史功能兼容性**：新增接口对历史接口的影响
+
+### 工程化一致性
+- **版本记录规范**：版本号、变更类型、提交人、日期、更新内容完整
+- **命名规范**：术语、模块、接口命名遵循团队约定，前后一致
+- **文档结构规范**：章节层级清晰，编号连续，无错位
+- **避免绝对化表述**：绝对不能出现"完美""零缺陷""完全覆盖"等绝对化词汇
+- **杜绝凑数内容**：一定要杜绝需求文档中大量文字填充但不解决实际问题
+
+---
+
+## 输出格式
+
+完成后，输出完整的 Markdown 格式需求说明书。
+
+---
+
+## 触发场景
+
+- "写需求文档"
+- "编写需求说明书"
+- "我要开发新功能，需要需求文档"
+- "帮我写一个xxx的需求分析"