35PLUS 技术博客 – 文章

程序员做独立开发三年，我总结了这 5 个反常识搞钱认知

Fri, 09 Oct 2026 21:19:32 +0800

01 | 那个决定辞职的凌晨

凌晨三点半，我盯着屏幕上第 47 次跑失败的 CI/CD pipeline，顺手打开了银行卡余额。

数字不多不少，正好够我在北京续命到下个月 15 号。

那天是我在大厂的第 1024 天——别笑，我特意看了下日历，真是个程序员会注意的数字。我当时的 title 是「高级前端工程师」，听起来挺唬人，但本质上就是一个在业务需求和祖传代码之间反复横跳的缝合怪。

我做了个决定：辞职，做独立开发。

同事说我疯了。领导说「你想清楚」。我妈说「你房贷不用还了？」

我说：我想试试，能不能用写代码的方式，给自己打工。

三年后的今天，我坐在自家书桌前（旁边就是猫砂盆，独立开发的真实办公环境），写下了这篇文章。

没有上市，没有融资，没有「年入百万」的爽文剧本。但我养活了自己，还清了房贷，存款比在大厂时多了一倍，而且——我不再害怕周一早上了。

这三年踩过的坑、交过的学费、半夜失眠想明白的事，浓缩成了下面这 5 个反常识认知。不一定全对，但每一个，都是真金白银换来的。

如果你也想过独立开发这条路，或者单纯好奇「程序员不打工能干嘛」，花十分钟看完，说不定能帮你少走两年弯路。

02 | 反常识一：技术栈越「土」，越能赚钱

颠覆性观点：追新技术的人，往往赚不到钱。

我刚独立那会儿，跟所有程序员一样，有严重的「技术焦虑症」。

Rust 火了，我学。Svelte 出了，我试。AI 编程来了，我把 Cursor 供在桌面上每天拜三拜。

然后呢？

我花了四个月，用一套极其「先进」的技术栈，做了一个谁都不需要的产品。

那个产品叫啥我不说了，怕丢人。技术选型堪称豪华：Next.js + Rust 后端 + SQLite + Tailwind + Vercel 部署，发个推特都有技术大佬点赞。

点赞数：32。

付费用户：0。

后来我才想明白一件事：用户不关心你用什么技术栈，他们只关心你能不能解决他的问题。

就像你去餐馆吃饭，你不会问厨师用的是不是分子料理设备，你只关心好不好吃、值不值这个价。

现在我选技术栈的原则就一个：哪个能让最多人最快用上的，我就用哪个。

所以我的产品，技术栈可能是 PHP + jQuery + MySQL，可能是 WordPress 套个主题，可能就是个 Notion 数据库加个表单。

很土？是。但它能赚钱。

通俗解释：你的目标是赚钱，不是写技术博客。技术是工具，不是 KPI。选工具的唯一标准是——能不能最快地把产品送到用户手里。

03 | 反常识二：代码写得越好，可能亏得越多

颠覆性观点：程序员最大的敌人，是「完美主义」。

独立开发第一年，我犯了一个经典错误：我花了六个月重构代码。

你没听错。产品还没上线，用户还没来一个，我先把代码重构成了「艺术品」。

微服务架构、设计模式、单元测试覆盖率 95%、代码审查流程齐全——就差给每行代码写首诗了。

结果是什么？

结果是我六个月没上线新功能，竞品用一堆「屎山代码」抢占了市场。

后来跟一个做 SaaS 的朋友聊天，他说了一句话让我记到现在：

「用户不会为你的 clean code 买单，但他们会为能用的产品掏钱。」

从那以后我给自己定了个规矩：MVP（最小可行产品）必须在两周内上线，不管代码多丑。

丑到什么程度？丑到我每次看自己的代码都想给自己两拳。

但你知道吗？丑代码 + 上线 = 有钱赚。

完美代码 + 没上线 = 零。

通俗解释：独立开发不是考驾照，没有人在旁边给你打分。你的考场是市场，评分标准只有一个——有没有人愿意掏钱。先跑起来，再调整姿势。

04 | 反常识三：验证想法的速度，决定了你赚钱的速度

颠覆性观点：你以为在「做产品」，其实你只是在「猜需求」。

独立开发的第二个月，我有个绝妙的 idea：做一个面向程序员的效率工具，可以自动整理 GitHub issue。

我觉得这想法太牛了，毕竟我自己就是程序员，我太了解这个痛点了。

于是我吭哧吭哧做了两个月，上线。

用户数：个位数。

后来我学乖了。

下次有个新想法，我不写代码了。我干嘛呢？

先发个朋友圈，或者在知乎写个帖子，说「我正在考虑做一个 XXX，你们觉得有用吗？」

然后看反馈。

有人留言说「这个我早就在用了」——说明市场已经有了，要么竞争太激烈，要么需求太小。

有人说「这个我确实需要，但我更想要 XXX 功能」——恭喜你，找到了真实需求。

有人说「谁在乎这个？」——好的，pass，下一个。

这个流程的成本是多少？零。不需要写一行代码，不需要部署服务器，不需要买域名。

只需要发条消息，然后闭嘴听别人说。

