NihaoLife 是我做的一个全栈项目：帮外国人来中国旅行和生活的 AI 助手。它上线之后，问题不在产品， 在于没人知道它存在 —— 一个新站在 Google 上的平均排名是第 34 位，也就是第四页， 自然增长基本等于零。
一、系统长什么样
| 层 | 用了什么 |
|---|---|
| 前端面板 | Vue 3 + Element Plus（内容任务、平台登录、数据看板） |
| 服务端 | Node 18 + Express，同时托管前端静态文件 |
| 数据 | SQLite（任务 / 日志 / 设置），全部留在本机 |
| 浏览器自动化 | Playwright，每个平台一个独立的持久化 Profile |
| 内容生成 | DeepSeek（OpenAI 兼容接口），提示词集中在一个文件里 |
| 配图 | Pexels 按主题关键词检索 |
| 数据回看 | 自建 Umami 的只读 API |
发布器按平台拆成独立包，目前六个：
packages/publishers/ ├── core 公共层：持久化 context、截图、停止型错误 ├── x X (Twitter) ├── instagram Instagram ├── threads Threads ├── facebook Facebook ├── pinterest Pinterest └── reddit Reddit
每个发布器把页面选择器集中在自己的 selectors.js 里。
平台改版的时候只改这一个配置文件，不动业务逻辑 —— 这是被现实教育出来的设计。
二、内容工厂：同一个主题，六种母语
最容易做错的一件事，是把一段文案复制到六个平台。所以这套系统里，
平台风格是第一等公民：所有提示词集中在 packages/ai/src/prompts.js，
要提高内容质量就改这一个文件，绝不让提示词散落进业务代码。
- X —— 280 字以内，信息密度优先，开头一个钩子，最多 1–2 个话题标签
- Instagram —— 第一行必须抓人（feed 里后面会被截断），暖色调、软 CTA，末尾单起一行放 5–10 个标签
- Threads —— 500 字以内，像跟朋友说话，结尾必须留一个开放问题
- Facebook —— 2–5 段的完整攻略，能直接当指南读
- Pinterest —— SEO 优先。标题会被真正发布，所以按“别人会怎么搜”来写
- Reddit —— 反营销：第一人称、真实经历、最多顺带提一次产品
自动驾驶
全自动那条链路是这样跑的：抓当天与中国旅行相关的新闻标题 → 交给模型挑一个当日选题 → 按各平台风格生成文案 → 用模型顺带产出的图片关键词去 Pexels 找配图 → 排期 → 到点发布。 选题的约束写在提示词里：必须转成对旅行者有用的角度、不许复述标题、不许和最近用过的主题重复、 政治敏感话题直接跳过。开机自启由一个 supervisor 脚本守着，无人值守。
三、几条不能碰的红线
社媒自动化最贵的错误不是发得少，是重复发帖和被判定成机器人。所以可靠性这块花的心思比功能多：
- 绝不自动重试。遇到验证码、登录失效、页面元素找不到 —— 立刻停下并标记失败，等人来看
- 任务领取用数据库原子更新（pending → running），从根上杜绝同一条被发两次
- 平台级互斥锁，同一个平台任何时刻只有一个任务在跑
- 限频可配：分平台的每日上限 + 同平台最小发布间隔
- 默认是“人工确认”模式：工具把内容和图都填好，最后那一下由我点。自动发布是可选项，不是默认项
- 不碰账号密码，不导出 Cookie。登录全程在真实浏览器窗口里手动完成，状态只留在本机的 profile 目录
- 服务只绑 127.0.0.1，配置里改成别的地址会被强制拒绝；所有接口都要密码
- 发布前后都截图存档，失败了可以回看当时页面长什么样
四、成果：Umami 怎么说
以下为自建 Umami（stats.liloulou.cn）在 nihaolife.com 上的真实读数，
窗口为 2026-09-04 往前 90 天；同比一栏为近 28 天 vs 再往前 28 天。
流量从哪来（90 天 · 按会话）
| 来源 | 会话 | |
|---|---|---|
| Facebook（含 m. / l. 跳转） | 66 | |
| Naver（含移动端搜索） | 28 | |
| 27 | ||
| X / t.co | 12 | |
| 7 | ||
| Threads | 5 | |
| Yandex | 3 | |
| ChatGPT | 2 | |
| Bing | 1 |
访客在哪（90 天 · 前十）
| 国家 / 地区 | 会话 | 国家 / 地区 | 会话 |
|---|---|---|---|
| 中国 | 403 | 爱尔兰 | 11 |
| 美国 | 129 | 新加坡 | 9 |
| 韩国 | 37 | 英国 / 瑞典 | 7 / 7 |
| 法国 | 14 | 德国 / 俄罗斯 | 6 / 6 |
来了之后做了什么（自建埋点）
页面浏览由 Umami 脚本自动上报，这几个事件是自己埋的 —— 没有它们就分不清“没人来”和“来了没用”：
| 事件 | 次数 | 说明 |
|---|---|---|
lang_switch | 71 | 切换界面语言 —— 所有事件里最高 |
quiz_result_view | 46 | 旅行者性格测试结果页（含被分享出去后别人看的） |
quiz_start → complete | 18 → 16 | 完成率 89% |
kb_read_deep | 16 | 知识条目读到底 |
assistant_ask | 8 | 向 AI 助手提问 |
设备构成：移动端 346 / 笔记本 264 / 台式机 55 —— 移动端过半。
① 韩国是第三大来源国，Naver 是仅次于 Facebook 的引荐来源、并且超过了 Google —— 而当时韩语只上线了 9 个页面。这是投入产出比最高的一块地。
②
lang_switch 是所有事件里最高频的 —— 人来了第一件事是换语言。多语言不是锦上添花，是入口本身。③ ChatGPT 已经开始往这边送人。2 次，小得可以忽略，但它证明 GEO 那条链路是通的。
五、韩区：用 9 个页面试出来的判断
做技术审计的时候发现一件事：站点有 11 种界面语言，但只有英 / 俄 / 法 / 西四种有独立 URL 前缀。 其余的（韩、德、日、阿、印地…）只能在客户端切换 —— 搜索引擎完全看不见它们。 用户问“sitemap 里为什么没有韩语”，答案不是漏做了，是那些语言根本没有可被收录的地址。
做法：试点，不是铺开
- 把
ko加进 SEO 前缀语言集合，路由自动生成/ko/...并进入 hreflang 集群 - 预渲染脚本给韩语单独设一份试点路由表，全量构建时 ko 只渲染这 9 页
- 选题按韩国游客真实关注点挑：
/ko首页 + 支付宝 / 微信 / 滴滴 / KTV 四个知识页 + 上海 / 北京 / 张家界 / 大连四个城市页 - （原计划里的青岛没有城市页，用同为韩国客高相关目的地的大连替代）
为什么不一次铺满？因为翻译质量还没有人审过。在有人把韩语自然度过一遍之前， 批量上线几百个机翻页面只会拖累整站权重。先放少量高质量入口，拿信号，再决定要不要扩。
上线后实测
- sitemap 从 736 个 URL 涨到 749（9 个韩语页 + 各页 hreflang alternates 共 54 处引用）
/ko/knowledge/alipay实测：<html lang="ko">、canonical 自指、韩语正文进了首次 HTML 响应（不是空壳等 JS）- IndexNow 一次提交 749 条 → HTTP 200，Bing 与 Yandex 同时收到
- 三个月后回看 Umami：韩国是第三大来源国，Naver 是第二大引荐来源
还没做的一步是找韩语母语者审一遍试点页 —— 过审之前不提交 Naver Search Advisor。 Naver 的收录逻辑比 Google 更看重站内的“像不像韩国人写的”，用机翻去敲门是负分。
六、俄区：URL 铺满了，语言没有本地化
俄语的处境和韩语正好相反 —— 技术层全做了，内容层没跟上：
- 约 160 个页面预渲染 + 全部进 sitemap，hreflang 双向
- Yandex Webmaster 已验证，每次部署都跑 IndexNow 通知
- 给乌鲁木齐、哈尔滨手写了俄语标题和描述，不是机器直译 —— 实测
/ru/cities/urumqi的标题变成了 “Урумчи, Китай: достопримечательности, еда, транспорт и советы туристам”。这两座城市恰好是俄语区最相关的目的地
结果呢？90 天里俄罗斯只有 6 次会话，Yandex 引荐 3 次。
待办很清楚：/ru 首页原生化、给 KB 加逐语言的人工文案覆盖、找俄语者审校。这件事没有捷径， 它是内容工作，不是配置工作。
七、GEO：给 AI 搜索引擎准备的那一层
传统 SEO 争的是排名，GEO（Generative Engine Optimization）争的是被引用。 做法上有重叠，但优先级不一样：
robots.txt明确放行 GPTBot、OAI-SearchBot、ChatGPT-User、PerplexityBot、ClaudeBot、Claude-Web、Claude-SearchBot、Claude-User、Google-Extended、Applebot-Extended —— 抓取型和训练型爬虫分开对待，不能一刀切- 实测这些 UA 拿到的都是 200，没有被 WAF / 限流拦掉（很多站是在这一步无声地把 AI 挡在门外的）
- 整站预渲染成静态 HTML：首次响应就带 title / description / H1 / 正文 / canonical / hreflang / JSON-LD，不给爬虫留空壳
- 结构化数据：首页 Organization + WebSite，知识页 Article + HowTo，城市页 TouristDestination
llms.txt托管在站点根目录- 每条知识条目带来源与核查日期 —— AI 愿意引用你的前提，是它能确认这条信息可核查、有出处、有时间
监测手段很土但有效：
grep -E 'OAI-SearchBot|Claude-SearchBot|PerplexityBot' /var/log/nginx/access.log
再加上每月手测 5 个固定问题，看生成式回答里有没有引用到 NihaoLife。
八、这件事教给我的
曝光和排名是两个问题。28 天曝光从 165 涨到 1536，靠的是索引覆盖变大 —— 技术层的活儿见效很快。但平均排名一直卡在 34.5，因为盘点下来 81% 的知识条目正文不到 130 词。一个 150 字符的页面，标题写得再好也不可能排进有竞争的查询前列。
自动化有它的边界。AutoMarketing 能保证“每天有内容、按时发出去、不重复、不违规”， 但它保证不了“这一篇值得排第一”。想明白这点之后，重心从多发挪到了写深： 先合并 8 组自我竞争的重复条目（免签、买药、牙医、必备 App、上网、饮食、买菜、医院各有两篇在互抢排名）， 再把景点实名预约、护照买高铁票这类“通用大模型一定答旧、答错”的题目写成长文。
assistant_ask 记录用户真实提问，
assistant_answer 里 sources=0 的那些，
就是知识库没接住的问题。这份清单比任何关键词工具都准 —— 它不是推测需求，它就是需求本身。
九、还没做完的
- Bing Webmaster Tools 未开通 —— Copilot 那条线依赖 Bing 索引
- Naver Search Advisor 待韩语审核通过后再提交
/de等未知路径是软 404（返回 200 + SPA 壳），需要真的返回 404- sitemap 的 lastmod 目前是生成日全量刷新，不是内容真实改动日
- /ru 首页与知识库的俄语原生化
- 城市页正文扩充：34 座城市每座只有约 164 字符的独有文案