祝融说。

We are born with an irresistible infatuation with speed. When AI can generate three hundred lines of code in three seconds for a complex problem we throw at it, the "instant gratification" is overwhelming. Our brains release dopamine, we marvel at its lightning speed, and we feel as though we possess the most powerful productivity tool in the world.

This obsession with speed is precisely the most dangerous and most deceptive trap in AI programming.

A junior engineer, upon receiving a requirement, reacts by jumping straight into writing code. A senior engineer or architect, upon receiving the same requirement, reacts by saying, "Wait, let me think first." They may spend hours or even days researching, drawing diagrams, comparing solutions, and assessing risks. They know that before the first character is typed on the keyboard, the outcome of the battle is largely already decided through mental war-gaming.

AI, by its nature, is a "junior engineer." Its underlying mechanism dictates that it will always tend to deliver the "highest-probability answer" at the "fastest speed," and that answer is often to generate code directly.

If we indulge this nature, we will forever receive only "junior" level output. The core of process constraint is to reverse this nature. What we must do is to "deprive" AI of the power it excels at most -- the immediate execution of code -- and force it to "slow down," imitating the thought process of a senior engineer: "think" first, then "act."

In this chapter, we will learn a standardized "three-step" workflow. This workflow will act as a "thinking scaffold," forcing AI to always first "research," then "plan," and finally "implement" when faced with any non-trivial requirement. Through this, we redirect AI's immense computing power from "low-quality rapid response" to "high-quality deep thinking."

7.1 Asking AI to Write Code Directly Upon Encountering a Problem Is the Dumbest Approach

Let us first dissect what exactly is wrong with "writing code directly." Why is this seemingly most efficient approach, when dealing with complex problems, actually the dumbest and most expensive choice?

Mistake One: You Get "Pattern Matching," Not "Problem Solving"

When you throw out a question without guidance, such as "How do I implement a plugin-based system?", AI does not truly "understand" the deeper meaning of "plugin-based" in your business context. Its neural network rapidly pattern-matches across its vast training data.

It finds thousands of code snippets, tutorials, and design patterns related to the keyword "plugin system." Then it selects the most common, most frequently occurring pattern (for instance, a simple "observer pattern" or "strategy pattern" implementation), "translates" it into code, and presents it to you.

This process lacks the most critical step: problem clarification and requirements analysis.

• What do you mean by "plugin"? Dynamically loaded DLLs/SOs, or just a few configurable JavaScript objects?
• How strict are the security requirements for plugins? Do they need to run in a sandbox?
• What is the communication mechanism between plugins? Do they need to share state?
• What is the lifecycle management of the main system and plugins?

These crucial questions that determine the final architecture are never asked by AI. It only gives you the most "generic" and "standard" answer. And this "standard answer" has a high probability of not fitting your unique, specific business scenario at all.

The result is that you either get an overly simplistic "toy" that cannot meet future expansion needs, or an over-engineered "aircraft carrier" that introduces unnecessary complexity. Either way, you waste time and start down the wrong technical path from the very beginning.

Mistake Two: Falling into the "Implementation Details" Swamp Prematurely

Once AI generates the first version of the code, your attention is immediately drawn to the code itself. You start thinking:

• Is this variable name good enough?
• Can this loop be optimized a bit?
• Should the parameter order of this function be adjusted?

This premature focus on "implementation details" is a major taboo in architectural design. It causes you to lose the global perspective. Before you have even figured out what the "skeleton" of the entire system should look like, you are already worrying about the pattern on a single "brick."

This is known in psychology as the "anchoring effect." The first version of code AI provides, good or bad, becomes an "anchor" for your subsequent thinking. You unconsciously make patches on top of this "anchor" (the "confirmation bias" we have repeatedly emphasized), and find it very difficult to step back and consider whether there is a completely different but better top-level design.

Writing code directly is equivalent to AI proactively casting an "anchor of thought" for you, trapping both you and itself on one specific, narrow implementation path.

Mistake Three: Giving Up Your Highest Power as "Decision Maker"

We established in Chapter 1 that the human's core role in AI collaboration is that of the "decision maker." And the value of decision-making lies in weighing and choosing between different solutions.

In software engineering, there is almost never a "single correct answer."

• Plan A: Best performance, but highest development cost.
• Plan B: Fastest development, but has security concerns.
• Plan C: A balance between the two.

Choosing which plan is not purely a technical question. It is a business decision that combines project timeline, team capability, business risk, future planning, and many other factors.

