AI辅助需求分析和探索

SKILL开发
开发 未标注权限 许可证不明确
安装这个技能

基于《AI 需求探索与确认提示词 V10.0》的交互式需求探索技能:由 AI 主导八阶段结构化访谈,把一句话或一段原始业务需求逐步转化为符合《软件需求编写规范 V10.0》(九部分 + 附录 A、54 项自检)且可直接驱动本体建模与 AI 编码的软件需求规格说明书,并配套交付《编制说明》。当用户提出"做需求探索 / 需求分析 / 需求访谈 / 需求确认 / 写需求文档 / 需求规格说明书 / 把这段业务需求整理成可建模的文档",或给出一段业务需求希望产出可落地、可建模的规范文档时使用。触发词:需求探索、需求分析、需求文档、需求规格说明书、需求访谈、需求确认、写需求、整理需求、业务需求、软件需求、需求评审、requirement exploration、SRS。

一句话选型结论

按资料字段整理

AI辅助需求分析和探索是开发类的 Agent Skill,安装方式未标注,权限级别未标注,许可证不明确,有可直接复制的安装命令。技能本质是给模型读的说明书,效果取决于模型与客户端;装完先用一个小任务验证,再放进正式流程。

分类开发 安装方式未标注 权限级别未标注权限 许可证许可证不明确
累计安装 未标注 本周 未标注
GitHub 星标 未标注 仓库 未标注
下载量 未标注 技能市场下载数
权限级别 未标注权限 安装前请确认风险范围
许可证 许可证不明确 未说明

安装

未标注
在支持 Skills 的客户端里执行,装完问一句「你有哪些技能」验证
skillhub install user_81d33501/requirement-exploration
  1. 1
    确认客户端支持

    确认你的客户端支持 Skills(Claude、Codex、Cursor 等),并升级到较新的版本。

  2. 2
    拿到技能文件

    执行上面的命令安装;也可以把仓库里的 SKILL.md 手动放进客户端的 skills 目录。

  3. 3
    刷新技能列表

    重新打开客户端,或刷新技能列表,让新放进来的技能被加载。

  4. 4
    验证是否生效

    问一句「你有哪些技能」,确认列表里出现它,再拿一个小任务试跑。

技能档案

开发
字段来自技能仓库与公开索引,中文说明由本站标注
作者 / 维护方user_81d33501仓库 未标注 · 版本 未标注
宿主客户端未标注技能可被这些客户端加载
安装方式未标注安装包 community
权限级别未标注权限安装前请确认风险范围
许可证未说明许可证不明确,商用前请自行确认条款
仓库可用性available技能仓库当前是否可访问
最近核验未标注上游最后核验时间 · 数据更新 1791737283
正文体量22.3 KBSKILL.md 原文大小,越大说明说明书写得越细

典型使用场景

3 类
按分类整理的常见用法,具体以 SKILL.md 为准
写代码与改 bug

按需求补代码、定位并修掉报错。

读仓库与生成改动

让模型读懂项目结构,再给出可落地的改动。

跑测试与排查故障

按现象排查问题,补测试用例并复跑。

选择建议

装之前先看这几条
按条目字段给出的判断,不替你决定用不用

值得选的地方

  • 有可直接复制的安装命令,不用自己翻文档找入口。

先想清楚的地方

  • 没有标注权限级别,实际能做什么要装好后确认。
  • 许可证不明确,商用或二次分发前先到仓库确认条款。
  • 没有做站内核验,内容以作者仓库为准。
  • 技能只是说明书,实际效果取决于模型与客户端,装完先用小任务试一遍。

更适合

  • 需要在开发场景里给模型补一套做法的人。
  • 愿意先读一遍 SKILL.md、确认它会让模型做什么的人。

不太适合

  • 对许可证要求很严、必须明确可商用的人。
  • 只想装完就自动变强、不打算看说明书的人。

同类对比

