Requirement Sharpening Stone

帮助 PM 在需求启动阶段,通过三步对话法(苏格拉底→第一性→奥卡姆)拆清问题本质, 产出可进 review 的 PRD v3.x 终稿。支持按需裁剪章节、按需启用场景定位/Agent 设计/学习循环等可选阶段。输出优先飞书文档,降级本地 MD。

X和小克@mistyhuqwq-art

Install

openclaw skills install @mistyhuqwq-art/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 工具。依赖以下内置能力：

能力	用途	来源
飞书文档创建	PRD 输出载体	feishu_lark_cli
WebSearch	竞品信息抓取(物料补全)	web_access_tool
本地文件读写	降级输出 + 经验沉淀	内置

需求磨刀石 v2

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

使用方式

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

Stage	名称	何时启用
0	场景定位	做 Agent 产品时必须;非 Agent 项目可跳过
1	三步对话	默认启用,任何 0→1 产出的起点
2	PRD 产出	默认启用,三步对话产出后接续
3	多角色 Review	默认启用,PRD 写完必走
4	Agent 交互设计	做 Agent/Copilot 产品时启用
5	学习循环 + 分期	Agent 产品需要长期迭代时启用

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

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

输入参数

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

参数	说明	默认值
project_name	项目名称	运行中追问
project_type	new(0→1) / iteration(迭代) / hotfix(修复)	运行中判断
stages	启用哪些 Stage,如 `1,2,3`	`1,2,3`
output_format	feishu(飞书文档) / local(本地 MD)	feishu
prd_chapters	PRD 章节裁剪列表,如 `0,1,2,3,7,14,15`	默认全选必选章节
existing_prd	已有 PRD 链接(迭代场景)	无

触发示例:

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

错误处理与边界情况

异常场景	处理方式
用户说“你先列一个吧”(不愿回答三步对话)	不替用户答,给出候选选项让用户拍板,不能跳过
物料严重不足(3 类全缺)	列补料清单 + 责任人 + deadline,不强行推进 PRD
三步对话拆不出必要条件(目标本身模糊)	退回,建议用户先找业务方对齐目标
Review 反馈 > 20 条	PRD 还没稳定,拆成多次小 review
“待确认”连续 2 轮清不掉	强制升级:列出未决项 + 责任人 + deadline,推业务方
用户中途要跳阶段	允许,但记录跳过项,后续阶段提醒补
飞书文档创建失败	降级写本地 `knowledge-base/product/`

前置条件

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

全景流程图

text

┌──────────────────────────────────────────────────────────────────────┐
│                      需求磨刀石 · 按需裁剪                           │
├──────────┬──────────┬──────────┬──────────┬──────────┬──────────────┤
│  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 通过

门禁依赖图:

text

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/ 目录:

json

