自从 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 分钟。

下面是处理脚本:

- 阅读剩余部分 -