我不知道自己算不算一人公司？

我问过自己这个问题很多次。

"一人公司"这个词最近两年被说烂了。每次看到有人分享这个概念，配图一般是一个人坐在笔记本前面，窗外是落日，标题写着"辞掉工作之后，我一个人养活了自己"。

我看到这种内容会有一种奇怪的感觉——不是共鸣，不是排斥，是一种说不清楚的隔阂感。

我的状态，好像确实符合"一人公司"的定义——没有团队，没有固定办公室，没有固定上班时间，收入来自我自己建立的系统，而不是来自某个雇主。但又跟那些内容描述的东西差得很远。

他们说的"一人公司"，通常意味着一个人在做一件事。

我这里是一个人在管一个生态系统。

内容在自动生成，站点在自动监控，外链在自动检查，流量数据在自动汇总，收益在不固定的时间点陆续进账——有时候凌晨两点，有时候下午三点，有时候是一笔，有时候是几笔。

我不需要盯着这台机器运转，因为盯着是低效的。我需要做的，是定期检查它有没有偏离方向，偶尔给它换零件，偶尔加一条新的 cron 任务，偶尔重新审视整个架构是不是还合理。

这不是"一个人在工作"，更接近"一个人在养一台机器，机器在工作"。

更重要的是：我不能告诉任何人我在做什么。不是因为见不得人，是因为这门生意的护城河，根本上就是信息不对称。你说出去的那一刻，护城河就开始渗水。

所以我是一个人，不是出于什么价值观，是出于生存本能。

这篇文章没有具体的域名，没有具体的账号。这不是我在藏着掖着，这是基本的操作卫生。而且文章最后有一条铁律，是这门生意里最重要的原则——我把它放在最后，是因为读完全文之后，你才会真正理解它为什么不可以打破。

第一件事：想清楚你在做什么生意

很多人做站群做着做着，会发现自己陷入了一种奇怪的困境——站越来越多，流量越来越大，但每个月的收益和工作量不成正比，系统越来越难维护，方向越来越模糊。

这种困境的根源，几乎总是同一个问题：他们搞混了"流量业务"和"盈利业务"。

流量是前提，不是结果。你可以有很多流量，但如果你没有想清楚这些流量最终往哪里走、用什么方式变成钱、哪种收入结构是你真正想建立的，流量只是一堆待转化的可能性，而不是一门生意。

所以在讲任何技术细节之前，我想先把这件事说清楚：站群依旧可以做，但你必须先想好盈利模式。

这不是废话。这是整篇文章的核心前提。

流量最好的两种站：测评站和攻略站

如果你只做一种内容站，做测评站或攻略站，是目前流量性价比最高的两个方向。

测评站的逻辑很清楚：用户在做购买决策时需要对比信息。无论是软件、硬件、服务、课程、工具，购买前搜索"best X"、"X vs Y"、"X review"的行为，是搜索意图里转化率最高的类别之一。这种流量不仅量大，而且精准——来的人已经处于购买漏斗的中后段，他们需要的是帮助决策，而不是被说服产生需求。

测评站的内容要做到让人没有理由不信任你：有真实的横向对比，有具体的使用场景描述，有优缺点的诚实陈述，有明确的推荐结论。不能全是优点，没有缺点的测评没有可信度。不能所有产品都推荐，能说"这个产品不适合这类用户"的测评，才让读者愿意把购买决定交给你。

攻略站的逻辑稍有不同：用户在遇到具体问题时搜索解决方案。游戏攻略、软件教程、旅行指南、学习路径、操作手册——这类内容有一个独特的特点：用户黏性极高，因为用户在找到有用答案之后，会把这个站记住，下次遇到同类问题还会回来。这是测评站很难建立的复访率。

攻略站的SEO特性也很好：用户搜索的关键词通常是长尾的、具体的、意图明确的，竞争相对小，但累积起来流量可观。而且攻略类内容有天然的更新需求——软件版本更新了，游戏出了新内容，旅行政策改了——这给了你持续发布新内容的理由，而持续更新是算法喜欢的信号。

这两类站有一个共同点：它们本身就是好的内容，不需要靠技巧去"骗"排名。 你做得好，Google愿意把你排上去；你做得差，再多技巧也是短命。

还有两类站被严重低估，值得单独说：小游戏站和工具站。

