自从 Claude Sonnet 4.5 上线以来，好评如潮。很多 AI 编程助手都整合了 Claude Sonnet 4.5 模型，比如 GitHub Copilot。

不过 GitHub Copilot Pro 会员每个月只有 300 个 Premium Requests，一个月 30天，平均每天就 10 个请求，对于广大程序员来说，根本不够用，怎么办?

下面我要讲5个小技巧来优化你的 Vibe Coding 流程，让每一次 Premium request都用到点上。

第一个小技巧:控制问题的颗粒度

之前那篇文章中我聊过这个问题，提的问题不要太大也不要太小。太大了超出 Tokens限制反而不好，太小了就是严重的浪费。

大问题拆解成几个模块分别提交。多个小问题可以聚合起来一起提交。

控制好颗粒度很关键，这个需要实战演练，自己把握。

第二个小技巧:让模型先“热身”，别一上来就提终极问题

Claude Sonnet 的上下文理解能力极强，但也意味着它在面对含糊问题时会尝试“猜你的意思”，从而浪费一次 premium 请求。

正确做法是:先用普通模型(如 Claude Instant 或 GPT-3.5)帮你把问题框清楚，比如确定 API 调用的结构、接口参数、上下文依赖，然后再让 Sonnet 出手解决关键逻辑或生成高质量代码。

用轻模型暖场，用重模型收割。

- 阅读剩余部分 -

在全球依赖云计算的今天，亚马逊 AWS 的任何一次抖动，几乎都意味着互联网世界的一次“地震”。

而就在 10 月 20 日（美西时间），这场震动真实地发生了——持续超过 15 个小时的 AWS 服务中断，波及了全球数以千万计的企业与用户。

一、从 DNS 故障开始的“系统雪崩”

根据亚马逊官方说明，事故最早在 10 月 19 日晚 11:49（PDT） 出现：美国东部 1 区（US-EAST-1）的多个 AWS 服务出现了显著的延迟与错误率上升。

起初的原因看似简单：DynamoDB 区域端点的 DNS 解析出现异常，导致相关服务无法访问。

但问题在于，AWS 内部的很多关键系统——包括 EC2 实例启动模块、网络负载均衡器（NLB）、Lambda 调度、CloudWatch 监控 等——都不同程度依赖 DynamoDB。

当 DynamoDB 挂掉后，这些服务像骨牌一样接连出错。

官方在凌晨 2:24 修复了 DNS 问题，但由于 EC2 启动子系统对 DynamoDB 的反向依赖，故障迅速演变为经典的 循环依赖（Circular Dependency）灾难。

- 阅读剩余部分 -

Vibe Coding 这个词最近很火。

这个词原本的含义是“凭感觉写代码”或“以氛围驱动的编程”。听起来有点抽象，其实背后是一种趋势:让开发过程更自然、更即时、更具创造性。

在 AI 辅助开发兴起的时代，“Vibe Coding”常指:开发者不再精确地计划每个函数和架构，而是与 AI 一起边想边写，让代码流动起来

但随着 A1 越来越智能，尤其是 Claude Sonnet 4.5 的横空出世,“Vibe Coding”更常用的含义变成了:我来指挥 A1写代码，顺便监工。

没错，我现在就是这个状态，

如果项目结构比较规范、需求比较明确的话，基本上不需要我手动编码，只需要提需求就行了，基本上就像个指挥程序员干活的产品经理。

- 阅读剩余部分 -

这个问题非常常见，本质是 z-index 层级冲突。Element Plus 的 el-dialog 默认是挂载在当前组件上下文内（不是挂载到 body），而 el-table 的表格内容有时会开启 overflow 隐藏或 transform，导致 dialog 被裁剪或压在下面。

解决方案

非常简单，使用 append-to-body，将 el-dialog 输出到最外的层级。

<el-dialog
  v-model="visible"
  title="详情"
  append-to-body
>
  ...
</el-dialog>

在实际项目（特别是 Vite + Vue3 + Element Plus）中，建议所有全屏或模态层组件（如 Dialog、Drawer、Popconfirm）都加上 append-to-body，以避免被嵌套容器影响。

本文不谈商业服务，只讨论免费的服务。

