Agent 实践

研究笔记:wenzi-xhs-agent-skills — 小红书冷启动 Agent Skills 工程化样本

7 分钟阅读AIAgent小红书学习笔记
文章目录
  1. 一句话定性
  2. 关键事实
  3. 逻辑全景图
  4. 每个 Skill 内部结构（R-I-A1-A2 模板）
  5. 审计轨迹（这才是项目的工程化高光）
  6. 项目方法来源（融合 4 源）
  7. 升级路线图（三段位）
  8. 入门段（先审阅再安装）
  9. 进阶段（半天，做出可用的账号档案）
  10. 高手段（把它接进你的内容生产流水线）
  11. 场景迁移
  12. 场景 ①：把"虾说蓉城"做成 Agent Skills
  13. 场景 ②：技术团队的"内部方法论沉淀"
  14. 场景 ③：本地服务业的"冷启动模板"

原研究时间：2026-10-01 13:56 UTC；2026-10-13 资料核对修订 研究对象：https://github.com/wenziai/wenzi-xhs-agent-skills 维护账号：wenziai；方法来源按项目自述包括文子、yanliudreamer、dbskill、xhs-visual-director-skill 研究报告人：大管家 原报告版本：v1；本次按 2026-10-13 可读取的官方资料核对

长文方法论被拆解成六张可调用操作卡并形成复盘环
图 1：方法论变成可调用的 Skill，关键是执行与反馈都能接上。

一句话定性

它是把"小红书冷启动"这篇文章拆成 6 个可安装 Agent Skills 的工程化产物——文子在 X 上写了一篇 1000 粉长文，作者把它和 yanliudreamer 系列、dbskill、xhs-visual-director 融合并整理为方法论检查和示例提示，最终做成一套可以 cp -R 到 ~/.codex/skills/ 就能用的工作流包。

像把一本菜谱拆成 6 份操作卡，每张卡上写着"现在该做什么、做完给谁看、下一步交给哪张卡"——你不是厨师也能照着做出 6 道菜。

关键事实

  • 仓库：wenziai/wenzi-xhs-agent-skills。本次目录树未见独立 LICENSE，不能据公开可读默认获得商业打包/再分发授权。
  • 热度：删除缺少可追溯历史快照的精确数字；stars/forks 不证明运营方法有效。
  • 主语言：无主语言（主要是 Markdown）
  • Topics：agent-skills, codex-skills, content-creation, workbuddy, xiaohongshu
  • 6 个 Skill：wb-xhs-monetization-backsolve / wb-xhs-account-profile / wb-xhs-low-follower-pattern / wb-xhs-topic-bank / wb-xhs-humanize-compliance / wb-xhs-schedule-review
  • 每个 skill 内含：SKILL.md（方法论重写）+ test-prompts.json（拟用于触发、边界和回归检查的提示样例，不等于测试已执行）
  • 辅助文档：README / INDEX / BOOK_OVERVIEW / DIGEST / GLOSSARY / verified.md / FUSION_NOTES / DBSKILL_EXTRACTION_NOTES / VISUAL_DIRECTOR_FUSION_NOTES / PIPELINE_STATE
  • 审计目录：candidates/（候选池）/ rejected/（淘汰 + 理由）
  • 融合 4 源：文子 X Article + yanliudreamer X 系列 + dbskill + xhs-visual-director-skill
  • 演示：assets/ 含截图（hero-workbuddy-xhs.png, proof-500k-reads.png, proof-engagement.png, demo-low-follower-search.png）

逻辑全景图

