CI/CD完全指南:持续集成与持续部署的工作原理与搭建实践
核心要点
CI/CD 是一套自动化流程:每次代码变更都会自动触发构建与测试(CI),验证通过后立即自动部署到目标环境(CD)。它要解决的根本问题是“人工操作不可靠”,能将上线风险降低 80% 以上,把发布耗时从天级压缩到分钟级。
关键数据
◆ 风险降低 80%+
◆ 发布耗时降至分钟级
◆ 已成为现代开发团队的标配
一个典型场景:一行代码引发的线上故障
你改了一行代码,在本地运行完全正常,于是信心十足地把它提交到了服务器。结果线上系统直接崩溃——那个看似无关痛痒的改动,与别人的代码发生了冲突,或者依赖的运行环境并不相同。这种经历,几乎所有写过代码的人都曾遭遇过。
传统的部署方式是:写代码 → 手动打包 → 上传到服务器 → 停止服务 → 替换文件 → 重新启动。每个环节都依赖人工操作,每一步都有出错的可能。更糟糕的是,当你终于发现问题时,那段代码已经在线上运行了好几个小时,受影响的用户可能已经达到数万人。
CI(持续集成):为每次代码提交做全面体检
CI,即 Continuous Integration(持续集成)。它的核心理念是:团队成员频繁地将自己的代码合并到主干分支,每次合并都会触发一次自动化的构建与测试流程,确保新加入的代码没有破坏已有的功能。
- 自动构建 — 将源代码编译成可运行的软件包,保证代码能够正确完成编译
- 自动测试 — 执行单元测试、集成测试,及时发现逻辑错误和边界问题
- 快速反馈 — 几分钟内就能告诉你代码是否存在问题,而不必等到上线之后
简单来说,CI 就是在你提交代码后,自动替你进行一次全方位的健康检查。有问题当场就能发现,不必等到用户被影响、被激怒之后才回过神来。
CD(持续交付/持续部署):从代码到生产环境的自动化之路
CD 通常有两种解读,但本质相同:Continuous Delivery(持续交付)或 Continuous Deployment(持续部署)。二者的区别只在于最后一环是否需要人工确认。
▲ 持续交付 — 代码通过所有测试后,会自动部署到 staging 环境,但上线到生产环境需要手动批准
▲ 持续部署 — 所有测试通过后,自动上线到生产环境,整个过程完全无需人工干预
▲ 共同前提 — 必须具备充分的自动化测试覆盖率作为保障,否则自动化部署就等同于自动制造故障
关键区别
持续交付是“一键部署”,而持续部署是“自动部署”。大多数团队只要能先做到持续交付,就已经比传统方式进步了一大截。
一个典型的 CI/CD 流水线实战:5~15 分钟完成从代码到 Staging
下面用一个最简单的例子来说明 CI/CD 在实际项目中如何运作。假设有一个三到五人的 Web 应用团队。
Claude Code 实战复盘:从 Vibe Coding 到 Agentic Engineering,我的血泪教训与工作流升级
2025 年 2 月,Andrej Karpathy 在推文中抛出一个新词——“Vibe Coding”(氛围编程),意味着一种全新的编程方式:完全凭感觉,用自然语言向 AI 描述需求,“忘掉代码的存在”。这条推文瞬间引爆了开发者圈。短短几周,Y Combinator 里 25% 的创业公司已经开始用这种方式写代码。整个社区都在沸腾:AI 终于让编程变成了“动动嘴皮子就行”的事。
仅仅一年后,Karpathy 自己却说:Vibe Coding 这个词已经过时了。 他提出一个新概念——“Agentic Engineering”,即智能体工程。究竟发生了什么?为什么“开口就能写代码”这么爽的事,不到一年就被认为不够用了?
我使用 Claude Code 做日常开发已有大半年,完整经历了从“天哪这也太爽了”到“等等,好像哪里不对”再到“原来如此”的过程。这篇文章不是概念科普,而是踩了无数坑之后的真话。
Vibe Coding 的爽感,真实不虚
先说好的一面。Vibe Coding 确实爽,特别爽。
我第一次用 Claude Code 大概在去年下半年。在此之前我用过 Copilot、Cursor,体验就是“有个聪明的补全工具”。但 Claude Code 完全不同——它在终端里直接操作你的整个代码仓库。你说一句“帮我把这个项目加上用户注册功能”,它就自己去读文件、理解架构、写代码、跑测试、修 bug,你在一旁端着咖啡看戏就行。那种感觉就像从手动挡直接切换到了自动驾驶。
Karpathy 说过一段非常精准的话:
“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”
忘掉代码的存在——这句话太对了。你不需要操心用什么设计模式,不用纠结变量命名,更不需要在脑子里模拟程序的执行流程。你只需要说出你想要什么,剩下的全部交给 AI。
Claude Code连接DeepSeek V4终极指南:开源工具CC-Switch配置全攻略
接续上篇安装教程,当你安装好Claude Code后,很可能兴冲冲地打开终端输入claude——结果却卡在要求登录Anthropic账号的界面。即便跳过登录,你又会遭遇另一个棘手问题:Claude Code默认只认Anthropic自家的模型,直接把DeepSeek的API地址填进去是无法工作的。别灰心,这篇续章将手把手带你用开源工具CC-Switch突破限制,让Claude Code顺利调用DeepSeek V4。
直接配置DeepSeek为何频频受阻?两大核心障碍解析
不少用户尝试在~/.claude/settings.json里设置环境变量来指向DeepSeek:
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.deepseek.com",
"ANTHROPIC_API_KEY": "你的Key",
"ANTHROPIC_MODEL": "deepseek-chat"
}
}
实际测试下来,你会发现两个关键难点:
障碍一:模型名称白名单校验
Claude Code内部固化了模型名白名单,只认以“claude-”开头的标识符。若传入deepseek-chat,它会在本地就抛出“模型不存在”的错误,根本不发起实际请求。
障碍二:API协议格式不兼容
即使想办法绕过了名称检查,Claude Code发送的是Anthropic Messages API的请求格式,而DeepSeek兼容的是OpenAI Chat Completions格式,两者的请求体和响应结构截然不同,无法直接对话。
要同时攻克这两个难关,就需要一个**“中间人”——它接收Claude Code的请求,进行格式转换后转发给DeepSeek,再把响应翻译成Claude Code能识别的格式返回。这个中间人便是CC-Switch**。
认识CC-Switch:Claude Code模型切换利器
CC-Switch的全称是Claude Code Model Switch,是一个开源项目(GitHub: win4r/CC-Switch),由社区开发者维护,专门用来让Claude Code调用非Anthropic的模型。
工作原理简述:
- 在本地启动一个HTTP代理服务(默认监听127.0.0.1:15721)
- Claude Code的所有请求都发送到这个本地代理
- CC-Switch接收Anthropic格式的请求,将其转换成OpenAI格式
- 转发给DeepSeek(或任何兼容OpenAI接口的国产大模型)
- 收到响应后,再转回Anthropic格式,返回给Claude Code
项目亮点:
- 完全开源免费,MIT协议
- 跨平台支持Windows、Mac、Linux
- 内置多种国产模型配置模板(DeepSeek、通义千问、智谱、文心一言等)
- 图形化操作界面,无需编写代码
- 支持多Provider灵活切换
- 当前最新版本:v3.14.1
💡 通俗理解:CC-Switch就像是Claude Code与DeepSeek之间的实时翻译官——双方的语言不同,翻译官在中间完成双向转译。
安装CC-Switch的两种方式
方式一:从GitHub下载安装包(推荐新手)
访问 https://github.com/win4r/CC-Switch/releases ,根据你的系统选择对应的安装包:
- Windows → 下载
CC-Switch-v3.14.1-Windows.msi - Mac (Intel) → 下载
CC-Switch-v3.14.1-x64.dmg - Mac (苹果芯片) → 下载
CC-Switch-v3.14.1-arm64.dmg - Linux → 下载
CC-Switch-v3.14.1.AppImage
下载后双击安装,按向导完成即可。
从AI旁观者到一人军团:三年亲历总结的十个使用能力等级
今天想聊点有意思的事。
前段时间出差,和一帮许久未见的老朋友吃饭,席间自然而然地聊到了AI。
一个朋友兴奋地说,他用AI帮老婆做了一份结婚纪念日的小贺卡,效果炸裂,老婆直接看哭了。
另一个朋友则接过话头:“你这还只是入门,你真应该建一个项目,把你们从恋爱到结婚的所有故事全喂进去,让Agent自己读完之后再去写,那才叫神作。”
说着说着,话题就滑到了做PPT、查资料上,有人开始吐槽:“现在的AI根本没法用,一本正经地胡说八道,全在瞎编。”
马上就有人反驳:“都2026年了,你能不能换点好用的AI?根本不可能。”
争论随之升级,每个人都觉得自己才是真正的AI高手。
混乱中,隐约听到隔壁桌也在谈AI,一个说用AI学习和查资料,另一个则在科普小龙虾。
那顿饭吃得我有点恍惚。
其实大家心里都清楚,同一个AI、同一个Agent,不同的人用出来的效果天差地别。可这个“差”到底差在哪里?怎么量化?我们自己现在到底处在什么阶段?下一步又该怎么走?
经常有人问我:“教练,我想学AI,到底该怎么开始?”每次听到这种问题我都头疼,因为这个问题实在太过宏大。
饭局回来的路上,我脑子里突然冒出一个想法。
如果把这条AI使用之路具象化,变成一种类似打游戏升级等级的过程,会怎样?如果AI也有“熟练度”这个概念,它应该怎么分等级?
我花了好长时间,把这三年来观察到的形形色色的人——同事、公众号留言区的读者、各种场合里聊过天的朋友——全部在脑子里过了一遍。
最终,我提炼出了四个递进的维度,这四个维度共同构成了AI使用度的十个等级。
第一个维度是可控性。从最初觉得AI胡编乱造、离题万里,到慢慢知道怎么约束它,怎么喂给它准确的上下文,怎么设计“缰绳”让它精准产出。
第二个维度是广度。从只在自己熟悉的一亩三分地里打转,到借助AI开始跨行业探索,从窄视野走向广天地。
第三个维度是形态。从用对话式聊天机器人,到用能执行长程任务的智能体,从单次问答走向多步自主协作。
第四个维度是角色。从纯粹的消费者,到成为创造者,从只会套用别人的提示词,到亲手打造属于自己的技能模块。
这四个维度,共同铺就了十个等级。
它们并不是齐头并进的。你可能可控性很高,但广度很窄,整天只在自己小圈子里转;也可能广度铺得很开,什么都想试试,但角色始终停留在消费者,从没沉淀出属于自己的东西。
但综合来看,你在这四条线上所处的位置,基本就能判断出你当前处于第几级。
我写这个并不是为了制造焦虑。AI进展太快了,我只是希望,在眼下这个时间节点,你看完之后能和周围的人对一对号,知道自己在哪,也清楚下一步该往哪儿走,这才可能百尺竿头更进一步。
同时我先叠个甲:这个等级体系只是我自己为了分类、为了好玩而做的,也仅针对大多数普通的AI用户,不涉及某些特别专业的领域。如果有不同意见,那一定是你对。
如果你也有朋友想问你“怎么学AI”“怎么进步”,你也可以把这篇文章发给TA。
那,我们正式开始。
Lv.0 旁观者:隔岸观火的局外人
’ fill=’%23FFFFFF’%3E%3Crect x=‘249’ y=‘126’ width=‘1’ height=‘1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
旁观者知道“AI”这个词,也许看过一些新闻,但从未真正和任何一款大模型对过话。
这个等级听起来离我们挺远,但实际上,全球大概还有80%的人正站在这个起跑线上。
这时候我又要掏出这张经典图片了。
’ fill=’%23FFFFFF’%3E%3Crect x=‘249’ y=‘126’ width=‘1’ height=‘1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
不过在国内,这一级的人数应该已经越来越少。
如果想从旁观者跨入Lv.1,方法简单到不能再简单:你不需要纠结哪款AI最好,直接打开手机应用商店,搜“豆包”“千问”“元宝”“DeepSeek”之类,哪个图标看着顺眼就下哪一个。打开,问它一句话,随便什么都行,就算问一句“今天该穿什么”也行。
迈出这一步,你就到了Lv.1。
Lv.1 尝鲜者:刚推开大门的体验派
’ fill=’%23FFFFFF’%3E%3Crect x=‘249’ y=‘126’ width=‘1’ height=‘1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
这个阶段,你开始真正上手了。
基本用法就是:“帮我写个XX”,然后坐等收菜,AI给什么你就用什么。比如帮我写封邮件,帮我总结一下这个文档,帮我想个方案。
你不会追问,不会补充更多背景,拿到结果直接复制粘贴,能用就万事大吉,不行就直接弃用。
你对AI的评价完全像抽盲盒,它有时候很靠谱,有时候又极其不靠谱,可你说不清这到底是因为什么。
这一阶段对AI的感觉是模糊而混沌的,觉得AI有时候聪明得吓人,有时候又离谱得可笑,还没有构建起稳定的使用习惯。
通常你只会用一两个App,大概率是DeepSeek或者豆包,不太在意底层是什么模型,也不太清楚不同模型之间有什么差异。
坦率地说,这个阶段的人,AI在他手里不过是一个更高级一点的搜索引擎。
你会搜索,但你还不太会提问。
Lv.2 对话者:开始懂得「怎么问」比「问什么」更关键
’ fill=’%23FFFFFF’%3E%3Crect x=‘249’ y=‘126’ width=‘1’ height=‘1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
从Vibe Coding到Spec Coding:agent-skills用20个工程纪律驯服AI编码,星数突破33600
你是否经历过这样的场景:让AI帮你实现一个功能,它三分钟写完,跑起来居然还能用。你欣喜若狂,觉得效率瞬间翻了十倍。然而第二天你想增加一个新特性,却发现昨天的代码没有测试、没有文档,接口设计一塌糊涂。改一处坏三处,像推倒的多米诺骨牌。更离谱的是,你翻看代码时发现AI连最基本的安全检查都没做——用户输入直接拼进了SQL语句。
这种开发模式有一个名字,叫Vibe Coding:给出一个模糊意图,让AI自由发挥,只要能跑通就算完事。短期来看确实很爽,但代价是技术债务疯狂累积——Controller里塞满业务逻辑,Service里直接拼接SQL,异常被catch后只打印一句“failed”,第二天再动一发而动全身。等到真正需要维护的时候,你就会明白,“能跑”和“能交付”之间横着一条鸿沟。
而与它对立的,是Spec Coding:先定义好技术规范和代码风格,让AI始终在同一套规则下工作。说直白些,Vibe Coding是放养,Spec Coding是立规矩。

