Silan Viking —— 研究发布工作台
一个本地优先的研究发布工作台，让一项新结果变成经过审阅的公开说明、相互关联的证据和可核对的线上页面。
一项研究结果，应该在上下文变冷以前成为一页清楚的公开说明。现实却常常相反：笔记继续向前，项目页、简历、搜索信息和线上网站悄悄停在旧版本。
Silan Viking 把这次更新放进一条可以审阅的路径：记录结果、解释证据、连接相关内容、明确发布，再核对真正到达网站的版本。
从周五的新结果开始
假设一项实验在周五结束。你已经知道三件事：结果改变了什么、为什么重要、证据还不能证明什么。真正昂贵的已经不是形成判断，而是把它分别带进笔记、文章、项目页、简历、图片、语言版本、搜索信息和部署，同时不丢掉原来的边界。
Silan Viking 不把这些内容强行合成一份文档，因为它们服务不同读者。系统为每项内容保留稳定身份，再把它们连接起来：文章负责解释，项目页负责组织，简历负责压缩，但每个公开 claim 仍然能找到来路。
完整流程是：
记录 -> 解释 -> 连接 -> 审阅 -> 发布 -> 核对- 把第一句有价值的判断保存成带日期的 Moment；
- 趁证据还新鲜，建立一篇私人文章或项目更新；
- 连接文章、项目、Moment 和简历证据；
- 直接编辑渲染后的页面，或检查 Agent 准备的修改提案；
- 明确公开审阅后的内容，再通过已经配置的目标部署；
- 核对线上内容版本，并把访问和抓取请求当成下一次小更新的诊断信号。
Release 与源码边界
- 公开 v1.0 macOS/Linux CLI 使用较早的
idea/update命名，可以初始化和校验工作区，并支持文章、项目、系列、简历、关系、提案、站点工具、stats 与 MCP； - 当前 main 分支增加了 Moment 模型、Tauri/React 桌面工作台、引导式上手、语音输入、更完整的交付核对，以及当前 silan.tech 使用的工作流；
- 结构化编辑、语音输入、图片、语言版本和相关工作链接目前需要源码仓库；
- Schema 校验、明确的私人/公开状态、本地预览和配置后的生产部署；
- 从审阅后的公开内容生成稳定地址、摘要、结构化数据、sitemap、robots 规则和
llms.txt； - 本地/线上版本核对、真实读者活动、评论，以及按规则判断的搜索与 AI crawler 请求；
- 通过 MCP 检索上下文并准备可审阅的 Agent 提案；发布和生产部署仍由本人执行；
- 当前使用 Git 在不同机器间同步内容源。
Crawler 请求只证明某个地址被访问过，不能证明搜索引擎或 AI 已经收录、理解、排名或引用页面。
main 分支中的 Moment、Desktop 和 onboarding 还没有进入 v1.0 之后的新 Release。新工作区先使用公开 CLI 和普通文件；桌面工作台目前需要完整源码仓库。
第一次成功
不要先迁移整个职业生涯。选一项被推迟的结果，先走完私人内容和校验：
curl -fsSL https://raw.githubusercontent.com/Qingbolan/Silan-Context-System/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先写清楚改变了什么、为什么重要、证据支持什么、还有什么不确定。然后再判断：这次更新是否比你原来维护网站的方式更容易保持准确。