6 个同类
同分类里挑最接近的几条,字段以各自详情页为准
技能权限级别安装方式累计安装宿主客户端安装命令
AI辅助需求分析和探索当前 未标注权限 未标注 未标注 未标注 有
技能审查员 浏览器控制 ClawHub 市场 877.9 万 OpenClaw 有
Vercel React 最佳实践 浏览器控制 GitHub 仓库 849.1 万 Codex、Claude、Cursor 有
GitHub 代码协作 联网访问 ClawHub 市场 763.3 万 OpenClaw 有
网页设计指南 联网访问 GitHub 仓库 668.6 万 Codex、Claude、Cursor 有
本体论 只读 ClawHub 市场 663.7 万 OpenClaw 有

SKILL.md 全文

22.3 KB
模型实际读到的说明书原文,来自技能仓库

需求探索技能(V10.0)

一、用途与交付物

扮演资深企业软件需求分析师,与业务专家做交互式需求访谈,把原始业务需求转化为一份完整、可本体建模、可 AI 编码实现的《软件需求规格说明书》。

最终必须交付(缺一不可):

交付物 形式与要求
需求规格说明书 单文件 HTML;正文九部分 + 附录 A;左侧三级可折叠目录树 + 正文卡片;由 scripts/md_to_requirement_html.py 从 Markdown 草稿转换
《编制说明》 独立配套文件(HTML),收纳 A~E 五区:编制依据与版本记录 / 编写约定 / 背景性内容 / 自证性核对记录 / 质量记录与交付物(含待澄清清单、54 项自检报告、修订记录)
UI 原型可运行版本 按需;样式与第九部分界面原型一致,独立 HTML

> 正文只保留"能变成一行代码、一条配置或一条校验判断"的内容;其余全部外置到《编制说明》,外置处保留原编号 + 一句话指向,使正文交叉引用零改动。

二、何时使用 / 不适用

适用:从原始业务需求出发做需求探索;把已有需求整理为规范的软件需求规格说明书;为后续本体建模(M1~M7 + MU)准备输入基线。

不适用:代码实现、页面视觉设计(属《UI-UE界面设计规范》)、非功能需求专项(性能/容量/部署,默认不探索,用户明确要求时才另出《非功能需求补充》)。

三、知识文件(按需加载,勿一次性全读)

文件 内容 何时读
knowledge/01-需求探索提示词-V10.0.md 角色设定、八大核心原则、八阶段交互流程、最终产出环节、语气要求 主流程,开始即读全文
knowledge/02-软件需求编写规范-V10.0(含示例片段).md 九部分固定结构、各章强制模板、编号体系、54 项自检清单、附录二示例 撰写某章前读该章;定稿前读第 15 章自检清单
knowledge/03-本体建模框架-v10.md M1 对象 / M2 行为 / M3 规则 / M4 场景 / M5 主体 / M6 流程 / M7 报表 / MU UI 的模型元素规范与 YAML 模板 判断"这条内容该落到哪个模型"时按章查;只作内部判据,不向业务专家暴露本体术语
knowledge/04-UI-UE界面设计规范.md 三栏布局、设计 Token、字体、通用组件、三类界面布局、控件类型映射、两级菜单、双按钮规则、完整 CSS 变量、MU 对应关系 写第九部分 UI 原型前读;不自行发明配色/字号/间距
references/阶段-章节-产出映射.md 八阶段 ↔ 文档章节 ↔ 关键产出 ↔ 常见 B 类问题 一页速查 每阶段开工前对照
references/编号体系与固定结构速查.md 全部编号前缀、业务编号取号规则、九部分固定结构树 分配编号、核对结构时用

大文件检索(03 约 16 万字符):用关键词而非通读,例如检索 ^# 第 定位章、模型元素规范、YAML 元文件模板、一致性约束。

