内容架构与信息组织

1. 站点内容定位

这个网站不是泛技术博客，而是围绕《回声》项目展开的专题化技术站点。内容重心非常明确：

• Unity 原型
• LLM 叙事集成
• Facts 与命令执行
• 玩法系统接入
• 毕业设计验证材料

它的真正主题不是“分享很多杂项技术”，而是“用一组页面把《回声》这个原型项目讲清楚”。

2. 信息架构总图

站内内容可以抽象成四层：

1. 首页入口
2. 项目专题页
3. 文章目录页
4. 四篇技术文章

阅读路径如下：

首页 index.html
  -> 项目页 projects/echo.html
    -> 文章目录 posts/index.html
      -> 三层架构
      -> Facts 与 Function Calling
      -> Unity 系统接入
      -> 论文验证思路

3. 各页面的内容职责

3.1 首页

首页负责三个动作：

• 先告诉访问者“这是什么网站”
• 再突出《回声》这个核心项目
• 最后把访问者送到项目页或文章页

它是一个入口页，不承担深度技术讲解。

3.2 项目专题页

项目页是整个站的信息中枢。它承担：

• 项目背景说明
• 剧情和玩法循环说明
• 三层架构概览
• 代码阅读入口导航
• 截图与流程图展示

这页不是源码文档，而是“全貌图”。

3.3 文章目录页

文章目录页承担索引职责。它把技术内容从项目全貌中拆出来，让读者明确知道有哪些专题文章可读。

3.4 技术文章页

四篇文章各自承担独立主题：

• three-layer-architecture.html：解释整体边界和主链路
• facts-function-calling.html：解释状态锚点与可执行命令
• play-systems.html：解释 Unity 玩法系统如何承接 AI
• experiment-and-thesis.html：解释如何把原型做成可复现实验

4. 《回声》技术内容的组织逻辑

这四篇文章并不是并列的杂谈，而是沿同一条问题链展开：

1. 为什么不能只让模型聊天。
2. 如何给模型稳定的状态来源。
3. 如何让模型请求落到系统执行层。
4. 如何验证这套机制真的工作。

换句话说，内容是按“问题 -> 机制 -> 系统接入 -> 证据”组织的。

5. 读者视角下的理解路径

如果从读者理解成本来设计，这套内容的最佳阅读路径是：

1. 在项目页先建立故事背景和整体印象。
2. 进入三层架构文章，理解技术边界。
3. 进入 Facts/命令文章，理解数据与执行的中层机制。
4. 进入 Unity 系统文章，理解落地方式。
5. 进入论文验证文章，理解为什么这不是概念演示，而是可复现原型。

这条路径的优点是先给框架，再讲细节，最后补证据。

6. 页面之间的互相支撑关系

项目页和文章页之间并不是简单跳转，而是互相补位：

• 项目页负责概览和引导
• 文章页负责分主题展开
• 项目页中的 #code-reading 章节直接把读者送到文章的特定锚点
• site.js 自动构建专题书签和本文目录，进一步强化这种“专题阅读”结构

因此，这个站点实际上已经具备“轻文档站”的雏形。

7. 为什么这套组织方式有效

原因有三点：

• 它先卖清楚问题，再解释实现，读者不容易迷路。
• 它把系统图、代码节选、实机截图放在一起，能同时满足展示和说明。
• 它把论文材料提前拆成博客结构，后续可以反过来服务毕业设计写作和答辩。

8. 后续内容扩展建议

如果以后继续扩展站点，建议沿现有结构继续长，而不是换主题：

• 可以新增“部署与性能记录”文章
• 可以新增“Prompt 设计与角色约束”文章
• 可以新增“存档、摘要与上下文压缩机制”文章
• 可以新增“已知限制与失败案例”文章

最重要的是保持每篇文章只回答一个核心问题，这样专题结构会一直清晰。