如何使用 Google Gemini 作为 Xcode 的智能编程助手?
首先准备好 Gemini 的 API Key,可以在 这里 申请。

申请过程很简单,不赘述。
将 macOS 升级到最新的 26.0.1 版本,Xcode 也一样升级到最新版,然后就可以开始了。
第一步,点击这里的 "Set Up..." 按钮:

首先准备好 Gemini 的 API Key,可以在 这里 申请。

申请过程很简单,不赘述。
将 macOS 升级到最新的 26.0.1 版本,Xcode 也一样升级到最新版,然后就可以开始了。
第一步,点击这里的 "Set Up..." 按钮:

自从 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 服务中断,波及了全球数以千万计的企业与用户。
根据亚马逊官方说明,事故最早在 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,以避免被嵌套容器影响。
当你升级了 ChatGPT 会员,准备开心得用上 Codex 时,坑来了。
在 VS Code 的插件库中搜索 Codex,你会看到 4 个 Codex——

其中,除了第一个是 OpenAI 出品外,其他 3 个都是不相关的。
我第一反应是有人山寨,但仔细看了一下发现都不是。
本文不谈商业服务,只讨论免费的服务。
如果不考虑商业用途,只是个人学习使用的话,那么 ipip.net 的地址库应该是最好用的,创始人是国内早期的站长。

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

企业版是正常更新的:

但如果商业使用,ipip.net 就必须付费了。
还好有国外的这些。

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

平均城市级正确率在 60%左右,但省级准确率达 80–90%。
综合来说,推荐优先级如下:
GeoLite2 ≥ IP2Location DB9 ≥ DB-IP Lite
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 是滴滴的研发团队出品,轻量,兼容原生,性能好,也支持跨平台,使用 vue 的语法,熟悉 vue 的还是比较推荐使用的。
缺点是 JetBrains 没有插件支持(原来有一个的,后来下架了)。
macOS 升级到最新版本(26.0.1)后,基于 Datavyu + ffmpeg 的视频读取出错误的视频旋转方向,原因是 datavyu 调用 ffmpeg 没有正确使用旋转参数。鉴于 datavyu 上次发布还是在 2022 年,目测短期内不会修复这个问题。只能本地处理视频的 Rotation 为 0。
1个G的视频在 M4 芯片上需要跑大概 5 分钟。