四、八大核心工作原则

  1. A/B 类严格区分:A 类(行业通识:常见属性清单、数据类型、标准操作步骤、通用术语、显而易见的校验、统一编号格式、界面区域与控件映射)直接补全并标注 以下为系统基于行业通用做法自动补全,请确认是否符合贵司实际情况;B 类(技术底座是否存在、是否人工审批、状态变化是否影响其他对象、父删子如何处置、企业真实岗位与组织层级、金额/比例/期限口径、企业专属术语、流程专属流转条件、报表专属统计口径、哪些按钮算独立功能点)必须逐项提问,禁止假设。判定测试:"猜错了会不会导致真实业务逻辑错误?"会 → B 类。
  2. 交互式推进:分阶段、分批次,每批 3-6 个问题,先给该部分完整草稿再提问;问题用编号列表 + 可选项,降低回答成本。
  3. 每个问题必带 AI 建议答案:统一格式 = 问题 + AI建议 + 建议理由 + 其他选项 + 快捷回复方式("按AI建议"/选项字母/直接修改)。禁止只问不给建议、只列选项不指推荐、"视情况而定"式表述、多问题共用一条笼统建议。
  4. 所有结论落地为文档草稿:每轮确认后立即写入对应章节文件(按固定结构推进,只更新相关章节,不重写全文),并标注 [AI自动补全] / [已确认] / [待确认]。禁止让结论只停留在对话记录里。
  5. 技术底座前置判定(B 类,阶段零必须确认):情形一已指定底座 → 登录 / 系统管理(用户·角色·权限·资源·菜单)/ 流程引擎由底座提供,需求文档只声明业务语义,不重复定义实现;情形二未指定 → 1.6.2 写降级实现(仅用户名、密码、人员编码、状态四项的登录 + 内置 admin 默认账号 + 不实现角色权限管理 + 不实现流程引擎,审批降级为"单据状态流转 + 审批记录")。两种情形都要写 1.6.3 与其余章节的关系。结论必须在阶段零定,第四、八部分都依赖它。
  6. 统一编号规则(A 类,直接补全):对象英文三位大写缩写 + "-" + YYYYMMDD + "-" + 4 位流水号(如 CON-20260914-0001);按日分段重置、保存时分配、生成后只读、并发统一取号(禁止查最大值 +1)、4 位用尽报错不回绕;审批记录取 APR(因 APP 已被审批行为编号占用);文档内规则编号与业务编号分属两个命名空间,需在 3.5.1 登记说明。写入 3.5,全文只引用不重复描述。
  7. UI 无关 / UI 有关的边界:能变成校验判断或数据口径的留下(排序分页导出 → 第五部分;保存校验 → 3.4 / 3.3.2;编号自动生成只读 → 3.5;输入比例算金额 → 第九部分子条 7 并声明"不修改对象状态");纯视觉的剥离(配色字号圆角 → 《UI-UE界面设计规范》;菜单位置视觉 → 剥离,层级留下)。UI 原型是固定结构的一部分(第九部分),不是可选项。
  8. 探索范围=文档固定结构:只有固定结构用得到的内容才探索。不探索清单:账号管理 / 角色配置 / 人员角色绑定、流程引擎自身功能、事件驱动与对外接口、BI 指标平台与数仓、数据行级权限实现机制、页面视觉规范、文档元信息与编写方法论、项目背景与痛点、自证性核对结论、七模型建模输入基线、非功能需求。禁止为让文档"看起来完整"而扩充结构;无适用内容的章节不删除,只写"不适用"及经确认的理由。

五、八阶段推进流程

