刚开始用 Codex 的时候,我对 medium 这个默认档位有点误会。
它看起来像一个很稳的中间值:不至于太慢,也不至于太省。网上又经常有人说 GPT-5.4 编码很强,于是很容易顺手把两件事合在一起理解:既然模型强,那默认 medium 应该就够了。
用了一段时间以后,我的结论变了。小修小补可以继续 medium,但只要任务开始跨文件、需求有歧义、需要先读代码再判断,我更愿意直接开 high。xhigh 不当日常默认,留给 high 已经证明啃不动的任务。
刚开始用 Codex 的时候,我对 medium 这个默认档位有点误会。
它看起来像一个很稳的中间值:不至于太慢,也不至于太省。网上又经常有人说 GPT-5.4 编码很强,于是很容易顺手把两件事合在一起理解:既然模型强,那默认 medium 应该就够了。
用了一段时间以后,我的结论变了。小修小补可以继续 medium,但只要任务开始跨文件、需求有歧义、需要先读代码再判断,我更愿意直接开 high。xhigh 不当日常默认,留给 high 已经证明啃不动的任务。
翻了一圈现在仓库里的配置,我反而更确定一件事:这套东西最后拼的不是单个模型有多强,而是每一层到底该让谁来承担成本。
最明显的一个信号就是,当前生效的 published.runtime.json 还是 2026 年 4 月 2 日生成的 minimax-m2,但 2026 年 4 月 3 日 16:38 的 5f17088 已经把 blog-style-suite 的默认 provider 切到了本地 LM Studio 里的 gemma-4-26b-a4b。这看起来像前后不一致,其实不是,它恰好说明了这条流水线开始有了分工。
如果 token 足够,最省脑子的办法其实很粗暴:把历史文章直接塞给模型,让它自己学。
问题在于,这种办法只适合偶尔来一篇,不适合反复写。你要是真把博客写作当成长期工作流来做,生吃历史文章这条路,很快就会从“简单直接”变成“又贵又乱”。
去年写了不少 AI 稿子,那会最土的流程就是,自己先整理个大纲或者问题清单,让大模型把正文吐出来,然后再把内容复制到本地 md 文档里,补 frontmatter、标签、分类、标题,最后再发布。
这套流程不是不能用,是很烦。真正费时间的地方,不是正文,而是正文外面那一圈重复劳动。尤其是最近 Codex 用多了以后,这种别扭感更强了。它能读仓库、能改文件、能补资料、还能直接把文章写进目录里,我要是还手工复制来复制去,反而像是人把工具的腿绑住了。
春节期间几家国内 AI 厂商撒钱拉新,动作一点都不陌生。
红包、补贴、免单、强入口,先把用户带进 App,先把 DAU 做起来,先让市场看到“大家都在用”。这是上一个互联网周期最熟的一套打法。
它不是没用。问题在于,AI 这门生意不能只按注意力经济算。人进来了,聊了几句,生成了几张图,这些都只是开始。真正决定用户会不会留下、会不会付费的,是它到底替用户做成了什么。
这几天看 AI 编程,前脚大家还在聊 MCP,后脚又开始聊 Skill。这两个词放在一起,最容易让人误会成又多了一个协议,或者又多了一种高级提示词。
真正的区别其实更朴素:MCP 解决的是 agent 怎么接上外部工具和数据,Skill 解决的是接上以后按什么顺序把活干稳。一个偏连接,一个偏流程。
所以 Skill 最有价值的场景,不是模型完全不会做,而是模型每次做法不稳。它像一份工种手册,把触发条件、步骤、边界、参考资料和必要脚本放在一起,让 agent 少靠临场发挥。
最近把一些边角活往 MiniMax 和本地模型上迁,感受反而比一开始更清楚:很多任务不是非要最强模型才能做,而是不能把所有模型都放到同一个工位上比。
以前我容易问“这个模型强不强”。现在更愿意先问两件事:这件活错了以后代价有多大,重复跑一百次以后成本有多高。答案一变,低成本模型、本地模型和旗舰模型的位置也就变了。
复杂编码、长链路推理、模糊需求拆解,还是该给更强的模型;数据清洗、文档改写、资料初筛、固定格式转换,反而更适合交给便宜模型和本地模型。它们不一定聪明到能总包项目,但很适合把那些不值得人反复动手的活接住。
最近回头翻了下博客里这两年和 AI 相关的文章,发现内容已经不是最开始那种“某个模型好不好用”的简单体验了,而是逐步形成了一条比较清晰的主线:AI 如何真正进入我的开发工作流,以及它带来了什么效率、代价和新的约束。