magosox
让品牌的社交内容自动化——选题、写文案、生成图片、发布
magosox 为一个品牌生产社交内容，并自己把它发出去。在给它设定好的时间点，它决定讲什么、写好文案、据此生成图片并发布：没有人需要打开任何东西。难的不是发布，而是在发布的同时保住一种能被认出来的声音。一条听上去就像是机器写的内容，价值等于零——这个项目的力气，正是花在这里。
## 品牌语境是数据，不是代码
让一条内容能被认出来的东西——那种声音、对读者说话的方式、品牌知道什么以及刻意不说什么，还有选题库——在 magosox 里存放在产品内部，而不是源代码里。它在界面上书写和修改，改动从下一条内容起生效，不需要发版。其余的一切都由此而来：接入一个新品牌属于配置而不是开发，而每个品牌各自带着自己的语境，互不干扰。
## 组织文字，而不是拆散文字
一条内容的质量不是来自某种架构，而是来自大约一千个写得好的字。这个区分看似显而易见，可这类系统几乎都做错了：把那些字拆进一个个字段——语气、正式度、使用表情：false——再重新拼回去，得到的指令反而比原来的更差。在 magosox 里，声音规则是一行行原样保存的文本，连换行和缩进都保留。系统只负责知道什么时候注入、按什么顺序、放在哪个小标题之下：它组织文字的范围、分量和位置，而从不组织文字本身。为了让改动引擎时不会悄悄改变声音，还有一项回归测试会从这些行里重新编译提示词，并与一份冻结的参照逐字符比对。
## 用台账，而不是用查询
为了让内容流不重复，系统必须知道最近讲过什么。直觉的做法是从已发布的内容里推导，但这行不通。窗口统计的是条数而不是天数，而同一天可能发出不止一条：任何按时间的排序都排不出先后。此外还有按需临时撰写的内容，它们不指向选题库里的任何条目，因此永远做不成外键。于是防重复被做成一本只增不减的台账，带有自己的一套序号。已排期的内容会立刻占用它的选题，如果发布失败再把选题还回去——这个生命周期，用内容自身的状态是无法如实表达的。
## 声明的上限与执行的上限
每一处文字都有两个不同的数字：对模型声明的那个，和校验真正执行的那个。比如标题可以声明成 55 个字符，却要到 65 才被拒绝，而纠正提示里仍然写 55。这大约 18% 的余量，正是让重试率接近于零的原因，而它的分量比听上去更重：第二次尝试写出来的文案，平均要比第一次差。把两个数字并成一个字段，结果要么是纠正循环被撑爆，要么是每个标题都胖上 18%。
## 从一个想法到一条已发布的内容
整条流水线无人值守，按日历设定的时间运行，每一步都留下可以回看的痕迹：
## 界面
后台是真正修改品牌语境的地方，不需要任何人去碰代码仓库。登录不用密码，靠邮件里的验证码；没有注册入口，账号从终端创建。
## 技术栈
配置的处理方式值得一提：在数据库还不存在的时候，环境变量是唯一能配置服务的途径，所以它们保留了下来。但从第一次启动之后，存进数据库的值优先，而界面会显示当前是哪一个在起作用。凌晨三点换一把模型密钥，不该还要登服务器。
magosox 自 2026 年 8 月 1 日起投入生产，按设定的节奏无人值守地发布。上线之前，过往已经发布过的内容历史也一并导入，好让防重复从第一天起就有记忆，而不必用几周时间慢慢积累。