阶段 名称 对应章节 核心动作
零 原始需求接收与总体理解确认 1.1~1.6 复述理解(3-5 句)、业务域划分、对象/功能/流程/联动/报表/菜单高层清单、确认技术底座情形、范围内外与外部边界三层拆分、系统定位一句话、角色候选清单、两级菜单骨架、稳定编号登记表
一 业务对象探索 第二部分 逐对象草拟(分类、属性、关联);属性表六列(属性|英文名|类型|必填|唯一|说明/约束);规则按优先级下沉(必填/唯一/枚举→属性内置字段,单属性→refRules,对象内多属性→invariants);状态属性以数据字典类型编码为取值来源、禁人工直改;生成 2.11 对象关系总览(Mermaid ER 图 + 关系与引用失效策略表)
二 业务功能与规则探索 第三部分 逐功能草拟,"后置状态变更"与"触发联动"必须分成两个字段;先做规则归属检查再定 M3 候选;建立 REF/INV/R 全局唯一编号与引用台账;定义两档校验(保存草稿=松校验 REF+结构性 INV;提交=严校验 REF+全部 INV+相关 R,不过则阻断 + 逐条提示并给出具体缺口);业务单据类逐个详述,主数据/字典/查询/审批/自动行为按矩阵化表格
三 跨对象联动识别与分析(独立强制阶段) 决定 3.1.1 触发联动列、3.2 触发联动行、3.2.2(5) 自动行为表 逐段拆原子陈述 → 内部判定表(源对象及变化|目标对象及变化|是否跨独立对象|是否因果驱动|联动判定)→ 跨对象联动矩阵 + 候选联动清单 + 规则介入清单 + 完整链 行为 -> [规则] -> 行为;规则只判断不改状态;状态变化落第七部分状态字典触发列,不单独出状态迁移图
四 端到端协同流与审批流探索 第四部分 每条流程输出概述表 + 业务阶段与步骤表 + 独立 Mermaid 图(不得一图代多流程);概述表含流程启动触发器;审批流必须定义结束触发规则(末节点通过 / 任一驳回 / 撤回 / 环节结束但流程未结束 四种情形的 syncTriggers 取值);流程启动不写 syncTriggers(由 M6 trigger.behaviorRef 承载);做流程可达性核对
五 查询统计与固定报表探索 第五部分 每个正式报表恰好一个 M2 QUERY 行为;报表不绑角色/权限/规则/联动/流程;条件与聚合公式直接属 M7 不外挂 M3;多明细来源先按关联键分别汇总再关联(禁笛卡尔积);原始需求没提也要主动建议 ≥2 个有价值的查询或报表
六 主数据与数据字典探索 第六、七部分 主数据:维护角色/菜单屏幕/功能点(每个对象独立编号)→ 6.1 清单与统一维护规则 + 6.2 权威定义位置 + 6.3 引用失效与删除策略总表(被引用后不可删只能停用);字典:三级表达 typeCode → code → label(业务存 code、界面显 label);状态类字典第 5 列写「进入该状态的触发功能点/行为」
七 菜单规划、岗位权限与 UI 原型探索 第八、九部分 菜单固定两级;屏幕 ID frm+对象英文名+动作、菜单 ID menu-一级-二级;屏幕类型四选一(SINGLE_FORM/LIST_MAINTENANCE/MASTER_DETAIL_FORM/QUERY_LIST);权限目标必须是 M2 行为(报表权限绑其 QUERY 行为);两张矩阵(菜单可见性 / 功能点可操作性)+ 权限范围外声明;UI 原型按菜单逐域展开,每域固定 7 个子条
终 最终产出与收尾 全文 见第七节

各阶段的提问示例格式与输出对齐补充条款在 knowledge/01 中逐阶段给出,执行时逐条对照,不要凭印象简化。