定位档案对标选题改稿和复盘六步串联，复盘写回档案与选题库
图 2：复盘写回档案和选题库，运营工作流才有持续学习的闭环。
wenzi-xhs-agent-skills（方法论 → Skills 的工程化流水线）
├─ 触发层：你想做小红书（或已有账号要梳理/单篇要优化）
│   ├─ 路径 A：从零起号
│   ├─ 路径 B：已有账号重新梳理
│   └─ 路径 C：单篇内容优化
├─ 核心层：6 个 Skill 串联成环
│   ├─ ① wb-xhs-monetization-backsolve（变现倒推定位）
│   │       └─ 先回答"靠什么赚钱"，再反推账号方向
│   ├─ ② wb-xhs-account-profile（建账号档案）
│   │       └─ 给 WorkBuddy 写"长期记忆"——语气、边界、可信主张
│   ├─ ③ wb-xhs-low-follower-pattern（拆低粉爆款）
│   │       └─ 找粉丝少但数据好的样本，学结构不学表达
│   ├─ ④ wb-xhs-topic-bank（七类选题库）
│   │       └─ 痛点/数字/对比/稀缺/共鸣/资源/反常识 七个模板
│   ├─ ⑤ wb-xhs-humanize-compliance（去 AI 味 + 规则检查）
│   │       └─ 用真实材料校准语气，做通用发布检查；不是平台合规认证
│   └─ ⑥ wb-xhs-schedule-review（排期 + 复盘）
│           └─ ⚠️ 这是闭环节点——复盘结论写回 ② 档案 和 ④ 选题库
├─ 输出层：你最终得到什么
│   ├─ 账号档案（可跨会话读取的协作记忆）
│   ├─ 35+ 选题与标题
│   ├─ 前 10 条 / 30 天发布计划
│   ├─ 单篇成稿（标题、开头、正文、6-8 页图文拆页）
│   └─ 周复盘报告 + 下周实验
└─ 卡点层：新手最容易在哪里翻车
    ├─ 翻车点 ①：跳过 ① 直接做内容——变现路径不定，定位飘
    ├─ 翻车点 ②：拆对标学表达不学结构——直接踩版权雷
    ├─ 翻车点 ③：复盘只看不写回——闭环断了，越做越像新人
    └─ 翻车点 ④：把"过往 50 万阅读"当承诺——README 自己也声明"不代表对粉丝或流量的承诺"

每个 Skill 内部结构（R-I-A1-A2 模板）

---
name / description / trigger phrases（前 30 行决定 Agent 会不会调用）
---

# Skill 标题
├─ R — 原文（引用一手作者的原话，带出处）
├─ I — 方法论骨架（融合多源后的核心逻辑）
├─ A1 — 文章中的应用（用一个具体案例走一遍）
└─ A2 — 触发场景（描述 Agent 何时该调这个 skill）

审计轨迹（这才是项目的工程化高光）

作者自评形成方法记录，提示样例仍待执行并记录结果
图 3：方法论自评不是独立验证；准备了提示样例，也不等于运行了回归测试。
项目根目录
├─ candidates/    候选单元池（还没晋升成 skill 的备选）
├─ rejected/      被淘汰的候选 + 淘汰理由（公开记录"为什么不要"）
├─ verified.md    已通过验证的方法论单元（每条带 V1/V2/V3 三关）
├─ GLOSSARY.md    术语词典（保证 6 个 skill 概念一致）
└─ BOOK_OVERVIEW.md  对原文方法论的批判性理解（含"作者的时代局限/立场盲点/未被证明的假设/最强反对意见"）

verified.md 的三关是作者组织方法论的自评记录，不是独立实验或因果验证： - V1 跨域证据：原文里有没有多处独立提到？ - V2 预测能力：能用它回答"如果 X 情况，下一步是什么"这种新问题吗？ - V3 排他性：是不是常识？非用这个方法不可的理由是什么？

项目方法来源（融合 4 源）

来源 用途
文子 X Article《别不信！WorkBuddy 就可以把你的小红书从 0 粉干到 1000》 冷启动主线
yanliudreamer X 系列 起号、个人 IP、内容验证、长期增长
dontbesilent2025/dbskill 标题、内容诊断、对标、共鸣、开头、文风、复盘
ziguishian/xhs-visual-director-skill 图文视觉导演方法

项目 README 自述只保留短引用、重写方法和工作流，不含来源全文。这有助于追溯来源，但短引用或重写本身不自动证明版权合规，第三方许可、引用范围和实际用途仍需逐项核对。

升级路线图（三段位）