小游戏站的逻辑出乎很多人意料。用户打开一个小游戏，停留时间动辄十分钟、二十分钟，跳出率极低，页面停留时长是所有内容类型里最高的之一。这两个指标是算法极度偏爱的用户行为信号，意味着小游戏站的自然排名往往比同等外链水平的内容站要好得多。而且小游戏站本身的开发门槛并不高——很多游戏是现成的开源项目，你做的是找到、集成、做好SEO，而不是从零开发。

工具站更直接。一个能帮用户解决具体问题的在线工具——单位换算、文字处理、图片压缩、颜色选择器、随机生成器——功能简单到不可思议，但用户有强烈的使用需求，搜索意图极为精准，收藏和书签行为比内容站高得多。工具站的复访率是内容站的几倍，因为工具是用完还会再来用的，文章读完就离开了。

这两类站变现路径很清晰：工具站可以做订阅版解锁高级功能（天然的 SaaS 雏形），也可以做 API 接口对外付费调用；小游戏站的停留时长给了软文植入和付费解锁关卡的空间。更重要的是，这两类站的建设成本极低，维护成本也低，但它们给整个网络带来的流量信号质量非常高。

我的站群里，工具站和小游戏站占的比例不是最大的，但它们的投入产出比，是我所有站型里最高的几个。

盈利模式的层次

把流量变成钱，有不同的层次，不同层次对应不同的天花板和不同的稳定性。

最底层：广告收入。 挂展示广告，流量换CPM，简单粗暴。这是我不做的那一层。原因前面讲了：广告损耗用户体验，压低站点的权威信号，而且收益天花板极低。展示广告是流量变现的最后一个选项，不是第一个。

中间层：软文合作。 品牌方付费，你写内容推荐他们的产品或服务。这比展示广告复杂，但收益高得多，而且做好了对读者也有价值。我的规则只有一条：只做软文，不做硬广。 软文的意思是，这篇内容即使去掉推广意图，单独作为内容也是有价值的。硬广的意思是，去掉推广意图，这篇内容什么都不剩。读者和算法都能分辨这两种东西的区别。

更高层：SaaS和订阅收入。 这是我认为被大多数站群玩家严重低估的一层。

SaaS的收入结构，本质上是一种复利机制：你获取了一个用户，只要他持续使用，他就持续付钱。不是一次性的，是月复一月、年复一年的。这种收入的稳定性，和"流量→单次转化"的模式相比，是完全不同的量级。

如果你的站群里有一个垂类，你对这个垂类足够了解，你能发现一个用户反复需要但没有好工具解决的问题，那你有可能在这个基础上做一个小型SaaS工具。不一定要很复杂，有时候一个关键词追踪工具、一个内容日历生成器、一个特定格式的数据转换工具，就能支撑起一个每月稳定订阅的用户群。

这不是所有人都应该做的事，但它值得在你建立了足够的垂类认知之后，认真考虑一次。

Ghost博客：被低估的订阅收入工具

Ghost是一个我用了很久的平台，它的商业逻辑比很多人意识到的要清晰得多。

Ghost自带会员和订阅功能。你可以把你的博客做成一个部分付费、部分免费的出版物——免费内容吸引流量，付费会员获得独家内容、更深度的分析、或者一个小型社区。Ghost处理订阅支付，处理会员管理，处理邮件分发，内置SEO设置，页面加载速度也很快。

它的核心价值是：把内容本身变成产品，而不是把内容当作获取流量再变现的中间环节。

这个逻辑的魅力在于，一旦你建立了一批愿意为你的内容付钱的读者，这部分收入几乎不受算法更新的影响。Google下一次更新，你的流量可能掉一半，但你的付费订阅用户不会因为算法更新而取消订阅。

Ghost官方托管每月$9起，有自定义域名，有完整的SEO控制，有Search Console接入能力，这是它比纯免费平台的根本优势。如果你有技术能力，自托管版本的Ghost是免费的，成本只有服务器费用。

Ghost的订阅收入，叠加在站群的整体收入结构上，是一个稳定性极高的现金流来源。我认为它在整个变现体系里的地位，比大多数人给它的权重高得多。

打开思路：站群的边界比你想的宽

"站群"这个词，很多人听到之后脑子里的画面，是几百个WordPress网站，托管在不同服务器上，外链结构复杂。

这个画面是对的，但不完整。

站群的本质不是"你拥有的自建站的数量"，而是"你控制的、能产生SEO价值或流量价值的网络节点的总和"。

从这个角度出发，你会发现可以用的节点比你想象的多得多：