When you directly ask AI to write code, you are irresponsibly ceding this crucial "decision-making power" to AI. And AI, as a probability model with no business sense and no understanding of your company's strategy, what choice will it make for you? It will only select the most "mediocre" and "common" option in its training data.

This is an extremely dangerous power vacuum. You give up your most valuable work and let a most unsuitable "intern" decide the fate of the entire project.

Conclusion: "Speed" is the cheapest byproduct and the most expensive temptation in AI programming. A professional AI collaborator must develop immunity to this "instant gratification."

Our first principle is: Before the problem is fully understood, the solution is fully evaluated, and the decision is explicitly made, AI is strictly forbidden from generating any line of substantive business code.

We must deprive it of its "execution rights" until we -- as the commander-in-chief -- have a complete understanding of the entire battle's map, objectives, and marching route. To achieve this, we need a standardized battle procedure.

7.2 The "Three-Step" Standard Flow: Research, Plan, Execute

To force AI (and ourselves) to engage in "slow thinking," I have designed an inviolable "three-step" standard workflow. For any requirement of more than medium complexity (for instance, requiring more than half a day to complete), this workflow must be strictly followed.

This workflow is essentially the externalization and proceduralization of the implicit "problem-solving model" that resides in a senior engineer's mind.

Step One: Research -- What Are We Facing?

Goal: In this phase, our only goal is to gather information, clarify requirements, and identify constraints. Discussing any specific implementation solutions is prohibited. We must investigate the crime scene like a detective, rather than prematurely concluding who the culprit is.

Core Activities:

• Requirements Decomposition: Break a vague, product-manager-originated "big requirement" into a series of smaller, more specific functional items.
• Boundary Definition: Clearly define the "success criteria" for this requirement. What is its scope? What are the "must-dos" and the "nice-to-haves"?
• Technical Pre-Research: Are there existing third-party libraries or technologies that can be leveraged? What are their respective pros and cons? Are there known "pitfalls" or best practices?
• Risk Identification: Which parts of the existing system might be affected by implementing this requirement? What known technical, performance, or security risks exist?

Output: A brief, structured "Requirements Analysis and Risk Assessment" document.

AI's Role: In this phase, AI is not a "programmer" but your "super research assistant." It is exceptionally skilled at quickly retrieving information, summarizing documents, and comparing technologies.

Step Two: Plan -- How Do We Proceed?

Goal: Based on the information gathered in the first phase, begin designing and comparing multiple possible solutions. Note: "multiple," not "one." Our goal is to produce options and weigh trade-offs.

Core Activities:

• Solution Design: For the core technical challenges, propose at least two (preferably three) different architectural or design approaches.
• Solution Comparison: Objectively compare these solutions across multiple dimensions (development cost, performance, maintainability, security, extensibility).
• Decision Making: Based on the comparison results, the human makes the final, explicit technology selection and architectural decision.
• Task Breakdown: Further decompose the selected final solution into a clear, executable, prioritized "development task list."

Output: A document containing a "Solution Comparison Table" and the final "Technical Plan and Task List."

AI's Role: In this phase, AI is your "architecture design consultant." It excels at generating different styles of solutions based on your constraints and filling in the details of the comparison table for you. However, the final decision must be made by you.

Step Three: Execute -- Let Us Begin!

Goal: Only after the "technical plan" and "task list" from the second phase have been finalized do we enter this phase. The goal here is to efficiently and precisely transform the design into code.

Core Activities:

• Coding Implementation: Following the order of the task list, complete the coding for each small task in a focused manner, one at a time.
• Test Writing: Write unit tests and integration tests for the new code to ensure its quality.
• Code Review: Manually review the code generated by AI to ensure it complies with architectural constraints and coding standards.
• Documentation Update: Update relevant project documentation (e.g., CHANGELOG.md).

Output: Working, tested, standards-compliant code.

AI's Role: In this phase, AI can finally play the role it is most famous for -- "high-speed code generator." Because all the "thinking" and "decision-making" work has been completed in the first two steps. At this point, AI is running on an extremely determined, unambiguous "track," and its speed advantage can be safely and efficiently unleashed.

This "three-step" process acts like a mandatory "valve," ensuring:

• Thinking precedes action: Before we have clearly understood "what" and "how," the valve is closed, and no code can flow out.
• Humans retain decision-making power: In the second "plan" phase, there is a clear "decision point" that requires human intervention. This ensures that the project's steering wheel remains in your hands.
• High efficiency in the execution phase: Because of thorough preparation, the third "execute" phase becomes exceptionally smooth. The communication cost between you and AI drops to a minimum because all issues requiring "discussion" have already been resolved earlier.

