2026/01/10 开源 1 周就 1.3K+ Star！让 AI 帮你盯盘, 不错过投资机会

Share

开源 1 周就 1.3K+ Star！让 AI 帮你盯盘, 不错过投资机会

昨天在社区里面, 看到一个叫帖子介绍一个开源项目 daily_stock_analysis 的项目, 作用就是让”AI 帮你盯盘”. 解决了广大群众忙于工作而错过盯盘, 而痛失几十w的问题.

这项目才开源 1 周, Star 已经 1.3K+ 了.

intro

1
2
3

开源地址：https://github.com/ZhuLinsen/daily_stock_analysis

核心功能

  • AI 决策仪表盘

相信不少人手里都有几只股票, 特别是最近大A异常火爆, 平时没时间天天盯盘的应该不在少数.

它是一个基于 AI 大模型的 A 股自选股智能分析系统, 每日自动分析并推送决策仪表盘到企业微信, 飞书, Telegram 或邮箱.

说白了, 就是给 AI 装上一双眼睛, 让它帮你盯着股市, 每天收盘后自动给你生成一份专业的分析报告.

dashboard

这个项目的核心逻辑其实就三步：

看（See）：通过 AkShare, Tushare 等多数据源获取实时行情和新闻.

想（Think）：把数据扔给 Gemini 等大模型, 让它分析技术面, 筹码分布, 舆情情报.

推（Push）：生成决策仪表盘, 自动推送到你的企业微信, 飞书, Telegram 或邮箱.

  • 买卖点位精准建议

AI 会给你一句话核心结论：买入/观望/卖出, 还要给你精确的买卖点位.

比如：买入价, 止损价, 目标价, 三位一体, 明明白白.

  • 交易理念内置

这个项目最牛的地方在于, 它内置了科学的交易理念.

严禁追高：乖离率超过 5% 自动标记危险, AI 会直接告诉你别追.

趋势交易：只有 MA5 > MA10 > MA20 多头排列才建议买入.

检查清单：每项技术条件用 ✅⚠️❌ 标记, 一目了然.

  • 大盘复盘功能

除了自选股分析, 它还能每天自动生成大盘复盘.

主要指数涨跌, 市场概况, 板块表现, 北向资金流向, 应有尽有.

review

  • 零成本纯白嫖

这个项目更吸引人的点在于——它可以是的不花钱.

GitHub Actions 免费运行, 不用买服务器.

每天工作日 18:00 自动执行, 你只需要打开手机就能看到分析报告.

run workflow

Fork 一下仓库, 配置几个 API Key, 就完事了.

剩下的 AI 分析, 数据抓取, 报告生成, 消息推送, 全部自动化.

Google AI Studio 提供的免费额度, 个人使用完全够用.

当然, 如果你想用 DeepSeek, 通义千问之类的国产大模型, 它也支持 OpenAI 兼容 API.

数据源也灵活, AkShare（免费）, Tushare, Baostock, YFinance, 新闻搜索都能用 Tavily, SerpAPI. 就是哪个免费用哪个, 灵活度很高.

推送渠道更不用说, 企业微信, 飞书, Telegram, 邮件, 想推哪推哪.

甚至支持自定义 Webhook, 钉钉, Discord, Slack, Bark 都能接.

如何使用

作者在项目的 README 上有详细的说明. 这里我简要说明一下

Github Action

第一步：Fork 仓库

点击右上角 Fork 按钮, 把项目 Fork 到你自己的 GitHub 账号下.

第二步：配置 Secrets

进入你 Fork 的仓库 → Settings → Secrets and variables → Actions → New repository secret.

必填项就两个：

GEMINI_API_KEY：Google AI Studio 获取免费 Key.

STOCK_LIST：你的自选股代码, 比如 600519,300750,002594.

通知渠道至少配一个, 比如企业微信的 Webhook URL.

第三步：启用 Actions

进入 Actions 标签, 点击 I understand my workflows, go ahead and enable them.

第四步：手动测试