入门段（先审阅再安装）

  1. 先在仓库根目录审阅 6 个 SKILL.md 与来源/授权，再按项目 README 的复制方式安装；复制前检查目标目录是否已有同名 Skill，避免覆盖。本文没有安装或运行。
  2. 在 Agent 里直接说一句人话："我想做小红书面向职场新人的 AI 工具号，未来通过咨询变现"
  3. 让 Agent 自动按 ① → ② → ④ → ⑤ → ⑥ 跑一遍，看交付物
  4. 做这一件事就够了：看 Agent 给出的"变现路径 + 定位卡"——如果它问的问题让你想了两秒以上，说明它问对了

进阶段（半天，做出可用的账号档案）

  1. 在 ① 拿到变现路径后，真的写一次账号档案（②），把它存成你 Agent 的长期记忆文件
  2. 用 ③ 找 5-10 个真实低粉爆款样本，让 Agent 学结构——不要让它"自由发挥"
  3. 把 ④ 的七类选题库和你的账号档案绑死，不允许 Agent 跨过档案自由选题
  4. 每天发一条前，先跑 ⑤（去 AI 味 + 规则检查），再发
  5. 每周日跑一次 ⑥，把数据写回 ② 和 ④
  6. 每天做一件具体的事：按统一观察窗口记录曝光、点击、收藏、评论；刚发布的数据尚不稳定，不能强求 30 秒内得到可比结果。

高手段（把它接进你的内容生产流水线）

  1. 把 ⑥ 的复盘输出做成结构化数据（CSV/JSON），而不是 Word 文档——便于 Agent 跨周读取
  2. 给 ⑥ 加一道自动判断：哪些选题数据稳定好、哪些反复扑街——自动降权/升权
  3. 为 6 个 Skill 增加统一入口，并保留各自边界；README 将统一入口和可自动执行测试列为计划，不能写成已经交付。
  4. 在 ② 的账号档案里加"竞品观察"字段，让 Agent 每周自动扫对标更新
  5. 本质差距：普通人用 skills 是"让 Agent 帮我写小红书"；高手用 skills 是"让 Agent 帮我经营一个能持续学习的账号系统"——核心动作从"用工具"变成"养系统"

场景迁移

底层逻辑是：单篇长文方法论 + 多源融合 + 批判性消化 + 工程化拆解 = 任意垂直领域的 Agent Skills 包。

场景 ①：把"虾说蓉城"做成 Agent Skills

  • 信源 = 你自己的文章 + 行业公开方法论
  • 拆 6 个 skills：定位 → 内容档案 → 对标拆解 → 选题库 → 去 AI 味 + SEO → 排期复盘
  • 把 verified.md 改成你的方法论验证标准（V1/V2/V3 三个问题通用）
  • 注意变量：内容平台不同，"低粉爆款"的定义不一样；B 站看播放完成率，小红书看收藏率，公众号看转发率
  • 好处：你已有的内容方法论可以变成可执行 Agent 工具，不用每次重新解释
  • 风险：cdclaw-post-publisher 已经是 skill 形式了，可以直接借鉴 R-I-A1-A2 模板优化

场景 ②：技术团队的"内部方法论沉淀"

  • 把团队内部的"代码评审 SOP"、"故障复盘流程"、"新人 onboarding 指南"做成内部 Agent Skills
  • 用 candidates/ + rejected/ + verified.md 公开审计轨迹——让团队成员看得懂"为什么是这套而不是别的"
  • 每个 Skill 配 test-prompts.json 做回归测试
  • 注意变量：内部方法论经常变，verified.md 要带日期和版本号
  • 好处：新人入职不用读 50 篇文档，直接问 Agent
  • 风险：方法论所有权——上传前要确认知识产权归属

场景 ③：本地服务业的"冷启动模板"

  • 把"开咖啡馆""做小红书母婴号""做本地探店号"做成 6 个通用 skills
  • 换 platform 字段 = 换垂直领域
  • 注意变量：本地服务强依赖地理位置，复盘数据要带 LBS 标签
  • 可探索的用途：自有方法可整理成咨询模板；本仓库未见明确商业再分发许可，不能直接把它打包销售。
  • 风险：结果不可承诺——README 自己都说了"不能保证从 0 到 1000 粉"

