DaShen.Wang

快讯

• 操蛋的CRS：透明世界的牢笼、加密资产的囚徒与被迫暴露的普通人

  夜里便利店的灯光亮得刺眼，一个男人趴在柜台上，对店员抱怨他的海外账户又被要求补资料。他说自己不过是把辛苦赚来的钱挪个地方，没想到国家比他妈还关心他的钱去哪了。店员点点头，像是听懂了，却又像是在想明天的班表。 那一刻我发现，现代人的隐私不是丢了，而是被制度按着头塞进透明袋子里。袋子外的人都能看见，唯独袋子里的你，看不见任何人。

  ---

  透明世界的铁窗：CRS如何从天而降

  CRS（Common Reporting Standard）听上去像某种改善世界的和平公约，仿佛只要加入它，国家与国家就能手牵手共建公平社会。

  但它真正的意思是：

  你的金融信息将被自动、定期、无条件地共享给你从未见过的税务官。

  CRS不是来征求你意见的，它像一种“不接受反对”的协议，宣布你所有的金融账户从此将被摆上显微镜。

  CRS是什么？制度制定者说得很好听：

  • 打击跨国逃税
  • 促进透明
  • 维护公平
  • 建设更健康的金融秩序

  可普通人的感受往往只有一句：

  我的钱怎么突然变成不是我自己的？

  那些制定制度的人永远不会排队办理银行查询、永远不会因为少写一张资金来源证明被吼、永远不会在日本的税务局前被冷风吹着。他们不需要追踪透明，因为追踪透明的人自己就站在不透明的地方。

  这一切都从 2014 年 OECD 拍脑袋决定“我们要搞自动交换”开始。 那时候全世界大多数国家还懵着，连“自动交换”三个字的后果都没想明白。

  几年后，银行开始怀疑客户，客户开始怀疑银行，大家互相怀疑，但制度没有怀疑任何人——制度直接判定每个人都嫌疑重大。

  CRS不是改革，它是审讯。 只是你不知道你什么时候被问，也不知道你到底做了什么需要被问。

  ---

  加密货币的自由神话，被制度拧成一条狗链

  加密货币曾经是自由的代名词。 它的创造者说：“We don’t need trusted third parties.” 意思是，我们不需要银行，不需要监管，不需要制度做我们的监护人。

  但制度显然不乐意。 制度说：“你们玩可以，但得实名。” 制度又说：“实名可以，但得上报。” 制度最后说：“上报之后我会共享，你们别紧张。”

  监管者从来不追着区块链跑，他们追着交易所跑。他们不研究钱包怎么生成，却研究账户如何关联。他们不懂私钥，却懂得怎么让交易所配合他们。

  于是自由世界有了门禁。 去中心化被现实中心化。 匿名变成实名。 隐私变成透明。

  CRS 就是这样进入加密世界的。

  它不是直接来破解区块链，而是去找链下入口，从 KYC 开刀，从交易所下手。

  于是这一幕出现了：

  • 想使用交易所？先身份证举好。
  • 想进行提现？请解释资金来源。
  • 想跨境流转？请问你的目的是什么？
  • 想继续保持匿名？对不起，这是违法风险。

  加密货币原本是逃离中心化世界的小舟，但 CRS 把每一条小舟都按上了号码牌，并定期检查小舟的航海日志。

  加密世界的理想被现实世界当成玩具拆开重组，装上监管摄像头，再递还给你：

  “你还可以玩，只是我们会一起盯着。”

  ---

  透明不是美德，是枷锁：普通人的隐私为什么最容易被放大

  当 CRS 运行起来后，世界上最尴尬的一群人出现了： 那些只是想安静生活，却每天被银行问东问西的人。

  银行客服不再友好，他们问话的样子像你在洗钱； 税务机关不再温柔，他们发信的语气像你藏着海外金库； 交易所不再自由，他们要你解释为什么提币、提去哪里、提几次。

  CRS带来的透明，不是那种“阳光是最好的消毒剂”的透明，而是那种让你感觉全裸站在审讯灯下的透明。

  制度说透明是为了公平。 可现实里的公平从来不是建立在“掌握普通人的资产细节”上。

  你知道 CRS 最讽刺的地方是什么吗？

  • 真正的大型跨国企业，依旧有数百条合法避税路径
  • 真正的巨额财富，依旧有信托、基金、离岸结构保护
  • 真正的亿万富豪，依旧不会出现在自动交换名单里

  倒是普通人，被迫透明到像脚底的灯泡一样亮：

  • 三万日元的海外转账要解释
  • 三百美元的加密入金要检查
  • 一笔跨境转存要提供材料
  • 银行为了避免风险，随手就可能关掉你的账户

  CRS把普通人变成“重点关注对象”， 把自由的人变成“透明的物件”。

  你没做错什么，但你被怀疑一切。

  原本属于你的隐私，被制度拖到台面上亮相，像展示柜里的商品。

  ---

  各国实施CRS的时间：一份全球透明化的强制时间表

  既然制度如此强势，那它到底是什么时候开始让世界变透明的？ 下面是各主要国家与地区加入 CRS 的年份（按第一批交换年份或正式实施年份统计）。

  用一份时间表来呈现制度推进的速度，也许更能让人看清 CRS 究竟如何成为全球性的透明铁网。

  ---

  CRS 时间线大表

  说明：年份为第一次自动交换年份或正式加入执行年份，不反映每国后续扩展情况。

  地区	国家/地区	实施年份
  欧洲	欧盟成员国（共27国）	2017 开始统一交换
  	瑞士	2018
  	英国（脱欧前后均执行）	2017
  	挪威	2017
  	冰岛	2017
  	列支敦士登	2017
  	摩纳哥	2018
  	安道尔	2018
  亚洲	日本	2018
  	中国（含香港、澳门）	2017
  	韩国	2017
  	新加坡	2018
  	印度	2017
  	阿联酋	2018
  	卡塔尔	2017
  	沙特阿拉伯	2017
  	以色列	2017
  北美	加拿大	2018
  	墨西哥	2017
  	开曼群岛	2017
  	英属维京群岛（BVI）	2017
  	百慕大	2017
  南美	巴西	2018
  	阿根廷	2017
  	智利	2018
  	哥伦比亚	2017
  非洲	南非	2017
  	加纳	2018
  	毛里求斯	2017
  大洋洲	澳大利亚	2017
  	新西兰	2018

  📌 特别说明：美国不参加 CRS，仅执行 FATCA。

  也就是说，美国成了全球透明网络中的巨大灰色地带。

  制度告诉你要透明，但制度自己却保留了阴影。

  这难道不是最大的讽刺吗？

  ---

  制度越透明，普通人越恐惧：真实案例像一面镜子照着未来

  为了让这篇文章不是单纯抱怨，我们从现实案例里看看 CRS 给人带来的“透明体验”。

  案例一：日本银行账户被冻结的工程师

  一个在东京工作的工程师，从海外拿到自由职业收入，被银行要求提供：

  • 海外收入来源
  • 合同副本
  • 交易截图
  • 纳税证明

  因为他不能立即提供所有文件，银行直接冻结账户。 原因是：“疑似规避 CRS 风险”。

  工程师惊讶至极： “我只是多赚了点钱，什么时候成跨国犯罪嫌疑人了？”

  案例二：在加密交易所转出自有资金，却被要求解释“去向”

  一家全球知名交易所对于所有东京用户执行高强度审核： 一次用户把自己的币提到个人钱包，被要求解释理由。

  理由？ “我的钱我自己保管。”

  但交易所不接受，会持续追问：“你为什么要提币？你要转给谁？你的钱包是什么性质？是否涉及境外？”

  提币变成“审讯”。 自托管钱包变成“风险行为”。 加密货币变成“需要解释的行为”。

  而背后，就是 CRS 对平台施压的副作用。

  案例三：跨国移民者的“透明噩梦”

  一个人在亚洲持有加密资产多年，移民日本后开始产生收益。 结果税务机关要求：

  • 过往交易记录
  • 历史成本价
  • 持仓变化
  • 回国期间是否使用海外账户

  他不是罪犯，只是换了个国家，却被当成走私者一样盘问。

  制度没有区分善意与恶意， 制度只知道你“可能”不透明， 于是它先让你“完全透明”。

  ---

  透明牢笼的出口在哪里？

  政府说 CRS 是为了税收公平。 监管说透明能减少犯罪。 银行说配合制度是义务。 交易所说 KYC 是避免风险。

  每个人都站在自己的立场上说得头头是道， 唯一没有立场的，是普通人。 唯一必须被牺牲的，也是普通人。

  世界走向透明社会本没有错， 错的是透明只对普通人， 不透明却依旧对权力与财富有利。

  CRS 让所有人被迫习惯曝光， 让隐私从权利变成福利， 让财富从自由变成备案， 让加密资产从匿名变成数据。

  有人说，这就是进步的代价。 也有人说，这是制度的胜利。 但更多人只是像夜里便利店里的那个男人一样， 对着一罐温掉的咖啡发狠： “操蛋的 CRS。”

  1天前

