这里没有"即将上线"。三套东西每天都在跑，下面写清它解决什么问题、现在什么数字、坑在哪。
网站右下角那个能回答问题的助手，也是留言板的自动回复
访客懒得翻 51 篇文章找答案。山山能读到最新的文章、新闻和日记摘要再回答，等于把整站变成了可对话的索引；留言板没人值守时也由它先回一句。
前端悬浮组件 → /api/chat（Cloudflare Pages Function）→ 直连 DeepSeek 的 OpenAI 兼容接口，SSE 流式返回。构建时另生成一份 site-context.json（最新 8 篇文章 / 5 条新闻 / 5 篇日记），Function 侧读取并缓存 30 分钟。
最早把模型挂在自家电脑的临时隧道上（openclaw + trycloudflare），电脑一关、隧道一重启地址就换，线上直接不可用。教训写进了手册：别把线上功能绑在自己机器的临时地址上。现在换模型厂商只改一个环境变量。
三个计划任务：早上采新闻、傍晚生草稿、夜里兜底推送
每天写东西不现实，但每天什么都不写，站就死了。于是把"找料"和"排版"交给机器，把"判断"留给自己。
Windows 计划任务三个：06:00 抓 RSS 并去重成 5 条新闻；18:00 按 git 提交记录生成日记草稿；22:30 把已提交未推送的内容兜底推上线。新闻脚本带失败重试、合集/厂商稿过滤、历史相似度去重。
36氪、机器之心的 RSS 早已反爬封禁，一直返回 HTML 反爬页而不是 XML——所以信源是实测筛过的。另外脚本只产草稿、不自动上线：机械稿直接发布过一次，读者一眼看得出，之后加了「18:00 出草稿 → 人工/审稿重写 → 再提交」的闸门。
51 篇长文都是这条流程出来的，中英双语
写长文最难的不是写，是决定"这篇值不值得写"。选题拍脑袋，写完才发现没人关心，是最贵的浪费。
两道工序：选题用 7 个问题打分（有没有真实经验、读者能不能拿走动作、有没有反常识点…），过线才写；写作走 18 项自检清单（事实来源、数字口径、标题是否过度承诺…）。英文不是机翻，是按英文读者的表达习惯重写一遍。
链接必须逐条打开核实标题和时间——曾有 79 条假新闻混进站里，是看链接结构才发现的，随后全站下架。数字口径同理：写"节省 47% token"之前，得先确认它是官方实测还是媒体转述。
想知道这些系统在某一天具体出了什么岔子？都在工作日记里，按天记，不修饰。
看工作日记 →