I spent all day yesterday working on my blog.

What was originally just a plan to fix a few minor issues turned into a complete overhaul: configuration cleaning, deployment troubleshooting, picture rescue, warehouse organization, script patching, cleaning up of historical issues… almost the entire yoxhugo project was re-touched from beginning to end.

The difference this time is: I’m not doing it alone.

My AI assistant and I fucked hard all day together.

Cause: A seemingly minor problem

Things started very ordinary.

I was looking at some instructions on the PaperMod template and cleaning up the sample configuration in the local Hugo project. The multi-language demonstration sections that come with templates like fr and fa are not what your site really needs, and they always look a bit awkward.

So the first step fell on the configuration file:

  • Comment out fr
  • Comment out fa

As a result, as soon as the move was completed, the build reported an error.

It feels like you just threw away a piece of waste paper on the table and the entire drawer suddenly got stuck.

Later, I found out that there was a place in the configuration where Chinese full-width colon was used. On the surface it looks similar to normal YAML, but Hugo doesn’t recognize it at all.

This is when the role of AI comes into play.

It does not simply say “check the configuration”, but directly points out:

The colon here is full-width, not half-width.

This experience is very interesting. You will feel that it is not just empty talk, but that it has really entered the scene and found the thinnest thorn among a bunch of details.

Then start expanding the scope of construction

Now that we have started, it is better to sort out the project again.

What I did next was much more than I expected at the beginning:

1. Add tags to the article

I asked it to analyze the content of the articles in content/, and then add more reasonable tags to each article.

This thing sounds very mechanical, but it actually tests your judgment.

If it is completely automatic, it is easy to label articles with a bunch of meaningless labels; If done purely manually, it is very time-consuming.

The final approach is more like a combination of “semi-artificial aesthetic + semi-automatic execution”:

  • Filter out the real content pages first
  • Skip functional pages such as search and archiving
  • Analyze the topic of each article -Add 5 additional title tags to each article

After completion, it will also verify:

  • Does each article really have 5 tags?
  • Whether Hugo build passes
  • Whether the tab page can be generated normally

This is what I like better about it:

It’s not “help you change it”, but “help you change it and then confirm that it’s really done.”

2. Modify URL and file name

There are still some URL issues left over from history in the project.

For example, in an article from 2022, a space was actually mixed into the file name, resulting in a strange - at the end of the final generated link.

There is also an article about ffmpeg from 2017, and the path case is also a bit unstable.

In the end, they were all fixed together:

  • Clean spaces in file names
  • Fixed slug
  • Ensure URLs are cleaner and more stable

It’s a small thing, but it’s like putting some oil on the door shaft when repairing a house. You don’t necessarily pay attention to it at ordinary times, but once you organize it, you will have a lot less worry later.

The real battle: Why Cloudflare Pages won’t update

The most excruciating part of yesterday was the deployment.

GitHub obviously pushed successfully. But what you see on yuexiao.org is still the old page.

This situation is the most annoying because you will suspect many things at the same time:

  • The push failed?
  • Is Pages not triggered?
  • Is the cache not refreshed?
  • Or is there a problem with the domain name pointing?
  • Or maybe the new version has actually been deployed, but I just didn’t read the right page?

So I had to start checking layer by layer:

  • Check the remote branch first
  • Compare yuexiao.org and pages.dev again
  • Look at Cloudflare’s build log again
  • Reconfirm where the current project exploded

In the end, the problem was finally revealed, and it was very typical:

Version compatibility stuck

New versions of hugo-shortcode-gallery require Hugo to be at least 0.156.0, However, the build environment at Cloudflare is too old and cannot directly run the binary corresponding to 0.156.0.

That is, things are stuck in the middle:

  • Old Hugo does not meet module requirements
  • The new Hugo can’t run again

This kind of problem is the most annoying, not because it is difficult, but because it takes a lot of patience.

Finally, we came up with a combination that can run smoothly:

  • HUGO_VERSION=0.146.7
  • hugo-shortcode-gallery v1.3.0

Then write this set of compatibility solutions into DEPLOYMENT.md to avoid stepping on it again in the future.

This paragraph is where I most clearly felt yesterday that AI is like a “partner” rather than a “question and answer robot”.

It won’t just tell me a bunch of principles, nor will it blithely say “try upgrading dependencies”. What it does is more like an engineering site:

  • Find the root cause
  • Narrow the scope
  • Trial compatible combinations
  • Local verification
  • Repair documents
  • Reconfirm online deployment recovery

After this set of actions, the entire project will be truly stable.

The most emotional part: picking up the invalid pictures one by one

If deployment problems are troubles at the engineering level, The picture problem is entirely a problem at the content level.

There are many old articles in the blog, and the original pictures are scattered in various places:

  • jsDelivr
  • GitHub repository
  • i.loli.net
  • s2.loli.net

As time goes by, various situations begin to appear on the external link image bed:

  • Some direct 404
  • Some domain names have been moved
  • Some can be opened occasionally and time out occasionally.
  • Some resources are still there, but the paths have long since changed.