AI编码工具的能力确实越来越强,但模型越强,抄近路的毛病就越明显。拿到任务就一头猛冲,不会主动补上测试、边界、安全和可维护性。这也是AI编码最容易翻车的地方。
最近,Addy Osmani开源了一个项目:agent-skills。它将资深工程师的工作流和开发规范,封装成了20个可复用的技能包,让AI在每一个开发阶段都按照工程纪律行事。

起初我以为这不过又是一套Prompt集合,等读完整座仓库的结构后,才发现它有价值的不是提示词本身,而是把工程流程拆解成了可执行的检查点。项目已经收获三万多GitHub Star,并且还在持续攀升。它不是简单地堆砌Prompt,而是把需求、计划、测试、评审、上线这些工程动作拆成可执行的流程。
即使你暂时不用AI编码工具,这个项目的设计思路也值得花时间深入理解。
本文篇幅较长,建议收藏,通过它你将彻底搞懂下面几点:
- agent-skills到底在解决什么问题:AI编码Agent为什么总是写出“能跑但不能交付”的代码。
- 20个Skill如何覆盖完整开发周期:从需求定义到上线发布的六阶段全景图。
- 在Claude Code中安装后实际效果如何:亲身体验与核心价值。
- Skill内部机制为什么远超普通Prompt:反合理化表、渐进式披露等设计的拆解。
这个项目到底在解决什么
先承认一个很多人不愿面对的事实:当前主流的AI编码Agent,默认选择的是最短路径。
所谓最短路径,就是拿到任务直接写代码,跳过需求分析、跳过设计评审、跳过测试策略、跳过安全审查。代码只要能跑起来就算达成目标。这和一个刚入职的初级开发者别无二致——甚至还不如,因为初级开发者至少还会问问前辈“这样写行不行”。
agent-skills的核心理念是:给AI立规矩,让它在每一步都按资深工程师的标准工作,而不是纵容它走捷径。