通俗解释：独立开发就像开餐厅。聪明的老板会先问问附近的人想吃什么，而不是闷在厨房里做一道自认为很牛但没人点的菜。验证想法，永远比实现想法更重要。

05 | 反常识四：不要把鸡蛋放在一个篮子里

颠覆性观点：只靠一个产品赚钱，和只靠一份工资打工，本质没区别。

独立开发半年后，我终于有了第一个稳定收入的产品——一个月能赚八千块。

我高兴坏了，觉得自己终于「财务自由」了（当时的标准真低）。

然后呢？

然后这个产品的核心平台改了个算法，我的流量断崖式下跌，收入直接砍掉 70%。

那天晚上我坐在电脑前，突然意识到一件事：我所谓的「独立开发」，不过是把「给一个老板打工」变成了「给一个平台打工」。

从那天起，我开始有意识地多元化收入：

产品 A：SaaS 工具，月付订阅
产品 B：信息产品（模板、教程）
产品 C：接一些定制开发的小单子
产品 D：写技术博客，赚流量和广告费
产品 E：一个看起来跟技术完全无关的细分小工具

五个收入来源，没有一个是绝对主力的。最高的占 35%，最低的占 10%。

这意味着什么？意味着哪怕某个产品突然挂了，我也不会饿肚子。

更重要的是，不同产品的用户群体互相引流，形成了一个小小的正循环。

通俗解释：如果你只有一份工资，公司裁员你就完了。但如果你有五份收入，任何一份没了，你还有四份撑着。独立开发不是换个地方打工，而是建立一个「收入系统」。

06 | 反常识五：最快的赚钱方式，恰恰是「慢」

颠覆性观点：越想快速赚钱，越赚不到钱。

独立开发第一年，我最大的焦虑是：什么时候能月入过万？

我到处搜「独立开发收入排行榜」，看别人的月报，对比自己的收入，焦虑得睡不着觉。

后来我发现了一个规律：

那些认真写用户反馈的人，一年后收入都上来了。

那些天天发「今天赚了多少钱」的人，一年后大多消失了。

为什么？

因为前者在「种树」，后者在「摘果子」——而且摘的还是别人的果子。

我有个产品，做了整整一年才达到月入三千。那段时间我每天都在怀疑人生：我是不是不适合做这个？

但到了第十八个月，这个产品的收入开始指数级增长。因为这一年里：

我根据用户反馈加了 17 个功能
我写了 80 多篇相关内容的文章
我的 SEO 排名慢慢爬到了首页
老用户在帮我做口碑传播

这些东西，没有任何一个是能「快速」完成的。

独立开发最残酷的真相是：它没有复利曲线的前半段，你什么都看不到。

但一旦过了那个临界点——

通俗解释：种一棵树，前三年你只能看到它在地底下扎根，地面上啥都没有。第四年突然开始疯长。独立开发也一样，前两年可能在积累用户、内容、口碑、信任，第三年才开始收获。问题是，大部分人在第二年就放弃了。

07 | 写在最后

写了这么多，其实核心就一句话：

独立开发不是技术的游戏，是认知的游戏。

技术再好，不懂用户，白搭。

代码再漂亮，不解决真问题，白搭。

想法再绝妙，不去验证，白搭。

我三年前的自己如果能看到这篇文章，可能会少踩很多坑，少掉很多头发（好吧，该掉的还是会掉，这是程序员宿命）。

但有些坑，可能注定得自己踩过才记得住。

如果你也在考虑独立开发这条路，或者已经走在路上了但遇到了一些困惑，欢迎来聊聊。我在知乎和公众号都在分享独立开发的日常——不是那种「月入十万」的爽文，就是一个普通程序员的真实记录：有踩坑，有收入，有焦虑，也有小确幸。

搜「独立开发实录」就能找到我。没啥大道理，就是一些过来人的碎碎念。

说不定哪天，我们就在评论区聊上了。

祝每个写代码的人，都能找到属于自己的那棵树。

慢慢种，它终会长大的。

💡 觉得有启发的话，点个赞呗。不点也行，就当是朋友间聊了个天。

头条链接打不开别乱刷！教你一招找回被下架的原文 - 今日头条

Fri, 09 Oct 2026 06:06:47 +0800

经常刷头条的朋友应该都遇见过，复制网页链接点开，页面空白、内容直接消失，今天就拿链接
https://www.toutiao.com/article/1869393565370375给大家讲清楚，为啥文章会打不开，以及实用解决办法。

不管是别人转发分享，还是自己收藏的旧文章，网页端头条链接失效是很普遍的情况。我实测这条链接，直接浏览器访问完全无法加载正文，系统判定内容解析失败，看不到任何文字、图片。

造成这种情况无非三种原因。第一，作者主动删除文章，或者设置仅自己可见，服务器直接清除对外展示数据，外网再也读不到内容。第二，文章存在违规内容，平台审核下架屏蔽，为规避风险，网页渠道全部关停访问权限。第三，头条网页端存在加载bug，网页链接依靠AJAX动态加载内容，单纯浏览器打开抓取不到后台文字，才会显示空白。

很多人遇到链接失效只会反复刷新、切换网络，折腾半天还是没用，白白浪费时间。这里分享一个百分百可行的实操方法：把链接末尾一串数字1869393565370375复制下来，打开今日头条官方APP，在顶部搜索框直接粘贴数字检索。