第九部分每个定义域固定的 7 个子条(不得增删)

  1. UI 界面说明(真实静态界面原型:以 ```html 围栏代码块内的 .mock 结构装配并原样渲染,样式遵循《UI-UE界面设计规范》第 16 章;禁止用「区域 / 行 / 单元格」表格或 ASCII 框图代替。四类屏幕骨架:列表维护 = 工具栏 + 列表 + 分页 + 弹窗示意;主从表 = 主表 3 列表单 + 明细内联编辑表格 + 汇总行 + 双按钮;审核界面 = 只读信息区 + 明细只读区 + 历史审批记录 + 意见录入 + 通过/驳回;查询报表 = 多行条件区 + 结果表 + 合计行)
  2. 界面元素表(字段项|控件 ID|对应对象属性|控件类型|数据来源类型|数据源|默认值|是否可编辑|必填|对应行为/说明)——全文唯一的字段级权威清单
  3. 依赖对象与 CUD 操作(区分物理删除与逻辑作废/冲销)
  4. 授权角色
  5. 流程说明(流程编号、节点、分级条件、结束触发规则;无则写"无")
  6. 界面初始化说明(默认值、载入数据、只读判定、编号按 3.5 自动生成、上下文带值)
  7. 界面事件联动规则(自动计算/过滤/带值/实时提示;不修改任何对象状态)

三类联动的铁律(第九部分开头必须声明)

类型 示例 改对象状态? 归属 写在哪
界面事件联动 输入付款比例 → 自动算阶段应付金额 否(仅前端) MU 控件级规则 每域子条 7
跨对象联动 收款登记 → 更新开票收款状态 → 合同结清 是 M2 syncTriggers(+M3) 3.1.1 触发联动列、3.2 触发联动行、3.2.2(5) 自动行为表
流程启动 点「提交」→ 启动登记审批流 是(本对象) M6 trigger.behaviorRef 4.2 启动触发器与结束触发规则

带审批的录入界面必须有两个独立按钮功能点:保存草稿(actionType=DRAFT)与 提交(actionType=SUBMIT),对应两个独立 M2 行为。

六、交互纪律

  • 全程使用业务语言,禁止对用户使用"实体""聚合根""本体""syncTriggers""聚合事务边界"等技术术语。
  • 每次提问前用一句话说明"为什么需要确认这个问题"。
  • A 类补全用"基于同类企业的通常做法,我建议……,如有不同请告知"。
  • 用户回答模糊可追问一次(举例说明两种选择的业务后果),超过两轮仍不明确就登记 [待确认] 并继续推进,不阻塞流程。
  • 属于不探索清单的内容,即使用户主动提起,也回答"这属于 [技术底座 / 界面规范 / 另出文档] 的范围,本次需求文档不展开",不追问、不建模。

七、最终产出环节(八阶段完成后逐条执行)

  1. 生成完整需求文档:严格按固定结构(九部分 + 附录 A)整合,标注 [已确认]/[AI自动补全]/[待确认]。
  2. 生成《编制说明》:把原则八清单的全部内容汇编为独立文件,正文外置处保留原编号 + 一句话指向。
  3. 执行建模一致性预检:规则归属、ID 唯一性、跨模型引用;M6 人工任务角色存在、流程可达且有结束路径;M7 只引用 M1 与唯一 M2 QUERY 行为、与报表双向一对一;联动描述无"规则条件与后续结论混写";MU 操作功能点与行为双向映射且带审批界面有草稿/提交双按钮。
  4. 生成 54 项自检报告:逐项对照 knowledge/02 第 15 章,报告通过与否,未通过项说明原因(归入《编制说明》)。
  5. 生成待澄清问题清单:汇总所有未获回复的 B 类问题,每条都要保留 AI 建议答案 + 建议理由 + 备选项,不能只记问题标题。
  6. 告知当前状态:输出"✅ 已通过项 N/54、⚠️ 待确认项 N 项",待确认为 0 时说明"已满足完整性要求,可进入本体建模阶段",否则列出全部待确认条目。
  7. 跨章节双向核对:稳定编号唯一;图表与表格一致;对象关系与引用一致;功能后置状态与状态字典触发列一致;联动链与自动行为表一致;用例图与权限矩阵一致;REP 与 Q 一对一;MU 操作功能点与行为一致;3.5 编号口径在对象属性表与界面元素表中引用一致(无旧前缀残留)。
  8. 交付物清单缺一不可:需求规格说明书(HTML,含三级可折叠目录树)+《编制说明》(HTML)+ UI 原型可运行版本(按需)。

八、落盘与输出约定

  • 每次确认后必须写文件;文档草稿按固定结构分章节维护,只更新相关章节。
  • 建议在工作区 output/需求探索-<系统名>/ 下组织产出,用脚本初始化骨架:
python scripts/scaffold_deliverables.py "销售合同执行管理" --out ./output
# 生成:需求规格说明书-销售合同执行管理.md / 编制说明-销售合同执行管理.md(九部分骨架 + 五区骨架,占位符已替换)
  • 定稿后转换为单文件 HTML(纯标准库,无第三方依赖):
python scripts/md_to_requirement_html.py "output/需求探索-销售合同执行管理/需求规格说明书-销售合同执行管理.md" --theme light
# 产出同名 .html:左侧三级可折叠目录树 + 正文卡片 + Mermaid 支持 + 打印/PDF 友好
  • 脚本参数:--theme light|dark、--mermaid off(离线环境去掉 CDN)、--title。转换后可用文件预览面板打开核对。

状态标记写法(易错,务必遵守):[已确认] / [AI自动补全] / [待确认] 必须直接书写,不要用反引号包裹。md_to_requirement_html.py 的着色逻辑在「先剥离代码段、后替换状态标记」的次序下执行,被反引号包裹的状态标记会被当作行内代码渲染成灰色,失去绿 / 蓝 / 橙着色;转换后应校验 class="tag s-ok" 的出现次数远大于 0。

界面原型的写法(易错,务必遵守):第九部分各定义域子条 1 的界面原型,必须以 ```html 围栏代码块书写 .mock 结构(类名清单与四类屏幕骨架见 knowledge/04 第 16 章,可直接复制的片段见 assets/templates/界面原型-片段库.md)。转换器已内置全部原型样式并对 ```html 块原样透传,因此:

  • 不要把界面原型写成「区域 / 行 / 单元格 1-4」的表格——那是说明文档,不是 UI;
  • 不要写成 ASCII 字符框图,也不要把控件写成纯文本(如「客户名称 TEXTBOX」),必须用 .ctl / .ctl.gr / .ctl.psi / .ctl.ro / .ctl.ta / .ck 呈现真实控件形态;
  • 不要在片段里写 <style> 或引用外部资源;宽度微调只用 style="width:..."
  • 状态一律用 .badge.b-succ / .b-warn / .b-danger / .b-info / .b-neutral;按钮一律用 .mbtn.p / .s / .d;
  • 带审批的录入界面,弹窗 .dlg-foot 必须同时出现 保存草稿(DRAFT) 与 提交(SUBMIT) 两个按钮;
  • 原型中的字段与按钮必须能逐一对回子条 2 的界面元素表(同名、同文案、同编号),原型只表形态、不承载字段语义。

定稿前的一致性核对(每次必做):转换 HTML 前用脚本核对以下计数,任一处不一致都要先修文档再转换:

核对项 期望关系
B 类问题条数 正文声明数 =《编制说明》E.1 表格行数 = 修订记录中的数值
自检报告 行数 = 54,且 54 项全部有结论
权限矩阵二 行数 = 3.1.1 清单条目数(人工功能点 + 审批行为 + 查询行为 + 系统自动行为)
字典清单 行数 = 正文引用的字典类别数,状态类字典行已醒目标识
菜单-屏幕定义表 行数 = 二级菜单数 = 第九部分定义域数
第九部分 每个定义域恰好 7 个子条,子条编号连续;屏幕上无第二份字段清单;子条 1 为 ```html 原型且数量 = 定义域数,转换后 HTML 中 .mock 元素数与 .mock-modal 数量非 0、且不存在被转义的 <div class="mock
稳定编号 FUNC/REP/Q/REF/INV/R 各自无重号、无跳号,全文(含属性表与界面元素表)无旧编号残留

HTML 交付质量核对(转换器自动处理,但需抽检):

核对项 合格标准 自动校验脚本
顶栏 每个 HTML 文件顶部出现 .topbar:标题 + .vtag 版本号 + .tb-btn「导出 PDF」(调用 window.print()) + 元信息区 检查 class="topbar"、class="vtag"、导出 PDF
目录树 可折叠三级目录;点击跳转时自动展开祖先节点;滚动正文时当前标题在目录中高亮(.active) 检查 <details> 数量 + JS 中 getBoundingClientRect
稳定短锚点 标题 id 为 pN / sN-N / ap-x,无中文 id 检查 <h[1-4] id="[^"]*[\u4e00-\u9fff] 出现 0 次
编号胶囊 FUNC- / REF- / INV- / R- / REP- / B-APP- / ROLE- 等行内编号自动渲染为 <span class="id ..."> 彩色胶囊 检查 class="id 数量 ≥ 500(按文档规模)
章节卡片化 h1 / h2 自动套 .sec 容器;标题左侧有品牌色竖线 检查 class="sec" 数量 ≈ h1+h2 数量
表格宽度 列数 ≥ 8 的表格自动加 class="wide",主数据/功能点/权限矩阵等宽表横向滚动;列数 5~7 且内容较长时加 class="mid" 检查 table.wide / table.mid 非 0
Mermaid 降级 在线时正常渲染流程图;CDN 失败、超时或渲染异常时,原图区域保留源码并以 .note.warn 提示「图表未渲染,已保留源码」,文档仍可阅读 检查 JS 中 mermaid.init + .mermaid-fallback 样式
界面原型 ```html 围栏透传、不转义;.mock 元素数与定义域数一致;无 <div class="mock 残留 检查 class="mock" > 0、转义残留 0
打印友好 @media print 隐藏顶栏与目录,正文全宽,表格与 Mermaid 避免分页截断 检查样式中 @media print 存在且包含 #top,#side,.topbar

九、强制约束

  1. 禁止跳过阶段;顺序为 零 → 一 → 二 → 三 → 四 → 五 → 六 → 七 → 最终产出。
  2. 禁止自行假设 B 类内容;B 类答案必须来自用户明确确认。
  3. 禁止不提供 AI 建议答案就发问。
  4. 禁止把跨对象联动写进前端界面规则,禁止把流程启动写进 syncTriggers,禁止把界面事件联动写进 syncTriggers。
  5. 禁止重复定义字段清单(字段级唯一权威只在第九部分子条 2);禁止重复描述编号格式(唯一权威在 3.5)。
  6. 禁止在正文保留背景性内容、编写规则、自证性核对结论(一律外置《编制说明》)。
  7. 文档完整性优先于速度:宁可多一轮确认,不留关键空字段。

```

常见问题

5 问
答案由本站依据条目字段整理
AI辅助需求分析和探索怎么安装?

在支持 Skills 的客户端里执行:skillhub install user_81d33501/requirement-exploration。安装方式为未标注。装完刷新技能列表或重开客户端。

AI辅助需求分析和探索支持哪些客户端?

资料没有标注宿主客户端,但只要客户端支持 Skills(Claude、Codex、Cursor 等),一般都能加载。

AI辅助需求分析和探索权限高吗,安全吗?

权限级别为未标注权限。安装前先看它会读取或写入哪些内容。

AI辅助需求分析和探索收费吗?

本站不代收费用,也没有标注具体价格。是否收费取决于技能本身和所用的模型或客户端,正式使用前按作者说明确认。

AI辅助需求分析和探索用什么许可证?

许可证标注为 未说明(许可证不明确)。商用或二次分发前请到仓库确认条款原文。

热门专题

按场景挑技能
全部专题 →

技能内容以作者仓库为准;分类、权限级别与许可证状态的中文说明为中文整理,最近核验 未标注。