简单说,Skill不是让模型“知道更多”,而是告诉它:什么时候该做需求澄清,什么时候该写测试,什么时候必须停下来做评审。

Harness 和 Prompt/Context Engineering 的嵌套关系
从架构分层的角度看,Skills位于Harness的信息边界层和执行编排层。理解了这一定位,后续每一个Skill的设计逻辑就会非常清晰。
项目的作者Addy Osmani长期深耕Google Chrome、DevTools、Web性能以及AI开发体验等领域,很多前端和自动化开发者都间接受到过他项目的影响。如果你用过Chrome DevTools调试页面、用Lighthouse跑过性能评分、用Puppeteer做浏览器自动化,那么你早就是他作品的使用者。这些背景并非闲笔。agent-skills中的工程方法论,大多数源于《Software Engineering at Google》这本书。Hyrum’s Law、Beyoncé Rule(简单说就是:如果你喜欢它,就该给它写测试)、测试金字塔、主干开发、变更大小控制——这些都是Google内部经历过大规模验证的工程实践,而不是抽象的原则。Addy把这些实践翻译成了AI Agent可以执行的结构化工作流。
20个Skill:覆盖从想法到上线的完整链路

agent-skills围绕软件开发生命周期设计了20个Skill,分布在6个阶段。
| 阶段 | 核心目标 | 包含的 Skill |
|---|---|---|
| 定义(Define) | 搞清楚要做什么 | idea-refine、spec-driven-development |
| 规划(Plan) | 拆解成可执行的单元 | planning-and-task-breakdown |
| 构建(Build) | 按规范写代码 | incremental-implementation、test-driven-development、context-engineering、source-driven-development、frontend-ui-engineering、api-and-interface-design |
| 验证(Verify) | 证明代码是对的 | browser-testing-with-devtools、debugging-and-error-recovery |
| 评审(Review) | 上线前的质量门禁 | code-review-and-quality、code-simplification、security-and-hardening、performance-optimization |
| 发布(Ship) | 安全部署到生产环境 | git-workflow-and-versioning、ci-cd-and-automation、deprecation-and-migration、documentation-and-adrs、shipping-and-launch |
光看表格你可能会觉得不过是功能清单,但每个Skill背后的设计逻辑值得单独剖析。
火山方舟Agent Plan与Coding Plan对比:怎么选更划算?全场景AI订阅选购指南
双订阅计划全景解读
火山方舟目前采用双轨并行策略,全新上线的 Agent Plan 与持续运营的 Coding Plan 在定位、模型能力及适用场景上差异显著,且资源池相互独立。
方舟 Agent Plan:全模态智能体订阅
这是面向多模态与复杂 Agent 场景的进阶方案,深度集成了主流大模型与智能体框架。
核心模型: 涵盖 Doubao、GLM、DeepSeek、Kimi、MiniMax 等编程大模型;扩展支持 Seedance 2.0、Seedream 5.0 lite 以及向量化模型。
新增能力: 原生联网搜索、RAG(向量检索)、复杂 Agent 任务编排。
工具生态: 兼容 OpenClaw、Hermes Agent 等智能体框架,以及 Claude Code、Cursor、Cline、Kilo Code、Roo Code、OpenCode 等主流编程工具。

