祝融说。

This is the most important chapter in the entire book. Whatever project you are working on, you can use this workflow to organize the work.

3.1 Why You Need a Workflow

Suppose you have just installed an AI coding tool and want to test what it can do. You type:

"Build me a note-taking app."

The AI starts generating code. Files are created one after another, lines of code stream out. It all looks great—a polished interface, feature-complete.

But when you look closely, you find problems: the data is stored in the browser's localStorage, when you had wanted it on a server. The tech stack is not the one your team uses. Some of the code seems needlessly complex for the simple functionality you need.

This is the cost of "having no workflow." The AI is powerful, but if the target is never aligned, what it produces can be entirely different from what you intended.

Why? Because the AI cannot read your mind, and it has no concept of "project context." It does not know which tech stack your team uses, where your data needs to live, or how large your project is meant to grow. It can only "guess" the most likely implementation from its training data, based on that one sentence you gave it. And the outcome of a guess is almost never what you wanted.

A good workflow ensures that the AI always works in the right direction. It does not constrain the AI's capability; it channels that capability toward the correct target.

3.2 Overview of the Six-Step Workflow

The Six-Step Workflow breaks an AI coding task down into six steps that form a closed loop:

&circled1; Decompose → &circled2; Issue instructions → &circled3; Code → &circled4; Inspect → &circled5; Branch decision → &circled6; Update blueprint
                                                                              ↓
                                                                   Return to &circled1; (next milestone)

Each step has a clear objective and a clear output:

3.3 Detailed Walkthrough

Step 1: Decompose

What it does: Break the feature you want to build into several small tasks, each of which is called a "milestone."

Why does this step matter so much? Because the AI's context window is limited. If you hand a complex task to the AI all at once, it will jump back and forth between multiple concerns, producing tightly coupled code in which errors are hard to locate. The core purpose of decomposition is not "turning big things into small ones"—it is isolating risk. Each milestone is completed and inspected independently, so even if one milestone goes wrong, the rest is unaffected.

What does good decomposition look like?

Taking the "note-taking app" as an example, it can be decomposed into:

• Milestone 1: Set up the project scaffolding (project structure, configuration files)
• Milestone 2: Implement the notes list page (display all notes)
• Milestone 3: Implement the note editing page (create and edit notes)
• Milestone 4: Implement note deletion
• Milestone 5: Add search functionality

Principles of decomposition:

• Each milestone should be completable within 2 to 30 minutes. If it feels like it would take half a day, the decomposition is not fine-grained enough.
• Each milestone should be independently verifiable. You should be able to test it immediately once it is done.
• Milestones should follow a dependency order. Build the foundational functions first, then the higher-level ones on top of them.

How to collaborate with the AI:

Help me break the "note-taking app" down into several milestones that can be implemented independently.
Each milestone should be completable within 30 minutes and testable immediately after it is done.
List the dependency order.

Step 2: Issue Instructions

What it does: Give the AI clear instructions for the milestone currently in progress.

Why does instruction quality matter so much? Because the quality of the AI's code depends directly on the clarity of the instructions. A vague instruction ("implement user login") makes the AI guess, and the outcome of a guess is almost never what you intended. A precise instruction ("implement user login, with these acceptance criteria: passwords compared using bcrypt, JWT valid for 2 hours, errors returned in a unified format") leads the AI to produce code that covers your expectations exactly. The core of acceptance-driven development is "define the acceptance criteria first, then let the AI produce the code"—the acceptance criteria themselves are the best instruction.

What does a good instruction contain?

We are implementing Milestone 2: the notes list page.

Requirements:
- Display the title and last-updated time of every note
- Sort by last-updated time in descending order
- Clicking a note opens its editing page
- Support pagination, 10 items per page

Technical constraints:
- Use the Next.js App Router
- Fetch data through the API (already implemented in Milestone 1)
- Use Tailwind CSS for styling

