I built many AI projects. Most failed, so I wrote this book.

I have built many AI projects. Some looked good and some were ready to demo quickly. But when I replaced "does the page open?" with harder questions, the answers became uncomfortable: who needs it, who used it, what changed, and what evidence justifies another version?

I had to admit that most of those projects failed.

Failure does not always mean the code stopped running. A page may open, every button may work, and a demo may even earn a polite "looks good." The real problem is that the project never entered the world. It met no specific user, survived no real situation, and produced no evidence strong enough to change the next decision.

A polished page is not a real project

AI has lowered the cost of producing a first version. That is useful. It also makes it easier to confuse generation with completion.

1. Who will use it? Name a real person, not "everyone."
2. Where will they use it? Name a real situation, not an imagined need.
3. What does the first version solve? Keep one golden path, not a platform feature list.
4. What evidence decides the next step? Watch what users do, not how excited the maker feels.

A magic prompt cannot rescue a vague intention

I once spent too much time looking for smarter prompts. The missing piece was usually not a clever sentence. It was a clear work brief.

A useful work brief states the context, goal, source materials, allowed scope, forbidden changes, completion criteria, and test method. Codex can then act with less guessing, and you can judge what it actually did.

That is why this book repeats a simple rhythm: ask AI to explain the project, ask for a plan, approve the plan, make the change, then run and test it. "Done" in a chat window is not the same as verified in the product.

"Looks good" may be the least useful feedback

Useful feedback is behavior. Did a user open it? Could they complete the key action alone? Where did they stop? Would they use it again? Which assumption did reality overturn?

A project can succeed, fail, narrow, pivot, or stop. Any of those outcomes can be valid when the process and evidence are real.

So I wrote this book

The Zhiyuan Vibe Coding Red Book is not another tool collection. It follows a complete path: observe a person, define a problem, break down the work, collaborate with AI, build the first version, test with users, and turn the evidence into a credible portfolio record.

What this book does not promise

It does not promise a job, funding, admission, income, virality, or project success. Completing the Codex starter path does not make someone a professional programmer. Completing one real project does not create a mature business.

It promises smaller actions, clearer boundaries, real tests, and honest feedback. At the end, you should have a working or demonstrable version, one round of real feedback, and a record that shows how you thought and chose.

Action for todayPrint action card

Observe one real person before imagining a product.

1. Write down one person you met or spoke with today.
2. Record the situation and the difficulty you observed.
3. Write facts before suggesting a solution.
4. Ask what one small first version could help that person complete.

Keep this observation. It may become the beginning of your 16th case.

The 16th case is yours

The book will document 15 cases. The final place will not be filled with a polished author story. It belongs to a reader who begins, builds, tests, and records the truth.