Agent Plan 资费(AFP 积分制):
| 套餐 | 月额度 (AFP) | 周额度 (AFP) | 五小时额度 | 视觉模型日额度 |
|---|---|---|---|---|
| Small | 20,000 | 7,000 | 2,000 | 10,000 |
| Medium | 100,000 | 35,000 | 10,000 | 50,000 |
| Large | 250,000 | 87,500 | 25,000 | 125,000 |
| Max | 500,000 | 175,000 | 50,000 | 250,000 |

卡兹克开源AIHOT:三年迭代11版,用代码替代模型终结AI信息过载
卡兹克,一名扎根AI领域的自媒体人,把自己默默打磨了三年的信息筛选工具完全开源了。这款名为AIHOT的工具,专门帮你盯紧全球AI动态,从信息汪洋里捞出真正值得关注的精品,自动过滤掉冗余噪音,最后呈上一份干净利落的AI日报。

从2月份动手到现在,评分策略整整迭代了11个版本,踩过无数深坑,才沉淀出今天这样的效果。而这背后的设计思路和教训,其实比工具本身更有嚼头。
做AI自媒体最耗神的部分往往不是写文章,而是找选题。而找选题的前提,是得先知道这个世界正在发生什么,这第一步听起来简单,实际执行起来却极其要命。AI领域每天涌出来的信息量太大了。OpenAI发个东西,官网写一遍,官方推特发一遍,山姆·奥特曼转一遍,各路KOL评论一遍,IT之家翻译一遍,同一个事件能刷出七八条重复内容。如果全部吞下去,一天光刷信息就得耗掉两三个小时,而且绝大多数内容要么重复,要么根本跟你没有关系。
卡兹克做这个工具的初衷,正是要解决这层信息筛选的痛苦。他每天都要从信息海里捞出选题,这个过程极其熬人,所以干脆自己动手做个自动化工具。他的底层逻辑非常简单清晰:先把信息来源筛选好,再从这些优质信源里把值得看的内容挑出来。控制输入的质量,把控输出的密度,就这关键两步。