Ghost博客，不管是自托管还是官方托管，有自定义域名，有完整的SEO控制，内置订阅系统，是一个能同时产生流量和订阅收入的高质量节点。

Medium，拥有极高的域名权重，内容在它平台上发布，可以借助Medium自身的算法分发获得曝光。对于新内容来说，Medium发布的文章往往比一个新建的自建站更快被Google收录和展示。通过canonical链接，你可以把SEO权重指回你的主站，同时在Medium上保持曝光。

WordPress.com（注意不是WordPress.org），作为免费平台，它的子域名托管在wordpress.com下，本身有较高的域名权重。内容发布方便，不需要技术维护，可以作为网络里的轻量节点。

Google Sites，作为Google自家产品，它的内容被Google收录的速度极快，几乎没有延迟。这是它作为节点最有价值的特性——快速收录，快速产生索引存在感。

Google Blogger，同样是Google生态的产品，blogspot.com域名的历史积累权重可观，发布内容的收录速度和Sites类似，都享受Google对自家产品的收录优先级。

这些平台有一个共同的缺点：管理起来非常麻烦。

自建站可以通过统一的后端系统、标准化的API接口、脚本化的内容发布流程来管理。这些第三方平台不行——每个平台的内容管理界面不同，发布方式不同，能接入的API能力参差不齐，有些甚至根本没有开放的内容管理API，你只能手动操作。

但"麻烦"不等于"不值得"。

这些平台的价值，不在于管理效率，而在于它们自带的域名权重和分发能力。一个在Medium上发布的高质量文章，可以在没有任何外链支持的情况下，通过Medium自身的推荐算法获得数千甚至数万次阅读。一个在Google Sites上发布的内容，可以在发布后几小时内出现在Google索引里。

这些是你在一个新建的自建站上，需要花几个月时间才能建立的能力。

所以正确的使用逻辑是：这些平台不是你站群的主体，是你站群的补充节点和快速炮台。 重要内容、长期经营的资产在自建站上，需要快速获得曝光或快速建立索引存在的内容，用这些平台做辅助。

使用这些平台时，canonical链接是关键工具。它告诉Google："这个内容的权威版本在我的主站，这里是转载。"这样既能利用平台的流量分发，又不会让权重分散。

SEO 从未死去，外链从未失效

每隔一段时间，就会有人宣布 SEO 死了。AI 搜索崛起之后，这种声音又密集了一波。

我直接给结论：SEO 在 2026 年依然是内容站最重要的流量来源，外链依然是 SEO 里权重最高的单一因素，两件事都没有变，也不会在可预见的未来里消失。

这不是情怀，这是机制决定的。

Google 的核心算法依然以链接作为最重要的权威性信号。PageRank 的基本逻辑——其他值得信任的网站愿意链接到你，意味着你的内容有价值——这个逻辑没有被颠覆，只是在检测技术上越来越精密。2024 年的 Google 内部文件泄露，再次确认了外链在排名因素里的核心地位，而且文件里明确指出，来自真实网站的高质量外链，在算法中的权重远高于技术SEO和内容质量因素的加权。

AI 搜索引擎的崛起没有改变这个逻辑，反而在某种程度上强化了它。ChatGPT、Perplexity、Google AI Overview在生成回答时引用的来源，高度集中在那些在传统 SEO 里排名靠前的、有大量高质量外链支撑的权威站点。换句话说，在 AI 搜索里被引用的前提，仍然是在传统 SEO 里表现好。SEO 做好了，AI 可见性也跟着好；SEO 做得差，你在 AI 搜索里基本是透明的。

根据 Moz 的 2026 年数据，AI 搜索引擎的引用来源和 Google 有机搜索结果的重叠率大约在 10% 到 40% 之间，取决于查询类型。这意味着大量的 AI 引用来自 Google 有机排名之外的来源，但反过来说，有机排名靠前的内容被 AI 引用的概率依然远高于没有排名的内容。

SEO 的三个层次，在 2026 年的优先级是这样的：

第一层，技术 SEO：页面速度、Core Web Vitals、移动端体验、结构化数据、robots.txt 配置、sitemap 更新频率、内链结构合理性。这些是底线，不做好，其他一切都是建在沙子上。好消息是这些东西大多数可以系统化、自动化，做一次配置好之后，用 cron 任务定期监控和修复。

第二层，内容 SEO：关键词定向、搜索意图匹配、内容深度、E-E-A-T 信号（经验、专业性、权威性、可信度）、内容更新频率。这一层决定你的内容有没有资格被排名，是质量门槛。

