PRD生成 Skill

一、Skill定位

用于辅助完成工作中的两份核心文档：

1. 《需求分析文档》
2. 《数字化解决方案设计文档》

根据当前用户提供的背景、要求、痛点及已有资料生成文档。

核心原则：

> 业务痛点明确 → 需求完整 → 功能有对应关系 → 方案可落地 → 业务闭环完整 → 规则可核验 → 数据逻辑一致 → 页面可实现。

文档以竞赛实操为目标，强调完整、准确、可实现，不追求长篇幅和功能堆砌。

二、执行方式

支持以下执行方式：

Step 1

生成《需求分析文档》。

Step 2

基于当前赛题及已有《需求分析文档》，生成《数字化解决方案设计文档》。

Step 1 + Step 2

依次完成两份文档。

如果Step 2执行时已经存在Step 1结果，必须优先继承已有的角色、痛点、需求、功能、业务对象等内容，避免前后出现不一致。

三、通用输出要求

1. 输出格式

只输出Markdown内容。

不负责DOCX排版，后续由其他工具进行DOCX转换。

Markdown仅使用：

• 标题
• 段落
• 有序/无序列表
• Markdown表格

禁止使用：

• Mermaid
• ASCII字符画
• 状态机代码
• JSON作为文档主体
• 代码块模拟流程图
• 复杂字符图
• 依赖特殊渲染才能正确转换DOCX的内容

流程和数据流向使用文字、编号步骤或Markdown表格表达。

2. 内容控制

• 不追求文档篇幅。
• 不堆砌无关功能。
• 优先保证核心业务链完整。
• 优先描述能够在竞赛时间内实现和演示的内容。
• 对不确定的业务规则不得虚构行业标准。
• AI不是必选项，只有能够解决实际业务问题时才使用。
• 技术架构根据赛题实际需要决定，不强行添加。
• 文档内容里只呈现业务、需求、方案、规则、数据、页面和实现设计，不得呈现思考过程、自检过程或Skill执行过程。
• 禁止在最终文档中出现“已自检”“经分析”“本次提炼”“根据上述分析”“本文已完成一致性检查”等执行思考过程性表述。
• 禁止将Skill中的执行步骤、检查动作、提示词要求写入最终业务文档。

3. 一次性完成

• 应根据当前资料一次性生成完整文档。
• 仅在规定的自检触发条件下执行自检，见Step 2中的“自检机制”。
• 自检属于内部处理过程，不得将自检过程、检查结果、修改过程写入最终文档。

Step 1：需求分析文档

生成《需求分析文档》。

1. 项目背景

简要说明：

• 项目背景
• 业务现状
• 建设目标

避免大段重复赛题原文。

2. 业务现状与痛点

严格以赛题正文中明确列出的突出问题/现存问题为依据，原则上逐条保留，不得为了控制数量而合并。

• 如果赛题明确列出1～N条问题，则需求分析文档应完整对应列出这1～N条问题，不得擅自压缩为“3～5个核心痛点”。
• 允许在每条赛题痛点下补充“业务影响”和“需要解决的核心问题”，但不得改变、删除、合并赛题原有痛点。
• 如果赛题没有明确列出痛点，再根据业务背景合理提炼，数量以实际需要为准。
• 痛点必须具体，不使用大量“效率低、管理难、信息孤岛”等空泛表述。
• 痛点编号应与赛题原有编号保持对应，便于后续评分和需求追踪。

3. 用户角色与业务场景

列出主要用户角色，并说明：

• 角色职责
• 主要业务场景
• 核心需求

角色数量以实际业务需要为准。

4. 业务架构

梳理当前业务涉及的主要业务领域、业务环节和业务模块。

说明各业务模块之间的关系。

业务架构应能够支撑后续功能需求和解决方案设计。

5. 功能需求

按照业务模块列出核心功能。

每项功能至少说明：

• 功能名称
• 功能目的
• 主要业务内容

功能必须能够对应实际业务痛点。

6. 数据需求

列出核心业务数据，并说明：

• 数据名称
• 数据来源
• 主要内容
• 主要用途

只描述支撑核心业务所需的数据。

7. 非功能需求

根据实际赛题选择必要内容，包括：

• 性能
• 安全
• 可靠性
• 易用性
• 可维护性
• 数据质量
• 其他实际约束

不要机械套用完整软件工程模板。

8. 业务痛点与功能需求对应关系

建立痛点与功能之间的对应关系。

推荐使用表格：

确保每个核心痛点都有明确的解决功能。

9. 需求总体框架

总结：

