# Req Eval

> 需求评估器——按项目类型用不同"镜头"评估一个需求/项目能不能做、值不值得做、报价合不合理。覆盖四类：①外包需求类（接单/甲方付费，重点：范围边界+验收可测性+报价合理性+合同风险）②项目合作类（合伙/共建/分成，重点：权责分工+利益分配+退出机制）③自研商业产品（自己做来卖，重点：真伪需求+市场竞品+商业模式+MVP+ROI）④实用小工具类（自用/小范围提效，重点：有无现成替代+工时+最小实现）。触发条件：用户说"评估这个需求""这个需求能不能做""值不值得做""报价合不合理""项目可行性""接不接这个项目""需求清不清楚""范围边界在哪里"，或明说"外包/接单/甲方付费""合作/合伙/共建/分成/股权""自研/做产品/创业/SaaS/卖钱""小工具/脚本/自动化/提效"并要求评估/分析/报价/可行性判断。产出默认 Markdown 快评（分段+表格），加 --word 联动 word-doc 技能出正式 Word，加 --brief 只要一页结论。严格遵循 CLAUDE.md 推理校验规则：结论前先列前提、重要结论自我反驳一次、标注置信度、不确定先问不瞎猜。

- Skill: `frog1205/req-eval` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add frog1205/req-eval`
- Raw SKILL.md: https://api.skillmd.com/api/skills/frog1205/req-eval/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: Frog1205 (https://skillmd.com/u/frog1205)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/frog1205/req-eval

---


# 需求评估器（req-eval）

把"评估一个需求/项目"这件事标准化。**核心思想：不同类型的项目要用不同的评估镜头**——外包怕被坑、合作怕扯皮、自研怕没市场、工具怕白做。不要用同一套模板套所有项目。

## 工作流（每次必走）

1. **读全材料**：用户给的方案/PDF/聊天描述，先完整读懂（文本层坏了就渲染图片 OCR，别凭标题猜）。
2. **判定项目类型**（见下）。拿不准就**用一个 AskUserQuestion 问清楚**，绝不瞎猜类型——类型错了整套评估全错。
3. **套对应框架**（A/B/C/D 之一）逐项评估。
4. **复用通用积木**：报价框架、风险维度、推理校验规则。
5. **产出**：默认 Markdown 快评；`--word` 出正式版；`--brief` 一页结论。
6. **存示例**：评估完一个真实项目，征得同意后存到 `examples/` 作为后续参考样本。

---

## 第一步：判定项目类型

| 信号词 | 类型 |
|---|---|
| 甲方/客户/外包/接单/报价/工期/验收/交付物/合同/采购 | **A 外包需求类** |
| 合作/合伙/联合/共建/分成/股权/共同开发/团队组建 | **B 项目合作类** |
| 自研/做产品/创业/SaaS/上线卖/目标用户/商业模式/竞品/融资 | **C 自研商业产品** |
| 小工具/脚本/自动化/提效/批量处理/自己用/随手做个 | **D 实用小工具类** |

**判定不准时必须问**（一个多选/单选问题），例如："这个项目是 ①接外包赚钱 ②找人长期合作 ③自己做产品卖 ④做个小工具自用？" 判定准了再继续。

---

## A. 外包需求类（重点：别被坑）

适用：有人付钱让你/团队开发。评估顺序：

1. **一句话定性 + 范围复述**：把这个需求说成人话，确认你和甲方理解一致。
2. **需求成熟度体检**（红/黄/绿）：
   - 有没有可执行的 SRS，还是只有宣传册式方案？
   - 范围边界清不清（做什么、**不做什么**）？
   - 验收标准可测不可测（能写进测试用例吗）？
   - 非功能性需求齐不齐（并发/SLA/安全/性能/合规）？
3. **工作量分解 + 报价区间**：按模块拆人月，套报价框架给三档（精简/标准/完整）。
4. **风险清单**：范围蔓延、需求变更成本、IP/源码归属、转包、验收扯皮、维保期、Token/算力谁出。
5. **开发前必须敲定的需求**：按 P0/P1/P2 列（P0 = 不定就无法报价/排期）。
6. **合同关键条款提示**：联动 `legal-*` 系列技能（尤其 `legal-risks`/`legal-missing`/`legal-agreement`）。
7. **结论**：接 / 不接 / 有条件接（列出前置条件）+ 置信度。

## B. 项目合作类（重点：权责与退出）

适用：不是一锤子买卖，是长期共同做事。评估顺序：

1. **合作性质定性**：技术合伙 / 资源互补 / 股权合伙 / 项目分成 / 联合开发——性质不同条款天差地别。
2. **双方贡献与分工矩阵**：谁出钱/出技术/出资源/出渠道/出时间，列成表。
3. **利益分配建议**：股权比例 / 收入分成 / 里程碑付款，给可谈判的区间和理由。
4. **决策权与治理**：谁拍板、僵局怎么破、重大事项门槛。
5. **知识产权归属**：既有 IP、合作产出 IP、背景 IP 各归谁。
6. **共担风险识别**：技术失败、市场变化、一方中途退出、投入不对等。
7. **退出/解散机制**：散伙条件、IP 和数据怎么分、竞业/保密——**这块最常被忽略也最容易翻脸**。
8. **信任与背景尽调提示**：对方资质/口碑/资金真实性。
9. **结论**：合作模式建议 + 落地下一步 + 联动 `legal-agreement`/`legal-nda`。

## C. 自研商业产品（重点：能不能赚钱）

适用：自己投人投钱做产品去卖。评估顺序：

1. **真伪需求判断**：谁的痛、多痛、多频繁、现在怎么忍的（"没有也行"就是伪需求）。
2. **市场与竞品**：TAM 有多大、现有替代方案（含免费/开源/Excel）、你的差异化点是不是真差异。
3. **目标用户与 PMF 假设**：第一批用户是谁、怎么触达、凭什么用你。
4. **商业模式与定价**：怎么收钱（订阅/买断/按量/免费增值）、定价参照、单位经济模型。
5. **MVP 最小范围**：砍到不能再砍，能用最便宜方式验证核心假设的版本。
6. **ROI 与机会成本**：投入 vs 预期回报 vs 不做的代价，时间线。
7. **技术可行性与护城河**：能不能做出来、做出来别人抄不抄得动。
8. **Go/No-Go**：做 / 不做 / 先做验证实验 + 最便宜的那个验证实验是什么。

## D. 实用小工具类（重点：最快验证有没有用）

适用：自用或小范围提效。评估顺序：

1. **真痛点确认**：自己/团队是否真的会反复用，还是"感觉有用"。
2. **现成替代检查**：**先搜有没有轮子**（开源/免费工具/现成 SaaS/一行命令），别重复造。
3. **技术可行性与选型**：用什么最快做出来（脚本/无代码/AI 生成）。
4. **工时预估**：小时级 / 天级 / 周级——超过一周就该重新审视是不是真"小工具"。
5. **自用 vs 分发**：只自己用、团队内用、还是开源/收费分发（分发成本远高于自用）。
6. **维护负担**：数据源会不会变、依赖会不会挂、谁来长期维护。
7. **结论**：做 / 不做（用现成的）/ 最小实现路径 + 预估工时。

---

## 通用积木

### 报价框架（A 外包、C 自研定价时复用）

**方法论前提**：公网几乎没有项目级标准价目，故用**功能点分解 × 人月单价**估算，并明确声明这是估算、给区间不给单一数字。

1. **拆模块估人月**：把功能拆成模块，每个给一个区间（如 RAG 引擎 2.5–3.5 人月）。
2. **人月单价参考（2026 年，中国，含税客户报价）**：
   - 个人/小工作室：¥1.5 万–2.5 万/人月
   - 二线外包团队：¥2.5 万–3.5 万/人月
   - 一线/品牌厂商：¥3.5 万–5 万+/人月
   - 国企/合规溢价（信创/等保/重验收）：再 +30%–60%
3. **三档报价**：精简二开版 / 标准自研版 / 完整合规版，分别给区间。
4. **持续成本**：大模型 Token/算力（按量）、年运维维保（开发费 15–20%）。
5. **自我反驳**：报价的前提是工作量与单价假设，列出"若 X 成立则落到低端/高端"的分支。

### 风险清单通用维度

范围蔓延 · 需求变更 · 工期延误 · 技术可行性 · 第三方依赖 · 数据/合规 · IP 归属 · 人员变动 · 验收扯皮 · 维保责任。每条标 红黄绿 + 缓解动作。

### 推理校验规则（对齐 CLAUDE.md，强制）

- **结论前先列前提**：给判断/报价/排名前，先写依赖的规则或数据。
- **与常识冲突必标注**：发现矛盾（如方案自相矛盾、模型被别名、市场价异常）主动点出，不静默忽略。
- **重要结论自我反驳一次**：报价/Go-NoGo/接不接，给出后反驳"前提是 X，X 不成立则结论失效"。
- **标注置信度**：高/中/低，不确定的结论别用肯定语气。
- **信息来源优先级**：已知规则/文档 > 界面视觉 > 模糊推断；冲突时说明采信哪个及原因。

---

## 输出格式

- **默认**：Markdown 快评，分段 + 表格，直接可读。
- **`--word`**：联动 `word-doc` 技能，产出正式 Word（封面/目录/正文/页脚，符合 Word 规范），用于交付甲方/立项。
- **`--brief`**：只要一页结论（定性 + 关键风险 + 报价区间/Go-NoGo + 下一步）。

## 示例

真实项目评估样本见 `examples/`。例如 `examples/enterprise-rag-outsourcing.md`（某央企销售部 AI 知识库问答助手——典型 A 类外包评估，含工作量分解、三档报价、P0 待定需求清单）。做新评估前可读一个同类样本对齐颗粒度。