expert-ops-strategy-pipeline

name

expert-ops-strategy-pipeline

description

Build and maintain an end-to-end expert-operations content collection and strategy synthesis pipeline. Use this skill when the user clearly wants the full workflow, or a substantial subset of it: building or maintaining a Feishu Base for expert-ops sources, collecting multi-source expert-ops content, scoring and tiering sources, extracting strategy cards, merging duplicate strategies, or publishing a dated strategy note from the resulting strategy library. Do not trigger this skill for lightweight requests such as only summarizing a few articles, only polishing a document, or only brainstorming strategy ideas with no database / scoring / extraction workflow.

Expert Ops Strategy Pipeline

把“全网搜集行业专家运营经验内容”这件事，稳定地执行成一条可复用流水线：

1. 采集近 3 年高相关内容
2. 用统一口径打分并分层
3. 把高分内容拆成策略卡片
4. 归并相似策略，形成整合策略库
5. 生成《专家运营备选策略笔记-yyyymmdd》

What This Skill Is For

当用户的目标属于下面任何一种时，触发这个 skill：

• 要搭建或维护“专家运营策略库”
• 要搜集行业专家运营、KOC/KOL 运营、知识付费、私域社群、专家招募/冷启动/分层/激励/转化相关经验帖、教程、文章
• 要把零散文章沉淀到飞书多维表格
• 要给文章做 0-100 分评分、S/A/B/C/D 分层
• 要从文章里抽取多条运营策略
• 要把相似策略去重整合
• 要把高分策略输出成策略笔记、研究报告、操作 SOP

下面这些更轻的任务通常不要触发本 skill，除非用户同时明确要求表格沉淀、评分分层或策略库建设：

• 只总结几篇文章
• 只润色一篇笔记
• 只头脑风暴策略方向
• 只问“专家运营有哪些思路”

Default Deliverables

默认交付物有四层：

1. 内容源采集库
2. 专家运营策略拆解库
3. 专家运营策略整合库
4. 专家运营备选策略笔记-yyyymmdd

如果用户只要其中一层，也可以只执行到对应阶段，不必强行跑完整流水线。

Compatibility

Hard requirements by task type

• lark-base：只要任务涉及建 Base、建表、读写记录、字段设计、公式字段，就把它视为硬依赖。
• web-research 或同等联网检索能力：只要任务涉及“近三年”“最新”“全网搜索”“采集文章”，就把联网研究视为硬依赖。
• lark-doc：只有当用户明确要求发布飞书文档时，才是硬依赖。

Optional but preferred dependencies

• firecrawl：当用户要更深的页面抓取、整站抽取或网页交互时优先使用；如果不可用，不要阻塞全流程，改用浏览器检索和页面阅读。
• assess：优先用来执行 0-100 分评分；如果不可用，仍然按本 skill 的评分口径手动完成评分。
• research-synthesis：优先用来组织整合策略的主题、洞察和机会；如果不可用，直接按本 skill 里的默认策略笔记结构输出。
• writing-documentation-with-diataxis：优先用来约束最终文档写成 How-to Guide；如果不可用，仍然按“可执行优先”的原则输出，不要停止任务。

Fallback rules

• 缺少联网能力：明确说明无法验证“近三年 / 最新”范围，只能基于已提供资料或本地上下文给出非联网版本。
• 缺少 lark-base：先输出建议表结构、字段定义和待写入内容，不要假装已经写进 Base。
• 缺少 lark-doc：先输出 Markdown 成品，并明确“尚未发布到飞书文档”。
• 缺少 firecrawl / assess / research-synthesis / writing-documentation-with-diataxis：降级执行，不中断主流程。

Tool Selection

优先使用下面这些能力：

• lark-base：建 Base、建表、查字段、写记录、更新字段
• web-research：做多源检索、归类、研究式汇总
• firecrawl：需要更强页面抓取、站点级抽取时使用；如果 CLI 或环境不可用，明确说明并回退到浏览器检索
• assess：按评分口径打 0-100 分并写出评分依据
• research-synthesis：把整合后的策略聚类成主题、洞察、机会
• writing-documentation-with-diataxis：把策略整合成可执行的笔记文章，优先写成 How-to Guide
• lark-doc：把最终 Markdown/结构化内容发布成飞书文档

如果用户是问“有没有更合适的 skill 可以补采集能力/补渠道/补整理能力”，再补用 find-skills。

Working Principles

1. 先结构化，再规模化

先确认 Base、表结构、字段设计和评分口径，再扩大采集量。不要一上来抓很多内容，最后发现字段不够用。

2. 优先采集“可转策略”的内容

不是所有文章都值得入库。优先保留：