7.3 What and How to Ask at Each Step (With Question Templates)

Theory is gray. The tree of life is evergreen. Let us see how, in practice, to guide AI through each of the "three steps" using specific questions.

The following templates are honed from countless hours of practice. You can adjust them according to your needs, but the underlying "thinking structure" is universal.

Phase One: Research -- Interrogate AI Like a Detective

Goal: Squeeze the value out of AI as an "information retriever" and build a comprehensive understanding of the problem.

Core Sentence Patterns: "Act as a [role]," "Analyze/Break down/List for me," "Identify risks," "Do not provide any solutions."

Template 7.1: Requirements Clarification and Decomposition

Your Question:

Context: We have received a new feature request from our product manager. The original request is: "[Paste the product manager's original wording, e.g.: I want a 'smart recommendation' feature that recommends relevant articles based on the user's browsing history.]"

Your Role: Act as a Senior Business Analyst. Your task is to break down this high-level, ambiguous requirement into a list of specific, answerable questions that we need to clarify before any technical work can begin.

Task:

1. Deconstruct the Requirement: Break the core request into smaller, functional components.
2. Identify Ambiguities: For each component, list the key questions we need to ask the product manager to define the scope and success criteria. Examples: What defines "recent" history? What does "related" mean? How many recommendations to show?
3. Define Boundaries: List what is explicitly out of scope for this feature's first version.

Constraint: Do not, under any circumstances, suggest any technical implementation or solution at this stage. Your entire focus is on clarifying the "What", not the "How".

Template 7.2: Technology Selection Pre-Research

Your Question:

Context: For our "Article Recommendation" feature, we need to choose a method to calculate the "relatedness" between articles. Let us assume articles have tags.

Your Role: Act as a Research Engineer. Your task is to conduct a preliminary investigation into common techniques for this problem.

Task:

1. Identify Techniques: List at least three common algorithms or techniques for calculating similarity based on tags (e.g., Jaccard Similarity, TF-IDF with Cosine Similarity, etc.).
2. Summarize Pros and Cons: For each technique, provide a brief, 2-3 sentence summary of its core idea, and list its main advantages and disadvantages in a bulleted list. Focus on aspects like computational complexity, ease of implementation, and quality of results.
3. Find Libraries: For each technique, identify one popular and well-maintained library in [your tech stack, e.g.: Python] that implements it.

Constraint: Do not recommend a "best" option. Your goal is to provide an objective, neutral summary of the available options for my review.

Phase Two: Plan -- War-Game Like a General

Goal: Have AI generate multiple parallel solutions and force it to engage in "self-debate," with the final decision made by you.

Core Sentence Patterns: "Design Plan A/B/C," "Create a comparison table," "Evaluate according to the following criteria," "I have decided to choose Plan X. Please create an execution plan for me."

Template 7.3: Multi-Solution Design and Comparison

Your Question:

Context: Based on our research, we have the necessary information to design the architecture for the "Article Recommendation" feature. Our core constraints are: the calculation must be fast (under 50ms), and it must run on our existing [e.g.: Python/Flask] backend.

Your Role: Act as a Solutions Architect. Your task is to propose and compare three distinct architectural approaches.

Task:

1. Propose Three Solutions:

• Solution A (Simple & Fast): An approach based on pre-calculating and caching similarity scores. Describe how and when this pre-calculation would happen.
• Solution B (Real-time & Flexible): An approach that calculates similarity on-the-fly with every request. Describe how to optimize this.
• Solution C (Hybrid): A combination of the two, e.g., using a faster, simpler algorithm for real-time and a more complex one for offline batch processing.

2. Create a Comparison Table: Generate a markdown table that compares these three solutions across the following criteria:

• Performance (Latency)
• Data Freshness (How up-to-date are the recommendations?)
• Implementation Complexity
• Infrastructure Cost
• Scalability

3. Provide a Recommendation: After the table, briefly state which solution you would recommend and why, explicitly stating the trade-offs it makes.

Template 7.4: Decision Confirmation and Task Breakdown

Your Question:

Context: I have reviewed the options. My Decision: We will proceed with Solution A (Pre-calculation). The trade-off of slightly less fresh data is acceptable for the gain in performance and simplicity.

Your Role: Act as a Tech Lead. Your task is to take this architectural decision and break it down into a concrete, step-by-step implementation plan.

