Requirement Sharpening Stone

操作说明

操作一：三步对话拆解

• 功能：用苏格拉底→第一性→奥卡姆三步,把模糊需求拆成清晰骨架
• 输入：用户的项目背景(一句话或一段描述均可)
• 输出：真实目标一句话 + 1-3 个必要条件 + 精简后的功能清单 + 不做清单

操作二：PRD 产出

• 功能：按章节裁剪表产出 PRD v1.0,迭代到 v3.x 终稿
• 输入：三步对话产出 + 物料(参照物料/数据分析/继承清单)
• 输出：飞书文档格式的 PRD v3.x(章节按需裁剪)

操作三：多角色 Review

• 功能：四端(服务端/客户端/测试/设计)并行 review,分级反馈闭环
• 输入：PRD v2.x
• 输出：review 反馈汇总 + PRD v3.x 终稿 + 决策记录

操作四：场景定位(Agent 产品专用)

• 功能：交互模型选型 + 核心场景设计 + PageContext 协议
• 输入：产品方向描述
• 输出：交互模型决策 + 场景故事线 + PageContext 字段清单

操作五：Agent 交互设计(Agent 产品专用)

• 功能：三步确认链路 + 交互状态机 + 快捷工具设计
• 输入：PRD v3.x
• 输出：交互设计文档 + 状态机 Mermaid 图

操作六：学习循环 + 分期(Agent 产品专用)

• 功能：日志架构 + 经验库三层设计 + P0-P3 分期规划
• 输入：PRD v3.x + 交互设计
• 输出：日志规范 + 经验库设计 + 分期规划文档

工具定义

本 Skill 为纯流程编排型,不直接调用 MCP 工具。依赖以下内置能力：

---

需求磨刀石 v2

一句话:让 PM 的第一版 PRD 少返工 50%。从命题到可交付的 PRD 终稿,6 个 Stage 按需裁剪。

使用方式

按需启用 Stage,不用全跑。默认启用 Stage 1-3(三步对话 → PRD 产出 → Review),其余按需叠加:

快速启动:跟用户说"帮你写 PRD"→ 自动启用 Stage 1-2-3。 完整流程:跟用户说"帮我跑完整流程"→ 全部启用。

输出格式:所有文档产出优先飞书文档,降级写本地 MD。PRD 文档章节支持按需裁剪(Phase 2.3 会先让你勾选需要的章节)。

---

输入参数

本 Skill 接受以下可选输入(不提供则在运行中追问):

触发示例:

• 帮我写 PRD → 自动走 Stage 1-2-3
• 跑完整流程 → 全部 Stage
• 写个迭代 PRD → Stage 1-2-3 + 自动识别为迭代模式

---

错误处理与边界情况

---

前置条件

• ✅ 用户能描述项目背景(哪怕是模糊的一句话)
• ✅ 有基本的飞书文档权限(如选飞书输出)
• ❌ 不需要已有代码/设计稿/技术方案
• ❌ 不需要特定工具或环境

全景流程图

┌──────────────────────────────────────────────────────────────────────┐
│                      需求磨刀石 · 按需裁剪                           │
├──────────┬──────────┬──────────┬──────────┬──────────┬──────────────┤
│  Stage 0 │  Stage 1 │  Stage 2 │  Stage 3 │  Stage 4 │   Stage 5    │
│  场景定位 │ 三步对话  │ PRD 产出  │  多角色  │  Agent   │   学习循环    │
│  (可选)  │ (默认)   │ (默认)   │  Review │  交互设计 │   + 分期      │
│          │          │          │ (默认)  │  (可选)  │   (可选)      │
├──────────┼──────────┼──────────┼──────────┼──────────┼──────────────┤
│ 交互模型 │ 苏格拉底  │ 物料准备  │ 四端并行  │ 三步确认  │ 日志→AI汇总  │
│ 核心场景 │ →第一性   │ 4步推进  │ 反馈闭环  │ 状态机   │ →人工标注    │
│ 上下文   │ →奥卡姆   │ 门禁控制  │ 角色Agent │ 快捷工具  │ →经验沉淀    │
│ 设计     │          │ 产出PRD  │ 人工定稿  │          │ P0-P3分期   │
└──────────┴──────────┴──────────┴──────────┴──────────┴──────────────┘
         ↓              ↓              ↓              ↓
      G0 通过        G1 通过        G2 通过        G3 通过

