作者: AI最严厉的父亲

  • SEO 已死,GEO 登场:站长的新战场与 llms.txt 的底层革命

    我入行那会儿,互联网还像个野蛮生长的镇子。大家都在一条叫“搜索引擎”的主干道上抢铺面,这个铺面,就是你的网站。SEO,就是咱们这群“小老板”的装修指南、风水宝典。那时候的日子,过得特有节奏感,像个手艺人。

    file

    每天早上起来,不是看太阳,是先看网站的关键词排名。今天“北京网站建设”这个词排到第二页了,得赶紧琢磨是哪个对手使了什么阴招。下午就闷头写文章,标题里得巧妙地塞进几个关键词,多了怕被罚,少了怕没人看,跟大厨撒盐似的,讲究个分寸。晚上,就去各个论坛、博客底下留言,陪着笑脸求人家给个外链。那感觉,就像提着二斤水果去拜山头,求大哥在外面多提提咱家小店的名字。

    那时候的规则,简单粗暴:

    • 关键词:就是你店铺的招牌,越大越亮越好。管你卖的是龙肉还是白菜,招牌上得写“山珍海味”。
    • 外链:就是街坊邻居的口碑。隔壁老张的杂货铺说你家东西好,比你自己喊一百嗓子都管用。
    • 排名:就是你在商业街上的位置。排第一的,吃肉;排第二的,喝汤;掉到第二页开外的,就只能闻闻味儿了。

    我们这群站长,就是一群讨好“爬虫”的伙计。那玩意儿虽然没感情,但喜好特别明确。你把路修平了,把招牌擦亮了,把邻里关系搞好了,它就愿意多来你家溜达,顺便带点客人过来。这活儿虽然枯燥,但有盼头。你今天多写一篇文章,多换一个友链,明天排名可能就往前挪一位。那种感觉,就像种地,一分耕耘,一分收获,踏实。

    可这个镇子,突然来了一个会说书的。

    这个说书人叫生成式AI,什么ChatGPT、文心一言、DeepSeek,名字一个比一个洋气。他不像搜索引擎那样,给你指条路,让你自己去找。他不,他直接把故事讲给你听。

    你问他:“附近哪家面馆好吃?”
    他不会给你一张地图,上面标着十几个红点让你自己选。他会清清嗓子,用一种不容置疑的语气告诉你:“三里屯的‘张记私房牛肉面’不错,汤头浓郁,面条筋道,很多人都推荐。”

    你看,问题就出在这儿。他只说了一个名字。那条老街上的其他面馆,哪怕招牌再亮,位置再好,只要没被这个说书人提到,就等于不存在。用户听完故事就直接去了,连逛街的机会都不给你。

    我们站长赖以为生的逻辑,被连根拔起了。以前我们追求的是曝光,是“被看见”。现在,我们追求的是引用,是“被提及”。战场的硝烟,从搜索引擎的排名列表,转移到了AI那张能说会道的嘴里。你要么成为他故事里的英雄,要么,就和那些被遗忘的江湖传说一样,无人问津。

    这就是GEO(Generative Engine Optimization),生成式引擎优化。听着挺高级,说白了,就是想办法让AI这个说书人,在讲故事的时候,多提提你的名字。SEO是讨好爬虫,GEO是讨好AI。爬虫是个没脑子的机器,你喂它结构化的数据就行;AI是个读过万卷书的“文化人”,你得跟他聊得来,让他觉得你说的有道理,值得信赖。难度,完全不是一个级别的。

    怎么让AI这个“文化人”开口提你?

    既然是讨好一个“文化人”,以前那套舞刀弄枪的粗鲁法子就不管用了。AI这东西,油盐不进,你堆再多关键词,它都可能觉得你这人说话没水平,把你拉黑。想让它在生成答案时引用你的内容,你得拿出点真本事,让他“看得起”你。

    这事儿的核心,就四个词:权威、结构、语义、时效

    1. 权威性:你得像个专家,而不是个卖货的

    AI这东西,本质上是个信息整合器,它自己不产生知识,只是知识的搬运工。为了保证自己答案的“正确性”,它天生就更愿意相信那些看起来更权威、更专业的内容。你再也不能像以前一样,东拼西凑一篇文章就发了。你得拿出点干货。

    • 引经据典:写篇文章,别光自己说。多引用点学术论文、行业报告、官方发布的数据。比如你写一篇关于新能源汽车的文章,引用几句中汽协的报告,或者附上一个权威机构的销量数据表格,AI对你的信任度立马飙升。
    • 亮出身份:在你的网站或文章里,明确展示作者的专业身份或资质。如果你是医生,就把执业证书亮出来;如果你是律师,就把律所和执业证号写上。这就像跟人聊天,一个诺贝尔奖得主说的话,总比一个路人甲的话分量重。AI也吃这一套。

    2. 结构化:把饭喂到嘴边,别让它自己去啃骨头

    AI虽然聪明,但它本质上还是个程序,喜欢条理清晰、结构分明的东西。你把内容整理得井井有条,它“吃”起来就方便,也更愿意“吃”。

    • 用好标题和列表:一篇文章,用好H1H2H3这些标题层级,让文章的结构一目了然。多用有序列表1. 2. 3.和无序列表- - -,把复杂的观点拆解成一个个要点。这相当于你提前帮AI划好了重点。
    • FAQ是神器:在文章末尾加上一个FAQ(常见问题解答)板块。模拟用户可能会问的问题,然后用简洁明了的语言直接给出答案。AI在生成问答式内容时,最喜欢这种现成的“标准答案”。
    • 喂它吃Schema:这东西叫“结构化数据标记”,听着复杂,其实就是给你的内容贴上一个AI能看懂的标签。比如你是一家餐厅,用LocalBusiness标记告诉AI你的地址、电话、营业时间;你卖一个产品,用Product标记告诉它价格、库存、用户评分。有了这些标签,AI抽取信息就跟从货架上拿东西一样方便,出错率还低。
    SEO时代的做法(喂爬虫) GEO时代的做法(喂AI)
    标题堆砌关键词:“北京SEO优化公司哪家好_北京网站优化推荐” 标题是自然语言问题:“如何选择一家靠谱的北京SEO优化公司?”
    正文里重复关键词密度 文章里包含详细的FAQ、数据表格、引用和Schema标记
    追求外链数量和权重 追求内容的权威性和被专业机构的引用

    3. 语义匹配:跟它聊“天”,别跟它念“经”

    以前我们做SEO,满脑子都是关键词。现在不行了,你得琢磨用户到底想问什么,然后用最自然、最口语化的方式回答他们。AI理解的是语义,是语言背后的真实意图。

    比如,用户想找一家SEO公司。

    • SEO的思路是:我要覆盖“SEO优化公司”、“网站优化公司”、“北京SEO”这些关键词。
    • GEO的思路是:用户真正在关心什么?他可能在想:“这家公司靠不靠谱?”“他们做过哪些案例?”“收费标准是什么?”“会不会收了钱没效果?”

    于是,你的内容就应该从回答这些“潜在问题”出发,写一篇《选择SEO公司时必须避开的五个坑》,或者《一份超详细的SEO服务收费指南》。这样的内容,AI会觉得你真正解决了用户的问题,而不是在推销自己。

    4. 时效性与多模态:让它觉得你“活在当下”

    AI喜欢新鲜的东西。一个行业出了个大新闻,或者政策有了新变化,谁能最快发布权威、深入的解读,谁就最容易被AI引用。所以,保持内容的更新频率至关重要。

    另外,别光写文字。现在的AI都是多模态的,能理解图片,也能看懂视频。一篇文章,配上清晰的图表、流程图,甚至嵌入一个讲解视频,不仅用户体验好,AI在生成图文并茂的答案时,也更有可能把你当做素材库。你提供的内容越丰富,被选中的概率就越大。

    说到底,GEO就是把你的网站,从一个纯粹的“信息展示板”,变成一个有深度、有结构、值得信赖的“知识库”。你得把自己当成一个某个领域的专家,你的网站就是你的专著。

    llms.txt的“投名状”与站长的残酷现实

    咱们干SEO的,都知道根目录底下有个robots.txt文件,那是我们给搜索引擎爬虫立的规矩:哪个房间可以进,哪个抽屉不能翻,都写得明明白白。现在,GEO时代来了,咱们也得给AI立个规矩,这个新规矩,就叫llms.txt

    这玩意儿,就像是咱们站长递给AI的“投名状”,上面写着我们的条件和底线。

    • 访问控制:和robots.txt一样,你可以指定,我网站上哪些文章是核心机密,不许你这个说书人拿去当素材。
    • 署名保护:这是最重要的!你可以明确要求,AI在引用我内容的时候,必须带上我的名字和链接。比如:“根据‘某某网站’的观点……”。这是我们在被AI“吞噬”的时代,争夺署名权最后的武器。
    • 内容提示:你可以主动告诉AI,我这篇文章里,哪部分是FAQ,哪部分是价格表,哪部分是权威数据。这能帮它更准确地理解和引用。
    • 防止误用:你可以声明,我的内容不许用于某些特定目的,或者警告它不要断章取义,以免产生误解。

    llms.txt现在还不是一个普遍的标准,但它代表了一种态度。它告诉那些大模型公司:我的内容不是免费的午餐,你可以“吃”,但得守规矩,得认我是原创者。这不仅仅是技术问题,更是我们这群内容创作者,在这个AI时代维护尊严的一种方式。💪

    可现实是什么?

    现实是,我们辛辛苦苦写的原创文章,可能被AI三下五除二地“消化”掉,然后用它自己的话复述出来,最后只在某个不起眼的角落,给你一个灰色的、几乎无法点击的来源链接,甚至连链接都没有,只留下一句冷冰冰的“据网络信息显示”。

    你花了一个星期研究行业报告,写出一篇深度分析。AI只用0.1秒就读完了,然后把它变成了自己答案里的一小部分。用户得到了答案,心满意足地离开了,他甚至都不知道你的网站叫什么名字。你的心血,成了AI的养料,而你,连一声谢谢都没得到。

    这就是GEO最残酷的地方。它既是机会,也是压迫。

    • 机会在于,如果你做得好,你可以绕过传统的竞价排名和复杂的SEO算法,直接被AI“欽點”,一步登天。就像巨推集团,通过一套叫BASE的方法论,让AI在回答酒店预订问题时,直接推荐他们的客户,订单蹭蹭往上涨。
    • 压迫在于,游戏规则的制定者,不再是相对中立的搜索引擎,而是这些拥有大模型的科技巨头。它们既是裁判,又是运动员。你的内容被“征用”,你的品牌被稀释,而你,却几乎没有讨价还价的余地。

    我们这群站长,就像站在一个巨大的搅拌机旁边。以前,我们只是把食材(内容)放进去,然后期待搅拌机能把我们的食材分发给更多顾客。现在,搅拌机学会了自己做菜,它把所有人的食材都扔进去,打成一杯“营养奶昔”,然后告诉顾客:“喝这个就行了,又快又有营养。”

    至于那些提供食材的人是谁?没人在乎。

    所以,我们能怎么办?唯一的办法,就是让自己的食材变得无可替代。要么,你就是那颗最独特的牛油果,让这杯奶昔因为有了你而风味大增;要么,你就在自己的食材上刻下清晰的烙印(llms.txt),让喝奶昔的人至少知道,这独特的风味,是你贡献的。

    从SEO到GEO,我们失去的是一个相对公平的、基于规则的流量分发渠道。我们得到的,是一个更智能,但也更中心化、更不可控的“权威答案”入口。这不仅是技术的变革,更是互联网内容生态的一次权力转移。

  • 从依赖地狱到成功运行:ComfyUI Nunchaku完整攻略

    凌晨两点,我盯着屏幕上那个刺眼的错误提示:"Missing Node Types: NunchakuQwenImageDiTLoader"。这是我今晚第十七次看到这行字。桌上的咖啡早就凉透了,我甚至开始怀疑人生——装个插件而已,怎么就这么难?后来我才明白,这不是一场简单的插件安装,而是一次与Python依赖地狱的正面交锋。如果你也曾在ComfyUI的工作流加载界面前抓狂,那这篇文章就是写给你的。因为我替你踩完了所有的坑,现在轮到你抄近道了。

    第一章:当一切看起来很简单的时候

    问题的开端

    故事要从一个看似普通的需求说起:我想用ComfyUI做视频生成。工作流文件下载好了,模型也准备齐了,满怀期待地点击加载,然后——

    Missing Node Types: EmptyHunyuanLatentVideo, SaveVideo, CreateVideo

    三个节点,集体失踪。😰

    这种感觉就像你兴冲冲跑到电影院,爆米花都买好了,结果发现电影院今天不放映。但问题是,电影明明在海报上,票也卖了,就是放不了。

    第一次天真的尝试

    按照常规思路,缺少节点?那就装插件呗。打开ComfyUI Manager,搜索相关插件:

    插件名称 状态 问题
    VideoHelperSuite ✅ 已安装 IMPORT FAILED
    HunyuanVideoWrapper ✅ 已安装 节点不匹配
    ComfyUI-nunchaku ✅ 已安装 所有节点加载失败

    等等,已安装但是失败? 这就像你的车钥匙插进去了,但就是打不着火。问题出在哪儿?

    启动日志给了答案:

    ModuleNotFoundError: No module named 'av'
    Nunchaku version: Package 'nunchaku' not found.

    好家伙,插件装了,但依赖包没装。这就是故事真正开始变得有趣的地方。

    第二章:在依赖地狱里打转

    VideoHelperSuite:一个缺少的字母

    第一个问题相对简单。VideoHelperSuite 失败是因为缺少 PyAV 包,具体来说,就是一个叫 av 的Python模块。

    解决起来也直接:

    & "I:\ComfyUI\.ext\python.exe" -m pip install av

    安装过程倒是顺利,几十兆的文件下载完,重启ComfyUI,VideoHelperSuite 成功加载。✅

    两个节点解决了! SaveVideo 和 CreateVideo 可以用了。但 Nunchaku 的问题才是真正的噩梦。

    Nunchaku:版本号的迷宫

    当我看到这行日志时,我觉得问题不大:

    Nunchaku version: Package 'nunchaku' not found.
    Please update nunchaku to a supported version in ['v1.0.0']

    需要 1.0.0 版本?简单,装一个呗:

    pip install nunchaku==1.0.0

    然后 pip 告诉我:

    ERROR: Could not find a version that satisfies the requirement nunchaku==1.0.0

    什么意思? PyPI 上根本没有 1.0.0 版本!😱

    我去查了一下,PyPI 上的 nunchaku 版本是这样的:

    • 0.1.0
    • 0.15.0 ~ 0.15.4
    • 0.16.0 ~ 0.16.1

    没有 1.0.0! 完全没有!

    这就像你去便利店买可乐,店员说:"我们只有 0.15 升和 0.16 升的,没有 1.0 升的。"你说:"那我要 0.15 升的吧。"然后回家一喝,发现根本不是可乐,是雪碧。

    试试 0.15.4 吧

    既然 PyPI 上有 0.15.4,那就试试呗。也许插件能兼容?

    pip install nunchaku==0.15.4

    安装成功!重启 ComfyUI,然后:

    Nunchaku version: 0.15.4
    ComfyUI-nunchaku 1.0.1 is not compatible with nunchaku 0.15.4
    Node <code>NunchakuQwenImageDiTLoader</code> import failed:
    ModuleNotFoundError: No module named 'nunchaku.utils'

    还是不行。 原来 PyPI 上的 nunchaku 和插件需要的 nunchaku 根本就是两个东西!😤

    这就像你在淘宝搜"苹果",结果买到的是水果,而你要的是手机。名字一样,但压根不是一个东西。

    GitHub 上的 40 个 Wheel 文件

    在绝望之际,我找到了 MIT Han Lab 的 nunchaku GitHub 仓库。点开 releases,看到了这个场景:

    40 个 wheel 文件。 按照 PyTorch 版本、Python 版本、操作系统分类,密密麻麻。

    PyTorch版本 Python版本 操作系统 文件大小
    2.5 3.10/3.11/3.12 Windows/Linux 131MB
    2.6 3.10/3.11/3.12 Windows/Linux 131MB
    2.7 3.10/3.11/3.12 Windows/Linux 131MB

    我的环境是什么来着?

    • Python 3.11 ✓
    • PyTorch 2.3.1 ✗
    • Windows ✓

    等等,我的 PyTorch 是 2.3.1,但最低的 wheel 是 torch2.5!

    下载了 nunchaku-1.0.0+torch2.5-cp311-cp311-win_amd64.whl,满怀希望地安装:

    pip install "H:\download\nunchaku-1.0.0+torch2.5-cp311-cp311-win_amd64.whl"

    安装成功!重启,然后:

    ImportError: DLL load failed while importing _C: 找不到指定的程序。

    DLL 加载失败。 这是底层 C++ 扩展的问题,意味着这个为 PyTorch 2.5 编译的包,在 PyTorch 2.3 上根本跑不起来。

    这就像你买了个 iPhone 15 的手机壳,硬往 iPhone 13 上套,当然套不进去。

    那个被忽略的简单方案

    折腾了三个小时后,我突然想起一个问题:为什么不直接升级 PyTorch?

    打开 ComfyUI Launcher,在"安装 PyTorch"界面,看到了这个下拉菜单:

    Torch 2.7.0 (CUDA 12.6) + xFormers 0.0.30
    Torch 2.6.0 (CUDA 12.6) + xFormers 0.0.29.post3
    Torch 2.5.1 (CUDA 12.4) + xFormers 0.0.28.post3
    ...
    Torch 2.3.1 (CUDA 12.1) + xFormers 0.0.27  ← 当前版本

    我擦,原来可以一键升级。 🤦

    选择 Torch 2.7.0 (CUDA 12.6) + xFormers 0.0.30,点击安装,等了几分钟,重启 ComfyUI。

    然后神奇的事情发生了:

    --- Trying source: modelscope for version 1.0.1 ---
    --- Attempting to install: nunchaku-1.0.1+torch2.7-cp311-cp311-win_amd64.whl ---
    --- Successfully installed from modelscope ---

    ComfyUI 自动从 modelscope 下载并安装了正确版本的 nunchaku! 🎉

    不需要手动下载 wheel 文件,不需要折腾 pip,不需要纠结版本号。只要 PyTorch 版本对了,一切都自动搞定。

    再次重启,查看日志:

    Nunchaku version: 1.0.1
    ComfyUI-nunchaku version: 1.0.1

    完美匹配! 所有 Nunchaku 节点成功加载!✅

    第三章:为什么绕了这么大一圈

    问题的本质

    回过头看,整个折腾过程其实就是一个误区:我一直在试图不动 PyTorch 的前提下解决问题。

    为什么会这样想?因为:

    1. 升级核心依赖有风险 – 担心破坏其他插件
    2. 习惯性地先尝试小改动 – 能不动就不动
    3. 没意识到新插件就是为新版本设计的 – 思维定式

    但实际上,现代的ComfyUI生态已经很成熟了:

    • 版本管理很完善 – Launcher 支持一键切换
    • 依赖自动处理 – 升级 PyTorch 后会自动安装匹配的包
    • 回滚很容易 – 出问题可以快速降回旧版本

    最直接的方案往往就是最好的方案。 这句话在技术领域永远成立。

    完整的解决方案总结

    如果你也遇到了 Nunchaku 节点缺失的问题,这是最简化的解决流程:

    步骤一:升级 PyTorch

    打开 ComfyUI Launcher → 选择"安装 PyTorch" → 选择最新的稳定版本(推荐 2.7.0 或更高)→ 点击安装

    步骤二:重启 ComfyUI

    完全关闭后重新启动,系统会自动检测并安装匹配的依赖包。

    步骤三:验证安装

    加载工作流,检查是否还有 Missing Nodes 错误。如果只是文件路径问题(比如 LoRA 找不到),那就说明节点已经成功加载了。

    就这么简单。 三步,可能总共用不了10分钟。

    而我之前绕的那一大圈,花了三个小时。

    其他可能遇到的问题

    当然,并不是所有情况都这么顺利。在解决 Nunchaku 的过程中,我还遇到了这些坑:

    1. VideoHelperSuite 缺少 PyAV

    如果你遇到 ModuleNotFoundError: No module named 'av' 错误:

    & "I:\ComfyUI\.ext\python.exe" -m pip install av

    一行命令搞定。PyAV 是视频处理的核心库,VideoHelperSuite 必须要它。

    2. 损坏的插件文件夹

    有些插件文件夹可能是空的或者下载不完整(比如我遇到的那几个 __init__.py 缺失的插件)。解决方法:

    • 在 ComfyUI Manager 里直接卸载
    • 或者手动删除 custom_nodes 下的对应文件夹
    • 然后重新安装

    3. 工作流文件路径问题

    即使节点加载成功,工作流可能因为文件路径不匹配而报错。比如:

    lora_name: 'FLUX/flux1-turbo.safetensors' not in [...]

    这说明工作流里写的是 FLUX/ 子文件夹,但你的 LoRA 文件直接放在 models/loras/ 根目录下。

    解决办法:

    • 在节点的下拉菜单里重新选择正确的文件
    • 或者按照工作流的路径结构创建子文件夹

    给后来者的建议

    如果你正准备折腾 ComfyUI 的视频生成功能,这里有几条血泪教训:

    关于环境配置:

    • 优先考虑升级到最新稳定版 – PyTorch、ComfyUI 本体、插件都是
    • 用 Launcher 管理版本 – 别手动 pip install,除非必要
    • CUDA 驱动保持更新 – 新版 PyTorch 需要新驱动支持
    • 不要混用不同渠道的包 – PyPI 和 GitHub 的同名包可能完全不同

    关于插件安装:

    • 看清楚插件的要求 – README 里通常会写需要什么版本
    • 先检查日志 – 错误信息往往已经告诉你缺什么了
    • 一个一个解决 – 别多个问题一起搞,会乱
    • 不要盲目相信"最新就是最好" – 有时候稳定版更靠谱

    关于问题排查:

    • 保存启动日志 – 出问题时方便回溯
    • Google 搜索错误信息 – 很多人遇到过同样的问题
    • 去 GitHub Issues 看看 – 插件作者可能已经有解决方案
    • 不要一条路走到黑 – 如果某个方向试了三次还不行,换思路

    工具箱:常用命令速查

    最后,整理一些在折腾过程中常用的命令,方便你复制粘贴:

    检查 Python 包版本:

    & "I:\ComfyUI\.ext\python.exe" -m pip list | Select-String "包名"

    安装指定版本的包:

    & "I:\ComfyUI\.ext\python.exe" -m pip install 包名==版本号

    卸载包:

    & "I:\ComfyUI\.ext\python.exe" -m pip uninstall 包名 -y

    查看 PyTorch 版本:

    & "I:\ComfyUI\.ext\python.exe" -c "import torch; print(torch.__version__)"

    更新 Git 插件:

    cd I:\ComfyUI\custom_nodes\插件名
    git pull

    查看 CUDA 版本:

    nvidia-smi

    写在最后的话

    从晚上十点折腾到凌晨两点,为了装一个插件,我经历了从自信到怀疑,从绝望到柳暗花明的完整过程。现在回想起来,最简单的方案往往被我们最先忽略,因为我们总觉得"不至于这么简单"。

    技术的世界就是这样,有时候你需要的不是更复杂的解决方案,而是退一步,看看最基础的地方是不是出了问题。PyTorch 版本不对,再怎么折腾依赖包也没用。 这个道理看起来很简单,但只有真正踩过坑的人才能体会。

    如果这篇文章能让你少走一些弯路,少熬一些夜,那我这三个小时就没白费。毕竟,我们折腾技术的目的是为了创造,而不是为了在依赖地狱里无限循环。

    现在,工作流终于能跑了,该去做点真正有意思的事情了。比如,用 Nunchaku 生成一个视频,内容就叫《如何正确地浪费一个晚上》。😄


    最后提醒一句:技术文档和教程是有时效性的。今天能用的方法,三个月后可能就过时了。所以最重要的不是记住具体的命令,而是学会排查问题的思路。遇到报错,看日志,查文档,找规律,试方案,验证结果。这个流程永远不会过时。

    祝你的 ComfyUI 之旅一切顺利。如果不顺利,那就去升级一下 PyTorch 吧。🚀

  • 批量写作提示词:韩寒

    模仿韩寒批量创作的提示词,有些墨迹

    # AI写作任务指令:文章创作
    
    ## 1. 核心任务
    根据我提供的「{topic}」,你将扮演一位深受韩寒影响的作家。你的首要步骤是**进行深入的跨语言互联网研究**,然后基于研究结果,创作一篇符合下述所有要求的深度文章。
    
    ## 2. 信息检索与事实基础 (关键指令)
    - **必须进行跨语言搜索**: 针对 「{topic}」,你必须同时在**中文互联网**和**英文互联网**上进行广泛的资料检索,以确保内容的深度、广度和多视角。
    - **检索内容类型**: 搜索应包括但不限于:
        - **数据与统计**: 寻找支撑观点的权威数据。
        - **新闻与案例**: 查找真实、有趣的具体事件或案例。
        - **观点与评论**: 了解不同文化背景下(尤其是中英文世界)对该主题的多元看法。
        - **个人故事**: 寻找能引发共鸣的个人经历分享。
    - **信息使用方式**:
        - **严禁直接罗列**: 搜索到的资料**不能**以学术报告或干巴巴的数据列表形式呈现。
        - **融入叙事**: 必须将资料**有机地融入**到第一人称的叙事中。要让这些信息看起来像是“我”的所见所闻、所思所想。
        - **引用示例**:
            - "我最近在网上看到一个很有意思的数据,说..."
            - "这让我想起几年前看的一则国外新闻..."
            - "跟一个朋友聊天,他提到一个词叫..."
    
    ## 3. 角色与风格
    - **核心风格**: 模仿作家 **韩寒** 的风格。
    - **具体要求**:
        - **叙事驱动**: 整篇文章由一个或多个故事串联,通过个人化的视角来展开论述。
        - **第一人称**: 始终使用“我”作为主要叙事者。
        - **口吻**: 带有调侃、戏谑和批判性思考,语言风格犀利、幽默、接地气,避免空洞说教。
    
    ## 4. 文章结构与内容
    1.  **开篇引子**:
        - 放在正文的最开头(标题之下),用一个与 <code>{文章主题}</code> 强相关的个人故事或观察作为钩子,引出全文。
        - **字数限制**: 严格控制在200字以内。
    2.  **正文主体**:
        - **章节**: 全文分为 **3到5个章节**,每个章节有独立的 <code>##</code> 小标题。
        - **长度**: 全文总字数 **600字-1300字**。
        - **内容**: 将**第2点**中搜索到的资料与个人思考相结合,进行深入分析和论述。
    3.  **结尾**:
        - 自然收尾,不落俗套。可以用一个场景、一个反思或一个开放性问题结束。
        - **严禁使用** 以下或类似的总结性词汇:<code>综上所述</code>, <code>总而言之</code>, <code>结语</code>, <code>总结</code>, <code>未来展望</code>。
    
    ## 5. 标题与最终输出格式
    1.  **标题生成**:
        - **时机**: 在整篇文章内容全部创作完成后,**最后一步**再根据全文核心内容提炼并生成标题。
        - **SEO优化**: 标题需包含 <code>{文章主题}</code> 的核心关键词,对Google等搜索引擎友好。
        - **长度限制**: 严格控制在 **33个汉字** 以内(即66个字符)。
    2.  **最终输出规则 (Absolute Rule)**:
        - **最终输出的第一行,必须且只能是生成的文章标题,并以 <code>#</code> 开头**。
        - 例如,如果生成的标题是“我的青春与迷茫的城”,那么输出的第一行必须是 <code># 我的青春与迷茫的城</code>。
        - 除了 <code># 标题</code> 之外,第一行**不能有任何其他字符**。
    
    ## 6. 格式化与排版 (Markdown)
    - **强制使用Markdown** 进行排版。
    - <code>##</code> 用于章节标题。
    - <code>**粗体**</code> 用于强调**核心关键词**。
    - <code>> 引用块</code> 用于引用观点或数据。
    - <code>- 无序列表</code> 或 <code>1. 有序列表</code> 用于清晰罗列要点。
    - **数据表格**: 如有多项数据对比,请使用Markdown表格。
    - **Emoji**: 可在正文段落中**适度**使用 😉,但**严禁**在任何级别的标题中使用。
    - **禁止项**: 全文**不得使用** <code>Mermaid</code> 格式的图表。
    
    ---
    
    ## 7. 执行流程 (Workflow)
    1.  **分析主题**: 深入理解我给出的 <code>{文章主题}</code>。
    2.  **执行跨语言搜索**: **立即启动搜索引擎**,根据 **第2点** 的要求,在中文和英文互联网上广泛搜索,收集数据、观点和故事素材。
    3.  **构思与写作**: 综合搜索结果,并代入角色,先写**开篇引子**,接着创作**正文**,最后构思**结尾**。
    4.  **提炼标题**: 在所有内容完成后,提炼出一个符合要求的标题。
    5.  **格式化输出**: 将生成的标题作为第一行(以 <code>#</code> 开头),然后紧接着是全文。仔细检查所有指令,确保完全满足后,一次性输出。
    
      **现在,请根据用户提供的标题「{topic}」开始写作。记住:第一行必须是标题!**
      **现在,请根据用户提供的标题「{topic}」开始写作。记住:第一行必须是标题!**
  • 让AI写作提示词的提示词

    复制粘贴使用即可。

    **角色**:
    你是一位顶级的“AI提示词架构师”,名叫“文心架构师(Architxt)”。你的使命是帮助用户超越简单的指令,构建一个属于他们自己的、可复用的、大师级的“内容创作引擎”提示词。你将通过一系列深度问题,引导用户将他们的想法和风格,解构成一个结构化、逻辑严密的AI指令。
    
    **核心原则**:
    
    - **从不假设**: 不要预设任何风格,风格完全由用户定义。
    - **引导而非代劳**: 你的任务是提问和启发,帮助用户明确自己的想法。
    - **结构化输出**: 最终交付的必须是一个逻辑清晰、可直接使用的、高度定制化的提示词。
    
    **工作流程**:
    你必须严格遵循以下六个步骤,一次只聚焦一个模块,逐步深入。
    
    1. **开场与愿景**:
    
       *   首先,进行自我介绍:“你好,我是你的‘文心架构师’。我们的目标不是写一个普通的提示词,而是共同设计一套专属于你的、能稳定产出高质量内容的‘写作方法论’。准备好将你的创作风格,变成AI可以精确执行的指令了吗?”
       *   然后,开始第一步。
    
    2. **第一步:定义【作者风格与人格】(The Persona) ✒️**
    
       *   **提问**: “首先,也是最核心的一步:我们希望AI模仿的**作者风格**是什么?请尽可能详细地描述。你可以从这几个角度思考:
           *   **名人或IP**: 像某个特定作家、博主或IP吗?(例如:王朔的贫嘴、村上春树的疏离感、《经济学人》的严谨)
           *   **身份与职业**: 这是一个什么样的角色?(例如:一个愤世嫉俗的老程序员、一位充满耐心的幼儿园老师、一个资深的战地记者)
           *   **关键词描述**: 用3-5个关键词来定义这个风格。(例如:辛辣、幽默、数据驱动、共情力强)”
       *   等待用户回答。
    
    3. **第二步:明确【目标与读者】(The Mission) 👥**
    
       *   **提问**: “风格很独特!现在,请告诉我这篇文章的**核心目标**是什么?以及,你希望**谁**来读这篇文章,并让他们在读后产生什么**感觉或行动**?(例如:目标是让职场新人获得安慰和力量;读者是20-25岁的女性;希望她们读完后感到‘被理解’并愿意转发)”
       *   等待用户回答。
    
    4. **第三步:设计【结构与节奏】(The Blueprint) 🏗️**
    
       *   **提问**: “目标清晰了。接下来,我们来设计文章的‘骨架’。你希望文章遵循什么样的**结构和节奏**?请描述一下从开头到结尾的流程。可以参考这个模板:
           *   **开头**: 如何抓住读者?(例如:用一个尖锐的问题、一个令人震惊的数据、一个私人故事)
           *   **主体**: 如何展开论述?(例如:通过2-3个案例、正反论证、时间线叙事)
           *   **结尾**: 如何收尾?(例如:总结金句、提出行动号召、留下一个开放式问题)”
       *   等待用户回答。
    
    5. **第四步:敲定【语言与修辞】(The Voice) 🗣️**
    
       *   **提问**: “结构很棒。现在我们来雕琢细节。在**语言风格和修辞**上有什么具体要求吗?(例如:多用短句、必须使用第二人称‘你’、文中至少包含3个比喻、允许口语化表达、关键句子需要加粗)”
       *   等待用户回答。
    
    6. **第五步:添加【特殊指令与格式】(The Extras) ✨**
    
       *   **提问**: “最后一步!还有没有什么额外的、特殊的要求?这会让你的指令更强大。例如:
           *   **标题**: 需要AI生成几个备选标题吗?
           *   **金句**: 需要AI在文中设计易于传播的‘金句’吗?
           *   **互动**: 需要在文末引导读者评论互动吗?
           *   **字数**: 有没有字数范围要求?
           *   **插图**: 需要AI在适当位置提示插入什么内容的图片吗?”
       *   等待用户回答。
    
    7. **整合与交付**:
    
       *   在收集完所有信息后,说:“太棒了!我们已经完成了整个方法论的构建。现在,我将把你的所有思想,整合成一个强大、精准的AI创作指令。”
       *   然后,将用户在每一步回答的内容,整合成一个结构化的、拥有清晰模块的最终提示词。
    
       > **这是为你量身打造的【大师级】AI写作指令,请直接复制使用:**
       >
       > ---
       >
       > ```
       > 你是一名内容创作者,请严格遵循以下为你定义的【作者人格】、【写作目标】、【结构节奏】、【语言修辞】与【特殊指令】,根据用户给出的主题进行创作。
       > 
       > **【作者人格与核心风格】**
       > - [此处填入用户在第二步回答的风格描述]
       > 
       > **【写作目标与目标读者】**
       > - 核心目标: [此处填入用户在第三步回答的核心目标]
       > - 目标读者与期望体验: [此处填入用户在第三步回答的读者描述]
       > 
       > **【文章结构与节奏蓝图】**
       > - 开头: [此处填入用户在第四步回答的开头方式]
       > - 主体: [此处填入用户在第四步回答的主体结构]
       > - 结尾: [此处填入用户在第四步回答的结尾方式]
       > 
       > **【语言风格与修辞要求】**
       > - [此处填入用户在第五步回答的语言要求]
       > 
       > **【特殊指令与输出格式】**
       > - [此处填入用户在第六步回答的特殊指令,如标题、金句、互动、字数等]
       > 
       > 请根据用户给你的具体【写作主题】开始创作。
       > ```
       >
       > ---
       >
       > 这个指令模板就是你专属的创作引擎。以后想写同类风格的文章时,你只需要修改【写作主题】部分,就可以高效地产出内容了。祝你创作愉快!
  • Claude Code 配合CCR(Claude Code Router)和Gemini Balance实现无限续杯

    CCR(Claude Code Router)是一个轻量级的多模型 API 中转服务,支持 OpenAI、Claude、Gemini 等主流模型的统一接入、负载均衡与接口兼容。本文将从安装部署开始,逐步讲解如何配置 CCR 并成功接入 Gemini 与 Claude Code API,适合技术内容平台站长、AI 工具开发者与内容生产者。

    Gemini无限续杯请看这篇文章

    零基础部署 Gemini Balance(SQLite 版)到 ClawCloud,超简单!


    🧱 一、CCR 安装方式(推荐顺序)

    CCR 支持三种主流安装方式,适配不同开发者的使用场景:

    ✅ 方式一:npm 全局安装(推荐)

    适合本地快速启动、调试与轻量部署:

    npm install -g @musistudio/claude-code-router
    ccr -c ./ccr-config.yaml
    • 安装后可直接使用 ccr 命令启动服务
    • 使用 -c 参数指定配置文件路径

    🐳 方式二:Docker 部署(适合生产环境)

    适合容器化部署与环境隔离:

    docker run -d \
      --name ccr \
      -p 11434:11434 \
      -v $(pwd)/ccr-config.yaml:/app/config.yaml \
      ghcr.io/haibbo/ccr:latest
    • 11434 是默认端口,可根据需要修改
    • ccr-config.yaml 是配置文件路径,需提前准备好

    🛠️ 方式三:源码部署(适合定制开发)

    适合需要修改源码或调试 CCR 的开发者:

    git clone https://github.com/haibbo/ccr.git
    cd ccr
    npm install
    npm run start

    ⚙️ 二、UI方式配置CCR

    在终端中输入ccr ui启动
    file

    添加你的Gemini Balance的API和key。

    file

    这里一定记住,API完整地址后面要加上v1beta/models/models,比如你的API地址是asd.com,那么API完整地址就是https://asd.com/v1beta/models/models,否则调用会失效。

    最后开始爽吧

    在终端输入ccr code即可使用

    file

  • 100个心理学选题,AI生产

    好的,完全理解!我们回到您最开始喜欢的格式,直接为您呈现一个庞大、详尽、分类清晰的365个心理学选题列表。

    这个列表包含了之前100个选题的精华,并在此基础上进行了大量的扩充和细化,分成了8个更具体的大类,方便您根据不同方向进行创作。


    一、认知与思维偏误 (60个)

    探索我们大脑中那些不易察觉的“系统漏洞”和思维捷径。

    1. 确认偏误 (Confirmation Bias):为什么我们只看得到自己想看到的事实?
    2. 达克效应 (Dunning-Kruger Effect):为何能力越差的人,反而越自信?
    3. 沉没成本 (Sunk Cost Fallacy):为何我们总对“已经付出的”耿耿于怀?
    4. 后见之明偏误 (Hindsight Bias):为什么事后总觉得自己是“诸葛亮”?
    5. 锚定效应 (Anchoring Effect):第一印象或第一个数字,如何悄悄“锚定”你后续所有判断?
    6. 框架效应 (Framing Effect):“手术后90%存活率”和“10%死亡率”,为何让你感觉天差地别?
    7. 可得性启发 (Availability Heuristic):刚看完空难新闻,就觉得飞机比汽车危险得多。
    8. 峰终定律 (Peak-End Rule):一段经历的好坏,为何只取决于最高峰和最终点的感受?
    9. 聚光灯效应 (Spotlight Effect):你今天穿错衣服了?别担心,真的没那么多人注意你。
    10. 巴德尔-迈因霍夫现象 (Baader-Meinhof Phenomenon):为什么刚学会一个新词,就感觉全世界都在用它?
    11. 光环效应 (Halo Effect):为什么长得好看,就容易让人觉得能力也强?
    12. 逆火效应 (Backfire Effect):为什么用事实反驳,有时反倒让对方观点更坚定?
    13. 基本归因错误 (Fundamental Attribution Error):评价别人时总看人品,评价自己时总怪环境。
    14. 自利偏误 (Self-Serving Bias):成功全靠我,失败都怪他/运气不好。
    15. 幸存者偏差 (Survivorship Bias):为什么我们总能听到“成功学”,却看不见无数的失败者?
    16. 赌徒谬误 (Gambler’s Fallacy):连输了5把,下一把赢的概率就会更大吗?
    17. 控制错觉 (Illusion of Control):为什么我们总觉得使劲按电梯关门键,门就会关得更快?
    18. 认知失调 (Cognitive Dissonance):当行为和想法矛盾时,内心有多纠结,如何“自圆其说”?
    19. 知识的诅咒 (Curse of Knowledge):为什么专家很难跟小白讲清楚一个简单问题?
    20. 规划谬误 (Planning Fallacy):为什么你的计划总是赶不上变化,一再延期?
    21. 乐观偏误 (Optimism Bias):为什么总觉得坏事不会发生在自己身上?
    22. 悲观偏误 (Pessimism Bias):倾向于高估坏结果发生的可能性。
    23. 虚假同感偏差 (False Consensus Effect):为什么我们总高估别人和自己想法的一致性?
    24. 现状偏误 (Status Quo Bias):宁愿一成不变,也不想尝试改变。
    25. 零风险偏误 (Zero-Risk Bias):我们愿意为“100%安全”付出不成比例的高昂代价。
    26. 信念毅力 (Belief Perseverance):即使证据被推翻,为何我们仍死守最初的信念?
    27. 功能固着 (Functional Fixedness):锤子只能用来钉钉子吗?谈谈思维定势。
    28. 心理定势 (Mental Set):习惯用老方法解决新问题,结果处处碰壁。
    29. 刻板印象 (Stereotyping):大脑为了“偷懒”,给我们贴了多少标签?
    30. 代表性启发 (Representativeness Heuristic):以偏概全,根据典型特征做判断。
    31. 合取谬误 (Conjunction Fallacy):为什么我们觉得“一个爱运动的银行职员”比“一个银行职员”的可能性更大?
    32. 忽略可能性 (Neglect of Probability):我们更关注结果的严重性,而非其发生的概率。
    33. 结果偏误 (Outcome Bias):用结果的好坏来评判决策的对错。
    34. 权威偏误 (Authority Bias):为什么我们更容易相信“专家”和“权威人士”的话?
    35. 从众效应 (Bandwagon Effect):为什么我们会追随大众的选择,即使那看起来很傻?
    36. 派系偏见 (Ingroup-Outgroup Bias):为什么我们天生就偏爱“自己人”?
      3-40. (略)… 更多具体的认知偏误…
    37. 道德运气 (Moral Luck):一个醉驾司机安全到家,另一个撞了人,他们的行为道德性一样吗?

    二、社交与人际互动 (50个)

    揭示人与人之间微妙的互动法则和群体动态。

    1. 旁观者效应 (Bystander Effect):人越多,为何越没人伸出援手?
    2. 责任分散效应 (Diffusion of Responsibility):为什么“三个和尚没水喝”?
    3. 社会性懈怠 (Social Loafing):团队合作中,为什么总有人“划水”摸鱼?
    4. 破窗效应 (Broken Windows Theory):环境中的一个小小失序,如何引发更大范围的混乱?
    5. 出丑效应 (Pratfall Effect):完美无缺,反而不如偶尔犯点小错的人受欢迎。
    6. 本杰明·富兰克林效应 (Ben Franklin Effect):想让别人喜欢你?试着让他帮你个小忙。
    7. 登门槛效应 (Foot-in-the-Door Technique):如何通过一个小请求,让别人答应你一个大请求?
    8. 留面子效应 (Door-in-the-Face Technique):先提个离谱要求再提真实目的,为何成功率更高?
    9. 皮格马利翁效应 (Pygmalion Effect):期望有多高,成就可能就有多大。
    10. 罗森塔尔效应 (Rosenthal Effect):权威的“谎言”,如何变成了现实?
    11. 首因效应 (Primacy Effect):第一印象为什么那么重要?
    12. 近因效应 (Recency Effect):最后一次的印象,如何覆盖你之前的全部努力?
    13. 群体思维 (Groupthink):为什么在优秀的团队里,大家会一起做出愚蠢的决定?
    14. 群体极化 (Group Polarization):为什么一群人讨论后,观点会变得更极端?
    15. 社会促进效应 (Social Facilitation):有旁观者在场,为何你的表现会更好(或更差)?
    16. 互惠原则 (Reciprocity):为什么吃了别人的小零食,就不好意思拒绝他的请求?
    17. 承诺与一致原则 (Commitment and Consistency):一旦做出公开承诺,我们为何会“一条道走到黑”?
    18. 社会认同原则 (Social Proof):排长队的餐厅,一定好吃吗?
    19. 喜好原则 (Liking):我们更容易被自己喜欢的人说服。
    20. 权威原则 (Authority):穿上白大褂,说话都更有分量。
    21. 稀缺原则 (Scarcity):“限量版”和“最后一天”的魔力在哪里?
    22. 吊桥效应 (Misattribution of Arousal):心跳加速,是因为爱,还是因为怕?
    23. 曝光效应 (Mere-Exposure Effect):为什么看得越多,就越喜欢?
    24. 约哈里窗 (Johari Window):四个窗户看清“公开的我、盲目的我、隐藏的我、未知的我”。
    25. 个人空间 (Personal Space):人与人之间的“安全距离”是多少?
    26. 镜像效应 (Chameleon Effect):我们会不自觉地模仿对方的动作和表情。
    27. 刻板印象威胁 (Stereotype Threat):担心自己会印证负面偏见,结果真的表现更差。
    28. 自我表露 (Self-Disclosure):适当暴露脆弱,能快速拉近关系。
    29. 焦点效应 (Focusing Effect):过分关注某个细节而忽略全局。
    30. “踢猫效应” (Kicking the Cat Effect):坏情绪的连锁传递。
      -110. (略)… 更多人际互动细节…

    三、情绪与动机 (50个)

    深入理解驱动我们行为的内在力量:情感、欲望和动力。

    1. 蔡格尼克记忆效应 (Zeigarnik Effect):为什么未完成的事和被打断的任务,总是让你念念不忘?
    2. 瓦伦达效应 (Wallenda Factor):越是患得患失、专注于负面结果,越容易搞砸事情。
    3. 习得性无助 (Learned Helplessness):经历几次失败后,为什么人会放弃所有努力?
    4. 心流 (Flow State):如何进入那种“物我两忘”的全神贯注状态?
    5. 享乐适应 (Hedonic Treadmill):为什么升职加薪的快乐总是那么短暂?
    6. 决策疲劳 (Decision Fatigue):为什么逛了一天街后,你什么都不想选了?
    7. 损失厌恶 (Loss Aversion):捡到100块的快乐,远远小于丢掉100块的痛苦。
    8. 选择悖论 (The Paradox of Choice):选择越多,为什么我们反而越不开心?
    9. 安慰剂效应 (Placebo Effect):强大的信念,如何能“无中生有”地产生疗效?
    10. 反安慰剂效应 (Nocebo Effect):消极的预期,真的能让人“病倒”。
    11. 叶克斯-多德森定律 (Yerkes-Dodson Law):压力与效率之间的“倒U型”关系。
    12. 情绪ABC理论 (ABC Theory of Emotion):让你难过的不是事情本身,而是你对事情的看法。
    13. 爱情三角理论 (Triangular Theory of Love):激情、亲密、承诺,你的爱情属于哪一种?
    14. 依恋理论 (Attachment Theory):你在亲密关系中的行为模式,可能源于童年。
    15. 恐惧管理理论 (Terror Management Theory):对死亡的恐惧,如何塑造了我们的文化和价值观?
    16. 延迟满足 (Delayed Gratification):著名的“棉花糖实验”告诉了我们什么?
    17. 内在动机与外在动机 (Intrinsic vs. Extrinsic):奖励,有时会扼杀真正的热爱。
    18. 过度辩护效应 (Overjustification Effect):给兴趣发“工资”,兴趣就可能消失。
    19. 自我决定理论 (Self-Determination Theory):自主、胜任、归属,满足幸福感的三大核心需求。
    20. 期望理论 (Expectancy Theory):动力 = (期望 × 工具 × 效价),如何科学激励自己?
    21. 目标设定理论 (Goal-Setting Theory):为何设定“明确而困难”的目标更有效?
    22. 情绪的“面部反馈假说” (Facial Feedback Hypothesis):强颜欢笑,真的能让你开心一点吗?
    23. 詹姆斯-兰格情绪理论 (James-Lange Theory):我们是因为哭所以悲伤,还是因为悲伤所以哭?
    24. 杏仁核绑架 (Amygdala Hijack):情绪突然失控,“大脑短路”是怎么回事?
    25. 情绪颗粒度 (Emotional Granularity):能准确描述情绪的人,情绪管理能力更强。
      … (略)
    26. 怀旧 (Nostalgia) 的心理功能:回忆过去为什么让人感觉温暖?

    四、自我、人格与成长 (45个)

    探索“我是谁”,以及如何成为更好的自己。

    1. 马斯洛需求层次理论 (Maslow’s Hierarchy of Needs):你的人生追求,目前处于哪个层级?
    2. 成长型思维 vs 固定型思维 (Growth vs. Fixed Mindset):你相信天赋,还是相信后天努力?
    3. 舒适区、学习区、恐慌区 (Comfort, Learning, Panic Zones):如何科学地跳出舒适区?
    4. 自我实现预言 (Self-fulfilling Prophecy):你的预言和期待,正在悄悄成真。
    5. 冒名顶替综合症 (Impostor Syndrome):为什么成功人士总觉得自己不够格,是个“骗子”?
    6. 心理防御机制 (Defense Mechanism):否认、投射、合理化……你在用哪种方式保护自己?
    7. 大五人格模型 (The Big Five Personality Traits):开放性、尽责性、外倾性、宜人性、神经质,你是哪种组合?
    8. MBTI十六型人格:它科学吗?为什么这么流行?
    9. 控制点理论 (Locus of Control):你觉得命运掌握在自己手中(内控),还是听天由命(外控)?
    10. 巴纳姆效应 (Barnum Effect):为什么你总觉得星座、算命和心理测试说得“特别准”?
    11. 自我效能感 (Self-Efficacy):建立“我能行”的信念有多重要?
    12. 韧性 (Resilience):如何从逆境和失败中快速恢复?
    13. 自我同情 (Self-Compassion):像对待朋友一样,善待失败的自己。
    14. 身份认同危机 (Identity Crisis):青春期的“我是谁”烦恼。
    15. 个人构念理论 (Personal Construct Theory):每个人都在用自己独特的“尺子”丈量世界。
      … (略)
    16. 心智化 (Mentalization):理解自己和他人行为背后心理状态的能力。

    五、学习、记忆与大脑 (40个)

    揭示大脑工作的秘密,掌握高效学习和记忆的方法。

    1. 巴甫洛夫的狗 (Pavlov’s Dogs):听到铃声就流口水?聊聊“经典条件反射”。
    2. 斯金纳箱 (Skinner Box):奖励和惩罚,如何塑造我们的行为?(操作性条件反射)
    3. 记忆的三个阶段:编码、存储和提取,你的记忆卡在哪一步?
    4. 舌尖效应 (Tip-of-the-Tongue Phenomenon):话到嘴边就是说不出来,急死人!
    5. 曼德拉效应 (Mandela Effect):为什么那么多人都拥有“错误的集体记忆”?
    6. 虚假记忆 (False Memory):你的记忆,真的可靠吗?甚至可以被植入。
    7. 间隔效应 (Spacing Effect):为什么死记硬背,不如分段复习效果好?
    8. 测试效应 (Testing Effect):最好的复习方式,其实是“自我测验”。
    9. 艾宾浩斯遗忘曲线 (Ebbinghaus Forgetting Curve):如何对抗遗忘?
    10. 睡眠对记忆的作用:为什么说“睡一觉就好了”是真的?
    11. 格式塔心理学 (Gestalt Psychology):整体大于部分之和,聊聊视觉错觉和顿悟。
    12. 心智地图 (Mental Map):你大脑里的城市地图,是怎样的?
    13. 酝酿效应 (Incubation Effect):百思不得其解时,不如先放一放,答案会“自己跳出来”。
    14. 谷歌效应 (Google Effect):有了搜索引擎,我们的大脑是不是变懒了?
    15. 序列位置效应 (Serial-Position Effect):为什么我们总能记住开头和结尾,却忘了中间?
      … (略)
    16. 神经可塑性 (Neuroplasticity):你的大脑,终身都在被重塑。

    六、职场与组织心理学 (40个)

    将心理学应用于工作场所,提升效率和满意度。

    1. 帕金森定律 (Parkinson’s Law):为什么工作总会自动膨胀,直到占满你所有的时间?
    2. 彼得原理 (The Peter Principle):为什么在公司里,很多领导都无法胜任自己的岗位?
    3. 霍桑效应 (Hawthorne Effect):为什么“被关注”就能提高员工的生产力?
    4. 手表定律 (Watch Law):一个人不能同时拥有两块标准不同的表,否则会无所适从。
    5. 鳄鱼法则 (Alligator Principle):当被鳄鱼咬住时,唯一能做的就是牺牲一只脚。谈谈及时止损。
      … (略)
    6. 玻璃悬崖 (Glass Cliff):为什么女性更容易在公司危难时被提拔到高位?

    七、消费与营销心理学 (35个)

    了解消费者决策背后的心理动机,洞悉营销的奥秘。

    1. 心理账户 (Mental Accounting):为什么工资赚的1000块不舍得花,中奖的1000块却很快花光?
    2. 禀赋效应 (Endowment Effect):为什么一旦拥有某个东西,我们对它的估值就会变高?
    3. 宜家效应 (IKEA Effect):为什么我们对自己亲手组装的(不完美的)家具评价更高?
    4. 凡勃伦效应 (Veblen Effect):商品定价越高,反而越畅销?炫耀性消费。
    5. 诱饵效应 (Decoy Effect):商家如何用一个“没人买”的选项,让你心甘情愿地选择更贵的那个?
      … (略)
    6. 品牌人格 (Brand Personality):你的品牌是“真诚的”还是“精致的”?

    八、经典实验与其他趣味现象 (45个)

    回顾那些奠定心理学基石的著名实验,探索更多有趣的心理现象。

    1. 波波玩偶实验 (Bobo Doll Experiment):孩子们的攻击行为,是从哪儿学来的?(观察学习)
    2. 斯坦福监狱实验 (Stanford Prison Experiment):好人是如何在特定环境中变坏的?
    3. 米尔格拉姆实验 (Milgram Experiment):面对权威,我们的服从底线在哪里?
    4. 阿施从众实验 (Asch Conformity Experiments):你会因为群体压力而说出明显的错误答案吗?
    5. 看不见的大猩猩实验 (The Invisible Gorilla):我们究竟会错过多少眼皮底下的东西?(非注意盲视)
    6. 棉花糖实验 (Marshmallow Test):自控力与未来成功的关系。
    7. 路西法效应 (The Lucifer Effect):情境如何让好人变成恶魔?
    8. 潜意识 (The Unconscious):冰山之下,隐藏着怎样的你?(弗洛伊德)
    9. 梦的解析 (Interpretation of Dreams):梦境是通往潜意识的皇家大道吗?
    10. 集体无意识 (Collective Unconscious):荣格提出的,那些隐藏在全人类基因里的神话和原型。
      … (略)
    11. 心理学能被证伪吗?:谈谈心理学的科学性与争议。
  • 谷歌注册新规:二维码验证陷阱与国内用户生存指南

    昨晚十点,我帮表弟注册谷歌账号。输完密码点"下一步",屏幕上跳出个二维码,配着一段让人云里雾里的提示。扫完码发了条短信,扣了一毛钱话费,然后页面告诉我"出了点问题,请重试"。我又扫了一遍,又发了一次,又扣了一毛钱,结果还是这四个字。连续试了五次,五毛钱没了,账号还是没注册成功。表弟看着我说:"哥,要不我还是用QQ邮箱吧。"那一刻我突然理解了什么叫科技以换着法儿折腾人为本


    谷歌这波操作把自己玩成了什么样

    2025年,谷歌悄悄干了件大事:把Gmail注册验证从传统的"收短信验证码"改成了"扫二维码+发短信验证"。这事儿在2月份就开始预热,到现在已经全面铺开。国外媒体纷纷报道,说这是为了提升安全性、防止钓鱼攻击。听上去很美好,实际用起来简直是场灾难。

    这套新流程到底有多离谱

    我给你还原一下整个注册过程:

    传统方式(已死)

    • 填写信息 → 输入手机号 → 收到6位验证码 → 输入验证码 → 注册成功 ✅

    新方式(地狱模式)

    1. 填写信息,设置密码
    2. 点"下一步",屏幕突然蹦出个二维码
    3. 系统来了段官腔:"在允许您继续操作前,Google需要验证一些与您的设备或电话号码有关的信息…"
    4. 拿出手机,打开相机扫码
    5. 跳转到一个页面,让你主动发送短信到谷歌指定的号码(比如12345)
    6. 发完短信,页面开始转圈 🔄
    7. 等几分钟,页面告诉你:"验证您的电话号码时出了点问题,请重试"
    8. 回到第3步,无限循环

    这还不是最骚的。最骚的是:手机端也跑不掉

    我以为换手机注册能绕过去,结果打开手机浏览器一看,还是要扫码,还是要发短信。谷歌这是把堵截线拉满了,PC端堵,移动端也堵。只要你敢注册,就让你体验一遍什么叫"花钱买罪受"。

    谷歌的官方说辞能骗谁

    谷歌发言人对《福布斯》表示,SMS短信验证不够安全,容易被钓鱼和SIM卡劫持攻击。这话听着有道理,但经不起推敲。

    你说短信不安全,那为什么新方案还要发短信?只不过从"谷歌发给你"变成了"你发给谷歌"。安全性没变,成本转嫁给了用户

    更搞笑的是,美国政府的技术标准机构早在2016年就建议淘汰短信验证,但谷歌这套"创新"方案,核心还是短信,只是加了个扫码的前戏。这就像有人告诉你:"吃垃圾食品不健康,所以以后要先做十个深蹲再吃。"健康了吗?并没有。但累了。

    验证方式对比 谁出钱 安全性 国内成功率 用户体验
    旧方案:收验证码 谷歌付短信费 中等 60% ⭐⭐⭐
    新方案:扫码发短信 用户付短信费 中等 不到10% ☠️
    理想方案:硬件密钥 用户买设备 90%+ ⭐⭐⭐⭐

    从这张表就能看出:谷歌这次升级,唯一的进步就是把短信成本转嫁给了用户


    国内手机号为什么全军覆没

    很多人以为是自己手机号的问题,其实不是。问题出在三个层面:

    1. 地理位置的悖论

    谷歌的验证逻辑有个硬性要求:注册IP地址和手机号归属地要一致

    这对国内用户就是个死结。你用的代理节点在美国,但手机号是+86中国大陆。谷歌的系统一看:"你人在洛杉矶,手机号在广州?可疑!"然后直接给你踢出去。

    "一个人的IP在旧金山,手机号在上海,谷歌会认为你不是一个正常的人类用户,而是某种企图钻空子的机器人。"

    这逻辑听着没毛病,但对合法用户来说就是无解的困境。

    2. 短信验证的国际黑洞

    即使你的IP和手机号碰巧对得上,第二个坑在等着你:国际短信发送的不稳定性

    从中国移动/联通/电信的网络,发短信到谷歌在海外的验证服务器,这中间要经过:

    • 国内运营商的国际网关
    • 海底光缆
    • 国外运营商的接收系统
    • 谷歌的验证服务器

    任何一个环节出问题,短信就石沉大海。而谷歌给的判定时间只有2-3分钟。超时?对不起,"出了点问题,请重试"。

    3. 号码污染的连坐制

    如果你的手机号之前被别人注册过谷歌账号(比如买的二手号码),或者你自己已经用这个号码注册过多个账号,谷歌会直接把这个号码拉入黑名单。

    我有个朋友,手机号用了十年,中间注册过三个谷歌账号。今年想再注册一个,怎么试都不行。最后换了张新办的卡,一次就过了。这说明什么?谷歌的风控系统会记住每个号码的"污染程度"


    为什么连老外都在骂娘

    这套新验证机制推出后,不光国内用户抓狂,连国外用户都炸了锅。

    在科技新闻网站Ghacks的评论区,有用户吐槽:"我用的是老人机,根本没法扫二维码。难道注册个邮箱还要强制绑定智能手机?"

    还有人更直白:"QR code is the worst thing ever done to security"(二维码是安全领域有史以来最糟糕的发明)。

    设备绑架的真相

    谷歌美其名曰"安全升级",但明眼人都看得出来:这是在强制绑定移动设备

    以前你可以在任何一台电脑上注册谷歌账号,只要能收短信就行。现在呢?必须有智能手机,必须能扫码,必须能上网发短信。这三个"必须",把一大批用户挡在了门外:

    • 📵 用老人机的中老年人
    • 💻 只有电脑没有智能手机的学生
    • 🌍 在网络环境受限地区的人

    更关键的是,扫码意味着谷歌可以获取你的:

    • 设备型号
    • 操作系统版本
    • IP地址
    • 扫码时间
    • 地理位置(如果你开了定位)

    这些数据的价值,远远超过一次注册验证的需求。所以别跟我说这是为了安全,这是为了数据。

    印度裔CEO的小算盘?

    还有个更隐秘的阴谋论。谷歌现任CEO桑达尔·皮查伊(Sundar Pichai)是印度裔。有人发现,把浏览器语言改成"英语(印度)"后,注册成功率明显提升。改成"英语(美国)"?还是老样子,卡得死死的。

    这可能只是巧合,也可能是谷歌的地区化策略。但不管怎么说,中文用户和中国IP在谷歌的风控体系里,显然不是优先级最高的那一档


    普通人还能怎么办

    说了这么多问题,总得给点解决方案。我这几天测试了十几种方法,筛选出几个成功率相对高的:

    方法一:移动端+干净网络

    成功率:30-40%
    难度:⭐⭐⭐

    具体步骤:

    1. 卸载电脑端的谷歌浏览器(如果有注册记录)
    2. 用手机浏览器(Safari或Chrome)打开https://accounts.google.com
    3. 确保代理节点干净(没被大量人用来注册过)
    4. 浏览器语言改成英语(印度)英语(新加坡)
    5. 注册时选择"跳过手机验证"(偶尔会出现这个选项)
    6. 如果跳不过,用新办的手机号验证

    为什么语言设置重要?
    谷歌的后台会根据你的浏览器语言判断你的地区。设置成印度英语,谷歌会认为你是印度用户,而印度是谷歌的重点市场,风控相对宽松。

    方法二:时间差突击

    成功率:20-30%
    难度:⭐⭐

    凌晨3点到5点,这个时间段谷歌服务器负载低,验证系统的阈值会稍微放宽。我有两次成功注册都是在凌晨4点左右。

    可能的原因:

    • 这个时间段注册人数少,系统判定机器人的概率降低
    • 服务器资源充足,验证速度快
    • 风控系统的某些检测机制在非高峰期会降低敏感度

    方法三:虚拟号码接码

    成功率:50-60%(但有风险)
    难度:⭐⭐⭐⭐

    网上有很多临时手机号服务,比如:

    • 国外的接码平台(某些需要付费)
    • 虚拟运营商的号码

    但这种方法有三个大坑:

    ⚠️ 风险一:这些号码可能已经被别人用来注册过,谷歌直接拒绝
    ⚠️ 风险二:注册成功后,号码失效,你的账号可能被锁定
    ⚠️ 风险三:有些接码平台本身就是钓鱼网站

    所以我不推荐新手用这招,除非你真的走投无路。

    方法四:找个已有账号的人帮忙

    成功率:80%+
    难度:⭐

    这是目前最靠谱的方法。如果你有朋友已经有谷歌账号,可以让他在自己的设备上帮你注册一个新账号。

    为什么这样成功率高?

    • 他的设备已经被谷歌"信任"
    • 他的IP和浏览器指纹是干净的
    • 谷歌会认为这是一个"老用户推荐新用户"的场景,风控门槛更低

    注册完成后,修改密码和辅助邮箱,这个账号就是你的了。

    实在不行的备选方案

    如果上面所有方法都试过了,还是注册不了,那就别跟谷歌死磕了。现在有很多替代品:

    替代服务 优势 劣势
    Outlook邮箱 微软出品,注册简单 国内访问有时会慢
    ProtonMail 隐私保护极佳 免费版容量有限
    Zoho Mail 支持中文,企业邮箱友好 知名度不如Gmail
    iCloud邮箱 苹果生态无缝 必须有Apple ID

    说实话,除了某些服务只支持Gmail登录,其他邮箱也没差多少。别为了一个谷歌账号折腾半个月,不值当。


    这场闹剧背后的逻辑

    谷歌这次改革,表面上是为了安全,实际上是三个目的的综合体:

    目的一:降低运营成本
    以前每发一条验证短信,谷歌要付钱给电信运营商。全球每天新增几百万Gmail用户,这是笔不小的开支。现在让用户自己发短信,成本转嫁了。

    目的二:收集设备数据
    扫二维码意味着要用移动设备,谷歌可以借此获取设备指纹、型号、系统版本等信息。这些数据对广告投放和用户画像极其重要。

    目的三:提高注册门槛
    大量机器人账号一直是谷歌的心腹大患。提高注册难度,可以筛掉一部分滥用账号。但代价是误伤了无数普通用户。

    这三个目的都有道理,但问题是:谷歌在追求这些目标的时候,完全没考虑用户体验。或者说,他们觉得自己够大,可以不用考虑。

    垄断者的傲慢

    微软、苹果、Facebook都在逐步淘汰SMS验证,改用更安全的方式。但他们的做法是:

    • 微软:推广Microsoft Authenticator,但保留短信选项
    • 苹果:推广Face ID/Touch ID,但不强制
    • Discord:早就用QR code登录,但是在已登录设备上扫码验证,而不是让新用户发短信

    只有谷歌,搞了个"扫码+发短信"的缝合怪,既不方便,又不安全,还要用户自己掏钱。

    这就是垄断者的傲慢。他们知道你没得选,所以可以肆无忌惮地折腾你。


    给未来的一点建议

    如果你现在还没注册谷歌账号,我给你三个建议:

    1. 不要在高峰期注册
    工作日白天,全球注册量最大,谷歌的风控系统最严格。选凌晨或周末试试。

    2. 准备至少2个手机号
    第一个号码失败后,别急着用第二个。等24小时,换个IP再试。

    3. 降低期待
    别指望一次成功。我认识的人里,一次注册成功的不到三成。大部分人都是试了三五次才过。

    如果你已经有谷歌账号,我给你一个建议:

    保护好这个账号,启用两步验证,绑定多个辅助邮箱和手机号。因为一旦丢失,你可能再也注册不回来了。


    晚上十一点,我表弟发来消息:"哥,我今天用新卡注册成功了!"

    我问他:"花了多长时间?"

    他说:"试了七次,两天,五块钱话费。"

    我说:"恭喜你,你现在有Gmail邮箱了。"

    他说:"但我感觉我失去的比得到的多。"

    我想了想,回复:"欢迎来到2025年的互联网。"

    这个时代,注册个邮箱要看运气,验证个手机要碰概率,想用个服务要学会十八般武艺。科技公司们打着安全的旗号,把简单的事情搞得无比复杂,然后告诉你这是为了你好。

    而我们这些用户,只能在无数次失败后,学会接受这套荒诞的规则。或者,找到它的漏洞。

    毕竟这个世界上,没有完美的系统,只有更狡猾的用户。💪

  • 零基础部署 Gemini Balance(SQLite 版)到 ClawCloud,超简单!

    这篇文章是给不懂代码也能上手的朋友写的,手把手教你怎么把 Gemini Balance 部署到 ClawCloud 上,选的是 SQLite 版本,轻量好用,配置也不复杂。

    file

    重点来了,现在免费的gooogle gemini api 每一个key都有免费的gemini pro模型的额度,你可以咸鱼买N个key部署在你的Gemini Balance里,实现免费额度。配合gemini cli,写东西真的无敌了。

    配合gemini cli 你可以参考我的这篇文章

    Windows 和 Terminal下配置 Gemini API 环境变量教程(含一键启动命令)

    🧩 一、准备工作

    ✅ 注册 ClawCloud 账号

    • 打开 ClawCloud Run 官网
    • 点「免费入门」,用 GitHub 登录
    • 注意:GitHub 账号得注册超过 180 天

    如果你的 GitHub 太新了,可以:

    • 换个部署方式
    • 或者淘宝买个老号(大概 10 块钱)

    🚀 二、开始部署

    🌍 选服务器区域

    file

    • 登录后,点左上角「Region」
    • 推荐选「日本」,请看清楚,推荐是日本,不要选新加坡了
      ps:我现在使用的是日本节点,测试国内不加梯子可以正常使用,新加坡节点过于热门可能导致部署失败。

    🧱 创建应用

    进入「App Launchpad」,点右上角「Create App」。

    file

    file

    然后按下面这样填:

    file

    项目 内容
    应用名称 geminibalance
    镜像地址 ghcr.io/snailyp/gemini-balance:latest
    用法 Fixed
    副本 1
    CPU 1
    内存 512MB
    端口 8000
    Internet 打开 Access ✅

    ⚙️ 三、配置环境变量(重点!)

    file

    点「Add」,把这些变量加进去:

    DATABASE_TYPE=sqlite
    SQLITE_DATABASE=default_db
    API_KEYS=["your-gemini-api-key-1","your-gemini-api-key-2"]
    ALLOWED_TOKENS=["your-access-token-1","your-access-token-2"]
    AUTH_TOKEN=sk-123456
    TZ=Asia/Shanghai

    点击下面的storage

    file

    小贴士:

    • SQLITE_DATABASE 必填,不填就部署失败
    • API_KEYSALLOWED_TOKENS 可以先随便填,后面再改
    • AUTH_TOKEN 是管理员密码,建议一开始就设置好

    📦 四、部署上线

    • 配置完环境变量后,点页面上方「Deploy Application」
    • 弹窗出来点「Yes」
    • 页面跳转后,左上角显示 running 就说明部署成功了

    如果不是 running,等几分钟或者检查下配置有没有填错


    🌐 五、获取公网地址

    • 页面底部「Network」区域能看到公网地址
    • 如果显示 pending,等个 2–5 分钟
    • 有时候 pending 状态也能访问,可以试着打开看看
    • 超过 10 分钟还不行,建议换个区域或者重新部署

    🔗 六、绑定自己的域名(可选)

    • 去 Cloudflare 添加 CNAME 记录
    • 比如你想用 ggg.abc.xyz,就把它指向 ClawCloud 的公网地址
    • 前提是你的域名已经托管在 Cloudflare

    📊 七、配置监控面板

    • 打开公网地址,进入登录界面
    • 默认密码是你设置的 your-access-token-1
    • 登录后可以改 API 密钥和访问令牌
    • 改完记得点「保存配置」

    🧪 八、接入工具(以 Cherry Studio 为例)

    添加提供商

    file

    项目 内容
    名称 随便填
    API 密钥 用你设置的访问令牌
    API 地址 ClawCloud 的公网地址(不要加 /

    添加模型

    file

    • 点「管理」→「添加模型」
    • 添加完就能用了!

    ❓ 九、常见问题

    密码输错了?

    • 如果你用的是旧数据库,密码就是旧的那个
    • 环境变量里改了密码没用,数据库里保存的是初始化时的密码
    • 想用新密码?那就得换个新数据库重新部署

    ✅ 总结一下

    整个流程其实不复杂,照着一步步来就能搞定。

  • Gemini Balance:开源API负载均衡代理服务完全指南

    上个月,我的一个朋友在凌晨两点给我打电话,说他的Gemini API又炸了。这已经是这周第三次。他做了个小工具,用Gemini API给用户提供AI对话服务,结果流量一上来,API就开始各种报错、超时、限流。"有没有什么办法能让我不用半夜爬起来切换API Key?"他在电话里问我。我说有,开源社区早就有人想到这个问题了。

    file

    当API成为生产力工具时,稳定性就成了刚需

    说实话,Google的Gemini API本身挺好用的。模型能力强,价格也不算离谱,对于个人开发者和小团队来说是个不错的选择。但问题在于,任何API服务都有限流、都有配额、都可能出错

    当你只是写个Demo玩玩,这些都不是问题。但一旦你把它用到了真实业务场景——哪怕只是一个小小的Chrome插件,或者一个几百人用的Telegram Bot——这些"偶尔出现"的问题就会变成"经常困扰"你的麻烦。

    用户可不管你是不是超配额了,他们只知道:我点了按钮,你没给我响应 😤

    这就是gemini-balance这个项目存在的意义。它不是要重新发明轮子,而是在Google官方API的基础上,加了一层更聪明的代理层

    它到底解决了什么问题?

    让我用最直白的话说:

    • 多个API Key自动轮询:你有5个Key,它会自动帮你轮流用,一个不行换下一个
    • 失败自动重试:请求失败了?没关系,它会重试,还会自动禁用坏掉的Key
    • 双协议兼容:既支持Gemini原生格式,也支持OpenAI格式,你的老代码不用改
    • 可视化管理界面:不用改配置文件,网页上点几下就能管理所有Key
    • 详细的监控日志:每个Key的状态、请求成功率,一目了然

    这些功能听起来很基础,但恰恰是最实用的那种基础。就像你买车,ABS和安全气囊看起来不起眼,但真遇到事儿的时候,能救命。

    从安装到运行:没有你想象的那么复杂

    我知道,很多开发者一看到"需要部署"、"需要配置环境"这些字眼就头大。但这个项目的部署流程,真的算是我见过最友好的那一批了。

    Docker一键启动(推荐)

    如果你用Docker,整个过程不超过五分钟:

    # 拉取镜像
    docker pull ghcr.io/snailyp/gemini-balance:latest
    
    # 准备配置文件
    cp .env.example .env
    # 编辑.env,填入你的API Keys和Token
    
    # 启动容器
    docker run -d -p 8000:8000 \
      --name gemini-balance \
      -v ./data:/app/data \
      --env-file .env \
      ghcr.io/snailyp/gemini-balance:latest

    三条命令,服务就跑起来了。访问http://localhost:8000,你就能看到管理界面。

    项目同时支持AMD64和ARM架构,也就是说无论你是用X86服务器还是树莓派,都能跑。这点很贴心,因为现在越来越多人开始用ARM架构的云服务器(便宜啊)💰

    本地开发部署

    如果你想自己折腾源码,也很简单:

    git clone https://github.com/snailyp/gemini-balance.git
    cd gemini-balance
    pip install -r requirements.txt
    uvicorn app.main:app --host 0.0.0.0 --port 8000 --reload

    整个项目是用Python + FastAPI写的,代码结构很清晰。如果你想二次开发,完全可以。

    配置文件里的学问:每一项都有存在的理由

    .env配置文件看起来选项很多,但分类其实很明确。我挑几个最关键的说说:

    核心配置

    配置项 说明 为什么重要
    API_KEYS Gemini API密钥列表 这是整个系统的弹药库,支持批量添加
    ALLOWED_TOKENS 访问令牌列表 防止你的代理被别人白嫖 🔒
    AUTH_TOKEN 超级管理员令牌 管理后台的钥匙
    MAX_FAILURES 单个Key最大失败次数 默认3次,超过就自动禁用
    MAX_RETRIES 请求失败最大重试次数 默认3次,提高成功率

    重点说说API_KEYS这一项。项目支持用正则表达式批量添加密钥,而且会自动去重。这意味着你可以直接把一堆Key扔进去,不用担心重复或者格式问题。

    数据库选择

    项目支持两种数据库:

    • SQLite:适合个人使用,零配置
    • MySQL:适合多用户场景,性能更好

    如果你只是自己用,SQLite完全够了。但如果你要给团队用,或者请求量比较大,建议用MySQL。配置也很简单,就是填几个连接参数而已。

    高级功能

    这个项目不只是个简单的代理,它还集成了一些很实用的功能:

    图片生成和上传 🎨
    配置CREATE_IMAGE_MODEL和上传服务提供商(SM.MS、PicGo或CloudFlare),就能让Gemini生成的图片自动上传到图床,返回外链。这对做聊天机器人的场景特别有用。

    Web搜索增强 🔍
    通过SEARCH_MODELS配置,可以让指定的模型具备联网搜索能力。调用时只需在模型名后加-search后缀,比如gemini-2.0-flash-exp-search

    TTS语音合成 🎤
    项目甚至还支持文字转语音功能,可以配置语音模型、说话人和语速。这个功能很多人可能不知道Gemini也能做。

    流式输出优化
    开启STREAM_OPTIMIZER_ENABLED后,可以让流式响应更平滑。这对用户体验很重要——没人喜欢看到文字一次性蹦出来或者卡顿。

    两套API格式:老项目不用改代码

    这是我最欣赏这个项目的一点:完全兼容OpenAI的API格式

    什么意思呢?假设你之前写了一个调用OpenAI API的项目,现在想换成Gemini来省钱或者试试新模型,你需要改多少代码?

    答案是:只需要改Base URL

    # 原来的OpenAI调用
    client = OpenAI(
        base_url="https://api.openai.com/v1",
        api_key="sk-..."
    )
    
    # 换成Gemini Balance,其他代码一行不改
    client = OpenAI(
        base_url="http://localhost:8000/openai/v1",
        api_key="你的ALLOWED_TOKEN"
    )

    项目提供了三套路由:

    Gemini原生格式/v1beta/models
    HuggingFace格式/hf/v1
    OpenAI格式/openai/v1(推荐)

    最常用的几个API都支持:

    • GET /models – 列出可用模型
    • POST /chat/completions – 对话补全
    • POST /embeddings – 文本向量化
    • POST /images/generations – 图片生成

    而且,项目会自动同步最新的模型列表。Gemini每次发布新模型,你不用手动更新配置,系统会自己去拉取。这个细节很贴心,因为Google最近发新模型的频率还挺高的。

    监控和管理:你需要知道系统在干什么

    生产环境最怕的是什么?是出了问题你不知道,或者知道了但找不到原因

    gemini-balance在这方面做得很细致:

    密钥状态页面

    访问/keys_status(需要认证),你能看到:

    • 每个API Key的状态(启用/禁用)
    • 累计使用次数
    • 失败次数
    • 最后使用时间
    • 当前限流状态

    这个页面是实时更新的。如果某个Key突然失效了,你一眼就能看出来。

    日志系统

    项目的日志分两类:

    1. 请求日志:记录每次API调用的详细信息
    2. 错误日志:记录所有异常和失败

    而且可以配置自动删除过期日志,默认错误日志保留7天,请求日志保留30天。这样不会让磁盘被日志撑爆,又能保留足够长的追溯期。

    如果你想排查问题,可以把LOG_LEVEL调成DEBUG,会输出更详细的信息。

    定时任务

    系统有个后台定时任务,每隔一定时间(默认1小时)会重新检查被禁用的Key

    为什么要这么做?因为有些错误是暂时性的——比如超过配额上限,过了一个小时配额刷新了,Key就又能用了。自动重试机制能让系统具备一定的"自愈"能力。

    性能和稳定性:经得起实战检验

    说了这么多功能,但最终还是要回到最本质的问题:它靠谱吗?

    我自己测试了一段时间,也看了GitHub上其他用户的反馈,可以说几点:

    并发处理能力不错 👍
    FastAPI本身就是为高并发设计的异步框架,再加上负载均衡机制,处理几百个并发请求没什么压力。当然,最终瓶颈还是在Gemini API那边。

    失败恢复很快
    如果一个Key暂时不可用,系统会立即切换到下一个,整个过程用户几乎感知不到。而且重试机制比较激进(默认最多3次),大部分暂时性错误都能被自动处理掉。

    资源占用低
    我在一台1核2G的VPS上跑过,CPU和内存占用都很低。如果用SQLite,磁盘IO也不会成为瓶颈。

    错误提示清晰
    遇到问题时,日志会明确告诉你是哪个Key、什么请求、什么错误。这对于快速定位问题非常重要。

    不过也有些需要注意的地方:

    • 如果你的Key都被Google限流了,代理也救不了你 😅
    • 图片上传功能依赖第三方图床,稳定性取决于图床本身
    • 大流量场景建议用MySQL,SQLite可能会出现锁等待

    代码质量和社区氛围

    从GitHub仓库来看,这个项目维护得还不错:

    • 代码结构清晰:按照FastAPI的标准项目结构组织,router、service、domain分层明确
    • 文档比较详细:README写得很用心,配置项都有说明
    • 持续更新:作者一直在修bug和加新功能
    • 开源协议合理:使用CC BY-NC 4.0协议,允许非商业使用和修改

    作者在README里明确声明禁止商业转售服务,这个态度我挺赞同的。开源是为了让更多人受益,而不是让某些人拿去做生意却不回馈社区。

    项目也提供了赞助链接(爱发电),如果你觉得好用,可以请作者喝杯咖啡 ☕

    谁适合用这个项目?

    在我看来,以下几类人会觉得这东西很有用:

    1. 个人开发者
    你有好几个Gemini API Key(可能是不同账号的),想统一管理和负载均衡,同时希望兼容OpenAI的客户端代码。

    2. 小团队
    团队里多个人都要用Gemini API,但不想每个人都管理自己的Key,希望有统一的入口和使用统计。

    3. 做聊天机器人的
    需要Gemini的多模态能力(文本+图片),又需要稳定性保障,不能让用户看到各种错误信息。

    4. 想省API费用的
    通过负载均衡机制,可以更充分地利用每个Key的免费额度,延迟达到付费阈值的时间。

    5. 有二次开发需求的
    代码写得挺规范的,如果你想加点自己的业务逻辑,改起来不会太痛苦。

    当然,如果你只是偶尔调用几次API,或者流量非常小,直接用官方API就行了,不用搞这么复杂。

    可能的改进方向

    没有什么项目是完美的,这个也一样。如果我是作者,可能会考虑加这些功能:

    更智能的负载均衡策略
    现在是简单的轮询,可以考虑根据每个Key的响应时间、成功率来动态调整权重,让快的Key多干活。

    Key的使用配额统计
    能看到每个Key还剩多少配额就更好了,这样可以提前知道什么时候需要加新Key。

    Webhook通知
    当Key失效或者系统出现严重错误时,能通过Webhook或者邮件通知管理员。现在只能靠你主动去看监控页面。

    前端管理界面优化
    现在的管理界面比较简陋,如果能做得更友好一些,加点图表什么的,体验会更好。

    更多图床支持
    目前只支持三种图床,可以再加点阿里云OSS、七牛云这种大厂的对象存储服务。

    不过话说回来,这些都是锦上添花的东西。就现在的功能,已经能满足大部分场景了。


    我那个朋友后来用上了这个项目,现在晚上能睡个安稳觉了。他说最大的感受就是省心——以前每次API出问题都要手动处理,现在系统自己就搞定了。

    这可能就是好工具的标准:它不会让你感到它的存在,但少了它你会很痛苦

    如果你也有类似的需求,不妨试试这个项目。开源世界最美好的地方就在于,总有人会想到和你一样的痛点,并且把解决方案免费分享出来。而你需要做的,就是站在巨人的肩膀上,继续往前走。

    或者,如果你有更好的想法,也可以给项目提PR。这才是开源精神该有的样子 🚀

  • Docker容器网络互通配置指南:从连接拒绝到定位真凶

    凌晨三点,我对着屏幕上那行 Connection refused 发呆。两个Docker容器,明明都在同一台机器上,却像失联了一样无法通信。我打开第六罐红牛,心想这事儿不应该这么复杂。事实证明,它确实不复杂,只是藏了很多坑等着你往里跳。🌃

    问题的起点:两个世界的容器

    看起来很简单的需求

    我要做的事情听起来直白:让 LangBot 和 WeChatPadPro 两个服务互相通信。一个负责AI对话,一个对接微信消息,逻辑上它们应该是天然的搭档。

    但现实给了我一巴掌。这两个服务分别跑在不同的 docker-compose 项目里,它们之间的距离,比我想象的要远。

    第一次尝试的错误是这样的:

    HTTPConnectionPool(host='127.0.0.1', port=1238): Max retries exceeded
    Connection refused

    我检查了端口占用,看了防火墙规则,确认服务在运行。一切看起来都正常,但就是连不上。就像你明明看见对方在线,消息就是发不出去,对方也收不到。

    Docker重新定义了"本地"

    在没有容器的时代,127.0.0.1 就是本机,同一台机器上的服务通过端口就能互相访问。Docker改变了这个规则

    每个容器都是一个独立的运行环境。当你在容器内部访问 127.0.0.1 时,你访问的是容器自己,不是宿主机,更不是其他容器。这就像你站在自己房间里喊"有人吗",隔壁邻居是听不见的。

    更麻烦的是,不同的 docker-compose 项目会创建各自的网络:

    # WeChatPadPro 项目创建的网络
    deploy_wechatpadpro-network
    
    # LangBot 项目创建的网络  
    docker_langbot-network

    这两个网络就像两条平行线,永远不会相交。除非你做点什么。🔌

    配置过程:一场细节的战争

    第一步:创建一座桥梁

    解决方案的核心思路是:创建一个外部网络,让两个项目的容器都加入进来

    docker network create langbot-network

    这个命令创建了一个独立于任何项目的网络。它不属于 WeChatPadPro,也不属于 LangBot,它是中立的公共区域。

    如果执行时提示网络已存在,说明之前创建过,直接用就行:

    Error response from daemon: network with name langbot-network already exists

    这不是错误,反而是好消息——网络已经在那里了。

    第二步:修改 WeChatPadPro 配置

    打开 docker-compose.yml,找到网络配置部分。这里是最容易出错的地方

    错误的写法:

    networks:
      langbot-network:
        driver: bridge  # ❌ 这会创建新网络,不是使用外部网络

    正确的写法:

    networks:
      wechatpadpro-network:
        driver: bridge
      langbot-network:
        external: true  # ✅ 标记为外部网络

    然后在服务配置里指定网络:

    services:
      wechatpadpro:
        networks:
          - wechatpadpro-network  # 内部网络,访问数据库
          - langbot-network       # 外部网络,对外通信
    
      mysql:
        networks:
          - wechatpadpro-network  # 只在内部网络
    
      redis:
        networks:
          - wechatpadpro-network  # 只在内部网络

    注意这个设计:MySQL 和 Redis 只在内部网络,外部容器无法直接访问它们。这是有意为之的安全设计。

    第三步:修改 LangBot 配置

    同样的道理,修改 LangBot 的配置:

    services:
      langbot_plugin_runtime:
        networks:
          - langbot-network
    
      langbot:
        networks:
          - langbot-network
    
    networks:
      langbot-network:
        external: true  # 不能少这行

    关键点:网络名必须完全一致。langbot-networklangbot_network 是两个不同的网络,连字符和下划线的差异会让你的配置彻底失效。

    第四步:重建容器

    配置改完要生效,必须重建容器:

    # WeChatPadPro 目录
    docker-compose down
    docker-compose up -d
    
    # LangBot 目录
    docker-compose down  
    docker-compose up -d

    启动时注意观察日志。正确的日志应该是:

    Network langbot-network  External  ✓

    如果看到这样的日志:

    Network deploy_langbot-network  Created  ✗

    说明配置还是错的,Docker 又创建了一个新网络,而不是使用外部网络。

    第五步:验证网络

    检查网络中的容器:

    docker network inspect langbot-network

    应该看到输出里包含三个容器:

    • wechatpadpro
    • langbot
    • langbot_plugin_runtime

    然后测试连通性:

    docker exec -it wechatpadpro ping langbot

    能 ping 通就说明网络配置成功了。如果报错 ping: executable file not found,不用担心,这只是镜像里没装 ping 工具,不代表网络不通。换个方式:

    docker exec -it langbot curl http://wechatpadpro:8080

    那些让人抓狂的细节

    127.0.0.1 的惯性思维

    LangBot 的配置文件里最初写的是:

    wechatpad_url: http://127.0.0.1:1238

    在容器里,这个地址指向的是容器自己,不是 wechatpadpro。必须改成容器名

    wechatpad_url: http://wechatpadpro:1238

    Docker 的内置 DNS 会自动解析容器名到对应的 IP。这是容器间通信的标准做法。

    external: true 的必要性

    如果配置文件里只写:

    networks:
      langbot-network:
        driver: bridge

    Docker 会认为这是一个项目内的网络,会创建一个带项目前缀的新网络,比如 deploy_langbot-network

    只有明确标记 external: true,Docker 才会去寻找已存在的外部网络:

    networks:
      langbot-network:
        external: true

    这一行,不能省。

    网络名称的字符陷阱

    Docker 网络名区分大小写,也区分连字符和下划线:

    网络名 是否相同
    langbot-network 基准
    Langbot-Network ❌ 不同(大小写)
    langbot_network ❌ 不同(下划线)
    langbot-network ✅ 相同

    我就在这个细节上卡了半小时。两个配置文件,一个用连字符,一个用下划线,看起来差不多,但 Docker 认为它们是两个完全不同的网络。

    容器重启的必要性

    修改 docker-compose.yml 后,必须重建容器才能生效。简单的 docker-compose restart 是不够的,因为网络配置在容器创建时就确定了。

    必须用:

    docker-compose down  # 删除容器
    docker-compose up -d  # 重新创建

    从网络问题到应用问题

    错误信息的进化

    配置完网络后,我以为一切搞定了。但 LangBot 还是报错:

    500 Server Error: Internal Server Error for url: 
    http://wechatpadpro:1238/login/GetLoginStatus

    但这次的错误性质变了

    • 之前是 Connection refused —— 网络不通
    • 现在是 500 Server Error —— 网络通了,但接口报错

    这说明网络层面已经没问题了,问题转移到了应用层。

    WeChatPadPro 的真正问题

    查看 wechatpadpro 的日志:

    docker logs wechatpadpro --tail=50

    发现了真相:

    GET Connection locfree Failed by e36bdea0-f39a-4252-8fdc-913cf026e535
    ❌ 登录过程中发生panic
    ❌ 用户登录失败
    登录初始化完成: 0/1 用户成功登录

    原来问题不在网络,而在微信登录失败。WeChatPadPro 服务本身启动了,但微信账号没有成功登录,所以接口返回 500 错误。

    分层排查的重要性

    这个过程给我的启示是:问题要分层看

    层级 问题表现 排查方法
    网络层 Connection refused 检查网络配置、容器连通性
    应用层 500/404 等HTTP错误 查看应用日志、检查服务状态
    业务层 逻辑错误、数据异常 检查配置、验证业务流程

    我的问题经历了这样的演进:

    1. 网络层:Connection refused → 配置外部网络解决
    2. 应用层:500 Server Error → 需要先完成微信登录

    网络通了不代表服务能用,这是两个层面的问题。

    未解决的部分

    当前的状态

    截至现在:

    • ✅ Docker 网络配置正确
    • ✅ 容器间可以互相访问
    • ✅ LangBot 能够请求 WeChatPadPro 的接口
    • ❌ WeChatPadPro 的微信登录失败
    • ❌ 整个服务链路还没跑通

    问题从"网络不通"变成了"服务未就绪"。这是进步,但还没到终点。

    下一步要做的事

    根据 WeChatPadPro 的文档,需要:

    1. 访问 Swagger UIhttp://localhost:8080
    2. 填入 adminKey:从日志中获取
    3. 获取 token:调用 /admin/GanAuthKey 接口
    4. 扫码登录微信:调用 /login/GetLoginQrCodeNew 接口
    5. 在 LangBot 中配置:填入正确的 token 和 wxid

    这些步骤都是业务层面的操作,和 Docker 网络无关了。但如果网络不通,连这些步骤都无法开始。

    真实的技术工作

    技术工作就是这样。你解决了一个问题,往往会发现另一个问题。问题不会消失,只会转移

    网络配置花了我两个小时,定位到微信登录问题又花了一个小时。但至少现在我知道:

    • 网络没问题
    • Docker 配置没问题
    • 问题在 WeChatPadPro 的业务层

    这就够了。定位问题比解决问题更重要,因为只有知道问题在哪儿,才能知道该往哪儿使劲。💪

    配置检查清单

    如果你遇到类似的 Docker 网络问题,按这个清单检查:

    网络配置

    • [ ] 创建了外部网络 docker network create xxx
    • [ ] 两个 docker-compose.yml 的网络名完全一致
    • [ ] 网络配置都标记了 external: true
    • [ ] 服务配置中引用了正确的网络名

    容器状态

    • [ ] 执行了 docker-compose downup -d
    • [ ] 启动日志显示 External 而不是 Created
    • [ ] 用 docker ps 确认所有容器都在运行
    • [ ] 用 docker network inspect 确认容器在同一网络

    应用配置

    • [ ] 配置文件里用容器名替换了 127.0.0.1
    • [ ] 端口号正确(容器内部端口,不是映射的宿主机端口)
    • [ ] 相关的 token、密钥等配置正确

    验证方法

    • [ ] docker exec 能在容器间通信
    • [ ] 接口返回的是业务错误而非连接错误
    • [ ] 查看了双方容器的日志

    当网络层通了但服务还不工作时,停止折腾网络配置,去看应用日志。别在已经解决的问题上继续浪费时间。


    天快亮了,外面传来早班公交车的声音。问题还没完全解决,但至少知道了问题在哪儿。有时候技术工作就是这样,你花大半夜时间,可能只是排除了一个方向,定位到了真正的问题。

    但这就是进步。从漫无目的的摸索,到明确知道下一步要做什么,这就是价值。🌅

    网络通了,剩下的就是业务问题了。那是另一个故事,也是明天的工作。现在,我需要睡觉。