翻了一圈现在仓库里的配置，我反而更确定一件事：这套东西最后拼的不是单个模型有多强，而是每一层到底该让谁来承担成本。
最明显的一个信号就是，当前生效的 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 编程，前脚大家还在聊 MCP，后脚又开始聊 Skill。很多人第一次看到这个词，会本能地把它当成又一个新协议，或者又一种高级提示词。
我的判断很直接，Skill 不是来抢 MCP 位置的，它更像是给 agent 配一份工种手册。MCP 解决的是“让 agent 能连上外部世界”，Skill 解决的是“连上以后，按什么套路把活干稳”。这两者不是替代关系，更像是一前一后。
说白了，MCP 让 agent 有手有脚，Skill 让 agent 别乱来。
最近回头翻了下博客里这两年和 AI 相关的文章，发现内容已经不是最开始那种“某个模型好不好用”的简单体验了，而是逐步形成了一条比较清晰的主线：AI 如何真正进入我的开发工作流，以及它带来了什么效率、代价和新的约束。
近期在项目中，重度使用 AI 编程，应该是最近三年，AI 在工作中融合度最高的一个项目。记录的笔记不成体系，想到什么说什么。
针对某个热点函数进行性能优化，耗时的大头在内部的循环上，AI提示可用到 enumerate 和 ranges，于是查阅了一下相关资料。
以前用的产品，在进行代码开发的时候，大差不差，但是字节的SOLO，在代码开发的时候，就有了很大的不同。最开始通过邀请码参与内测，现在是提交邮箱，等待审核，审核通过后，就可以使用了。忘记什么时候进行的申请，今天打开 Trae 收到了审核通过的消息。