之前就尝试过让 ai 帮写博客, 在便签里手动加 prompt 调 llm, 还在博客上弄了个"ai 生成"标志, 结果基本全是不满意的, 基本全删, 所以就不用 ai 写了.
这次又探索下 ai 写博客的可能性.
实现过程
上次失败不是模型不行, 而是整条链路都靠手搬: 提纲写在便签里, prompt 自己拼, llm 的回复再手动贴进新便签. 除了写 prompt, 人还要负责所有的复制粘贴, 这样也能写, 但每次只能凭感觉判断好坏, 没法把流程固定下来做对比.
这次多了一个 agent, 它能自己调工具, 把 skill 和 mcp 串起来执行, 而且 token 是跟着 agent 走的, 不用再单独申请 apikey 付费. 于是流程终于变成了一个可以编排、可以反复跑、也可以被推翻的东西.
规划
之前是在我的软件 scheduleprop.yo-cwj.com 的便签里写提纲 (因为是有灵感慢慢记录的), 自己加 prompt 调 llm, 然后打开新便签放 llm 返回的内容.
现在想借用 agent 的能力来编排 skill, mcp, 也可以借用 agent 的 token, 原先自己调 token 是要付费拿 apikey 的, 流程变成了这样:
- 在软件上通过 mcp 反调 agent 执行 skill
- skill 编排先检索技术上的正确性
- 通过 rag mcp 拿到相似情况博客的段落, 作为 context 给 llm 生产博文
- agent 再通过 mcp 打开新的便签
mcp 的必要性
跑了下 skill, 发现它在调用 rag 之后还是会读取所有文章, 所以其实是参考了所有文章, 于是在 skill 里禁用了查看所有 post. 结果 token 使用没减少, 反过来让 agent 自己读所有 post, token 使用也没增加.
于是就做了测试. 在不读 mcp 的情况下, agent 读了 11 篇 post, 也确定了文风与 post 的格式, 看起来也能写. 但读的 post 没有针对性, 是 mcp 替代不了的. 它挑哪几篇全靠临时判断, 真正相似的场景反而可能漏掉; rag 的价值不是喂进去更多文章, 而是喂进去对的那几段.
反复测试了后, 决定还是留下 mcp.
skill 的必要性
在运行了不同场景后, 发现调用 skill 实际消耗了更多的 token, 因为 skill 写了太多没必要的"解释", 于是简写了 skill.
skill 是一种流程编排, 让流程更稳定, 其实就是一种"匹配 description 以后加载一段 prompt", 就是一种 prompt 模板. 模型平时只看得到所有 skill 的 name 和 description, 命中之后才把正文装进上下文, 所以它本质上是一段按需加载的 prompt, 不是什么新的运行时.
当然另外还可以硬控 workflow. 但现在 workflow 的意义在降低, 因为 llm 在增强, skill 里记录的人的实现方案可能比 llm 差, 用 skill 只是限制了 llm 的发挥.
而现在有意义的 skill 我认为是"要求+限制"型的, 也就是"根据场景触发导入一段复杂的 prompt", 作为 prompt 的剪切板.
实测
- 实测了用 skill/不用 skill, 检测文章正确性/不检测, 使用 mcp/不使用, 感觉不明显, 而且同样条件跑几次效果也是不一样的. 这几组对比都跑过, 差异小到没法归因; 同样的条件重跑一遍, 文章又不一样了. 样本太少, 单次结果说明不了什么.
- skill 里的指导没意义: 实测用不带文件夹的新 session, 会自动调用 rag mcp, 但不会用 skill. 模型自己会想到要做的事, 写进 skill 里也教不会它更多.
- skill 里的要求有意义: 在仔细思考我的提纲细节后, 我认为大多数地方是只需要修正错字和标点符号的, 而不需要扩写, 这点是需要写在 skill 里的. 不写的话, 模型会按"写博客"的默认习惯扩写一大段, 反而把提纲里原本的节奏打乱.
- mcp 有意义: 用文心一言全新 session 写了下, 这肯定用不到我的 rag mcp, 因为我实在看了太多次 ai 生成文章, 自己也有点没法评估文风了, 所以拿一个完全不会读到过去文风的来生成, 结果确实增加了很多"ai 味". 那也让我相信 rag mcp 是有意义的, 并且发现"注释"是不需要跟 ai 特别解释的, 那么就从 skill 里移除.
总结
- 文风不能机器 eval (evaluate), 是人需要参与的部分. 就是 ai 没有"眼睛"的地方, 不会 eval, 没 loss 函数的地方. 语法、通顺、结构都能判断, 但"像不像我写的"没有一个能直接优化的目标.
- 因为 llm 在进化, 所以我现在偏好不要"教 llm 做事", 而是"提要求"+"说限制". 把要实现的效果和不能碰的边界说清楚, 中间怎么做交给模型自己选.
- rag 仍然需要, 因为那么多数据走 llm 处理需要花很多 token, 不把数据告诉 llm 它也没法处理, 所以需要自己处理. 但不排除以后 llm 自己会写 rag, 只是现在我用的模型没想到写 rag. 并且 rag 的"语气"暂时也是需要人类来调教的.