# Brandbai Product Value

> Build an evidence-backed product value foundation from product links, product pages, product cards, briefs, packaging, manuals, parameter sheets, SKU files, reports, certifications, user feedback or mixed product materials. Use for 商品资料整理、商品事实建账、商品价值分析、P0候选与P0/P1/P2分层、商品表达边界、资料缺口、增量资料合并和下游卖点呈现或达人匹配前置。This Skill stops at product value; it does not create selling-point visuals, content ideas, scripts, creator matching or commercial attribution.

- Skill: `brandbai7/brandbai-product-value` (Agent Skill, multi-file: 29 files)
- Install (CLI): `npx skillmds@latest add brandbai7/brandbai-product-value`
- Raw SKILL.md: https://api.skillmd.com/api/skills/brandbai7/brandbai-product-value/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: PolyForm-Noncommercial-1.0.0
- Author: brandbai7 (https://skillmd.com/u/brandbai7)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/brandbai7/brandbai-product-value

---


# BrandBAI 商品价值底座

把不同形态的商品资料整理成可回溯的商品事实、完整 FABE 推导、价值候选、P0 决策和表达边界，为卖点呈现、达人匹配、内容诊断及其他内容电商任务提供稳定上游。本 Skill 只完成商品价值建模，不生成 VIS、拍摄方案、内容方向、脚本或达人合作结论。

## 先确认许可、资料与商品边界

只在 [PolyForm Noncommercial License 1.0.0](references/license.md) 允许的非商业范围内运行本 Skill。企业内部使用、客户交付、收费服务或其他预期商业用途，须先通过 `brandlaobai@163.com` 取得 BrandBAI 书面商业授权。

只处理使用者有权提供和分析的资料。不要把客户资料、商品证据原件、账号凭据、个人信息或实际交付结果提交到本仓库。

开始前确认一个具体商品和当前 SKU/标准成交单元。多个商品、多个 SKU、不同代际或不同组合分别建账。商品标题中的词组、搜索结果标题或 OCR 片段不能单独作为 SKU；本地文件名和文件路径只用于定位来源，无论其中是否出现规格词，都不能证明商品规格、制造 SKU 冲突或进入 `sku_basis`。优先核对 SKU 选择器、包装标示、规格表和商品信息区。若商品身份明确但 SKU 名称只得到部分确认，可继续建立有条件底座，但必须写明 `sku_status=partial`、确认依据和开放缺口；无法隔离当前商品或成交单元时只输出资料缺口。

## 运行要求

宿主需要能够读取使用者提供的商品资料，并允许在使用者指定的新目录中写入 Markdown、JSON 和 JSONL。随附脚本只使用 Python 标准库，建议 Python 3.10 或更高版本。图片输入还要求宿主能把生成的 SVG 审计卡按视觉内容打开；不得把 SVG 当文本读取或只看文件名。宿主无法运行脚本、生成审计卡或视觉打开审计卡时，必须说明能力缺口并停止图片事实建模，不能手工声明已完成同等校验。

## 读取工作合同

每次运行先阅读：

- [输入输出合同](references/input-output-contract.md)：确认输入、目录和数据字段；
- [账本填写与分阶段校验](references/ledger-writing-contract.md)：按可复制的 JSON 示例填写枚举、数组、时间、哈希和引用字段，并在每个阶段立即校验；
- [商品价值方法](references/value-method.md)：完成事实、利益、候选和价值分层；
- [交付合同](references/delivery-contract.md)：生成普通版并判断完成状态。

收到增量资料、旧版商品价值底座或 P0 争议时，再阅读 [版本与下游交接](references/versioning-and-handoff.md)。

## 路由商品资料

接受商品链接或页面导出、详情页 PDF/图片、商品手卡、包装说明、参数和 SKU 表、检测认证、用户反馈、混合资料或增量补充。宿主无法读取某种格式时，明确能力缺口并请求可读替代格式；链接不可访问时不得声称已读取。

将资料分为：

- `F-PAGE`：当前商品或 SKU 的页面、包装、说明书、官方 FAQ 和品牌手卡中明确的信息；
- `F-EVIDENCE`：检测、认证、报告、专利、研究或凭证中可核对的信息；
- `STRAT`：品牌战略方向、目标用户、创新任务和经营意图；
- `DYN`：价格、券、赠品、库存、物流和活动等动态交易信息；
- `U`：评论、问答、客服或调研中的用户语言、体验、场景和顾虑；
- `EX`：商品页或既有内容中已经存在的表达；
- `H`：分析推导、竞争判断和待验证解释。

`F-PAGE` 是当前商品价值建模的有效事实来源。对品牌或商家公开发布、且与当前商品和 SKU 明确对应的详情页、包装、说明书和官方 FAQ，可直接作为当前公开商品主张使用；缺少第三方报告不构成自动降级或禁用理由。`F-EVIDENCE` 用于增强证据等级，而不是决定商品价值能否存在。只有来源冲突、SKU 不明、页面过期、明显超出资料范围或涉及需要额外审慎判断的医疗与绝对化承诺时，才降级、暂缓或停止。`STRAT` 不得写成用户已认可事实；`U` 不得替代商品事实；`DYN` 必须绑定时间与 SKU。活动原文没有年份时，若依据采集时间补全年份，必须在边界中明示推定依据；原文含具体时刻时，`time_scope` 必须保留日期、时刻和时区。

动态权益必须抄录完整起止日期、年份和时区，并以本次交付的 `updated_at` 判断 `upcoming/active/expired`。活动期间不得写成已过期；活动结束后也不得继续标记当前有效。动态信息只形成时点快照，不固化为长期价值。

活动在本次快照时仍处有效期，可以写“采集时当前有效”，但必须同时显示快照时间和截止日期；不得一边标记 `active`，一边在 `cannot_prove`、限制或缺口中写“不能称为当前有效”。

## 判断资料成熟度

分别记录 `FC0—FC3` 商品事实完整度、`SC0—SC3` 战略信息完整度和 `PKG-L0—PKG-L4` 综合可用程度。事实多不等于战略清楚，战略明确也不能替代商品事实。

只有商品名或模糊描述时标 `FC0`，停止价值定稿并输出缺口。只有简单商品手卡时可以建立初步底座，但不得固定唯一长期 P0 或写成已证明竞争优势。

## 初始化交付目录

任何正式写入先运行 Dry Run：

```powershell
python scripts/init_product_value_delivery.py `
  --out "<新的输出目录>" `
  --brand "<品牌>" `
  --product "<商品名>" `
  --category "<品类>" `
  --sku "<当前SKU或版本>" `
  --sku-status "<confirmed|partial|unverified>" `
  --sku-basis "<SKU选择器/包装/规格表中的确认依据>" `
  --input-mode mixed `
  --dry-run
```

确认目标目录后去掉 `--dry-run`。脚本只初始化模板和底稿，不读取商品内容，也不自动得出价值结论。不要覆盖已有交付；重做使用新目录，增量更新按版本合同处理。

本地文件或文件夹必须在分析前建立真实来源清单：

```powershell
python scripts/index_product_sources.py `
  --input "<原始商品资料文件或目录>" `
  --delivery "<输出目录>" `
  --dry-run
python scripts/index_product_sources.py `
  --input "<原始商品资料文件或目录>" `
  --delivery "<输出目录>"
```

来源清单保留原始文件名、相对路径、大小和 SHA-256。生成后不得为了视觉顺序重命名或重新编号；需要重做时新建交付目录。ZIP、RAR、7z、tar 等压缩包只登记为来源容器，必须用 `unsupported_archive + unreadable` 明确记录未读取；不得把压缩包本身登记为页面事实来源。需要读取时先在输入侧解压，并在全新交付目录中对解压后的每个文件重新索引。图片清单建立后，先生成不可覆盖的视觉审计卡：

```powershell
python scripts/build_source_audit_cards.py `
  --input "<原始商品资料文件或目录>" `
  --delivery "<输出目录>" `
  --dry-run
python scripts/build_source_audit_cards.py `
  --input "<原始商品资料文件或目录>" `
  --delivery "<输出目录>"
```

每张 SVG 审计卡把 `source_file_id`、真实相对路径、原文件 SHA-256 和原图像素固定在同一个可视对象中。必须按 `source_file_id` 正序逐张视觉打开审计卡，完成第一遍观察后，再按反向顺序逐张重新打开并复核；两遍都要独立记录序号、标题、摘录和宿主在实际打开当下取得的带时区时间。若宿主提供 `inspect_source` 等受信打开工具，必须只通过该工具完成四阶段打开，并原样使用工具返回的时间；工具生成的 `data/tool_audit_events.jsonl` 是权威事件账本，模型不得创建、补写、改时或覆盖。XLSX/XLSM 必须用宿主固定表格读取器逐工作表读取真实单元格，至少检查商品概览、商品参数、可见规格、价格与权益等存在的工作表；SKU、规格、价格、销量、保质期、许可证、生产企业、警示等已出现字段必须进入原文主张与事实，或逐项登记不可读/不适用缺口。宿主不能读取表格、表格事件显示不可读或非空表格没有任何原文主张时，`analysis_status` 不得标为 `complete`。受信模式允许同一来源下的多条原文主张共享该来源的摘录事件与复核事件时间，不再要求模型为每条主张猜造不同秒数。未提供受信工具时才使用旧式宿主取时规则。所有核验时间必须晚于交付初始化的 `created_at`，时区偏移必须反映真实本地时钟；不得把 UTC 时钟值直接标成 `+08:00`。不得一次打开多张图后批量回填，不得复用自造时间，不得用固定间隔、重复循环节奏、在 8—45 秒受限整数区间内持续高频上下交替的机械节奏或未来时间生成核验记录，不得把审计卡作为文本读取，也不得只看文件名、缩略图、OCR 汇总或旧交付。核验时间不得晚于对应账本的实际写入时间。两遍不一致时先回到原卡纠错，未形成 `match` 不得继续建账。

完成图片两遍核对后，必须立即把全部图片观察写入 `source_observation.jsonl`，不得继续积累到原文摘录或价值分析结束才落盘。此时尚未由 `claim_extract` 打开的 XLSX、Markdown 等非图片来源不得虚构观察记录；观察阶段门禁只暂缓这些非图片来源的“尚无逐文件核对记录”错误，到了主张阶段与最终校验仍必须补齐。观察记录必须标记文字密度和可见内容类型；营养表、规格表、FAQ、食用方式、储存、注意事项、对比、检测和动态交易等页面不能只写摘要。写完立即运行 `validate_product_value_delivery.py --stage observations`；本阶段未通过时只修图片观察账本，不开始图片原文主张。

观察属性必须忠实反映可见内容。缺少原文摘录或时间戳时必须重新检查来源并补齐，不得通过移除 `content_flags`、降低 `text_density` 或改写缺口绕过门禁。若资料边界声明包数或克重冲突，冲突双方必须分别进入原文主张账本；观察摘要、事实边界和缺口不能替代可定位、经复核的原文。

再重新打开所有含文字来源，建立 `source_claim_ledger.jsonl`。每条原文主张必须逐字抄录可见文字，绑定原文件和观察记录，注明页面位置；“页面公开展示”“通用平台文本”“非本商品专属”等分析者摘要不能冒充 `verbatim_text`，应抄录实际可见原句，不能确认时登记缺口。先完成全部第三遍摘录，再开始第四遍重新打开来源复核，两个阶段不得交叉。第三、四遍完成后必须立即写 `source_claim_ledger.jsonl` 和 `source_ledger.jsonl`，再运行 `validate_product_value_delivery.py --stage claims`；本阶段未通过时不得开始事实与 FABE。受信模式按“来源”打开并记时：同一来源中的多条主张共享 `claim_extract` 时间，复核时共享该来源的 `claim_recheck` 时间；不得再人为拆成机械递增的逐条时间。对非图片来源，若固定工具用同一次 `claim_extract` 打开同时完成逐文件观察与原文摘录，观察 `inspected_at` 与主张 `claimed_at` 可以等于该受信事件时间。未使用受信工具时，每条摘录和复核仍由宿主在实际操作当下独立取时，不能批量使用固定间隔、重复时间、重复循环节奏、未来时间或晚于账本写入时间的记录。营养字段、SKU、配料、储存和警示一律标为关键主张。营养表逐行登记，FAQ 每个问答分别登记，对比页分别登记双方原文；“哪些人适合”与“哪些人不宜”、“建议冷藏”与“阴凉干燥”、“国家标准”与“推荐量”不得互换。看不清时登记不可读缺口，不得猜测、补全或调用旧交付。页面没有展示或当前没有取得的信息，只能写入 `boundary` 或 `gap`；除非所引原文明确写出该缺席声明，否则“未标示、未说明、未提供、未公开”等不能登记成直接页面事实。若可见商品证据声明两组包数冲突，冲突双方也必须分别进入原文主张账本，不能只在下游文字中补写；文件名中的数字不是可见商品证据，不能单独制造冲突。

当脚本可用时，原文主张默认采用“确定性候选 → 模型只选 ID → 确定性编译”，不要让模型逐条手写来源绑定、时间、稳定编号和 JSONL。每完成一个来源的 `claim_extract`，立即生成该来源候选，工作目录必须位于正式交付目录之外：

```powershell
python scripts/prepare_product_claim_candidates.py `
  --delivery "<交付目录>" `
  --source-root "<原始资料根目录>" `
  --out-dir "<外部候选目录>" `
  --source-file-id SF-001 `
  --dry-run
python scripts/prepare_product_claim_candidates.py `
  --delivery "<交付目录>" `
  --source-root "<原始资料根目录>" `
  --out-dir "<外部候选目录>" `
  --source-file-id SF-001
```

模型只读取候选包并在外部选择目录写一个小型 JSON 对象，不复制或改写原文；必须保留 SKU、配料、营养、储存、警示、冲突双方和观察标记要求的主张。需要修正类型时只增加 `claim_type_override`：

```json
{"source_file_id":"SF-001","selected_claims":[{"candidate_id":"CAND-001"},{"candidate_id":"CAND-004","claim_type_override":"ingredient"}],"notes":"只记录选择理由和边界，不进入正式原文"}
```

候选文件不是事实，模型选择也不是最终账本。完成全部 `claim_extract` 后再按逆序完成全部 `claim_recheck`；两个阶段不得交叉。全部复核事件存在后，由脚本一次生成按来源拆分的正式主张分包，并用既有合并器写入唯一账本：

```powershell
python scripts/build_product_claim_ledger_from_selections.py `
  --delivery "<交付目录>" `
  --candidates-dir "<外部候选目录>" `
  --selections-dir "<外部选择目录>" `
  --parts-dir "<新的外部主张分包目录>" `
  --expected-source-count <来源总数> `
  --dry-run
python scripts/build_product_claim_ledger_from_selections.py `
  --delivery "<交付目录>" `
  --candidates-dir "<外部候选目录>" `
  --selections-dir "<外部选择目录>" `
  --parts-dir "<新的外部主张分包目录>" `
  --expected-source-count <来源总数>
python scripts/merge_product_value_ledger_parts.py `
  --delivery "<交付目录>" `
  --ledger claims `
  --parts-dir "<外部主张分包目录>" `
  --expected-count <实际选中主张总数>
```

候选生成器读取 XLSX/XLSM 的真实工作表和单元格，过滤采集状态、链接、时间与说明页等操作元数据；图片候选必须同时读取已通过双遍或仲裁的 `visible_heading` 与 `visible_text_excerpt`，标题优先且按原文去重，不能因为标题未重复出现在摘录中而丢失页面主张。图片候选仍只来自正式 Observation，所以两遍冲突且被仲裁移除的小字不得重新出现。营养、SKU、配料、储存、许可证、标准、警示等高密度标签必须按字段拆成独立候选，不能把多个标签和值合并成一个“大主张”；页面主张带 `*1/※1/注1` 等标记时，候选包同时登记对应脚注，模型选中正文后由编译器自动带入绑定脚注。缺少对应脚注的主张不得通过正式校验。编译器自动绑定清单、Observation、来源哈希、摘录/复核受信事件，生成全局连续 `CLM-`、关键字段标记和 `claim_status=match`；未知候选、重复选择、缺事件、来源绑定变化或已有分包目录一律拒绝。模型不得绕过候选文件直接补写不存在的主张。

长任务若必须换新上下文，不能只读取 `tool_audit_events.jsonl` 就凭事件元数据补写原文；事件账本证明来源何时被打开，不保存上一上下文看到的完整图片或文档正文。宿主若提供 `review_source` 等“只读重开已完成受信审计来源”的固定工具，新上下文必须按来源逐个调用该工具，先重开一个来源、立即写完该来源的观察补充、原文主张与来源记录，再重开下一个；不得先重开多份来源后批量回填。`review_source` 不得新增或修改受信事件，全部 `claimed_at/rechecked_at`、序号与哈希仍复制既有 `claim_extract/claim_recheck` 事件。对于工作表多、FAQ 多、营养行多或高文字密度来源，默认单来源单轮；普通图片每轮建议不超过 3—4 个来源。宿主没有只读重开能力时，不得跨上下文声称已经取得上一上下文的完整原文，必须在同一上下文内完成摘录与落盘，或把结果明确留为未完成。

事实记录必须引用对应 `claim_id`，并逐条保留 `source_quotes` 原文；所有数字和“好吸收、道地、无添加、适合某人群、禁止食用、建议冷藏、无需熬煮”等高风险词，只有在所引原文中逐字出现时才能写成直接事实。复合事实中的每个 SKU、配料、营养、储存、生产日期、保质期和警示字段都必须分别存在于所引原文；同一句合并多个警示时，每个对象和动作都要有对应 `claim_id/source_quotes`，不能因为其中一项已引用就顺带写入另一项。关键主张必须进入事实记录，不能只摘录后遗漏。禁止沿用旧交付的页序、标题、观察、原文、事实或结论；文件名相似、数字相邻或上一次分析结果都不能替代本次核对。每条本地来源必须同时绑定清单中的 `source_file_id` 和核对记录中的 `observation_id`，`locator` 必须包含清单里的原始相对路径；只有直接 URL 来源可以不绑定本地文件。

claims 阶段通过后，`source_ledger` 默认由来源清单和正式 Observation 确定性生成，不再让模型重复抄写来源编号、标题、路径、时间与可读状态：

```powershell
python scripts/build_source_ledger_from_observations.py `
  --delivery "<交付目录>" `
  --parts-dir "<新的外部来源分包目录>" `
  --dry-run
python scripts/build_source_ledger_from_observations.py `
  --delivery "<交付目录>" `
  --parts-dir "<新的外部来源分包目录>"
python scripts/merge_product_value_ledger_parts.py `
  --delivery "<交付目录>" `
  --ledger sources `
  --parts-dir "<外部来源分包目录>" `
  --expected-count <实际来源行数>
```

容器文件不重复进入来源事实账本；已受信打开但不可读的非容器来源仍保留 `unavailable` 来源行，并明确“不代表来源没有内容”。该脚本只生成来源身份和读取边界，不生成商品事实。

已复核 Claims 也先用确定性保守事实层完整承接，再由 FABE 和价值层选择真正值得调用的事实。默认每条非 `other` Claim 生成一条逐字可回溯事实，`transaction` 自动隔离为 `DYN` 快照，其他主张先停在 `F-PAGE` 页面公开主张；证据原件升级、事实合并、用户价值与优势判断仍由后续分析完成：

```powershell
python scripts/build_fact_ledger_from_claims.py `
  --delivery "<交付目录>" `
  --parts-dir "<新的外部事实分包目录>" `
  --dry-run
python scripts/build_fact_ledger_from_claims.py `
  --delivery "<交付目录>" `
  --parts-dir "<新的外部事实分包目录>"
python scripts/merge_product_value_ledger_parts.py `
  --delivery "<交付目录>" `
  --ledger facts `
  --parts-dir "<外部事实分包目录>" `
  --expected-count <实际事实行数>
```

保守事实生成器不把 `other` 操作信息升级成事实；所有 `critical=true` 主张必须自动覆盖，否则脚本失败。套餐入口、多变包数、页面证据、页面内比较和动态字段继续保留各自边界，不因确定性生成而升级为已核验结论。

写完 `source_ledger.jsonl` 和 `fact_ledger.jsonl` 后运行 `validate_product_value_delivery.py --stage facts`。只有该阶段退出码为 0 才建立 FABE、识别锚、价值、P0 决策和缺口；分析账本写完后运行 `--stage analysis`，通过后才生成普通版并做不带 `--stage` 的最终校验。分阶段校验只用于缩小当前错误范围，不替代最终校验。

事实量较大时，不得把全部事实无差别塞进一次模型调用。事实超过 40 条、来源超过 8 个或宿主出现上下文不足时，先用 `prepare_product_value_analysis_packet.py --index-only` 读取短索引，再用真实 `claim_id` 生成紧凑分析包：

```powershell
python scripts/prepare_product_value_analysis_packet.py `
  --delivery "<交付目录>" `
  --index-only `
  --index-offset 0 `
  --index-limit 120 `
  --out "<交付目录之外的 claim-index.json>"

python scripts/prepare_product_value_analysis_packet.py `
  --delivery "<交付目录>" `
  --claim-ids-file "<交付目录之外的 claim-ids.json>" `
  --out "<交付目录之外的 analysis-packet.json>"
```

Claim索引默认每页最多120条，下一页通过增加`--index-offset`读取；定向分析包只保留本次选中的主张索引，不再次附带全量Claim索引。紧凑包必须披露全部事实数、返回数、省略数、索引总数/本页数和选中的真实主张 ID；它只缩短本轮分析上下文，不删除正式账本，也不能把未返回事实解释为不存在。冲突规格、高风险警示、适用边界、关键身份、P0/P1 候选机制与不可读来源缺口必须优先进入选择；需要补充时继续用真实 ID 生成补包，禁止编造编号。

## 建立结构化底稿

按合同填充：

```text
data/product_manifest.json
data/source_inventory.jsonl
data/source_audit_card_ledger.jsonl
data/source_audit_cards/SF-xxx.svg
data/source_observation.jsonl
data/source_claim_ledger.jsonl
data/source_ledger.jsonl
data/fact_ledger.jsonl
data/fabe_ledger.jsonl
data/anchor_ledger.jsonl
data/value_ledger.jsonl
data/p0_decision.json
data/gap_ledger.jsonl
```

稳定编号使用 `PV-`、`SF-`、`OBS-`、`CLM-`、`SRC-`、`ID-`、`ANCHOR-`、`F-/STRAT-/DYN-/U-/EX-/H-`、`V-`、`P0D-` 和 `GAP-`。编号只表示稳定资产身份，不表示优先级；不得固定 `V-001 = P0`。

## 完成商品价值建模

严格按以下顺序执行：

1. 确认商品身份、当前 SKU、版本和标准成交单元；
2. 先生成不可覆盖的真实文件清单和图片审计卡；PDF 拆成 `page_XXX` 图片时，原始 PDF 必须同时保留在清单中作为父来源，派生页图写入 `parent_source_file_id`，仅有该 PDF 及其拆页时 `input_mode=document`；按 `source_file_id` 正序逐张视觉打开审计卡并记录第一遍结果，完成全部图片后再逆序逐张打开，独立记录第二遍结果；两遍标题和摘录必须一致，第一遍时间必须随正序序号递进，第二遍时间必须随逆序复核序号递进；不得事后用固定间隔批量生成时间；
3. 两遍身份核对结束后，第三遍重新打开所有含文字来源，逐条摘录原文主张；完成全部第三遍后，第四遍重新打开并复核原文，禁止两个阶段交叉。对表格逐行、FAQ逐问、对比页逐侧登记，关键主张不得遗漏；含“禁止食用、请勿食用、不宜食用、遵医嘱”等语义的文字必须登记为关键警示，不能通过取消 `warning` 标记绕过；
   同样不能为减少原文摘录而取消 `usage` 等其他真实标记或降低文字密度。
4. 只有全部图片通过 `审计卡哈希一致 + 正序初检 + 逆序复核 + 原文摘录复核` 后才能建立来源账本；来源标题必须与该文件的核对标题一致，来源同时绑定 `source_file_id` 和 `observation_id`；
5. 穷举当前可确认事实，每条直接事实引用原文主张并保留逐字摘录，隔离跨 SKU、历史版本、动态字段和冲突；页面、主图、彩盒或规格区一旦出现互不相容的套组清单、到手件数或装箱内容，冲突双方只能标为待确认，缺口至少为 P1，不得因某一页面更显眼而保留 `active`；
6. 为每个准备进入 P0/P1/P2 或进入 P0 候选池的价值建立独立 FABE 记录，完整写出 Feature、Advantage、Benefit、Evidence、参照系、用户语言、推导状态和边界；Feature、Evidence 和参照系分别通过 `feature_fact_ids`、`evidence_fact_ids`、`reference_fact_ids` 回到本条实际使用的事实，不能只把参照事实挂在 Value 上。三个字段各自出现的数字、引号原文和关键语义成分都必须由对应 ID 列表实际支持，不能借用同一 FABE 的其他事实补链。相同内容不得换 ID 重复计数或重复展示。参数不能直接当用户利益；Advantage 必须写出具体任务差异，禁止用“本品（基于页面内对比信息）”等占位语补齐。“天然”“科学配比”“甜腻”“刺激”“甜品”“免熬煮”“免称量”“洗器具”“不打开包装”“完整的成分表”等词及其“不/不是/并非”等变体，只有在本条 FABE 所引原文或用户资料中直接出现时才能使用；页面写有需要煮制的方式时，不能同时把价值扩写为“免熬煮”。若 Feature、Advantage 或 Benefit 写“由/得益于某工艺实现某结果”或“厚切让商品更耐泡”等因果关系，所引页面原文必须直接建立该因果；否则将工艺与结果拆成独立页面事实，或把因果降为 `to_validate` 待验证推导。竞品或行业资料只是在写市场领先、优于同类、与同类形成差异点或产品替代结论时必需；若页面事实已经能说明当前商品对某个内生任务的作用差异，例如已处理形态减少当次准备步骤、两种明确食用方式增加当前商品内的使用选择，应写成带边界的内生任务优势并标记 `reasoned`，不能因为没有竞品就把全部 A 层判为不成立。`page_supported` 只用于 Advantage 与 Benefit 的完整表述能在本条所引原文中直接找到的情况；出现“用户能看到、用户获得、更容易、便于、可以、无需、减少、根据场景选择”等任务、主体或场景翻译，而原文没有直接写出该完整表述时，必须标为 `reasoned`。只有连内生任务差异也无法形成时，才写“当前资料不足以形成可核对的相对优势，A层暂不成立”，并将 `derivation_status` 标为 `to_validate`，此时 Benefit、参照系与用户语言也不得继续使用产品替代对象或比较结论；标为页面直接支持时，Evidence 至少包含一条 Feature 的直接事实，不能用无关检测页支撑另一种体验利益；没有页面明确对比、竞品页或行业资料时，不虚构“普通产品、无法确认工艺的产品、多配料加工食品、配料不透明的同类食品、单一食用方式产品、需要另购其他形态产品、散装或大包装、无检测引用产品、原料形态不可见或被打碎的冲泡饮品、一包一次的速溶茶、仅写单一冲泡方式的茶、未公开检测认证的茶饮”等替代对象；“而非”同样属于比较关系，不能把无来源的碎料、粉末、散料或需要额外分装的产品写进 A/B；在句尾加“内生任务假设”不能把外部产品对象变成内生任务，也不得把“当前商品内/当前商品自身”写成比较对象；真正的内生参照应直接写当前操作任务，例如“每次取用前是否需要额外分装或密封”。也不得改写成“与多种原料的同类食品相比”“区分其他普通商品”“不需要为不同形态再单独准备”等同义替代，无论比较词位于句首还是句尾；只有引用 `U` 用户原声或研究事实时，才能把用户旧习惯写成参照系，否则改写为页面内具体对比或真正只描述当前商品操作任务的内生假设；
   “称量”“熬煮”“器具”“完整披露”“额外操作”等任务限定词及其否定变体，只有在本条 FABE 或价值所引原文/用户资料中直接出现时才能使用。包装量、片数、盒数、容量和重量只能说明当前规格；“使用周期、频次、减少补货、一次买够、够吃/喝/用一阵”等利益必须由本条所引页面原文或 `U` 用户资料直接出现同类语义，不能自行换算或凭大包装推导。页面列出原料产地只证明页面标示了产地，不自动等于“可追溯”，除非原文明确写出追溯主张或提供追溯系统证据。
7. 分离商品身份、一级识别锚、P0 候选、P1、P2 与 DYN；
8. 建立完整 P0 候选池，将品牌指定方向纳入候选但不自动判胜；已有推荐 P0 时至少保留两个内容不同的用户价值候选，候选必须分别回答不同的用户任务或结果，不能用 SGS、认证标识、营养表、规格参数等 P2 信任信息冒充与核心价值同级的战略候选；这类 P2 信息继续保留为价值支撑。若 P1 中存在可能影响选择的整料可见、持续使用、准备便利或多方式使用价值，应至少检查其中一条是否具备 P0 候选资格，而不是全部排除。`p0_candidate=true` 的价值必须全部进入 `candidate_value_ids`，普通版候选比较必须展示全部候选，包括暂缓候选，并说明每个未入选候选的当前原因；
9. 分别判断战略价值潜力和当前执行成熟度，不机械合并总分；
10. 形成推荐战略 P0 及状态、当前执行主轴、P1、P2、暂缓价值和表达边界；用 `current_execution_value_ids` 按实际调用顺序列出价值，禁止引用 `deferred` 或 `downstream_readiness=blocked` 的价值；`current_execution_axis` 必须固定为“当前执行主轴调用：”加所列价值的 `value_statement` 原文并以中文分号连接，不得自由改写或暗中加入未列价值；另写一段不含内部 ID 的 `public_rationale` 供普通版使用；
11. 写清当前能证明什么、不能证明什么和下一步验证问题；“不能证明”必须置于明确否定标题下，不能让否定对象单独显示成正面结论；
12. 记录资料缺口、完成状态和下游可用范围后停止。

商品身份阶段必须同时填写 `sku_status` 和 `sku_basis`。页面标题与包装规格冲突时，以 SKU 选择器、包装或商品信息区为准；若净含量和小包数量只能确认标准成交单元，就写该成交单元并保留名称缺口，不要继续把标题片段锁定为当前 SKU。四遍读取只能证明记录过程发生过，不能证明 OCR 或肉眼识别正确；`oneBag`、斜杠拼接、单位错位等疑似 OCR 残片不得作为关键规格。总净含量、单包克重、包数、到手件数、套组清单或装箱内容互相冲突时，相关原文、事实和 SKU 一律降为待确认，并禁止进入识别锚、FABE、价值分层和 P0，直到用清晰实物、SKU 选择器、订单成交单元或高可读规格页复核。仅在 boundary/cannot_prove 写出冲突不能抵消正文调用。

每条价值的 `supporting_fact_ids` 只保留真正支撑该价值表述或其 FABE 的事实；配料、营养、规格、工艺等无关事实不能为了增加证据数量而错挂。`cannot_prove` 必须说明当前价值自身尚不能证明什么，不能把另一个价值的比较缺口、功效缺口或用户缺口复制过来。

表达边界采用“公开页面可用、分析推导不扩大”的原则：可以保留页面上的“未经二氧化硫熏制”、检测数值和公开口感主张，但不得扩写成“不引入二氧化硫残留风险”或“零残留”；检测报告不得改写为“安全认证”“安全底线”或笼统安全指标，高于页面所列基准的数值不得改写成“确保品质”，零脂肪或无硫熏不得自动推导“适合控脂/敏感人群”，食品价值不得预设未经资料支持的“滋养收益”“健康食品”或功效。安全性、刺激性或过敏相关检测只能支撑其原文覆盖的安全/刺激类页面主张，不能替代稳定性、活性、失活、孕哺禁忌或其他适用边界证据。配料表只列一种原料，不自动等于“无添加”或“无防腐剂”；储存、气味、咀嚼体验和竞品领先结论必须有直接资料。优惠、券、赠品和其他权益只有原文明确说明时才能写“可叠加”。口感词和使用限制必须逐字继承，不得把“回甜”换成“回甘”，不得把“适合泡水、煲汤”缩成“仅适合泡水”，也不得根据“麻舌、刺激咽喉”等体验描述自行增加“不宜直接食用”等限制性结论。用户利益不得写成“不用担心、无需担心、不必担心”等绝对化保证，应写成“减少相关顾虑”并保留资料边界。

交易叠加规则必须检查价值账本的全部文本字段，包括暂缓价值；不得在 `user_task` 或 `user_perception_goal` 写“叠加优惠/可叠加”，同时又在 `cannot_prove` 承认原文没有叠加依据。

页面截图和详情页图片可以证明其清楚展示的大字主张、机构、检测项目和结果，但一律不能把报告编号、日期、批次、证书编号、检测方法及 `GB/GB-T/ISO/SN-T/NY-T` 等方法标准代码的小字精确值写进观察、来源、事实边界、FABE、价值、P0 决策、缺口或普通版，证据细节可信度最高为 `medium`。只有报告原件/PDF可定位文本或官方验证页，才允许 `exact_fields_verified=true`，并必须填写 `verification_locator`；精确值进入任何下游字段前，必须先存在于这条原件级事实。不得把“反复蒸晒”扩写成“九蒸九晒”，也不得把“入口温和”扩写成“无刺激”，不得把“二氧化硫”误写为“二次硫”。

价值适用范围默认只覆盖当前已分析 SKU 或标准成交单元。只有每条支撑事实都明确覆盖全部 SKU 时，才允许写“全 SKU 适用”；`sku_status=partial/unverified` 时不得主动扩大范围。

P0 必须是一个简洁、不可拆的用户价值，只保留一个核心用户变化。不要在同一句同时叠加口感、咖啡因/刺激物、额外加料、冲泡方式、整天饮用、多个场景和信任证据；其余内容下沉到 P1、P2、FABE 或证据说明。P0 不得只写成分、技术名、包装、价格或赠品。可拍性、页面篇幅、出现次数、覆盖页数、识别度、已有呈现或单次内容表现都不能单独决定 P0。没有 `U` 用户原声或研究资料时，只能写“待验证用户问题”，不得写“最常见、主流、普遍、很多人、大多数用户、消费者普遍如何”，也不得把某项问题直接称为用户的核心、主要或关键顾虑。页面只写“担心咖啡影响睡眠”时，只能作为用户场景线索；除非逐字原文明确写出本品“无咖啡因/不含咖啡因”，不得把商品价值改写为“不靠咖啡因”或“不依赖咖啡因”。页面只支持“未经二氧化硫熏制”时，不得把用户任务扩写成对安全、健康、危害或风险的担心。

## 生成普通版交付

结构化底稿完成后，先预检、再生成：

```powershell
python scripts/build_product_value_report.py --delivery "<输出目录>" --dry-run
python scripts/build_product_value_report.py --delivery "<输出目录>"
```

正式构建会在生成两份报告前，用宿主实际时钟自动刷新 `product_manifest.updated_at`；不要由模型手工填写、取整、推算或事后改写收口时间。Dry Run 不修改 manifest。

普通入口只保留：

```text
01_商品价值底座.md
02_资料说明与缺口.md
```

`01` 回答“这是什么、为什么值得选、凭什么信”，固定展示用户问题、FABE 价值证据链、当前可调用的 P0/P1/P2、为什么这样分层和条件式下游接口；暂缓或禁止调用的价值不进入正式价值清单，但如果它属于 P0 候选，仍必须出现在“核心价值候选比较”中并说明未入选原因。`02` 说明资料来源、成熟度、冲突、未知、停止边界和下一步补充。普通版隐藏 `PV-/SF-/OBS-/CLM-/SRC-/F-/FABE-/V-` 等内部资产 ID，以及 `partial`、`active_at_snapshot`、`cannot_prove`、`user_task`、`user_perception_goal`、`read`、`STRAT`、`U`、`F-EVIDENCE`、`DYN`、`updated_at`、`ZIP`、缺口英文分类和 P0 英文状态码等内部术语；删除内部 ID 或把单字母内部类型翻译成中文后，必须重写完整句子，不能留下“在 包装面……”“/ / 等候选”“独立 用户原声”“用户原声 用户资料”“继承P0状态”或“.压缩包”等残句。完整底稿放入 `data/`，供后续 Skill 或审计继续使用。交付根目录不得携带事后修正脚本或可执行文件。

## 校验正式交付

把 `product_manifest.json` 的 `analysis_status` 更新为 `complete`、`partial`、`insufficient` 或 `stale`，再运行：

```powershell
python scripts/validate_product_value_delivery.py --delivery "<输出目录>"
```

只有退出码为 `0` 才能作为正式交付。校验会检查商品与 SKU 冲突、规格算术和跨页包数冲突、疑似 OCR 残片、冲突规格是否继续进入锚点/FABE/价值/P0、压缩包是否被误当作页面来源、原始 PDF 与拆页图片的父子来源身份、交付根目录、审计卡是否真实内嵌清单中对应原图、审计卡哈希、核验事件是否晚于 `created_at`、正序初检与逆序复核的真实时间顺序、固定节奏、少量整数微间隔、整组时间平移与晚于账本文件的可疑时间、第三遍是否全部完成后才开始第四遍、最终账本和报告是否在 `updated_at` 后继续修改、普通版是否由当前结构化账本原样生成、动态活动年份和时区、关键警示、复合事实逐字段回链、逐字主张是否被摘要替代、事实原文引用、数字、口感词与使用限制是否能回到原文、页面截图的小字证据跨字段绕过、FABE 重复、Feature/Evidence/参照系三类事实的逐字段数字、引号和语义回链、`page_supported` 的 A/B 全文直接性、限定词及否定变体、因果关系与比较依据、把当前商品自身写成比较对象、占位式 Advantage、含“而非”的无来源产品替代对象、A 层暂不成立后的比较残留、价值支撑事实相关性、`cannot_prove` 是否错挂到其他价值、P0 是否堆叠过多事实和场景、低战略信息且无竞争对照时是否仍把 P0 写成已选择、无用户证据的旧习惯参照和用户排名词、绝对化利益、交易叠加证据、来源和事实引用、稳定 ID、价值适用范围、完整 P0 候选池、候选展示、完成状态、资料缺口、SKU 缺口与名称的跨字段矛盾、结构化账本与普通版中的重复词、空括号、缺少结论对象的残句、内部字段删减残片、其他占位符和下游边界。

校验还会反向核对边界中声明的克重冲突是否完整进入原文账本，并拒绝通过移除观察标记、降低文字密度来逃避摘录，以及把原料产地扩大成无证据的“可追溯”。

## 判定完成状态

- `complete`：已确认商品与 SKU，完成事实、价值候选、P0 决策、P1/P2、证据边界和资料缺口；P0 可以是明确标注的假设，不代表已被市场验证。
- `partial`：已形成可用价值底座，但事实、战略、证据、用户或竞争资料存在影响使用的缺口。
- `insufficient`：无法确认商品/SKU或没有足够事实形成可靠价值，只输出资料说明与缺口。
- `stale`：新增资料、SKU、证据或战略输入挑战当前版本，旧输出停止下游使用。

完成表示对本次输入完成建模，不表示商品功效、竞争优势、用户心智或成交效果已获得独立验证。

## 严格停止在商品价值

本 Skill 不得：

- 自动把不可访问链接写成已读取；
- 混用不同商品、SKU、历史版本或动态权益；
- 把品牌战略愿望写成用户已认可事实；
- 把评论频次写成商品事实或自动决定 P0；
- 把成分、技术、识别锚、价格或赠品直接写成用户价值；
- 把页面显眼、好拍或已有素材多写成战略优先级；
- 编造添加量、功效、比较结论、绝对承诺或第一人称体验；
- 生成 VIS、卖点呈现卡、拍摄动作、画面、声音、字幕或道具方案；
- 生成选题、钩子、内容方向、完整信息链、脚本或 Brief；
- 判断某个达人是否适合商品或生成达人合作策略；
- 将点击、互动、求链接或自报购买写成成交归因。

完成后把当前有效的 `product_manifest.json`、`fact_ledger.jsonl`、`value_ledger.jsonl` 和 `p0_decision.json` 交给 `brandbai-value-expression` 或后续商品匹配 Skill；下游不得改写上游事实和 P0 决策。