第三层，外链 SEO：外链的数量、质量、多样性、锚文字分布、来源站点的主题相关性。这一层决定你在质量差不多的竞争对手里排第几。

很多人把精力全放在内容上，忽视外链。这是一个巨大的误区。在高竞争垂类里，内容质量是门票，外链是决胜因素。你的内容写得再好，没有足够的高质量外链支撑，你打不过那些外链更强但内容未必更好的竞争对手。

外链这个东西，到现在为止，我仍然坚持自己来做判断。"什么样的外链有价值，什么样的外链有风险"——这个判断依赖十几年积累的直觉和经验，目前还没有任何工具或 AI 系统能完全替代。我可以把外链的收集、筛选、跟踪工作自动化，但最终的决策，还是我自己来。

还有一件事需要专门说：流量来源不只是 Google。

Google 依然是主要流量来源，在大多数英文垂类里占比超过 60%，这个事实没有变。但 Bing 的份额这两年在悄悄增长，尤其是在北美和欧洲市场，Microsoft 把 Bing 深度整合进了 Copilot 和 Windows 搜索之后，Bing 的搜索量有明显提升。我的部分站，Bing 带来的流量占比已经在 15% 到 25% 之间。DuckDuckGo、Yahoo（后台其实也是 Bing）、Yandex 在特定地区的用户群里也有不可忽视的份额。

这意味着两件事：第一，你的流量统计不能只盯着一个来源，Google、Bing、DuckDuckGo、Yandex 的流量都要能看到；第二，用自建统计系统，不要依赖第三方工具。 你的流量数据是你最核心的运营情报，这份情报不应该托管在别人的服务器上。

站群节点网络在 2026 年的真实状态

每隔一段时间，就会有人宣布站群死了。它没死。但它已经不是当年那个东西了。

有一点要先说清楚：我说的站群，不是那种批量建站、堆砌低质量内容、靠数量刷存在感的模式。那种玩法确实死了，而且死得很彻底——Google 的 SpamBrain 系统对这类低质量站点网络的识别能力，在 2024 年到 2026 年之间有显著提升，处罚速度比以往更快。

我说的站群，是一个由高质量独立站组成的内容网络，每个节点都能独立存活，都有自己的真实用户价值。

这不是玩文字游戏。这是对站群本质的重新定义：网络里的每一个站，首先要是一个有价值的独立网站，其次才是网络的一个节点。顺序不能反。

2026 年还能活下来的站点网络，有几个共同特征：

域名质量是基础。节点域名必须有真实历史积累，Trust Flow 15 以上，linking root domains 20 以上，没有处罚记录，最好有 Wayback Machine 里留存的真实内容历史。一个好的过期域名，2026 年的市场价格已经比五年前贵了三倍以上，因为它越来越稀缺，也越来越难被替代。

内容质量不能偷懒。每个节点的内容，必须达到"如果只是一个独立站，它也有存在价值"的标准。不是填充内容，不是批量生成的通用稿，是真正针对这个站主题的有深度的内容。而且文章风格、体裁、语气要随内容需求自然变化，不能所有文章都是同一个模板出来的——那是机器特征，不是人类特征。

平台多样性是护城河。现代站点网络，不是"一堆 WordPress 站"，而是一个异构的节点生态：自建站（WordPress、Ghost、自研）、高权重平台（Medium、Blogger、WordPress.com）、工具站、小游戏站、Ghost 订阅博客……每个节点的形态不同，平台不同，主机不同。这种多样性本身就是稳定性的来源——没有统一的模式，就没有可被整体识别的结构性弱点。

主机分散是底线。不同国家的主机商，不同 C 类 IP 段，不同的 DNS 服务商，不同的域名注册商。一个非常常见的失误：用同一个 Cloudflare 账号管理所有域名的 DNS。Cloudflare 的数据在公开的证书透明度日志里可以被查询，这是一个明显的关联信号。分散到不同的 DNS 服务商，成本很低，消除了一个本不应该存在的风险。

绝对不卖外链。这条原则不变。短期收益，长期必死。你开始卖的那一刻，网络就不再是私人的了。

还有一个被大多数人忽视的现代实践：让每一个节点本身产生价值。

一个测评站节点，内容足够好，它有自己的自然流量。一个 Ghost 博客节点，订阅内容有价值，它有自己的付费读者。一个工具站节点，工具足够实用，它有自己的回访用户。这些节点的真实流量，是它们权威信号的核心来源，比任何技术手段都更有说服力。

