<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Gemini on 魔都水滴</title>
    <link>https://blog.margrop.net/tag/gemini/</link>
    <description>Recent content in Gemini on 魔都水滴</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zh-CN</language>
    <lastBuildDate>Mon, 20 Jul 2026 09:00:00 +0800</lastBuildDate>
    <atom:link href="https://blog.margrop.net/tag/gemini/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Coding Plan 还能买到吗？2026 年主流大模型编程套餐限购、限额与避坑实测</title>
      <link>https://blog.margrop.net/post/coding-plan-market-2026/</link>
      <pubDate>Mon, 20 Jul 2026 09:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/coding-plan-market-2026/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;Coding Plan 主视觉&#34; src=&#34;https://blog.margrop.net/post-images/coding-plan-market-2026/hero.svg&#34;&gt;&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;**结论先说：**截至 &lt;strong&gt;2026 年 7 月 20 日&lt;/strong&gt;，主流 Coding Plan 并不是简单的“全部涨价”或“全部限购”。更准确的说法是：**大多数方案仍能购买，但购买入口、地区、支付方式、模型额度和高峰期并发，已经被拆成了几道不同的门槛。**其中，Google Gemini CLI 的个人服务、部分新产品的高阶档位，以及地区不支持的本地化套餐，最容易出现“看得到、买不到”或“买到了、用不满”的情况。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>国产小模型不稳定？别急着换模型，先给你的 Agent 装上 Superpowers</title>
      <link>https://blog.margrop.net/post/agent-superpowers-stable-output/</link>
      <pubDate>Thu, 07 May 2026 16:43:10 +0800</pubDate>
      <guid>https://blog.margrop.net/post/agent-superpowers-stable-output/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;很多 Agent 工作流里所谓“国产模型不稳定”，表面看是模型一会儿聪明、一会儿犯糊涂，真正落到工程现场，常常是两个问题叠在一起：一是模型本身参数规模、训练数据和工具调用稳定性确实不如顶级闭源大模型；二是 Agent 没有稳定的方法论和检查点，导致每一次任务都靠即时发挥。前者短期内不一定能解决，后者可以马上解决：给 OpenClaw、HermesAgent、Codex、Claude、Gemini、OpenCode 这类 Agent 安装一套可复用的 Skill 工作流，例如 Superpowers。&lt;/p&gt;&#xA;&lt;p&gt;Superpowers 不能把小模型“魔改”成大模型，也不能保证所有国产模型突然拥有顶级推理能力。它真正有价值的地方，是把 Agent 的行为从“靠灵感输出”拉回“按流程工作”：先澄清目标，再写设计，再拆计划，再测试，再审查，再验证。对参数较少、上下文保持能力较弱、输出波动较大的模型来说，这种外置流程约束往往比继续堆提示词更有效。&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;这篇文章想聊一个很现实的问题：当我们把 OpenClaw、HermesAgent、Codex、Claude、Gemini、OpenCode 乃至更多 Agent 放进日常工作流之后，为什么某些模型看起来特别不稳定？又为什么我会建议先安装 Superpowers 这样的 Skill，而不是第一反应就去换模型、加提示词、调温度或者把系统提示写成一篇论文。&lt;/p&gt;&#xA;&lt;p&gt;为了避免泄露任何隐私信息，本文所有环境、路径、主机、账号、项目名都使用通用示例，不包含真实内网地址、密钥、业务系统名称或个人配置。文中的命令也以官方公开文档和通用安装方式为准，实际使用前请结合你自己的 Agent 版本确认。&lt;/p&gt;</description>
    </item>
    <item>
      <title>如何写提示词，让 OpenClaw、HermesAgent、Codex、Claude、Gemini、OpenCode、Droid 自动写文章并发布到微信公众号草稿箱</title>
      <link>https://blog.margrop.net/post/agent-prompt-wechat-draft-automation/</link>
      <pubDate>Tue, 05 May 2026 16:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/agent-prompt-wechat-draft-automation/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;想让 OpenClaw、HermesAgent、Codex、Claude、Gemini、OpenCode、Droid 这类 Agent 自动写文章、生成博客、转换微信公众号 HTML、检查预览效果，并最终把内容发布到微信公众号草稿箱，提示词不能只写“帮我发一篇文章”。真正有用的提示词要把目标、素材、路径、账号约束、网络白名单、检查项、失败回退、隐私边界和最终验收写清楚。Agent 才能从“写一段内容”升级成“完成一次可验证的发布流程”。&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;本文整理一套可以复用的写法：如何准备微信公众号草稿箱 API，为什么固定 IP Linux 机器很重要，怎样让 Agent 先直连再走中转，如何使用 Markdown 到公众号 HTML 的转换器，如何让 Agent 检查白字白底、奇怪缩进、图片可访问性，最后如何把整条流程写进一段高质量提示词里。&lt;/p&gt;&#xA;&lt;p&gt;为了避免泄露任何私人环境信息，本文只使用占位符和抽象示例，不出现真实 AppSecret、内网地址、跳板机地址、仓库地址、主机名、token、cookie 或任何可定位到具体环境的配置。你可以把文中的占位符替换成自己的值，但不要把真实密钥写进公开文章、公开仓库或聊天截图。&lt;/p&gt;</description>
    </item>
    <item>
      <title>使用 WoClaw 解决多智能体共享记忆：让 OpenClaw、Codex、Claude、Gemini 站在同一张桌子上</title>
      <link>https://blog.margrop.net/post/woclaw-shared-memory-for-openclaw-codex-claude-gemini/</link>
      <pubDate>Sun, 05 Apr 2026 20:10:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/woclaw-shared-memory-for-openclaw-codex-claude-gemini/</guid>
      <description>&lt;p&gt;我一直觉得，多智能体系统最难的不是“谁更聪明”，而是“谁还记得上一次已经讨论到哪里了”。&lt;/p&gt;&#xA;&lt;p&gt;当你把 OpenClaw、OpenAI Codex、Claude、Gemini 这些工具放进同一个工作流里，最容易出现的问题并不是回答质量不够，而是上下文开始分叉：&lt;/p&gt;&#xA;&lt;ol&gt;&#xA;&lt;li&gt;OpenClaw 记住了调度顺序，Codex 记住了代码细节，Claude 记住了讨论结论，Gemini 记住了背景资料，但它们彼此并不知道对方知道什么。&lt;/li&gt;&#xA;&lt;li&gt;每个工具都有自己的会话生命周期，今天说过的话，明天可能就不在同一个上下文里了。&lt;/li&gt;&#xA;&lt;li&gt;一旦项目进入“多人、多轮、多工具”的阶段，重复解释背景会比真正解决问题更耗时。&lt;/li&gt;&#xA;&lt;li&gt;如果没有统一的记忆层，最后你得到的不是协作，而是几份彼此相似、又彼此不兼容的局部答案。&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;p&gt;这篇文章想讲的就是：我怎么用 WoClaw 把这些工具拉到同一套共享记忆里，让它们从“各说各话”变成“围着同一份状态协作”。&lt;/p&gt;&#xA;&lt;p&gt;为了避免泄露任何隐私信息，下面所有例子都做了抽象处理，不包含真实机器名、账号、地址、密钥和内部项目代号。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
