用途
job-ops 是运营岗的「数字员工」，接的是运营工作中规则清楚、判断少、纯体力的那部分：搬数、翻记录、重复生产。设计意图是把体力活拿走，让运营腾出时间做选题判断、活动创意和对用户情绪的感知。
明确不做的：替用户决定选题好不好、替用户判断平台调性对不对、替用户把内容发出去。
主要能力（五个场景）
场景 1：多平台数据日报。定时任务结合浏览器操作与多维表格，挂云电脑运行。每天早上打开指定平台创作者后台，取昨日曝光、点击、互动、涨粉、转化数据，汇总进多维表格并保留历史每日记录，与前一天、上周同一天做对比，波动超阈值指标单独标出，生成两百字以内日报文字，只陈述事实和异常、不给建议。
场景 2：用户反馈归类。获取指定时间范围内群聊记录，提取问题、需求与吐槽，按问题归类并合并同类说法，标明提及次数、代表性原话（原文引用不改写）、首次出现时间，分为 bug、体验问题、功能需求、价格相关四类，判断不了的单独列出，整理成多维表格。
场景 3：一稿多平台改写。将原平台原文改写成目标平台版本，保留原文所有具体数字和案例，不替换成概括说法，最后附平台标签，并列出改动较大处及原因。资料中以小红书为例给出具体要求：开头三行内出现痛点、正文分点但不用「首先其次」、每段不超过三行、口语化可用「我」、结尾给互动引导。
场景 4：活动复盘。综合项目群聊天记录、多维表格的报名和转化数据、活动方案文档，按时间线还原执行过程，标出计划与实际差异点，分析转化流失环节，单列群内出现的问题及处理方式，分四部分输出：做对了什么、哪里出了问题、数据结论、下次怎么改。所有结论须指出依据来自哪条记录或哪个数据，无依据的写为待确认。
场景 5：内容排期与派任务。从选题库中状态为「待排期」的选题里按本周发布计划挑选（优先级高、素材齐的优先），改状态并填发布日期与平台，为每条建一组任务（初稿、配图、终审），指定负责人与截止时间。建任务前须先列出排期方案和任务清单供确认，不直接改表。
使用方式
该技能以指令模板方式驱动，每个场景配有指令模板、执行要点、验收清单和必须保留的否定条款。
- 站内部分（如飞书多维表格、云文档）走内置技能直接读取；站外部分（各内容平台后台、竞品账号）需走浏览器操作，且登录态会失效，是故障率最高的环节。
- 定时类任务建议先手动跑一遍，观察入口查找、翻页与取数口径，稳定后再设为周期任务。
- 数据取不到或后台登录失效时必须提醒，不得留空当成零——这是各场景反复强调的否定条款。
适用场景
面向运营岗位的日常重复性工作：每日跨平台数据汇总、群聊反馈提取与归类、跨平台内容改写、活动结束后的复盘整理、周度内容排期与任务派发。
限制与边界
- 选题好坏、活动创意是否可行属于判断，不在该技能承担范围内。
- 平台调性的最后一道把关必须由人完成。
- 数据日报只呈现事实和异常，不提供运营建议。
- 改写产出只是初稿。
- 用户反馈归类存在合并错误风险（例如把「找不到入口」与「入口点了没反应」合成一类）。
- 活动复盘时间线可能把讨论的事和实际做的事混淆，计划与实际差异点最容易被美化。
- 排期时表里的勾不等于素材可用，截止日期遇周末可能算错。
- 兜底策略：取不到站外数据时直接说明卡在哪一步，不用上次数据凑数也不填零；群聊记录过多时先按时间和关键词收窄并向用户确认；用户意图模糊时先做数据体检并给出 3-5 个可深挖方向再确认。
- 上下游衔接：上游为 job-mkt（活动 Brief 和物料），下游为 job-fin（活动费用核对）及 pm-skills/pm-analytics（反馈转需求后的深度归因）；链路模式下完成后输出不超过 10 行的交接摘要。
补充说明
资料建议每个平台沉淀一个自定义技能（如「小红书改写」「视频号口播改写」），后续只需丢入原文并调用技能。关于该技能的安装命令、收费方式、支持平台清单及具体运行环境，资料中暂未提供。