祝融说。

35.1 Why Tiered Training Is Needed (Junior / Senior / Tech Lead / Manager)

You organized the training, prepared the materials, arranged the instructors, and sent out the notices. On training day, everyone listened attentively. You thought: "This training went well." But a week later, you found the trainees back to their old habits -- letting AI write code directly, skipping acceptance, skipping blueprints. The training content seems to have been forgotten.

This is not a failure of your training; it is that "training" as an activity carries an inherent limitation: training can only solve the problem of "knowing," never the problem of "doing." A trainee can understand every step of the six-step workflow, but when they actually get hands-on, they still deviate. So a training plan must be designed around a single core goal: get trainees to start "doing" during the training, not just "listening."

Why is tiered training needed? Because different roles use AI-assisted coding in completely different ways:

• Junior developers need "how to operate" -- how to install tools, how to give instructions, how to run acceptance;
• Senior developers need "why to operate this way" -- why a blueprint is needed, why acceptance is needed, why rebuilding matters more than patching;
• Tech leads need "how to manage" -- how to guarantee quality, how to schedule multiple features;
• Managers need "how to decide" -- how to judge whether a method is working, how to control risk.

If you teach everyone the same content in the same way, the result is: juniors find it "too hard" (they cannot follow the architecture design), and seniors find it "too easy" (they have long since mastered the six-step workflow).

Tiered training plan:

Training formats:

35.2 Training Content Design and the "Listen-to-Do 1:1" Principle

The core design principle of training content: the ratio of "listening" to "doing" is at least 1:1. For every hour of theory, schedule one hour of hands-on practice. The gap between "knowing" and "doing" can only be closed by doing.

Junior developer training (2 days):

• Day 1: theory foundation -- morning (3 hours): what is AI-assisted coding? What can it do? Preparation and a detailed walkthrough of the six-step workflow; afternoon (3 hours): first hands-on project, follow the tutorial to build a notes app from scratch;
• Day 2: practice consolidation -- morning (3 hours): quick reference for common skills, common pitfalls and how to handle them; afternoon (3 hours): independently complete a small feature, confirm whether the full six-step workflow was followed, and hold a retrospective on the problems encountered and how they were solved.

Senior developer training (3 days):

• Day 1: methodology panorama -- morning: the complete system of the 14 skills, requirements analysis methodology; afternoon: architecture design practice, design a blueprint for an example project;
• Day 2: automated workflows -- morning: detailed breakdown of automated workflow mechanisms, acceptance system design; afternoon: hands-on use of Workflow to complete a feature and run the full four-dimensional acceptance;
• Day 3: project combat -- morning: project orchestration methods, fully automated build flow; afternoon: complete project practice, retrospective sharing.

Manager training (1 day) -- a full day (6 hours): the impact of AI-assisted coding on management, the 14 skills from a management perspective, the team rollout roadmap, quality governance methods, efficiency measurement, risk control, and drawing up the team's rollout plan.

Training material preparation: training materials are not just "textbooks" -- they also include example projects, templates, and checklists. Their purpose is to lower the entry barrier for trainees: trainees do not need to start from zero; they only need to practice on prepared materials:

1. Tutorial documents (printed or electronic versions of the three-volume tutorial);
2. Example projects (complete code for the notes app or other simple projects);
3. Practice projects (practice problems for trainees to work on);
4. Template files (blueprint template, acceptance template, report template);
5. Checklists (six-step workflow checklist, acceptance checklist).

Environment preparation: make sure every trainee's tools are installed and configured; prepare a git repository containing the practice projects; build a team knowledge base to hold the training materials and best practices.

35.3 Post-Training Follow-Up and Effectiveness Evaluation (Four Levels: Reaction / Learning / Behavior / Results)