APP内部数据库和网页端分开，只要文章没有永久删除，通过ID搜索大概率能找到原文。如果检索依旧无结果，就代表文章已经被彻底下架，没有任何途径恢复查看。

除此之外还有两个辅助小技巧，清理头条APP缓存、更新软件版本，能减少网页跳转异常；避开早晚流量高峰时段访问，服务器负载低，链接加载成功率更高。

现在网上很多人遇到失效链接只会到处求助，其实掌握这个数字ID检索法，不用求人自己就能搞定。大家平时看到有用的干货，别只存网页链接，最好收藏进头条APP，从根源避免内容丢失、打不开的麻烦。

如何用《玉树芝兰》入门数据科学？

Thu, 08 Oct 2026 17:22:58 +0800

链接起散落的文章，给《玉树芝兰》数据科学系列教程做个导读，帮你更为高效入门数据科学。

（由于微信公众号外部链接的限制，文中的部分链接可能无法正确打开。如有需要，请点击文末的“阅读原文”按钮，访问可以正常显示外链的版本。）

问题

2017年6月以来，我陆续在自己的微信公众号《玉树芝兰》里，写了一系列数据科学教程。

这源于一次研究生课编程工作坊尝试。受D9X合伙人阎教练的创新思维训练营启发，我在课后把词云制作流程详细记录转述，分享给了大家。

没想到，这篇《如何用Python做词云？》受到了读者们非常热烈的欢迎。

此后，一发不可收拾。

应读者的要求，结合我自己的学习、科研和教学实践，我陆续分享了更多与数据科学相关的文章。

读者越来越多，我收到的问题也愈发五花八门。

许多读者的问题，我其实都已经在其他的文章里面讲解过了，因此有时用“请参考我的另一篇文章《……》，链接为……”来答复，也帮助读者解决了问题。

在建构同理心（empathy）之前，估计我会问出这样的问题：

他们为什么不翻翻我的其他文章呢？

但现在，我能感受到他们的疑惑：

我哪里知道你写过另一篇文章？

散落在各处的文章，不容易系统学习和检索。于是我在公众号里面，给不同类别的文章做了索引。

然而，这样简单的标题索引，依然无法满足许多读者的需求。

有的读者跟着教程做完了词云，发现如果对中文文本做分析，就会出现乱码：

这时候，你该怎么办呢？

更进一步，如果你希望把词云的外边框变成指定的形状，又该如何操作？

光看标题，你可能不容易发现哪一篇文章会帮助自己解决这些问题，甚至可能会选择放弃。

我决定做这个导读。

这篇文章，不再是从任务出发，简单罗列文章标题和链接；而是从先易后难的学习步骤，来重新组织文章的顺序，并简要介绍内容和提示可能遇到的问题。

希望对你的学习能有帮助。

基础入门

大部分的教程，都是在Python运行环境Jupyter Notebook下运行和演示。

安装这个运行环境，最简单的方法，就是安装Anaconda集成套件。

请先收看这个视频教程《如何安装Python运行环境Anaconda？（视频教程）》，自己尝试安装Anaconda，运行起第一个Jupyter Notebook，输出一个“Hello world!”出来。

有了这个基础，你就可以尝试不同的数据科学任务了。

我的建议是先做词云。

因为简单，而且有成就感。

跟着图文教程《如何用Python做词云？》一步步执行。用几行Python代码，你就可以做出这样的词云来。

我还专门把它升级做成了视频教程《如何用Python做词云？（基础篇视频教程）》，供你观看。

注意图文教程和视频内容并不完全一致。

视频教程目前全系列采用Python 3.6版本。

这个变化的发生，是因为技术的发展。Python已经逐步要过渡到3.X版本了。许多第三方软件包都已经宣布了时间表，尽快支持3.X，放弃2.X的支持。

其实才半年而已，你就可以感受到技术、社群和环境的变化有多快。

可是目前某些软件包（例如后面我们要提到的TuriCreate），依然只能支持2.X版本Python。

你需要暂时做个“两栖动物”，千万不要束缚自己，因为“立场原因”固执着不肯用低版本Python。这样吃亏的是自己。

怎样才能做个“两栖动物”呢？

办法之一，就是使用Anaconda的虚拟环境。可以参考《如何在Jupyter Notebook中使用Python虚拟环境？》。

你初始安装版本针对Python 2.7的Anaconda，并不妨碍你快速建立一个3.6版本Python的虚拟环境。

有了这个秘籍，你就可以在不同版本的Python之间左右逢源，游刃有余了。

如果你想做中文词云，请参看这篇文章《如何用Python做中文分词？》。你就能做出这样的词云了。

如果你希望改变词云边框外观，就参考这篇文章《Python编程遇问题，文科生怎么办？》的最后部分。

到这里，你已掌握Python运行环境安装、虚拟环境建立与使用、文本文件读取、常见软件包调用、可视化分析与结果呈现和中文分词等基本功夫了。

回头望去，是不是成就感爆棚呢？

自然语言处理

下一步，我们来尝试自然语言处理（Natural Language Processing, NLP）。

情感分析，是NLP在许多社会科学领域热门的应用之一。

《如何用Python做情感分析？》这篇文章，分别从英文和中文两个案例，分别采用不同的软件包，针对性地解决应用需求。

