JitHub程序员

Antigravity 突然越用越顺手

边做边学，边学边做。
多做多错，少做少错，不做不错。
多错多收获，少错少收获，不错无收获。
多多上站，踩足够多的坑，才能把技能锻炼出来，才能在后面遇到大机会时快速上站，并且尽量少犯错。
然后就能起飞了。

这是程序员最好的时代😎

为什么都 2025 年了，很多人做 X 上的选题和舆情，还在手动收藏推文、截图、贴到 Notion 里慢慢整理？

我这两天在用一个开源小工具 x-kit，实测可以免费把指定用户在 X 上的推文，稳定抓下来，本地存成结构化数据，还能挂在 GitHub Actions 上定时跑，等于给自己做了一个私人版的 X 数据后台。

简单说下工作方式和门槛

1️⃣ 需要你自己准备合法的 X 相关 token 在项目里配置好
2️⃣ 在配置文件里把你想追踪的账号写进去 比如竞品 创作者 KOL 等
3️⃣ 本地用 Bun 跑脚本 或者直接用 GitHub Actions 定时执行 把最新推文和用户信息同步到仓库里的 accounts 和 tweets 目录

所以它本质不是“某个平台的黑盒服务”而是一个你完全掌控的抓取脚本 技术栈是 Bun加TypeScript 外加 GitHub Actions 负责调度 只要你肯花一点时间配置 环境成本和使用成本几乎是零。

对创造者有什么用呢

1️⃣ 持续观察一批人 比如你关心的顶级博主和同行 把他们一个月的推文拉下来 看真正有效的内容分布 主题节奏 和引流路径
2️⃣ 做自己产品的“选题雷达” 你可以按天按人去翻数据 而不是被时间线算法牵着走
3️⃣ 以后要做简单的数据分析 或者喂给大模型做二次总结 你有完整原始数据在手 而不是散落在收藏夹和截图里

纳瓦尔说过 杠杆来自代码和媒体 这种小爬虫其实就是很典型的“代码杠杆” 你写或用一次 之后每天在后台默默帮你干活 把时间线变成数据库 把碎片阅读变成可反复研究的资产

唯一要提醒的是 这类工具一定记得在合规前提下使用 遵守平台的使用条款 不要做大规模滥用和骚扰行为这点是底线

如果你也是那种想认真对待自己信息输入的创造者 想提升对 X 的“研究能力”而不只是刷一刷时间线 可以找个周末把这个仓库跑起来 当成你个人的信息基础设施之一

GitHub 仓库在这里 👇

不管你信不信，但这就是事实。
基于 Nano Banana 提供的能力，去做生图、修图、改图网站，提供老照片修复、图片翻译、海报生成等服务，然后等着人来付钱。

当然，最难的是等着人来这步。
怎么才能有人来用？
做好 SEO 或者 SEM。

又开始了，上午又在处理前端问题，自己产品新发布的好几个页面都没被爬虫爬，网站流量高+入口在navbar+是<a>标签链接，想起之前遇到过类似的问题（m.okjike.com），让Cursor分析了产品网站的原因（条件渲染问题），由于没用新对话，分析上下文之后我的博客站也有相同的问题（不一样的原因，portal组件库）

—————————

一个容易被忽视但影响严重的 SEO 问题

如果网站导航栏使用下拉菜单（如"产品"、"服务"、"资源"等），而这些下拉菜单中的链接在页面初始加载时不存在于 HTML 代码中，搜索引擎爬虫可能无法发现和索引这些页面。

问题表现：
在 Google Search Console 中，导航栏的很多链接对应的页面都没有被索引
即使网站流量很高，导航链接理论上应该被优先抓取，但如果链接不在初始 HTML 中，爬虫就无法发现它们
用户可以看到并点击这些链接，但搜索引擎无法发现，影响自然流量获取

如何检查（无需开发背景）：
查看页面源代码（Ctrl+U），搜索你的导航链接（如 /products/feature-a）
如果找不到，说明这些链接不在初始 HTML 中，存在 SEO 问题
也可以使用 Google Search Console 的"URL 检查工具"，查看"已渲染的 HTML"

常见原因：
Portal 渲染技术（Radix UI、Headless UI 等组件库）
JavaScript 动态创建（React useState、Vue v-if 等条件渲染）
客户端渲染（CSR）导致 SSR 不完整

解决方案：
最简单：在页脚添加完整的站点地图链接
最佳实践：使用纯 CSS 下拉菜单（group-hover），确保所有链接在初始 HTML 中
使用服务器端渲染（SSR），确保导航在服务器端完全渲染

重要提示：
这个问题主要影响使用 React、Vue、Next.js 等现代前端框架自建网站的开发者。如果你使用的是 WordPress、Framer、Webflow 等 CMS 平台，通常不会出现这个问题。

