祝融说。

7.1 Why You Need a Process

Imagine you just installed an AI coding tool and want to try it out. You type: "Build me a notepad app."

AI starts generating code. Files are created one by one, code is output line by line. It looks impressive -- the interface is attractive, and the features seem complete.

But when you look closely, you find problems: the data is stored in the browser's localStorage, but you wanted it on a server; the tech stack isn't what your team uses; some code looks complex, but you only need simple functionality.

This is what happens without a process. AI is powerful, but if you don't align on goals, it may build something entirely different from what you need.

Why? Because AI cannot read minds, nor does it have a concept of "project context." It doesn't know what tech stack your team uses, where your data should be stored, or how large your project needs to scale. It can only take the single sentence you provide and "guess" the most likely implementation from its training data -- and that guess will almost certainly not be what you want.

A good process ensures AI always works in the right direction. It doesn't limit AI's capabilities -- it channels them in the right direction.

From the "mental leap" in Part Two to here, the methodology starts to take shape. The Six-Step Workflow is the core track for guiding AI.

7.2 Overview of the Six Steps: Decompose -> Issue Instructions -> Code -> Validate -> Branch Decision -> Update the Blueprint

The Six-Step Workflow breaks an AI coding task into six steps, forming a closed loop:

Decompose -> Issue Instructions -> Code -> Validate -> Branch Decision -> Update the Blueprint
                                                                    |
                                                              Return to "Decompose" (next milestone)

Each step has a clear objective and output:

7.3 Detailed Breakdown and Deliverables for Each Step

Step 1: Decompose.

What to do: Break the feature you want to implement into several small tasks, each called a "milestone."

Why this step is so important: Because AI's context window is limited. If you hand a complex task to AI all at once, it will jump between multiple features, resulting in tightly coupled code that is hard to debug. The core purpose of decomposition is not to "make big things small," but to isolate risk -- each milestone is completed and validated independently, so even if one milestone has problems, it won't affect other parts.

What a good decomposition looks like: For a "notepad app," you might decompose it as:

• Milestone 1: Create the project scaffold (project structure, config files)
• Milestone 2: Implement the note 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

Decomposition principles:

1. Each milestone should be completable in 2 to 30 minutes. If it feels like it needs half a day, you haven't decomposed finely enough.
2. Each milestone should be independently validatable. You should be able to test it immediately after completion.
3. Milestones should have a dependency order. Build basic features first, then upper-layer features.

How to collaborate with AI:

Help me decompose the "notepad app" into several independently implementable milestones. Each milestone should be completable within 30 minutes and testable immediately after. List the dependency order.

Step 2: Issue Instructions.

What to do: For the current milestone, issue clear instructions to AI.

Why instruction quality is so important: Because AI's coding quality depends directly on the clarity of your instructions. Vague instructions ("implement user login") force AI to guess, and the result will almost certainly not be what you want. Precise instructions ("implement user login; acceptance criteria: passwords compared via bcrypt, JWT validity of 2 hours, errors returned in a unified format") let AI produce code that precisely covers your expectations. The core of acceptance-driven development is "define acceptance criteria first, then let AI code" -- the acceptance criteria themselves are the best instructions.

What good instructions contain:

We need to implement Milestone 2: Note list page.

Requirements:
- Display the title and last updated time of all notes
- Sorted by last updated time in descending order
- Clicking a note navigates to the edit page
- Support pagination, 10 items per page

Technical constraints:
- Use Next.js App Router
- Data fetched via API (API already implemented in Milestone 1)
- Use Tailwind CSS for styling

Acceptance criteria:
- Page loads correctly and displays the note list
- Pagination works correctly
- Clicking a note navigates to the edit page

The four elements of an instruction:

1. What to do -- the goal of the current milestone;
2. Requirement details -- specific feature requirements;
3. Technical constraints -- technical conventions that must be followed;
4. Acceptance criteria -- how to determine the task is complete.

Step 3: Code.

What to do: AI generates code based on your instructions. In this step, you observe AI's work but do not intervene.

What you should do during this phase:

• Observe whether AI-generated files match expectations;
• If AI misunderstands something, point it out after it finishes the current file;
• Do not interrupt AI's coding process to modify details -- wait for the validation phase to handle everything at once.

Common issues:

• What if AI uses a library I've never heard of? Make a note of it and evaluate during the validation phase. If the library meets requirements and doesn't add extra burden, it's acceptable.
• What if AI writes code beyond the current milestone? Gently remind it: "This feature will be implemented in a later milestone. Please finish the current task first."

Step 4: Validate.

What to do: Check whether AI-generated code meets requirements. This is the step most often skipped among the six, but also the most important.

Why validation cannot be skipped: Because fluent, plausible generation does not prove correct logic. A model predicts a token distribution from context; only greedy decoding selects the most probable token at each step, while sampling draws from the distribution (see Transformers generation strategies). Its code may therefore look "right," but logic errors, edge cases, and security vulnerabilities are not obvious at a glance. Validation is not about distrust -- it is a fundamental engineering practice, just as you wouldn't sign for a package without inspecting it. The validation target in this chapter is code; when a milestone's changes affect model behavior (prompts, model, sampling parameters, context), code review cannot catch the quality of model outputs -- for evaluating model output quality, see Chapter 23.

Validation checklist:

1. Functional check -- Are all features implemented per acceptance criteria?
2. Code check -- Is the code style consistent? Are there obvious quality issues?
3. Edge case check -- Are edge cases handled (empty data, invalid input, etc.)?
4. Security check -- Are there obvious security issues (e.g., SQL injection, XSS)?
5. Blueprint check -- Does the code follow the project architecture conventions?

How to validate: You can review the code yourself, or have AI help you check. An effective approach is to have AI perform a self-check:

Validate the code for the current milestone. Check: 1. Whether all features are implemented; 2. Whether code quality is acceptable; 3. Whether edge cases are handled; 4. Whether there are security vulnerabilities; 5. Whether it follows the project architecture.

Step 5: Branch Decision.

What to do: Decide the next step based on the validation result.

After validation, there are three possible outcomes:

• PASS: Code meets requirements. Action: commit the code to git, then move to the next milestone. Example commit message: feat: implement note list page.
• NEEDS_FIX: Minor issues need fixing. Action: describe the issue to AI, have it fix it, then re-validate. Example: "The pagination buttons on the list page have the wrong style -- they should be round, not square. Fix and re-validate."
• REBUILD: Too far off the blueprint. Action: use Section 10.4 to distinguish a personal, unshared branch from shared commits, preserve needed work, and verify the target before choosing a safe recovery path; then issue new instructions. Example: "This implementation uses a state-management library I do not know; I will return to a clean milestone through a verified recovery path, then redo it more simply."

Decision criteria:

Why REBUILD is more important than NEEDS_FIX: Many beginners hesitate when they see REBUILD -- "All that work, and now I have to throw it away?" But AI generation cost and human review cost are not symmetric. Chapter 7 retains this signal table for quick use in the workflow; the complete total-cost calculation and applicability boundary are in Section 7.5.

Step 6: Update the Blueprint.

What to do: If you discover new findings during implementation (such as a better technical approach or a flaw in the original design), write these findings into the blueprint.

Why update the blueprint? The blueprint is AI's "working memory" -- after each conversation resets, AI rebuilds its understanding of the project from the blueprint. If the blueprint is outdated, AI will make decisions based on incorrect information. So the blueprint is not a one-time document, but a living document that is continuously updated.

When to update the blueprint:

• You discover a better technical approach;
• The original design has omissions or errors;
• New requirements emerge that weren't considered before;
• The decomposition of a milestone needs adjustment.

7.4 A Complete Example: Pagination for the Note App

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

Scenario: Add pagination to the note list page.

Step 1: Decompose. This is a small feature that doesn't need further decomposition. The entire feature is one milestone.

Step 2: Issue Instructions.

Add pagination to the current note list page.

Requirements:
- Display 10 notes per page
- Show pagination controls at the bottom (previous, next, page numbers)
- No full page refresh when switching pages

Technical constraints:
- Backend API already supports page and size parameters
- Use existing UI component library
- Place pagination controls at the bottom of the page

Acceptance criteria:
- Pagination controls display correctly
- Clicking page numbers switches correctly
- "Previous" button is disabled on the first page
- "Next" button is disabled on the last page
- Total page count is displayed correctly

Step 3: Code. AI generates the pagination component and related logic. You observe that it uses existing components from the project.

Step 4: Validate. You check and find that pagination works correctly, but the edge case "disable the previous button on the first page" was not handled.

Step 5: Branch Decision. The result is NEEDS_FIX. You tell AI to fix this edge case. AI fixes it and you re-validate -- it passes. The result changes to PASS.

Step 6: Update the Blueprint. You discover a case that wasn't previously considered: when there are very few notes (e.g., only 3), the pagination controls should not be displayed. Update this finding in the blueprint.

Then move to the next milestone.

7.5 Repair or Rebuild: Count the Full Cost

These are teaching assumptions, not customer measurements or industry benchmarks: failure is confined to an independent unreleased milestone, the accepted foundation is recoverable, and requirements and interfaces are clear. Price everything in RMB and provisionally value labor at RMB 200 per hour. Past effort is sunk; compare incremental costs from now on.

Under these assumptions, rebuilding saves RMB 180 by reducing the work of understanding tangled logic, not by making generation free. List files and state to protect and verify the recovery path in Section 10.4 before deciding. Both paths must pay for review and validation.

Change the conditions and the conclusion may reverse. A legacy module carrying implicit business rules, migrations, or complex external state may require extra recovery, test coverage, and release coordination to rebuild. A localized defect with a clear boundary often warrants NEEDS_FIX instead. Record uncertainties and their upper bounds; never omit protection of existing work, downtime, or acceptance costs to make rebuilding look cheap. Chapter 8 uses this account to support discipline; Chapter 10 implements recovery. Neither introduces another calculation.

[Hands-On] Complete a Small Feature Using the Six-Step Workflow

Task: Add a "search by name" feature to an existing user list page, going through the complete Six-Step Workflow.

Guidance (what to do at each step):

1. Decompose: Assess whether this feature can be a standalone milestone (it can -- it doesn't depend on other unfinished features). If it feels too large, break it into three sub-tasks: "search API parameters," "search box UI," and "real-time results refresh."
2. Issue Instructions: Write instructions containing all four elements -- goal (add search functionality), requirements (input keywords for fuzzy name search, real-time refresh), technical constraints (backend API already supports search parameter, use existing component library, 300ms debounce), acceptance criteria (inputting keywords filters correctly, empty results show empty state, clearing search restores full list).
3. Code: Let AI execute, observe only without interrupting.
4. Validate: Check using the five-dimension checklist (functional / code / edge cases / security / blueprint). Pay special attention to edge cases -- empty search keyword, matching only one result, including special characters.
5. Branch Decision: PASS means commit (feat: user list supports search by name); NEEDS_FIX means fix and re-validate; REBUILD means roll back and rebuild.
6. Update the Blueprint: Write the search feature's API contract and debounce convention into the blueprint.

Validation points (for instructor/self-assessment):

• Did the student's instructions contain all four elements?
• Did the student maintain "observe only" during the coding phase?
• Did the student's validation cover edge cases?
• Was the student's branch decision decisive and consistent with the cost-benefit analysis?
• Did the student update the blueprint after completion?