agentsclimarketplace

Req eval

Skill Frog1205/OPC-Skills/skills/req-eval

OPC-Skills — AI 一人公司（One-Person Company）Claude Code 技能合集。一个人 + AI = 一支团队。战略/法务/内容/文档等虚拟部门，18 个开箱即用的 AI 技能。

Install
npx -y skills add Frog1205/OPC-Skills --skill req-eval

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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

SKILL.md

9.1 KB, as published. Nobody here has run it

需求评估器（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 待定需求清单）。做新评估前可读一个同类样本对齐颗粒度。

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.