• bing秒收网站内容了。

  高兴不起来，测试AI从B站爬内容自动改写成文章被人抓包了。害羞。

  1天前

• DeFi获利机器人原理解析与构建指南

  那天深夜，我盯着屏幕上某个地址提交的交易记录。数字跳动得像脉搏，又像一条在黑暗里游动的鱼。它没有犹豫，没有休息，没有恐惧，只在必要的时候狠狠咬住差价，在别人意识到之前先一步把利润拖走。 我突然明白，所谓 DeFi 获利机器人，不过是一个对世界毫无感情的猎手。而我，也终于想弄清它究竟是怎么做到的。于是便有了这篇文章。

  ---

  第一章　机器的世界里没有情绪，只有公式与机会

  你若是第一次听说“DeFi 获利机器人”，可能脑子里跳出来的是某种像是科幻电影中出现的金属怪物，它每天替你赚钱，甚至还懂得风控与哲学。

  

  事实并没有这么夸张。机器人从不感慨行情好坏，它只遵守最原始的逻辑：当数字出现可被利用的误差时，它出手；没有时，它等待。

  机器人对市场毫无情感波动，它不焦虑、不恐惧、不贪婪，它只是忠于数学。

  在链上，利润来源往往来自以下三件事：

  • 市场价格不同步
  • 抵押不足导致的清算机会
  • 流动性偏斜产生的波动空间

  为了让你看得清楚一点，我们先看这些机器人到底做哪些事：

  1. 套利机器人

     • 像一个跑得很快的黄牛，看到两个市场价格不一致，立刻从便宜的地方搬到贵的地方。

  2. 清算机器人

     • 像医院急诊室外的救护车，盯着那些快撑不住的仓位，一旦符合条件，马上给一针——但顺便拿走一点“感谢费”。

  3. 做市与再平衡机器人

     • 像守着河流的船夫，负责让左右两岸的货物保持平衡，否则河道会被水流冲歪。

  机器人为什么能赚钱？因为链上的价格就像一锅永远不会真正均匀的汤。有人搅拌时会咕嘟一声，有人停下时又恢复平静，而机器人就是那个盯着汤面气泡的人。 其中最重要的三项机制：AMM、预言机、清算机制，分别支撑着机器人理解价格、判断风险、设计动作。

  机器的世界没有所谓“行情差的时候休息”，也没有“压力大，今天不干活”，它只认数字，只在数字允许的地方赚取它应该赚的。

  ---

  第二章　AMM：价格在池子里流动，机器人在水面上捕食

  AMM（自动做市商）的运行方式简单得几乎浪漫。 任何一个交易池子，都像一个装着两种代币的水箱，它遵循一句刻在链上的古老箴言：

  x * y = k

  你往里倒进更多 x，池子就会把 y 变贵；你取走 y，池子就让 x 涨价。 AMM 不问你的名字，也不关注你的情绪，它甚至不关心你是否理解它，只按这条公式维持世界平衡。

  机器人看到这个池子，看到的不是水，而是差价。 举个例子：

  池子	ETH 价格	流动性	适合操作
  Uniswap	2000 USDC	中等	买
  Curve	2050 USDC	深厚	卖
  SushiSwap	1980 USDC	偏浅	不建议大量操作

  机器人会做的事情非常简单：

  1. 在便宜池买
  2. 在贵池卖
  3. 一口气完成
  4. 如果滑点和手续费没有吃掉利润，就赚到了

  这听上去像极了小时候在黑板上做的算术题，但其实藏着非常复杂的工程问题：

  • 价格读取延迟
  • 滑点计算不准
  • 池子深度变化太快
  • Gas 费用飙升
  • 被其他机器人抢跑

  机器人对付这些问题的方式很暴力——算法不断试错，不断迭代。它早就明白，链上不存在“绝对公平”，但只要有人不够快，它就能活下去。

  AMM 是水

  市场是河道 机器人是鱼 而你，是偶尔看到水花的岸边行人

  如果你想和它们一起游，就得学会屏住呼吸。

  ---

  第三章　预言机：链上需要有人告诉它世界多大，机器人需要知道什么时候世界撒谎

  区块链是一个封闭的宇宙。它不知道外面一天涨了几个点，它不知道新闻，也不知道恐慌指数。为了让链上的协议能借贷、结算、定价，它们需要一个“外部传声筒”——这就是预言机。

  可是传声筒可能失真。 机器人不会错过这种机会，但真正的获利机器人只利用市场自然的间隙，而不会利用漏洞或攻击系统。 这种界限非常重要。

  预言机的工作方式很像一个听力不好的人，他总是隔着半秒钟理解世界的声音，而机器人就是那个抓住这半秒的人。

  闪电贷操纵：在一个区块里制造假象

  闪电贷允许攻击者做一件很戏剧性的事：

  1. 无需本金借入巨额资产
  2. 在一个池中疯狂买入，把价格推到不合理的位置
  3. 协议以为价格是真的，于是允许他抵押高估资产获得大量贷款
  4. 他再把钱还回去
  5. 将多借出的稳定币收入囊中

  这是一种攻击，不属于合规的获利方式。但理解它有助于理解为什么协议需要更安全的预言机。 真正的机器人会避免靠这些动作盈利，因为那不是技术，是犯罪。

  预言机夹击：趁更新不及时的时候动手

  有些协议更新价格是按固定时间窗口的。 机器人如果盯准这个窗口的前后，短暂地推一下价格，就能让协议记录一个并不准确的平均值。 再利用这个平均值做抵押、借贷，甚至提前卖出获利。

  预言机的延迟像体温计坏掉之前的那几秒钟，医生还以为病人发热，而机器人已经把退烧药卖出去了。

  不过这同样属于攻击范畴。 合法的机器人不会这么做，但它必须理解这种行为，以便规避被操纵的数据。

  能被利用的是偏差，而不是漏洞

  一个真正可靠的机器人倚靠的是：

  • 不同步的价格
  • 不同协议之间的流动性差
  • 池子调整速度不一样造成的小误差

  偏差是自然现象，而不是人为破坏。 机器人的价值就在于在偏差出现的一瞬间行动。

  ---

  第四章　清算机制：当有人撑不住时，机器人会接住他，但要收费

  借贷协议里的每一个仓位都像是走钢丝的人。 抵押品价格跌一点，借款的价值涨一点，或风向突然变化，这条钢丝就会抖得让人心脏发凉。

  当一个仓位快撑不住时，清算机器人便会出现。

  它的动作非常明确：

  1. 扫描所有仓位
  2. 找到健康度不足的
  3. 模拟如果清算能得到多少抵押品
  4. 对比债务、预估卖出价格
  5. 判断能不能赚钱
  6. 如果能，就执行清算

  清算奖励是机器人眼里的糖果。 有时只是一点点，有时却足够它兴奋好几天。

  比如：

  用户	抵押率	状态	机会
  UserA	145%	无风险	❌
  UserB	120%	边缘	✔️
  UserC	104%	危险	✔️（回报更高）

  机器人不会嘲笑那些仓位失衡的人。 因为它知道，错不在他们，而在市场的无常。 它只是执行协议允许的动作，而协议通过这种方式保持系统稳定。

  清算机器人像司法系统中的执行员，程序化、公平、冷静。 它也像一个只对数字负责的天平，不关心情绪，只关心是否“该行动了”。

  ---

  第五章　构建一台真正的获利机器人

  你真正要写的机器人，不是一个“抓差价的小脚本”。 它是一个微缩的交易结构体，像一辆赛车，只要一个螺丝松动，它就会翻车。

  你需要至少这些模块：

  数据模块

  • 从 DEX 获取链上价格
  • 从借贷协议读取仓位健康度
  • 从预言机读取指数价格
  • 从内存池读取待处理交易

  策略模块

  • AMM 价格差判断
  • 清算条件判断
  • Gas、滑点、深度分析
  • 多路径 swap 模拟
  • 执行前利润预测

  执行模块

  • 构造交易
  • 签名
  • 精确控制 Gas
  • 发送到节点
  • 监听成功或失败

  风控模块

  • 最大交易限额
  • 滑点容忍度
  • 失败回滚机制
  • 节点延迟保护

  一个简化示例（非可运行代码）：

  def check_arbitrage():
      price_a = read_price("uniswap")
      price_b = read_price("curve")
      if price_b - price_a > threshold:
          return True
      return False
  
  def execute_arbitrage():
      # 合约内一次完成买入→卖出，避免被抢跑
      pass

  当你真的把它跑起来时，你会发现机器人并不神秘。 它甚至没什么哲学。 但它确实有一种很奇怪的生命力： 只要链上还有一丝机会，它就会继续活着。

  这台机器的心跳来自你，而不是链

  机器人本身不懂风控、不懂深度、不懂滑点，全是你告诉它的。 写机器人是一种自我放大——你越冷静，它越冷静；你越冲动，它越容易爆仓。 你若偏执，它会替你在链上反复犯错；你若沉稳，它就会变得精准。

  机器人没有思想，却能完全暴露你的思想。

  ---

  尾声：当屏幕亮着时，机器就不会睡

  有时候我会想，人类为什么会羡慕一段代码？ 也许因为它从不犹豫，也不为明天担忧。 它不会因为涨跌而手抖，不会因为失眠而误判，它只在公式允许的范围内生活。

  而写这样一个机器人的人，会在无数个夜里看着那串地址跳动。 当它第一次替你完成套利，当它第一次成功清算，当它第一次战胜深度与滑点，你会突然理解一种奇妙的安静： 原来世界的缝隙里真有东西在流动，只是速度太快，肉眼看不清。

  但机器人能看清。 它不是你的敌人，也不是你的未来，它只是一个工具。 你若明白它的原理，它就能成为你的伙伴。 你若误解它，它只会成为另一种风险。

  写它之前，先让自己安静下来。 等你的想法成形，它就会诞生。 在某个没有情绪、没有声音的区块高度里，它会醒来。 然后开始一段属于你的运转。

  2天前