在信源管理上,卡兹克目前持续监控着168个渠道,每一个都是他亲手挑选出来的。采集手段不拘一格,RSS订阅、爬HTML页面、调用API、购买三方数据接口,哪种方式效果好就用哪种。真正有趣的是他为信源划分的三个等级:T1、T1.5、T2。T1是最值得关注的一手官方信息源,比如OpenAI官方博客、Anthropic工程博客、CMU博客这些;T1.5是官方社交媒体账号,像OpenAI的推特,内容比官方网站更杂一些,权重略低;T2则是技术大牛的个人账号、KOL、科技媒体和综合资讯站。这个分级绝不是摆设,在后续打分环节直接左右权重——同一件事,T1源发出的分数天然高于T2源,官方一手信息永远比二手转述更受青睐。
接下来便进入了最折磨人的部分:怎么给每条信息打分。卡兹克最初的想法朴实无华,写一个Prompt让大模型给每条新闻打个分,设个阈值,过线的就是精选内容,听起来简单干脆。

然而第一版跑出来的结果完全没法看。极其硬核的学术论文动不动就飙到90分,他自己点开三秒就读不下去了;山姆·奥特曼转发一篇实习生写的鸡汤推文,模型能给出87分;同一件事被七家媒体报道,七条全都混进了精选列表。于是他开始往Prompt里不断堆规则:大佬转发要降分、重复事件要降分、营销软文直接压到50分以下。规则越叠越多,Prompt一度膨胀到300多行。
到3月份,他还引入了一套人类反馈标注机制,每天和同事一起标记“这条精选对不对”,系统把反馈喂回去持续进化。同时搭配内部评估体系,每次规则升级都拿过去500条新闻重新跑一遍,对比新旧版本到底谁更准。听上去是不是特别标准?模型+人类反馈+自动评估+持续迭代,教科书一般的流程。可跑了一周,他差点崩溃。规则加得越多,模型反而越笨。V7到V8那次迭代甚至出现了负向优化。他又尝试了双维度评分、实体热度感知等方案,结果全部报废。最后不得不全面回滚,推倒重来。

真正的转折点在一个瞬间到来。卡兹克突然想起自己曾经写过一篇文章,标题就叫《能用脚本就别用Agent》。这句话可以说是整个项目最核心的认知。你不能把所有工作都一股脑儿推给模型,让模型既负责打分又计算权重,既打标签又判断是否精选。什么都让模型干,模型就什么都干不好。

于是他彻底重构了整个系统。重构后的设计异常清晰:大模型只做一件事,按照Prompt对每条信息从五个维度分别打分。不打最终总分,不判断是否精选,不承担任何其他职责。Prompt从600多行直接砍到200行,模型的任务被压缩到最纯粹的状态。而打完分之后的所有事情——信源权重计算、类型加权、是否越过精选阈值——全部用代码写成明确的公式,拿着模型给出的五维分数直接套公式计算。一条信息是否进入精选,也不再由模型拍板,而是根据最终质量分,用代码判断有没有达到对应类别的精选阈值。比如OpenAI官网发的东西,60分就已经足够值得看了,而一个博主的转发评测属于二手信息,60分可能只是普通水平,不一定需要展示。这套数值设计是他用量化方式跑了上百个回测反复调出来的,后续要调整也非常简单,改一下公式里的权重或者阈值,几秒钟就能搞定。
还有一个设计令人印象深刻:事件聚类。假设昨天GPT-5.5 Instant发布了,除了OpenAI官方报道,还会有一大批媒体和个人号同时跟进。如果不做聚类,精选页面上同一个事件能刷出十几条。

卡兹克用embedding把语义相近的条目聚到一个事件簇里面,簇里选一条最权威的作为主条目,其他全部折叠收起。官方源永远拥有最高优先级——官网高于官方推特,官方推特高于意见领袖。精选页上同一件事只展示一条,点开就能看到所有相关报道。

配套的还有一项贴心小功能:AI日报。每天北京时间早上8点整,系统自动把过去24小时的精选内容按版块整理好,分为模型发布/更新、产品发布/更新、行业动态、论文研究、技巧与观点五大板块。这个日报完全不需要任何大模型来生成,因为精选、分类、翻译在信息入库的时候就已经全部完成了,日报只需把处理好的条目分桶排序,每天一秒钟搞定。思路跟前面一脉相承:能提前算好的就提前算好,绝不等到展示时再让模型临时抱佛脚。
回过头来看这趟旅程,有几个感触特别深。“能用代码就别用模型”这句话值得每一个做AI产品的人刻在脑门上。卡兹克踩过的最大的坑就是什么东西都交给模型,后来他反过来把能用代码做的全部用代码做,模型只专注于自己最擅长的那一步,效果反而大幅跃升。评分策略的迭代其实不是做加法,而是做减法。从V1到V11,真正帮他走出泥潭的,并不是往Prompt里加入更多规则,而是把Prompt从600行砍到200行,把模型的职责从“什么都干”压缩成“只干一件事”。信源比信息重要得多。与其设计复杂的过滤算法去处理劣质信源,不如一开始就只接入优质信源。168个精挑细选的信源,比10000个杂乱无章的信源要有用得多。另外,做给自己用的东西,往往比做给别人看的更靠谱。AIHOT最初就是做给自己用的,解决的是卡兹克自己最真切的痛点,每一步迭代都有明确具体的反馈,他自己就是用户,好不好用他比谁都清楚。
免费工具组合:Obsidian + Claude Code 如何让单人运营月入两万美金的知识管理体系成为现实