业务痛点 → 用户角色 → 业务需求 → 功能需求 → 数据需求

使用简洁文字或表格表达。

10. Step 1自检

检查：

• 用户角色是否完整
• 业务场景是否覆盖
• 痛点是否具体
• 功能是否对应痛点
• 数据是否支撑功能
• 非功能需求是否合理
• 是否存在没有业务依据的功能

发现问题直接修改。

Step 2：数字化解决方案设计文档

基于当前赛题和Step 1结果生成《数字化解决方案设计文档》。

必须保证与Step 1中的角色、痛点、需求、功能、数据对象保持一致。

1. 总体解决方案

说明：

• 建设目标
• 总体解决思路
• 主要业务模块
• 业务与数据总体流向

重点回答：

系统如何解决前面提出的核心业务痛点。

2. 业务架构

将需求阶段的业务架构进一步落实为解决方案中的业务模块。

说明：

• 核心业务域
• 业务模块
• 模块职责
• 模块之间的业务关系

3. 业务闭环设计

围绕赛题明确要求且方案实际具备功能的核心业务场景设计闭环。

• 业务闭环数量不设绝对上限，以赛题复杂度、明确要求和实际设计功能为依据。通常围绕少量核心业务主线展开，不为了丰富文档而扩展大量分支。
• 对于赛题明确要求、业务上相互独立且具有实际价值的多个核心场景，可分别设计业务闭环，不得为了控制数量而强行合并。
• 闭环必须与Step 1中的功能需求、Step 2中的页面和核心功能一致。
• 业务闭环应能够通过原型进行验证，避免设计无法演示或没有数据支撑的环节。
• 可根据实际业务采用“数据采集 → 异常判断 → 问题确认 → 分类/风险分级 → 处置 → 整改 → 复核 → 销项”等结构，但不得机械套用。
• 只有赛题确实存在异常、退回、重新处理等情况时，才设计对应分支。
• 不得为了体现完整性而增加与赛题无关的审批、统计、预警、画像、AI分析等业务分支。
• 流程使用编号步骤或表格描述。

4. 业务规则设计

仅针对赛题明确涉及、方案实际使用且能够被数据支撑和验证的规则进行设计。

• 规则数量不设绝对上限，优先围绕赛题明确要求和方案实际使用的核心业务判定进行设计。通常采用少量核心规则，不追求规则数量。
• 对于题目明确提出、业务流程实际需要且会直接影响系统判断或业务处理的规则，应完整保留，不得为了控制数量而合并或删除。
• 只有赛题或方案确实需要时，才增加重复问题、动态评分、升级督办等规则。
• 每条规则必须能够回答：需要什么数据 → 满足什么条件 → 判定什么结果 → 触发什么业务动作。
• 规则必须与业务闭环、页面操作和核心功能相互对应。
• 不得为了显得“智能”而虚构复杂评分模型、行业阈值或大量自动化规则。
• 规则优先采用：

条件 → 判断 → 结果 → 业务动作

的方式表达。

5. 功能设计及需求追踪

建立：

业务痛点 → 业务需求 → 功能模块 → 核心页面

之间的对应关系。

使用Markdown表格表达。

确保方案中的功能能够追溯到Step 1。

6. 系统页面与交互设计

对核心页面进行简版PRD级描述。

• 页面数量以支撑完整业务闭环为准，不追求数量。
• 页面应优先按照实际功能模块组织，而不是按照每一个数据对象拆分页面。
• 一个数据对象通常采用“列表/台账 + 操作列 + 详情/处理页”的方式组织。详情页属于该功能模块的一部分，不应单独作为一个独立功能模块。
• 只有以下情况才单独拆分页面：
• PC端与H5/移动端存在明显不同的操作场景；
• 不同角色承担完全不同的业务操作；
• 页面需要承担明显不同的核心业务任务；
• 详情页本身存在独立、复杂的业务处理流程。
• 禁止为了增加页面数量，将同一业务模块的列表、详情、编辑、处理等简单拆成多个独立功能。

每个核心功能必须描述：

页面定位

• 页面名称
• 所属功能模块
• 使用角色
• 页面目的

页面布局

说明主要区域及布局，例如：

• 查询/筛选区
• 统计区
• 地图区
• 列表区
• 详情区
• 操作区

列表字段

必须使用Markdown表格列出，不得写成连续文字。

只列出支撑当前页面业务操作的核心字段，不追求字段数量。

列表操作

表单字段

必须使用Markdown表格列出，不得写成连续文字。

只列出实际需要用户填写、选择或上传的字段。