Acceptance criteria:
- The page loads normally and displays the notes list
- Pagination works correctly
- Clicking a note navigates to the editing page

The four elements of an instruction:

1. What to do—the goal of the current milestone.
2. Requirement details—the specific functional requirements.
3. Technical constraints—the technical conventions that must be respected.
4. Acceptance criteria—how to judge that the task is complete.

Step 3: Code

What it does: The AI generates code according to your instructions. During this step you observe the AI's work without intervening.

What you should do at this stage:

• Observe whether the files the AI generates match your expectations.
• If the AI appears to have understood something incorrectly, point it out after it finishes the current file.
• Do not interrupt the AI's coding process to fix minor details—leave those to be handled together during the inspection stage.

Common questions

What if the code the AI writes uses a library I have never heard of?

Make a note of it and evaluate it during inspection. If the library meets the requirement without adding extra burden, it can be accepted.

What if the AI writes code that goes beyond the current milestone?

Gently remind it: "This feature will be implemented in a later milestone. Let's finish the current task first."

Step 4: Inspect

What it does: Check whether the code the AI generated meets the requirements. This is the most frequently skipped step of the six, and also the most important.

Why can inspection not be skipped? Because code generated by the AI is almost always syntactically correct—it is a probabilistic model, and every token it produces is "the one with the highest probability in the current context." This means its code looks "right," yet logical errors, edge cases, and security vulnerabilities are not visible at a glance. Inspection is not distrust; it is basic engineering discipline—just as you would not sign for a package without checking it first.

The inspection checklist

1. Functional check—Was the functionality implemented according to the acceptance criteria?
2. Code check—Is the code style consistent? Are there obvious quality problems?
3. Edge-case check—Were exceptional situations handled (empty data, invalid input, and so on)?
4. Security check—Are there obvious security issues (such as SQL injection or XSS)?
5. Blueprint check—Does the code conform to the project's architectural conventions?

How to inspect

You can review the code yourself, or have the AI check it for you. One effective method is to have the AI perform a self-check:

Inspect the code for the current milestone. Check:
1. Whether every feature is fully implemented
2. Whether the code quality is acceptable
3. Whether edge cases are handled
4. Whether there are any security risks
5. Whether it conforms to the project architecture

Step 5: Branch Decision

What it does: Decide the next move based on the inspection verdict.

Why is REBUILD more important than NEEDS_FIX? Many beginners hesitate at REBUILD—"I've written all this code; if I roll it back, wasn't all that work wasted?" But in reality, the cost for the AI to write code is near zero, while the cost for a human to review code is very high. If the AI spent 30 minutes going down the wrong path and produced 200 lines of code, fixing that code might take 3 rounds of conversation (5 minutes each, 15 minutes in total), and the quality of the patched code is usually lower than a rewrite. If you choose to rebuild—rolling back to the last clean commit and reissuing more precise instructions—the AI needs only 1 round of conversation (5 minutes), and the resulting code is of higher quality because the context is clean.

There are three possible verdicts after inspection:

PASS: The code meets the requirements

• Action: commit the code to git and move on to the next milestone.
• Example of a commit message: feat: implement notes list page

NEEDS_FIX: Minor issues that need to be fixed

• Action: describe the problem to the AI, have it fix it, then inspect again.
• Example: "The styling of the pagination buttons on the list page is wrong; they should be round buttons rather than square ones. Fix it and inspect again."

REBUILD: The code has strayed too far from the blueprint

• Action: roll back the code (git reset --hard) and reissue the instructions.
• Example: "This implementation uses a state management library I'm not familiar with. Roll back and redo it with a simpler approach."

Decision criteria

Step 6: Update Blueprint

What it does: If you made new discoveries during implementation (such as a better technical approach, or a flaw in the original design), write those findings into the blueprint.

Why update the blueprint? The blueprint is the AI's "working memory"—every time a conversation is reset, the AI rebuilds its understanding of the project from the blueprint. If the blueprint is out of date, the AI will make decisions based on incorrect information. The blueprint is therefore not a one-time document; it is a living document that is continuously updated.