一句话说明:一组完全免费的工具(Obsidian 笔记 + Claude Code 编程代理)正让单人经营月入两万美元的生意变得切实可行。零员工、零运维开销、知识随时间自动累积,系统每天都在变得更聪明。
$15-20K
月收入
0
团队人数
$0
运维成本/月
一个正在发生的事实
2026 年 5 月,一篇题为“Claude + Obsidian have to be illegal”的帖子在 X 平台揽获近万点赞与七十万浏览量。作者 Leo 讲述了他的日常:早上打开电脑,Claude 已经掌握了他的身份、在手的项目、用过的工具、待办清单、写过哪些文章、有过哪些念头。这听上去像科幻里的“记忆副本”雏形,但它的技术栈简单到令人不安:一款免费笔记软件,一个免费终端工具,外加前 Tesla AI 总监 Andrej Karpathy 公开的一段提示词。全部加总,一分钱都不用花。
更值得留意的是评论区:大量用户晒出自己的数字。有人独自运营月流水 1.5 万美元的 SaaS 业务,有人用它管理横跨三个时区的自由职业项目,还有人用这套组合替代了原本需要两名全职运营的电商客服体系。这些不是推演,而是一群人在真实生产场景中使用的工具。
两款工具,一个体系
这套组合的原理比表面看到的更简洁。Obsidian 是纯本地、基于 Markdown 的笔记工具,没有任何专有格式,所有数据都是纯文本。Claude Code 是 Anthropic 推出的终端 AI 编程代理——名义上是编程助手,实际上它能读写任意文本文件。把 Claude Code 指向 Obsidian 的笔记库,它就拥有了读取并理解一切的能力。不需要 API 对接,不需要插件桥接,不需要第三方服务。文件夹就是接口,文本本身就是协议。这种直接性恰恰是它强大的根源——没有中间层,就没有中间层的故障点。
关键洞见 过去所有的“第二大脑”方案都死于维护负担——你得投入时间打标签、建链接、做分类、定期清理。AI 消除了这项“税”,让维护变成了一句指令。这才是本质变化,不是工具更好用了,而是工具的持有成本归零了。
Memex 八十年等待的历史回响
1945 年,Vannevar Bush 在《大西洋月刊》发表《As We May Think》,构想了一台名为 Memex 的机器,能存储一个人所有的书籍、档案与通信,并用微缩胶片实现自动交叉引用。他写道:“未来的人将拥有个人知识存储装置,其中文档间的关联与文档本身同等重要。”Memex 从未真正问世。不是技术上做不到——微缩胶片在当时就已存在。真正卡住的,是维护问题:谁来管理这些关联?新增文档时谁来刷新旧的索引?十年后如何确保系统还能运行?Bush 没有答案,因为答案需要一台比 Memex 本身更聪明的机器来承担维护任务。
儒家与物质主义的双重枷锁:中国人为何难以停止奔忙?