门禁依赖图:

G0 场景定位(可选) → G1 三步对话 → G2 PRD v1.0 → G3 四端 Review → G4 PRD v3.x 终稿
                                                                    ↓
                                                          G5 Agent 交互设计(可选)
                                                                    ↓
                                                          G6 学习循环设计(可选)
                                                                    ↓
                                                          G7 P0-P3 分期规划(可选)

---

通用机制

门禁原则(Gate-based)

本流水线所有 Stage 采用 Phase + 门禁 机制:不过闸不下一步。每步有明确产出和通过标准。

• ✅ = 通过条件满足
• ❌ = 不满足,停下补或重做
• 不接受"后面补"--后面补 = 永远不补

日志规范

每个 Stage 完成后写入 experience-base/raw/ 目录:

{
  "timestamp": "ISO 8601",
  "stage": "stage-0/1/2/3/4/5",
  "project": "...",
  "mode": "new | iteration | hotfix",
  "outcome": "...",
  "gate_passed": true
}

---

Stage 0: 场景定位（可选）

来源：agent-scenario Skill 🎯 目标：选准交互模型 + 定义核心场景 + 设计上下文协议，避免做成“能聊天但没价值”的鸡肋。 何时启用：做 Agent/Copilot 产品时必须；传统 Web/App 项目可跳过。

Phase 0.1: 交互模型选型

三选一:

一句话规则:有现成后台就做内嵌 Copilot,没后台就做 IM 或独立。

🚧 门禁:

• ✅ 交互模型唯一确定
• ❌ "都做" / "看情况切换" → 一个产品先定一个模型

Phase 0.2: 核心场景设计

每个场景必须完整描述 3 要素:

1. 谁:用户画像(角色 + 经验水平 + 使用频率)
2. 什么时候做什么:触发时机和具体动作
3. 为什么用 Agent 而不是原有方式:Agent 带来的价值

场景模板:

## 场景 1: {场景名}

**用户画像**: {角色}, {经验水平}, {使用频率}
**触发时机**: {具体触发场景}
**具体动作**:
  - 用户: {用户输入}
  - Agent: {Agent 自动执行的步骤}

**Agent 带来的价值**: {具体提效数据,如"10 分钟→1 分钟"}
**不做什么(YAGNI)**: {明确砍掉的}

场景数量控制:P0 必做 1 个,P1 跟进 1-2 个,超过 3 个砍。

🚧 门禁:

• ✅ 至少 1 个完整场景(3 要素齐全)
• ✅ 有"不做什么"清单
• ❌ 场景 > 3 个 → 砍
• ❌ "所有用户都能用" → 必须画像具体

Phase 0.3: 上下文设计(PageContext 协议)

Agent 必须拿到的上下文,决定意图识别复杂度:

PageContext {
  page_type:       schedule | coupon | resource_slot | campaign | ...
  filters:         当前筛选条件(键值对)
  selected_items:  当前选中的行(可选)
  form_state:      如果有打开的表单,当前表单状态(可选)
  user_locale:     用户界面语言
  user_timezone:   用户本地时区
  target_country:  目标市场国家
  target_region:   目标市场区域
  currency:        当前币种
}

关键:页面/选中/筛选即上下文。用户说"排春促",Agent 已知"西班牙 / 未来时段 / 筛选空"。

🚧 门禁:

• ✅ PageContext 字段清单完整
• ✅ 核心场景的追问清单明确
• ❌ "Agent 自己猜" → 必须明确上下文来源

产出物

1. 交互模型决策 + 决策矩阵
2. 1-3 个核心场景(完整故事线)
3. PageContext 协议字段清单
4. 每个场景的追问清单

---

Stage 1: 三步对话法（默认启用）

