name: req-eval
description: '需求评估器——按项目类型用不同"镜头"评估一个需求/项目能不能做、值不值得做、报价合不合理。覆盖四类：①外包需求类（接单/甲方付费，重点：范围边界+验收可测性+报价合理性+合同风险）②项目合作类（合伙/共建/分成，重点：权责分工+利益分配+退出机制）③自研商业产品（自己做来卖，重点：真伪需求+市场竞品+商业模式+MVP+ROI）④实用小工具类（自用/小范围提效，重点：有无现成替代+工时+最小实现）。触发条件：用户说"评估这个需求""这个需求能不能做""值不值得做""报价合不合理""项目可行性""接不接这个项目""需求清不清楚""范围边界在哪里"，或明说"外包/接单/甲方付费""合作/合伙/共建/分成/股权""自研/做产品/创业/SaaS/卖钱""小工具/脚本/自动化/提效"并要求评估/分析/报价/可行性判断。产出默认 Markdown 快评（分段+表格），加 --word 联动 word-doc 技能出正式 Word，加 --brief 只要一页结论。严格遵循 CLAUDE.md 推理校验规则：结论前先列前提、重要结论自我反驳一次、标注置信度、不确定先问不瞎猜。'
需求评估器（req-eval）
把"评估一个需求/项目"这件事标准化。核心思想：不同类型的项目要用不同的评估镜头——外包怕被坑、合作怕扯皮、自研怕没市场、工具怕白做。不要用同一套模板套所有项目。
工作流（每次必走）
- 读全材料：用户给的方案/PDF/聊天描述，先完整读懂（文本层坏了就渲染图片 OCR，别凭标题猜）。
- 判定项目类型（见下）。拿不准就用一个 AskUserQuestion 问清楚，绝不瞎猜类型——类型错了整套评估全错。
- 套对应框架（A/B/C/D 之一）逐项评估。
- 复用通用积木：报价框架、风险维度、推理校验规则。
- 产出：默认 Markdown 快评；
--word 出正式版；--brief 一页结论。 - 存示例：评估完一个真实项目，征得同意后存到
examples/ 作为后续参考样本。
第一步：判定项目类型
| 信号词 | 类型 |
|---|
| 甲方/客户/外包/接单/报价/工期/验收/交付物/合同/采购 | A 外包需求类 |
| 合作/合伙/联合/共建/分成/股权/共同开发/团队组建 | B 项目合作类 |
| 自研/做产品/创业/SaaS/上线卖/目标用户/商业模式/竞品/融资 | C 自研商业产品 |
| 小工具/脚本/自动化/提效/批量处理/自己用/随手做个 | D 实用小工具类 |
判定不准时必须问（一个多选/单选问题），例如："这个项目是 ①接外包赚钱 ②找人长期合作 ③自己做产品卖 ④做个小工具自用？" 判定准了再继续。
A. 外包需求类（重点：别被坑）
适用：有人付钱让你/团队开发。评估顺序：
- 一句话定性 + 范围复述：把这个需求说成人话，确认你和甲方理解一致。
- 需求成熟度体检（红/黄/绿）：
- 有没有可执行的 SRS，还是只有宣传册式方案？
- 范围边界清不清（做什么、不做什么）？
- 验收标准可测不可测（能写进测试用例吗）？
- 非功能性需求齐不齐（并发/SLA/安全/性能/合规）？
- 工作量分解 + 报价区间：按模块拆人月，套报价框架给三档（精简/标准/完整）。
- 风险清单：范围蔓延、需求变更成本、IP/源码归属、转包、验收扯皮、维保期、Token/算力谁出。
- 开发前必须敲定的需求：按 P0/P1/P2 列（P0 = 不定就无法报价/排期）。
- 合同关键条款提示：联动
legal-* 系列技能（尤其 legal-risks/legal-missing/legal-agreement）。 - 结论：接 / 不接 / 有条件接（列出前置条件）+ 置信度。
B. 项目合作类（重点：权责与退出）
适用：不是一锤子买卖，是长期共同做事。评估顺序：
- 合作性质定性：技术合伙 / 资源互补 / 股权合伙 / 项目分成 / 联合开发——性质不同条款天差地别。
- 双方贡献与分工矩阵：谁出钱/出技术/出资源/出渠道/出时间，列成表。
- 利益分配建议：股权比例 / 收入分成 / 里程碑付款，给可谈判的区间和理由。
- 决策权与治理：谁拍板、僵局怎么破、重大事项门槛。
- 知识产权归属：既有 IP、合作产出 IP、背景 IP 各归谁。
- 共担风险识别：技术失败、市场变化、一方中途退出、投入不对等。
- 退出/解散机制：散伙条件、IP 和数据怎么分、竞业/保密——这块最常被忽略也最容易翻脸。
- 信任与背景尽调提示：对方资质/口碑/资金真实性。
- 结论：合作模式建议 + 落地下一步 + 联动
legal-agreement/legal-nda。
C. 自研商业产品（重点：能不能赚钱）
适用：自己投人投钱做产品去卖。评估顺序：
- 真伪需求判断：谁的痛、多痛、多频繁、现在怎么忍的（"没有也行"就是伪需求）。
- 市场与竞品：TAM 有多大、现有替代方案（含免费/开源/Excel）、你的差异化点是不是真差异。
- 目标用户与 PMF 假设：第一批用户是谁、怎么触达、凭什么用你。
- 商业模式与定价：怎么收钱（订阅/买断/按量/免费增值）、定价参照、单位经济模型。
- MVP 最小范围：砍到不能再砍，能用最便宜方式验证核心假设的版本。
- ROI 与机会成本：投入 vs 预期回报 vs 不做的代价，时间线。
- 技术可行性与护城河：能不能做出来、做出来别人抄不抄得动。
- Go/No-Go：做 / 不做 / 先做验证实验 + 最便宜的那个验证实验是什么。
D. 实用小工具类（重点：最快验证有没有用）
适用：自用或小范围提效。评估顺序：
- 真痛点确认：自己/团队是否真的会反复用，还是"感觉有用"。
- 现成替代检查：先搜有没有轮子（开源/免费工具/现成 SaaS/一行命令），别重复造。
- 技术可行性与选型：用什么最快做出来（脚本/无代码/AI 生成）。
- 工时预估：小时级 / 天级 / 周级——超过一周就该重新审视是不是真"小工具"。
- 自用 vs 分发：只自己用、团队内用、还是开源/收费分发（分发成本远高于自用）。
- 维护负担：数据源会不会变、依赖会不会挂、谁来长期维护。
- 结论：做 / 不做（用现成的）/ 最小实现路径 + 预估工时。
通用积木
报价框架（A 外包、C 自研定价时复用）
方法论前提：公网几乎没有项目级标准价目，故用功能点分解 × 人月单价估算，并明确声明这是估算、给区间不给单一数字。
- 拆模块估人月：把功能拆成模块，每个给一个区间（如 RAG 引擎 2.5–3.5 人月）。
- 人月单价参考（2026 年，中国，含税客户报价）：
- 个人/小工作室：¥1.5 万–2.5 万/人月
- 二线外包团队：¥2.5 万–3.5 万/人月
- 一线/品牌厂商：¥3.5 万–5 万+/人月
- 国企/合规溢价（信创/等保/重验收）：再 +30%–60%
- 三档报价：精简二开版 / 标准自研版 / 完整合规版，分别给区间。
- 持续成本：大模型 Token/算力（按量）、年运维维保（开发费 15–20%）。
- 自我反驳：报价的前提是工作量与单价假设，列出"若 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 待定需求清单）。做新评估前可读一个同类样本对齐颗粒度。