做到让网络里的每一个站都不需要依靠网络才能存活，这是 2026 年站点网络的最高标准。

Token 是这个时代的原材料

我的整个运营系统高度依赖大模型 API。内容生产、关键词分析、竞品研究、内链规划——几乎所有原来需要人工判断的环节，现在都有模型在跑。

Token 是这个时代真正的原材料，就像制造业需要钢铁。我花了很长时间在系统性地压缩这个成本。

方法一：注册公司，申请云厂商创业赠金。

大多数主流 AI 平台都有针对初创企业的赠金计划。一个正式注册的公司实体，以"小型 AI 创业团队"的名义申请，通过率大概在 60% 到 70% 之间，每次额度从几百美元到几千美元不等。云厂商设立这些计划，目的就是让开发者黏在平台上，双方都没有损失，正常的商业行为。

方法二：NewAPI 做统一路由层。

我的整个 AI 调用架构，在模型之前加了一层 NewAPI 做路由和管理。NewAPI 的核心价值有两个：

第一，根据任务类型自动分发给最合适的模型。批量内容生成用便宜的小模型，深度推理和判断用大模型。路由策略跑下来，整体 Token 成本压缩 30% 到 50%。

第二，统一管理多账号、多平台的 API key，把所有来源的 key 聚合成一个统一的调用池。代码层面只需要对接 NewAPI，不需要在业务代码里到处散落各种 key 管理逻辑。

方法三：API 中转生态。

这个生态比大多数人意识到的要丰富。硅基流动、七牛云这类平台有邀请注册机制，闲鱼上有人批量出售邀请码，批量注册的免费额度加起来很可观，直接进 NewAPI 的 key 池轮询。

更重要的一个来源：基于 GPT Team 订阅的反向代理。这是目前 Token 成本最低的方案之一——通过中转层以极低的价格调用 GPT-4 级别的模型，效果够用，价格是官方 API 的几分之一。以前 Claude 和 Google 的模型也有类似的中转渠道，但现在封号越来越严重，能稳定跑的越来越少，GPT Team 的中转相对来说还是目前最优解。

用这类服务有一个细节必须注意：IP 池子的质量。中转服务如果 IP 被打标记，调用质量和稳定性都会下降，严重的直接封掉。选中转服务的时候，IP 池的多样性和干净程度，比价格更重要。

核心逻辑始终是：Token 成本是可变成本，系统设计是固定成本。在固定成本上多花一点时间，在可变成本上省下来的，是长期复利。

这台机器的骨架：Linux 和定时任务

说到系统，有一件事我一直觉得被严重低估——

很多人在讨论 AI Agent、大模型调用、自动化工作流的时候，画的架构图越来越复杂：Orchestrator、Memory Layer、Tool Registry、Reflection Loop。都对，都有价值。但真正让这些东西每天稳定运转的，是一台 Linux 服务器，和几十条定时任务。

这听起来土气。但我是认真的。

Linux 是整个系统最可靠的那一层。

不是因为它功能最强，是因为它最可预期。一条 cron 表达式，0 3 * * *，每天凌晨三点，它就跑，不需要你盯着，不受节假日影响，不受你心情影响，不受产品更新影响。你设置好，它就是一台不会疲倦的机器。

我的整个站群运营系统，本质上是一棵 cron 树：

凌晨两点，关键词排名监控脚本跑一遍。每个站的核心关键词排名数据拉下来，写进数据库，跟上周对比，异常的发通知。

凌晨三点，内容生产队列开始跑。每个站的 Agent 读取待写选题列表，调用 API 通过 NewAPI 路由生成草稿，写进内容队列，等待确认或发布。

这里有一个很重要的细节：发布时间和发布数量，都不能是固定的。

一个真实运营的人类博主，不会每天凌晨三点整准时发一篇文章，不会每周固定七篇，不会月月如一。真实的更新节奏是随机的、不均匀的、偶尔密集偶尔稀疏的。这种"不规律"本身就是真实性的信号。

所以我的内容发布环节引入了随机变量：发布时间在一个时间窗口内随机偏移，发布数量在一个范围内随机取值，不同站的发布节奏互相错开且各自独立。某个站这周发了三篇，下周可能发一篇，再下周发五篇——这才像一个真实的人在运营。