Training is not a one-off activity; it is an ongoing process. Why follow up after training? Because changing habits takes time -- a trainee learns the six-step workflow in training, but back in day-to-day work, faced with urgent tasks and familiar habits, they easily fall back onto the old road of "let AI write the code directly." Post-training follow-up is about helping trainees consolidate new habits and keep from sliding back into old ones.

Post-training follow-up cadence:

• First week after training: each trainee completes a small feature and walks through the full six-step workflow independently; the tech lead reviews each trainee's practice; collect questions and feedback;
• First month after training: each trainee completes 3-5 features; hold team sharing sessions (each person shares one "most rewarding" point and one "most confusing" point); update the training materials and add common questions;
• First quarter after training: assess the team's skill maturity; identify weak areas and arrange targeted training; build a best-practice library.

Training effectiveness evaluation -- the four-level model (Kirkpatrick's four levels):

Common training problems and how to respond:

• Trainees find it "too easy" ("Isn't the six-step workflow just think first, then do?"): behind this reaction is a misconception -- knowing "what it is" does not equal being able to "do it." Response: let the trainee run through it once and discover in practice the gap between "knowing" and "doing"; introduce challenge scenarios to see whether they can persist through the full six steps.
• Trainees find it "too complex" ("So many skills, I cannot remember them all"): trainees are overwhelmed by the "14 skills." Response: start from the six-step workflow, master the core flow before learning other skills; provide decision trees and quick-reference cards; emphasize "you do not need to master everything; learn on demand."
• Trainees fall back to old habits (a week after training, they are back to "let AI write code directly"): this is the most common and the hardest problem to solve. Response: check whether the six-step workflow was followed during code review; build a peer-monitoring mechanism (paired checks); managers lead by example and follow the standards themselves.

35.4 Building the Team's "Second Brain": From Standards to a Knowledge Base

A team's collective intelligence, if it lives only inside each member's head, will keep leaking away as people come and go. The "Second Brain" is the final resting place for all of a team's consensus, decisions, and wisdom -- the team's knowledge base in the digital world. It does not forget, it does not produce ambiguity, and it does not get lost to staff turnover.

The evolution path from standards to a knowledge base:

1. Step one: standardize documentation -- write the team's agreements (collaboration norms, coding standards, AI-assisted coding standards) into explicit documents (this is the output of the "standardization phase" in the four-phase rollout);
2. Step two: crystallize decisions -- deposit important decisions, solution comparisons, and lessons from failures into the knowledge base as entries, instead of leaving them stranded in meeting minutes and chat records;
3. Step three: structure the knowledge -- organize knowledge in a way the team can search (by domain, by scenario, by tag); build a FAQ, a best-practice library, and a troubleshooting manual.

"Living documents": why do your standards need timestamps? A standards document is not a law carved in stone -- standards are "alive" and must keep evolving with the team's practice. A timestamp ("updated 2026-08-29") lets readers understand how current a standard is, so that a standard made obsolete three years ago is not treated as gospel.

35.5 One-Off Course → Standing Cadence: Keep the Knowledge Loop Running Past Graduation Day

Section 35.3 already provides post-training follow-up; this section connects those checkpoints into a lasting mechanism. If behavior improves after one month but old habits return after a quarter, examine the cadence of continued practice and feedback alongside training quality and workload. The frequencies, durations, and operating rules below are teaching suggestions from this textbook; teams should adapt them to available material and actual workload.

This section provides three standing mechanisms. Chapter 29 covers the FDE's personal duties in the knowledge outer loop -- why to throw field findings into Field Notes, why to take turns giving shares. This section covers how a manager institutionalizes those same behaviors: same mechanism, Chapter 29 gives the why, this section gives the how.

Mechanism 1: bootcamp-style training camp -- cadence and content. The first shift from "one-off" to "standing" is to add a fixed-cadence advanced camp on top of onboarding training. Three points:

• Cadence: quarterly as the default; teams with a large headcount and dense project flow can tighten to every six weeks -- the cadence adjusts with team size and project rhythm, and what matters is "a fixed cadence", not "the denser the better";
• Content source: not a rerun of the textbook, but material drawn from the assets accumulated in the optimization phase of Chapter 34 -- high-frequency fragments from the Field Notes channel, failure cases from recent project retrospectives, validated new tools and practices. The knowledge base of 35.4 is the bootcamp's raw-material store, and the bootcamp is the knowledge base's "publishing mechanism";
• Format: half a day to a full day, dominated by hands-on work and case retrospectives rather than lecturing. The 1:1 listen-to-do principle (Section 35.2) applies equally to the bootcamp -- and since trainees already have battle experience, the hands-on share should be even higher.

Mechanism 2: biweekly sharing -- an operating template. Alongside daily Field Notes, biweekly sharing creates a regular opportunity for group discussion. A minimal configuration:

Mechanism 3: connecting to the post-training follow-up cadence. The first week's independent-practice output in 35.3 enters the appropriately restricted Field Notes space once sharing authorization is confirmed. The first month's sharing session joins the biweekly roster; the first quarter's skill-maturity assessment informs the next bootcamp's topics. This reuses existing material and schedules, but managers must still allocate preparation, maintenance, and follow-up time.

Standing mechanisms need a clear owner, which can rotate, to manage the roster, request topics, and archive records. As Chapter 29 explains, individual FDEs provide evidence authorized for sharing, try building blocks, and report results; organizers own access, time, topic selection, and follow-up tasks rather than implicitly assigning maintenance to presenters. Each bootcamp should require trainees to independently reproduce a failure, try a building block, and submit a conclusion with applicability limits. The owner routes failures to the asset maintainer and checks next time whether the asset was revised or withdrawn.

35.6 Regular Retrospectives and Iterating Collaboration Practices

A methodology is not "designed once and done" -- it is "gradually refined through continuous use." Regular retrospectives and iteration are the mechanism that keeps a collaboration style advanced.

Three levels of retrospectives:

1. Project retrospective (whenever a project or iteration ends): what was the experience of using AI-assisted coding on this project? Where was it smooth and where did it get stuck? How should the process be adjusted?
2. Collaboration retrospective (monthly): which links in the team's collaboration style are getting "clogged"? Which kanban column keeps piling up? Where does information get lost?
3. Methodology retrospective (quarterly): is the current methodology (blueprint template, acceptance checklist, prompt corpus) still applicable? After AI tools evolve, are there better approaches?

Embrace change: AI coding tools evolve extremely fast -- new features, new models, and new best practices keep emerging. A team that clings to "last year's best practices" will fall behind within six months. Make "embracing change" the default setting of your collaboration style: spend about 10% of your time regularly exploring new tools and methods, and deposit validated new practices into the knowledge base and the standards.

Finally, remember that the "collaboration standards" themselves should also be a "living document" -- they can even have their own "meta-standards": every standard must be "conditional" rather than "absolute" (a standard may be broken for a sound reason; when it is broken, record the reason and evaluate whether the standard should be revised); encourage "constructive destruction" grounded in first principles; provide a safe test bed for "breaking standards" (experiment with new methods on a small scale, and only promote them broadly once validated). The best standards are the standards that keep getting broken -- provided that every break pushes the standard to be better.

Part Eleven complete. You have now mastered the full roadmap for rolling the AI-assisted coding methodology into a team (pilot phase → standardization phase → scaling phase → optimization phase, with each stage's goals, practices, and acceptance criteria), the team training plan (tiered training, the 1:1 listen-to-do ratio, post-training follow-up, four-level effectiveness evaluation, and the progression from one-off course to standing cadence), and the continuous evolution mechanisms (Second Brain knowledge base, living documents, regular retrospectives).

Now, let us move to the final part of this textbook: hands-on cases and comprehensive drills. There, you will see the methodology play out end to end across four realistic exercise scenarios (pedagogically recomposed cases), and complete your graduation comprehensive drill.