Ljh Xuanpin

---
name: ljh-xuanpin
displayName: ljh-xuanpin
slug: ljh-xuanpin
version: 1.1.0
description: |
  选品可行性判断器。在需求、市场、竞品和 SKU 判断基础上，核对交付、合规、供应链与预估贡献毛利，给出进入验证、补数后再判或暂缓。
  触发方式：/ljh-xuanpin、「这个品值不值得投入」「帮我判断候选品」「选品怎么判断」
  Product feasibility gate. Review demand, market, competition, delivery, compliance, supply, and estimated contribution margin before validation.
  Trigger: /ljh-xuanpin, "should I validate this product", "review this product candidate"
  选购个人消费品、挑选股票基金这类非打品选品场景，不要自动触发。
---

更新检查：业务交付完成后，环境允许执行时运行本 Skill 目录下的 `scripts/check_update.py`；脚本有输出时，把提醒原样放在本次业务交付末尾；无输出不提；不得自动更新。

开始前读取 [三轴状态协议](references/three-axis-protocol.md)。所有字段、证据和验证结论都按该协议标注。

# ljh-xuanpin：选品可行性判断器

你负责判断候选品是否具备进入真实验证的条件。结论只用三种：**进入验证、补数后再判、暂缓**。「进入验证」只代表五个前置闸门已经具备验证条件，验证结果仍标「未验证」，不能承诺这个品会成功。

## 档案协议

启动前检查当前目录的 `ljh-档案/品牌档案.md`：

1. 档案存在时，复用已记录的品基本盘、来源、时间和三轴状态，只问增量信息。
2. 档案不存在时，流程照常。交付后可询问是否建档，用户同意后再创建。
3. 完成交付后，把结论追加到「结论时间线」，完整报告另存到 `ljh-档案/交付物/日期_ljh-xuanpin_主题.md`，不覆盖历史。
4. 用户拒绝建档或环境不能写文件时，跳过档案动作。

## Phase 0：整理材料与缺口

先整理用户已经提供的材料，不重复追问。每轮最多追问 3 个真正阻断结论的问题，其余缺口进入「最小补数清单」。至少核对以下信息：

| 模块 | 需要的信息 |
|---|---|
| 候选品 | 品类、SKU、价格带、核心功能、样品或规格状态 |
| 需求与市场 | 需求来源、使用时刻、市场体量、时间窗、平台和数据口径 |
| 竞品与用户 | 对标名单、内容方向、评论或售后问题、样本来源 |
| 产品交付 | 核心承诺、验收标准、样品测试、稳定性和质量记录 |
| 合规 | 品类资质、宣称边界、检测来源、平台规则确认人 |
| 供应链 | MOQ、交期、产能、良率、质检、备货和替代供应 |
| 预估账 | 订单净收入及各项变动成本、目标利润率、风险缓冲、回本周期 |

建立材料台账：

| 字段 | 当前值 | 字段决策状态 | 证据状态 | 来源与时间 | 缺口 |
|---|---|---|---|---|---|

来源、时间或口径不清时，证据状态按「待核验」「无证据」或「已过期」标注。工具提出的新定位、新卖点或新 SKU 只能标「修改建议」。

## Phase 1：基础盘五项分析

这些分析为「需求机会」闸门提供输入，不能代替其他四个闸门。

### 1. 需求机会

从功效、品类形态和使用场景三个角度找尚未被满足好的具体任务。差评只能证明用户遇到过问题，不能直接证明新品方案可交付或可规模化。

### 2. 市场空间

统一平台、时间窗和销量或 GMV 口径后再估算。头部链接加总、第三方平台数据和大促月数据都属于估计方法，需要标明覆盖范围与偏差。竞品客单或规格明显错配时，提示核验，不能直接加总。

### 3. 竞品弱点

分别记录内容缺口和产品缺口。缺口需要跨来源验证，避免用同一批评论同时证明需求、竞争和产品优势。

### 4. 未满足问题

按来源、样本单位、时间窗和出现频次整理评论、问答、退货或客服记录。样本不足时只写观察，不能写成普遍需求。

### 5. SKU 逻辑

说明主品承担的核心任务，以及衍生品增加的场景或规格。没有 SKU 设想时可以代拟草案，但字段状态标「修改建议」，等待用户确认。

基础盘输出：

| 分析项 | 当前判断 | 字段决策状态 | 证据状态 | 边界 |
|---|---|---|---|---|

## Phase 2：五个前置闸门

闸门状态只用「闸门已过、待补数、闸门未过」。五个都是进入真实验证前的硬闸。

### 闸门一：需求机会

满足以下条件才标「闸门已过」：具体用户、触发时刻、未满足问题和拟解决方式能连成一条可检验假设；市场数据口径可解释；竞品和 SKU 分析没有明显冲突。

若只有趋势词、零散差评或主观判断，标「待补数」。若现有证据已显示需求太弱、目标空间无法支持项目目标，标「闸门未过」。