Actions → 每日股票分析 → Run workflow → 选择模式 → Run workflow.

这时候, 你就会在企业微信里收到第一份 AI 分析报告了.

也可以选择本地运行

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 克隆仓库
git clone https://github.com/ZhuLinsen/daily_stock_analysis.git
cd daily_stock_analysis

# 安装依赖
pip install -r requirements.txt

# 配置环境变量
cp .env.example .env
vim .env  # 填入你的 API Key

# 运行
python main.py                    # 完整分析
python main.py --market-review    # 仅大盘复盘
python main.py --schedule         # 定时任务模式

docker 方式

1
2
3
4
5
6
7
# 配置环境变量
cp .env.example .env
vim .env

# 一键启动
docker-compose up -d

用的都是免费的 API 和 GitHub Actions, 真正的零成本纯白嫖.

对于咱们这些平时要上班, 没时间天天盯盘的打工人来说, 确实有点东西.

或者你们已经在用类似的工具了？评论区聊聊, 看看还有没有其他好东西.

2026/01/10 48小时狂揽百万赞助, Tailwind的生死劫后余生!

Share

48小时狂揽百万赞助, Tailwind的生死劫后余生!

tailwind__sponsor_cover_image

48小时, 在2026年1月的第一个周末成为了Tailwind Labs的救命稻草.

就在前, 这家拥有80万GitHub Star的前端框架巨头刚刚宣布裁员75%的工程师团队, 创始人Adam Wathan公开承认营收暴跌80%, 运营资金仅能维持6个月.

然而, 谁也没想到的是, 就在Adam披露危机后的48小时内, 科技圈上演了一场”集体救援行动”.

豪门的集体入场

1月8日这一天, 注定要成为Tailwind商业上的一个转折点.

Vercel CEO Guillermo Rauch在X平台上率先宣布: “Vercel将正式赞助tailwindcss.com, 这是毫无疑问的. 我们整个社区和行业都欠@adamwathan团队很多. Tailwind现在已经是最基础的网络基础设施了(它修复了CSS).”

紧接着, Google AI Studio的产品主管Logan Kilpatrick宣布: “我很高兴地宣布我们(@GoogleAIStudio团队)现在成为@tailwindcss项目的赞助商, 很荣幸能够支持他们, 并找到更多方式共同帮助建设者生态系统.”

AI代码生成平台Lovable的创始人Anton Osika更是直言: “Lovable上的每个应用都使用Tailwind, 我们欠他们很多. 我们现在正在赞助他们, 我真诚地鼓励其他创始人都这么做.”

就在同一天, Gumroad, Supabase, Macroscope, Profound等公司纷纷宣布成为Tailwind的合作伙伴.

创始人 Adam随后也在 X 平台上确认了这些信息, 并对一一做出感谢.

tailwind_partner

这是一份令人惊讶的救援名单:

  • Google AI Studio - 全球最大的AI公司之一
  • Vercel - 估值数十亿美元的部署平台
  • Lovable - 据称ARR已达2.5亿美元的AI建站平台
  • Supabase - 开源Firebase替代品, 早期Tailwind大客户
  • Gumroad - 创作者经济平台, Adam创业第一单收入来源

Tailwind的合作伙伴级别赞助费用是每月5000美元, 年化为6万美元. 如果这7家公司都按此级别赞助, 单这一项就能带来42万美元的年收入.
tailwind_sponsor

如果按1月8前公司年度赞助收入大约在100万美元左右. 这意味着, 48小时的集体救援, 可能直接将Tailwind的年化赞助收入提升了30%-40%.

迟到的正义, 还是被迫的良心?

但这场”救援行动”, 看似温暖, 背后确实更具体的现实.

让我们看看时间线: Tailwind的文档流量从2023年初就开始下滑, 到2026年已经下降了40%. 在这整整三年时间里, 那些大量使用Tailwind的AI公司, 有谁站出来赞助过?

Lovable这个AI建站平台, 每个生成的应用都用Tailwind, 据Hacker News用户估算, 其ARR已达2.5亿美元. 但在这次危机之前, 他们没有给Tailwind贡献过一分钱.