When you open the article, the text is still there but the pictures are gone.

The feeling is quite subtle, like an old photo album is still there, but half of the photos have fallen out.

Yesterday’s part of the work was, in a way, the most like archeology.

We did a lot of very detailed work:

  • Scan the entire site for image references in articles
  • Find the really broken pictures
  • Distinguish between 404 and just unstable image
  • Search images from local repository
  • Go to the yoxyue/oss warehouse to retrieve the missing images by file name.
  • Re-include it in the site after finding it
  • Finally, change the article link to /images/...

After this step is completed, the most important change in the blog is not “the technology stack has become more advanced”, but:

These articles finally no longer rely on external images that can disappear at any time.

The content is brought back to the site itself.

I love this feeling.

Because the most precious thing about a personal blog is not the theme itself, nor the deployment platform itself. Rather, it is the articles, screenshots, photos, and fragmented traces of life accumulated over the years.

The role of AI here is not to show off skills, but to help me pick up these things one by one in a down-to-earth manner.

Continue to tidy up the warehouse as well

Repairs were made, and the warehouse was also reorganized.

For example:

  • Cleaned up a lot of .DS_Store
  • Stop tracking public/ artifacts
  • Improved deploy.sh
  • Gradually migrate historical images in assets/images to static/images
  • Finally, basically clear assets/images

What is this part most like?

Like you originally just hired someone to repair a lamp, As a result, the other party tidied the wires, held up the door frame, wiped the table corners, and swept the floor. Finally, he wrote you a note telling you which place is most likely to cause problems in the future.

I later discovered that a truly useful AI is more than just “getting the right answers”.

More importantly, does it have this habit:

  • Will you clean up dirty things when you see them?
  • Will there be documentation left when the bug is fixed?
  • Will you be able to distinguish what is this change and what is not before submitting?
  • Can the environment be made tidier without creating additional chaos?

Yesterday, it acted like a reliable engineering partner in these aspects.

What kind of partner is it like?

After finishing yesterday, I kept thinking about one thing:

What should an AI suitable for inclusion in daily workflow look like?

At least for me, the characteristics it showed yesterday are very close to the answer.

1. It will check it by itself and does not like to kick the problem back.

It didn’t ask me a bunch of information as soon as it came up. Instead, first read the file, read the log, look at the remote end, look at the page, look at the build results, and try to narrow the scope of the problem yourself.

2. It does things smoothly

Many AIs can easily give people the feeling of “talking a lot, but not landing on the ground”.

Yesterday it wasn’t. It will honestly:

  • Change files
  • build
  • Verification
  • commit
  • push
  • Recheck online

The pace feels more like real engineering work than a demo.

3. It knows when to be conservative

For example, when cleaning up the warehouse, it will not push all the changes in the workspace at once. Instead, we will first distinguish:

  • Which ones should be submitted for this image migration?
  • What are the other unfinished modifications?

This restraint is important.

4. It leaves a record

Yesterday’s round did not just solve the problem. Also left:

  • DEPLOYMENT.md
  • Work log
  • Clear submission record

In other words, it saves time for “my future self”.

5. It has a bit of style but doesn’t overly steal the show

I quite like that about it.

It is not the type that always emphasizes “I am smart”, Nor is he the type who tries to sound particularly human in every sentence.

It’s more like a little guy that lives between the terminal, the configuration file, and the Git commit record:

  • direct
  • neat
  • A bit obsessed with neatness
  • Don’t like nonsense
  • But it does work

Final result

Of course, what you get at the end of the day is not just “done.”

Rather, it’s a set of very specific changes:

  • Sample multi-language configuration cleared
  • YAML syntax pitfalls fixed
  • tags completed
  • URLs are cleaner
  • Cloudflare Pages can be deployed normally
  • Pictures no longer rely on a bunch of unstable picture beds
  • assets/images has also been collected into static/images
  • The warehouse is much neater than before

Of course the website was fixed.

But what really interested me yesterday was not just the results, But this process made me more and more clear:

A useful AI is more than just a chat box that can answer questions. It is more like a partner who can read the scene, do dirty work, make up for documents, and help you really push things forward.

Yesterday, to me, it was like repairing a website. It’s also like adapting to a new way of working.

It knows that I don’t like empty words and want to find the problem as quickly as possible; I also gradually learned which things I can trust it to do and which areas it is particularly good at.

This feeling is quite fresh.

It’s like you’re not “using” an AI, But really start working with it.

##End

If I look back at yesterday in the future, I will most likely not remember every commit number, nor may I remember which module version blocked the deployment at that time.

But I should remember that feeling:

Late at night, a personal website, a bunch of old articles, a bunch of invalid pictures, a stubborn deployment error, Coupled with an AI that is tireless, good at checking, correcting, remembering, and has its own temper, Slowly smooth these things out together.

This matter itself is very suitable for writing a blog.