你只需要几行代码，就能让Python告诉你情感的取向。是不是很厉害？

有了情感分析做基础，你可以尝试增加维度，对更大体量的数据做分析。

增加时间维度，就可以持续分析变化的舆情。

《如何用Python做舆情时间序列可视化？》这篇文章，一步步指引你在时间刻度上可视化情感分析结果：

这图难看了一些。

不过我们需要容忍自己起步时的笨拙，不断迭代与精进。

希望一出手就满分，对极少数天才，确实无非是日常。

但对大多数人，是拖延症的开始。

你可能迫不及待，尝试换自己的数据做时间序列可视化分析。

不过日期数据如果与样例有出入，可能会出现问题。

这时候，不要慌，请参考《Python编程遇问题，文科生怎么办？》的第二部分，其中有详细的错误原因分析与对策展示。

看过后，分析结果图也会迭代成这个样子：

刚刚这些情感分析，其实只是二元分析（正面vs负面）。但是我们都知道，人的情感其实是多方面共同构成的。

如何从文本中，分解出多维度的情感特征变化呢？

《如何用Python和R对《权力的游戏》故事情节做情绪分析？》一文分析了《权力的游戏》中某一集剧本，你会获得这样的结果：

如果你是《权力的游戏》剧迷，请告诉我，这张图描绘的是哪一集？

先猜猜看，然后再打开文章，跟结尾做对比。

这篇文章的可视化分析部分，用的是R。

R也是数据科学领域一个非常受欢迎的开源工具。它的通用性和热度可能不如Python（毕竟Python除了数据科学，还能干许多其他的事儿），但是因为有统计学界诸多科学家的拥护和添砖加瓦，因此有非常好的一套生态系统。

到这里，你对情感分析逐渐有点儿感觉了吧？

课间答疑

随着知识、技能和经验的积累，你的疑问可能也逐渐增多了吧？

有的同学对这种教学方式有疑问——案例挺有意思，也很简单易学，但是怎么把它用到我自己的学习、工作和科研中呢？

我为你写了一篇答疑说明，叫做《文科生如何高效学数据科学？》。文中提到了以下几个方面：

如何指定目标？
如何确定深度？
如何加强协作？

提到协作，就不能不说Github这个全球最大的开源代码托管仓库了。

在咱们的教程里，也多次使用Github来存储代码和数据，以便你能够重复运行教程中的结果。

《如何高效入门Github？》一文提供了文档和视频教程资源，希望能对你掌握这个数据富矿提供帮助。

不少读者在这个阶段常提出这个问题：老师，想学Python，推荐本书呗。

看来，你已经明白了Python的好处了，对吧？

《如何高效学Python？》帮助你给自己的学习特性做出了分类。根据分类的结果，你可以选择更适合自己的学习路径。

机器学习

你可以尝试做更高级的分析了。

例如机器学习（Machine Learning）。

机器学习的妙用，就是在那些你（其实是人类）无法准确描述解决步骤的问题上，让机器通过大量案例（数据）的观察、试错，构建一个相对有用的模型，来自动化处理问题，或者为人类的决策提供辅助依据。

大体上，机器学习主要分为3类：

监督学习（Supervised Learning）
非监督学习（Unsupervised Learning）
强化学习（Reinforcement Learning）

目前本专栏介绍了前两类的一些例子。

监督学习与非监督学习最大的差别，在于数据。

数据已有标注（一般是人工赋予标签），一般用监督学习；

数据没有标注，一般只能用非监督学习。

监督学习部分，我们举了分类（classification）任务的例子。

《贷还是不贷：如何用Python和机器学习帮你决策？》中的案例，选择了贷款审批辅助决策。

具体的机器学习算法，是决策树（decision tree）。

有同学表示，绘制这棵决策树的时候，遇到了问题。

这主要是因为运行环境的差异和依赖工具的安装没有正确完成。

《Python编程遇问题，文科生怎么办？》的第一部分，对这些问题做了详细的阐述，请根据列出的步骤尝试解决。

《Python编程遇问题，文科生怎么办？》这篇文章展示给你了一种任务导向的学习方式，期望它可以提升你Python语言和数据科学学习效率。

非监督学习部分，我们讲述了《如何用Python从海量文本抽取主题？》。

文中用一种叫做LDA的聚类（clustering）方法，帮你从可能感兴趣的浩如烟海文档中，提取出可能的类别，对应的主要关键词，并且做了可视化处理。

如果你不是从海量文本归纳主题，而是希望对单一长文本提取若干重要关键词，该怎么办呢？

《如何用Python提取中文关键词？》一文会对你的任务有帮助。但注意它并不需要使用机器学习算法，而是采用相对成熟的算法来直接解决问题。

深度学习

深度学习，指用深度神经网络（Deep Neural Network）进行机器学习。

相对于传统机器学习方法，它使用的模型结构更为复杂，需要更多的数据支持，并且训练起来要消耗更多的计算资源和时间。

常见的深度学习应用，包括语音识别、计算机视觉和机器翻译等。

当然，新闻里面最爱提的，是下围棋这个事儿：

我们提供的案例，没有那么挑战人类智能极限，而是跟日常工作和生活更加相关。