• 密码保护：懂懂日记"风格写作提示词 V1.3 有效降低AI率

  此内容受密码保护。如需查阅，请在下方输入密码。

  密码：

  3天前

• Claude Code Router 模型路由与配置实战

  那天晚上，我的 IDE 里蹦出一行小字：“请选择默认模型”。 屏幕右下角的时钟显示 01:37，像是在提醒我，正常人这个点应该已经睡着，而不是在给一个叫 Claude Code Router 的东西配路由。

  

  我盯着那几个选项：默认、后台、思考、长上下文。手里有一把牌——DeepSeek、Qwen3、各种 thinking 版、coder 版——但我根本不知道应该让谁上场。 就像踢球，队里都是球星，可是我连谁打前锋、谁去守门都没想明白。🤦‍♂️

  于是我干脆问了下 AI：“你帮我排个阵容吧。” 接下来，你看到的这篇，就是那天凌晨的“排兵布阵笔记”。

  ---

  一、IDE 里的“多模型人生”：为什么要路由？

  如果你只用过一个模型，世界是简单的：

  “无论什么问题，都问同一个家伙。”

  但装上 Claude Code Router 之后，世界忽然复杂起来：

  • 你可以接很多模型：DeepSeek、Qwen3、Gemini、OpenAI、OpenRouter……

  • 每个模型都有自己的性格：

    • 有的推理强，但贵；
    • 有的便宜，但只适合同声传译；
    • 有的记忆力爆棚，能记几本书；
    • 有的只适合写点短代码。

  Router 做的事其实很朴素：

  把不同场景，分配给最合适的模型。

  于是它在配置里给你准备了几个“角色”：

  • default
  • background
  • think
  • longContext
  • webSearch
  • 再加一个 longContextThreshold

  第一次见到这些，我的感觉是：

  “你能不能像正常人一样写：主力、打杂、思想家、记性好的、爱上网的？”

  不过这几个词背后，确实是有点讲究的。要把它们弄明白，后面的配置才不会乱。

  ---

  二、先把“角色”看懂：default / background / think / longContext / webSearch

  先别急着贴 config.json，我们先把这几个名字翻译成人话。😏

  1. default：队里的前锋，也是你最常看的脸

  什么时候用到？

  • IDE 里写代码、改代码；
  • 问报错、要解释；
  • 写点注释、生成小工具函数；
  • 聊天胡侃。

  没有特别说明的时候，一切请求都会走 default。

  该选什么样的模型？

  • 综合能力最强；
  • 代码、自然语言都靠谱；
  • 不会一问三不知，也不会卡半天不说话。

  你可以把 default 理解成：

  “如果这个项目只能留一个模型，那就是它。”

  ---

  2. background：后台搬砖工，干活多但不抢镜

  什么时候用到？

  • 在“背后默默干活”的任务：

    • 多文件扫描；
    • 批量重写；
    • 预分析项目结构；
    • 生成一些中间产物。
  • 有些操作你点一个按钮，前台模型给你反馈，后台模型去跑长一点的分析。

  所以 background 的模型，一般有这些特点：

  • 便宜：因为调用频次会很高；
  • 够用：不要求它写出世界上最优雅的代码，但别太离谱；
  • 可以比 default 弱一点，但别弱太多。

  一句话：

  “能干体力活，别给我挖坑就行。”

  ---

  3. think：认真思考的那一个，不适合用来点外卖

  think 听着就有点装，但它确实是用来干重度推理的。

  典型场景：

  • 排查一个跨多模块的复杂 bug；
  • 设计一套系统架构；
  • 写一个需要很多推理步骤的算法；
  • 分析边界情况、并发问题、事务一致性这些会让人掉头发的东西。

  在这些场景里，你需要的不是“说人话的模型”，而是：

  “愿意慢一点，但多动脑子”的模型。

  所以 think 适合用：

  • 那些名字里就带 reasoner / thinking / o3 之类后缀 的版本；
  • 你愿意多付一点钱，换更稳妥的思考过程。

  它不一定要当你的主力模型，但该它上场的时候，不能掉链子。

  ---

  4. longContext：记性最好的人，负责应对“信息海啸”

  如果你经常干这些事：

  • 一次性丢几十个文件给模型；
  • 让它读一整份产品文档、PRD、需求书；
  • 扔给它几百 KB 的日志，让它自己想办法梳理。

  那你就会发现：

  有些模型聪明，但记忆力小； 有些模型不一定最聪明，但记忆力惊人。

  longContext 的作用，就是当上下文长度超过阈值（longContextThreshold）时，Router 自动让这位“记性最好的人”顶上。

  它的特点：

  • 上下文窗口大（几十万 token 起步）；
  • 整体水平不错，但可能不如你的 default 那么尖锐；
  • 适合干“耐心阅读大量资料，然后给个还行的答案”这种活。

  你可以设一个阈值，比如 60000：

  • 没超过，就继续用 default；
  • 超过了，就切到 longContext。

  ---

  5. webSearch：那个爱上网的人

  webSearch 一般和“联网搜索”“工具调用”相关。

  有的模型：

  • 自己就带搜索能力；
  • 或者在你的框架里，专门被用来接第三方 API；

  也有时候你可能只是懒得区分，干脆用和 default 一样的模型。

  适合放在这里的模型：

  • 对新信息、网页、搜索结果适应性好；
  • 能看长文本网页，提取重点；
  • 速度别太慢，不然你会怀疑自己是不是断网了。

  如果暂时搞不清楚，就先和 default 设成一样，后面再单独优化。

  ---

  6. 一张小表，看得更清楚一点

  角色	触发时机	模型该有什么特点	举例场景
  default	绝大部分普通请求	综合最强，代码&自然语言均衡	写代码、改代码、问报错、简单解释
  background	后台任务、批处理	便宜、够用、稳定	扫描项目、预分析、多文件批量操作
  think	需要深度推理、复杂决策时	推理能力强，允许稍慢、稍贵	复杂 bug、架构设计、算法、边界分析
  longContext	上下文长度超过阈值时	上下文窗口巨大，阅读能力强	超长日志、整仓代码、长篇文档
  webSearch	需要联网 / 调用外部信息时	善于处理搜索结果、网页	查资料、读 API 文档、看 news / issue

  看完这个表，你再回头看 Router 的配置项，多少就不那么抽象了。

  ---

  三、把手上的牌排好：用 DeepSeek + Qwen 配一套阵容

  我们现在手里有一副真实牌，你的 provider 叫 gemini22222，接口是：

  https://api.qnaigc.com/v1/chat/completions

  模型列表是：

  • deepseek-v3.1
  • deepseek/deepseek-v3.1-terminus-thinking
  • deepseek/deepseek-v3.2-speciale
  • deepseek/deepseek-v3.2-exp-thinking
  • qwen3-max
  • qwen3-coder-480b-a35b-instruct

  现在就像选足球阵容一样，我们一个位置一个位置来排。

  1. default：让谁当主力？

  候选人里，看名字就知道：

  • deepseek/deepseek-v3.2-speciale ——新版本，高配选手，适合做主力。
  • deepseek-v3.1 ——上一代主力，靠谱但略旧。
  • qwen3-max ——综合模型，但你这套里还有 coder，适合做别的位置。

  推荐：

  default → gemini22222,deepseek/deepseek-v3.2-speciale

  理由很简单： 写代码、日常聊天、解释问题，全部交给最强的那个，是最省心的选择。

  ---

  2. background：找个能干活又不贵的

  在你这套牌里，background 可以用：

  • deepseek-v3.1：已经证明过自己，性能足够；
  • 或者 qwen3-max：也 OK，但多留一个通用位给 webSearch 也不错。

  我会这样选：

  background → gemini22222,deepseek-v3.1

  原因有三个：

  1. 对比 v3.2 high-end 版，v3.1 通常 更省钱；
  2. 写点辅助代码、做预分析完全没问题；
  3. 即便 background 暂时和 default实力有差距，对体验影响也不大，因为大多数你能直接看到的回复依然来自 default。

  ---

  3. think：推理上限拉满

  你手里有两个显眼的“thinking”类选手：

  • deepseek/deepseek-v3.1-terminus-thinking
  • deepseek/deepseek-v3.2-exp-thinking

  如果从“更新鲜 + 潜在能力更高”的角度，我会选：

  think → gemini22222,deepseek/deepseek-v3.2-exp-thinking

  把最强 reasoning 版本放到 think，能让下面这种场景变得舒服很多：

  • “帮我彻底分析这个并发 bug，给出可能的 race 条件。”
  • “这段业务流程所有分支路径帮我走一遍。”
  • “给一个 3 个月的重构计划，把这个单体拆成服务。”

  terminus-thinking 你也可以作为备选，或者在另一个环境单独配置做对比测试。

  ---

  4. longContext：Qwen3 Coder 去守后场

  长上下文的需求很明确：谁的记忆力大，就用谁。

  在你的列表里，最适合当 longContext 的就是：

  • qwen3-coder-480b-a35b-instruct

  光是名字里的 480b 就已经在拼命暗示你：

  “我虽然贵一点，但我记得住的东西比别人多。”

  所以这里的选择很自然：

  longContext → gemini22222,qwen3-coder-480b-a35b-instruct longContextThreshold → 60000（可以先按默认来）

  这么配的实际效果：

  • 正常聊天 / 写代码：走 deepseek/deepseek-v3.2-speciale；
  • 偶尔扔点大文件：一开始还是 default，只要没超过阈值；
  • 当对话历史 + 文件内容一起超过 6 万 token 时，Router 自动换成 Qwen3 Coder，把这场“信息海啸”扛下来。

  ---

  5. webSearch：谁来负责上网？

  对于 webSearch，你有两种思路：

  1. 简单粗暴版：

     webSearch → 和 default 一样

  2. 分工明确版：

     webSearch → 用 qwen3-max，让它专门干查资料这类活

  看你的模型组合，我会倾向第二种：

  webSearch → gemini22222,qwen3-max

  原因是：

  • default 已经在忙着写代码；
  • coder 版本已经去处理长上下文；
  • 剩下这个 qwen3-max，刚好可以专门管理“读网页、查资料”。

  当然，如果某天你发现 qwen3-max 的联网效果不如 deepseek 让你放心，你可以再把 webSearch 切回 deepseek/deepseek-v3.2-speciale，Router 配置改一下就完事。

  ---

  6. 阵容一览表

  下面这一表就相当于你的模型首发名单：

  Router 角色	绑定模型	人设定位
  default	gemini22222,deepseek/deepseek-v3.2-speciale	主力前锋，绝大部分请求都靠它
  background	gemini22222,deepseek-v3.1	后台搬砖工，批处理、预分析
  think	gemini22222,deepseek/deepseek-v3.2-exp-thinking	深度思考型选手，专管复杂推理
  longContext	gemini22222,qwen3-coder-480b-a35b-instruct	记忆怪兽，负责超长上下文
  longContextThreshold	60000	超过 6 万 token 就切长上下文
  webSearch	gemini22222,qwen3-max	爱上网的人，专管搜索与读网页

  这个阵容已经足够支撑你在 IDE 里过得比大多数人更舒适了。😎

  ---

  四、config.json 实战：从一行 URL 到完整路由

  讲完“为什么”，该看看“怎么写”。

  下面是一个简化版的 config.json 片段，专注在你这次要改的两个部分：Providers 和 Router。

  1. Providers：先把所有牌摆到桌上

  {
    "Providers": [
      {
        "name": "gemini22222",
        "api_base_url": "https://api.qnaigc.com/v1/chat/completions",
        "api_key": "YOUR_API_KEY_HERE",
        "models": [
          "deepseek-v3.1",
          "deepseek/deepseek-v3.1-terminus-thinking",
          "deepseek/deepseek-v3.2-speciale",
          "deepseek/deepseek-v3.2-exp-thinking",
          "qwen3-max",
          "qwen3-coder-480b-a35b-instruct"
        ],
        "transformer": {
          "use": [
            "openai-compatible"
          ]
        }
      }
    ],
    ...
  }

  这里有几个容易踩坑的点：

  1. name 必须和 Router 里写的一模一样，比如我们统一用 gemini22222。

  2. models 数组里的每一项：

     • 要和调用方支持的 model id 完全匹配；
     • 不能自己随便改大小写、少写斜杠。
  3. api_base_url 用的是对方给的 chat completions 兼容地址。

  只要 Provider 配对了，后面的路由才有意义。否则 Router 配得再优雅，也是对空气吼。

  ---

  2. Router：给每个角色安排好“人选”

  现在把前面那张“首发名单”翻译成真正的配置：

  {
    ...
    "Router": {
      "default":    "gemini22222,deepseek/deepseek-v3.2-speciale",
      "background": "gemini22222,deepseek-v3.1",
      "think":      "gemini22222,deepseek/deepseek-v3.2-exp-thinking",
      "longContext":"gemini22222,qwen3-coder-480b-a35b-instruct",
      "longContextThreshold": 60000,
      "webSearch":  "gemini22222,qwen3-max"
    }
  }

  格式规则只有两条：

  1. 每个值都是一个字符串："providerName,modelId"；
  2. 注意逗号左右可以有空格，也可以没有，但 providerName 和 modelId 一定不能写错。

  保存之后，通常你会：

  1. 关掉原来的服务；
  2. 再启动一次 Router（比如 ccr restart 那套命令）。

  IDE 里打开插件，看到每个路由下拉框对应的选项已经高亮，就是它开始按你写的阵容跑了。

  ---

  3. 日常调参的几个小习惯

  用久了之后，你大概率会遇到这些状况：

  • “最近 default 有点慢，是不是太忙了？”
  • “后台批处理好像也不需要那么强的模型？”
  • “我这个项目里，超长上下文其实不多，用 coder 有点浪费。”

  可以参考下面几个步骤来调：

  1. 先记录感受

     • 是慢？贵？还是回答风格不满意？

  2. 对照 Router 角色

     • 这个问题发生在哪种场景？

       • 写代码时慢 → 看 default
       • 多文件处理慢 → 看 background
       • 超长任务卡死 → 看 longContext

  3. 只改一个变量

     • 比如：只把 background 换成更便宜的模型；
     • 或者把 longContextThreshold 从 60000 调到 80000，让 default 多扛一点。

  路由配置就像调球队阵容， 不要一次换 11 个人， 否则你都搞不清到底是谁踢得好。

  ---

  4. 小结式备忘录（随手抄一份放旁边）

  • 如果你懒得想很多：

    • default = 最强模型
    • background = 稍微便宜一点的模型
    • think = 带 thinking / reasoner 后缀的模型
    • longContext = 上下文最大的模型
    • webSearch = 一个你觉得“查资料够靠谱”的模型

  • 如果你有 DeepSeek + Qwen 这套组合：

    • default → deepseek/deepseek-v3.2-speciale
    • background → deepseek-v3.1
    • think → deepseek/deepseek-v3.2-exp-thinking
    • longContext → qwen3-coder-480b-a35b-instruct + 阈值 60000
    • webSearch → qwen3-max 或和 default 一样

  • 如果哪天又多接了几个模型：

    1. 先想清楚它适合当哪个“角色”；
    2. 再把 Router 里对应的那一行换掉；
    3. 重启服务，看实际体验。

  ---

  那天凌晨配置完路由，我关掉 IDE，才发现窗外已经泛起一点亮光。 对于绝大多数人来说，这只是几个模型名字的排列组合； 但对天天和代码打交道的人来说，它决定了以后每一次敲下快捷键时，屏幕那头到底是谁在回答你。

  至于谁更懂你写的那堆 bug，谁更适合当你深夜的搭档—— 现在你至少有能力，亲手给他们排个座位。✨

  5天前