详情信息

如果列表操作列存在“查看详情”，详情作为该功能模块的子页面描述，说明：

• 核心信息；
• 关联数据；
• 当前状态；
• 可执行操作。

除非符合前述独立页面条件，不得将详情页单独列为一个新的功能模块。

核心交互

说明用户能够进行的主要操作，以及操作条件。

交互结果

说明操作完成后产生的业务变化。

数据流向

说明：

数据来源 → 页面处理/使用 → 产生结果 → 下一业务环节

不要只写“支持查询、编辑、提交”等功能名称，必须达到能够指导后续HTML原型设计的粒度。

7. 核心业务数据设计

列出支撑核心业务闭环的业务对象，例如：

• 项目
• 标段
• 单位
• 人员
• 设备
• 问题
• 风险
• 整改工单
• 复查记录

根据实际赛题选择。

说明：

• 核心对象
• 主要字段
• 对象之间的业务关系
• 数据在业务流程中的作用

不要求进行完整数据库设计。

8. 非功能需求与设计约束

根据实际赛题描述：

• 性能要求
• 数据安全
• 权限
• 系统可靠性
• 易用性
• 数据质量
• 网络或部署环境
• 其他影响系统设计的约束

只保留实际有意义的内容。

9. 技术架构与关键技术设计（按需）

系统技术架构，考虑赛事时间，后端采用spingbot+sqlite，前端vue

AI架构根据赛题实际情况决定是否生成。

如果存在明确的技术需求，可说明：

• 数据采集
• 数据存储
• 业务服务
• AI能力
• 规则能力
• GIS
• IoT
• 视频
• 无人机
• 数据分析等。

如果AI不是实际业务需要，不得为了体现AI而强行增加。

如果赛题对技术架构要求较弱，可以简化本章节。

Step 2：自检机制

0. 自检触发条件

仅在以下三种情况下执行完整自检：

1. 第一次生成Step 1或Step 2时：完成首次完整自检；
2. 用户明确要求“自检、检查一致性、检查逻辑、检查文档”等时：执行完整自检；
3. 最终定稿时：执行一次完整自检。

在用户仅要求修改、补充、调整某一部分内容时：

• 默认只修改用户指定内容，不自动进行完整自检；
• 可进行必要的局部逻辑判断，避免明显冲突，但不得重新执行整份文档的完整自检；
• 不得因为每次修改都自动触发完整自检而重复消耗处理资源。

1. 自检输出原则

• 自检属于内部处理过程。
• 不得在最终文档中出现任何自检过程、检查结果、修正记录或Skill执行提示。
• 不得在文档中体现“已自检”“检查发现”“已修正”“一致性检查通过”等过程性文字。
• 用户要求查看自检结果时，才单独向用户说明检查发现和修改内容；这些内容不得写入正式文档。

2. 需求一致性

检查：

• 每个赛题痛点是否完整保留并有对应需求和功能。
• 方案中的功能是否能够追溯到需求分析。
• 是否存在没有业务依据的功能。
• 页面是否覆盖核心功能。

3. 业务流程检查

检查：

• 核心业务流程是否完整。
• 前后业务节点是否逻辑合理。
• 是否存在跳过必要业务环节的情况。
• 是否存在实际需要的异常、退回或重新处理路径。
• 是否真正形成业务闭环。

4. 数据流检查

重点检查：

数据从哪里来 → 在哪里产生/处理 → 产生什么结果 → 流向哪里

确认：

• 每项核心数据是否有明确来源。
• 上一个环节产生的数据是否能够支撑下一个环节。
• 是否存在凭空产生的数据。
• 数据是否存在合理的后续用途。
• 页面中的数据是否在核心数据设计中存在。
• 规则所需要的数据是否真实存在。
• 统计、评分、画像等结果是否能够由已有数据计算得到。

5. 数据对象与字段一致性检查

检查：

• 同一业务对象是否前后使用不同名称。
• 同一字段是否出现多个名称。
• 字段含义是否前后一致。
• 列表、详情、表单字段是否与核心数据对象一致。
• 页面字段、业务规则和核心功能使用的数据是否一致。

6. 业务状态与操作检查

检查：

• 是否存在不合理的业务状态。
• 状态转换是否合理。
• 当前状态是否允许对应操作。
• 未完成整改的问题是否可能直接销项。
• 复核不通过是否能够重新整改。
• 已销项数据是否存在明显矛盾的操作路径。

7. 规则逻辑检查

检查：