部署/借鉴的好处、注意事项、风险

humanize-compliance 的原始 Skill明确只能做通用发布检查，审计字段写的是 prompts prepared。因此“可发”是 Agent 的建议，不是小红书审核通过、规避平台限制或合法导流的保证；真实经历也必须来自用户，不能为“真人感”编造案例。客户材料和后台数据交给云模型前，还需单独确认处理权限与发送范围。

好处

  • 一套现成的运营方法组织方式，可减少梳理成本；没有依据承诺节省一两个月。
  • R-I-A1-A2 的文档结构非常优雅——可以直接抄到任何 Agent Skill 项目
  • verified.md + candidates/ + rejected/ 的审计设计，是 Agent Skill 项目该有的工程化标准
  • 闭环节点（schedule-review → account-profile + topic-bank）的设计，是数据驱动内容生产的范式
  • 多源说明与提示样例便于审阅，但不是效果背书；测试是否执行、结果如何应另有记录。

注意事项

  • 本次未见独立 LICENSE。GitHub 的自动识别字段不是最终法律判断；参考 GitHub 许可说明，复用、修改或商业再分发前向权利人核实授权。
  • 单一文章衍生（文子 2026-07-06 一篇），方法论主观性强
  • "50 万阅读"截图是过往结果，README 自己也声明不代表承诺
  • 拆对标只学结构不学表达——这条边界要严格守住
  • Skill 内部用了大量第三方 skill（dbskill、xhs-visual-director）的转译，引用边界要核实

风险

  • 不能用短期 stars 增长推断成熟度；应观察真实样例、行为测试和版本维护。
  • 文子本人是博主，方法论带强个人风格——直接套用可能不适配所有赛道
  • 数据闭环依赖用户手动复盘——大部分新手不会坚持，这是设计假设里的最大风险
  • 国内小红书平台规则变化频繁——Skills 里的"规则检查"很快会过时

与我相关的判断（可借鉴点）

  1. R-I-A1-A2 Skill 文档模板——优雅、可复用、可回归测试。值得直接抄到我自己的 Agent Skills 项目里
  2. V1/V2/V3 三关验证——是判断"该不该单独搞一个 skill"的标准方法，比"我觉得有用"严谨得多
  3. 审计轨迹公开化（candidates/ + rejected/ + verified.md）——把"为什么是这 6 个"透明化，是少见的工程化诚实
  4. 闭环节点设计（schedule-review 写回档案和选题库）——数据驱动内容生产的范式，跨项目通用
  5. 方法论重写 + 来源记录——有助追溯，但不能代替授权与引用范围审查。
  6. 触发语写入 description——是选择 Skill 的重要提示，不保证所有 Agent 必然自动调用。

一句话总结

wenzi-xhs-agent-skills 的灵魂是"把方法论当原材料，把 Skill 当成品"——它示范了怎么把一篇好文章工程化成可安装、可验证、可回归的工作流包。它的赌注是：好方法论只有变成 Agent 能调的 Skill，才真正有人用。

附录：相关链接

  • 仓库：https://github.com/wenziai/wenzi-xhs-agent-skills
  • 原始 WorkBuddy 文章：https://x.com/Eejoylove/status/2074028317498601870
  • 融合源 1（dbskill）：https://github.com/dontbesilent2025/dbskill/tree/main
  • 融合源 2（xhs-visual-director-skill）：https://github.com/ziguishian/xhs-visual-director-skill
  • 安装路径：~/.codex/skills/ 或 ~/.claude/skills/

2026-10-13 资料核对说明： 实际浏览仓库，读取 README、verified.md、humanize-compliance/SKILL.md 原始文件和目录树；项目的 V1/V2/V3 与阅读截图仅作为作者材料，不是本文独立运营验证。未安装 Skill、运行提示回归或发布小红书；未重新核验所有第三方来源全文及其授权链。

记录到这里，判断留给实践。