• Nano Banana Pro 生成当地天气的提示词（针织微缩景观风格）

  测试之后Nano Banana Pro生成效果很不错，豆包即梦也可以。 效果如下：

  提示词如下（修改地点为你想要的城市即可）：

  [哈尔滨市，2025.12.01]
  根据您输入的城市名称、日期和时间，自动反映该城市的实际天气和时区，并生成一张“钩针玩偶世界”的气候卡片。
  [风格]
  – 所有元素（建筑物、树木、车辆、人物、地标、标志等）均以钩针玩偶的形式呈现。
  – 人物也以可爱的钩针玩偶形式出现，
  表情萌趣，四肢短小，比例圆润。
  – 柔和的粉彩色调 + 舒适的针织纹理。
  – 背景是一个完全由针织元素构成的微缩城市世界。
  
  [自动天气模拟]
  – 准确反映所输入城市的实际天气状况。
  • 雪 → 钩针雪花 + 蓬松的冬季针织背景。
  • 雨 → 用毛线表现的雨滴 + 湿润的色彩。
  • 多云 → 厚重的针织风暴云。
  • 晴朗 → 柔和的粉彩天空。
  • 雾 → 朦胧的毛毡雾。
  – 温度会自动反映今日实际的最高和最低气温。
  
  [自动时区反映]
  – 背景氛围会根据输入的时间而变化。
  • 早晨 → 柔和的粉彩天空。
  • 下午 → 明亮温暖的光线。
  • 日落 → 橙粉色的针织日落。
  • 傍晚 → 针织玩偶夜景（点缀着小巧的针织灯）。
  • 夜晚 → 深蓝色的针织天空 + 毛毡星星。
  
  [背景构成]
  
  – 以针织玩偶的形式重新诠释具有代表性的城市地标。
  
  例如：首尔 → 南山塔 / 北村小巷 / 咖啡街
  
  – 几个钩织玩偶在街上自然地行走和交谈。
  
  – 街边的咖啡馆、面包店、商店、招牌和其他标识
  
  自动生成您输入的城市语言文本，使其以钩针编织的风格自然呈现。
  
  （例如：中国 → 中文标识 / 巴黎 → 法语 / 东京 → 日语 / 纽约 → 英语）
  
  [界面布局]
  
  – 顶部中央显示城市名称
  
  – 下方显示输入的日期
  
  – 下方显示今日实际温度
  
  – 今日天气图标（云/晴/雪/雨等，由毛线制成）
  
  – 底部无文字。
  
  [自动文本颜色优化]
  
  文本颜色会根据背景亮度、色调、天气状况和时间自动调整，以提高可读性。调整：
  
  – 阴天/暗云背景 → 深炭灰/深灰/藏青色
  
  – 雪景/白色背景 → 暖棕色/驼色
  
  – 雨天暗夜 → 米色/白色缝线
  
  – 晴空/晴空 → 深棕色或深蓝色
  
  – 日落背景 → 棕色/深橙色
  
  – 夜景 → 象牙色/白色针织缝线
  
  [整体色调]
  
  – 9:16 比例
  
  – 温馨的冬日氛围，柔和的光线
  
  – 一个可爱、简洁的微缩世界

  5天前