Google的Gemini, OpenAI的ChatGPT, Anthropic的Claude, 这些AI工具每天都在生成数百万行Tailwind代码, 它们的训练数据直接来自Tailwind的公开文档. 但这些数十亿美元估值的AI公司, 没有想过给Tailwind分一杯羹.

这就像你种的树被别人砍了卖木材, 等树快死了, 他们才想起来给你浇点水.

更现实的是, 这场雪中送炭的“救援”的本质, 是科技巨头们可能意识到: Tailwind不能倒, 因为倒了可能会损害他们自己的利益.

Vercel的CEO Guillermo Rauch说得很直白: “我已联系Adam, 探索如何使这成为更长期的承诺.”

强调这不是慈善, 这是战略投资. Tailwind倒了, Vercel的生态系统会受损, Google的AI工具会失去最好的代码生成基础, Lovable的产品会出问题.

他们支援Tailwind的背后, 是在拯救救自己盈利点.

AI时代的开源护城河

Tailwind的这场危机, 撕开了AI时代开源经济的残酷真相.

以前的路径: 开源免费 → 文档引流 → 付费产品转化 → 持续开发

现在的路径: 开源免费 → AI抓取文档 → AI生成代码 → 用户直接使用 → 原创者零收益

开发者再也不需要访问Tailwind的文档网站, 因为ChatGPT, Claude, Cursor会直接告诉他们该怎么写代码. 这意味着Tailwind的付费产品Tailwind UI的曝光渠道被切断了.

这不仅仅是Tailwind的问题. 所有依赖”文档经济”的开源项目都面临同样的命运.

AI带走的不仅是流量, 还有整个”免费+增值”的商业逻辑.

救援之后的疑问

Adam在收到大量赞助后很快表态: “我们被大家的支持感动得不知所措, 但我想澄清, 我们不需要被拯救. 我们依然有一个不错的生意(虽然在走下坡路), 只是不再是一个伟大的生意了. 在我们现在的规模下, 我们还好, 我们很舒服.”

他说, 在新的规模下运营, 预算减少, 但如果能找到解决方案当然好, 如果找不到, 作为一家小公司继续运营也是一个可行的路径.

进一步的问题是: 这些赞助能撑多久? 如果文档流量继续下降, 如果AI工具继续进化, 这些科技公司会持续赞助吗? 还是说, 这只是一次性的”良心发现”?

更深的困境

Tailwind的救援, 更像是回归到 开源项目的生存依赖于大公司的赞助/捐赈, 而不是自身可持续的商业模式.**

以前, 开源项目或许可以通过自己的产品和服务获得收入. 现在, 这个渠道被AI切断了. 他们只能寄希望于那些使用他们技术的公司”主动”赞助.

对于开源项目这是好还是坏呢?

开源运动的精神, 正在被AI时代的商业逻辑碾压.

最后的思考

48小时的集体救援, 应该让Tailwind暂时渡过了难关. 但这可能不是胜利, 这是缓刑.

对于整个开源社区来说, Tailwind的案例是一个警告: 在AI时代, 你的代码可以被免费使用, 你的文档可以被免费训练, 但你的收入会被切断, 除非你足够幸运, 能够引起大公司的”同情”.

当GitHub Star数超过80万, NPM月下载量超过500万, 却养不起4个工程师的时候, 我们该问的不是”为什么Tailwind失败了”, 而是”整个开源模式在AI时代还能活下去吗?”

Tailwind被救了, 但下一个Tailwind呢?

48小时的百万赞助, 换来的是下一个6个月的喘息, 又或是葬礼? 对于开源社区来说, 这场救援行动的背后, 是整个”文档经济”模式在AI时代的集体崩塌. 当转化链路被切断, 所有依赖”免费+导流”的开源项目, 都该考虑新的出路了.

2026/01/10 营收暴跌80%大崩盘, Tailwind也扛不住了!

Share