更重要的一点：文章数量宁少勿多。 一篇质量高的文章，对站点权威的贡献，远大于十篇平庸的文章。而且大量低质量内容的累积，是触发算法降权的最常见原因之一。我的队列有一个质量过滤层，生成的草稿里不达标的直接丢弃，不发布。宁可这个站这个月只发了两篇，也不发凑数的内容。

凌晨四点，外链健康检查。通过 Ahrefs 和 Majestic 的 API，拉取每个站的外链变化，标记丢失的高质量外链和新增的垃圾外链，生成日报。

早上八点，流量数据汇总。我用的是自建统计系统，不依赖任何第三方分析工具——原始数据来自服务器日志，Nginx 的访问日志直接解析，写进自己的数据库，分析脚本是自己写的。

为什么不用 Google Analytics 或者 Bing 的统计工具？原因有两个，跟我不挂 Google Ads 的逻辑是一样的。

第一，账号数量的问题。我的站群规模一旦上去，需要的 Google 账号或 Bing 账号数量是个麻烦事——批量注册就有风险，每个站单独用独立账号又要维护大量账号，成本和风险都不划算。

第二，数据主权的问题。你把流量数据交给 Google，Google 就能拿到你所有站的流量模式、用户行为、关键词表现。这些数据在 Google 手里能做什么，你无法控制。自建系统，数据在自己服务器上，粒度比任何第三方工具都细，没有外部依赖，没有任何人能从统计后台看到你在做什么。

每隔四小时，站点健康检查。每个站发一次 HEAD 请求，响应时间超过阈值的标记告警，返回非 200 状态码的立刻发通知。

每天晚上，Agent 状态更新。遍历每个站的历史内容，提取观点档案，更新到各站的 Agent 配置数据库，为第二天的内容生产准备上下文。

这棵树上还有很多枝：数据库备份、日志归档、SSL 证书到期提醒、服务器负载监控、Cloudflare 缓存刷新、sitemap 提交。

今年，我在这套 cron 树的基础上，开始搭一套基于 AI 的站群管理系统，现在还在使用和测试阶段。它已经能做不少事情：站点健康监控、内容写作调度、域名状态追踪，把原来散落在脚本日志和命令行里的状态集中到一个地方看。后续还在扩展，等跑稳了再说。

Bash 脚本是最忠诚的执行层。管理系统是最清晰的观测层。 都是自己的，没有外部依赖，没有订阅费，数据不出自己的服务器。

工程哲学：够用就行，然后蒸馏

我的整个系统设计，从第一行脚本到现在，贯穿着一个原则：够用就行，然后蒸馏。

来看这个原则在真实系统里是怎么长出来的。

最早，我的内容生产是一个 Python 脚本，大概两百行，逻辑很简单：读一个 CSV 文件里的选题，逐行调用 API，把结果写进另一个 CSV。没有队列，没有错误重试，没有速率限制，跑一半 API 报错了就崩掉，重新手动跑。

这个脚本很丑。但它在跑。

我没有停下来重构它，而是先把它能做的事做完，跑了大概两个月，积累了足够多的"这个地方很烦"的感受。

然后有一天我坐下来，问 AI：这些烦人的地方，是因为什么？

答案很清晰：没有队列，所以不能断点续跑。没有错误处理，所以一个请求失败会阻断整个任务。没有日志，所以不知道哪些任务跑了哪些没跑。

然后我只修了这三件事。新脚本三百行，多了一个 SQLite 数据库做任务队列，多了基本的错误捕获和重试，多了一个日志文件。依然很丑，但这三个问题没了。

这就是蒸馏。不是重写，是找到真正让你痛的那几个点，精准处理，其他不动。

很多人的直觉是把一切重构成"干净的"架构。我见过太多人在这一步消失：他们开始画架构图，开始研究"最佳实践"，开始考虑三年后的扩展性——然后什么都还没跑起来，热情先灭了一半。

更残忍的现实是：你精心设计的架构，面对的是一个会动的靶。你调用的 API，下个月可能改了返回格式。你依赖的平台，可能哪天调整了权限策略。你设计的流程，在真实环境里跑了三天，发现完全不是你预想的使用方式。

所以正确的姿势是：先凑合，后蒸馏，全程模块化。

模块化在我这里只有一个实际标准：换掉任何一块，系统不会整体崩。

API 挂了，换接口，其他不动。NewAPI 里的某个 key 用完了，换 key，调用层感知不到。脚本逻辑改了，只改那一个脚本，cron 调度不需要知道。某个站的内容策略调整了，只改那个站 Agent 的配置文件，其他站不受影响。某个 PBN 节点需要调整，只动那个节点，网络其他部分不感知。

