Post 评分器
Codex 和 Claude 运行时
- 在 Codex 或 Claude 中使用此技能时，请使用当前任务实际可用的工具。
AskUserQuestion示例描述的是问题本身，而非必需的 API：请在其限制范围内使用可用的提问工具，或在聊天中直接提问。重复使用已提供的答案和原始资料。 - 在用户选择的项目中工作。在进行个性化工作之前，请阅读项目的
about-me.md、voice.md以及相关的品牌文件。如果文件之间存在冲突或包含默认值，请确认预期的作者。询问缺失的事实或运行voice-builder；切勿继承维护者的身份、账户或私有文件。 - 相对于此技能文件夹解析捆绑的
references/。对于明确要求的个人资料刷新，请就地读取并更新规范的about-me.md、voice.md或newsletter-voice.md，保留无关的用户事实和规则。使用者必须重新读取这些规范文件。仅对可能与现有无关文件冲突的新交付件使用新文件名。单独的安装操作绝不会开始对话或写入文件。除非被要求，否则不要写入持久性学习内容。 - 优先使用提供的证据。必要时通过可用的搜索/来源工具验证外部声明。如果某个来源或集成不可用，请说明缺失的能力，并提供已提供的文本/导出输入。切勿捏造事实、第一人称经验、指标或成功的工具运行结果。
- 仅通过用户的现有账户连接所选路线所需的服务。切勿打印凭据或覆盖连接。起草、保存和审核不代表授权发布、发送消息或更改账户。
关键：加载时自动启动
当此技能触发时，直接进入步骤 1。不要总结。不要解释评分方法。立即开始。
步骤 1. 获取帖子
如果用户已在同一条消息中粘贴了帖子，则使用它。否则请说：
请粘贴你想要评分的 LinkedIn 帖子。
等待帖子。
步骤 2. 加载评分数据
评分器需要两样东西：用户的声音系统和真实的性能数据。
声音系统
如果项目中存在 about-me.md 和 voice.md，则读取它们。如果缺失，请注明并在没有声音匹配的情况下评分。
性能数据
检查所选项目中用户提供的导出文件或缓存的帖子数据。在使用前，请验证作者、收集日期和覆盖范围。切勿搜索其他用户的文件夹或回退到维护者的基准数据。
如果数据缺失，请提供以下选项：
- 使用用户帖子导出的上传文件以及汇总的互动计数。
- 使用用户授权的 Apify 连接获取用户的帖子正文和汇总计数。在进行付费运行前，请确认账户、范围和当前成本。在调用 actor 之前，请验证其当前文档记录的输入模式；不要猜测回退的 actor 输入。
- 现在进行编辑评审，并将性能比较标记为不可用。
对于 Apify 运行，apimaestro/linkedin-profile-posts 是现有的提供商路线。使用小批量请求（最多 100 条帖子）。请求 帖子正文和汇总计数。切勿抓取评论或回复，包括通过 deepScrape 或 numComments。如果 actor 无法排除评论正文，请使用其他经过验证的仅帖子路线或请求导出。不要运行评论抓取后再丢弃。
将所获允许的帖子数据保存在项目中的 outputs/post-scorer/ 目录下，并注明作者和收集日期。如果 Apify 不可用，请保留草稿并提供导出/编辑路线。不要声称历史记录已被获取。
步骤 3. 分析最佳表现者
当性能数据可用时，在进行评分前运行此分析：
- 计算每篇帖子的互动分数：总点赞数 + （汇总评论数 × 3），这是一个编辑权重，而非私有覆盖分析数据。
- 找出互动分数最高的 10% 帖子。
- 从这些顶级帖子中，提取：
- 出现频率最高的 Hook 类型（反常规、数据驱动、大胆声明、个人故事、提问、新闻）
- 平均帖子长度（字数）
- 格式分布（纯文本、图片、轮播、视频）
- CTA 模式（新闻通讯提及、评论引导、转发请求、提问、无）
- 主题聚类（哪些主题的互动率异常高）
- 句子节奏（平均句子长度、每篇帖子的段落分隔数）
- 同时记录底部 10% 帖子的模式，以确定哪些表现不佳。
在此评审中记录来源、日期、样本量和模式。除非被要求，否则不要写入持久性记忆。未知计数即为缺失，而非零；当样本量过小或存在选择偏差时，请明确说明无法支持性能比较。
步骤 4. 评分帖子
按 5 个标准评分，每个 1 到 10 分。将编辑判断与测量的历史比较分开。如果既没有声音配置文件也没有经过确认的作者样本，则将声音匹配标记为不可用，并按 40 分计算总分；否则使用 50 分。没有数字总分能预示预期表现。
Hook 强度（1 到 10）
将草稿的开场行与顶部 10% 帖子的 Hook 类型进行比较。
- 它是否使用了该作者历史上表现良好的 Hook 类型？
- 它是否具体，包含数字、名称或具体细节？
- 根据实际阻止滚动浏览的数据，它是否能阻止滚动？
- 有历史数据时，引用相关模式；没有时，将 Hook 分数标记为编辑判断，并将历史适应性标记为不可用。
声音匹配（1 到 10）
如果存在 voice.md：
- 帖子是否与 voice.md 中的语气、节奏、句子长度匹配？
- 帖子是否违反了 voice.md 缺席模式部分中的任何规则（该声音从不做什么）？
- 句子长度是否与其顶部表现者的平均值匹配？ 如果不存在 voice 文件：使用来自帖子数据的经过确认的作者样本。如果两者都不可用，则将此标准标记为不可用。
价值密度（1 到 10）
与用户的顶级表现帖子进行比较：
- 他们最好的帖子是教学、提供步骤、分享数据，还是讲故事？
- 此草稿是否匹配该价值模式？
- 结论是否足够具体，以至于有人会保存或分享它？
- 将字数与其顶部 10% 平均值进行比较。如果远远超出或低于，则标记。
结构和格式（1 到 10）
基于他们的数据：
- 哪种格式（文本、图片、轮播）为他们获得最多互动？
- 草稿的结构是否与顶部帖子的换行和段落节奏匹配？
- 帖子在移动设备上是否易于浏览？
- CTA 是否与其最佳表现者的模式匹配？
发布就绪度（1 到 10）
- 所有声明是否有支撑，必需项目是否涵盖，编辑是否完成？不要从风格推断作者身份。
- 此帖子是否会根据其发帖历史自然地融入用户的 feed？
- 是否存在任何警示信号：voice.md 缺席模式部分中列出的禁用词、通用短语、公司语气？
- 与其顶部表现者相比，长度是否合适？
步骤 5. 输出评分卡
在代码块中输出：
LINKEDIN POST 分数
数据来源：[经过验证的作者导出文件 / 经过验证的 Apify 结果 / 仅编辑评审]
分析的帖子数：[数字或不可用]
顶部 10% 平均互动：[测量数字或不可用]
Hook 强度： [X] / 10 [检测到的 Hook 类型]
声音匹配： [X] / 10
价值密度： [X] / 10
结构和格式： [X] / 10 [格式：文本/图片/轮播]
发布就绪度： [X] / 10
----------------------------------------
总分： [XX] / [50 或 40，排除不可用的声音匹配]
结论：[一句引用具体数据的话]
顶级表现者比较：
您的顶级帖子平均 [X] 字，使用 [Hook 类型] Hook，
并包含 [CTA 模式]。此草稿 [匹配/不同] 因为 [具体原因]。
修复：
1. [基于数据的具体修复，例如：“您的顶部 10% 帖子以数字开头。此帖子以问题开头。建议改为统计数据。”]
2. [基于数据的第二个修复]
3. [如果需要，第三个修复]
为历史比较引用实际证据。对于仅编辑评审，省略顶级表现者比较，并提供标记为“编辑”的具体文案/结构修复。切勿使用虚构指标填充模板。在评分前，对照确切的草稿检查每个必需的项目或步骤。
步骤 6. 提供后续步骤
在评分卡之后：
希望我用您顶级帖子的模式重写最薄弱的部分，还是直接发布？
如果请求重写，应用修复并在代码块中输出修订后的帖子。
规则
- 始终尝试使用真实数据，然后再回退到通用建议。
- 将每个发现标记为基于来源/历史，或编辑判断。
- 高编辑分数并不代表历史适应性或预示覆盖范围。
- 要诚实。一个慷慨的评分器毫无用处。
- 如果数据过时（14 天以上），建议在评分前刷新。
- 在运行 Apify 抓取前告知用户（需要付费）。
- 任何输出中不要使用 em dash。
- 全文使用英式英语（本项目保留原英文）。
- 保持评分卡紧凑。它需要在活动大屏上看起来美观。