营收暴跌80%大崩盘, Tailwind也扛不住了!

cover_picture

营收暴跌80%, 在2026年第一个月成为了Tailwind送给开源社区的新年礼物, 或者说, 一枚震撼弹.

这可能是开源历史上最讽刺的一幕——当一款工具的使用率达到历史最高峰时, 它的商业命脉却被拦腰斩断.

1月7日, Tailwind Labs创始人Adam Wathan在GitHub上对一个被关闭的PR进行回复时给出的原因是: 有更重要的事情要做,没时间处理不能帮助赚钱的事情. 该回复引起了社区的不满.
close_pr

随后 1月8日, Adam继续给出了更炸裂的原因:

adam_explain

  • 营收暴跌80%, 从巅峰期的月入10万美元断崖式下跌
  • 文档流量下降40%, 使用者访问文档站次数大幅减少
  • 工程团队裁员75%, 4个工程师裁掉3个
  • 运营资金还能坚持6个月, 这是Adam在个人podcast中给出的最后期限

仅仅24小时后, 整个前端开发圈炸了.
更讽刺的对照是, Tailwind CSS的使用规模还在增长, GitHub Star数突破80万, NPM月下载量超过500万. 一切看起来都很美好, 除了钱.

越火越穷的开源

Tailwind的商业模型其实很简单: 开源框架免费, 靠文档流量导流到付费产品Tailwind UI.

这个模式在2022年效果拔群——年营收突破250万美元, 团队规模扩张到15人, Adam甚至写过《从副业到数百万美元生意》的爆款文章.

但AI改变了游戏规则.

当ChatGPT、Claude、Cursor这些AI工具能直接生成Tailwind代码时, 使用者不再需要反复查阅文档. 文档流量暴跌40%, 意味着付费转化的入口被切断了80%.

这就像你开了一家免费图书馆, 靠卖咖啡赚钱. 突然有人发明了”意念图书馆”, 所有人都不来图书馆了——虽然书还是被疯狂借阅, 但咖啡一杯都卖不出去.

文档经济的末日来了

Tailwind的崩盘可能”文档经济”模式崩溃的信号.

Vercel、Stripe、Auth0这些依赖开发者文档的公司, 同样面临流量断崖. 甚至有业内人士透露, 多个开发者工具公司的文档流量在2024-2025年间下降了30%-60%.

更致命的是, AI带走流量的同时, 它还在从根本消除了”查阅-学习-购买”的传统转化路径.

以前的开发者路径:遇到问题 → 查文档 → 看到付费产品 → 考虑购买
现在的开发者路径:遇到问题 → 问AI → 直接得到答案 → 继续写代码

付费产品可能都无法进入开发者的视野, 潜在的有能力购买用户也会逐渐消失.

开发者的真实困境

让我们换个角度, 看看那些被裁掉的工程师.

他们在GitHub讨论区留言:”为Tailwind贡献了3年代码, 收到通知时还在修bug. “

更残酷的是, Tailwind采用”终身许可制”卖UI组件库——用户付一次钱, 永久使用. 这种模式对用户友好, 但对公司来说是慢性自杀.

没有订阅收入, 没有持续性现金流, 一旦新用户增长放缓, 资金链就断裂.

有开发者在Reddit评论:”我花49美元买了Tailwind UI, 用了3年, 现在才知道我的’一次付费’可能是压垮他们的最后一根稻草. “

AI时代, 开源如何活下去？

Tailwind的困境撕开了AI时代的残酷真相:

**第一, 流量不再是护城河. ** 当AI可以直接生成代码, “文档 → 转化”的商业模式被彻底瓦解.

**第二, 免费不是好策略. ** Tailwind开源免费, 培养了百万用户, 但这些用户在关键时刻无法转化为付费客户.

**第三, 技术成功≠商业成功. ** 全球最受欢迎的CSS框架, 却养不起4个工程师, 这是开源的悲哀.

Adam在公告中写道:”我们正在探索新的商业模式, 包括订阅制、企业版、AI集成方案. “