• 有明确方法、步骤、机制、案例、数据的内容
• 与专家运营核心环节强相关的内容
• 能拆成“可执行动作”的内容

默认过滤掉：

• 明显广告软文
• 纯新闻快讯
• 没有方法细节的通稿
• 与专家运营弱相关的泛鸡汤

3. 时效性要默认检查

只要用户要“近三年”“最新”“当前”“现在还适用吗”，就必须用联网检索确认，不要靠记忆。

4. 评分不是装饰，是准入门槛

>= 60 才进入“值得参考”集合。

• 90-100：S-可直接复用
• 80-89：A-高价值参考
• 70-79：B-部分参考
• 60-69：C-谨慎参考
• <60：D-不建议参考

如果用户没有特别指定，默认只把 >=60 的内容推进到策略拆解环节。

当输出执行方案、验收标准或 dry-run 结果时，明确写出：>=60 的内容才进入策略拆解，<60 默认只保留在源表或标记为不建议参考。

Core Workflow

Step 1: Clarify Scope and Existing Assets

先判断用户当前处在哪一阶段：

• 还没有 Base，需要从零建库
• 已有 Base，但缺表/缺字段
• 已有内容，需要继续补采集
• 已有拆解库，需要做去重整合
• 已有整合库，需要生成策略笔记

如果用户已经给了 Base、表名、文档名、评分规则、目标数量，优先复用现有资产，不要重复建新的。

Step 2: Ensure Base Structure

如果需要建库，优先保证至少有这三张表：

1. 内容源采集库
2. 专家运营策略拆解库
3. 专家运营策略整合库

内容源采集库

至少包含这些字段：

• 内容标题
• 来源平台
• 内容链接
• 作者/账号
• 发布时间
• 内容类型
• 核心摘要
• 原文摘录/要点
• 运营阶段
• 评分依据
• 专业可信度分
• 方法可复用分
• 证据完整度分
• 业务匹配度分
• 落地可操作分
• 时效性分
• 风险透明度分
• 参考总分(自动)
• 内容分层(自动)
• 是否值得参考(自动)
• 内容分层
• 参考分值
• 入库状态

字段归属 contract

把字段归属写清楚，避免 agent 同时写自动列和手工列：

• 公式字段 / 自动字段（formula-owned，agent 不写）
  • 参考总分(自动)
  • 内容分层(自动)
  • 是否值得参考(自动)
• 评分输入字段（agent-owned，agent 应写）
  • 专业可信度分
  • 方法可复用分
  • 证据完整度分
  • 业务匹配度分
  • 落地可操作分
  • 时效性分
  • 风险透明度分
  • 评分依据
  • 入库状态
• 兼容字段 / 手工镜像字段（default: do not write）
  • 内容分层
  • 参考分值

默认 contract：

1. agent 只写评分输入字段，不写任何 (...自动) 字段。
2. 如果表里同时存在 内容分层 / 参考分值 和它们的自动版本，默认把自动列视为唯一真值来源。
3. 只有用户明确要求维护手工镜像列时，才同步写 内容分层 / 参考分值。
4. 当手工列与自动列冲突时，不回写自动列；以自动列为准，并在结果里说明冲突。

专家运营策略拆解库

至少包含这些字段：

• 策略名称
• 适用阶段
• 核心打法
• 执行步骤
• 适用前提
• 风险点
• 参考分值
• 分层标签
• 来源文章
• 来源文章标题
• 来源文章链接

专家运营策略整合库

至少包含这些字段：

• 策略名称
• 适用阶段
• 核心打法
• 执行步骤
• 适用前提
• 风险点
• 参考分值
• 分层标签
• 来源文章
• 来源策略卡片
• 来源文章标题
• 来源文章链接

如果用户已经有这些表，只做差异化补齐。

Step 3: Collect Sources

采集时遵循这些规则：

1. 默认搜近 3 年内容
2. 关键词围绕：
   • 专家运营
   • 专家招募
   • 专家冷启动
   • 知识付费社群
   • KOC/KOL 分层
   • 私域社群运营
   • 专家内容生产
   • 专家激励与留存
   • 专家商业化转化
3. 结果优先覆盖：
   • 行业媒体
   • 专业运营社区
   • 企业/平台方法论文章
   • 有案例和数据的教程
   • 可映射到专家生态的成熟私域打法

采集后先写入 内容源采集库，不要跳过源表直接写策略表。

Step 4: Score and Tier Content

对每篇内容按统一口径评分。详细标准看 references/scoring-rubric.md。

默认维度是：

• 专业可信度
• 方法可复用性
• 证据完整度
• 业务匹配度
• 落地可操作性
• 时效性
• 风险透明度