注意：
正文内容中的内部链接通常不会出现这个问题，因为正文在页面初始加载时就已经存在于 HTML 中。页脚链接通常也不会出现这个问题，除非使用了 JavaScript 动态加载。

📜分享点干货，我了解到的很多独立开发、AI 出海的朋友们都是用 Plausible 看数据。提起 Google Analytics 都是觉得这个东西很难用。

我自己主业是出海 Saas 产品经理，副业自建 AI 小破站出海，因此这两个统计我都会用。

客观讲，对于独立开发来说 Plausible 的确更适合，尤其是不停尝试新词站的站长，一目了然地在面板里面扫到多个站点的近期数据非常方便，加载也快，手机客户端也好用。

但是如果想要深耕一个站点，持续地分析优化站点数据、增加用户停留，那么 GA 提供的分析工具更加全面和强大。

我去年的时候刚开始接触 GA也是一头雾水，除了看看笼统的PV、UV访问数据以外，根本不知道如何用它开展分析，最多就是看看哪些国家的用户访问。

实际上 GA 真正的强大之处是需要结合 Google Tag Manager 这个工具的。比如说，想要分析自己的产品整体的转化漏斗，那么需要在 GTM 中创建一系列的「打标」（GA 和 GTM 中管这个叫 Tag），把想要观察的用户交互的行为比如点击哪个按钮、上传什么文件一个个「标」在 GTM 中，这样 GA 就能够全方面地收集产品中各个页面的行为数据，而不仅仅是页面访问、滚动高度这些泛泛的数据。

最关键的是，GA 记录的是不仅仅是「数据」，而是「数据流」。什么意思？就是说当一个用户是先到访、再注册、在创建项目、最后导出下载、点击订阅，这些被打标的 Tag 在 GA 中，是一个「流」而不是一堆孤立的点。

说的再直白一点，GA 能够知道一个用户到访以后后续都干了些什么
举个例子，我可以通过 GA 非常具体地知道，某一天点击「订阅升级」这个事件的用户中，哪些来自老用户、哪些是当天新到访的用户，哪些是从 Home 页直接点击 Pricing 升级的，哪些是在付费卡点的弹窗升级的

有了这样的能力，团队在GA【探索】这里搭建了几个漏斗看板，定期分析每个版本上线后层层操作的转化效果，不停找转化率低的那一环改进，产品数据就是这样一点一点做起来了

如果你也是对 GA 抱有偏见，希望上面这些经验能改观你对 GA 的印象

【Neon成本优化方法】

Neon有个过于离谱的细节，每个新项目的默认CU都被设置为 1-8 CU，而计费公式是：账单 = CU * 时间。也就是说，对于测试项目或者刚启动的项目，这么高的 CU 完全是在浪费钱。

我做了几个优化测试，再跑一个月看看：
- 把不重要的数据库最大 CU 调到 0.25，用量不大的调到0.25-0.5
- 所有数据库都开启Scale to zero
- 删除所有数据库的 development 分支（小项目直接用production 分支）
这几个成本优化方法在 Neon 文档里也找到了，所以肯定是靠谱的，你们也可以试试。

该说不说，最好的优化方式是生产环境的数据库不用Neon😂别看他们允许免费账号创建60个项目，这只是鱼饵罢了。

刚看了下，12月13日哥飞的朋友们年终分享交流会目前报名人数已经过500了。

另外再跟大家透露下，12 月上站 Hackathon 活动奖项情况：
特等奖一名 2000 美金/队（共 2000 美金）
一等奖五名 1000 美金/队（共 5000 美金）
二等奖十名 500 美金/队（共 5000 美金）
三等奖二十名 100 美金/队（共 2000 美金）
总共奖金14000 美金，颁给 36 个队伍

作为对比，6 月上站 Hackathon 活动奖项如下：
特等奖一名 奖金 5000美金/队（共5000美金）
一等奖三名 奖金 1000美金/队（共3000美金）
二等奖五名 奖金 500美金/队（共2500美金）
三等奖十名 奖金 100美金/队（共1000美金）
总共奖金11500 美金，颁给 19个队伍

也就是说，这次12 月的上站 Hackathon 活动，虽然特等奖的奖金变少了，但是整体奖金总额增加了，并且获奖队伍也将变多，雨露均沾，为的是让更多的团队受到鼓舞。

React 爆出高危漏洞，React 19、Next.js 15、Next.js 16所有子版本全覆盖，所以基本上今年开发的项目都要升级。

升级依赖可以针对性升级到安全修复版本，无需升级到大版本的最新版，例如：
你当前使用Next.js 15.3.0，那么升级到 15.3.6就可以，升级命令是 `pnpm i next@15.3.6`