从《重做个人主页：先回答放什么》开始的六期周刊，记录的是我如何把一个个人站点逐步做成一套内容系统。最开始，我先回答一个最基础的问题：个人站点应该放什么。随后，我继续复盘完整的技术实现：页面怎么组织，技术如何选择，SEO 基建如何落地；再往后，我记录如何收集和整理灵感，把零散输入变成可以继续创作的内容；最后，我回到与 AI 协作时的个人表达，确认哪些事情可以交给工具，哪些部分必须由我自己保留。
内容载体、输入与创作、人与 AI 的分工，拼在一起，构成了我对“一个人如何记录、沉淀、产出并守住自我”的阶段性认知闭环。
这套体系从 0 到 1 开始：先让一条记录有地方可放，有名字可叫，有一个日后还能找到这条记录的地址；再从内到外，把私人记录整理成可以被别人阅读的内容。闭环形成后，问题自然往外延伸——这些已经拥有身份的记录，是否只能孤零零地停在自己的页面里？
前一篇《什么才是独属于我的表达》写的是这套闭环里最靠近自我的一层：AI 可以帮我整理和润色，但不能替我改写。守住“我”之后，怎样让它向外生长，而不是继续孤零零地停在自己的页面里？
我想要的不是把所有内容挤成同一种声音，也不是为了让网络看起来完整而凭空制造联系。周刊、影集、动态、项目和博客可以保持各自的职责，再通过真实存在的关系彼此找到。这是我理解的网络共生：实体成链，自我向外生长。
这就是我现在想谈的实体链。实体 SEO（让搜索系统理解网页背后是谁，以及不同内容之间有什么关系）只是它在技术层面的名字；我更在意的是这个名字背后的动机：链接可以把内容连起来，但不能替内容伪造一段关系。
先看一眼全貌
在拆开讲之前，我先给这件事找一个整体的画面：一座小图书馆。
我的每一篇周刊、每一册影集、每一条动态，都像馆里的一本书。书有标题、作者、出版时间和索书号，书里也可以引用另一本书。所有内容放在一起，构成一座图书馆；作者目录则把分散在不同位置的内容归到同一个人名下——MoeWah。
在这个画面里，内容实体是可以被单独找到的书，链接是书里的参考书目，站内和跨域的互认是内容之间留下的引用，作者目录则让不同位置的内容仍然指向同一个作者。
但对我来说，图书馆不是书越多、引用越多就越可信。只有确实有关的内容，我才愿意让它们彼此引用。为了让目录看起来完整，给无关内容硬加关系，只会让这张网络变得更嘈杂。
接下来回到我自己的站点，看这些关系怎样发生，以及它为什么需要一致性和链接边界才能长久成立。
01 内容实体：一篇记录什么时候拥有独立身份
在我的站点里，周刊、影集、动态和项目原本只是不同类型的内容。对我来说，只有当一份记录有明确标题，被发布到稳定的 URL，能够被别人单独找到、引用和回看，它才从“我写过的东西”变成网络里可以被指认的内容实体。
fig-framework-entity-chain
在我自己搭建的这套网站内容生态体系里，不同类型的内容各自对应一套编号：
| 内容 | 编号 | 它记录什么 |
|---|---|---|
| 主页 | MW-2018-NNN |
我是谁 |
| 周刊 | MW-WKL-NNN |
我怎么思考 |
| 影集 | MW-ALB-NNN |
我看见了什么 |
| 动态 | MW-MMT-NNN |
我正在经历什么 |
| 项目 | MW-PRJ-NNN |
我做过什么 |
编号不是装饰。它让一份内容有稳定的位置，也让其他内容以后能够准确地找到它。对我而言，这是从 0 到 1：先让一个念头拥有自己的身份，才谈得上被连接。
02 站内互认：记录之间如何留下来路
内容实体有了身份，下一步才是它们之间的关系。
这篇文章开头的回指就是一个很小的例子：我没有只说“又想到了一个问题”，而是把它接回个人站点最初的内容选择，再说明这套体系怎样一步步走到今天的实体链。
这就是我理解的 callback：在新记录里回到一份旧记录，并说明两者为什么有关。 它不是独立于 SEO 的新链接类型，而是我对“有明确关系说明的回指”的称呼。站内，它通常表现为内链（internal link）；外部页面指向我的内容时，从被链接页面的角度看，则是反向链接（backlink）。前两者说明链接发生在哪里、朝哪个方向，callback 强调的是：这条链接为什么存在。
fig-comparison-entity-chain
在我的站点里，周刊记录判断，影集留下看见过的东西，动态保存事情刚发生时的痕迹。我没有把它们写成同一种内容，只在确实有关的地方让它们彼此指认。站内互认不是把内容拧成一个整体，而是让不同时期的我留下的记录，仍然能够彼此找到。
03 跨域互认：不同入口如何指向同一个作者
我的内容还分布在两个地址：www.moewah.com 是主站，blog.moewah.com 是博客（喵斯基部落）。这里的“子域”，指的是主域名下的一个独立地址。两个入口可以承载不同内容，但共享 moewah.com 这个主域名。
fig-framework-cross-domain-entity-chain
我没有把所有内容都放进同一个地址，而是让两个地方承担不同的工作：
- www 主站：承载身份、影集、动态和周刊索引，让人先认识我以及我正在记录什么；
- blog 子域：承载长篇文章和技术沉淀，把一个问题展开，留下更完整的思考。
现在主站在构建时读取 blog 的 RSS（博客更新时提供的一份机器可读目录），把博客的新文章带回主页。读者因此能从主站进入博客，两个地址之间也留下了清楚的身份和来源线索。
我不会把两个相似的网址直接当成互认已经完成。对搜索系统来说，作者名、头像、品牌标识和相互链接，只是整理关系时可以参考的信号。对我来说，先把事实放清楚：两个入口内容分工不同，但作者是同一个 MoeWah。这样，同一个人的记录就能拥有不同入口，却不再是互不相干的孤岛。
04 一致性：让变化留下来
实体网络需要一致性。商业实体 SEO 里，一致性通常指名称、标识、地址和属性在不同地方保持统一，方便机器把分散的信息归并到同一个实体上。
放回个人记录系统里，我更在意另一层一致性：不是每份记录都要给出同一个结论，而是每份记录都要诚实地说明自己和其他记录是什么关系。 人会变，想法也会变。对我来说，麻烦不在于观点变化，而在于为了让前后内容看起来整齐，回头把旧文章全部改写成今天的样子。
假设将来我重新审视自己此前关于“AI 只允许润色、绝不可以改写”的判断，我会按变化的程度处理：如果现在仍然认同，就在新文章里回链；如果只是补充，就说明旧文说了什么、现在补上了什么；如果已经改变立场，就保留那份旧记录，并明确写出勘误，说明“过去的我这样判断，现在的我有了不同看法”。
fig-flowchart-entity-chain
这三种处理方式最终都指向同一个动作：保留原记录，把变化写出来。正文里的补充、明确的勘误、更新时间，以及内容修改后的 changelog（修改记录），都在说明判断发生过什么变化。changelog 不需要列出每个标点，只记录会改变理解的修改，例如：
Changelog：补充主站与博客的关系说明；修正一处容易误解的表述；保留原文，并新增勘误说明。
搜索系统更容易处理稳定、少冲突的身份信号，但人的记录不会永远停在同一个位置。我不想为了适应机器，把思想演变抹掉。对我来说，真正的一致性不是“过去和现在说同一句话”，而是“过去和现在的关系没有被我说假”。
05 链接的边界：让关系保持真实
实体 SEO 当然可以继续往技术层面展开：schema（给搜索系统看的结构化描述）如何写，作者和文章如何标识，页面之间如何组织。但我判断一条链接是否应该存在，只看一个问题：它能不能说清两份内容之间的关系？
如果两个彼此无关的页面，只是为了让引用数量好看而互相挂上链接，在我看来，这条链就失去了事实依据；如果一篇文章确实从旧文章继续往下写，或一册影集确实补充了周刊里的某段经历，链接就有成立的理由。它不负责把两个内容变得相似，只负责说明它们本来就有关。
放在我自己的做法里，编号、作者名、URL 和站点分工会尽量保持稳定；引用、callback、补充和勘误，则回到内容事实本身。观点可以变化，但我不希望把这种变化伪装成从未发生。向内守住“我”和向外接入“链”并不冲突：如果“我”已经被改造成适合网络识别的样子，外面接上的就不是我的链。
最后
我是 MoeWah，我现在还不急着把所有关系都命名，也不急着把这套关系扩展成一份完整的规则表。
我想先继续把每份记录留下来，让它们在各自的位置上被找到，再让真实存在的关系慢慢把它们连接起来。实体成链，不是把自己交给网络，而是让自我从内向外生长，在彼此不被抹平的前提下，和更大的网络共生。
至于它们以后会互相补充、修正，还是走向完全不同的方向，留给时间，静待一切自然的发生。
评论
Comments评论加载中…