Task:

1. Define Data Models: Specify any new database tables or data structures needed (e.g., an article_similarity table).
2. Outline Key Modules/Functions: List the main new functions or classes we will need to create. For each, give it a clear name and a one-sentence description of its responsibility (e.g., calculate_similarity_matrix(), get_recommendations_for_article(article_id)).
3. Create a Sequential Task List: Generate a numbered list of development tasks in the logical order they should be completed. This should be a checklist an engineer can follow. Example:
4. DB: Add 'article_similarity' table migration.
5. Backend: Implement the Jaccard similarity calculation logic.
6. Backend: Create a background job (e.g., cron) to run the calculation nightly.
7. Backend: Create the API endpoint GET /articles/:id/recommendations.
8. Tests: Write unit tests for the similarity logic.

Constraint: All tasks should be small enough to be completed in a single coding session.

Phase Three: Execute -- Craft Like an Artisan

Goal: On a completely determined track, maximize AI's code generation efficiency.

Core Sentence Patterns: "According to our plan, execute Task X," "Write code for this function," "Write tests for this code."

Template 7.5: Focused Coding Instruction

Your Question:

Context: We are now implementing the plan. Our current task is: "[Copy one item from the task list, e.g.: Backend: Implement the Jaccard similarity calculation logic.]"

Your Role: Act as a Senior Pair Programmer.

Task: Write the Python function calculate_jaccard_similarity(tags1: set, tags2: set) -> float.

Constraints:

• The function must be pure, with no side effects.
• It must handle cases where one or both sets are empty (return 0.0).
• Include a clear docstring explaining the formula.

After you provide the function, immediately provide a second code block with three unit test cases for it using the unittest framework.

Through this set of templates, you transform a one-time, vague "give me the code" request into a structured, human-led, progressively deepening "deep workshop." You are no longer AI's "user," but its "process manager."

[Flow Diagram] Mandatory Flow Path for Complex Requirements

To give you a more intuitive understanding of this process, here is a flow diagram that clearly shows how information and decisions flow between the three phases, and the critical "gatekeeping" role of the human decision maker.

graph TD
    A[Requirements Input - Vague] --> B{Phase 1: Research};
    B -- "Templates 7.1 & 7.2" --> C[AI: Generate Requirements Analysis & Tech Pre-research Report];
    C --> D{Human Review};
    D -- "Is the information sufficient?" --> |No| B;
    D -- "Yes" --> E{Phase 2: Planning};
    E -- "Template 7.3" --> F[AI: Generate Multi-Solution Comparison];
    F --> G{Human Decision};
    G -- "Choose Plan A/B/C" --> H["Template 7.4"];
    H --> I[AI: Generate Final Plan & Task List];
    I --> J{Human Final Confirmation};
    J -- "Is the plan clear?" --> |No| E;

    subgraph "Think Zone (No Code Zone)"
        direction LR
        B; C; D; E; F; G; H; I; J;
    end

    J -- "Yes, approved!" --> K{Phase 3: Execution};

    subgraph "Execute Zone (Coding Zone)"
        direction LR
        K -- "Template 7.5 (one task at a time)" --> L[AI: Generate Code & Tests];
        L --> M{Human Review & Integration};
        M -- "Task complete?" --> |Yes| N((Done));
        M -- "No" --> K;
    end

    style G fill:#f9f,stroke:#333,stroke-width:4px
    style J fill:#f9f,stroke:#333,stroke-width:4px

Diagram Explanation:

• Think Zone vs. Execute Zone: The entire process is divided into a "Think Zone" and an "Execute Zone" by a clear boundary. In the "Think Zone," no substantive business code may be produced.
• Human Gate (Pink Highlight): There are two critical "gate" nodes that must be operated by humans:

1. G - Human Decision: After comparing multiple solutions, you must make a choice. Without your approval, the process cannot move forward.
2. J - Human Final Confirmation: After AI generates the final execution plan, you must do a final review and approval. This is the last safety valve before "starting work."

• Iteration Loop: Notice the "No" arrows in the diagram. These represent that at each phase, if AI's output does not meet your requirements, you can (and should) have it return to the previous step for iteration and correction until you are completely satisfied.

Please treat this flow diagram as your "battle map" for collaborating with AI. It will constantly remind you that in the face of complex requirements, discipline, process, and patience are far more important than speed alone. By forcing AI to "think slowly" like a senior engineer, you will ultimately get truly high-quality, high-efficiency "fast results."