如果不考虑商业用途，只是个人学习使用的话，那么 ipip.net 的地址库应该是最好用的，创始人是国内早期的站长。

2025-10-14T03:12:39.png

不过刚发现从2019年开始就停止更新了。。。

2025-10-14T03:15:22.png

企业版是正常更新的：

2025-10-14T03:19:52.png

但如果商业使用，ipip.net 就必须付费了。

还好有国外的这些。

2025-10-14T02:55:48.png

在中国大陆的实际表现（社区与实测汇总）

2025-10-14T02:56:15.png

平均城市级正确率在 60%左右，但省级准确率达 80–90%。

综合来说，推荐优先级如下：

GeoLite2 ≥ IP2Location DB9 ≥ DB-IP Lite

GeoLite2 下载地址

GeoLite2-City.mmdb

PS: 从 2019 年底开始，下载 GeoLite2-City.mmdb 必须先注册登录 MaxMind 帐号。这是 MaxMind 公司根据隐私法规（GDPR / CCPA）调整后实施的强制措施。

以前（2019 年前）GeoLite2 是完全公开的匿名下载；但自从隐私法规要求对 IP 数据分发进行追踪后，MaxMind 改为：“所有下载必须使用授权 License Key 进行身份验证。”

- 阅读剩余部分 -

过去两年，AI 产品的形态经历了一次悄无声息但深刻的转变。最初，人们把 ChatGPT 当成一个“万事通”的聊天窗口，各种外部 App 都在想办法“嵌入 Chat”。从最早的 ChatGPT 插件到后来的 Actions，每个 App 都希望被 ChatGPT 调用，希望在那一行对话背后，能让模型触发自己的服务。这种形态其实沿袭了传统互联网思维：AI 是一个超级入口，而所有第三方都是被调用的 API，它们被动等待用户的自然语言指令，然后在后台完成任务。这一时期的 Chat，更像一个智能中控台，App 只是工具箱里的螺丝刀。

但今年情况变了。OpenAI 推出了 Apps SDK，一切开始反转。过去是 App 嵌入 Chat，现在是 Chat 嵌入 App。这听起来只是语序的变化，实则是产品范式的质变。Apps SDK 让开发者可以构建自己的 MCP 服务端（Model Context Protocol Server），再配上前端 widget，小到一个查询组件，大到一个完整的操作界面，都能被模型直接加载到对话中。与此同时，App 自身也能反向调用 ChatGPT，让聊天成为自己应用内部的一部分。这意味着 ChatGPT 不再是一个独立入口，而开始“渗入”每一个 App 的界面、逻辑与体验之中。

- 阅读剩余部分 -

2025年了，马上2026年了，距离2017年微信小程序推出快10年了，应该选择什么框架开发微信小程序？还是用原生开发？

不得不说原生开发是最靠谱的方案之一，毕竟没有中间商，理论上坑是最少的。

如果你不嫌原生开发一个页面分4个文件麻烦，还是可以考虑的。而且绝大多数场景下，小程序只需要开发微信的就行了，其他家的小程序都不是主流，没有必要开发多端。

如果你跟我一样非常嫌弃原生的开发方式或者需要开发多端，那就需要考虑选择一款框架了。

MPX

MPX 是滴滴的研发团队出品，轻量，兼容原生，性能好，也支持跨平台，使用 vue 的语法，熟悉 vue 的还是比较推荐使用的。

缺点是 JetBrains 没有插件支持（原来有一个的，后来下架了）。

- 阅读剩余部分 -

macOS 升级到最新版本(26.0.1)后，基于 Datavyu + ffmpeg 的视频读取出错误的视频旋转方向，原因是 datavyu 调用 ffmpeg 没有正确使用旋转参数。鉴于 datavyu 上次发布还是在 2022 年，目测短期内不会修复这个问题。只能本地处理视频的 Rotation 为 0。

解决方案：

  1. 先用 exiftool 清除 Rotation（设置为0)；
  2. 使用 ffpmeg 旋转视频。

1个G的视频在 M4 芯片上需要跑大概 5 分钟。

下面是处理脚本：

- 阅读剩余部分 -

  1. 1
  2. 2
  3. 3
  4. 4
  5. ...
  6. 30