rd-feasibility git:20260807.e82ae86A

Immutable. This exact content never changes and is served at /api/v1/blob/1bf8e668fc113df5.

---
name: rd-feasibility
description: >-
  评估项目、产品、开源组件、AI 工具、基础设施变更或候选方案是否可行，并形成
  面向决策的可行性结论。当承诺投入前需要综合比较技术、经济、进度、运行、安全、
  合规和风险证据时使用。需求、设计、独立评审和执行分别路由到其责任工作流。
---

# rd-feasibility

产出**可支撑决策的可研报告 / 可行性分析报告**，明确区分事实、假设、估算和待核实事项。

## 交付物

- 可研报告 / 可行性分析报告
- 可行性对比矩阵
- 结论：可行 / 有条件可行 / 不可行
- 风险登记表及缓解、核验动作

## 执行步骤

### 1. 研究范围确认

- 明确决策问题：要判断什么是否可行
- 明确读者：决策层、立项评审委员会、甲方评审、技术负责人
- 确认输入：PRD、会议纪要、既有系统文档、标准、政策、预算、周期
- 评估前先区分事实和假设

**完成标准：** 决策问题、比较范围、受众、来源集合、事实、假设和证据缺口均已明确。

### 2. 可行性维度

按以下维度评估项目或方案：

| 维度 | 检查内容 |
|------|----------|
| 必要性 | 问题价值、政策/业务驱动、干系人需求 |
| 技术可行性 | 技术成熟度、兼容性、集成约束、数据可得性、架构适配 |
| 经济可行性 | 预算、全生命周期成本、许可、人员、采购 |
| 进度可行性 | 里程碑、依赖关系、评审周期、交付风险 |
| 运行可行性 | 可安装性、可维护性、人员配置、流程适配、培训、支持和回退 |
| 安全与合规 | 法规、标准、隐私、供应链暴露、安全控制、可审计性 |
| 可持续性 | 上游维护、发布节奏、许可、厂商或社区依赖、退出路径 |
| 风险可行性 | 高风险假设、外部依赖、失败模式、替代路径 |

**完成标准：** 每个重要维度均依据证据完成评价，或说明理由后明确排除；未覆盖维度不得被静默视为有利。

### 3. 候选方案

- 存在真实选择时至少比较 2 个方案
- 适用时包含“维持现状”作为基线方案
- 详细比较前先说明被排除方案及排除理由
- 不把单一偏好方案包装成唯一可行方案

**完成标准：** 每个真实候选方案和相关现状基线均按共同准则比较，或有明确记录的排除依据。

### 4. 证据与估算纪律

- 事实性结论、时效性资料、标准、政策、市场或成本数据必须标注来源
- 区分可检索事实和责任人决策，并记录每项已接受条件或风险的决策权限
- 估算必须标注为估算，并说明估算依据
- 精确数据不可得时，用范围和敏感性分析替代伪精确数字
- 对无法证实的假设单独列出核验方法
- 对开源或 AI 工具选型，区分仓库活跃度与可维护性、演示与可复现能力、模型能力与产品/系统能力

**完成标准：** 每项影响决策的事实、估算和假设均可追踪到来源或估算依据；否则附验证动作，并明确其对置信度的影响。

### 5. 结论与决策建议

- 明确给出：可行 / 有条件可行 / 不可行
- 标注置信度：高 / 中 / 低
- 说明继续推进的最低条件
- 列出阻塞问题、开放问题和下一步建议

**完成标准：** 结论、置信度、推进条件、阻塞项、剩余风险和后续验证动作均来自比较结果，而非偏好。

## 上下文与基线检查

执行前检查：

- 项目可研报告模板或立项审批格式
- 必填的财务、合规、安全或标准评审维度
- 既有 PRD、项目背景、干系人决策记录
- 术语、编号、章节结构约定

## 工具选择

- 现行政策、标准、市场、厂商、成本或技术成熟度证据使用 `rd-research`
- 优先一手来源和最窄的已配置检索能力
- 只有当前库或 API 接口、兼容性事实影响可行性时才使用文档检索能力
- 将无法取得的证据与分析结论分开，并明确后续核验动作

## 质量门禁

交付前核查：

- [ ] 决策问题和研究范围明确
- [ ] 事实、假设、估算、未决问题已区分
- [ ] 重大决策和已接受风险具有明确决策权限
- [ ] 核心可行性维度已覆盖，未覆盖项有理由
- [ ] 存在真实选择时已比较至少 2 个方案
- [ ] 关键数据和标准/政策结论有来源
- [ ] 结论、置信度、推进条件、风险和下一步清晰
- [ ] 技术采用相关任务已覆盖兼容性、生命周期、安全、支持和退出路径
- [ ] 未编造成本、进度、基准、政策或标准结论

## 不做

- 不写详细设计或实施指令
- 不编造财务数字、政策要求或标准条款
- 不用“基本可行”等模糊话术掩盖条件和风险
- 不把可研结论写成无条件承诺