注：本技能主锚行业已切换为 ai-video（视频内容创作）；文中酒店示例为历史参考案例。
行业标杆竞品深度调研方法论
一、技能定位
1.1 这个技能解决什么问题
当HyperReality决定进入一个新行业（如酒店、餐饮、美业、教培）时，第一个要回答的问题是：这个行业的标杆玩家是谁？他们跑出了什么被验证过的产品模式？HyperReality与之相比，差异化机会在哪里？
这个技能就是回答这个问题的"元方法论"。它不是调研某个具体竞品的功能列表，而是拆解一个标杆企业从"产品定位"到"战略逻辑"的完整骨架，找出其被市场验证的模式本质，并识别HyperReality可以切入的差异化空间。
1.2 何时调用
- HyperReality决定进入一个新行业，行业Bundle开发启动前
- 行业内出现新的标杆产品/范式，需要重新评估竞争格局时
- 已有行业Bundle需要迭代升级，需要重新对标行业最新标杆时
- 投资/合作决策前，需要深度理解目标行业头部玩家时
1.3 调用者
- 行业交付工程师（负责行业Bundle开发）
- 产品战略团队（负责HyperReality行业进入决策）
- 商务团队（负责行业合作伙伴评估）
1.4 与其他技能的关系
本技能与技能二是并行独立的两个调研技能，两者的产出共同作为技能三的输入：
技能一（竞品调研）──┐
├──→ 技能三（落地完整方案设计）──→ 可交付研发团队的方案
技能二（一线调研）──┘ ↑
│
HyperReality底座（代码+PRD兜底）
- 输出 → 技能三（HyperReality行业落地方案设计）：差异化竞争点分析，直接指导落地方案的定位策略
- 与技能二无先后依赖：两者可在同一行业并行执行；若技能二已完成，其产出可作为本技能的参考输入之一（非必需）
- 引用HyperReality能力前，必须执行附录A的"动态读取前置环节"
二、适用场景
2.1 典型场景
场景一：新行业进入调研 HyperReality决定进入餐饮行业，需要找到餐饮SaaS/AI领域的标杆玩家（如美团SaaS、客如云、哗啦啦等），深度拆解其产品模式，找出HyperReality的差异化机会。
场景二：标杆产品范式跃迁追踪 酒店行业的订单来了从"PMS厂商"跃迁为"AI操作系统厂商"，这种范式跃迁值得深度拆解——它为什么转型？转型后的产品架构是什么？对HyperReality有什么启示？
场景三：竞争格局变化评估 行业内出现新的强力竞争者（如通用AI巨头进入），需要重新评估竞争格局，调整HyperReality的差异化定位。
2.2 不适用场景
- 单一功能点的竞品对比（用轻量对比表即可，不需要全量调研）
- 通用AI工具的调研（通用AI不是行业标杆，缺乏行业数据壁垒）
- 集团连锁市场的竞品调研（HyperReality目标客群是中小单体，集团市场不重叠）
三、方法论：六维全量拆解
3.1 核心原则
原则一：全量拆解，不留盲区。 标杆企业的产品定位、功能模块、技术架构、客群定价、差异化竞争、行业趋势，六个维度必须全部覆盖。任何一个维度的遗漏，都可能导致对竞品的误判。
原则二：信息溯源，不编造数据。 所有调研结论必须标注信息来源（官网/新闻/行业报告/合理推测）。公开信息不足的部分，明确标注"推测"，不得编造。
原则三：战略逻辑推演，不停留在功能列表。 拆解标杆企业不能只看"它有什么功能"，必须推演"它为什么这么做"——背后的战略逻辑是什么？这个逻辑是否成立？对HyperReality有什么启示？
原则四：差异化导向，不是为了调研而调研。 调研的最终目的是找到HyperReality的差异化机会。每个维度的拆解，结尾都要回答"HyperReality与之相比，差异化方向在哪里？"
3.2 六维拆解框架
维度一：产品定位与核心卖点
拆解目标：理解标杆企业"是什么"和"卖什么"。
拆解步骤：
- 企业演进历程：这家公司从成立到现在，经历了哪些阶段？每个阶段的核心业务是什么？为什么发生转型？（转型往往揭示了行业趋势和企业战略判断）
- 当前产品定位：用一句话概括其产品定位。这个定位包含几层含义？（如订单来了"PMS记录发生了什么，AI操作系统回答接下来该做什么"包含"从记录到执行""从通用AI到行业Agent""从单点到操作系统"三层）
- 核心卖点提炼：对外传递的核心卖点有哪些？（通常3-6个）每个卖点背后的潜台词是什么？它针对的是哪个痛点？
- 定位的战略逻辑推演：为什么选择这个定位？它对抗的是什么威胁？它占据的是什么品类认知？
输出要求：
- 企业演进时间线（含转型节点和原因）
- 产品定位的一句话概括 + 多层含义拆解
- 核心卖点清单（每个含"卖点表述+针对痛点+潜台词"）
- 定位战略逻辑推演（3条以上）
- Mermaid图表：定位架构图、定位对比矩阵
维度二：功能模块深度拆解
拆解目标：理解标杆企业"能做什么"和"怎么做的"。
拆解步骤：
- 功能全景梳理：标杆企业的全部功能模块有哪些？（通常5-7大模块）这些模块是"单点能力"还是"系统整合"？
- 每个模块深度拆解：对每个功能模块，拆解其工作机制（输入→处理→输出闭环）、关键设计原则、边界约束（什么不做）。
- 功能设计的共性原则提炼：纵观所有模块，提炼出3-5条功能设计的共性原则（如"AI做执行人做判断""基于真实数据而非凭空生成"）。
- 功能成熟度评估：哪些功能已上线运营？哪些还在规划？已上线功能的验证程度如何？
输出要求：
- 功能全景脑图（Mermaid mindmap）
- 每个模块的工作机制流程图（Mermaid flowchart）
- 功能设计共性原则清单
- 功能成熟度矩阵
- Mermaid图表：功能脑图、模块流程图、功能对比象限图
维度三：技术架构推测
拆解目标：理解标杆企业"怎么实现的"。
拆解步骤：
- 整体架构推测：基于公开信息（发布会、产品更新日志、官网功能描述、行业通用架构），推测其技术架构分层（通常3-5层）。
- 关键技术组件识别：识别其架构中的关键技术组件（如PMS CLI、AI浏览器、Skill引擎、大模型路由等），推测每个组件的技术实现。
- 架构层面的关键设计：推测其架构层面的3-5个关键设计（如"唯一事实源""全程留痕""权限校验前置"）。
- 与HyperReality架构对比：每个关键设计，与HyperReality的对应机制对比（如"唯一事实源"对应HyperReality的"五元事件库"）。
输出要求：
- 技术架构分层图（Mermaid graph）
- 关键技术组件清单（含推测实现方式）
- 架构关键设计清单（含与HyperReality对比）
- 明确标注"基于公开信息推测，非官方披露"
- Mermaid图表：技术架构图、架构对比图
维度四：目标客群与定价策略
拆解目标：理解标杆企业"卖给谁"和"怎么收费"。
拆解步骤：
- 客群演进历程：标杆企业的目标客群经历了哪些阶段？每个阶段的客群画像是什么？为什么发生客群扩展？
- 当前客群画像：业态、规模、客单价、地域、经营者画像、数字化程度、核心痛点。
- 与HyperReality目标客群的对比：重叠区域在哪里？各自独占的客群在哪里？
- 定价体系分析：版本划分、价格区间、功能范围、目标客群。AI功能的定价模式推测。
- 对HyperReality定价的启示：HyperReality可以采用什么差异化定价模式？
输出要求：
- 客群演进时间线
- 当前客群画像表
- 客群对比图（Mermaid，标注重叠和独占区域）
- 定价体系表
- 对HyperReality定价策略的建议
- Mermaid图表：客群对比图、定价策略图
维度五：与HyperReality的差异化竞争点
拆解目标：回答"HyperReality与之相比，差异化机会在哪里？"
拆解步骤：
- 多维度系统对比：从底座、自治能力、夜班能力、审计能力、围栏精细度、生态模式、定价模式等维度，系统对比标杆企业与HyperReality。
- 标杆企业的优势识别：它在哪些方面有先发优势？（HyperReality需补齐什么？）
- HyperReality的潜在优势识别：HyperReality在哪些方面有差异化优势？（标杆企业尚未覆盖什么？）
- 差异化竞争策略建议：基于以上分析，HyperReality应采取什么差异化竞争策略？（通常3-5条）
输出要求：
- 多维度对比矩阵（Mermaid）
- 标杆企业优势清单（HyperReality需补齐）
- HyperReality差异化优势清单
- 差异化竞争策略建议（3-5条，每条含具体执行方向）
- Mermaid图表：差异化维度对比图
维度六：行业趋势判断
拆解目标：理解"这个行业往哪里走"和"HyperReality怎么卡位"。
拆解步骤：
- 行业演进时代划分：将行业数字化的历程划分为若干时代（通常3个），每个时代的核心能力、价值、局限。
- 演进路径推演：基于时代划分，推演行业未来的演进路径（通常5个阶段），每个阶段的特征和触发条件。
- "AI替代SaaS"的深度判断：AI是否会替代传统SaaS？SaaS的哪些部分会被替代？哪些不会？SaaS厂商的转型路径有哪些？
- 行业格局预判：未来1-3年，行业格局会如何演变？梯队如何划分？
- 对HyperReality的战略启示：基于趋势判断，HyperReality应采取什么战略？（通常3-5条启示）
输出要求：
- 行业演进时代划分图（Mermaid）
- 演进路径推演图（Mermaid）
- "AI替代SaaS"判断（含会被替代/不会被替代的清单）
- 行业格局预判图（Mermaid，含梯队划分）
- 对HyperReality的战略启示清单
- Mermaid图表：时代演进图、五阶段路径图、行业格局图
四、输入契约
4.1 必需输入
| 输入项 | 说明 | 来源 |
|---|---|---|
| 目标行业 | 要调研的行业名称（如酒店、餐饮、美业） | 调用者指定 |
| 标杆企业/产品 | 要深度拆解的标杆企业或产品名称 | 调用者指定 |
4.2 推荐输入
| 输入项 | 说明 | 来源 |
|---|---|---|
| 标杆企业官网 | 产品介绍、功能列表、定价信息 | web-reader抓取 |
| 行业媒体报道 | 发布会、产品更新、创始人访谈 | web-search + web-reader |
| 行业报告 | 市场规模、客群画像、竞争格局 | web-search |
| 标杆企业产品体验 | 注册试用、功能体验（如可能） | 人工体验 |
4.3 输入校验
- 标杆企业必须在目标行业内有"被验证过的产品模式"（有付费用户、有市场认知），否则不适用本技能
- 公开信息不足时，明确标注"信息不足"，不得编造
五、输出契约
5.0 执行前置：时效性与置信度校验（v1.1 新增，强制）
调研开始前必须执行：
- 最新信息检索：对标杆企业做一次最新公开信息检索（发布会、产品更新日志、官网变更），并在文档头部标注信息截止日期（如"信息截止2026-08-21"）。
- 竞品数据置信度分级：竞品公开宣称的所有数据（用户数、商家数、转化率等）必须标注置信度——A级（有独立第三方来源交叉验证）/ B级（仅企业官方口径）/ C级（讲者现场引用、来源不明，如"90%的旅游出行决定在小红书发生"，C级数据不得作为决策依据）。
- 禁止编造：公开信息不足处标注"信息不足"，合理推演处标注"推测"。
- 历史产出复核：若同一主题存在历史产出，先按第九节进入"迭代融合模式"，复核旧结论时效性。
5.1 输出物
一份完整的竞品脑暴文档，Markdown格式，包含：
- 调研说明（信息来源、调研时间、信息截止日期、推测标注）
- 第一章：产品定位与核心卖点拆解
- 第二章：功能模块深度拆解
- 第三章：技术架构推测 + 目标客群与定价策略 + 与HyperReality差异化竞争点
- 第四章：行业趋势判断
- 可选附录：多竞品横向对比（行业内存在2个以上标杆时，增加横向对比矩阵，避免单一标杆视角偏差）
5.2 输出规格
| 规格 | 要求 |
|---|---|
| 格式 | Markdown，使用Mermaid语法绘制所有图表 |
| 字数 | 不少于30000字（分4章输出） |
| Mermaid图表 | 至少6张（架构图、流程图、对比矩阵、功能脑图等） |
| 信息溯源 | 所有结论标注来源（公开报道/官网/推测） |
| 抽象适配 | 每个模块结尾说明"如何抽象适配到其他行业" |
5.3 输出校验
- 六个维度是否全部覆盖？
- 每个维度是否有Mermaid图表？
- 所有Mermaid图表在最终交付物中是否已实际渲染为图形（渲染率100%，禁止只交付代码块）？
- 所有信息是否标注来源？
- 竞品宣称数据是否完成置信度分级（A/B/C级）？
- 文档头部是否标注信息截止日期？
- 是否有"对HyperReality的启示/差异化建议"？
- 是否有"抽象适配到其他行业"的说明？
- 字数是否达标（≥30000字，融合模式下以"旧+新增补"合计信息量计）？
- 迭代融合模式下：是否包含新旧对比表、冲突裁决记录、融合结论？
六、质量标准
6.1 深度标准
- 不停留在功能列表：必须推演"为什么这么做"的战略逻辑
- 不编造数据：公开信息不足时明确标注"推测"
- 不遗漏维度：六个维度必须全部覆盖
- 不空泛描述：每个结论必须附带逻辑推导
6.2 可执行性标准
- 差异化竞争策略必须具体可执行（不能是"要做好产品"这种空话）
- 对HyperReality的启示必须能转化为具体的行动项
- 抽象适配说明必须能指导其他行业的调研
6.3 格式标准
- Mermaid图表必须可复制到支持Mermaid的编辑器直接渲染
- 表格必须规范（表头、对齐、内容完整）
- 层级必须清晰（一级标题→二级标题→三级标题）
七、抽象适配说明
7.1 本技能的复用性
本技能是行业无关的元方法论。六维拆解框架（定位+功能+架构+客群定价+差异化+趋势）适用于任何行业的标杆竞品调研。
7.2 适配到其他行业的步骤
- 识别行业标杆：找到该行业中"跑出被验证产品模式"的标杆企业
- 替换行业词汇：把"酒店"替换为目标行业词汇（如"餐饮""美业"）
- 保持六维框架不变：六个维度的拆解框架完全复用
- 行业特定调整：根据行业特点，调整某些维度的拆解重点（如餐饮的"渠道管理"重点是外卖平台，酒店的"渠道管理"重点是OTA）
7.3 已验证的行业
- ✅ 酒店行业（订单来了AI操作系统调研，已验证框架可行性）
- 🔜 餐饮行业（客如云/美团SaaS调研，待执行）
- 🔜 美业行业（待识别标杆）
- 🔜 教培行业（待识别标杆）
八、调用示例
8.1 调用模板
调用技能：industry-benchmark-research
输入：
- 目标行业：餐饮
- 标杆企业：客如云
- 推荐输入：客如云官网、餐饮行业媒体报告、产品体验
输出：
- 餐饮行业标杆竞品深度调研文档（≥30000字，≥6张Mermaid图表）
8.2 与HyperReality底座的集成
本技能作为"行业进入方法论"技能，建议：
- 归类为official套件（随HyperReality底座分发）
- 安装后由行业交付工程师Agent调用
- 输出文档存入组织记忆，供后续行业Bundle开发引用
- 调研结论中的"差异化竞争点"可固化为围栏规则（如"不与XX竞品在XX维度正面竞争"）
九、交付质量门禁与迭代融合规则（v1.1 新增）
9.1 交付质量门禁（Pre-Delivery Gate）
交付前必须逐项过门禁，任何一项不通过则禁止交付：
| 门禁项 | 标准 | 检查方式 |
|---|---|---|
| 图表渲染率 | 所有Mermaid图表在最终交付物（PDF/HTML等）中实际渲染为图形，渲染率100% | 逐张目检，禁止出现"只有代码块或空白占位"的图 |
| 信息截止日期 | 文档头部明确标注信息截止日期 | 目检 |
| 置信度标注 | 竞品宣称数据完成A/B/C级标注 | 抽查关键数据 |
| 推测标注 | 所有推测内容明确标注"推测" | 抽查 |
| 章节完整性 | 六维全覆盖，每维有图表有结论 | 对照5.3清单 |
教训来源：v1.0产出的PDF中全部Mermaid图表丢失为空白，且技能未规定交付物渲染要求。v1.1起"图表实际渲染"为一票否决项。
9.2 迭代融合模式（同一主题已有历史产出时）
当调用者提供同一主题的历史产出时，本技能切换为迭代融合模式，产出物为"融合版"而非"覆盖版"：
- 对比（Diff）：逐章对比历史产出与新调研结论，产出差异清单——旧内容仍有效/旧内容已失效/新内容增补/新旧冲突四类。
- 增补（Augment）：新产出聚焦"旧版缺失或已过时"的部分——更新的公开信息、旧版缺失的维度深化、旧版未渲染图表的重绘。
- 融合（Merge）：产出单一整合文档，要求：
- 旧内容全文保留（已失效的标注"已被vX更新取代"而非删除，保留演进痕迹）
- 新内容以"【增补】"小节并入对应章节
- 每章结尾设"【融合结论】"小节，给出整合后的最终判断
- 新旧结论冲突时：新证据优先；证据不足无法裁决时并列呈现并标注"分歧待验证"
- 卷首附"新旧对比一览表"（章节 | 旧版覆盖 | 新版增补 | 融合后状态）
十、版本记录
| 版本 | 日期 | 变更 |
|---|---|---|
| v1.0 | 2026-08-20 | 初始版本，基于酒店行业订单来了调研实践抽象 |
| v1.1 | 2026-08-21 | 新增：交付质量门禁（图表渲染率一票否决）、迭代融合模式（对比→增补→融合）、时效性校验（信息截止日期）、竞品数据置信度分级（A/B/C）、多竞品横向对比可选附录 |
附录A：HyperReality底座上下文（动态读取前置环节 + 兜底摘要）
本技能的产出需要频繁引用HyperReality的定位与能力（差异化对比、AI替代映射、SOP/Skills设计）。HyperReality是活的开源项目，禁止凭记忆引用其功能。执行前必须按 A.1 动态读取最新代码；代码不可得时按 A.2 兜底摘要执行并显著标注。
A.1 前置环节：HyperReality最新代码动态轻量读取（强制）
读取目标：HyperReality开源仓库 https://github.com/workloom-ai/workloom-im（主干即可，无需全量clone历史）。
轻量读取清单（按优先级，预计10-20分钟）：
| 优先级 | 路径 | 提取什么 |
|---|---|---|
| P0 | README.md | 产品定位、仓库地图、最小跑通路径、当前版本状态 |
| P0 | bundles/hotel/bundle.json（或目标行业bundle） | 该Bundle提供的资产清单（presets/fences/skills/schemas/ui）与版本号 |
| P0 | bundles/<行业>/fences/*.yml | 基线围栏规则（rule_id/level/when表达式/default_level） |
| P1 | bundles/<行业>/schemas/objects.json、stages.json | 经营对象枚举、经营阶段枚举（现有多少类，扩展空间） |
| P1 | bundles/<行业>/presets/*.yml | Agent班组清单与各自围栏绑定 |
| P1 | bundles/<行业>/skills/*/SKILL.md | 已有官方Skill的功能边界（避免重复设计） |
| P2 | packages/shared/src/event-schema.ts | 五元事件schema字段（Who/Context/Object/Decision/RuleImpact）与冻结范围 |
| P2 | packages/base/各包文件头注释 | 九域能力的关键设计约束（围栏三级/哈希链/夜班状态机等） |
| P2 | docs/03-功能清单-用户版.md、docs/DECISIONS.md | 用户版功能全表、关键架构决策（ADR） |
| P3 | CHANGELOG.md | 最近变更（判断能力演进方向） |
读取产出（写入调研/方案文档的"HyperReality底座上下文"小节）：
- 底座能力清单：本次读取确认存在的能力（标注代码路径）
- 目标行业Bundle现状：对象/阶段/围栏/Agent/Skill的数量与清单
- 引用锚点表：本报告引用的每个HyperReality能力 → 对应代码路径或规则号
- 读取时间戳：如"代码快照：2026-08-21 main分支"
代码不可得时的兜底：使用 A.2 摘要，并在产出物头部标注："⚠️ 本报告的HyperReality能力引用基于兜底摘要（PRD V2.5 + 2026-08-21代码快照），未经实时代码核验，关键结论建议复核。"
A.2 HyperReality定位与能力兜底摘要（PRD V2.5 + 2026-08-21代码快照提炼）
一句话定位：HyperReality是企业级 Agent IM——以消息（五元事件）为唯一事实源、以规则围栏为行动权限边界、以三态会话（Ask/Agent/Quest）为人机分工范式的人机协作网络。不是工作台（工作台只是交互皮肤）、不是传统SaaS（它按意图动态组装能力）、不是单个智能体（Agent班组只是它雇佣的"数码员工"）。人只做三件事：供给（定目标/给素材）、裁决（围栏审批拍板）、沉淀（固化SOP为技能），其余执行、巡检、对账、夜班值守全部交给Agent班组。
架构分层：L0 基础设施（PostgreSQL 17+pgvector，本地优先/数据主权）→ L1 运行时（DeepSeek Harness，vendor锁定rc.8）→ L2 Base Bundle（九域能力，底座不内置行业词汇）→ L3 行业Bundle（六装配槽填充）→ L4 客户Patch（只可收紧不可放宽）。
九域能力清单（代码已实现）：
| 域 | 包 | 关键能力 |
|---|---|---|
| 数据大脑 | workdata | 五元事件库（append-only + SHA-256哈希链 + 幂等）；安全网关三段瀑布（权限→PII脱敏→高危授权）；组织记忆（workspace/agent/run三级作用域，preference/pattern/sop/forbidden四类，pgvector语义检索） |
| 围栏引擎 | fence-engine | auto/review/block三级判定（deny优先、求值异常按block"宁可错杀"）；YAML围栏包DSL（沙箱表达式，禁eval）；基线单调守卫（is_baseline规则只可加严）；dry-run回放10条历史事件验证；对象级写锁 |
| 审批触达 | review-console | 统一审批队列；三手势（采纳/编辑后采纳/驳回，驳回必填原因）；审批卡片为IM原生消息（inapp/钉钉/企微/飞书/Slack）；高危项不过期自动放行；驳回回流为记忆校准样本 |
| IM通道 | im-channels | 入站消息五元化、幂等去重；外部通道经dsh-im插件 |
| 夜班班组 | night-shift | 18:00候选清单→22:00-08:00围栏内自治→08:30清晨决策包（已完成/待审批/需介入三栏，≤20条）；一键暂停≤60s；自研cron触发器；夜班动作100%过围栏（版本快照） |
| 巡检中心 | inspection | 只读巡检（工具集裁剪保证）；异常分级P0/P1/P2聚合推送防风暴；一键派单回链；检项由行业包定义 |
| 技能市场 | skills | official/team/industry三级（industry上架必须脱敏）；安装即绑定围栏、卸载即收缩；forge零代码自建（触发/步骤/边界三要素）；安装前必须dry-run；意识系统（同类动作≥3次/周产出固化建议） |
| 多租户 | tenancy | 四版本能力矩阵：community（无Quest/夜班/巡检）/pro/teams/vpc；越版访问403+升级提示 |
| 模型路由 | model-router | 记忆复用优先→确定性任务分级→峰谷窗口（22:00-08:00谷时费率≤20%）→降级链→熔断；逐事件计量（账单=事件投影）；降级写事件禁静默换模型 |
五元事件模型：Who（human/agent/system）× Context（tenant/workspace/time/channel/stage）× Object（行业化枚举）× Decision（action/before/after/basis/memory_refs）× RuleImpact[]（rule_id/version/result）。附加：Receipt回执（未核实不得转完成）、ModelTrace（逐事件模型计量）。schema v1冻结，行业仅可在context/object/decision内loose扩展。
执行面五级分层：L1官方API（零token主路径）→ L2确定性适配器 → L3确定性剧本（AI浏览器模拟，频次自律）→ L4自主探索（冷启动，探明后固化为L3）→ L5人工接管（进决策包"需介入"栏）。
酒店行业Bundle现状（2026-08-21代码快照，bundles/hotel v1.0.0，演示Bundle）：
- 7个Agent preset：pricing-agent / review-agent / reconcile-agent / inspection-agent / content-agent / competitor-agent / desktop-agent
- 基线围栏R1-R6（default_level=review）：R1房价涨幅≤8% auto；R2保底价¥380 block；R3新渠道首发改价/发布必审；R4退款≥¥500必审；R5担保订单异常block；R6差评必审
- 3个官方Skill：revenue-manager / review-crisis / channel-reconciler
- 经营对象8类：room_type/room_price/channel/order/guest/review/store/staff
- 经营阶段5个：ramp（爬坡）/stable（稳定）/peak（旺季）/off_season（淡季）/turnaround（调整）
- 一店一档Schema + UI用例（cases.json）
行业可配置范围（六装配槽）：①档案Schema（一X一档）②对象与阶段枚举 ③工具集（MCP优先，每动作标注读/写）④围栏包（阈值默认值行业定、客户patch只收紧）⑤Agent班组preset（未声明fence_bindings禁止写动作）⑥工作台UI。全局枚举与五元事件v1 schema冻结不可改；写类动作前缀可经registerWriteActions扩展；模型任务分级表与降级链可按工作区覆盖。
质量与验收基线：371条全场景测试套件（域A-Q）+ dsh-gate崩溃重放/验链/幂等门禁；全局验收口径G1-G11（如事件检索P95≤3s、夜班成本谷时≤20%、留痕100%）。
版本补充记录
| 版本 | 日期 | 变更 |
|---|---|---|
| v1.2 | 2026-08-21 | 修正技能关系：技能一/二并行独立（原"输出→技能二"依赖删除）；新增附录A——HyperReality最新代码动态读取前置环节（P0-P3读取清单+读取产出要求）与兜底能力摘要（PRD V2.5+2026-08-21代码快照），禁止凭记忆引用HyperReality功能 |