把这个标准用在站群管理上来解释：每一个网站是一个独立模块，它有自己的配置文件，自己的内容队列，自己的 Agent 上下文，自己的监控告警规则。站与站之间不直接耦合——A 站的内容生产不依赖 B 站的状态，B 站的外链检查不依赖 A 站的数据。

这种设计从美学上很丑。我的代码库里有好几个版本的同一功能，有些注释是三年前写的，有些变量名很随意，有些逻辑绕了一个不必要的弯。

但它每天在跑，已经跑了很多年，中间几乎没有过需要紧急处理的故障。

跑起来的丑东西，永远比没跑起来的完美设计值钱。

Agent 的角色扮演和成长曲线

技术骨架说完了，说最有意思的那一层。

我为每一个站配备了一个 AI Agent，作为这个站的运营者。Agent 不只是一个执行工具，它是一个角色。

每个站都有自己的设定：这个站的"作者"是谁，有什么背景，在这个领域有什么独特的视角和偏好，有什么写作风格。这些设定不是装饰，是 Agent 在生成内容、决定选题、规划内链时的核心参照系。

一个测评站的 Agent，扮演的是一个在这个垂类有五年实际使用经验的资深用户，他有自己固定的测评框架，有自己重视的评分维度，也有他明确不推荐某些产品的历史记录。这个人物设定越具体，生成的内容越有辨识度，越不像一个模板输出的通用稿。

但更重要的是：这个 Agent 有成长曲线。

刚建站的时候，这个"作者"是一个新博主，内容是入门向的，选题保守，语气是分享者而不是权威。随着内容积累，他开始写更细分的话题，开始引用自己之前写过的内容，建立"观点体系"——他对某个品牌的评价是有历史支撑的，他的推荐是有前后文可以验证的。

这里有一点要说清楚：我说的"一致性"，指的是立场和观点的一致性，不是写作风格的固定。

写作风格反而不能固定。同一个站，有时候需要写深度长文，有时候需要写快速对比，有时候是问答格式，有时候是数据报告。文章体裁和语气随内容需求变化，是正常的、健康的内容生态。真正的人类博主也是这样写的，你不会每篇文章都是同一个结构同一个语气。

如果你的整个站所有文章都像是从同一个模板里出来的——同样的开头方式、同样的段落结构、同样的结尾风格——这反而是一个被识别为机器生成的特征。

E-E-A-T 框架里的"Experience（经验）"和"Trustworthiness（可信度）"，靠的是内容里有真实的使用经历描述、有具体的数据和案例、有明确的立场和理由，而不是靠文章长得像同一个人写的。

从技术上实现，是一个由 cron 任务驱动的状态管理问题：每天晚上，一个脚本遍历每个站的历史内容，提取观点档案，写进这个站的 Agent 配置数据库。第二天，Agent 在生成新内容之前，先读取这份档案，保证新内容在观点立场上与历史保持连贯，但在写作形式上根据这篇文章的目的自由选择最合适的表达方式。

驱动这一切的，不是什么复杂的 orchestration 框架，是一条每天晚上跑的 cron 任务，和一个写得不怎么好看的 Python 脚本。

GEO：写给 AI 读的优化层

GEO，Generative Engine Optimization，让你的内容被 ChatGPT、Perplexity、Gemini 这些 AI 引用。

这不是要替代 SEO，是在 SEO 之上的一层新的优化。

AI 引擎在读内容的时候，做的是"段落级检索"——把你的页面拆成一段一段，每一段独立评估它有没有资格被引用。这意味着你的每一个 H2/H3 下面的第一句话，都必须是这个段落核心观点的直接陈述。AI 不等你铺垫，它要立刻知道这一段在说什么。

根据 Princeton 的研究数据，包含具体可溯源统计数据的内容，AI 引用率比没有数据的内容高 30% 到 40%。这不是软建议，是已经被量化的差距。

我具体做的事：

第一，开放 AI 爬虫。Cloudflare 在 2024 年把默认配置改成屏蔽 AI 爬虫，很多站主不知道这件事，结果 GPTBot、ClaudeBot、PerplexityBot 全被挡在门外。我的所有站，这些爬虫全部明确放行。这是一行配置，不是一个工程问题，但被忽视的比例之高让人吃惊。

