https://ttf248.life/tags/workflow/ Recent content in 工作流 on 向叔记事簿 Hugo -- gohugo.io zh-cn https://ttf248.life/p/how-blog-style-suite-split-style-and-token-cost/ Fri, 03 Apr 2026 21:02:02 +0800 https://ttf248.life/p/how-blog-style-suite-split-style-and-token-cost/ <p>如果 token 足够，最省脑子的办法其实很粗暴：把历史文章直接塞给模型，让它自己学。</p> <p>问题在于，这种办法只适合偶尔来一篇，不适合反复写。你要是真把博客写作当成长期工作流来做，生吃历史文章这条路，很快就会从“简单直接”变成“又贵又乱”。</p> <p>这组文章讲到这里，主线已经变了。上一篇 <a class="link" href="https://ttf248.life/p/why-blog-writer-had-to-exist/" >AI 写博客这件事，后来还是得做成工程（一）：blog-writer 为什么会长出来</a> 讲的是消费侧的自动化；这一篇开始讲生产侧，也就是风格数据怎么生成、怎么压缩、怎么别把 token 白白烧掉；下一篇会接着收在 <a class="link" href="https://ttf248.life/p/how-i-split-local-online-and-minimax-models/" >AI 写博客这件事，后来还是得做成工程（三）：本地模型、在线模型和 Minimax 最后怎么分工</a>。</p> <h2 id="一开始最自然的想法就是直接喂历史文章">一开始最自然的想法，就是直接喂历史文章 </h2><p>这条路真的太自然了。</p> <p>你既然想让模型学会你的写法，那最直观的办法当然就是把旧文章喂给它。最好把历史博客里写得最像自己的那些都塞进去，让它自己总结。</p> <p>单看一次任务，这么干没什么毛病。</p> <p>甚至很多时候效果还不错。上下文够长，模型够强，历史文章够多，风格确实能被带出来。</p> <p>但问题不是“这一篇能不能写成”，问题是“下一篇、下下篇，还要不要再来一遍”。</p> <p>每次都重新喂一批旧文章，会带来几个很现实的副作用：</p> <ul> <li>同一批材料反复占上下文</li> <li>token 开销和写稿次数近乎线性增长</li> <li>模型看到的噪音越来越多，真正有用的信号反而被稀释</li> <li>写稿动作和风格维护动作彻底绑死，谁都轻不下来</li> </ul> <p>也就是说，token 富裕的时候，生吃当然能吃。但工程上不能老这么吃。</p> <h2 id="这也是为什么数据模块和数据生成模块必须拆开">这也是为什么数据模块和数据生成模块必须拆开 </h2><p>我后来把这件事想明白，核心就一句话：消费侧和生产侧得分开。</p> <p><code>blog-writer</code> 负责的是消费侧。它只管读一份已经发布好的 runtime，然后把文章按固定契约写出来。</p> <p>而风格数据的扫描、筛选、评分、压缩、provider 对比，这些都应该放到另一条生产侧流水线里。也就是后来长出来的 <code>blog-style-suite</code>。</p> <p>从 git 记录看，这个转折很清楚。</p> <p>2026 年 4 月 1 日 21:47 的 <code>84a06b5</code>，已经明确把原来的 <code>blog-style-maintainer</code> skill 换成了仓库级 CLI 工具。这个动作很说明问题，因为一旦你有了 <code>scan/build/rebuild</code>、有了输出目录、有了恢复机制，事情就已经不像一个 skill 了，更像一个正常的 Python 项目。</p> <p>再到 2026 年 4 月 1 日 23:05 的 <code>9e92b8e</code>，<code>blog-style-suite</code> 继续被拆成 <code>scanner.py</code>、<code>builder.py</code>、<code>compressor.py</code> 这些模块。到这一步，思路其实已经非常工程化了：</p> <ul> <li><code>scanner.py</code> 负责把文章从磁盘里扫出来，提取结构化特征</li> <li><code>builder.py</code> 负责评分、精选、缓存、运行时装配</li> <li><code>compressor.py</code> 负责该让模型参与的那几步压缩</li> </ul> <p>这和单纯写一段超级 prompt，已经是两种完全不同的思路了。</p> <h2 id="省-token不靠玄学靠的是预处理和批量化">省 token，不靠玄学，靠的是预处理和批量化 </h2><p>这套工程真正最值钱的地方，我觉得是 2026 年 4 月 2 日 19:41 的 <code>bc4b950</code>。</p> <p>那次提交把话说得很直白，AI 调用从大约 <code>2000</code> 次，直接降到了每个 provider 最多 <code>5</code> 次。</p> <p>怎么做到的？</p> <p>不是靠“把 prompt 改得更聪明”，而是靠把该预处理的东西提前做掉。</p> <p>现在 <code>blog-style-suite</code> 的流程，已经很清楚了：</p> <ol> <li><code>scan</code> 阶段纯启发式，0 次 AI 调用</li> <li><code>build</code> 阶段先做启发式评分，还是 0 次 AI 调用</li> <li>再按 <code>technical / finance / essay / tooling</code> 四个 lane 各做 1 次批量精选和打标签</li> <li>最后再做 1 次作者风格压缩</li> </ol> <p>这样算下来，冷启动最多也就是 5 次调用。</p> <p>更关键的是，这 5 次不是分散在每一篇文章上，而是集中在已经被预处理过的、高价值的摘要材料上。</p> <p>这就是预处理真正省 token 的地方。不是少省几个字，而是从“按文章逐篇调用”改成“按阶段集中调用”。</p> <p>再往后，缓存也补上了。</p> <p><code>builder.py</code> 里有 lane 的 batch fingerprint，有 provider checkpoint 恢复，有 <code>review_pool_per_lane = 12</code> 这种为了本地模型上下文做的收缩。你要改一小部分数据，不会整条流水线重跑。</p> <p>这类设计看起来都不炫，但每一个都很实用。因为它们解决的都是“别让同一批 token 反复烧第二次”。</p> <h2 id="现在这套数据结构本质上就是在压缩真正有用的信号">现在这套数据结构，本质上就是在压缩真正有用的信号 </h2><p>这一套拆完以后，数据结构也就顺了。</p> <p>我现在更愿意把它理解成三层。</p> <h3 id="第一层scanjson">第一层：<code>scan.json</code> </h3><p>这是共享原料。</p> <p>里面放的是文章路径、标题、日期、分类、标签、开头段落、closing stub、headings、screening 结果、lane 归类这些结构化信号。</p> <p>它不是给 <code>blog-writer</code> 直接吃的，它是给生产侧继续往下加工的。</p> <h3 id="第二层providersourcejson">第二层：<code>{provider}.source.json</code> </h3><p>这是 provider 级 checkpoint。</p> <p>在共享原料的基础上，多了评分结果、lane selection、fingerprint、cache status 这些中间态。也就是说，它更像“加工过程中的半成品”，重点是可恢复、可复用、可中断继续。</p> <h3 id="第三层providerruntimejson-和-publishedruntimejson">第三层：<code>{provider}.runtime.json</code> 和 <code>published.runtime.json</code> </h3><p>这才是消费侧真正关心的成品。</p> <p>里面保留的是：</p> <ul> <li><code>author_style</code></li> <li><code>lanes</code></li> <li><code>samples</code></li> <li><code>writer_guide</code></li> </ul> <p>也就是把原来一大堆历史文章，压成一份可直接消费的运行时风格资产。</p> <p>尤其是 <code>published.runtime.json</code> 这个发布位很关键。<code>blog-writer</code> 只读这一份，不回头去扫 <code>content/post</code>，也不关心 suite 目录下所有 provider 的完整镜像。</p> <p>这个边界一旦立住，消费侧就轻了。写稿模型看到的，不再是一堆原始旧文，而是一份已经预处理好的高密度信号。</p> <h2 id="不是所有事情都该让模型做">不是所有事情都该让模型做 </h2><p>我现在越来越觉得，这套工程里最正确的一个判断，其实不是“多接几个模型”，而是“别把不该让模型做的事也扔给模型”。</p> <p>像这些事情，就很适合本地规则先做掉：</p> <ul> <li>frontmatter 解析</li> <li>开头段落提取</li> <li>headings 抽取</li> <li>本人/转载/模型署名判断</li> <li>blockquote 比例检测</li> <li><code>&lt;!--more--&gt;</code>、嵌入 prompt、正文长度这类硬规则筛掉</li> </ul> <p>这些动作让模型来做，不是不行，是浪费。</p> <p>模型更适合做的，是那些带模糊性、带取舍的部分。比如一个 lane 里哪几篇更能代表当前声音，或者从高分文章里提炼作者风格标签。</p> <p>所以 <code>blog-style-suite</code> 真正值钱的，不只是“省 token”，而是它把人、规则、模型三者各自该干的活重新分了一次。</p> <h2 id="预处理不是为了省一点-token是为了让写稿这件事可持续">预处理不是为了省一点 token，是为了让写稿这件事可持续 </h2><p>第二篇的结论，我想压得更直接一点。</p> <p>token 富裕的时候，生吃历史文章当然没问题。甚至你真只写一两篇，可能还更省脑子。</p> <p>但只要你想把这件事做成长期工作流，预处理就不是可选项了。因为你不做预处理，写稿模型每次都得重复看旧材料，风格维护和文章生成也永远搅在一起。</p> <p><code>blog-style-suite</code> 的意义，就是把这一团东西拆开。</p> <p>不是为了显得系统，不是为了多一个项目名，而是为了让 <code>blog-writer</code> 保持轻，保持稳，保持“只干写稿这一个动作”。</p> <p>到了这里，下一步的问题也就顺理成章了。</p> <p>既然生产侧已经独立出来了，那到底该让什么模型来承担这部分成本？本地模型、在线模型、<code>Minimax</code>，分别该站在哪个工位上？这件事，留到下一篇 <a class="link" href="https://ttf248.life/p/how-i-split-local-online-and-minimax-models/" >AI 写博客这件事，后来还是得做成工程（三）：本地模型、在线模型和 Minimax 最后怎么分工</a>。</p> <h2 id="参考资料">参考资料 </h2><ul> <li>仓库提交：<a class="link" href="https://github.com/ttf248/notebook/commit/84a06b5dc743f2e9bc6e788d53496a1261bc63ae" target="_blank" rel="noopener" ><code>84a06b5dc743f2e9bc6e788d53496a1261bc63ae</code></a></li> <li>仓库提交：<a class="link" href="https://github.com/ttf248/notebook/commit/9e92b8e6a15d03e6392aff7f3b2dcb0992fe5043" target="_blank" rel="noopener" ><code>9e92b8e6a15d03e6392aff7f3b2dcb0992fe5043</code></a></li> <li>仓库提交：<a class="link" href="https://github.com/ttf248/notebook/commit/bc4b950cbb13e37d1fdb16a9d23325cfefa6f90e" target="_blank" rel="noopener" ><code>bc4b950cbb13e37d1fdb16a9d23325cfefa6f90e</code></a></li> <li>仓库文件：<code>scripts/blog-style-suite/README.md</code></li> <li>仓库文件：<code>scripts/blog-style-suite/style_pipeline/scanner.py</code></li> <li>仓库文件：<code>scripts/blog-style-suite/style_pipeline/builder.py</code></li> <li>仓库文件：<code>scripts/blog-style-suite/style_pipeline/compressor.py</code></li> <li>生效运行时：<code>.agents/data/blog-writing/published.runtime.json</code></li> </ul> <h2 id="写作附记">写作附记 </h2><h3 id="原始提示词">原始提示词 </h3><pre><code class="language-text">$blog-writer 本次的内容比较多，拆分成系列文章：去年就有很多稿子是通过大模型写的，那会是自己写个大纲或者问题清单，然后AI出稿子，复制内容到本地 md 文档，填写头信息，标签信息、发布文章；近期 codex 用了很多，发现 codex 里面的联网搜索能力很强，那我是不是能写个 skill，将这些事情自动化，此时诞生了 skill blog-writer 的第一稿，我还想着让 AI 学习我以前文章的风格，这就导致 blog-writer 运行的时候，很费 token，后续我针对 blog-writer 进行了多个版本的优化，拆分了 数据模块，数据生成的模块，原本数据生成的模块还是独立的 skill，写着写着，我就发现，更适合做成 Python 项目，此时就有了 blog-style-suite，然后我又发现，训练风格数据，也是比较费 token，我就想着用本地的大模型，对接了本地的大模型，我又想到了对比下本地大模型和在线版本的区别，又对接了 minimax；blog-style-suite 和 blog-writer 的演化历史可以分析的 git 提价记录。顺带基于本地 blog-writer、blog-style-suite 的代码，可以讲讲里面的设计思路，是如何做到了节约 token，数据结构是如何设计的，核心的设计思路。Token 富裕完全能生吃历史文章，预处理能节约很多 token </code></pre> <h3 id="写作思路摘要">写作思路摘要 </h3><ul> <li>这一篇把重点从写稿动作切到数据工程，核心回答“为什么必须拆模块”。</li> <li>开头直接承认“生吃历史文章能用”，这样后面的拆分理由才更有说服力。</li> <li>重点展开了 <code>scan.json</code>、<code>source.json</code>、<code>runtime.json</code> 这三层结构，避免空讲架构。</li> <li><code>bc4b950</code> 被放在中间当转折点，因为“从约 2000 次到 5 次”最能说明预处理的价值。</li> <li>结尾把消费侧和生产侧重新分开，为第三篇的模型分工做铺垫。</li> </ul> https://ttf248.life/p/why-blog-writer-had-to-exist/ Fri, 03 Apr 2026 20:58:02 +0800 https://ttf248.life/p/why-blog-writer-had-to-exist/ <p>去年写了不少 AI 稿子，那会最土的流程就是，自己先整理个大纲或者问题清单，让大模型把正文吐出来，然后再把内容复制到本地 <code>md</code> 文档里，补 frontmatter、标签、分类、标题，最后再发布。</p> <p>这套流程不是不能用，是很烦。真正费时间的地方，不是正文，而是正文外面那一圈重复劳动。尤其是最近 <code>Codex</code> 用多了以后，这种别扭感更强了。它能读仓库、能改文件、能补资料、还能直接把文章写进目录里，我要是还手工复制来复制去，反而像是人把工具的腿绑住了。</p> <p>这组文章其实就想讲一件事，AI 写博客到了后面，不能再只靠一段 prompt 硬顶。当前这一篇先讲 <code>blog-writer</code> 为什么会长出来；下一篇会接着写 <a class="link" href="https://ttf248.life/p/how-blog-style-suite-split-style-and-token-cost/" >AI 写博客这件事，后来还是得做成工程（二）：blog-style-suite 怎么把风格学习和 token 成本拆开</a>；最后一篇收在 <a class="link" href="https://ttf248.life/p/how-i-split-local-online-and-minimax-models/" >AI 写博客这件事，后来还是得做成工程（三）：本地模型、在线模型和 Minimax 最后怎么分工</a>。</p> <h2 id="真正烦人的不是写稿是那一串机械动作">真正烦人的，不是写稿，是那一串机械动作 </h2><p>早期那套流程，说穿了很像外包流水线。</p> <p>我自己先把问题列清楚，或者先搭个大纲。模型负责把正文铺出来。然后人再回来补齐剩下的发布动作。</p> <ul> <li>复制到本地 <code>md</code></li> <li>补 <code>title</code>、<code>date</code>、<code>slug</code></li> <li>填标签和分类</li> <li>补 <code>&lt;!--more--&gt;</code></li> <li>整理参考资料</li> <li>再决定落到哪个目录</li> </ul> <p>这一串活，单看每一步都不难，连起来就很烦。烦的不是技术难度，烦的是它们都很机械，但又不能不做。</p> <p>这也是为什么我后来越来越觉得，<a class="link" href="https://ttf248.life/p/command-line-ai-coding-interaction/" >基于命令行的AI编码交互</a> 这类变化，不只是“换了个入口”。当 AI 已经能直接在仓库里读写文件的时候，博客写作如果还停在“复制正文到本地文档”这一层，整个工作流其实已经落后了。</p> <h2 id="blog-writer-第一层价值不是文风是把契约写死">blog-writer 第一层价值，不是文风，是把契约写死 </h2><p><code>blog-writer</code> 最早的那个节点，是 2026 年 4 月 1 日 17:00 的 <code>991536a</code>。从 git 提交记录看，这一版已经把 <code>SKILL.md</code>、<code>write_post.py</code> 和一套最初的风格材料一起放进来了。</p> <p>但我后来回头看，这一稿最值钱的地方，不是“AI 学会了我的文风”，而是先把写稿契约写死了。</p> <p>什么叫契约写死？</p> <ul> <li>输入里至少要有大纲和事实锚点</li> <li>输出必须是完整 Markdown，不是半成品</li> <li>frontmatter 不能再靠人补</li> <li>文章不能只停在聊天窗口里，得直接落到 <code>content/post</code></li> </ul> <p>这件事很重要，因为 prompt 本身不稳定。你今天说一句“帮我像以前那样写”，它可能理解成语气像一点；明天你再说一遍，它可能只学到表面句式。可一旦写成 <code>Skill</code>，规则就从“临场发挥”变成“固定工序”了。</p> <p>后面的几个节点，其实都在继续补这个契约。</p> <p>2026 年 4 月 2 日 22:54 的 <code>8eb735a</code>，把作者字段、写作附记、原始提示词这些东西都固定下来了。到这一步，博客成稿已经不是“正文写完就算完”，而是连元信息、可追溯性、公开附记都一起标准化了。</p> <p>所以 <code>blog-writer</code> 的第一层价值，从来不是让模型显得更会写，而是让写稿这件事终于有了可重复执行的边界。</p> <h2 id="系列模式其实也是写作契约往前走了一步">系列模式，其实也是写作契约往前走了一步 </h2><p>单篇写稳了以后，下一个问题很快就冒出来了。</p> <p>有些题目根本不适合挤在一篇里。你如果硬塞，最后往往会变成一篇信息很多、主线很散、每个点都讲不透的长文。</p> <p>这也是为什么 2026 年 4 月 2 日 23:55 的 <code>1a5604e</code> 很关键。那次直接把系列模式和 <code>write_post_series.py</code> 一起补进来了，文章之间用 <code>relref</code> 串起来，批量写入时再统一替换。</p> <p>这看起来像是个写文件脚本的小升级，实际上不是。</p> <p>它说明一件事：写作工程化已经不再只考虑“这一篇怎么生成”，而是开始考虑“这一组内容怎么稳定落盘、怎么保证顺序、怎么在站点里互相跳转”。</p> <p>第二天 2026 年 4 月 3 日 09:29 的 <code>04dccb9</code> 继续把这件事往前推了一步。系列文章时间戳按分钟递增，不再共用一个时间。这个改动很小，但很有工程味，因为它解决的是 Hugo 列表页、上一篇下一篇、系列顺序这些真实问题。</p> <p>说白了，系列模式不是为了显得高级，而是为了让“多篇一起发”这件事别再靠手工兜底。</p> <h2 id="但只靠一个-skill后面还是会撞到-token-墙">但只靠一个 skill，后面还是会撞到 token 墙 </h2><p>问题也就出在这里。</p> <p>一旦开始认真折腾文风学习，<code>blog-writer</code> 的上下文会很快变胖。你不但要让它会写，还想让它像你以前那样写。那最自然的办法，就是把历史文章也一股脑塞进去。</p> <p>这么干，单次当然能跑。</p> <p>但只要你不是偶尔写一篇，而是想把它变成长期工作流，问题马上就来了：</p> <ul> <li>token 花销高</li> <li>每次都重复喂同一批旧文章</li> <li>模型注意力被旧材料稀释</li> <li>写稿和风格维护缠在一起，谁都不轻</li> </ul> <p>也就是从这里开始，我慢慢意识到，<code>blog-writer</code> 更适合当消费侧，而不是把所有事情都塞给它做。</p> <p>写稿这个动作，应该尽量轻，尽量直接，尽量只读生效版本。至于风格数据怎么生成、怎么筛、怎么压缩，那是另一条生产侧流水线的事。这个判断，最后才把我推到了下一步，也就是 <a class="link" href="https://ttf248.life/p/how-blog-style-suite-split-style-and-token-cost/" >AI 写博客这件事，后来还是得做成工程（二）：blog-style-suite 怎么把风格学习和 token 成本拆开</a>。</p> <h2 id="先把流程做稳后面才有资格谈风格和模型">先把流程做稳，后面才有资格谈风格和模型 </h2><p>现在回头看，<code>blog-writer</code> 长出来，不是因为我忽然很想做一个博客写作助手。</p> <p>更像是因为原来那套流程已经开始不配合新的工作方式了。</p> <p><code>Codex</code> 这种工具一旦能联网补资料、能在仓库里读写、能直接调用脚本，写博客这件事就不该再停在“复制正文到本地文档”那一步。你不把这部分自动化，它反而会变成整条链路里最笨的一环。</p> <p>所以第一篇的结论我就放这。</p> <p><code>blog-writer</code> 先解决的，不是文风，而是发布动作的重复劳动。没有这层契约，后面谈 token、谈数据结构、谈本地模型，其实都站不住。</p> <h2 id="参考资料">参考资料 </h2><ul> <li>仓库提交：<a class="link" href="https://github.com/ttf248/notebook/commit/991536a237d04aba7c44dec501b3d98c644040c8" target="_blank" rel="noopener" ><code>991536a237d04aba7c44dec501b3d98c644040c8</code></a></li> <li>仓库提交：<a class="link" href="https://github.com/ttf248/notebook/commit/8eb735aa8448c97deb2af1ea46b86772008fa9e3" target="_blank" rel="noopener" ><code>8eb735aa8448c97deb2af1ea46b86772008fa9e3</code></a></li> <li>仓库提交：<a class="link" href="https://github.com/ttf248/notebook/commit/1a5604e7e6ce0a13f260fcbb8c2c1d964cdd0892" target="_blank" rel="noopener" ><code>1a5604e7e6ce0a13f260fcbb8c2c1d964cdd0892</code></a></li> <li>仓库提交：<a class="link" href="https://github.com/ttf248/notebook/commit/04dccb98c55a6ea3b81408012b33a6219cf8ab77" target="_blank" rel="noopener" ><code>04dccb98c55a6ea3b81408012b33a6219cf8ab77</code></a></li> <li>仓库文件：<code>.agents/skills/blog-writer/SKILL.md</code></li> <li>仓库文件：<code>.agents/skills/blog-writer/scripts/write_post.py</code></li> <li>仓库文件：<code>.agents/skills/blog-writer/scripts/write_post_series.py</code></li> </ul> <h2 id="写作附记">写作附记 </h2><h3 id="原始提示词">原始提示词 </h3><pre><code class="language-text">$blog-writer 本次的内容比较多，拆分成系列文章：去年就有很多稿子是通过大模型写的，那会是自己写个大纲或者问题清单，然后AI出稿子，复制内容到本地 md 文档，填写头信息，标签信息、发布文章；近期 codex 用了很多，发现 codex 里面的联网搜索能力很强，那我是不是能写个 skill，将这些事情自动化，此时诞生了 skill blog-writer 的第一稿，我还想着让 AI 学习我以前文章的风格，这就导致 blog-writer 运行的时候，很费 token，后续我针对 blog-writer 进行了多个版本的优化，拆分了 数据模块，数据生成的模块，原本数据生成的模块还是独立的 skill，写着写着，我就发现，更适合做成 Python 项目，此时就有了 blog-style-suite，然后我又发现，训练风格数据，也是比较费 token，我就想着用本地的大模型，对接了本地的大模型，我又想到了对比下本地大模型和在线版本的区别，又对接了 minimax；blog-style-suite 和 blog-writer 的演化历史可以分析的 git 提价记录。顺带基于本地 blog-writer、blog-style-suite 的代码，可以讲讲里面的设计思路，是如何做到了节约 token，数据结构是如何设计的，核心的设计思路。Token 富裕完全能生吃历史文章，预处理能节约很多 token </code></pre> <h3 id="写作思路摘要">写作思路摘要 </h3><ul> <li>第一篇先收在工作流触发点，不急着展开 token 和模型分工，避免三篇一起抢主线。</li> <li>重点保留了“正文不难，麻烦的是发布前后那串机械动作”这个判断。</li> <li>通过 <code>991536a</code>、<code>8eb735a</code>、<code>1a5604e</code>、<code>04dccb9</code> 这些节点，把“流程契约化”落到真实 git 演化上。</li> <li>系列模式放在这一篇讲，是为了说明博客写作已经从单篇生成走到了整组落盘。</li> <li>结尾故意把问题引到 token 墙，为第二篇的数据工程和预处理做铺垫。</li> </ul> https://ttf248.life/p/next-8-ai-topics-after-reviewing-two-years-of-posts/ Mon, 30 Mar 2026 22:20:00 +0800 https://ttf248.life/p/next-8-ai-topics-after-reviewing-two-years-of-posts/ <p>最近回头翻了下博客里这两年和 AI 相关的文章，发现内容已经不是最开始那种“某个模型好不好用”的简单体验了，而是逐步形成了一条比较清晰的主线：<strong>AI 如何真正进入我的开发工作流，以及它带来了什么效率、代价和新的约束。</strong></p> <p>这里说的“近两年”，按当前时间往前看，大致是从 <code>2024-03-30</code> 到 <code>2026-03-30</code>。实际翻下来，一个很明显的现象是：<code>2024</code> 年几乎没有真正意义上的 AI 主题文章，密集产出主要从 <code>2025-01</code> 才开始。</p> <p>这件事本身就很有意思。它说明对我来说，AI 并不是一开始就进入了稳定使用期，而是先在工作和写作中慢慢渗透，等到真正碰到合适的工具和任务形态以后，才开始形成持续记录。</p> <h2 id="这两年的-ai-文章大致可以分成三个阶段">这两年的 AI 文章，大致可以分成三个阶段 </h2><h3 id="第一阶段工具尝鲜先看能不能用">第一阶段：工具尝鲜，先看能不能用 </h3><p>这一阶段的代表文章有：</p> <ul> <li>《Cursor AI 编程 IDE 试用》</li> <li>《ollama 本地部署 deepseek-R1》</li> <li>《不写代码，设计开发自选股模块》</li> <li>《AI发展两年：有点类似Docker发布前的状态》</li> </ul> <p>这个阶段的核心问题很朴素：<strong>AI 到底能不能帮我做事？</strong></p> <p>那会的关注点，更多还是工具层面：</p> <ul> <li>IDE 形态是否顺手</li> <li>本地部署是否能跑起来</li> <li>模型生成代码是否能省时间</li> <li>遇到复杂需求时，AI 会不会卡壳</li> </ul> <p>回头看，这一阶段的文章，像是在给后续的重度使用铺路。很多结论现在依然成立，比如：AI 可以明显提高基础开发效率，但复杂任务依然要靠人工拆分；本地模型可以尝鲜，但真正进入高频工作流，稳定性和速度才是关键。</p> <h3 id="第二阶段开始进入工作流但副作用也一起出现">第二阶段：开始进入工作流，但副作用也一起出现 </h3><p>这一阶段的代表文章有：</p> <ul> <li>《AI用多了，有点后遗症》</li> <li>《Claude4发布，尝试开发：hugo标签、超链接翻译助手》</li> <li>《近期大模型的一些使用经验》</li> <li>《字节AI编码新范式 SOLO》</li> </ul> <p>到了这里，AI 已经不只是“偶尔试一下的工具”，而是开始直接参与：</p> <ul> <li>博客工具链开发</li> <li>翻译缓存与批处理流程</li> <li>UI 设计与代码往返</li> <li>模型分工与场景选择</li> </ul> <p>与此同时，问题也越来越具体。</p> <p>以前的疑问是“AI 能不能写代码”，后来的疑问变成了：</p> <ul> <li>代码是写出来了，但怎么验收？</li> <li>文章是生成出来了，但有没有烟火气？</li> <li>文档是同步更新了，但我自己是否真的理解了？</li> <li>工具越来越强，但人的思考强度是不是在下降？</li> </ul> <p>这也是我觉得这批文章里最有价值的部分。相比空谈“AI 很强”，这种带有一点不适感的记录，反而更真实。</p> <h3 id="第三阶段从单工具体验走向协议流程稳定性和成本">第三阶段：从单工具体验，走向协议、流程、稳定性和成本 </h3><p>这一阶段的代表文章有：</p> <ul> <li>《基于命令行的AI编码交互》</li> <li>《从协议约束到智能释放：深度对比 MCP 与 Skill》</li> <li>《重度AI编程的一段日子》</li> <li>《低价 API 中转站的终局：三月份的大模型体验与不可能三角》</li> </ul> <p>到了这个阶段，关注点已经明显升级了。</p> <p>不再是“哪个模型回答更聪明”，而是：</p> <ul> <li>终端交互和 IDE 交互，哪种更适合持续开发</li> <li>MCP、Skill 这类能力扩展方式，到底有什么边界差异</li> <li>重度 AI 编程时，人工应该在哪些地方介入</li> <li>成本、稳定、质量之间，怎么做现实选择</li> </ul> <p>这类话题已经不再是简单的产品测评，更接近于<strong>工作流设计</strong>。这也是目前博客里 AI 主题最稳定、最有辨识度的一条线。</p> <h2 id="这批文章最大的优势不是追热点">这批文章最大的优势，不是追热点 </h2><p>回头看，博客里已有的 AI 文章，真正有辨识度的地方，不是你比别人更早写了某个模型，也不是参数、榜单、跑分写得更全，而是下面这几个点：</p> <h3 id="1-都是从真实使用场景长出来的">1. 都是从真实使用场景长出来的 </h3><p>无论是自选股模块、博客翻译工具、命令行编码，还是 API 中转站折腾记录，几乎都不是凭空凑出来的题材，而是自己在实际使用中碰到问题以后才写的。</p> <p>这种内容的好处是，不容易空洞。</p> <h3 id="2-关注的是怎么把-ai-接进流程">2. 关注的是“怎么把 AI 接进流程” </h3><p>很多 AI 文章只写模型能力，但现有这批文章更关心的是：</p> <ul> <li>如何拆任务</li> <li>如何接入项目</li> <li>如何维护文档</li> <li>如何控制上下文</li> <li>如何在不同模型之间做分工</li> </ul> <p>这类内容的生命周期通常比单纯的模型测评更长。</p> <h3 id="3-已经开始意识到副作用和成本">3. 已经开始意识到副作用和成本 </h3><p>从《AI用多了，有点后遗症》到《低价 API 中转站的终局》，其实已经形成了一条很完整的思考线：</p> <ul> <li>AI 能提效</li> <li>但会改变人的搜索和思考习惯</li> <li>便宜不等于真正省钱</li> <li>质量、稳定、划算很难同时成立</li> </ul> <p>这类判断是有个人使用沉淀的，不是单纯复述网上观点。</p> <h2 id="但也有几个明显的内容缺口">但也有几个明显的内容缺口 </h2><p>现有文章虽然已经有主线了，但如果继续往下写，我觉得还有几个缺口比较明显。</p> <h3 id="1-缺少系统性的验收方法论">1. 缺少系统性的“验收方法论” </h3><p>已经写了很多 AI 编程体验，也提到了单元测试、性能测试、文档同步，但还没有一篇文章专门把“AI 写的东西如何验收”这件事完整讲透。</p> <h3 id="2-缺少团队视角">2. 缺少团队视角 </h3><p>目前大多是个人开发和个人工作流视角。这个角度很好，但如果继续往下写，完全可以扩展到：</p> <ul> <li>多人协作时如何限制 AI 修改范围</li> <li>code review 怎么看 AI 代码</li> <li>文档、提交日志、测试记录怎么配合</li> </ul> <h3 id="3-缺少安全与权限边界的讨论">3. 缺少安全与权限边界的讨论 </h3><p>最近这波趋势已经越来越明显了，AI 不再只是聊天框，而是在接管：</p> <ul> <li>终端命令</li> <li>仓库读写</li> <li>浏览器操作</li> <li>第三方工具调用</li> </ul> <p>能力越强，权限边界就越值得写。</p> <h3 id="4-缺少长期知识库方向">4. 缺少“长期知识库”方向 </h3><p>现在文章里已经有翻译缓存、slug、标签这些基础能力，但还没系统去写：如果博客本身就是个人知识库，那么怎样把它整理成更适合 AI 消费、检索和加工的内容资产。</p> <h2 id="接下来我觉得最适合写的-8-个选题">接下来我觉得最适合写的 8 个选题 </h2><p>下面这 8 个方向，我是按“最贴合现有写作风格”和“最容易写出一手内容”来排的。</p> <h3 id="1-ai-编程的验收体系怎么建">1. AI 编程的验收体系怎么建 </h3><p>这是我最推荐优先写的一篇。</p> <p>可以重点写下面这些内容：</p> <ul> <li>哪些修改必须补单元测试</li> <li>哪些模块必须跑回归测试</li> <li>哪些重构需要性能对比</li> <li>哪些文档应该同步维护</li> <li>人工 review 时重点看什么</li> </ul> <p>这篇文章一旦写好，后面很多 AI 编程文章都可以反复链接回来。</p> <h3 id="2-mcp-真正有用的场景不是接得越多越强">2. MCP 真正有用的场景，不是接得越多越强 </h3><p>现在 MCP 已经越来越热了，但大多数讨论仍然停留在概念层面。</p> <p>更值得写的是：</p> <ul> <li>哪些工具接入后真的提升效率</li> <li>哪些只是看起来很酷，实际没必要</li> <li>本地文件、文档、issue、监控、设计稿，哪些最值得优先打通</li> <li>协议化接入和“塞一大段提示词”相比，差异到底在哪里</li> </ul> <h3 id="3-claude-codecodexgemini-cli国产-cli-模型的横向实战">3. Claude Code、Codex、Gemini CLI、国产 CLI 模型的横向实战 </h3><p>不是简单写“哪个好”，而是统一一个任务集做横评。</p> <p>比如固定比较：</p> <ul> <li>需求拆解能力</li> <li>指令遵循度</li> <li>代码修改范围控制</li> <li>测试补充能力</li> <li>文档同步能力</li> <li>成本和等待时间</li> </ul> <p>这种文章读者最容易直接拿来参考。</p> <h3 id="4-ai-编程里的上下文管理">4. AI 编程里的上下文管理 </h3><p>很多时候，并不是模型不够强，而是上下文已经脏了、长了、漂了。</p> <p>这篇可以专门写：</p> <ul> <li>什么时候该清空上下文</li> <li>什么时候应该开新线程</li> <li>什么时候应该把任务切小</li> <li>什么时候适合多 agent 并行</li> <li>什么情况下必须人工重新总结一次当前状态</li> </ul> <p>这个题目很具体，也很容易结合自己的真实案例。</p> <h3 id="5-从-ide-到终端再到多-agent-协作">5. 从 IDE 到终端，再到多 Agent 协作 </h3><p>过去一年，AI 编程交互的重心已经明显变化了。</p> <p>以前更多是 IDE 内补全、聊天、局部改代码；现在越来越多工具开始强调：</p> <ul> <li>终端交互</li> <li>仓库级理解</li> <li>多线程上下文</li> <li>并行 agent</li> <li>worktree 隔离开发</li> </ul> <p>这个选题适合把过去的 Cursor、Trae、Claude Code、Codex 这些文章串起来。</p> <h3 id="6-ai-编程的安全面正在扩大">6. AI 编程的安全面正在扩大 </h3><p>这个方向很值得写，而且现在还没怎么覆盖。</p> <p>可以从这些角度切：</p> <ul> <li>自动执行命令的风险</li> <li>第三方 MCP 服务的信任边界</li> <li>私有仓库和敏感信息泄露问题</li> <li>提示词注入和恶意上下文污染</li> <li>自动化脚本与人工确认的边界</li> </ul> <p>如果只写“AI 很能干”，文章会慢慢趋同；把安全边界写进去，内容层次会明显更高。</p> <h3 id="7-本地模型的真实位置">7. 本地模型的真实位置 </h3><p>以前更多是在问“本地模型能不能跑”，现在更值得问的是：</p> <ul> <li>它适合什么任务</li> <li>它不适合什么任务</li> <li>隐私、离线、低成本这些优势什么时候真的成立</li> <li>什么时候继续坚持本地方案，反而是在浪费时间</li> </ul> <p>这比单纯的部署教程更有后续价值。</p> <h3 id="8-博客如何整理成-ai-友好的知识资产">8. 博客如何整理成 AI 友好的知识资产 </h3><p>这个方向和现有博客体系结合得最紧。</p> <p>可以写：</p> <ul> <li>slug、标签、摘要、分类如何统一设计</li> <li>多语言内容如何减少链接漂移</li> <li>文章元数据如何帮助后续检索</li> <li>如何让历史文章更适合被 AI 检索、总结、引用</li> </ul> <p>这篇如果写出来，既是 AI 主题，又能反过来服务整个博客体系。</p> <h2 id="未来一段时间值得继续盯着的趋势">未来一段时间，值得继续盯着的趋势 </h2><p>最近行业里有几个变化，也会影响后续选题判断。</p> <p>第一，AI 编程已经越来越明显地从“补全工具”走向“agent 工作流”。像 <code>Codex</code>、<code>Claude Code</code> 这类产品，强调的已经不是单次回答，而是任务拆解、工具调用、并行处理和上下文持续维护。</p> <p>第二，MCP 这类协议化接入方式，正在从“新概念”变成基础设施。以后真正有价值的文章，不会是再解释一遍协议定义，而是写清楚：<strong>哪些接入场景真的有效，哪些只是看起来很先进。</strong></p> <p>第三，设计稿、文档、代码、命令行之间的往返正在变多。过去工具之间是割裂的，现在 AI 在尝试把这些链路接起来，这也意味着“工作流设计”会比“模型榜单”更值得长期写。</p> <p>第四，稳定性、成本和权限风险不会消失。相反，模型能力越强，这几个问题只会变得更重要。</p> <h2 id="最后的判断">最后的判断 </h2><p>如果继续写 AI，我觉得最应该坚持的一件事，不是追着每次模型发布去做测评，而是继续围绕一个更具体的问题展开：</p> <p><strong>AI 到底是怎么一步步进入真实开发与写作流程的，它在哪些地方真正提高了效率，又在哪些地方把问题重新丢回给了人。</strong></p> <p>这条线，你其实已经写出来了，只是还没有完全显形。</p> <p>接下来最合适的做法，不是把题材铺得更散，而是沿着“实战工具、流程设计、边界控制、长期知识资产”这四条支线，继续往下挖。这样写出来的东西，时间久了，反而更容易沉淀成自己的东西，而不是一批很快过时的热点记录。</p>