这个网站需要展示的并不只是几篇彼此独立的文章。实践项目和技术项目会持续产生阶段记录，一个项目下面可能出现多篇文章；观察与判断目前以单篇文章为主；长篇创作则暂时只展示项目概况。后端结构首先要解决的，是这些内容如何保存、归类、排序和呈现，而不是先决定页面应该套用哪一种模板。
由此确定了一个基本原则：原稿、页面结构和运行时查询分别处理。文章作者只编辑 Markdown；Django 负责验证内容、建立索引、匹配路由并选择模板；模板负责把元数据放到固定位置，再把正文排版后直接显示在页面中间。
从内容关系确定页面层级
实践项目和技术项目采用“栏目—项目—文章”三层。栏目页汇总同类项目，项目页保存周期、状态、范围和责任边界，文章页只记录一个具体主题。以个人展示网站为例，项目页说明整个网站使用了哪些技术、本人和 AI 分别负责什么；首页视觉设计与后端架构设计则作为项目下的两篇独立文章。
观察与判断采用“栏目—文章”两层，因为现有内容可以直接独立成篇，还没有必须先进入某个项目的阅读关系。页面层级由内容之间是否存在稳定的从属关系决定，而不是为了形式统一强行增加一级目录。
URL 沿用同一关系：栏目、项目和文章分别使用自己的 slug。展示标题可以继续修改，slug 保持稳定。文章的先后顺序不写进 URL，而是在元数据中用 article_number 保存；数据库据此排序并查询下一篇文章。
Markdown 是内容的编辑入口
正文如果写在 Django 模板里，增加文章就等于修改代码；如果直接建设完整 CMS，又会提前引入在线编辑、账号权限和数据备份。这个网站当前只有一个维护者，因此 Markdown 更适合作为唯一内容源。
每个 Markdown 文件由两部分组成：顶部 Front Matter 保存结构化元数据，分隔线以下保存正文。标题、slug、所属栏目、所属项目、文章编号和发布状态属于机器需要识别的字段；段落、小标题和图片属于文章本身。新增内容时复制对应模板文件，填写元数据并撰写正文，不需要再创建一套 HTML 页面。
Markdown 文件仍然保存在会随网站代码同步的 content 目录中。原型、讨论记录和不应上传服务器的内部资料放在 local 目录，使部署范围和内容读取范围从文件系统层面就保持分离。
元数据和正文分别渲染
读取 Markdown 后，Django 不会把整个文件当作一段富文本直接输出。Front Matter 先经过字段校验，再转换成模板可以使用的结构化数据；正文则按原有顺序解析成小标题、段落和图片，进入文章页面中间的正文区域。
因此，元数据可以稳定地出现在标题附近、项目信息区或文章底部，并保持统一的标签和值格式。slug、article_number、visibility 等字段只参与路由、排序或权限判断，不必全部展示。正文不重复这些信息，也不负责控制页面导航；它只保留文章内容，再由全站样式统一处理字号、行距、首行缩进和图片宽度。
这条分界也避免了内容和表现互相污染。调整元数据排版时不需要改文章正文，修改正文时也不会破坏返回项目、下一篇或发布状态等页面结构。
Markdown 保存原稿，数据库提供运行索引
Markdown 适合编辑和版本管理，却不适合让每一次网页请求都遍历文件。随着项目和文章增加，目录排序、详情定位和“下一篇”查询都需要稳定的运行索引，因此同步程序会校验 Markdown，并把可查询字段写入 SQLite 的 ContentRecord。
数据库不是第二套文章源。索引记录可以从 Markdown 完整重建，也不通过管理后台直接修改。这样既保留了文件编辑和 Git 留档的便利，又让 Django 可以按栏目、项目、文章编号和发布状态直接查询，不必在请求过程中反复读取全部元数据。
本地开发时，内容发生变化后可以重建索引并刷新页面；正式环境只在部署阶段显式同步，网页请求只读取数据库。任何一篇文件校验失败时，同步事务整体停止，避免数据库处于只更新一部分文章的状态。
栏目卡片需要不同的元数据
框架建立完成后，最初的目录卡片仍沿用一套近似的顶部信息和底部说明。实际填入内容后才发现，同样的位置在不同栏目中承担的含义并不相同：项目需要回答“什么时候做、现在是什么状态、本人负责什么”，文章则更关心“什么时候发布、如何创作、讨论什么”。
随后，元数据从一套通用展示字段拆成按栏目映射。实践项目卡片左上显示项目时间，右上显示项目状态，底部显示本人职责；观察文章左上显示发布时间，右上显示创作方式，底部显示文章标签；技术项目左上和右上同样使用项目时间与状态，底部只列项目实际涉及的技术栈。
技术项目还需要区分“项目用到了什么”和“谁具备或完成了什么”。因此，目录卡片只展示 Django、前端技术、服务器运维和网站备案等项目技术范围；进入项目页后，再分别显示项目前已有基础、项目中掌握的内容、本人职责和 AI 职责。这样不会把 AI 完成的代码实现写成本人既有能力，也不会把备案流程误写成编程技术。
这次修改没有改变 Markdown 加模板的总体结构，只是为不同内容类型定义各自的必填字段和展示映射。共享模板继续负责相同的视觉骨架，栏目配置决定骨架中具体出现哪些信息。
发布状态和业务状态分开
Markdown 文件存在并不代表页面已经公开。visibility 是唯一的正式站可见性开关：true 表示允许出现在目录并通过详情 URL 访问，false 表示在服务器的 DEBUG=False 环境中保持隐藏。本地开发环境会读取全部内容，便于直接使用正式 URL 检查草稿；是否公开仍必须在部署前作为内容决策写入 Markdown，部署过程本身不修改该字段。
项目自身的“进行中”或“已结束”由 status 表示，与文章是否公开无关。把这两类状态分开以后，可以在本地查看仍处于修改阶段的项目文章，也可以公开一个尚未结束的现实项目，而不会让页面权限和项目进度互相影响。
Django 负责把各层连接起来
Django 在这套结构中承担的是路由、内容校验、数据库查询、模板选择、可见性过滤和 404 处理。它暂时不承担在线写作、用户注册、评论或文章后台编辑，因为这些能力并不是当前网站展示内容所必需的。
一个页面请求到来后，路由先确定栏目、项目和文章 slug；视图从数据库索引中取得对应记录并检查可见性；模板渲染标题和结构化元数据，再将 Markdown 正文放入内容区。返回项目与下一篇文章也来自同一组关系和编号查询，不依赖正文中手写链接。
本地预览、Git 提交和部署相互独立
修改 Markdown 并刷新本地页面，只代表当前内容能够被正确解析和排版。Git 提交负责保存版本，服务器同步和内容索引重建才会改变正式网站。三者保持分离，既能在本地检查草稿，又不会因为保存文件就自动发布。
这套后端架构的重点并不是使用了多少 Django 功能，而是让每类信息只有一个明确位置：Markdown 保存原稿，Front Matter 描述内容，数据库支持查询，模板决定呈现，发布字段控制边界。以后增加项目或文章时，只需延续同一套内容规则；只有出现多人编辑、在线投稿或更复杂的媒体管理需求时，才需要继续扩展后台能力。
技术选择与实际分工
由于本人已经具备 Django 的技术基础，网站在技术选型之初便确定以 Django 作为后端框架。这并不意味着后端代码由本人手写：本项目采用纯 Vibe Coding，模型、内容读取器、视图、模板连接、同步命令和测试代码均由 AI 实现，本人没有手写其中任何一行代码。
前端与后端的协作方式并不相同。前端实现路径超出本人原有知识范围，因此采用的是由 AI 先给出可运行版本，本人根据实际页面判断问题、提出修改并完成验收的方式。后端则从最底层开始由本人设计：网站需要管理哪些内容对象，栏目、项目和文章如何分层，Markdown、元数据与数据库怎样分工，URL 与文章编号如何组织，以及本地预览和正式发布如何隔离，均由本人确定。
因此，后端部分更准确的分工是：本人负责整体架构、数据关系、运行规则和验收标准，AI 负责把这些设计转化为可运行的 Django 代码，并完成具体实现、调试与测试。没有手写代码，并不等于后端框架由 AI 自行决定；AI 承担的是工程实现，架构决策仍由本人负责。