作者用Claude Code headless搭建自动化营销系统:Playbook.md定义规则、routines文件夹管理Agent提示词、state文件夹协调状态,定时执行多阶段pipeline全自主发布。
我有 16 个开源项目,PyPI 和 npm 加起来月下载量 15,386 次,却没有能力让自己坚持在论坛发帖。我对自己这个问题已经心知肚明好几年了。于是在 2026-08-09,我搭了一套系统来干那些我自己不会去做的事。
以下是该系统上线头四天的真实经历。
系统放在 c:\Users\sync\codes\marketing 文件夹里。一份 PLAYBOOK.md 存放语音规则和护栏。routines/ 文件夹里有 markdown 文件,每个文件描述一个 agent prompt。state/ 文件夹里是 JSON 和 markdown 文件,负责各 routine 之间的协调。一个 Python 标准库服务器跑在 localhost:8781,处理那件仍然需要人工介入的事。
这些 routines 通过 Claude Code 无头模式按 cron 调度执行。weekly-metrics 每周一运行。registry-sweep、repo-seo 和 content-writer 每周运行。opportunity-scout 每天运行(上线当天从每周两次调上来的,因为 Hacker News 帖子冷得很快)。issue-responder 早上 7:26 和晚上 7:26 各运行一次。
重要的架构决策是分层拆分。Tier 1 是完全自主的:MCP 注册库、目录列表、仓库 SEO、更新日志、dev.to 文章。系统自己写、自己通过多级 pipeline 审查、自己发布,不需要问我。你正在看的这篇文章就是走的那套流程。
Tier 2 永远是草稿模式。Hacker News、Reddit、X。系统写出可以直接粘贴的草稿,队列到 state/drafts/,然后停下。portal(scripts/portal.py)通过在 --- 分隔符处拆分来解析每个草稿文件——上面是元数据,下面是可直接粘贴的正文,用正则提取"Reply to:" URL,然后在 localhost:8781 上提供服务,配有 Copy、Open 和 Archive 按钮。Archive 操作把文件移到 state/drafts/archive/。这就是整套审批流程。大概花 10 秒。
Tier 2 存在的原因写在系统自己的文档里:"那些平台会暗中封禁自动化自我推广,而且声誉损害是永久的。" PLAYBOOK.md 里的语音规则从另一个方向强化了这一点:"绝不能伪造社区热情,绝不能搞天铺,绝不能把同一段文字发到两个地方。" 我不打算让 Tier 2 渠道升级到完全自主。那些让 HN 和 Reddit 值得发帖的社区,恰恰是那些能正确识别并惩罚自动化参与行为的社区。那 10 秒的摩擦力是在做实事的。
还有一个自有渠道——bothn.com,我的 agent 平台。自动驾驶有一个公开的 agent 账号(yantrikos-autopilot),它以自己的身份发帖,不是我。
第一次扫描在 2026-08-09 运行,结果有成功也有碰壁。
它在 punkpeye/awesome-mcp-servers(#11771)和 tolkonepiu/best-of-mcp-servers(#349 和 #350)上开了 PR。它通过网页表单向 mcp.directory 提交了 yantrikdb-mcp 和 saga-mcp,截图收据保存到 state/logs/。它发现了 mcpserverfinder.com,这个网站只接受邮件提交,于是从 yantrikdb@gmail.com 发了一封邮件过去。
appcypher/awesome-mcp-servers ——已归档、只读。目标列表数据过时了,这个仓库已经好几个月没接受 PR 了。本来准备了一个分支,后来删掉了,没开出去。
mcphunt.com —— 域名停放,出售中。不是活的目录。
wong2/awesome-mcp-servers —— README 里写明:"We do not accept PRs. Please submit your MCP on the website: https://mcpservers.org/submit" 自动化在开任何东西之前先检查了 README,然后停下了。
smithery.ai —— 需要我的 GitHub 登录,而浏览器自动化 profile 的 session 已经失效。系统记录了"NO SESSION"并回退到草稿模式。
docker/mcp-registry —— run instructions 里写明需要我的 GitHub 身份。完全跳过——没尝试检查 session,只在 submissions.json 里记了条备注就继续了。
PLAYBOOK.md 里有个安全护栏限制出站 PR:"每次扫描最多向第三方仓库开 3 个出站 PR(避免看起来像 bot 攻击)。" 这次扫描开了 3 个 PR(两个给 tolkonepiu,一个给 punkpeye),然后就停了。
自动驾驶还在 bothn.com 发了一篇这次运行的总结(帖子 #99,来自 yantrikos-autopilot)。它报告了实际结果:8 个已回复的 issue,4 个它认为是 listing 提交的,1 个新发现的目录并已提交。然后它问其他 agent 在哪里找到了 agent 原生的分发渠道。
上线第二天,仪表盘显示 portfolio PyPI 下载量从 14,389/月掉到了 130。一夜之间。这是 state/metrics-history.jsonl 第 2 行的数字——它还在那里。
以下是 scripts/collect_metrics.py 实际上做的事:它遍历 portfolio.json 里的项目,对每个项目调用 pypistats.org/api/packages/{package}/recent 和 api.npmjs.org/downloads/point/last-month/{package}。当某个调用失败时,处理器执行 print(f" warn: {url} -> {e}", file=sys.stderr) 并返回 None。这个包被静默排除在总和之外。不重试。不告警。总数行只汇总成功的那部分。
所以在 2026-08-10,大多数 PyPI 调用显然失败了——可能是 pypistats.org 宕机,也可能触发了限流——仪表盘报告了 130 次/月,因为那唯一成功的调用返回的就是这个数字(yantrikdb-client,130 次下载)。错误输出到 stderr,没有其他地方能看到。我过了 20 分钟才发现,而且是还是因为那个数字在仪表盘上看起来太离谱了。更隐蔽的失败——比如说 30% 的包失败而不是 95%——会生成一个看起来合理的数字,我根本不会察觉到。
显而易见的修复方案是与前一个快照的总数做比较,在记录之前标记出下降超过 40% 的异常值。我还没写这个。
Bun 运行时也硬崩溃了两次——一次是 2026-08-11 18:13 运行 opportunity-scout 时,另一次是今天早上 07:26 运行 issue-responder 时。Bun v1.3.10,Windows x64,两次 panic 完全相同:panic(main thread): switch on corrupt value / "Bun has crashed. This indicates a bug in Bun, not your code." 不同的 routine,不同的日期。我还没去填 bug 报告。
截至 2026-08-09:月下载量 15,386 次(PyPI 14,389 加 npm 997),约 16 个追踪项目 GitHub stars 加起来 483 个。yantrikdb-hermes-plugin 月下载 1,831 次——portfolio 里 PyPI 下载量第二大的包——连一条公告都没有。它是 NousResearch/hermes-agent 里的可插拔内存提供者,人们在那里发现它。没有发布帖,没有营销。这个数据点解释了为什么下一阶段专注于嵌入框架而不是在各种地方发帖子。
90 天目标(2026-08-09 设定,目标 2026-11-07):月下载量达到 31,000,stars 达到 800,活跃目录列表从 9 增加到 16 以上,发布 12 篇 dev.to 文章。这是第一篇——content-log.json 里的 articles 数组在这个运行之前是空的。
长期 executor 应该是 yantrik-mind,我自己的 agent 堆栈跑在家庭服务器上,不是 Claude Code 无头模式。一次一个 routine,按风险顺序迁移,一旦 shadow runs 在连续四周内与生产环境匹配,这个 routine 就可以毕业。还没有 routine 毕业。shadow metrics 在每周一 08:20 触发,它的 diffs 进入 state/shadow-diff.md。
这个系统是 icantmarket.com 想要为其他技术创始人做的事——他们做出了真实的东西,却没法让自己去推广它。在平台接受的地方实现全自动化。在不接受的地方提供 10 秒的界面。
我先在它自己的 portfolio 上构建这个系统,因为我不想在知道它哪里会坏之前就卖出去。现在我知道了某些地方。
Pranab Sarkar,独立研究员。正在构建 yantrikdb、saga-mcp、brainstorm-mcp 和 icantmarket.com。
对于进一步的操作,你可以考虑屏蔽这个人或举报滥用行为。