• 分类规则是否有对应数据。
• 风险分级规则是否能够实际计算。
• 动态评分指标是否有数据来源。
• 重复问题判断所需的数据是否存在。
• 规则计算结果是否真正影响业务流程。
• 页面展示的结果是否与规则一致。

8. 页面与业务检查

检查：

• 页面是否对应明确业务场景。
• 页面布局是否能够支撑实际操作。
• 列表字段是否满足业务需要。
• 表单字段是否满足业务处理需要。
• 操作是否符合当前业务状态。
• 操作后的结果是否与业务流程一致。
• 页面数据来源和去向是否正确。
• 同一功能模块的列表、详情、处理页面是否被不必要地拆成多个独立功能。

9. 可实现性检查

检查：

• 页面是否能够转换为HTML原型。
• 核心功能是否能够根据文档直接进行开发。
• 业务规则是否能够转化为程序逻辑。
• 是否存在“文档写了功能，但没有数据或处理逻辑支撑”的情况。
• 是否存在明显超出4小时竞赛实现能力的复杂设计。

10. 最终链路检查

最终确认：

业务痛点 → 需求 → 功能 → 业务流程 → 业务规则 → 数据 → 页面 → 核心功能 → 业务结果

如果发现任何环节无法对应：

优先修正逻辑和对应关系，不增加无关内容。

最终目标是：

> 文档内容完整、前后一致、数据流合理、业务逻辑正确，并能够直接指导后续原型和核心功能开发。

Step 2：最终一致性自检

文档生成完成后，必须进行一次完整的方案走查。

发现问题直接修改文档。

1. 需求一致性

检查：

• 每个核心痛点是否有对应需求和功能。
• 方案中的功能是否能够追溯到需求分析。
• 是否存在没有业务依据的功能。
• 页面是否覆盖核心功能。

2. 业务流程检查

检查：

• 核心业务流程是否完整。
• 前后业务节点是否逻辑合理。
• 是否存在跳过必要业务环节的情况。
• 是否存在必要的异常、退回或重新处理路径。
• 是否真正形成业务闭环。

3. 数据流检查

重点检查：

数据从哪里来 → 在哪里产生/处理 → 产生什么结果 → 流向哪里

确认：

• 每项核心数据是否有明确来源。
• 上一个环节产生的数据是否能够支撑下一个环节。
• 是否存在凭空产生的数据。
• 数据是否存在合理的后续用途。
• 页面中的数据是否在核心数据设计中存在。
• 规则所需要的数据是否真实存在。
• 统计、评分、画像等结果是否能够由已有数据计算得到。

4. 数据对象与字段一致性检查

检查：

• 同一业务对象是否前后使用不同名称。
• 同一字段是否出现多个名称。
• 字段含义是否前后一致。
• 列表、详情、表单字段是否与核心数据对象一致。
• 页面字段、业务规则和核心功能使用的数据是否一致。

5. 业务状态与操作检查

检查：

• 是否存在不合理的业务状态。
• 状态转换是否合理。
• 当前状态是否允许对应操作。
• 未完成整改的问题是否可能直接销项。
• 复核不通过是否能够重新整改。
• 已销项数据是否存在明显矛盾的操作路径。

6. 规则逻辑检查

检查：

• 分类规则是否有对应数据。
• 风险分级规则是否能够实际计算。
• 动态评分指标是否有数据来源。
• 重复问题判断所需的数据是否存在。
• 规则计算结果是否真正影响业务流程。
• 页面展示的结果是否与规则一致。

7. 页面与业务检查

检查：

• 页面是否对应明确业务场景。
• 页面布局是否能够支撑实际操作。
• 列表字段是否满足业务需要。
• 表单字段是否满足业务处理需要。
• 操作是否符合当前业务状态。
• 操作后的结果是否与业务流程一致。
• 页面数据来源和去向是否正确。

8. 可实现性检查

检查：

• 页面是否能够转换为HTML原型。
• 核心功能是否能够根据文档直接进行开发。
• 业务规则是否能够转化为程序逻辑。
• 是否存在“文档写了功能，但没有数据或处理逻辑支撑”的情况。
• 是否存在明显超出4小时竞赛实现能力的复杂设计。

9. 最终链路检查

最终确认以下链路能够完整对应：

业务痛点 → 需求 → 功能 → 业务流程 → 业务规则 → 数据 → 页面 → 核心功能 → 业务结果

如果发现任何环节无法对应：

优先修正逻辑和对应关系，不增加无关内容。

最终目标是：

> 文档内容完整、前后一致、数据流合理、业务逻辑正确，并能够直接指导后续原型和核心功能开发。