《如何用Python和深度神经网络发现即将流失的客户？》为你介绍了深度神经网络的基本结构。

这篇文章通过客户流失预警的例子，讲述了使用前馈神经网络进行监督式学习的基本样例。

实际操作部分，采用Tensorflow作为后端，tflearn作为前段，构造了咱们自己的第一个深度神经网络。

《如何用Python和深度神经网络发现即将流失的客户？》一文末尾还为你提供了进一步掌握深度学习的相关资源。

如果你需要安装Tensorflow深度学习框架（Google出品哦），欢迎先阅读这篇《Tensorflow执行pip升级安装的坑》。

有了深度神经网络的基础知识，我们折腾计算机视觉。

《如何用Python和深度神经网络识别图像？》一文，举例分类哆啦a梦和瓦力这两个机器人的各种花式图像集合。

卷积神经网络(Convolutional Neural Network, CNN)这时就大放异彩了。

这篇文章，帮你分析了卷积神经网络中，不同层次（Layer）的作用。我们尽量避免用公式，而是采用图像、动图和平实的语言描述来解释。

这次我们使用的深度学习框架，是苹果的TuriCreate。在后台，我们调用了一个非常深层次的卷积神经网络，帮我们投机取巧（迁移学习），获得了非常高的分类准确率。

有的读者自己尝试，测试集准确率居然达到100%（视运行环境不同，有差异），大呼过瘾。可同时又觉得不可思议。

为了解释这种“奇迹”，同时解答读者“如何在私有数据集上以图搜图”的疑问，我写了《如何用Python和深度神经网络寻找近似图片？》。

希望读过此文，你对迁移学习（Transfer Learning）有了更深入的认识。

另一批作者又来发问了：

老师，我用Windows，死活就是装不上TuriCreate，可怎么办？

我替他们着急的时候，恰好找到了一个宝贝。于是写了《如何免费云端运行Python深度学习框架？》。

免费使用GPU，用极为简易的操作，就可以在Google云端Linux主机上部署和执行苹果深度学习框架……

听着是不是像做梦啊？

感谢Google这个为人类知识积累做出贡献的企业。

数据获取

学完深度学习之后，你会发现自己变成了“数据饥渴”症患者。

因为如果没有大量的数据，就无法支撑你的深度神经网络。

如何获取数据呢？

目前主流的（合法）方法，主要分为3类：

开放数据集下载；
API读取；
爬虫爬取（Crawling）。

《如何用Python读取开放数据？》一文中，我为你讲解了如何把开放数据集下载并且在Python中使用。

这篇文章介绍了常见的CSV/Excel, JSON和XML等开放数据文件格式的读取、初步处理和可视化方法与流程。

如果没有开放数据集整理好供你下载，网站只提供API接口，你该怎么办呢？

《如何用R和API免费获取Web数据？》一文中，我们使用R读取维基百科API，获得指定条目的访问数量记录，并且做了可视化。

希望这些文章可以帮助你免费高效获得优质数据，撑起你自己的（深度）机器学习算法。

小结

本文把《玉树芝兰》专栏目前的数据科学类文章进行了梳理和归类，建立了链接，以帮你看清它们之间的逻辑依赖关系。

目前专栏文章主要围绕以下方面展开：

基础入门；
自然语言处理；
机器学习；
深度学习；
数据获取；
答疑。

你可能早已发现，我们还有很多话题，没有来得及涉及。

别着急。

今后，本专栏会继续补充相关的内容，为你提供更多的学习素材。

35PLUS 技术博客上线

Wed, 07 Oct 2026 23:00:00 +0800

我们为什么写这个博客

35PLUS 一直在做两件事：把企业散落在各处的数据变成可检索的知识，以及让 AI 真正落在业务流程里。这个博客用来沉淀我们在落地过程中积累的方法、踩过的坑和可直接复用的配置。

内容方向

企业知识库与 RAG：切分策略、召回调优、评测方法
智能问数（BI Ask-Data）：自然语言到 SQL 的边界与工程实践
私有化部署：GPU 选型、向量库选型、合规与安全
行业方案：金融、制造、零售的真实场景拆解

关于发布方式

全部文章以 Markdown 维护，静态构建后发布到 blog.35plus.tech。没有数据库，没有后端运行时，加载快、可被完整索引。

一万篇 Markdown 之后：静态博客的性能拐点与应对

Wed, 07 Oct 2026 11:00:00 +0800

静态博客在几百篇时几乎不会遇到性能问题。但跨过某个量级后，四个原本不存在的麻烦会同时出现。

拐点一：构建耗时

这是最先暴露的问题。不同生成器在 1 万页量级的差距是数量级的：

生成器	1 万页全量构建	运行时依赖
Hugo	10–30 秒	无（Go 单二进制）
Zola	30–60 秒	无（Rust 单二进制）
Astro	3–8 分钟	Node
VitePress / Hexo	10 分钟起	Node
Jekyll	十几分钟起	Ruby

如果每天发布多次并走 CI，分钟级构建的累积成本会非常可观。这也是我们在 blog.35plus.tech 选择 Hugo 的直接原因。

拐点二：搜索索引

大多数博客主题内置 Fuse.js，实现方式是把全站内容的 JSON 推给浏览器。几百篇时这个 JSON 只有几百 KB，1 万篇时会膨胀到 20MB 以上——首屏直接被拖死。