今年初,一条推特在中国互联网上激起了远超预期的涟漪。一位旅居意大利十八年的华人博主注意到,意大利人与中国人面对相同的境遇时,反应方式截然对立。这并非种族或语言的分歧,而源于更深层的文化根脉——一种由对世界的基本信念所模塑的分野。他把驱动东亚生活的力量概括为四股:儒家、物质主义、佛教与基督教。其中,儒家和物质主义的交织,被指认为中国人“永无止境地为家庭和可量化的成功而奋斗”的根源。
本文无意评判文化的优劣。以下是一个社会学视角的观察:当一个人被两股方向并不完全一致的力量同时拉扯时,他的疲惫很可能是一种结构性的产物,而不是个人选择的问题。
儒家与物质主义的汇流,造就了一个“无法停下”的社会。并非文化本身出错,而是两套驱动系统同时全速运转,不留一丝喘息的空间。
01 · 无法退出的责任契约:儒家的深层驱动力
儒家传统中最根本的推力,并非源于对成就的向往,而是源于对“失责”的恐惧。在儒家的伦理坐标中,个人的价值几乎完全取决于他在关系网络里对角色的履行程度。你是一个好儿子吗?好父亲吗?好母亲吗?这些追问拼凑成自我认同的基石。这与基督教传统中“人因信称义”的逻辑截然不同:后者提供了一种外来的拯救可能,人可以在承认自身有限性的前提下获得完整。
在儒家的世界里,不存在“够了”这个概念。孝道没有天花板,对子女的担当没有终点,维护家庭颜面的努力亦无穷无尽。社会学家将这种无边界性表述为“角色义务的无限化”:你永远可以做得更好,永远背负着亏欠,永远不该停步。这恐怕是亚洲社会中“面子”机制的心理根源。面子并非虚荣,而是社会对一个人角色履行的公开评分,它的分值永远可以继续攀升。
荷兰学者霍夫斯泰德的文化维度理论为这一图谱提供了实证框架。在“长期导向”维度上,中国得分极高。该维度最初被研究者命名为“儒家工作动力”,因它在儒家文化圈国家中表现得格外抢眼。高长期导向意味着重视坚韧、节俭、按地位排定关系次序,而“休闲并不重要”正是它的典型表征。在“放纵/克制”维度上,中国则落于“克制”一端,意味着社会规范对个体欲望的满足持约束态度。两组数据重叠,勾勒出一个高度看重未来回报、同时不鼓励当下享乐的社会结构。这恰好是“无法停下”的文化密码。
02 · 量化成功带来的无形焦虑:物质主义引擎
改革开放四十余年,物质主义作为第二股驱动力在中国社会急速膨胀。它与儒家传统形成了一种奇特的共振:儒家提供了“为家庭奋斗”的合法性,物质主义则给出了“怎样算奋斗成功”的量化标尺——房子、车子、存款、子女的教育成就、社会地位的可视化符号。
这种量化的成功标准带来了一个直接后果:社会时钟变得空前精准。什么年龄该达成什么事,正在被日渐标准化。2024年全国人口普查数据显示,初婚平均年龄从1996年的24.15岁推迟至2020年的28.67岁,晚了将近五年。然而,社会期望并未同步后移,这导致了尴尬的错位:一方面,年轻人需要更多时间完成教育和职业积累;另一方面,“剩女”这一带有贬义的标签自2007年起便被官方媒体频繁使用,指代27岁以上仍未结婚的高学历女性。社会学家洪理达(Leta Hong Fincher)在其2014年的著作《剩女》中追溯了这个术语的起源:它并非民间自发生成的词汇,而是由官方媒体系统性地散播的一种社会施压工具。
科技行业则呈现出一种平行的年龄焦虑,即“35岁危机”。2024年招聘平台Zhaoin发布的年龄歧视报告表明:35至45岁求职者投递的简历数量是35岁以下求职者的3.2倍,但获得的面试机会却不及后者的一半。拉勾招聘的调研发现,87%的程序员“严重担忧”自己在35岁后被裁或无法找到工作。2025年发表在国际期刊上的一项实证研究确认了“35岁危机”中的年龄歧视效应,数据显示这是一种可测量的劳动力市场现象,并非仅仅是主观感受。
在另一端,学生的处境同样不轻松。2019年一项涵盖22,983名中国大学生的横断面研究显示,59.9%的学生存在学业倦怠。高考作为“一考定终身”的制度性压力源,每年有超过1300万考生参与角逐,能进入985/211高校的比例不足5%。一项针对1232名江苏青少年的实证研究揭示了从学业压力到睡眠质量恶化的传导链条:学业压力经由焦虑和学校倦怠的链式中介效应,显著压低睡眠质量。这或许可以解释为何中国青少年的心理健康问题在过去十年中引起了越来越多的政策关注。
03 · 双重压境:儒家与物质主义的叠加效应
儒家驱动与物质主义驱动各自运行时,社会各有其稳态。但当两者层叠,个体便坠入双重的钳制:一个要求“为家庭无限付出”,另一个要求“用可量化的成就证明这种付出”。
工作场所是这种叠加效应最为密集的体现。根据Our World in Data的数据,中国2023年人均年工作小时数为2328小时,位居全球前列。作为参照,德国为1783小时,法国为1565小时。更值得关注的,是趋势的方向:中国的年均工作时间在1980年至2024年间增加了22%,而同一时期几乎所有OECD国家都在缩减。
“996”工作制(早九点到晚九点、每周六天)在科技行业中长期成为潜规则,尽管中国最高人民法院与人力资源和社会保障部已在2021年8月将其明确为违法。2025年9月,中国劳工观察发布的报告指出,在iPhone 17生产高峰期间,富士康工人仍旧面临工资扣留、非法超时劳动和学生工胁迫等困境,而苹果公司则声称“正在进行现场调查”。2021年,拼多多一位22岁女性员工在连续加班后猝死,触发了公众对“过劳”的广泛愤怒。
2023年发表在《欧洲应用心理学评论》上的一项实证研究(Gong, 2023)进一步揭示了加班的心理健康代价。该研究对583名23岁至45岁的中国企业员工进行了调查,发现加班通过“家庭隔离”和“孤独感”的中介效应显著加剧抑郁水平,并降低生活满意度。加班天数越多,越带有“非自愿”或“无偿”属性,心理损伤就越严重。这一结论符合直觉,但它提供的实证价值在于:加班伤害的并非抽象的健康,而是人作为社会存在的基本纽带——与家庭的联结。
这里出现了一个悲剧性的悖论:你拼命加班原是为了家庭,但加班的直接后果恰恰让你被隔绝于家庭之外。这不是个体的矛盾,而是系统内在的矛盾。
04 · “够了”的文化正当性:界限、救赎与平衡
原始推文中提出了一个值得深入比较的维度:基督教传统中“承认界限”和“外在救赎”的框架,为“够了就是够了”提供了文化合法性。在“原罪—恩典”的神学逻辑里,人无法也不必靠自身行为臻于完美,救赎来自外部。这套框架在世俗化之后,转化为休息、守护个人边界、对“无限责任”说“不”的文化权利。
但这并不意味着儒家的“无边界责任”是一种缺陷。它同样解释了中国社会何以在过去四十年里创造出人类历史上规模最大、速度最快的经济飞跃,何以家庭储蓄率居高不下,何以海外华人社群在经济成就上持续表现突出。这犹如同一把刀的两面:切菜利落,伤人也同样锋利。关键不在于评判哪一面更好,而在于承认:若一面已经割得太深,便需要另一面的存在来加以平衡。
值得留意的是,社会内部已经浮现出自我调适的迹象。2023年,超过50%的25至29岁中国人处于未婚状态,这与发达社会的趋势趋同。年轻一代正在重新界定“成功”:2025年发表在同行评审期刊上的一项追踪研究显示,年轻中国人对婚姻和生育的意愿在过去十年中持续走低,个体的价值取向(如希望同居、享受性自由)与传统孝道责任之间出现了明显的裂痕。高考报名人数在达到峰值后也开始出现结构性松动,部分家庭转而选择国际教育路径作为替代方案。“反内卷”从网络热词演变为一种真切的社会情绪。
这些变化的共同指向是:当结构性的疲惫积聚到一定程度,社会个体会通过“用脚投票”的方式来重新划定边界。文化此刻不再是静止的遗产,它在回应内部累积的压力中发生着演化。
05 · 三种可能的边界设定:为自己争取喘息的空间
对于正在承受这股双重推力的个体来说,问题并非“要不要反抗文化”,而是“如何在文化的缝隙中为自己开凿喘息的空间”。以下三种策略来自社会学观察,而非道德劝说:
第一,认清“社会时钟”是建构的产物,而非天然的铁律。 什么年龄应该做什么事,本质上是一种社会约定,不是自然法则。初婚年龄在三十年间从24岁浮动至29岁的事实本身,就说明了时钟是可调的。当足够多的个体选择调节自己的节律,时钟的整体刻度便会移动。
第二,辨别“可量化的成功”与“真实的满足”之间的距离。 物质主义提供的量化标准具有高度的可比性,这使它成为焦虑的完美载体。但一项2023年针对加班与满意度关系的研究表明,加班时长与满意度之间存在显著的负相关,且年龄越大,加班越多。数据的含义再清晰不过:加班并不能带来预期中那种由“成功”所许诺的满足感。
第三,在家庭责任与自我保全之间找到切合实际的平衡。 儒家的孝道伦理自有其深刻的价值,它维系着代际间的支持网络,也是中国社会在转型期保持稳定的重要机制。然而,无限的责任必然通向耗竭。设定边界并不意味着放弃担当,而是为了确保自己有能力持续地担当。这听来像是老生常谈,但从实证数据来看,大多数人直到枯竭殆尽才意识到边界的分量。
文化并非宿命。它是一种集体沉淀的习惯,而习惯可以由人重新书写。当足够多的人开始坦承“我不必一直奔跑下去”时,社会的平均节奏便会自然放缓。停下来审视自己的处境,比永无休止地奔跑更需要勇气。
Sources
· Gong, M. (2023). Overwork-induced exploitation of Chinese adults. European Review of Applied Psychology, 73(6), 100866. · Chen, Z. (2023). High-tech Companies Work Overtime Culture and Employee Satisfaction in China. AEMPS, 27(1), 132-142. · Zhao, B. & Hu, P. (2024). The longitudinal impact of cultural values on adaptation among ethnic minority students. IJIR, 101, 102014. · Garcia-Hombrados, J. & Özcan, B. (2024). Age at marriage and marital stability. Review of Economics of the Household, 22, 297-328. · Fu, Y. (2024). The Impact of Gaokao High-Stakes Testing on Student Mental Health. RAE, 3(5), 23-32. · Wang, H. & Fan, X. (2023). Academic Stress and Sleep Quality among Chinese Adolescents. Int. J. Environ. Res. Public Health, 20(3), 2452. · Hofstede, G. (2001). Culture’s Consequences, 2nd ed. Sage. · Hong Fincher, L. (2014). Leftover Women: The Resurgence of Gender Inequality in China. Zed Books. · China Labor Watch (2025). Foxconn Report. Bloomberg, 25 Sep 2025. · Our World in Data / OECD. Average annual working hours per worker, 2023. · National Bureau of Statistics of China. China Population and Employment Statistics Yearbook 2023. · Lagou Zhaopin (2023). Age Discrimination Report. Cited in chinastrategy.org. · MDPI (2025). Declining Aspirations for Marriage and Parenthood Among Young Women and Men in China.
无需WSL!Windows原生环境零基础安装OpenClaw(龙虾)完整教程
昨天我们分享了在 Windows 的 WSL 下利用 Ubuntu 终端部署 OpenClaw 的方法——本质上是借了一个 Linux 的壳来运行。有朋友反馈:能不能直接在 Windows 原生环境里安装,不绕弯子?
今天这篇就是给你的答案。
不用 WSL,不需要 Linux 基础,打开 PowerShell,就能在纯粹的 Windows 系统里把“龙虾”养起来。命令虽然和之前不同,但思路一致,跟着步骤走,半小时内基本都能跑通。
今天这一篇是 Windows 原生篇:完全依靠 PowerShell 终端命令,不依赖任何额外的环境。三篇文章覆盖三种系统,核心目标统一:让你在自己的电脑上顺利跑起“龙虾”🦞。
本次 Windows 本地安装前提:
- 系统版本:Windows 10(版本 2004 或更高)或 Windows 11,并且必须是 64 位系统
- 网络条件:安装过程需要科学上网,用于拉取安装包
1. 安装 Node.js
(1)按下 Win + X,选择 PowerShell(管理员) 并运行:
winget install OpenJS.NodeJS.LTS
(2)也可以直接访问 Node.js 官网下载:
https://nodejs.org/zh-cn/download/
根据系统类型选择:
Windows 用户:下载 “LTS” 版本的
.msi安装包(推荐 64 位)按照安装向导操作
重点:在 Custom Setup(自定义安装)页面,务必勾选 “Add to PATH” 选项(或显示为 “Will be installed on local hard drive”),这样后续才能全局调用 Node。