第二，每页提供 Markdown 版本。URL 后加 .md 可访问纯文本 Markdown 版本。AI 爬虫更倾向于读干净的格式，被正确解析的概率更高。用 Nginx 的 rewrite 规则实现，加一条配置，对所有站批量生效。

第三，结构化 FAQ 模块。每个内容页的底部有 FAQ 区块，用 schema markup 标注。AI 搜索引擎在生成回答时，非常偏向引用本身就是问答格式的内容。FAQ 由 Agent 在写完主文之后自动生成，同一条 cron 任务的最后一步。

第四，llms.txt 文件。站点根目录放一个 llms.txt，告诉 AI 爬虫这个站的主题是什么，核心内容在哪里。这个标准还很新，但早做早受益。注意：不要迷信 llms.txt 本身的魔法，它是一个辅助信号，不是万能开关。

GEO 在小语种站上的竞争密度，比英文站更低。这是一个还没有被大多数人重视的叠加优势。

你必须有一个真正赚钱的核心业务

这一段比所有技术细节都重要。

站群是放大器，不是引擎。

我说的"真正赚钱的核心业务"，是一个独立于站群之外的、由你自己控制的商业逻辑。可以是一个有真实复购的独立站，一个服务性质的收入来源，一个付费社群，一个 SaaS 工具。只要它是由你主导的、有品牌积累的、不完全依赖搜索算法心情的生意。

为什么这很重要？

因为算法会更新，而且不会提前通知你。你的流量可以在一次更新里下降 50%，你的收益可以在一个星期内腰斩。如果你所有的收益都绑在这台机器上，这种风险是存在性的。

但如果你有一个独立的核心业务，站群只是你的流量来源之一，不是全部，你就有了真正的抗风险基础。

这也是为什么我不认为自己是纯粹的"站群玩家"。站群是方法，不是身份。

一人公司，或者别的什么

站群还能做吗？

能做。但不是所有人都应该做，而且在开始之前，你必须先想清楚盈利模式——流量是前提，不是结果，没有变现路径的流量只是一堆待转化的可能性。

但我想说的，不只是"站群能不能做"这个问题。

这十几年，我一直在做的其实是同一件事：把需要人来做的事情，系统化、工具化、自动化，然后把自己从这个循环里解放出来。

早期是写脚本替代手工操作。后来是建系统替代脚本的混乱管理。现在是用 AI Agent 替代内容生产里需要人工判断的环节，用站群管理系统替代逐站盯数据的低效。

每一步都是在把"需要我在场才能运转"的东西，变成"我不在场也能运转"的东西。

这是我理解的一人公司的本质：不是一个人在工作，是一个人建了一套系统，系统在工作。

这个系统可以是站群，可以是 SaaS，可以是付费社群，可以是 Ghost 订阅博客，可以是工具站，可以是任何能在你离开屏幕之后继续运转的东西。站群只是其中一种载体，不是唯一答案，也不是必选项。

但如果你要做站群，记住这门生意真正的门槛：

SEO 是引擎，外链是燃油，内容是方向盘，变现是目的地。哪个都不能缺，哪个都不能偷懒。

然后是那条铁律。

那条铁律

永远不要跟任何人透露你站群里的网站域名。

一个都不行。不是"大概不行"，是一个都不行。

不是你的员工，不是你的朋友，不是你的合作伙伴，不是你在交流群里认识的同行，不是你信任的师傅，不是你的家人。

原因有四个。

第一，你的合作伙伴可能某天开始做自己的站，他脑子里有一张你的站的地图。

第二，你信任的同行可能在某个私下讨论里提到了你某个站的域名，那个讨论里有其他人，其中一个可能刚好是某个想反向工程你网络的竞争对手。

第三，一旦你的某个站被公开关联到"某人的站群"，它对外的独立性就破了。它不再是一个"独立网站"，它变成了一个已知网络的节点。

第四，最难防的不是恶意，是无意。人会在不经意间泄露信息——截图里露出一个角，聊天里顺嘴提到一个域名，分享一篇文章的时候没想到那篇文章能被溯源到你。

这不是偏执，这是这门生意的基本操作卫生。

我管过 2000 多个站，没有一个域名泄露过。不是因为我特别谨慎，是因为我把"不说"变成了默认值，而不是需要提醒自己的规则。

最后吐槽一下逐年递增的成本。

为什么呢？

(4) X 上的 AI最严厉的父亲：“我管理过2000个网站，这是我这些年走过的弯路” / X