正确做法是 Pagefind：索引在构建期生成并分片，用户搜索时浏览器只拉取命中的那几片。

hugo --minify --gc # 先构建
npx pagefind --site public # 再建索引

Pagefind 官方数据：1 万页站点的完整搜索请求总传输量在 300KB 以内，多数站点约 100KB。它还原生支持中文分词，这一点对中文博客是刚需。

拐点三：列表页与归档

如果首页渲染"全部文章"，1 万篇会生成一个巨大的 HTML。必须做两件事：

首页只取最近 20 篇，配合 featured 推荐位
归档页按 年 → 月 两级聚合，绝不做全量列表

标签页同理，每页 20 条分页。另外标签总数建议控制在 300 以内，否则要合并同义词，不然标签云本身就失去了导航价值。

拐点四：sitemap 与 feed

sitemap 由 Hugo 自动分片成 sitemap.xml + 子索引，无需手工处理
RSS 只输出最近 50 条，否则 feed 文件体积会失控，订阅客户端也会卡

目录分片同样重要

单目录文件数超过 3000 后，文件系统遍历、git 操作、编辑器索引都会明显变慢。所以内容目录要按年月分：

content/posts/2026/10/xxx.md
content/posts/2026/11/xxx.md

这个结构还有一个附带好处：date 元信息落到了路径上，即使 front-matter 缺失也能推断。

结论

万级规模下，静态站依然是最省心的方案——但前提是把这四个拐点提前处理掉，而不是等它炸了再补。

企业知识库为什么必须做 RAG，而不是直接问大模型

Wed, 07 Oct 2026 10:00:00 +0800

很多企业在做知识库时都会问同一个问题：直接把文档丢给大模型不行吗？

答案是：短期可以，长期不行。本文解释为什么 RAG（检索增强生成）不是可选项，而是必选项。

三个绕不过去的硬约束

1. 上下文窗口装不下

一份中型企业的制度、产品手册、历史工单加起来常常是几十万到几百万字。即使上下文窗口足够大，把全部内容塞进 prompt 的成本与延迟也不可接受。

2. 知识需要实时更新

模型权重是静态的。今天改了报销标准，明天就想让员工问到新答案——只有检索层是热更新的，这一点微调做不到，提示词也做不到。

3. 答案必须可溯源

企业场景里"答错了但说不出依据"是最严重的失败。RAG 天生带引用：检索到哪几段，答案就来自哪几段，可以逐条点开原文核对。

RAG 的最小可用架构

文档 → 解析 → 切片 → 向量化 → 向量库
 ↓
用户提问 → 向量检索 → 重排序 → 拼装上下文 → LLM 生成 → 带引用的答案

关键在于切片与重排序，而不是换更大的模型。我们的实测结论：

环节	对最终准确率的影响
切片策略	高
重排序（rerank）	高
向量模型选型	中
生成模型选型	中低

一个常被忽略的细节：切片不是等长切

按固定字数切是最省事、也最伤效果的方案。更好的做法是按语义边界切——标题层级、段落完整性、表格不跨片。

def split_by_semantic(doc, max_tokens=512):
 """按标题层级优先切分，超长段落再按句号降级"""
 blocks = doc.split_by_heading()
 chunks = []
 for b in blocks:
 if b.token_count <= max_tokens:
 chunks.append(b)
 else:
 chunks.extend(b.split_by_sentence(max_tokens))
 return chunks

小结

上下文窗口不是检索的替代品
热更新能力只能由检索层提供
可溯源是企业级应用的底线

RAG 的价值不在"让模型更聪明"，而在让答案可控。

向量检索够用了吗：重排序在真实业务里的收益测算

Tue, 06 Oct 2026 15:30:00 +0800

做了向量检索之后，很多人会发现一个尴尬现象：召回的 10 条里，真正有用的只有 3 到 4 条。

问题不在向量模型，而在向量检索本身的表达能力上限。

为什么向量召回会漏

向量检索把 query 和文档各压缩成一个向量，用余弦距离排序。这个过程的损失在于：

query 通常很短，语义信息稀疏
文档被压成单一向量后，细节被平均掉
一词多义、否定、数值条件几乎无法表达

举个真实 case：问"2025 年差旅标准里北上广深的住宿上限是多少"。向量检索很可能召回"2024 年差旅标准"和"北上广深办公用品采购"，因为它们整体语义接近，但都答非所问。

重排序做了什么

重排序（rerank）是第二阶段：向量先粗召回 50–200 条，再用一个交叉编码器逐条给 query-文档对打分。

graph LR
A[用户提问] --> B[向量粗召回 Top-100]
B --> C[Cross-Encoder 逐条打分]
C --> D[取 Top-5 拼装上下文]
D --> E[LLM 生成答案]

区别在于：向量检索是"各自编码再比距离"，交叉编码器是"把 query 和文档拼在一起过一遍模型"，能捕捉到向量丢掉的细粒度匹配。

实测收益

在我们的企业知识库场景（约 8 万片段）上的对比：

方案	Top-5 有用片段数	端到端延迟
纯向量检索	2.8 / 5	210 ms
向量 + rerank	4.3 / 5	480 ms

