一个终端循环命令，30秒生成全平台发布文案

上个月我上线了一个副项目，老实说，代码部分反而是最简单的。真正耗掉我整整一周时间的是发布文案：一条Product Hunt标语、一篇X线程、一条LinkedIn帖子、一篇完全不像广告的Reddit帖子，再加一堆SEO文章。同一个产品——五套完全不同的语调和定位。那个周三下午，我盯着满屏的聊天窗口，感觉自己像个在五个平行宇宙之间来回穿梭的翻译官，每个平台都是一套完全不同的语法体系。

后来我停下来想了一个问题：为什么我要把平台语音这种需要持久化的东西，塞进一个本质上属于易失性存储的聊天会话里？聊天窗口就像一张白板，每开一个新话题，之前精心调试的语调规则就消失了。每次重新打开对话，你都得从头解释一遍“Product Hunt要用第一人称，不能出现革命性这个词，字数控制在60个字符以内”。这不是在用AI，这是在给AI当24小时值班保姆。

最终我折腾出了一个工作流：每个平台的语音写成一个.txt文件，产品简介写成另一个文件，然后一条循环命令在大概30秒里跑完整个文案矩阵。下面就是这套方法的完整拆解，也包括了它目前还搞不定的地方。

工具用的是bl，这是阿里云百炼模型工作室的命令行接口。安装只需要一行npm install -g bailian-cli，再执行bl auth login登录就行。需要Node 18以上环境和一个API密钥，免费额度足够覆盖本文涉及的全部操作。选它的原因很直接：它支持--system和--message两个独立参数，而且两个参数都可以直接从文件读取。这就意味着你的系统提示词（也就是平台语音规则）和你的输入消息（产品简介）可以完全解耦，分别维护，随时替换。

文件目录结构大概是这样的：一个launch-copy文件夹，里面放brief.md产品简介文件，涵盖价值主张、目标受众、定价信息这些核心材料；一个voices子目录，放五份平台语音文件——ph.txt对应Product Hunt的标语和创作者评论，里面直接列了禁用词汇清单：革命性、改变游戏规则、颠覆，这些词只要出现就直接毙掉；x-thread.txt是X平台的6条推文串格式，规定第一条必须带钩子；linkedin.txt要求故事驱动、禁止表情符号墙；reddit.txt强调纯文本、零市场营销腔；seo.txt则是800词关键词文章的模板。最后还有一个out目录用来接收生成结果。整个架构就长这样，简单到让人觉得是不是少了点什么。

真正干活的就是这么一行循环命令：

for f in voices/*.txt; do bl text chat --system "$(cat "$f")" --message "$(cat brief.md)" > "out/$(basename "$f" .txt).md"; done

它做的事情极其朴素：遍历voices目录下的每个语音文件，把它作为--system参数传进去，同时把brief.md作为--message参数塞给模型，然后把输出重定向到out目录下的同名markdown文件。一次遍历，五套文案，约30秒全部搞定。没有状态管理，没有会话历史，没有需要手动复制的中间结果。文件就是状态，目录就是流程。

用这套方式跑了三周，有三个发现让我彻底放下了聊天窗口。

第一个发现是关于格式锁定的。我的第一版Product Hunt文案回来的时候，里面大喇喇写着“革命性”三个字。在一个聊天窗口里，这种情况的处理方式是手动删除，然后祈祷下次别出现。但在文件中，我只需要在ph.txt的禁用词汇清单里加上“革命性”、“改变游戏规则”、“颠覆”，从此再也没见过这些词。修复一次，永久生效。而且这份语音文件是纯文本，可以进Git做版本控制，可以diff看修改历史，可以复制给团队其他人直接复用。这种“形式化控制”的感觉，是任何聊天UI都提供不了的。

第二个发现跟温度参数有关。标语类文案在默认温度下产出的东西是死的——类似“学得更聪明”这种谁都能写的废话。我试着把--temperature调到1.2，结果冒出了几条可以直接放进候选名单的句子；再往上跳到1.8，模型就开始写一些跟产品没什么关系的奇怪比喻了。而新闻稿类的文案恰好相反，在--temperature 0.3的设置下，连续三次运行产出的结构几乎一模一样。这种精细度在绝大多数聊天界面里根本碰不了，要么是全局固定温度，要么藏在三层菜单后面没人会去调。命令行里加一个flag就解决了。

第三个发现是关于按风险拆分模型的。SEO这类批量填充的工作，我直接丢给了最经济的版本——--model qwen-turbo --max-tokens 1500，跑一篇800词文章成本几乎可以忽略不计，几分钱都不到。而面向公众的文案，比如标语、发布线程，还是留在默认的旗舰模型上跑。一个命令行参数切换，成本差出一个数量级。对于个人开发者或者小团队来说，这种成本的颗粒度控制意味着你可以把预算集中在真正影响转化率的那几段文案上，其他地方该省就省。

还有一个附带的好处：封面图也能在终端里顺手生成。一行bl image generate命令，描述词里放好场景和风格，模型选qwen-image-2.0-pro，比例设成3:4，一次出两张，不用跳到任何设计工具，也不用面对空白画布的那种决策瘫痪。从文案到配图，全链路留在命令行里，这在以前是很难想象的。

当然，这套工作流也不是没有短板。最明显的问题是，brief.md本身的质量决定了所有输出结果的上限。如果你的产品简介写得含糊不清，那五个平台的文案只不过是用五种不同的语气重复同一团浆糊。另外，语音文件目前对格式的约束力还比较粗糙——你可以规定禁用词，可以规定推文条数，但很难精确控制“第三段必须是转折句”这种级别的结构规则，除非你在系统提示里写得非常繁复，而这又会吃掉宝贵的token预算。还有一些边缘情况，比如Reddit的语音文件虽然要求“零市场营销腔”，但模型偶尔还是会在一段纯文本里偷偷塞进一个CTA，需要人工再扫一眼。

但总的来说，对比我之前在聊天窗口里反复粘贴、解释、纠错的流程，这套“一份简介、一次循环、全平台覆盖”的终端工作流已经足够把发布周的痛苦指数降到一个可以接受的水平了。核心的转变其实不是工具换了，而是把“交互模式”改成了“形式化配置模式”。你用文件定义规则，规则就永远在那儿，不会被会话清空，不会因为关了窗口就失忆，也不会因为你的提示词焦虑症反复修改而产生无数个不可复现的版本。文件就是最诚实的配置中心。

对于小团队和独立开发者来说，这套思路可以平移得很彻底。把每个成员对平台语言的手感和判断，沉淀成一份可执行的.txt文件，这件事本身就相当于在团队里建了一个轻量级的品牌语言手册——而且这份手册还能自动执行。当新成员加入时，clone一份仓库，跑一条命令，就能立刻获得符合团队标准的全平台文案种子，而不是坐在电脑前对着一个空白的Product Hunt编辑器发愣。

至于接下来要不要把语音文件进化成支持条件分支的更复杂模板，或者在loop里加入一个自动对比不同温度产物的diff步骤，那大概是下个版本的事了。目前这个版本足够简洁，足够好用，也足够让我彻底告别那个开了五个聊天标签、来回粘贴产品简介的可怕下午。