Designing a personal site as a long-lived system

If a personal site is expected to keep absorbing essays, project retrospectives, and public thinking, then the core question is not visual polish. The core question is system design.

The first problem is not the homepage

The real work in this round was not picking a hero line or deciding where cards should sit. It was answering a smaller set of structural questions:

• how public content and private knowledge should be separated
• whether bilingual support belongs in the URL or inside individual pages
• whether blog posts and project studies should both render from content files
• whether the content directory can survive when images and attachments arrive later

If those questions are left vague, every new entry eventually becomes a layout and routing problem again.

Why the site now uses locale routes, MDX, and folder-based entries

The public content structure is now explicit:

content/blog/zh/<slug>/index.mdx
content/blog/en/<slug>/index.mdx
content/projects/zh/<slug>/index.mdx
content/projects/en/<slug>/index.mdx

That solves three practical problems at once.

First, Chinese and English entries are separated cleanly instead of fighting for space inside a single file.

Second, every entry gets its own folder, which means images, diagrams, covers, and side notes can sit next to the actual content.

Third, the rendering layer is now decoupled from the content itself. Adding a new entry mostly means adding a new folder and index.mdx, not writing another bespoke page.

Why the knowledge base stays private

The knowledge base is not public writing. It is an internal archive for notes, references, evolving structures, and incomplete thinking.

That kind of material is valuable, but it does not automatically belong on a public site. Treating it as if it were public content usually lowers the quality of both the archive and the public writing.

So the current decision is simple: keep the knowledge base inside the repository as content storage, and only publish material once it has been turned into a blog post or project case study.

What the system can actually support now

The site is no longer a future-facing shell. It can already do concrete work:

• the homepage reads recent entries from content files
• blog posts and project studies share reusable detail templates
• bilingual content is maintained in parallel rather than improvised in the UI
• folder structure is ready for colocated assets

The next step is not more surface area. It is simply to keep feeding real content into a structure that now knows how to hold it.