准确率提升约 54%，代价是延迟翻倍。

什么时候可以不加 rerank

不是所有场景都值得。满足以下任一条件时，纯向量检索就够了：

文档总量小（几千片段以内），召回空间本就不大
查询是导航型的（用户知道要找哪份文档），而非探索型
延迟预算极紧（如实时客服对话，<300 ms）

反之，如果是开放域问答、文档量大、允许多花 200–300 ms，rerank 的投入产出比非常高。

落地建议

粗召回数量取 50–100 就够，再往上收益递减明显
rerank 模型不需要很大，参数是向量模型的 1/3 即可
把 rerank 做成可开关的：按 query 类型动态决定是否启用

一句结论

向量检索解决"找得到"，重排序解决"排得对"。在 RAG 里，后者的收益经常被低估。

如何开发一个ai agent

Mon, 28 Sep 2026 05:15:19 +0800

文章目录

开发一个AI Agent是一个融合人工智能、软件工程和领域知识的系统性工程。以下是完整的开发指南，结合实际案例和技术选型建议：

一、AI Agent 核心架构设计

1. 感知层（Perception）

输入处理：


from transformers import AutoProcessor
processor = AutoProcessor.from_pretrained("openai/whisper-large-v3")
def process_input(input_data):
if isinstance(input_data, str):
return processor(text=input_data)
elif isinstance(input_data, bytes):
return processor(audio=input_data)
else:
return processor(images=input_data)

关键技术：
- 语音识别（Whisper/Vosk）
- 图像识别（YOLOv8/SegFormer）
- 传感器数据解析（ROS/Arduino）

2. 认知层（Cognition）

知识图谱构建：


from py2neo import Graph, Node
graph = Graph("bolt://localhost:7687", auth=("neo4j", "password"))
person = Node("Person", name="Alice", age=30)
graph.create(person)

推理引擎：
- 规则引擎（Drools）
- 符号推理（Prover9）
- 神经符号系统（DeepSeek-R1）

3. 决策层（Decision-Making）

强化学习框架：


from stable_baselines3 import PPO
model = PPO("MlpPolicy", env, verbose=1)
model.learn(total_timesteps=10000)
model.save("trading_agent")

多目标优化：
- NSGA-II算法
- 帕累托前沿分析

4. 执行层（Execution）

动作生成：


from langchain.agents import Tool
from langchain.agents import AgentExecutor
tools = [
Tool(
name="EmailSender",
func=send_email,
description="发送邮件到指定地址"
)
]
agent = AgentExecutor.from_agent_and_tools(agent=llm, tools=tools)

二、关键技术栈选型

技术方向	推荐方案	适用场景
框架	LangChain/AutoGen	快速搭建Agent原型
大模型	GPT-4/Claude 3/DeepSeek-R1	自然语言理解与生成
知识管理	ChromaDB/Weaviate	向量知识存储
推理引擎	TensorRT-LLM/vLLM	高并发推理优化
部署平台	AWS SageMaker/阿里云PAI	生产级服务部署

三、开发流程实战（以客服Agent为例）

1. 需求分析与领域建模

创建用户旅程地图（User Journey Map）

定义服务级别协议（SLA）：


response_time:
max: 2.0s
p99: 1.5s
accuracy:
intent_recognition: 95%
problem_solving: 85%

2. 数据处理管道


from nlpaug import Augmenter
aug = Augmenter([
SynonymAug(aug_src='wordnet'),
KeyboardAug(),
ContextualWordEmbsAug(model_path='bert-base-uncased')
])
enhanced_data = aug.augment(raw_dataset, num_thread=4)

3. 混合推理系统架构

是

否

用户提问

意图识别

是否需要领域知识?

查询知识图谱

大模型直接生成

结果验证

格式化输出

4. 实时性能优化

量化加速：


from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained(
"deepseek-ai/deepseek-r1",
load_in_4bit=True,
device_map="auto"
)

缓存策略：


import redis
r = redis.Redis()
def get_response(question):
cached = r.get(question[:64])
return cached if cached else model.generate(question)

四、关键挑战与解决方案

1. 长对话状态管理

解决方案：


class DialogueState:
def __init__(self):
self.history = []
self.current_step = 0
def update(self, response):
self.history.append(response)
self.current_step = len(self.history)
def get_context(self):
return " -> ".join(self.history[-3:])

2. 可信性与可解释性

技术组合：

LIME/Shap值解释

事实核查模块：


def fact_check(response):
entities = extract_entities(response)
for entity in entities:
if not kg.query(entity):
return False
return True

3. 多模态协同


import torch
from transformers import Blip2Processor, Blip2Model
processor = Blip2Processor.from_pretrained("Salesforce/blip2-opt-2.7b")
model = Blip2Model.from_pretrained("Salesforce/blip2-opt-2.7b")
def align_modalities(image, text):
inputs = processor(images=image, text=text, return_tensors="pt")
outputs = model(**inputs)
similarity = torch.cosine_similarity(
outputs.image_embeds,
outputs.text_embeds
)
return similarity > 0.8

五、测试与评估体系

1. 自动化测试框架


