# Ohos Req Feasibility Analysis

> OHOS 可行性分析

- Skill: `openharmonyinsight/ohos-req-feasibility-analysis` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add openharmonyinsight/ohos-req-feasibility-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/openharmonyinsight/ohos-req-feasibility-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: openharmonyinsight (https://skillmd.com/u/openharmonyinsight)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/openharmonyinsight/ohos-req-feasibility-analysis

---


# OHOS 可行性分析

**Announce at start:** "我正在使用 ohos-req-feasibility-analysis skill 生成 02-feasibility.md。"

## 定位

OHOS 代码证据包（kb_precheck_path）是 feasibility 的独立于用户设计方案的源码级验证——PIR #13 已证明"基于 PRD+竞品就做决策"会导致 ADR 被源码复核后推翻。feasibility 禁止选型推荐，选型决策 exclusively 属于 03-arch-decision-record.md，由用户提供。工作量估算标准固定为 500 行≈1 人月，跨所有 OHOS 领域统一。

## 输入

- `{docs_dir}/01-requirement.md`
- `{docs_dir}/_draft/feasibility-inputs.md`（Step 0.1.8 用户提供或确认不提供的本地关键代码仓路径、接口文档和前置依赖资料记录）
- 代码证据包：`{kb_precheck_path}`（由 `ohos-req-intake-orchestration` Step 0.1.9 轻量代码预检产出；未产出时按本 skill Fallback 规则降级）
- 可用的源码、架构文档、Owner 结论、竞品或 PoC 证据

## 前置输入契约

启动提醒、建议补充资料清单推导和用户确认动作由 `ohos-req-intake-orchestration` Step 0.1.8 统一定义和执行（参见 ohos-req-intake-orchestration SKILL.md），本 skill 不重复维护规则。

生成 `02-feasibility.md` 前必须满足：
- `{docs_dir}/_draft/feasibility-inputs.md` 已存在。
- 文件中记录了用户提供资料，或用户明确确认不额外提供本地关键代码仓/接口文档/Owner 结论/前置依赖资料。
- 如用户确认不额外提供或资料不可访问，`02-feasibility.md` 必须按证据受限口径标注，不得写成源码已验证或接口已确认。

## 自省提示（Mindset Prompts）

在执行关键步骤前，自问以下问题：

- **Before estimating effort, ask yourself:** 我是否已为每个候选方案独立估算工作量，还是只给了一个总量？
- **Before marking evidence as '待Phase2验证', ask yourself:** 我是否真的尝试过用 Read 工具查找证据，还是过早放弃了？
- **Before writing a GAP analysis, ask yourself:** 我是否包含了接口签名和调用链路，还是只列了 file:line 引用？

## 流程（两阶段：草稿 → 澄清 → 定稿）

## 模板与产物命名

- 模板路径：`reference/feasibility.md`（模板文件不带 `02-` 阶段编号前缀）
- 产物路径：`{docs_dir}/02-feasibility.md`

### 第一阶段：草稿生成

1. 读取 `reference/feasibility.md` 和需求事实。
2. 读取 `{docs_dir}/_draft/feasibility-inputs.md`，确认用户已提供资料或明确确认不提供额外资料。
3. 确认评估范围与产品范围、FR/NFR 一致。
4. **候选路径分析**（含代码证据、子能力、可视化、估算四个子步骤）：
   - **4a 代码证据分析**：读取 `{kb_precheck_path}` 和用户提供的本地关键代码仓路径/文档/Owner 结论，提取关键接口、类、调用链，为候选路径提供代码级证据，将关键代码仓库分析写入 §2 技术可行性下的 §2.1「关键代码仓库分析」表（模板外补充子节：仓库/模块/路径/关键接口/影响类型/证据来源），供 `ohos-req-feature-baseline` §4 模块覆盖完整性校验引用。证据包和用户资料均未覆盖的接口/路径标记"证据受限，待 Phase 2 代码分析验证"，不得虚构。
   - **4b 子能力拆分**：识别是否存在多个可独立交付、独立验证或依赖不同系统能力的子能力；若存在，必须先按子能力分别评估价值、现有能力差距、候选路径、兼容性、安全、性能和依赖，再给出组合路径判断。不得只用一个整体方案掩盖子能力差异。
   - **4c 可视化方案图**：为每个候选路径绘制：
     - 流程图（Mermaid flowchart）：展示数据流转路径和模块交互顺序
     - 类图（Mermaid classDiagram）：展示新增/扩展的关键类及接口签名
     - 时序图（Mermaid sequenceDiagram）：展示跨进程/跨模块的 IPC 调用链路
   - **4d 工作量估算**：按统一评估标准折算端到端工作量，**每个候选方案必须独立给出工作量估算**，不允许只给单一总量：
     - 开发工作量：500 行代码 ≈ 1 人月（★ 本 skill 统一估算标准，后续章节引用此处）
     - 测试工作量：开发 × 0.3
     - 设计工作量：开发 × 0.1
     - UX 工作量（仅涉及 UX 时额外追加）：开发 × 0.1
     - 端到端合计 = 开发 + 测试 + 设计 + UX（如有）
     - **必须输出"各方案工作量对比汇总"表**，供 03-arch-decision-record.md 方案对比使用
5. 为风险和未知项指定验证动作、Owner、关闭时点和阻塞性。
6. 给出每个方案的可行、有条件可行、待证据或不可行判断（见强制规则"禁止选型推荐"）。
7. 不生成 ROI 章节（详见 NEVER §禁止生成ROI）。
8. 输出草稿到 `{docs_dir}/02-feasibility.md`（frontmatter `status: Draft-NeedsClarification`）。
9. 同时输出澄清问题清单到 `{docs_dir}/_draft/feasibility-clarification-questions.md`。

### 第二阶段：逐轮人工澄清 ⭐ 强制门禁

**草稿生成后，必须暂停并进入逐轮澄清对话。不允许直接进入 decision。**

澄清规则：

1. 主 Session 将「待澄清问题清单」逐条向用户提问
2. 每轮提问 ≤5 个问题（按对决策影响优先级排序）
3. **批量确认已知答案**：对需求文档或设计方案中已有明确答案的问题，一次性呈现全部已知答案让用户**批量确认**（✅确认/✏️修正），不逐条单独交互。仅真正不确定的问题才逐条澄清。
4. 用户回答后，更新 feasibility.md 对应章节（替换为确认事实）
5. 每轮澄清后检查：
   - 是否产生新的待澄清项？→ 继续下一轮
   - 是否所有字段都有确认事实？→ 进入定稿检查
6. 澄清完成后执行定稿检查：

**定稿检查清单（全部 ✅ 才可进入 decision）：**

- [ ] 目标与范围边界已明确
- [ ] feasibility-inputs.md 已存在且用户已确认（提供资料或明确不提供）
- [ ] 证据受限项已显式标注（不得写成源码已验证或接口已确认）
- [ ] 多子能力时按子能力分别分析候选路径、工作量、风险和可行性
- [ ] **代码分析分支判定**（二选一，满足其一即可）：
  - **源码级场景**（代码仓可访问或预检证据包已覆盖）：代码分析已完成（关键模块、接口、依赖已检索），技术可行性基于实际代码评估
  - **证据受限场景**（用户确认不额外提供资料或代码仓不可访问）：① 证据免责声明已在文档中显式标注（"证据受限，待 Phase 2 验证"）；② 未验证接口/路径清单完整（逐条列出）；③ 每条未验证项有 Owner、验证动作和 Phase 2 关闭时点；满足后允许以条件状态（`status: Conditional`）完成，不得标记为源码已验证
- [ ] 竞品参考有具体做法和可借鉴点，且每条竞品有来源链接（无链接视为不可信）
- [ ] 工作量估算有代码行数依据（见 Step 4d 估算标准），且每个方案独立估算
- [ ] 各方案工作量对比汇总表完整
- [ ] 收益量化优先
- [ ] 风险矩阵覆盖关键风险
- [ ] 结论与数据一致
- [ ] 无 ROI 章节（详见 NEVER §禁止生成ROI）
- [ ] 未包含选型推荐内容（详见 NEVER §1）
- [ ] 结论章节为各方案可行性判断表，不含选定方案
- [ ] 不含自审清单（详见 NEVER §禁止自审清单写入文档）

**任何一项不通过 → 继续澄清，不允许进入 decision。**

7. 定稿检查全部通过后，更新 frontmatter `status: Clarified`，输出最终版。

### 澄清状态检测

当用户提供的输入材料已包含澄清结论时，skill 应：
1. 检测输入材料中的澄清状态标记或澄清结论覆盖度
2. 若已澄清完成且覆盖所有必填字段，只做格式归一化和定稿检查
3. 若定稿检查通过，直接输出 `status: Clarified`，跳过逐轮对话
4. 在回传摘要中标注"澄清状态: 已完成/需补充/无标记"

## 强制规则

> **加载策略（Progressive Disclosure）**：本节保留 5 条顶层不变式（核心红线，始终生效）。生成 `02-feasibility.md` §2-§6 各章节时的详细判定口径（证据约束/单方案降级/锚点链接/竞品链接/Mermaid/GAP/工作量标准等 11 类细则）见 [`reference/feasibility-rules.md`](reference/feasibility-rules.md)，**在第一阶草稿生成步骤按需加载**。

**顶层不变式（始终生效，违反即阻断）：**

1. **证据为本**：技术判断必须有源码、文档、PoC 或 Owner 证据，否则标记待验证；代码事实验证优先用 `{kb_precheck_path}` 证据包，未覆盖标记"待 Phase 2 验证"，Read 不可用降级为 `warn` 不硬 fail（详见 reference §1）。
2. **启动前软前置确认**：必须存在 `{docs_dir}/_draft/feasibility-inputs.md` 且记录用户资料或明确不提供，未完成不得生成 `02-feasibility.md`（详见 reference §2）。
3. **禁止选型推荐**：不允许"推荐/最优/建议选择"等决策倾向性表述，只给可行性判断（✅/⚠️/❌），选型决策属 03-arch-decision-record.md（详见 NEVER §1）。
4. **按方案独立估算工作量**：每个候选方案独立给代码行数+人月折算，必须输出"各方案工作量对比汇总"表，统一标准 500行≈1人月（详见 reference §6）。
5. **多子能力分开分析**：多个独立子能力时按子能力分别输出候选路径/依赖/工作量/风险/可行性，工作量表和风险表带子能力归属（详见 reference §7）。

> 以下细则按章节加载 `reference/feasibility-rules.md` 对应小节：§6 结论填写约束与锚点链接(§8) · 性能/竞品链接出处(§9) · Mermaid 可视化与 GAP 接口签名(§10) · ROI/自审清单禁令(§11) · 单方案降级(§4) · 证据受限标注(§3)。

## NEVER

1. **禁止选型推荐**：feasibility 不允许出现"推荐"列、"建议选择XX方案"、"XX方案最优"等决策倾向性表述。方案选型决策 exclusively 属于 03-arch-decision-record.md，由用户提供。每个方案只给出可行性判断（✅可行/⚠️有条件可行/❌不可行）和事实依据，不做推荐排序。
2. **禁止生成 ROI 章节**：模板已去除 ROI 分析章节，只保留收益量化（原因：虚构的接口/路径在 Phase 2 代码分析阶段被证伪，导致 feasibility 结论失效需返工）
3. **禁止虚构代码证据**：证据包和用户资料未覆盖的接口/路径必须标注"证据受限，待 Phase 2 验证"（原因：电子流系统将"源码已验证"的需求直接进入分析阶段，标注不足会导致未经源码验证的需求被误判为已确认）
4. **禁止硬 fail 单方案**：客观上只有一条可行路径时允许单方案，标注 warn 并写明不可行证据（原因：禁止硬 fail 单方案避免迫使 AI 虚构垃圾方案凑数，单方案场景需标注 warn 并写明不可行证据）
5. **禁止自审清单写入文档**：自审结果输出到控制台回传摘要（原因：选型决策 exclusively 属于 03-arch-decision-record.md，由用户提供；feasibility 提前选型会跳过用户决策门禁）
6. **禁止无出处竞品引用**：无来源链接的竞品记录视为不可信证据，不得作为可行性判断依据

## 输出

- 路径：`{docs_dir}/02-feasibility.md`（`status: Clarified`）
- 澄清问题清单：`{docs_dir}/_draft/feasibility-clarification-questions.md`（澄清完成后保留，每个问题必须回填 `**澄清结论**`段）
- 回传：路径、各方案可行性判断、候选路径数量、各方案工作量（代码行数+端到端人月）、高风险项、阻塞条件、自审检查结果