How this website came to be

The website before this one

The previous version of this website was intentionally small. It was a single index.html file: my Chinese and English names in the center of the screen, followed by links to Google Scholar, email, and GitHub. The page did not scroll. It disabled text selection and copying, loaded its assets from a CDN, and ended with the line “99% created by ChatGPT-4o.”

That page worked as a digital calling card. It answered one basic question - how to find me elsewhere - but it could not explain what I study, what I have built, or how those projects connect. Updating it also meant editing presentation and content in the same HTML file.

As my work developed, I wanted the website to become something different: not a larger calling card, and not a promotional landing page, but a quiet research workspace that could grow over time.

From one page to a small research archive

The new site is organized around four distinct paths.

• Home contains a single interactive fluid surface and a Bruce Lee quotation. It creates an immediate connection to simulation without turning the first screen into a biography.
• Projects documents substantial research threads. The first project, LandslideSIM, connects its Julia packages, numerical methods, simulation media, GitHub repositories, and papers in one place.
• Notes is the writing layer of the site. Each note is a Markdown file with a title, date, description, reading time, and tags. This article is the first real entry.
• About carries the biography, academic journey, research interests, profiles, and a globe connecting the places that shaped that journey.

Publications remain on Google Scholar rather than being copied into a second archive that would need to be kept in sync.

Underneath those pages is a deliberately plain content structure:

src/
  content/
    projects/       Research project articles
    notes/          Essays and working notes
    about.md        Biography
  data/
    site.ts         Profile links and academic journey
  pages/            Astro page templates
  components/       Interactive visual elements
  styles/           Shared visual system
public/
  images/            Project media

The site is built with Astro and published as static HTML. Content collections validate the metadata before a build succeeds, so a missing date or malformed project entry becomes a development error rather than a broken production page. A GitHub Actions workflow builds the site and deploys the generated files to GitHub Pages.

This separation matters. A new note now requires a Markdown file, not a redesign. A new project can reuse the same page structure while carrying its own links, figures, and narrative.

Prompting the direction, one decision at a time

The new website was built with Codex, but not by asking it to “make me a personal website” and accepting the first result. The useful work happened through a sequence of increasingly specific prompts.

1. Define the character before the components

The first prompts established that this should be an academic profile and research archive. I wanted it to feel calm, contemporary, and precise - not like a startup landing page, an online newspaper, or a visual-effects demo.

Those constraints shaped later decisions. They discouraged decorative cards, marketing copy, generic hero sections, and unnecessary motion before any page was designed.

2. Decide what each page is responsible for

We then separated the site into Home, Projects, Notes, and About. I specified the journeys that should take one click: reaching Google Scholar, opening a project, reading a note, or finding contact details.

This step made the structure clearer than the old all-in-one page. It also gave every piece of information an owner. The biography belongs on About; publications belong on Scholar; detailed research belongs in Projects; evolving ideas belong in Notes.

3. Shape the homepage by removing things

The homepage became more focused through prompts that said what should not appear. I did not want a portrait, a visible name, an affiliation, a research-area label, or a list of recent content in the first viewport.

What remained was one interactive water surface and the quotation: “Empty your mind. Be formless. Be shapeless. Like water.” The simulation gives the site a computational identity, while the absence of explanatory text keeps the first page open and quiet.

4. Replace assumptions with verified information

The content became real only when I supplied facts: dates and institutions in my academic journey, my move to Xihua University, the names of my Ph.D. supervisors, and the scope of my research interests.

The same process applied to LandslideSIM. I provided two papers and pointed Codex to the GitHub organization. The project page was then grounded in the package documentation, publication metadata, figures, animations, and reported performance results.

This also required correction. When the page said the project continued to the present, I marked the word “present” and clarified that the project ended in 2025. When a headline claimed support for 190 million double-precision particles, I asked where the number came from. The paper confirmed it, but Table 7 also revealed the missing scope: it was the maximum for a 2D standard MPM configuration on a 96 GiB NVIDIA GH200. A shorter claim was convenient; the qualified claim was accurate.

5. Edit the interface in place

Later prompts became small and local. I selected a sentence directly in the browser and asked to add AI to the description of my research. I selected the timeline and corrected its end date. I supplied a new biography in Chinese and asked Codex to turn it into natural English consistent with the rest of the site.

These were not new design briefs. They were editorial moves: point to the exact surface, state what is wrong or missing, and let the implementation follow the decision.

6. Verify after every meaningful change

Each content or structural update was followed by schema checks and a production build. Links, images, GIFs, and PDFs were checked from the generated static site. Responsive rules keep the reading order intact on smaller screens, while interactive elements retain static fallbacks when JavaScript or WebGL is unavailable.

The prompt was therefore never just an instruction to generate code. It also defined what counted as finished: factually grounded content, valid structured data, working production output, and a page that remained readable outside the ideal desktop setup.

What the collaboration actually looked like

The old footer described the website as “99% created by ChatGPT-4o.” That was a playful and fairly accurate description of how the single page had been produced. This version is harder to summarize with a percentage.

Codex could inspect the repository, propose structure, translate ideas into implementation, trace a number back to a paper, and rebuild the site after each revision. But the important choices came from a continuing editorial conversation: what the website should represent, which details were true, what felt too generic, and what needed to disappear.

The most effective prompts were not necessarily long. They were specific and situated:

This project ended in 2025.

Add AI here.

Where did this number come from?

This is the biography.

Each prompt narrowed the distance between a plausible website and my website.

A website that can continue

The most important result of the migration is not a particular animation or layout. It is that the website now has a structure for future work. Projects can accumulate evidence and media. Notes can begin as short observations and become longer essays. The biography and academic journey can change without rewriting the site around them.

The website was born through prompts, but it is designed to outlast the conversation that created it. From here, maintaining it should feel less like rebuilding a webpage and more like continuing a research record.