def test_order_processing():
agent = CustomerServiceAgent()
test_case = {
"input": "我想退上周买的手机",
"expected": ["订单号", "退货政策"]
}
response = agent.process(test_case["input"])
assert all(kw in response for kw in test_case["expected"])

2. 评估指标矩阵

指标类型	具体指标	目标值
功能性	意图识别准确率	≥92%
性能	平均响应延迟	≤800ms
可靠性	异常恢复成功率	≥99.9%
用户体验	CSAT（客户满意度）	≥4.5/5

六、部署与持续演进

1. 微服务架构部署


# Docker-compose示例
version: '3'
services:
agent-core:
image: tensorflow/serving:latest-gpu
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 2
ports:
- "8500:8500"
knowledge-api:
image: neo4j:5.12
volumes:
- ./data:/data

2. 持续学习流程


class OnlineLearner:
def __init__(self, model):
self.model = model
self.buffer = deque(maxlen=1000)
def add_data(self, data):
self.buffer.append(data)
if len(self.buffer) % 100 == 0:
self.retrain()
def retrain(self):
dataset = prepare_dataset(self.buffer)
self.model.partial_fit(dataset)

七、前沿发展方向

多Agent协作系统
- 使用博弈论实现动态协商
- 联邦学习保护数据隐私
具身智能（Embodied AI）
- 结合物理引擎（NVIDIA Omniverse）
- 三维空间感知（NeRF/Gaussian Splatting）
道德与伦理约束
- 价值观对齐（RLHF进阶版）
- 合规性验证模块

开发资源推荐：

开源框架：MetaGPT
论文合集：AI Agent Papers
实践社区：AI Agent Developers Discord

通过系统性地整合这些技术和策略，即可搭建出具备专业领域能力、可扩展且可靠的AI Agent系统。实际开发中需要重点关注领域适配性、实时响应能力和持续学习机制的设计。

智能政务新纪元：AI驱动的自动化办公革命

Mon, 03 Mar 2025 12:48:23 +0800

智能政务新纪元：AI驱动的自动化办公革命

随着信息技术的飞速发展，政务领域也迎来了前所未有的变革机遇。传统的政务工作流程繁琐、效率低下，难以满足现代社会对高效、透明和便捷服务的需求。近年来，AI技术的迅猛发展为政务自动化带来了新的曙光。本文将探讨如何利用智能化工具软件，特别是AI编程平台，来推动政务系统的全面升级，提高政府工作效率和服务质量。

一、政务自动化的背景与需求

在数字化转型的大背景下，各级政府都在积极探索政务自动化的路径。政务自动化不仅涉及日常办公事务的简化，还包括政策制定、公共服务、数据管理等多方面的优化。然而，实现这一目标并非易事，需要解决以下几方面的问题：

信息孤岛：各部门之间存在大量孤立的信息系统，导致数据共享困难，协同效率低下。
流程复杂：传统政务流程繁琐，审批环节多，耗时长，容易出现人为错误。
技术滞后：部分政府部门仍依赖老旧的信息系统，无法充分利用现代信息技术的优势。
人才短缺：具备先进IT技能的专业人才匮乏，制约了政务信息化的发展进程。

二、AI编程平台助力政务自动化

面对上述挑战，引入先进的AI编程平台成为解决问题的关键之一。以某知名AI编程平台为例，它集成了强大的自然语言处理（NLP）、机器学习（ML）以及深度学习（DL）等先进技术，能够显著提升政务系统的智能化水平。具体而言，该平台具有以下几个应用场景：

1. 智能文档处理

在政务工作中，文件处理是一项繁重的任务。通过AI编程平台，可以实现自动化的文档生成、审核、分类和归档。例如，在处理居民身份证申请时，系统可以根据用户提供的信息自动生成申请表，并进行格式检查和内容校验，确保提交材料的准确性和完整性。此外，还可以利用OCR技术识别纸质文件中的文字，将其转化为电子文档，便于后续管理和检索。

2. 流程自动化

借助AI编程平台的强大功能，可以构建智能的工作流引擎，实现从任务分配到结果反馈的全流程自动化。比如，在行政审批过程中，系统可以根据预设规则自动判断是否符合要求，并将符合条件的申请直接转入下一环节；对于不符合条件的情况，则给出具体的修改意见或退回补充材料。这样一来，既提高了审批速度，又减少了人为干预的可能性。

3. 数据分析与决策支持

AI编程平台还能够帮助政府机构更好地挖掘和利用海量的数据资源。通过对历史数据的学习分析，预测未来趋势，辅助领导层做出科学合理的决策。例如，在城市规划方面，可以通过分析人口流动、交通流量等多维度数据，为基础设施建设提供依据；在社会保障领域，利用大数据模型评估政策效果，及时调整福利待遇标准。

快速上手：通过简单的自然语言交流，用户可以直接描述需求，InsCode AI IDE会自动生成相应的代码片段，极大降低了编程门槛。
高效协作：支持多人实时在线编辑同一个项目，方便团队成员之间的沟通与合作。
持续迭代：基于DeepSeek-V3模型，InsCode AI IDE能够不断学习用户习惯，提供个性化的代码优化建议，确保每次开发都能达到最佳效果。
免费使用：无需额外申请或配置DeepSeek模块，所有功能均免费开放给用户使用。

下载链接

让我们携手共进，开启智能政务的美好未来！