但时间不多了. 6个月, 要么找到新出路, 要么成为AI时代的第一个牺牲品.

最后的问题

对于类似Tailwind的开源项目来说, AI不是威胁, 而是更具体的现实冲击.

当免费的午餐被AI端走, 当文档的护城河被填平, 当开发者的行为被彻底改变后, 下一个倒下的又会是谁？

或许, 真正的混乱才刚刚开始.

一夜之间, Tailwind从开源标杆变成了商业反面教材. 但比裁员更可怕的, 是整个”文档盈利模式”的崩塌. 当AI改变了开发者的行为, 所有依赖”免费+导流”模式的商业, 都该醒醒了.

参考阅读:

  • [Github PR comments for “add llms. txt endpoint for LLM-optimized documentation”] (https://github. com/tailwindlabs/tailwindcss. com/pull/2388#issuecomment-3717222957)
  • [We had six months left](https://adams-morning-walk. transistor. fm/episodes/we-had-six-months-left)
  • [受AI衝擊, Tailwind CSS工程團隊裁撤75%](https://www. ithome. com. tw/news/173261)

2022/02/22 use podman to replace docker engine

Share

背景

使用docker需要基于root账户运行历来都是个痛点, 无论是命令行的麻烦(虽然可以用alias 来消除sudo 的使用), 还是数据的owner方面, 包括导出的tar, 以及挂载的本地文件, 都会出现只有root能访问的问题, 然而最近看到一篇文章 Docker 大势已去，Podman 即将崛起, 可能是解决这个问题的方案, 然而一直没有动力, 直到最近升级了docker engine, 导致本机一致无法运行 mysql 5.6 镜像的container, 就干脆卸载了docker 和 docker-compose, 转投podman 和 podman-compose.

安装

podman
Podman官网: https://podman.io

官方提供了各种平台的安装方式, 例如 Arch Linux:

1
sudo pacman -S podman podman-compose podman-dnsname

其中podman是主程序, 后面的 podman-compose 和podman-dnsname 是替换docker-compose 用的

配置以及支持包

重点是在账户下运行podman, 因此两个额外的支持包需要安装:slirp4netns, fuse-overlayfs , 分别是支持用户空间的网络和文件系统.

另一个必须的包是 shadow-utils, 在Arch Linux中是 shadow, 安装完成后, 修改文件 (如果没有可以用root用户创建)

  • /etc/subuid

      <username>:10000:65536

  • /etc/subgid

      <username>:10000:65536

然后使用命令让podman应用上面的修改

1
podman system migrate

默认情况下用户空间的podman不能绑定本机小于1024的端口号, 如果有特殊需要, 例如443, 则可以修改kernel的参数, 对Arch linux, 创建文件 /etc/sysctl.d/podman.conf

1
net.ipv4.ip_unprivileged_port_start=443

其他

  • 支持docker hub repo, 在 /etc/containers/registries.d/somefile.conf 或者 $HOME/.config/containers/registries.conf中增加配置:
1
unqualified-search-registries = ["docker.io"]

  • 使用docker-compose.yml 无法解析service 名称

    这个通过安装podman-dnsname解决

  • 如果本机配置了代理, proxy相关的环境变量(http_proxy, https_proxy…)会默认增加到container里面, 如果这不是你想要的, 可以通过修改 /etc/containers/ 或 $HOME/.config/containers/ 中的containers.conf , 就可以解决这个

1
http_proxy = false

2022/02/15 odoo integration webauthn

Share

背景

最近由于业务需要, 要求在odoo中支持FIDO2的认证方式, 即在用户账户绑定FIDO2兼容的Authenticator(通常为USB key), 需要用户在正常的帐号密码登录之后, 使用USB key做二次身份确认.

调查研究

当前项目使用的odoo版本是14.0 community 版本, 而OCA 的14.0 版本的server-auth 项目并不包含FIDO2 或者U2F的认证支持, 不过在 12.0 版本 中发现有 auth_u2f 插件 实现, 所以决定从改造 12.0 版本的auth_u2f 开始, 最终目标是FIDO2 与 odoo14 的集成

过程

整体的改造过程如下:

准备工作

由于FIDO2认证需要网站工作在TLS/HTTPS 下, 所以本地测试需要准备:

  1. 通过openssl生成网站需要的证书和私钥:certificate.pem 以及 key.pem, 方法请自行百(goo)度(gle) , 在nginx配置中会用到

  2. 搭建一个nginx反向代理, 关键的配置如下, 其中的 proxy_set_header X-Forwarded-HTTPS on 是解决odoo redirect 操作导致浏览器使用回HTTP请求的问题

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    server {
        listen 443 ssl;
        proxy_set_header X-Forwarded-Proto $scheme;
        ssl_certificate /usr/local/nginx/cert/certificate.pem; #cert
        ssl_certificate_key /usr/local/nginx/cert/key.pem; #key
        ssl_session_timeout  5m;    #time out
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;    #supported algorithm
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;    #supported tls version
        ssl_prefer_server_ciphers on;   #use server prefered
        ...

            location / {
            proxy_pass http://localhost:8069;
            proxy_set_header X-Forwarded-HTTPS on;
        }

    }

  3. 在odoo的系统参数中配置web.base.url 以及 web.base.url.freeze

    web.base.url -> https://localhost
    web.base.url.freeze -> True

完成之后可以测试新的https . 接下来就可以开始改造认证部分

auth_u2f -> odoo14

这部分工作主要集中在 auth_u2f 到odoo 14

  1. 下载auth_u2f插件到本地的插件目录
  2. 按照插件的说明安装依赖包 pip install python-u2flib-server
  3. 去掉方法上不支持的装饰器 @api.multi
  4. 按照标准插件安装方式安装插件

不出其他意外的话, auth_u2f 应该可以在系统中运行起来, 唯一遇到的一个问题是, 给当前用户新绑定usb key的时候, 会导致当前session出现登录失败的情况, 可能导致设备绑定出现问题, 修改方式也很简单, 修改controller ,如果发现用户已经登录, 不强制验证密钥

1
2
3
4
5
6
7
@http.route('/web/u2f/login', type='http', auth='none', sitemap=False)
def u2f_login(self, u2f_token_response=None, redirect=None, **kw):
    user = request.env['res.users'].browse(request.session.uid)
    if user:
        return http.redirect_with_hash(self._login_redirect(
            user.id, redirect=redirect))

测试后发现在 Firefox中能工作正常, 不过在chrome 中发现js错误, 由u2f-api.js 代码引起, 报extension: kmendfapggjehodndflmmgagdbamhnfd 不存在, 这个扩展应该是chrome 内置的扩展, 调查后发现应该和chrome放弃U2F支持有关 Deprecate U2F API (Cryptotoken), sighhhh! 还是Firefox耿直,所以接下来势必要转战 FIDO2

FIDO2 in odoo 14

和U2F的认证方式很类似, 包含注册部分

webauthn_reg

和认证部分

webauthn_auth

改造步骤如下:

  1. 替换对应的后端和前端U2F支持库到FIDO2的支持库, 这里选用的是 py_webauthn (server) 以及 SimpleWebAuthn (client) , 安装方式请参考对应项目文档.

  2. 后端

    1. device的模型中增加 credential (可选), credential_id , 以及 credential_pub_key 字段
    2. 在设备注册response verify通过后, 从对应的verify_registration_response 中解析出credential_id 和 credential_pub_key 并保存到对应的device record中
    3. 在登录时从device record中拿到creddential_id, 作为 allow_credentials 放到AuthenticationOption中
    4. 验证时从device记录中拿credential_pub_key做验证

  3. 前端的改动就比较简单, 替换auth_u2f.js 和auth_uf_frontend.js中对应的u2f-api的register 和 sign 方法为SimpleWebAuthn的startRegistration 和 startAuthentication即可

至此chrome 和 firefox都可以支持

相关网站连接

Some useful links