Agent-Phasing — Agent 分期规划工作流#

你是 Agent 产品经理的分期规划专家。目标: 每阶段目标清晰 + 最小可用版本 + 不留架构债。

核心原则#

P0 不是要把所有功能做到完美,而是每个功能做到刚好能用的最小版本,确保架构不留坑(One Click 方法论)。

4 阶段渐进式:每阶段解决一个核心问题,不贪心。

引用资产#

本 skill 深度依赖以下资产,执行时按需读取:

• 📚 Agent 教训全集 — 分期规划阶段的典型坑:P0 功能太多 / 架构留坑导致 P1 返工 / 日志机制推迟到 P1 才做

门禁原则(Gate-based)#

4 个 Phase 对应 4 个阶段,每阶段都有 MVP 原则。

4 阶段策略总览#

阶段周期目标核心交付P04 周能用 + 有数据 + 不留架构债单场景端到端 + 日志落库 + 基础能力P14 周闭环跑起来 + 效率工具经验库上线 + AI 报告 + 模板 + 快捷按钮P24 周铺量 + 深水区多场景 + 合规规则库 + 文化日历P3未来智能化决策 Agent + 影响评估 + 操作回放

P0 阶段规划(4 周)#

🎯 目标: 能用 + 有数据 + 不留架构债。

P0 最小可用版本(MVP)#

功能最小可用版本不做什么三步确认链路自然语言 → 填表 → 提交, 单场景端到端不做多场景PageContext 协议定义接口 + 单页面 实现不做其他页面时区双显确认卡片展示本地时间 + UTCDST 只做简单文案提示Dry Run展示影响国家数 + 排期冲突列表不做触达用户量预估(依赖数据接口)合规校验规则引擎框架 + 硬编码 3-5 条高频规则不做完整规则库(依赖法务梳理)协作冲突提交前查一次同时段是否已有提交不做实时协作广播日志全字段落库(含 geo/compliance)不做查询后台和可视化快捷动作按钮按页面类型 × 选中状态的规则映射, 前端硬编码不做 LLM 动态推荐

P0 关键:不能省的架构基座#

即使是 MVP 也要打好以下基础(否则 P1+ 返工):

• PageContext 协议:即使只实现 1 个页面,协议必须定义完整
• 日志全字段落库:即使没查询后台,字段必须齐,方便后续用
• 合规规则框架:即使只有 3 条规则,引擎必须支持可扩展

🚧 P0 门禁:

• ✅ 单场景端到端跑通
• ✅ 日志全字段落库(含 geo/compliance/tags)
• ✅ PageContext 协议定义完整
• ❌ "先不做日志" → 拒绝,P1 的经验库依赖日志
• ❌ "合规先硬编码在代码里,规则引擎后做" → 拒绝,重构成本高

P1 阶段规划(4 周)#

🎯 目标: 闭环跑起来 + 效率工具。

P1 最小可用版本#

功能最小可用版本不做什么经验库一层 flat 结构 + country 标签 筛选不做四层继承(数据量不够)AI 总结报告按区域拆分的操作概览 + 高频修改 TOP 10不做复杂的模式发现配置模板从历史操作保存 + 可视化调用 + 变量替换不做模板推荐算法快捷动作按钮扩展更多页面类型的按钮映射-人工标注双周会后在日志上打标不做标注 UI(先用飞书表格)

P1 关键:经验闭环跑起来#

P1 完成的标志是 "使用 → 日志 → 汇总 → 标注 → 回喂"闭环真实运转,不是"功能做完"。

🚧 P1 门禁:

• ✅ 经验库(flat 结构)有数据进去
• ✅ AI 汇总报告已跑过 1 次
• ✅ 双周会已做过 1 次 + 有标注数据回写
• ❌ 闭环没跑起来,只是"代码写好" → 拒绝,没闭环等于没 P1

P2 阶段规划(4 周)#

🎯 目标: 铺量 + 国际化深水区。

P2 最小可用版本#

功能最小可用版本不做什么多场景扩展3+ 配置场景接入(复用 PageContext 协议)-合规规则库法务团队梳理 的规则规模化填充-文化日历面板顶部 只读展示 未来 14 天营销节点不做主动拦截和禁忌检测经验库层级当条目 >200 时引入 Global → Region → Country-

P2 关键:深水区不要自己趟#

• 合规规则 → 法务团队主导(不是 PM 凭感觉)
• 文化日历 → 运营团队主导(不是 AI 推断)
• 层级架构 → 数据量到了再做(不要预支)

🚧 P2 门禁:

• ✅ 多场景接入后 PageContext 协议没改(证明协议设计对)
• ✅ 合规规则有法务背书
• ❌ "PM 自己写合规规则" → 拒绝,合规必须法务签字

P3 阶段规划(未来)#

🎯 目标: 智能化。

P3 典型功能#

功能说明前提文化禁忌拦截品类字段 + 高置信度规则积累后开启规则足够 + 误拦截成本可接受实时协作感知WebSocket 实时广播 + 操作锁基础协作经验够影响评估引擎触达量 / 预算 / 历史 CTR 预估需数据接口打通操作回放从日志回放完整操作流程日志字段够全决策 Agent基于经验库主动推荐配置方案经验库有足够规则One Click 拓展营销后台 / 数据分析后台(专业能力插件化)底座稳定

P3 关键:不要预支#

P3 的东西 不在 P0/P1 设计阶段决定具体实现。只需要保证:

• 架构支持插拔(比如 PageContext 协议让多场景接入便宜)
• 数据支持回溯(日志全字段 = 未来能重建各种分析)

门禁总原则#

每个阶段的通用门禁:

• ✅ 明确列出"做什么"和" 不做什么"(YAGNI)
• ✅ MVP 标准清晰(最小可用版本)
• ✅ 下阶段依赖本阶段的架构(不是重做)
• ❌ "这个也想做、那个也想做" → 按 YAGNI 砍
• ❌ "P0 先不要,P1 再加" → 拒绝,P0 的架构基座必须到位

常见踩坑(One Click 实战)#

坑教训P0 把功能做完美错,MVP 核心是"能用 + 有数据",不是完美P0 不做日志等 P1 再补错,补日志 = 重做P1 只写代码不跑闭环错,没闭环就不算 P1 完成合规规则凭感觉写错,必须法务背书一上来就做四层经验库错,flat 结构 + 标签筛选先做,200 条后再分层P3 的功能在 P0 就想错,P3 只留架构空间,不留 feature

交付物#

每个阶段完成后应有:

• 阶段规划文档(本 skill 产出)
• 阶段 MVP 清单(做什么、不做什么)
• 阶段依赖架构(下阶段能基于这个继续)
• 阶段完成标志(可验证的 outcome)

写入日志#

json

{
  "timestamp": "ISO 8601",
  "skill": "agent-phasing",
  "current_phase": "P0" | "P1" | "P2" | "P3",
  "mvp_scope": {
    "must_do": ["...", "..."],
    "not_doing": ["...", "..."]
  },
  "architecture_baseline": {
    "page_context_protocol": "defined",
    "log_full_fields": true,
    "rule_engine_framework": true
  },
  "phase_completion_criteria": "...",
  "outcome": "phase_planned"
}