论文被接收、实验有了新结果、档案里出现了新的证据，研究者真正想做的事情通常很小：把当前判断讲清楚，让别人能找到证据，并且知道哪一个页面代表最新版本。但现实里，这件事经常被推迟。项目页旧了，简历旧了，幻灯片里有新结论，公开网站还停在几个月前。
问题不是研究者不会做网站。现在 Vibe Coding 一个新页面并不难。真正的问题是：研究输出没有一个低摩擦的增量发布机制。每次新结果出现时，研究者都要重新处理标题、摘要、图片、语言版本、项目关系、公开状态、部署和访问反馈。一次本来应该很小的研究更新，被迫变成一次前端工程和运维任务。
我想提出的抽象是 Research Update Lifecycle：一次研究更新不是一段散落的文本，而是一个带有稳定身份、证据、关系、审阅状态、发布状态和观测信号的内容事件。网站不应该只是展示这些事件的静态页面，而应该成为研究工作的外部记忆。
下面只看一个具体场景：周五出现一项值得分享的结果，怎样在上下文还新鲜时把它变成一页清楚的公开说明，并确认它是否真正到达读者。Silan Viking 当前把这个过程拆成五个状态转换：capture -> structure -> propose -> publish -> observe。
从一项新结果到经过审阅的公开页面，需要五个明确状态转换
第一步应该比“写一篇文章”小得多。研究者打开快速编辑器，打字或口述一句最不应该丢失的话，在证据和判断还新鲜时先保存下来。这里保存的不是完整文章，而是一个最小 claim。
在当前快速编辑器中用语音起草研究更新
例如，在一个系统史或部署史项目里，新的档案证据可能只支持一句话：
新发现的档案把首次部署时间从 2019 年提前到了 2017 年。
这句话可以先成为一条带日期的记录。它暂时不需要漂亮标题、搜索关键词或完整论证，但它应该有稳定身份、时间、来源位置、可选证据链接和当前置信度。否则它很快会退化成聊天记录、幻灯片备注或某个文件夹里的临时 Markdown。
当前 Moments 时间线中的研究记录
这里的价值很简单：记录门槛足够低，但这句话不是一次性便签。它有稳定身份。以后无论标题、语言版本、页面路径怎么变，它都可以连接到解释它的文章、项目页或简历条目。稳定身份比漂亮编辑器更重要，因为研究维护最容易丢失的不是文本，而是文本之间的来路。
结果值得分享时，研究者新建一篇文章或一条项目更新，再把它与最初的记录连接起来。这里的关键是不要把所有东西假装成“同一份文档”。Moment -> Article -> Project 是三类对象，不是三个视图。它们应该通过显式关系连接，而不是通过复制粘贴维持一致。
一页研究更新先回答四个问题就够了：
- 新 claim 是什么？
- 它改变了哪条旧判断？
- 证据在哪里，边界在哪里？
- 读者下一步应该看什么？
编辑文章时仍能看到内容结构
编辑器呈现的是可以直接阅读的页面；内容源则保存标题、摘要、语言版本、图片和相关工作链接所需的结构。研究者维护的是 epistemic state，不是 React 模板。好的工具应该让研究者修改解释本身，而不是每次重新理解前端目录、构建脚本和部署管道。
如果这项结果还应该出现在项目页或简历里，它们仍是独立内容。同一结果在文章、项目页和简历中承担的语用功能并不相同：文章解释证据，项目页组织工作脉络，简历压缩贡献。系统应该保存关系，而不是要求同一段话勉强服务所有读者。以后无论是人还是 Agent，都能找到每项表述的来路。
任务足够具体、输出可以验证时，Agent 才真正有用。它可以找到项目和相关记录、起草摘要、准备另一种语言、补一条缺失关系，或汇报哪些公开页面已经落后。这些都是维护动作，不是研究判断本身。
默认的 Agent 流程应该停在“可审阅的修改提案”。研究者检查差异，再决定是否接受。正式发布和生产部署仍然由本人执行。换句话说，Agent 可以拥有 proposal authority，但不应该拥有 publication authority。
因此，一个自然语言要求可以非常具体：
用这项结果更新项目页，在文章里保留不确定性，并把所有改动列给我看。
一个可用的 Agent 输出不应该只是“我已经帮你更新好了”。它应该列出改了哪些文件、补了哪些关系、保留了哪些不确定性、哪些页面需要本人确认、哪些内容仍然不能公开断言。Agent 拿走的是重复维护，不是研究者愿意公开声称什么的决定权。
文章、项目页、语言版本、图片和搜索信息可以统一管理，但发布必须是一次明确的状态改变。更准确地说，一条研究更新应该从 private draft 进入 reviewed，再进入 published，最后通过部署进入 deployed。编辑、同步、翻译和 Agent proposal 都不是 publish event。
在当前桌面工作区中管理文章和发布状态
一份私人草稿不会因为被编辑、同步或加入 Agent 提案就自动公开。本人审阅页面、发布内容，再通过已经配置好的站点完成部署。这个边界看起来保守，但对研究写作很重要：研究者必须保留对公开声明的最终责任。
访客最终打开的是一个普通公开页面，不需要先理解 Silan Viking。好系统的结果应该降低读者理解成本，而不是要求读者理解你的工具链。
由确认过的内容生成的公开博客列表
SEO 和 GEO 在这里有一个克制的含义。它不是承诺某个搜索引擎或 AI 系统一定会引用你的研究，而是让公开页面带有稳定地址、清楚的标题和摘要、语言信息、结构化数据，以及指向相关工作的明确链接。这些信号方便搜索引擎和问答系统处理页面，但不保证收录、理解、引用或排名。
发布不是生命周期的结束。对研究者来说，传统 PV 也不够解释问题：访问不等于读完，抓取不等于理解，引用不等于读者真的看到了证据。更有用的是把发布后的反馈拆成几个诊断信号。
Silan Viking 的仪表盘会比较本地与线上内容版本，并把真实读者访问与搜索程序、AI 抓取程序的请求分开。
当前仪表盘中的访问、抓取请求和线上版本状态
抓取程序请求过页面，只能说明它到达过这个地址，不能证明某个 AI 已经理解或引用了研究。真正有用的问题更小，也更可执行：
- Delivery：当前版本是否已经到达网站？
- Attention：读者是在看结果页，还是只停在项目列表？
- Machine reachability：搜索程序或 AI 抓取程序是否请求过这页？
- Opening clarity：开头和摘要是否足以把读者带到证据？
下一步可能是改清楚前两句、补一条关系、增加另一种语言，也可能是什么都不改。关键是研究者终于能区分问题发生在哪里：内容没有部署、读者没有进入、机器没有请求，还是页面本身没有把证据讲清楚。
目前，Silan Viking 可以创建并校验纯文本内容、连接相关记录、发布多语言页面、用 Docker 本地预览、部署到已经配置的目标，并报告线上版本和访问情况。Agent 可以通过 MCP 提交修改提案；Git 是当前在不同机器间迁移内容源的方式。
上面的截图来自 Silan Viking 源码仓库中已经能工作的桌面界面，展示的是已有网站内容中的当前编辑体验，不是档案案例的摆拍流程，也不代表新工作区的安装路径。新建的外部工作区现在可以直接使用 CLI 和普通 Markdown 文件；独立打包的桌面端上手流程和更直接的跨设备体验仍在完善中。
这也是我希望保持克制的地方：当前系统已经能支持一个可审阅、可发布、可观测的研究更新循环，但还没有把所有个人网站维护都变成全自动。真正重要的不是自动化叙事，而是把研究更新从一次性页面工程变成一个可重复的状态机。
不要先整理所有旧项目。先为下一项原本会留在幻灯片里的结果创建一篇私人文章。下面这些命令创建的是一个本地工作区和一条可校验的私有研究更新，不会自动替你公开发布：
curl -fsSL https://raw.githubusercontent.com/Qingbolan/Silan-Personal-Website/main/engine/install.sh | sh
mkdir my-research-site && cd my-research-site
silan init
silan blog new new-research-result
silan blog add-lang new-research-result zh
silan content lint
silan index sync
silan blog show new-research-result用任意编辑器打开生成的 Markdown 文件，回答上面的四个问题。第一个有用结果不是“网站已经全自动”，而是一页有效、私密、由你决定何时公开的研究说明。
一旦这条更新有了身份、证据、关系、状态和观测信号，网站就不再只是一个展示页面。它开始成为研究工作的外部记忆。