第 1 集 - 选定更新和系统边界

这一集先定义任务，再进入 CLI。第一次成功使用 Silan Viking，不应该是“迁移整个网站”，而应该是一项研究更新走完清楚的生命周期：私人内容源、结构校验、明确发布，以及在基础设施可用时再预览或部署。

本集结果

完成这一集后，你应该得到：

• 一项具体研究结果；
• 第一次工作流的范围边界；
• 后续三集都会使用的四状态模型；
• 判断这项更新是否可以进入私人文章阶段的检查表。

本系列后续使用新建工作区中的 silan CLI。当前安装路径支持 macOS 和 Linux。打包桌面端的首次上手流程仍然和这条 CLI 主线分开。

选择一项更新

只选一项结果。好的候选应该足够小，可以用一页说清楚；也足够具体，让另一个研究者能检查证据：

• 一个还没有公开解释的项目里程碑；
• 一个改变原先预期的实验；
• 一份档案、数据集、benchmark 或 release note 改变了某个 claim；
• 一条简历表述缺少在线证据；
• 一个现在只存在于幻灯片里的短技术结果。

不要选择“重做整个研究网站”或“整理所有旧项目”。那是迁移项目。本系列处理的是一项更新如何安全通过系统。

写下发布边界

创建文件前，先用普通语言写清楚边界：

选定更新：
  <一句话说明结果>

公开 claim：
  <审阅后愿意公开说什么>

证据：
  <读者可以在哪里检查支持材料>

不在范围内：
  <旧项目、无关页面、生产部署或自动化>

这个边界会让第一次工作流足够小，也能防止 Agent 或后续编辑把一次窄更新扩大成失控重写。

使用四状态模型

Silan Viking 把内容状态和站点状态分开处理：

private source
    -> validate
    -> publish the item
    -> preview or deploy when infrastructure is available

每个动作的责任和失败模式都不同：

• 编辑改变普通 Markdown 和 TOML 文件；
• 校验检查内容源结构，并重建派生索引；
• 发布把某一项内容的源状态改为公开；
• 部署更新正在运行的网站或预览栈。

Agent 可以帮助检索上下文或准备提案，但不应该拥有发布权或生产部署权。这两件事继续由本人明确执行。

进入下一集前的检查表

只有当选定更新满足这些条件时，再进入第 2 集：

• 这项更新能用一两句话说清楚；
• 证据位置已知，即使最终正文还没写好；
• 第一版可以保持私人；
• 第一次成功不需要生产服务器；
• 你知道这一次什么算完成。

第 2 集会创建 CLI 工作区，并验证本地内容引擎可以初始化、校验、同步和给出下一步建议。