Quick 工作流
一句话：临时起意想写点什么的时候，直接开跑。
什么时候该用这个
你正在改代码，突然想到一个特别想分享的观点。
你早上醒来，脑子里冒出一个有意思的想法。
你在地铁上刷小红书，看到一条笔记引发了你的思考。
这些时刻都有一个共同点：你不想搞得太正式，不想建什么项目、列什么计划，就是想把脑子里的想法记录下来、整理成一篇可以发出去的笔记。
Quick 就是为这种时刻而生的。
它不要求你有完整的系列规划，不要求你想清楚三篇怎么写、五篇怎么发。它只要你有一个想法，然后帮你快速走完从想法到发布包的完整流程。
适合 Quick 的场景
- 日常更新，没有系列规划
- 突然有个想法想记录下来
- 低仪式感的创作，就是想发
- 灵感来了，想趁热写完
- 临时起意，想蹭一个不那么热的热点
简单来说：当你脑子里只有一个想法，而不是一个计划的时候，用 Quick。
一个完整的创作故事
让我带你走一遍 Quick 的完整流程，你就知道它是怎么工作的了。
第一步：想法来了
周二下午三点，你正在改一个 bug，改得有点烦躁。突然，你想到一个观点：「程序员真的不应该继续把 AI 当临时写手用。」
这个想法不是凭空来的。你上周用 AI 写了一个脚本，用完就扔。但如果你用 repo-first 的方式管理它，这个脚本以后可以反复用、可以分享给同事、可以沉淀成你工作流的一部分。
你觉得这个观点值得写一篇。
如果是以前，你可能会：
- 打开笔记软件，记个草稿，然后就没有然后了
- 打开小红书，直接开始写，写到一半不知道该怎么收尾
- 想了一下觉得太麻烦，算了吧
但现在，你打开 Claude Code，直接说：
帮我写一篇关于程序员用 AI 方式的笔记AI 没有立刻开始写，而是先确认了几个问题：
- 角度：是吐槽式的引发共鸣，还是方法论式的教别人怎么用？
- 受众：纯程序员，还是也包括产品经理、项目经理这些角色？
- CTA：想引导读者做什么？收藏？评论？还是关注？
你回答完之后，AI 说：「好，我帮你创建 Quick 工作流。」
第二步：brief 和初稿
AI 读取了你的 brand 配置（你之前用 init 命令填好的，包括你的账号定位、风格、常用话题等），然后生成了两个文件：
- brief.md：选题简报，包括选题背景、核心观点、目标受众、预期效果
- 初稿：基于 brief 生成的第一版笔记
你打开 brief 看了看，觉得方向没问题。再看初稿，结构是：
- 开头：一个场景切入——「你是不是也这样：用 AI 写个脚本，用完就扔」
- 观点：为什么这种方式Low，以及更好的方式是什么
- 方法：repo-first workflow 怎么运作
- CTA：欢迎在评论区分享你的 AI 用法
整体还行，但你觉得第三段有点太干了，缺少一些「攻击力」。于是你说：「帮我审核这篇笔记。」
第三步：审核
AI 不是简单地检查错别字，而是从三个角度给你反馈：
- 内容层面：观点够不够清晰，论据够不够有力
- 结构层面：开头能不能抓住人，结尾能不能让人行动
- 风格层面：语气是否一致，是否符合你的账号调性
审核意见出来了：
- 第三段的表达太温和，缺少一点「戳中读者」的力度
- 开头可以更直接一点，不要铺垫太长
- CTA 可以更具体一点，比如引导读者说出自己的痛点
你觉得这些意见很中肯，于是说：「帮我改写第三段，要更有攻击性一点。」
第四步：改写
AI 根据审核意见进行了改写。你看了一遍，觉得「对了，就是这个味道」。于是你说：「OK，这版可以了。」
第五步：发布包
现在草稿已经定稿了，你可以说：「帮我生成发布包。」
AI 生成了一套完整的发布包，放在 publish/2026-03-13/quick-xxx/ 目录下。里面包括：
- note.md：最终准备发布的正文版本
- first-screen.md：首屏策略——标题、冲突点、封面文案和第一眼的打开理由
- visual-plan.md：图文拆解建议——哪些内容适合拆卡片、适合截图、配图怎么组织
- demo.html：如果你想做信息卡或对比图，可以直接截这个页面
- posting-guide.md：发布前、中、后的动作引导
你打开 demo.html，截了两张图作为封面草案。然后把整个目录交给运营同事：「按这个包发。」
同事不需要知道 .xhsspec/ 里面有什么复杂的东西，只需要看到这个目录就能干活。
第六步：归档
最后，你说：「归档这次创作。」
AI 把整个创作过程归档，并自动生成了这次创作的复盘：
- 选题来源：临时起意
- 审核意见：3条
- 改写轮次：1轮
- 耗时：约20分钟
这些经验会沉淀到你的知识库里。下次你再想写类似主题的时候，可以直接从知识库里调取：「上次写这个角度效果不错，这次可以换个角度试试。」
交互方式
你不需要围着 CLI 生活，真正的前台入口是 AI 工具里的 slash command 和自然语言。Slash command 只是最稳定的入口：
/xhs:quick # 发起创作
/xhs:review # 审核草稿
/xhs:rewrite # 改写（如需要）
/xhs:publish # 生成发布包
/xhs:archive # 归档，沉淀经验或者更自然地，直接说「帮我写一篇 XXX」「帮我审核一下」「帮我改写第三段」，AI 知道什么时候该调用什么命令。
状态流转
created → drafting → reviewed → iterating → done → archived| 状态 | 意味着什么 |
|---|---|
created | 选题已创建，等待 agent 补完 brief 和首稿 |
drafting | 初稿已经生成，等待审核 |
reviewed | 审核意见已经给出 |
iterating | 正在根据审核意见改写 |
done | 发布包已经生成 |
archived | 经验已经沉淀到知识库 |
Gate：什么时候会被拦住
Quick 工作流有4个 Gate，保护你不会把半成品带入下一个阶段：
1. brand 没填完
如果你还没完成品牌定位配置，AI 会说：
先去医院检查 brand 吧，你的账号定位还没填完呢解决方案：运行 xhs-spec doctor 看看 brand 哪里没填完。
2. 草稿里还有 <placeholder>
如果你在 brief 或初稿里留下了 <placeholder>（比如某个数据没查、某个引用没填），AI 不会让你进入审核阶段。
解决方案：先把该填的填完，别偷懒。
3. 审核意见没写完
审核是改写的前置条件。如果你只是「看了一下」但没写正式的审核意见，AI 不会让你进入改写。
解决方案：认真写审核意见，这是在帮你打磨内容。
4. 终稿和审核没完成
如果审核意见还没处理完，或者终稿还没确认，AI 不会让你生成发布包。
解决方案：先把该改的改完，该确认的确认。
为什么 Quick 是「最小单位」
Quick 是 XHSSpec 的最小工作单元。
它把「从想法到发布」的完整路径，压缩成一个你可以独立使用的工具。你不需要为了一篇笔记而建立一个 Campaign，不需要为了一个热点而去想「我要不要做一个系列」。
Quick 就是为了那些「就是想写点什么」的时刻而存在的。