核心模型
先别急着背命令。在开始用 XHSSpec 之前，你得先搞清楚它在帮你管什么事。
这篇文章会带你理解 XHSSpec 的核心概念：Brand、Strategy、Spec、Command、Run、Artifact、Publish、Knowledge。这些词看起来挺抽象，但只要你往下读，就会发现它们每一个都在解决真实的问题。
Brand：你是谁
你有没有遇到过这种情况：让 AI 帮你写一篇文章，它写得还行，但总觉得哪里不对劲。语气不对，例子不贴切，有些话你根本不会这么说。
这就是问题所在：AI 不知道你是谁。
它不知道你是一个工作了五年的后端工程师，喜欢用故事讲技术，反对八股文。它不知道你的读者是刚入行的初级开发者，最需要的是实操性的东西而不是理论。它不知道什么东西你绝对不能写——比如任何贬低其他技术栈的言论。
Brand 就是来解决这个问题的。
Brand 是「你是谁」的完整描述。它包括：
- 身份定位：你是谁，你做什么，你有什么背景
- 目标读者：谁在看你的内容，他们的痛点是什么
- 语言风格：你喜欢用什么语气说话，举个什么例子
- 红线边界：什么东西绝对不能写，什么话题绝对不碰
举个例子。假设你是一个做 AI 产品的程序员，你的 Brand 可能长这样：
身份定位：前大厂工程师，现在做 AI 产品，擅长把复杂的技术讲简单
目标读者：想了解 AI、但被各种术语吓退的产品经理和开发者
语言风格：故事驱动，用生活化的例子解释技术概念，反对故作高深
红线：不接广告、不写虚的、只写自己真的用过的产品把这个告诉 AI 和不告诉 AI，写出来的东西完全不一样。前者是「一个有性格的人在做分享」，后者是「一个不知道谁写的通用文章」。
这就是 Brand 的价值：它让 AI 写出「像你」的东西，而不是满大街都是的 AI 味内容。
什么时候该用 Brand？每次让 AI 帮你写东西之前，先问自己：AI 知道「你是谁」吗？如果不知道，那这就是你第一个要解决的问题。
Strategy：你要打什么
好，现在 AI 知道你是谁了。接下来一个问题：你要写什么？
你可能觉得选题有什么好想的，想到什么就写什么呗。但如果你真的这么做，用不了多久就会遇到两个问题：
第一，你不知道还能写什么。写了十个选题，发现能写的都写完了，进入贤者时间。
第二，你写的东西没有一致性。这周写 Python 技巧，下周写 Java 面试，再下周写职场感悟——粉丝根本不知道关注你能得到什么。
Strategy 就是来解决这个问题的。
Strategy 是「你要打什么」的完整规划。它不是具体的某一篇要写什么，而是你整体的作战地图。包括：
- 内容支柱：你的主要内容方向，比如「AI 产品实战」「程序员职场成长」「技术写作方法论」
- 选题框架：每个支柱下面，有哪些类型的选题可以持续输出
- 关键词地图：你想占领哪些关键词，用户搜索什么会找到你
继续用刚才的例子。你的 Strategy 可能长这样：
内容支柱：
- AI 产品方法论（40%）：从 0 到 1 做 AI 产品的思考
- 实战复盘（30%）：具体项目的经验教训
- 工具测评（20%）：AI 工具的真实使用体验
- 职场思考（10%）：程序员转型的感悟
选题框架：
- AI 产品方法论：AI 产品的设计模式、AI 与工作流、提示工程实战
- 实战复盘：项目复盘、踩坑记录、方案对比
- 工具测评：横向测评、使用技巧、替代方案
- 职场思考：转型故事、能力模型、学习方法
关键词地图：
- 核心词：AI 产品经理、AIGC、提示工程
- 长尾词：程序员转型 AI、AI 产品怎么入门、提示词优化有了这个地图，你就不用每次都从零开始想「写什么」。选题的时候，直接从框架里挑就行了。而且因为你有清晰的内容支柱，粉丝也知道关注你能得到什么。
什么时候该用 Strategy？当你写了几篇之后，发现选题开始随机了、不知道还能写什么了，那就是该建立 Strategy 的时候。
Spec：规则是什么
好，现在你知道你是谁、你要打什么了。接下来一个问题：怎么判断一篇写得好不好？
你可能觉得，这有什么难的，写得好不好看不出来吗？
问题是，每个人的「看出来」标准不一样。
你今天心情好，看了一篇觉得「还行」；明天心情不好，看了一篇觉得「垃圾」。但标准呢？你说不出来。你让 AI 改，AI 问「哪里要改」，你也说不出来。
这就是没有 Spec 的问题：质量判断全凭感觉，修改意见无法量化。
Spec 是「规则是什么」的完整定义。它告诉 AI 什么算合格、什么算优秀。包括：
- 内容结构：笔记应该是什么格式，开头怎么写，中间怎么展开，结尾怎么收
- 质量标准：什么样的标题算吸引人，什么样的开头算抓住人
- 审核规则：review 的时候要看什么指标，什么情况算通过
- 适切性判断：热点话题怎么判断该不该追，什么样的热点适合你的账号
继续上面的例子。你的 Spec 可能长这样：
内容结构：
- 开头：用一个具体的问题或场景引入，让读者有代入感
- 展开：1-2 个核心观点，每个观点配一个实际案例
- 结尾：要么总结要点，要么留一个思考题，要么推荐延伸阅读
质量标准：
- 标题：必须包含具体数字或对比，必须让读者知道能学到什么
- 开头：前 50 个字内必须出现读者关心的痛点
- 案例：必须是真实的、具体的、带细节的，不能是泛泛而谈
审核规则：
- 准确性：技术细节必须经得起验证，引用数据要注明来源
- 原创性：必须有自己独特的观点，不能是综述性质的文章
- 可读性：每段不超过 3 句话，长句要拆开
适切性判断：
- 相关度：热点必须与 AI 产品相关
- 独特性：有没有独特视角，而不是简单的新闻搬运
- 时效性：热点是否还有讨论价值，还是已经烂大街了有了 Spec 之后，review 就不再是「感觉行不行」，而是有据可依的判断。你告诉 AI 按照这个标准写，AI 写完 你按照这个标准审，一切都有章法。
什么时候该用 Spec？当你发现 AI 写出来的东西每次标准都不一样、你自己也说不出哪里好哪里不好的时候，那就是该建立 Spec 的时候。
Command：怎么开始
好了，现在你有了 Brand、Strategy、Spec。接下来一个实际问题：怎么开始干活？
XHSSpec 提供了几种不同的 Command，对应不同的干活方式：
quick：临时起意
你想到了一个小点子，想快速写一篇笔记试试。不用搞那么复杂，直接 quick 走起。
这个 Command 会帮你走完一个轻量级的流程：brief → draft → review → done。跑完就走，不搞那么多花架子。
适合场景：突然想到一个想法想记录、看到一个小的技术点想分享、想测试某个选题的数据。
hot：追热点
你发现了一个热点，想判断一下该不该追。该不该写？该怎么写？能不能蹭？hot Command 会先让你做适切性检查，然后根据结果决定是继续创作还是放弃。
适合场景：看到某个技术新闻很火、某个产品发布了新功能、某个话题上了热搜。
plan：策划系列
你想做一个系统的内容系列，比如「AI 产品 30 讲」或者「程序员副业指南」。这种需要长期规划的，就用 plan。
这个 Command 会帮你做完整的策划：选题拆分、节奏规划、质量标准。适合需要持续输出、有明确目标的场景。
适合场景：做付费专栏、做系列教程、做月度主题策划。
draft：写draft
在 hot 或 plan 的流程中，如果已经确定要写了，会进入 draft 阶段。这个阶段就是专注于把内容写出来。
review：审核
draft 写完了，需要人来看一眼给反馈。这就是 review 的作用。
iterate：迭代
review 给完反馈了，需要根据反馈修改。这就是 iterate。
publish：发布
内容定稿了，需要整理成可以发布的格式。这就是 publish。
archive：归档
一个 run 结束了，需要归档，记录最终结果。这就是 archive。
每个 Command 对应一个完整的 workflow，帮你把该走的步骤都走一遍。你不用自己记流程，CLI 会推着你往前走。
Run 和 Artifact：每一次都留下痕迹
现在你理解了怎么开始干活。但还有一个关键问题：这些产物都去哪了？
你可能有过这种经历：让 AI 写了几十版文案，最后选了一版发出去。其他的呢？找不到了。下次想参考之前怎么写的，发现记录全在聊天框里，翻都翻不到。
这就是问题所在：聊天记录不是为「留下东西」设计的。对话天生是线性的、过时的、难以检索的。
XHSSpec 用 Run 和 Artifact 来解决这个问题。
一个 Run，就是你每一次运营动作的完整容器。它装的是这次动作全部的产物：brief、draft、review 意见、适切性检查结果、复盘笔记。
这些产物不叫「文件」，叫 Artifact。Artifact 是每一步真正写出来的东西，而 Run 是装这些 Artifact 的盒子。
举个例子。你用 hot 追一个热点，完整的过程是这样的：
Run: hot-2024-01-15-AI产品发布
├── brief/
│ ├── topic.md # 选题brief，说明为什么追这个热点
│ └── outline.md # 大纲，要写哪几个点
├── check/
│ ├── relevance.md # 适切性分析，这个热点该不该追
│ └── verdict.md # 结论，approved 还是 rejected
├── draft/
│ ├── v1.md # 第一版draft
│ ├── v2.md # 第二版draft
│ └── final.md # 定稿
├── review/
│ ├── feedback.md # review意见
│ └── decision.md # 结论，approved 还是 needs-revision
└── meta/
├── log.md # 操作日志
└── summary.md # 复盘总结这就是一个完整的 Run。所有产物都结构化地保存在这里，下次想找任何历史记录，直接去对应的目录翻就行。
XHSSpec 最核心的一条原则是：不要把内容留在聊天里。聊完就散了，但 Artifact 会一直待在它该待的地方。
Publish：发布不是终点
内容写完了，review 也通过了，然后就结束了吗？
不是的。
真实情况是：终稿只是第一步。封面怎么做、配图从哪里找、要不要补一张 demo 图、发布时间选哪个、数据监控怎么设——这些破事比写正文还烦人。
很多人大兴冲冲写完稿子，发出去，然后就等着数据。结果数据不好，也不知道为什么。
Publish 阶段就是专门处理这些的。
它生成的不是一个「自动发布」，而是一个「发布包」——包含：
- 终稿：review 通过的最终版本
- 封面方向：建议的封面文案、参考样式
- 配图建议：需要哪些配图，从哪里找
- 发布检查清单：标题对不对、标签打没打、发布时间合不合适
- 数据预期：预期数据范围、关注指标
这个包不是给 AI 看的，是给你看的。它把所有「发布前要确认的事情」整理好，让你在真正点发送之前，不会漏掉任何环节。
什么时候该做 Publish？每次内容定稿之后、真正发布之前。
Knowledge：让经验沉淀下来
跑完一个 Run 之后，然后呢？
很多人就跑了，不回头。下一篇继续写，写完继续跑。永远是全新的开始，永远没有积累。
这是最大的浪费。
你这次追热点，有什么经验教训？适切性判断是怎么做的？哪个角度写得好，哪个角度没人看？这些经验，如果就这么让它跑了，下次遇到类似情况，你还得从头摸索。
Knowledge 就是来解决这个问题的。
每次跑完一个 Run，你都应该做复盘，把这次的经验写进 knowledge/ 目录。包括：
- 有效的创作模式：什么样的选题容易火、什么样的开头吸引人、什么样的结构读起来舒服
- 踩过的坑：哪个热点不该追、哪次写作方向错了、哪个 Spec 标准定得不合理
- 热点教训：这次追热点的结果是什么，下次追类似热点要注意什么
这些知识会被保存下来。下次 AI 干活的时候，这些都会变成它的参考。
团队能力怎么变强？就是靠这一次次留下的经验，而不是那一次次聊过的天。
placeholder：诚实面对未完成
你可能还注意到一个问题：写内容的时候，经常会有一些「故意留白」的地方。
比如标题想了好几个，都不太满意，想再想想。比如某个数据还没查到，想先空着。比如某个观点还想再打磨，先写个草稿。
这些未完成的部分，如果你不管它，它就会偷偷溜到下一个阶段。你以为你只是「还没想好」，实际上你已经忘记了还有这回事。
<placeholder> 就是来解决这个问题的。
用 <placeholder>这里还没想好</placeholder> 标出来。
它不是提示词，是流程协议。系统会记住这里还没完成，不会让它偷偷溜到下一个阶段。未完成就是未完成，别骗自己。
每次 review 的时候，检查一下所有的 placeholder 都填上了没有。没有填，就退回去继续改。这是保证质量的一个小技巧。
CLI 和 Agent：各管各的
最后一个问题：XHSSpec 里面，CLI 和 Agent 分别负责什么？
简单说：CLI 管确定性操作，Agent 管创造性操作。
CLI（也就是你运行的那些命令）做的是：
- 初始化项目结构
- 创建目录和文件
- 管理状态流转（created → drafting → reviewed → done）
- 校验完整性（检查 required 字段有没有填）
- 落盘保存（把产物写到该写的地方）
这些事不需要动脑子，按规则走就行。它保证的是「流程不出错」。
Agent（也就是 AI）做的是：
- 理解 Brand 语境，写出符合你风格的内容
- 判断热点适切性，这个热点该不该追
- 写 brief 和 draft，创作具体的内容
- 做语义审核，判断内容质量好不好
- 生成发布建议，封面用什么、标签打什么
- 提炼经验教训，这次有什么可以沉淀的
这些事需要理解力和判断力。它保证的是「创作有质量」。
两边各管各的，谁也不抢谁的活。CLI 不会试图自己写文章，Agent 也不会试图自己创建目录。这是一个分工明确的协作系统。
好了，现在你理解了 XHSSpec 的核心模型。Brand 让你被记住，Strategy 让你有方向，Spec 让你有标准，Command 让你知道怎么开始，Run 和 Artifact 让你留下痕迹，Publish 让你不遗漏任何发布细节，Knowledge 让你持续变强，<placeholder> 让你诚实面对未完成，CLI 和 Agent 各管各的让你不混乱。
这些概念不需要一次性全部理解。你可以在实践中慢慢体会，用到哪个就回来看看。
核心就一句话：把内容运营变成一个可沉淀的系统，而不是一次性的随机创作。