Let’s talk about a real car rollover scene first
On July 5, 2026, I am revising the official website. An AI was helping me adjust the site navigation. Halfway through, I found that the article data file had been changed, and there was a new course page.
The person who changed it is another AI. It is performing another task, which has nothing to do with this revision, and it is started directly in the same folder. Neither side is archived, and the changes are all mixed together.
What’s the most ironic thing? I wrote this rule in black and white on my work board two weeks ago: "Check the status of a file before moving it." The rules are there, but they are still being violated.
The point of this matterIf you also start using AI to help you maintain your website, sooner or later it will be your turn. It’s not that AI is bad, it’s that “relying on consciously following rules” cannot prevent negligence. So do people.
Three sources of version confusion
1. Multiple tasks share the same work folder
This task is changed to page A, and that task is changed to file B. Each one does not know the other's existence. Git branches cannot solve this problem, because branches only protect the history, not the "site": A has not archived it yet, and as soon as B switches branches, A's semi-finished product will be destroyed.
2. There are too many places that need to be synchronized online, so it depends on human memory
Every time a new article is published on my website, six places need to be synchronized: the article page itself, the article list data file, the sitemap, the site index, the llms.txt read by the AI, and the two-way links between articles. There was an article that missed the process, and ended up suffering from three diseases at the same time: the Internet script was not installed, the English version was not built, and the navigation link was broken.
3. Problems can only be investigated afterwards
The Kanban board records where each task goes, but it is a schedule and cannot control the version. When you find that something is broken, you can only check the records and compare it to find out the cause, but you can't prevent it from happening next time.
Solution: Turn inspection into gate
I later condensed the entire approach into three layers and named it "Publish Gate". The core idea is: leave the inspection to the machine. If the inspection fails, the website will not be able to exit.
First floorOne task and one workshopUse git worktree to open a separate folder for each task, and only return to the main line after completion. No one is ever working on the main folder. The two AIs are not in the same room at all and cannot step on each other.
Second floorThere is only one entrance to go onlineThe things that should be checked before going online are written as preflight scripts: whether the link is broken, whether the new page is indexed, and whether the key is written into the public file. Then string it together into a publish script, and finish it all with just "publish".
Third floorYou will also be blocked if you forget to use the gate.Add a git pre-push hook: If anyone or any AI wants to push the mainline, it will automatically run a check first, but it will not be pushed out. This lock is tied to the repo itself, and no AI from any company can circumvent it.
The first level of instructions looks like this, as long as your AI can understand it:
# One task and one independent workroom
git worktree add ../my-site-worktrees/task-name -b task-branch origin/main
The first actual test after installation: the release script was run through one-stop process from inspection to deployment to online verification, with zero manual effort. Later, I deliberately left a bad link to push, and it was really blocked. That moment and the sense of peace of mind that "the rules are written in the document" are completely different.