agenticaiplan Expert Ops Strategy Pipeline
把“全网搜集行业专家运营经验内容”这件事，稳定地执行成一条可复用流水线：
- 采集近 3 年高相关内容
- 用统一口径打分并分层
- 把高分内容拆成策略卡片
- 归并相似策略，形成整合策略库
- 生成《专家运营备选策略笔记-yyyymmdd》
What This Skill Is For
当用户的目标属于下面任何一种时，触发这个 skill：
- 要搭建或维护“专家运营策略库”
- 要搜集行业专家运营、KOC/KOL 运营、知识付费、私域社群、专家招募/冷启动/分层/激励/转化相关经验帖、教程、文章
- 要把零散文章沉淀到飞书多维表格
- 要给文章做 0-100 分评分、S/A/B/C/D 分层
- 要从文章里抽取多条运营策略
- 要把相似策略去重整合
- 要把高分策略输出成策略笔记、研究报告、操作 SOP
下面这些更轻的任务通常不要触发本 skill，除非用户同时明确要求表格沉淀、评分分层或策略库建设：
- 只总结几篇文章
- 只润色一篇笔记
- 只头脑风暴策略方向
- 只问“专家运营有哪些思路”
Default Deliverables
默认交付物有四层：
内容源采集库专家运营策略拆解库专家运营策略整合库专家运营备选策略笔记-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 Guidelark-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
如果需要建库，优先保证至少有这三张表：
内容源采集库专家运营策略拆解库专家运营策略整合库
内容源采集库
至少包含这些字段：
内容标题来源平台内容链接作者/账号发布时间内容类型核心摘要原文摘录/要点运营阶段评分依据专业可信度分方法可复用分证据完整度分业务匹配度分落地可操作分时效性分风险透明度分参考总分(自动)内容分层(自动)是否值得参考(自动)内容分层参考分值入库状态
字段归属 contract
把字段归属写清楚，避免 agent 同时写自动列和手工列：
- 公式字段 / 自动字段（formula-owned，agent 不写）
参考总分(自动)内容分层(自动)是否值得参考(自动)
- 评分输入字段（agent-owned，agent 应写）
专业可信度分方法可复用分证据完整度分业务匹配度分落地可操作分时效性分风险透明度分评分依据入库状态
- 兼容字段 / 手工镜像字段（default: do not write）
内容分层参考分值
默认 contract：
- agent 只写评分输入字段，不写任何
(...自动)字段。 - 如果表里同时存在
内容分层/参考分值和它们的自动版本，默认把自动列视为唯一真值来源。 - 只有用户明确要求维护手工镜像列时，才同步写
内容分层/参考分值。 - 当手工列与自动列冲突时，不回写自动列；以自动列为准，并在结果里说明冲突。
专家运营策略拆解库
至少包含这些字段：
策略名称适用阶段核心打法执行步骤适用前提风险点参考分值分层标签来源文章来源文章标题来源文章链接
专家运营策略整合库
至少包含这些字段：
策略名称适用阶段核心打法执行步骤适用前提风险点参考分值分层标签来源文章来源策略卡片来源文章标题来源文章链接
如果用户已经有这些表，只做差异化补齐。
Step 3: Collect Sources
采集时遵循这些规则：
- 默认搜近 3 年内容
- 关键词围绕：
- 专家运营
- 专家招募
- 专家冷启动
- 知识付费社群
- KOC/KOL 分层
- 私域社群运营
- 专家内容生产
- 专家激励与留存
- 专家商业化转化
- 结果优先覆盖：
- 行业媒体
- 专业运营社区
- 企业/平台方法论文章
- 有案例和数据的教程
- 可映射到专家生态的成熟私域打法
采集后先写入 内容源采集库，不要跳过源表直接写策略表。
Step 4: Score and Tier Content
对每篇内容按统一口径评分。详细标准看 references/scoring-rubric.md。
默认维度是：
- 专业可信度
- 方法可复用性
- 证据完整度
- 业务匹配度
- 落地可操作性
- 时效性
- 风险透明度
写分时要同步写 评分依据，建议按下面格式：
优点：
- ...
风险：
- ...
适用前提：
- ...
Step 5: Extract Strategy Cards
只对高分内容做策略拆解。
执行原则：
- 一篇文章可以拆成多条策略
- 如果文章没有明确可执行动作，可以不拆
- 不要把“泛理念”硬拆成策略
- 策略名称先按动作命名，方便后续归并
每条策略至少要回答：
- 它适用于哪个阶段？
- 核心动作是什么？
- 怎么执行？
- 成立前提是什么？
- 风险边界是什么？
Step 6: Merge Similar Strategies
当用户要求做“整合库”“母策略”“去重归并”时：
按这些维度判断相似性：
适用阶段核心打法执行步骤适用前提风险点
整合后要：
- 合并相似内容
- 重新命名，不要简单照抄原策略名
- 保留来源文章和来源策略卡片关联
- 避免重跑脚本导致重复插入
如果是脚本化处理，优先做幂等写入：
- 已存在同名母策略时优先更新
- 重跑前检查重复写入风险
- 写入后巡检重复项
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.mdreferences/pipeline-playbook.md
不要一次性把全部参考文件都塞进上下文；按需要读取。