把个人网站做成一个可验证的静态系统

个人网站很容易从“写点东西”扩张成一组没有边界的愿望：后台、评论、订阅、统计、搜索、动画和部署系统似乎都应该立刻出现。这个项目选择先做相反的事——写下公开决策，缩小首版范围，再用可重复的检查证明原型确实符合这些决定。

先确定不做什么

首版没有数据库、CMS、评论服务或邮件发送服务。文章以 Markdown 保存，构建后成为静态页面；浏览器端代码只负责主题切换、本地搜索和必要的界面交互。

这个边界带来三个直接结果：

• 正文即使没有 JavaScript 也应当可读；
• 公开仓库不需要持有部署写入凭据；
• 内容和程序的输入可以在构建期集中校验。

预留未来能力不等于提前引入未来依赖。等一个真实需求出现，再根据它重新判断，比为假想场景维护后端更可靠。

内容也是受约束的输入

一篇文章不只是正文文件。它还需要稳定的文章标识、ASCII 固定链接、标题、摘要、日期、状态和标签。封面与数据下载若存在，也必须引用约定目录中的本地资源，并提供必要的来源、口径、许可和摘要信息。

文章正文不接受任意脚本、任意 HTML 或运行时表达式。需要交互时，正文只能引用预先实现、参数经过 Schema 校验的受控组件；复杂工具则使用独立页面。这样可以让写作保持接近普通 Markdown，也让公开内容的执行边界足够清楚。

让每篇文章拥有可复现的图形

项目会为已公开文章生成一张函数图形。它由三类输入共同决定：永久文章标识固定视觉身份，标题和内容结构影响有限参数，规范化正文的 SHA-256 控制局部细节。

生成过程只调用内置函数族，不求值作者输入的公式。构建产物包括静态 SVG、社交分享 PNG 和记录采样点与摘要的清单。正文变化会留下可比较的结果，但不会把装饰图形伪装成数据可视化。

草稿阶段只参与文章标识的唯一性检查，不生成公开图形，也不进入页面、搜索或 RSS。完成发布审核后，构建器才会为它创建静态产物并加入公开索引。

“可以构建”还不等于完成

目前的验收链包含内容安全检查、生成器测试、类型检查和生产构建。构建器在输入无效时失败关闭，并在替换生成目录失败时恢复上一份有效产物。草稿与已发布内容的隔离也需要从文章路由、栏目列表、本地搜索、RSS 和生成图目录分别验证。

这些检查证明的是当前实现满足当前约束，而不是设计已经永久正确。字体、最终色值、浏览器范围、公开镜像和生产发布流程仍需要独立决策与验证。

下一次判断从结果开始

这个原型最重要的产物不是某个框架组合，而是一条可回放的路径：先记录假设和边界，再实现最小闭环，然后让测试、构建结果和实际阅读体验修改原来的判断。

如果后续文章表明现有内容模型或交互边界不够用，应该根据具体失败调整它们。反过来，如果静态方案持续覆盖真实需求，就没有必要仅为了“完整”而增加运行时系统。