她把发帖权交给AI，却死守最后一道人工闸门

一个人打理一家店，社交媒体发布这件事有多耗人，做过的人都知道。这位创业者兼艺术家干脆用"氛围编程"的方式给自己搭了一套工作流：所有商业社交帖子，统一从同一个内容湖里起草、分发。

她的想法很直接——如果团队只有你一个人，任何能省下的优化都得抓住。但她同时给自己留了一条底线：最终批准权必须握在手里，不能让机器人自作主张发出去。用她自己的话说，这里得留点理智。

系统由四块拼起来

整套东西围绕她已有的 Rails 店铺 everfluorescent.com 搭建，包含四个部分：

• 一个定制化的 Sanity Studio
• 一个 Claude 智能体，通过 Sanity Context MCP 读取店铺和知识库，起草应季社交帖子
• 一个 Node 发布器，对外提供人工审核队列
• 一个 App SDK 应用，用来实时审核这些帖子

值得注意的是，目前没有任何内容真正发布到平台上，这是有意为之。她把这套系统的前半段称为"走到这里的经历"，包括那些花掉她好几天时间的坑；后半段才是系统本身怎么运转。

审核台：只批准，不发布

新增的审核台是一个 Sanity App SDK 应用，本质是一条分诊队列——智能体起草了社交帖子，人来做决定。它跑在 Sanity Dashboard 里，和项目 70komvgl 的 Studio 并排。

它的职责边界划得很清楚：它批准，但不发布。批准动作只是把 variant.status 置为 approved，这正是发布工作线程读取的状态。这里没有任何东西会去跟 Instagram 对话。

为什么做成独立应用而不是再加一个 Studio 面板？因为 Studio 一次只编辑一个文档，而审核队列的形状恰好相反。需要做决定的单位是"某个平台的变体"，而一篇帖子往往包含好几个变体——比如一篇万圣节帖子，有 Instagram 变体和 Facebook 变体，配文不同、素材不同，判定也各自独立。

所以这个应用会跨所有帖子列出变体，每个变体下面显示闸门的判定结果，以及推动它流转的按钮。

一条规则串起全部

整个系统靠一条规则维系：lib/platformSpec.ts 是唯一的事实来源，定义了每个平台接受什么。它也是预览面板和发布按钮共同依据的那套规则。

内容台这边，一篇帖子写一次，按平台分别渲染，预览面板画的正是守护发布按钮的同一套规则；还有一个夜间任务，会自己去把店铺目录拉进来。

项目结构里包含九种文档类型加一个变体对象、平台规格文件、守在变体和队列之间的预检检查、预览面板与四个平台模拟界面、实时同步控制台、发布按钮（它只批准，不发布）、从某个 vault 文件夹单向同步到知识笔记的工具，以及 Sanity 自己运行的函数——目录同步和它的夜间触发器。

已有的店铺底座

这套系统架在一个叫 Neoncart 的自托管店铺上，是 Ever Fluorescent 的 Rails 7.1 电商应用：Stripe Checkout 支持卡、Google Pay、Apple Pay；对接了多个代发货服务，其中 Printify 端到端打通，ThisNew、ArtsAdd、Yoycol 通过可配置适配器加人工队列接入；带品牌标识的发货邮件附免费追踪链接；还有支持工单台，以及面向 FestConnect、goVend 的合作伙伴 REST API 和签名 webhook。

没有付费附加服务：任务跑在 GoodJob 上（Postgres，也就是她的 Neon 数据库），图片通过 Active Storage 存在本地磁盘，追踪用免费承运商链接，邮件走普通 SMTP。技术栈是 Rails 7.1、PostgreSQL（Neon）、Puma、Hotwire（importmap，不用 Node）、Devise、Stripe、GoodJob、Faraday。

从终端里搭出来的时间线

她全程在终端里用 Claude CLI 构建这个项目。当 Claude 开始让她烦躁时，GitHub Copilot CLI 出手救过一次场。她尽量不把自己的 API 密钥到处传递，宁可自己来。

她一边做一边记笔记，能感觉到这是个大工程。以下是一条简要时间线：

9/23 之前：店铺这一侧。Phase 0 的 Studio 已经就位：schema、按平台的预览、预检检查、发布闸门、Obsidian 同步和目录同步。在 neoncart 这一侧，合并了四个 PR：一个产品 id 和画廊端点、Retro 帖子搜索归档、管理员批准队列，以及后续修复。她还在自己的管理后台里做了一个发布工具，可以在自己的店铺里预览商业帖子并发布；它从 Sanity 拉取内容，并保存已发布的帖子以便日后复用或修改。她跑了迁移，重启了 Jetson 服务，两个新的管理标签页都正常加载。

9/24：通过 Vercel 把店铺重新连回 Sanity。

9/26：智能体。店铺连上了，帖子也开始在批准区里出现，是时候把重活交给智能体了。generate.mjs 此前已经能根据模板（captionFor）起草处于 needs_review 状态的营销帖子。智能体替换掉了那个模板，管线的其余部分保持原样。它起草的内容现在会进入管理队列，审核卡片会显示来源在哪里出现分歧，以及每段配文基于什么。

9/27：打磨。她把顾客附近即将到来的活动，加上节日和季节，收集到一个文件里，好让帖子能按一年中的时节来限定范围。她写了一段更长的提示词，同时记录耗时，下面的缓存数字就来自这里。也是在这一天，她发现 Sanity 吐出了陈旧数据，最终追查到是同步的问题。重跑之后写出了五篇干净的万圣节草稿。

最后：审核台。一个 App SDK 应用（everfluorescent-desk）会跨所有帖子列出变体，附上闸门的判定，以及"批准／退回草稿"的操作。