来源:socratic-dialogue Skill 🎯 目标:在任何产出前,用苏格拉底→第一性→奥卡姆三步引导,避免 AI 写出"漂亮废话"。

核心铁律

别让 AI 直接开始写。 上来就写 = 写一堆看起来合理但无锚点的内容。先用 3 步把问题拆清楚。

适用场景

任何从 0 到 1 的产出启动时:PRD、技术方案、Agent 设计、架构设计、分享文档、复盘报告、工作计划。

不适用:已有明确规范的执行型任务(如"按设计稿写前端"、"修这个 bug")。

---

Step 1 苏格拉底(问真问题)

给用户的指令:

动笔前,我先请你回答 5 个问题。不用每题都完美,但至少要认真想过。

1. 真实目标:你要解决的真正问题是什么?(不是"提升转化率"这种结果指标,是"用户/业务实际遇到的什么痛)
2. 不做什么:这次明确不做的事情有哪些?(砍得越清楚,后面越不混乱)
3. 用户真实痛点:用户遇到了什么具体场景?最好有 1-2 个真实故事
4. 成功衡量:怎么算成功?(指标 + 目标值 + 衡量方式)
5. 失败接受标准:什么情况你能接受失败/砍掉?(你的底线在哪)

产出:真实目标一句话 + 不做清单 + 用户痛点 + 成功/失败标准。

🚧 门禁:

• ✅ 5 个问题全部有明确答复(不能是"待定 / 看后面")
• ✅ 真实目标不能是"提升 X%" 这种结果指标,必须是"用户/业务的 Y 问题"
• ❌ 用户说"你先列一个吧" → 不要替用户答,追问"我帮你列候选,但最终要你拍板"

---

Step 2 第一性(拆到本质)

给用户的指令:

忘掉线上现在怎么做。从刚才定的真实目标倒推:

• 要实现这个目标,最少需要几个必要条件?(建议 ≤3 个)
• 每个条件现在满足多少?
• 哪个条件是最大瓶颈?

原则:

• 条件必须是"必要"的,不能是"应该有"
• AI 提候选,最终由用户拍板
• 典型 trap:AI 会编"应该做个性化推荐"这种合理但非必要的条件

产出:1-3 个必要条件 → 这是未来产出物的骨架。

🚧 门禁:

• ✅ 必要条件 ≤ 3 条
• ✅ 每条都能回答"砍了它,真实目标还能达成吗?" → 答"不能"才是必要
• ❌ AI 自己定义必要条件,用户没拍板 → 退回
• ❌ 超过 3 条 → 大概率有非必要项,合并或砍

---

Step 3 奥卡姆(砍到最简)

给用户的指令:

现在我们有了骨架。接下来每个模块/字段/交互,都问一遍: "砍掉这个,核心目标还能达成吗?能 → 砍。"

执行方式:

1. 列出所有当前计划包含的模块/功能/字段
2. 逐条提问:砍了会怎样?
3. 能砍的画叉,不能砍的标"核心"
4. 回头看一眼:砍完后"必要条件"还全部满足吗?状态机闭环吗?

典型收益:某 B 端中台项目砍掉积分货币/补签卡/签到后数值/吸底栏二级 CTA → 篇幅 -30%,研发可实施度 +100%。

🚧 门禁:

• ✅ 每个模块都回答过"砍了会怎样"
• ✅ 砍完回头看过一眼,必要条件仍然满足
• ❌ 砍破坏了状态机闭环 → 退回,这个不能砍
• ❌ 一个都没砍 → 质疑:真的每个都必要吗?再过一遍

---

完整示例

用户需求:做个签到积分系统,提升用户活跃度。

Step 1 苏格拉底:

• 真实目标?→ 用户答:其实是想做一个状态自适应的社区入口,积分只是吸引器
• 不做什么?→ 用户答:不做复杂货币体系、不做社交分享
• 用户痛点?→ 用户答:新用户/活跃用户看到的入口一样,没有区分
• 成功衡量?→ 用户答:活跃用户入口点击率 +15%
• 失败标准?→ 用户答:如果活跃用户点击率没变化,就砍掉

Step 2 第一性:必要条件 3 条:位置不变 / 状态可判定 / 每个模块对每个状态有明确策略

Step 3 奥卡姆:砍掉积分货币、补签卡、签到后数值、吸底栏二级 CTA → 篇幅 -30%,PRD review 一次过。

产出物

1. 真实目标一句话
2. 1-3 个必要条件
3. 精简后的模块/功能清单
4. 明确的"不做"清单(YAGNI)

---

Stage 2: PRD 产出（默认启用）

来源:pm-requirement Skill 🎯 目标:从"命题"到"能进 review 的 PRD v1.0",少 50% 返工。

PM 的 3 大陷阱

1. 跳过苏格拉底直接动笔 -- AI 产出一堆漂亮废话
2. 继承逻辑不写清 -- 研发默认全部新建,估期翻倍
3. "必须澄清"项自己推断 -- 核心规则建在假设上,review 阶段大返工

---

Phase 2.0: 项目识别(入口分流)

判断场景类型,决定走完整流程还是轻量流程:

🚧 门禁:

• ✅ 场景类型已确认
• ✅ 迭代场景下:项目版本索引已存在或已创建
• ✅ 迭代场景下:上期 PRD 链接/位置已确认

迭代模式简化规则

迭代继承清单:

| 上期功能模块 | 本期决策 | 变更说明 |
|---|---|---|
| 优惠券创建 | 不变 | - |
| 优惠券分发 | 修改 | 加批次化能力 |
| - | 新增 | 多语言编辑器(本期新模块) |

优化/修复模式(极简流程)

1. 确认改动内容(一句话描述)
2. 直接在原 PRD 文档追加/修改对应 7.N 章节
3. 更新版本索引(记录一行)
4. 不走三步对话、不走完整门禁

---

Phase 2.1: 物料准备(质量决定上限)

3 类物料:

操作:问用户 3 类物料有哪几类 → 缺的列出来问怎么补 → 标注质量等级。

🚧 门禁:

• ✅ 3 类物料齐全(每类至少 1 份具体内容)
• ✅ 数据口径已对齐(显式说明"这里 UV" / "那里 PV")
• ✅ 继承清单已列好(继承/修改/不做三列)

不接受的"完成"声明:

• ❌ "物料后面补"
• ❌ "我都记在脑子里"
• ❌ "继承逻辑开发会知道"

物料缺失时的补料方案

物料 1(参照物料)缺失:用 WebFetch/WebSearch 抓取竞品公开信息,自动分类打标签。需要用户给 3-5 个对标竞品名称 + 线上产品截图。

物料 2(数据分析)缺失:口径不对齐 → 列出所有"核心数据点",逐个标注 UV/PV/DAU/其他,冲突让用户选统一口径。

物料 3(继承清单)缺失:读取现有代码仓库总结已有功能,模板化输出三列。

补料优先级:P0 物料 3 → P1 物料 2 → P2 物料 1

---

Phase 2.2: 三步对话拆解

复用 Stage 1 的三步对话法逻辑,这里不再重复。详见 Stage 1。

调用 Stage 1 完成后,产出真实目标 + 必要条件 + 精简方案。

🚧 门禁:

• ✅ 真实目标一句话
• ✅ 必要条件 ≤ 3 条
• ✅ 不做清单已列
• ✅ 已砍一轮,状态机仍闭环

---

Phase 2.3: 产出 PRD v1.0(骨架 + 占位)

📄 输出载体:所有产出优先飞书文档(doc_create),降级写本地 knowledge-base/product/。

---

PRD 章节按需裁剪:

不是每个项目都需要全部章节。先跑「章节裁剪」再写内容:

裁剪操作:

1. 列出上表给用户勾选(默认已勾的 + 用户额外勾的)
2. 未选中的章节不写,不占篇幅
3. 飞书文档目录结构只包含选中的章节

每个功能模块 7.N 五子章节:

1. 系统侧规则
2. 状态流转
3. 边界处理
4. 异常处理
5. 明确不做

R1-R6 硬规则:

PRD 职责边界(What vs How):

🚧 门禁:

• ✅ 必保章节存在(0/1/2/3/7/14/15)
• ✅ 每个功能模块五子章节齐全
• ✅ 不含技术实现细节(接口/表结构/技术选型)
• ✅ 飞书文档已创建,章节结构清晰
• ❌ 含"大概 / 似乎 / 可能" → 给具体数值或标"待确认"
• ❌ 出现接口名/字段名/技术方案 → 删除,改为业务规则描述

---

Phase 2.4: v2+ 迭代(收敛"待确认"到 0)

每次升版动作:找出"待确认" → 谁能答?去问 → 替换为具体内容 → 更新变更记录。

关键规则:标"必须澄清"的项 → 业务拍板,不自行推断。

🚧 门禁:

• ✅ 版本已迭代到 v3.0+
• ✅ 全文"待确认/待补充/待法务"数量 = 0
• ✅ 变更记录完整
• ❌ 有未收敛的"待确认" → 不能进 review

产出物

1. PRD v3.x 终稿(飞书文档)
2. 变更记录(v1.0 → v3.x)
3. 物料清单
4. 教训沉淀(如有)

---

Stage 3: 多角色 Review（默认启用）

来源:pm-review Skill 🎯 目标:PRD 从 v1.0 经 5 轮并行 review 收敛到 v3.x 终稿,每次反馈都闭环。

4 大陷阱

---

Phase 3.1: 评审前准备

检查清单:

• PRD 已迭代到 v2.x
• 已产出低保真原型或 mermaid 流程图
• 评审日程安排(技术 3 端 + 设计,必须并行)
• 评审产物形式(飞书消息 + MD 澄清清单)

组织方式(一人多角色场景):由 Agent 分别扮演四端视角出具 review 意见。

🚧 门禁:

• ✅ PRD 版本 ≥ v2.0
• ✅ 评审会议已约
• ✅ 三端 + 设计同时启动,不允许串行

---

Phase 3.2: 四端并行 Review

复用已有 Agent 的专业能力,不用临时空白 sub-agent。 每个视角的 review 由对应的专业 Agent 执行(review 模式),它们自带铁律 + 角色教训 + 专业 checklist。

四端 Agent 调用映射:

每个 Agent 的 prompt 模板:

你现在是 review 模式,不是正式设计/编码模式。
审核对象:PRD v{X} 全文
产出:阻塞(P0) / 风险(P1) / 优化(P2) 分级意见列表
无需产出接口文档/技术方案/测试策略,只产出 review 意见。

3 级分类:

每轮 review 动作:

1. 收集 Agent 反馈(四端并行产出,汇总合并)
2. 分级分类(P0 / P1 / P2)
3. 逐条响应(接受 / 拒绝 / 需澄清)
4. 更新 PRD 版本
5. 更新变更记录
6. 必须澄清项 → 业务方拍板(不允许 PM 自己推断)
7. 未通过的视角 → 带修改后的 PRD 重新调用对应 Agent re-review

⚠️ 关键规则:凡标"必须澄清"一律业务拍板

• 不允许 PM 自己推断答案
• 列清单 + 责任人 + deadline,推业务方拍板
• 拍板后回写 PRD,标注决策来源

🚧 门禁(每轮):

• ✅ 所有反馈都有明确响应
• ✅ "必须澄清"项已推业务方
• ✅ PRD 版本已升级,变更记录已更新
• ❌ 有反馈被忽略 → 回去响应

---

Phase 3.3: 通过确认

确认标准(每端独立确认):

• 服务端:接口草案通过 + 继承原则落地 + 失败路径明确
• 客户端:页面结构通过 + 交互可实现 + 依赖 API 已定
• 测试:AC 矩阵完整 + 接口未定项 = 0 + 版本兼容明确
• 设计:高保真覆盖所有 PRD 状态 + 设计稿 ↔ PRD 一致

🚧 门禁:

• ✅ 三端"必须澄清"= 0
• ✅ "条件通过"全部收敛
• ✅ PRD 版本 ≥ v3.0
• ✅ 全文"待确认"= 0
• ❌ 单端通过 ≠ 过闸,必须三端都过

产出物

1. 四端 review 反馈汇总(含分级)
2. PRD v3.x 终稿(所有反馈闭环)
3. review 决策记录

---

Stage 4: Agent 交互设计（可选）

来源：agent-interaction Skill 🎯 目标：把 6 步对话确认压缩到 3 步，用户认知负担最小。 何时启用：做 Agent/Copilot 产品时启用。

核心原则

三步确认链路:自然语言输入 → 隐式校验 + 填表高亮 → 确认提交。

Phase 4.1: 三步确认链路设计

步骤 1: 自然语言输入

• Agent 自动获取当前页面上下文(page_type / filters / selected / locale / timezone...)
• 结合上下文理解意图 + 提取参数
• 缺失参数才追问(不要预防性追问)

示例:

用户在排期页面(已选:集群=欧洲, 国家=西班牙)
用户输入: "明天 8 点到 12 点排一个春促活动"

Agent 自动知道:
  page_type = schedule(不用问)
  country = 西班牙(从筛选条件)
  日期 = 明天(从自然语言)
  时段 = 8:00-12:00(从自然语言)
  缺失: 活动素材 → 追问

步骤 1.5: 隐式校验(Agent 后台自动跑)

步骤 2: 参数确认卡片

不是纯对话,是结构化卡片。卡片内可嵌入下拉选择器、日期选择器等表单组件。

步骤 3: 填表高亮 + 用户提交

三色高亮系统:

提交:点击后台原有的提交按钮,走已有审核流程。

🚧 门禁:

• ✅ 三步每步都有明确设计
• ✅ 隐式校验 4 项覆盖
• ✅ 确认卡片是结构化非纯对话
• ❌ 超过 3 步确认 → 重新精简

Phase 4.2: 交互状态机

空闲态(AI 面板收起)
  │  用户点击 AI 按钮
  ▼
对话态(AI 面板展开)
  │  用户输入 / 快捷动作 / 模板
  ▼
校验态(隐式: 时区+合规+文化日历+冲突检测)
  │  校验完成
  ▼
确认态(参数确认卡片+校验结果)
  │  ├── 修改参数 → 留在确认态
  │  ├── 取消 → 回到对话态
  │  ├── 预览影响 → Dry Run → 回到确认态
  │  └── 填入表单 ↓
  ▼
填表态(左侧表单高亮显示 AI 填写内容)
  │  ├── 修改字段 → 高亮变黄
  │  ├── 放弃 → 回到对话态
  │  └── 点击提交 ↓
  ▼
完成态(提交结果+影响评估+模板保存建议)
  │  自动回到对话态

Phase 4.3: 快捷工具设计

上下文感知的快捷动作按钮

根据当前页面类型和选中状态,展示最可能的操作。按钮组不由 LLM 动态生成,而是按「页面类型 × 选中状态」做前端规则映射。

配置模板系统

多人协作感知

⚠️ @Maria 10分钟前刚给西班牙同时段配了另一个活动,是否冲突?

基于操作日志中的 operator + page_context 字段实现。

🚧 门禁:

• ✅ 至少 1 种快捷工具
• ✅ 快捷工具不依赖 LLM 动态生成
• ❌ "全靠 LLM 生成按钮" → 拒绝

产出物

1. 三步确认链路设计
2. 交互状态机(覆盖所有分支)
3. 快捷动作按钮方案
4. 配置模板系统设计

---

Stage 5: 学习循环 + 分期规划（可选）

来源：agent-learning + agent-phasing Skill 🎯 目标：让 Agent "越用越准"，同时做好 P0-P3 分期规划。 何时启用：Agent 产品需要长期迭代时启用。

5A: 学习循环设计

Phase 5A.1: 日志架构(P0 必做)

日志数据结构:

操作日志:
├── meta: operation_id / timestamp / operator / page_context / config_type
├── geo: region / country / city / timezone / locale / currency
├── interaction: user_input / input_type / agent_parse / agent_questions /
│                form_filled / user_modified / final_submitted
├── execution: api_calls / cross_system / validation_results / submit_status
├── compliance: rules_checked[] / rules_passed[] / rules_blocked[] / override_reason
├── localization: languages[] / currency / tax_rules_applied
├── calendar: nearby_events[] / cultural_flags[]
├── tags: ai_tags / human_tags(双周会后回填)
└── quality: accuracy_score / issues / lessons(双周会后回填)

核心字段:user_modified(记录 AI 填了什么、用户改成了什么--经验学习的核心数据源)

P0 必做:

• 日志字段规范定义
• 每次交互自动写入
• 操作编号体系(CFG-YYYYMMDD-NNN)
• 标签字段预留 + AI 自动打标

Phase 5A.2: AI 汇总报告机制

报告运转节奏:

日常: Agent 配置 → 自动写入日志
  ↓
定时(每双周): AI 汇总分析 → 生成总结报告 → 推送飞书
  ↓
双周会: 运营团队过报告 → 人工标注(哪些对、哪些错、哪些是规律)
  ↓
会后: 标注结果回喂 AI → 结合人工判断做经验沉淀
  ↓
沉淀经验更新 Agent 知识库 → 反哺日常配置 → 循环

AI 总结报告 7 板块:操作概览 / 准确率分析 / 高频修改 TOP 10 / 合规拦截统计 / 模板使用率 / AI 发现的模式 / 建议经验条目

原则:AI 先做脏活(汇总、归类、提假设),人类只做判断(确认、否决、补充)。

Phase 5A.3: 经验库三层架构

流转:原始层 → AI 清洗聚类 → 模式层 → 双周会确认 → 规则层 → Agent 决策推荐

关键:只有向上流动,没有跳级。AI 不能从原始日志直接生成规则。

地域维度:Global → Region → Country → Cluster(继承 + 覆盖,就近优先)

落地分级:

• P1: flat 结构 + country 标签(几十条够用)
• P2: 引入层级继承(超过 200 条时)

生命周期:规则 3 个月未命中 → 标记"待复核";原始层超 6 个月 → 冷存储。

🚧 门禁:

• ✅ 三层结构清晰
• ✅ 流转规则明确(不能跳级)
• ✅ 生命周期管理
• ❌ "AI 直接改规则" → 必须经模式层 + 人工确认

---

5B: P0-P3 分期规划

P0(4 周):能用 + 有数据 + 不留架构债

P0 不能省的架构基座:PageContext 协议定义完整 / 日志全字段落库 / 合规规则框架可扩展

P1(4 周):闭环跑起来 + 效率工具

P1 完成标志:"使用→日志→汇总→标注→回喂"闭环真实运转。

P2(4 周):铺量 + 深水区

• 多场景扩展(3+ 配置场景接入)
• 合规规则库(法务团队主导梳理)
• 文化日历(只读展示未来 14 天营销节点)
• 经验库层级(条目 >200 时引入继承)

P3(未来):智能化

• 文化禁忌拦截 / 实时协作感知 / 影响评估引擎 / 操作回放 / 决策 Agent

每阶段通用门禁:

• ✅ 明确"做什么"和"不做什么"
• ✅ MVP 标准清晰
• ✅ 下阶段依赖本阶段架构(不是重做)
• ❌ "P0 先不要,P1 再加" → 拒绝

产出物

1. 日志数据结构定义
2. AI 汇总报告模板
3. 经验库三层架构设计
4. P0-P3 分期规划文档(含 MVP 清单 + 不做什么)

---

完整交付清单

流水线跑完后,产出以下交付物(标注 ✅ 的为默认启用 Stage 的产出):

---

常见卡点速查

---

来源与致谢

本 Skill 融合了以下 7 个核心 Skill 的完整逻辑:

三步对话法源自企业内部 Agent 对话方法论实践,PRD 一次通过率从 ~40% 提升到 ~80%。