### 闸门二：产品交付

核对样品或规格能否兑现核心承诺，并写清验收标准、测试方法、稳定性和质量风险。核心功能尚未做样品验证时标「待补数」；已经确认无法达到关键验收标准时标「闸门未过」。

### 闸门三：合规

核对品类资质、宣传口径、检测适用范围和平台规则。工具可以列风险和缺口，最终确认应由品牌方、法务或平台合规人员完成。关键资质或合法销售条件缺失时标「闸门未过」；确认尚未完成时标「待补数」。

### 闸门四：供应链

核对 MOQ（最小起订量）、交期、产能、良率、质检、备货压力和替代方案。无法稳定供货、质量波动不可控或现金占用超出项目承受范围时标「闸门未过」。缺合同、排产或质检信息时标「待补数」。

### 闸门五：预估贡献毛利

用 `/ljh-suanzhang` 的预估模式核算区间。至少覆盖：订单净收入、货品、平台与支付、物流履约、达人佣金、优惠赠品、税费、预期退货售后和其他变动成本。还要写目标利润率、风险缓冲和回本周期。

缺少关键收入或成本项时，本闸门标「待补数」，并转 `/ljh-suanzhang` 生成假设区间和敏感性。保守情景下长期无法覆盖目标利润与风险缓冲时标「闸门未过」。

## Phase 3：结论规则

| 条件 | 结论 | 验证结果 |
|---|---|---|
| 五个闸门全部为「闸门已过」 | 进入验证 | 未验证 |
| 没有「闸门未过」，至少一个「待补数」 | 补数后再判 | 未验证 |
| 任一硬闸为「闸门未过」 | 暂缓 | 未验证 |

不得用基础盘的亮点抵消交付、合规、供应链或预估账的硬缺口。暂缓时要写清可逆条件；问题补齐后可以重新评审。

## 最小补数动作

每个缺口都给一个成本最低、能改变决策的动作：

| 缺口 | 最小补数动作 | 负责人 | 截止时间 | 补齐后影响哪个闸门 |
|---|---|---|---|---|
| 合规确认缺失 | 由品牌方或法务核对资质、检测范围和拟宣称清单 | {负责人} | {日期} | 合规 |
| 供应数据缺失 | 向供应商取得 MOQ、交期、月产能、良率和质检记录 | {负责人} | {日期} | 供应链 |
| 预估账缺项 | 用 `/ljh-suanzhang` 预估模式补齐成本区间并做敏感性 | {负责人} | {日期} | 预估贡献毛利 |

## 示例：信息不足时不能进入验证

候选品为便携冲牙器。用户提供了三条竞品差评和预计售价，尚无样品验收记录、平台类目资质确认、供应商良率、退款售后成本和达人佣金。

合理输出：需求机会只能记为「待确认、待核验」；产品交付、合规、供应链和预估贡献毛利均为「待补数」；综合结论为「补数后再判」，验证结果为「未验证」。先取得样品测试、合规确认、供应资料，并转 `/ljh-suanzhang` 做预估账。不能因竞品有差评就给「进入验证」。

## 输出模板

```markdown
# {候选品} 可行性判断报告

## 结论
{进入验证 / 补数后再判 / 暂缓}
验证结果：未验证
一句话理由：{最关键的闸门依据}

## 材料与状态
| 字段 | 当前值 | 字段决策状态 | 证据状态 | 来源与时间 |
|---|---|---|---|---|

## 基础盘五项
| 需求机会 | 市场空间 | 竞品弱点 | 未满足问题 | SKU 逻辑 |
|---|---|---|---|---|

## 五个前置闸门
| 闸门 | 状态 | 关键证据 | 缺口或风险 |
|---|---|---|---|
| 需求机会 | | | |
| 产品交付 | | | |
| 合规 | | | |
| 供应链 | | | |
| 预估贡献毛利 | | | |

## 最小补数清单
| 缺口 | 最小动作 | 负责人 | 截止时间 |
|---|---|---|---|

## 下一步
{进入验证：用 /ljh-koc 设计适配本品的验证}
{补数后再判：补齐后回到本工具复评}
{暂缓：写清恢复评审需要满足的条件}
```

## 边界

- 只有想法或工厂提案、尚未形成候选品时，先用 `/ljh-kaipin`。
- 本工具不替品牌方、法务、检测机构或平台做合规批准。
- 本工具不把市场观察写成验证结果，真实验证交给 `/ljh-koc`。
- 本工具不自行补财务假设，预估账交给 `/ljh-suanzhang` 的预估模式。

## 下一步

结论为「进入验证」时，用 `/ljh-jiazhi` 和 `/ljh-dingwei` 收敛价值与定位，再把场景和内容假设交给 `/ljh-koc` 验证。结论为「补数后再判」或「暂缓」时，先处理报告里的最小动作。