标签 github 下的文章

自从 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 出手解决关键逻辑或生成高质量代码。

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

- 阅读剩余部分 -

Vibe Coding 这个词最近很火。

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

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

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

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

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

- 阅读剩余部分 -

因为墙的缘故，github 仓库经常推送拉取慢或者断连，我一般的做法是开启终端的代理:

export https_proxy=http://127.0.0.1:7897 http_proxy=http://127.0.0.1:7897 all_proxy=socks5://127.0.0.1:7897

这种做法会让当前窗口所有的流量走代理，有额外的心理负担。

今天在社区看到一个更 nice 的做法，就是在 .ssh/config/ 里设置代理命令：

Host github.com
  User git
  HostName github.com
  ProxyCommand ncat --proxy-type socks5 --proxy 127.0.0.1:7890 %h %p

这样就不需要每次设置了。

国内的服务器有个蛋疼的问题：下载一些国外的依赖时非常慢甚至被墙。

比如 github 上的那些开源软件，下载速度只有十几K，甚至下不了。
再比如 packgist 至今都是被墙的，只能使用国内的镜像。

以前尝试过给服务器装个 v2ray 走代理，结果被云厂商扫描出来了，还给警告了一下。

怕被停服，不敢装了。

其实有个好办法就是使用 ssh -R 命令，将本地的代理端口共享给服务器，让服务器走你本地的代理去访问国外网站。

使用 ssh 连接服务器的时候，使用以下命令：

ssh -R 本地端口:本地主机:远程端口 用户名@远程主机

- 阅读剩余部分 -