When to update the blueprint:

• A better technical approach has been found.
• The original design had omissions or errors.
• New requirements have surfaced that were not considered before.
• A milestone needs to be re-split differently.

3.4 A Complete Example

Let us demonstrate the Six-Step Workflow with a complete example.

Scenario: Add pagination to the notes list page.

Step 1: Decompose

This is a small feature and does not require further decomposition. The entire feature is a single milestone.

Step 2: Issue instructions

Add pagination to the current notes list page.

Requirements:
- Display 10 notes per page
- Show pagination controls at the bottom of the page (previous, next, page numbers)
- Switching pages should not require a full page refresh

Technical constraints:
- The backend API already supports page and size parameters
- Use the existing UI component library
- Put the pagination component at the bottom of the page

Acceptance criteria:
- The pagination controls display correctly
- Clicking a page number switches to that page correctly
- The "previous" button is disabled on the first page
- The "next" button is disabled on the last page
- The total number of pages displays correctly

Step 3: Code

The AI generates the pagination component and the related logic. You observe that it is using components that already exist in the project.

Step 4: Inspect

Your inspection finds that pagination works correctly, but the edge case "the previous button should be disabled on the first page" has not been handled.

Step 5: Branch decision

The verdict is NEEDS_FIX. You tell the AI to fix this edge case. The AI fixes it and the re-inspection passes, so the verdict becomes PASS.

Step 6: Update blueprint

You discover a situation you had not considered before: when there are very few notes (say, only three), the pagination controls should not be displayed. You add this finding to the blueprint.

Then you move on to the next milestone.

3.5 Three Disciplines

Above the Six-Step Workflow, three disciplines run through everything. Violating any one of them can cause a project to spiral out of control.

Discipline 1: No Blueprint, No Coding

Do not let the AI write code without an architecture design. Why? Because the AI has no long-term memory—in every conversation, it faces a blank page. If you do not give it a blueprint, it can only "guess"—guess the tech stack, guess the naming style, guess the data structures. And "guessing" is the most expensive thing in engineering, because different conversations produce different guesses. Today you have the AI build user management, and it guesses one naming style; tomorrow you have it build order management, and it guesses a different one—and the two modules' data models end up conflicting.

Those five minutes of design will save you five hours of rework later.

Discipline 2: No Inspection, No Commit

Do not commit AI-generated code without inspecting it. Why? Because the AI suffers from a "self-consistency trap"—its code looks "right," but it may harbor logical errors, missing edge cases, or security holes. A functional test only checks "registration succeeded"; it does not check "whether the password was encrypted." If you commit uninspected code, those hidden problems become permanently baked into the codebase.

One simple way to inspect: have the AI check its own code once, and then you confirm the result.

Discipline 3: When in Chaos, Rebuild

If you find that the AI's code has strayed too far from the blueprint, or has grown messier with every patch, roll back decisively and start over. Why? Because the cost of fixing may exceed the cost of rebuilding. The cost for the AI to write code is near zero, but the cost for a human to review code is very high. Fixing a bug in messy code can take two hours, while rolling back and rebuilding takes only ten minutes—and the code you get is of higher quality.

Rolling back is not shameful. Patching on top of broken code is.

Chapter Summary

The Six-Step Workflow is the core process of AI coding, but it is not a rigid template to be followed slavishly; it is a way of thinking. The reasoning behind each step matters more than memorizing the six steps: decomposition is for isolating risk, issuing instructions is for acceptance-driven development, inspection is for resisting the self-consistency trap, the branch decision balances the cost of fixing against the cost of rebuilding, and updating the blueprint keeps the AI's working memory accurate. The three disciplines—No Blueprint, No Coding; No Inspection, No Commit; When in Chaos, Rebuild—are not suggestions but bottom lines. In the next chapter, we put the Six-Step Workflow into practice with a complete project.