{
  "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: 交互模型选型

三选一:

交互模型	适用	上下文感知	落地难度
IM 机器人	跨系统查询 / 简单提醒	从零理解,需大量追问	低
内嵌后台 Copilot	配置 / 操作 / 复杂表单	页面即上下文,意图识别易	中
独立工具	专业工具场景	自定义上下文	高

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

🚧 门禁:

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

Phase 0.2: 核心场景设计

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

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

场景模板:

markdown

## 场景 1: {场景名}

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

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

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

🚧 门禁:

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

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

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

typescript

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

上下文丰富度	意图识别难度	追问次数
零上下文(IM 机器人)	高	5-10 次
页面级上下文(内嵌)	低	0-2 次
选中级上下文(内嵌 + 选中)	极低	0 次

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

🚧 门禁:

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

产出物

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

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

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

核心铁律

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

适用场景

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

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

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

给用户的指令:

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

真实目标:你要解决的真正问题是什么?(不是"提升转化率"这种结果指标,是"用户/业务实际遇到的什么痛)

不做什么:这次明确不做的事情有哪些?(砍得越清楚,后面越不混乱)

用户真实痛点:用户遇到了什么具体场景?最好有 1-2 个真实故事

成功衡量:怎么算成功?(指标 + 目标值 + 衡量方式)

失败接受标准:什么情况你能接受失败/砍掉?(你的底线在哪)

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

🚧 门禁:

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

Step 2 第一性(拆到本质)

给用户的指令:

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

要实现这个目标,最少需要几个必要条件?(建议 ≤3 个)

每个条件现在满足多少?

哪个条件是最大瓶颈?

原则:

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

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

🚧 门禁:

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

Step 3 奥卡姆(砍到最简)

给用户的指令:

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

执行方式:

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

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

🚧 门禁:

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

完整示例

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

Step 1 苏格拉底:

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

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

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

产出物

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

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

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

PM 的 3 大陷阱

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

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

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

场景	判断依据	走法
🆕 0→1 新项目	没有已有系统、没有上期 PRD	完整流程
🔄 迭代需求	有已有系统、有上期 PRD/版本索引	轻量流程
🔧 优化/修复	小改动、不涉及新功能模块	极简流程

🚧 门禁:

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

迭代模式简化规则

物料类型	0→1 要求	迭代要求
参照物料	必须齐全	仅补本期新增功能相关的竞品/线上对比
数据分析	完整漏斗	仅补本期关注指标的数据现状
继承清单	从零列	从上期 PRD 自动生成 diff(新增/修改/废弃/不变)

迭代继承清单:

markdown

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

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

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

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

3 类物料:

#	物料类型	内容	常见坑
1	参照物料	竞品截图 + 线上截图(带状态标签)	竞品和"想做的"混在一起
2	数据分析报告	竞品信息架构 + 线上漏斗/状态差异	口径偷换(UV vs PV)
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 章节按需裁剪:

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

#	章节	默认	何时需要
0	文档元信息	✅	始终
1	执行摘要	✅	始终
2	项目背景与目标	✅	始终
3	用户故事 / 使用场景	✅	始终
4	信息架构	✅	默认含;纯后端项目可砍
5	业务流程图	✅	默认含;单角色简单流程可砍
6	数据规则 / 字段定义	⬜	涉及数据模型变更时
7	功能详述(7.N 五子章节)	✅	始终
8	非功能需求(性能/安全/合规)	⬜	有明确指标要求时
9	继承清单(已有逻辑 diff)	⬜	迭代项目,非 0→1
10	设计约束 / 视觉规范	⬜	有设计稿或品牌规范时
11	第三方依赖	⬜	涉及外部系统/API 对接时
12	灰度 / 上线方案	⬜	大范围变更或高风险项目
13	数据埋点需求	⬜	需要数据验证效果时
14	变更记录	✅	始终
15	待确认项	✅	始终

裁剪操作:

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

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

系统侧规则
状态流转
边界处理
异常处理
明确不做

R1-R6 硬规则:

规则	自检	常见违反
R1 禁止自造词	所有词都是通用语言或术语表已定义	"抽屉收起态下插卡逻辑"
R2 边界条件显式	每模块覆盖 6 类边界	"网络异常时展示兜底"
R3 前后端分离描述	分别描述用户侧行为和数据侧规则	混写"前端调 /api/xxx"
R4 状态机 6 列	含"禁止转换"列	"支持多状态切换"
R5 数值 4 维	值+单位+区间+可配置性	"长按触发选中"
R6 AI 可读	Figma 链接配 Mermaid/文字描述	只贴 Figma 链接

PRD 职责边界(What vs How):

❌ PRD 不写	✅ PRD 要写
接口设计(URL/字段名/请求格式)	业务数据规则
数据库表结构	数据实体关系
技术选型建议	性能期望("用户可感知的,如 < 3 秒")
前后端分工方案	用户侧行为 vs 系统侧规则的分别描述
数据流转实现方式	第三方系统依赖说明

🚧 门禁:

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

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

版本	关注点
v1.0	PRD 模板骨架完整,含占位
v1.x	业务流程 + 状态机 + 信息架构填实
v2.x	业务数据规则 + 异常路径 + 继承清单
v3.0	所有"待确认"必须清零
v3.x	review 反馈回填

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

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

🚧 门禁:

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

产出物

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

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

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

4 大陷阱

坑	后果	拦截机制
关键澄清项自行推断	核心规则建在假设上,返工	凡"必须澄清"一律业务拍板
技术 review 只看新功能	研发以为全部重写,估期翻倍	v3.0 起必含"现有逻辑继承"章节
单端 review 过 ≠ 三端过	服务端/客户端/测试理解各异	三端必须联合 review,不能串行
设计 review 与技术 review 串行	设计改完高保真,技术说做不了	设计与技术必须并行

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 调用映射:

视角	审查重点	Review 模式 prompt 要点
服务端	接口可行性、字段规范、状态机、错误码、数据模型	从接口可行性审
客户端	交互可实现性、组件复用、状态管理复杂度、技术风险	从前端实现审
测试	验收标准可执行性、边界覆盖、4 层测试能否设计	从可测试性审
设计	视觉一致性、信息架构、交互规范、响应式可行性	从视觉/信息架构审

每个 Agent 的 prompt 模板:

text

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

3 级分类:

级别	含义	响应要求
P0 阻塞	不解决无法开发	当轮必解决,解决后重跑 review
P1 风险	可开发但有后续 bug 风险	3 天内解决
P2 优化	锦上添花	可延后或砍掉

每轮 review 动作:

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

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

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

🚧 门禁(每轮):

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

Phase 3.3: 通过确认

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

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

🚧 门禁:

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

产出物

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

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

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

核心原则

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

Phase 4.1: 三步确认链路设计

步骤 1: 自然语言输入

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

示例:

text

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

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

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

校验项	说明	不通过处理
时区转换	本地时间转 UTC,检测 DST	确认卡片标注双时区 + DST 告警
合规校验	按 Global → Region → Country 层级匹配	硬性规则拦截;软性规则标黄
文化日历	检查营销节点、禁忌、宗教敏感期	确认卡片显示提示或告警
排期冲突	检测同时段已有配置	冲突标红

步骤 2: 参数确认卡片

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

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

三色高亮系统:

颜色	含义
浅蓝色	AI 填写,用户未修改
浅黄色	AI 填写,用户已修改(提醒 AI 改过)
浅红色	校验不通过或冲突

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

🚧 门禁:

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

Phase 4.2: 交互状态机

text

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

Phase 4.3: 快捷工具设计

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

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

配置模板系统

能力	说明
从历史操作生成	提交成功后 Agent 主动建议"保存为模板"
变量化	日期、国家、素材作为可替换变量,其余参数锁定
可视化调用	点击 [从模板创建],展示模板卡片列表
团队共享	模板可在团队内共享

多人协作感知

text

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

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

🚧 门禁:

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

产出物

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

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

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

5A: 学习循环设计

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

日志数据结构:

text

操作日志:
├── 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 汇总报告机制

报告运转节奏:

text

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

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

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

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

层次	规则层 Rules	模式层 Patterns	原始层 Raw Cases
数量级	几十~几百条	几百~几千条	全量操作记录
性质	确定性规则	统计规律,需人工确认	事实记录
产生方式	双周会确认后升级	AI 清洗日志后聚类	每次交互自动写入
Agent 使用	实时加载/检索	不直接使用	不直接使用

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

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

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

落地分级:

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

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

🚧 门禁:

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

5B: P0-P3 分期规划

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

功能	最小可用版本	不做什么
三步确认链路	单场景端到端	不做多场景
PageContext 协议	定义接口 + 单页面实现	不做其他页面
时区双显	确认卡片展示本地+UTC	DST 只做简单提示
Dry Run	影响国家数 + 冲突列表	不做用户量预估
合规校验	框架 + 硬编码 3-5 条规则	不做完整规则库
日志	全字段落库	不做查询后台
快捷按钮	前端规则映射	不做 LLM 动态推荐

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

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

功能	最小可用版本
经验库	一层 flat 结构 + country 标签
AI 总结报告	按区域拆分的操作概览 + 高频修改 TOP 10
配置模板	从历史保存 + 可视化调用 + 变量替换
人工标注	双周会后在日志上打标

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

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

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

P3(未来):智能化

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

每阶段通用门禁:

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

产出物

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

完整交付清单

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

#	交付物	产出阶段	载体
1	交互模型决策	Stage 0(可选)	飞书文档 / 本地 MD
2	核心场景故事线	Stage 0(可选)	飞书文档 / 本地 MD
3	PageContext 协议	Stage 0(可选)	本地 MD
4	✅ 三步对话产出(真实目标+必要条件+精简方案)	Stage 1	飞书消息 / 本地 MD
5	✅ PRD v3.x 终稿	Stage 2-3	飞书文档
6	✅ 变更记录	Stage 2	飞书文档内维护
7	✅ 四端 Review 汇总	Stage 3	本地 MD
8	Agent 交互链路设计	Stage 4(可选)	飞书文档 / 本地 MD
9	交互状态机	Stage 4(可选)	Mermaid / 本地 MD
10	学习循环架构	Stage 5(可选)	本地 MD
11	P0-P3 分期规划	Stage 5(可选)	本地 MD

常见卡点速查

卡点	解决
物料不够全	列补料清单,标明谁能给,定 deadline
三步对话拆不出必要条件	目标本身模糊,回去找业务方对齐
PRD 写着写着发散	每写完一章回头看必要条件还在不
"待确认"一直清不掉	列清单 + 责任人 + deadline,强制推进
一端反复不过	PRD 有结构性缺陷,回 Stage 2 补物料
"必须澄清"业务方不响应	飞书群 @ + 邮件 + 会议三连,带 deadline
一轮 review 反馈 > 20 条	PRD 还没稳定,拆成多次小 review
设计和技术 review 冲突	召开三方对齐会

来源与致谢

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

Skill	定位
`agent-scenario`	Agent 场景定位 + PageContext 协议
`socratic-dialogue`	三步对话法(苏格拉底→第一性→奥卡姆)
`pm-requirement`	PRD 4 步产出流水线
`pm-review`	多角色四端并行 Review
`agent-interaction`	三步确认链路 + 状态机
`agent-learning`	日志→AI 汇总→人工标注三层架构
`agent-phasing`	P0-P3 分期规划

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