写分时要同步写 评分依据，建议按下面格式：

优点：
- ...

风险：
- ...

适用前提：
- ...

Step 5: Extract Strategy Cards

只对高分内容做策略拆解。

执行原则：

• 一篇文章可以拆成多条策略
• 如果文章没有明确可执行动作，可以不拆
• 不要把“泛理念”硬拆成策略
• 策略名称先按动作命名，方便后续归并

每条策略至少要回答：

• 它适用于哪个阶段？
• 核心动作是什么？
• 怎么执行？
• 成立前提是什么？
• 风险边界是什么？

Step 6: Merge Similar Strategies

当用户要求做“整合库”“母策略”“去重归并”时：

按这些维度判断相似性：

• 适用阶段
• 核心打法
• 执行步骤
• 适用前提
• 风险点

整合后要：

1. 合并相似内容
2. 重新命名，不要简单照抄原策略名
3. 保留来源文章和来源策略卡片关联
4. 避免重跑脚本导致重复插入

如果是脚本化处理，优先做幂等写入：

• 已存在同名母策略时优先更新
• 重跑前检查重复写入风险
• 写入后巡检重复项

Step 7: Produce the Strategy Note

生成笔记时，默认采用：

• research-synthesis：整理主题、洞察、机会
• writing-documentation-with-diataxis：按 How-to Guide 输出

文章默认结构：

# 专家运营备选策略笔记-yyyymmdd

## Executive Summary

## Key Themes

### 战役模块

#### 策略名称
- 适用阶段：
- 推荐等级：
- 核心打法：
- 执行步骤：
- 适用前提：
- 风险边界：
- 来源覆盖：

## Insights → Opportunities

## 推荐落地顺序

## Methodology Notes

如果用户要求发布，继续用 lark-doc 发成飞书文档。

Output Rules

Dry-run / Evaluation Rules

如果用户明确说这是评估、dry run、演练、不要真实写入，输出开头要先说明边界：

本次是 eval dry run：没有实际联网搜索、没有写入飞书多维表格、没有发布飞书文档。

随后仍然给出真实执行时会采取的步骤、字段、质量门禁和验收方式，避免只说“不能执行”。

内容源表写入规则

• 先写元信息，再写评分字段
• 对于公式字段，只维护依赖它们的原始字段
• 分层冲突时，默认以自动列为准，除非用户明确要求保留手工列

策略表写入规则

• 拆解库 保留细粒度策略
• 整合库 只保留归并后的母策略
• 两张表都要保留来源关联

文档输出规则

• 文档标题默认：专家运营备选策略笔记-yyyymmdd
• 若用户指定日期或批次，使用用户命名
• 笔记风格优先“可执行”，不是纯汇报腔
• 当生成策略笔记时，默认保留这些一级章节：Executive Summary、Key Themes、Insights → Opportunities、推荐落地顺序、Methodology Notes
• 如果是 dry run 发布飞书文档，输出中使用固定声明：本次是 dry run：未实际发布到飞书文档。 然后给出真实发布时的 lark-doc 交接步骤

Common Failure Modes

1. 只抓文章，不做结构化

如果只返回一堆链接，没有写入源表、没有分层、没有拆策略，这不算完成任务。

2. 只给总分，不写依据

没有评分依据，后续无法复核，也不利于团队共识。

3. 把低价值文章推进到策略库

<60 分默认不进策略拆解库，除非用户明确要求保留观察样本。

4. 重复写入整合库

重跑脚本前检查幂等性；如果是基于名称或阶段归并，先做重复巡检。

5. 文档写成“研究摘要”而不是“行动指南”

最终策略笔记要优先帮助用户落地，而不是只展示你读了多少文章。

Examples

Example 1
Input: “用飞书多维表格建一个专家运营策略库，再去全网搜近三年经验帖，给每篇打分并沉淀到表里。”
Output: 建 Base/建表 -> 搜索采集 -> 写入 内容源采集库 -> 按 7 维评分 -> 自动分层 -> 输出入库结果。

Example 2
Input: “把策略拆解库里相似的内容去重整合成 sheet3，并重新命名。”
Output: 读取拆解库 -> 按阶段/打法/步骤归并 -> 生成整合库 -> 巡检重复项 -> 回写无重复结果。

Example 3
Input: “把专家运营策略整合库写成一篇策略笔记，并发到飞书文档。”
Output: 聚类主题 -> 生成 专家运营备选策略笔记-yyyymmdd.md -> 发布为飞书文档。

References

在需要具体评分细节或方法论口径时，再读：

• references/scoring-rubric.md
• references/pipeline-playbook.md

不要一次性把全部参考文件都塞进上下文；按需要读取。