祝融说。

In the previous chapter, we established a grand "three-step" workflow, a precision production line that ensures complex requirements are developed with careful planning before action. Now we must assign the most fitting "expert" to every "workstation" on this production line.

Imagine what it would be like if your entire software development team -- from architect to test engineer to security expert -- were the same person. That person might be very intelligent, but their knowledge, thinking patterns, and points of focus would inevitably have limits.

In its default state, AI is exactly such a "generalist." It knows a little about everything but is not deeply proficient in any one domain. When you ask it a question about database performance, its answer may be mixed with frontend knowledge. When you ask it to review code for security, it may care more about code style.

"Role locking" is the "silver bullet" that solves this problem. Through a simple, explicit instruction, it forces AI to flip in an instant from a "know-it-all" into an "expert" in a particular domain. This is like putting a specially made "thinking hat" on AI. Under that hat, the very way it thinks about and responds to the world is fundamentally transformed.

This is not mysticism. It rests on underlying logic worth examining. That said, existing research (e.g., Zheng et al.'s systematic test of 162 personas, "When 'A Helpful Assistant' Is Not Really Helpful") shows that role prompts do not reliably improve accuracy on objective tasks and can even hurt it; their stable gains lie mainly in consistency of terminology, perspective, focus, and tone -- which is precisely what collaboration scenarios need most. A well-designed role prompt remains one of the higher-leverage tools you can bring to bear on AI.

In this chapter, we will explore the essence of "role locking" in depth, provide you with a plug-and-play "expert role library," and teach you how -- like an experienced director -- to switch AI seamlessly between different roles in a complex development process, so that it offers your project comprehensive, expert-level support.

8.1 The Essence of Role Prompts: Activating the Model's Domain-Specific Weights

To truly master the power of "role locking," we cannot stop at copying examples by rote. We need to understand why a simple "Act as a..." produces such a remarkable effect. Behind it lies a fascinating facet of how large language models work.

An LLM Is Not "One Brain" but a Superposition of "Countless Brains"

We can picture a large model such as GPT-4 or Claude 3 as a "probability cloud" stored inside a supercomputer, one that holds nearly all the textual knowledge on the internet. The picture of "high-density regions" below is a heuristic analogy for the model's internal behavior, not a strict circuit-level description.

• There is a region concentrating all the knowledge about "database tuning" learned from Stack Overflow, technical blogs, and GitHub issues. The language style, terminology, and manner of thinking in this region share the unmistakable traits of a DBA.
• Another region is filled with knowledge drawn from OWASP, security forums, and vulnerability reports. This region is steeped in terms like "cross-site scripting," "SQL injection," and "zero-day vulnerabilities," and its thinking always starts from "how can this be breached."
• Yet another region has absorbed all the papers and articles on user experience (UX), design systems, and human-computer interaction. The language in this region is softer and more inclined toward the user's point of view.

In the default state, when you ask AI a question, it searches the entire "probability cloud" without discrimination and returns the most "average," most "generic" answer it can. That answer is like a "mixture" of the views of a DBA, a security expert, and a UX designer stirred together -- well-rounded, yet lacking insight.

"Role Prompts": A Searchlight That Illuminates a Specific Knowledge Region

A "role prompt" works like a high-energy "searchlight." When you enter:

"Act as a Senior Database Administrator with 20 years of experience optimizing high-traffic PostgreSQL databases."

This prompt, like a precise "coordinate," instantly sweeps the searchlight toward that "high-density region" where DBA knowledge resides. When the model generates its subsequent response, it dramatically raises the weight of knowledge within this specific region while suppressing the weight of other unrelated regions (such as frontend or UX design).

This dynamic re-weighting sets off a series of remarkable reactions:

1. Precisely targeted terminology: AI begins to use the most specialized vocabulary of that field. It no longer says "make the query faster" but rather "we need to analyze the output of EXPLAIN ANALYZE, check for any 'full table scans,' and consider creating a B-Tree index on the high-cardinality field in the WHERE clause."
2. A shift in mode of thought: AI's "reasoning" angle changes at its root. Ask it how to design a user table, and a "generic AI" may think about what fields are needed; a "DBA-AI," by contrast, first asks you: "What is the expected read-to-write ratio for this table? What are the dominant query patterns? What is the projected rate of data growth?" -- because its brain has already been switched into "performance and scalability first" mode.
3. Focused attention: AI proactively ignores information irrelevant to the current role, displaying a stronger "professional focus." A "Security Consultant-AI," when reviewing your login code, will fixate on "Is the password hash salted?" and "Can it withstand timing attacks?" while caring not at all whether your CSS is well styled.
4. Shifts in confidence and tone: An AI granted the role of "senior expert" often answers in a more decisive, assured tone, uses fewer hedging words like "maybe" or "perhaps," and tends toward clear, actionable recommendations. (Note: a confident tone is not evidence of correctness -- do not let decisiveness sway your review.)

The essence of role locking is not "teaching" AI new knowledge, but steering the relevant knowledge and expression patterns already present in the model's weights toward the task at hand. It is an efficient "context compression" technique. In a single sentence, it clears away a vast amount of irrelevant context for AI, letting it direct its computational resources onto the dimension of knowledge that the task actually requires.

Once you understand this, you see that the key to designing a good role prompt is "precision."

• A poor role: "Be a programmer." (Too broad, almost no focusing effect.)
• A good role: "Act as a Go backend developer." (Better; locks in the language.)
• An excellent role: "Act as a Senior Go backend developer specializing in building high-concurrency microservices with gRPC." (Extremely precise; activates the weights of multiple knowledge regions -- Go, backend, high concurrency, microservices, gRPC -- with outstanding effect.)

The more detail you inject into a role, the smaller and brighter the searchlight's beam grows, and the more professional and striking AI's performance becomes.

8.2 A Common Role Library: Architect, Performance Expert, QA Auditor, Security Consultant

Across the software development lifecycle, we need experts from different domains to step in at different stages. Below, I have assembled an "AI Expert Consultant Team" role library for you. You can keep it on hand and "summon" the right expert at any time.

Each role includes its "core responsibilities" and a carefully crafted, ready-to-use "summoning incantation" (prompt template).

1. Chief Architect

• When to summon: At the very earliest stage of a project, or when major technical decisions or refactoring are required. In our "three-step" workflow, it operates mainly in the "planning" phase.
• Core responsibilities:
• Carry out high-level technology selection and design.
• Evaluate the trade-offs among different architectural approaches.
• Focus on long-term maintainability, scalability, and robustness.
• Produce and interpret architecture diagrams.
• Summoning incantation:

Act as a Chief Architect. You are responsible for the high-level design of our system. Your primary concerns are long-term maintainability, scalability, and robustness. When I present a problem, I need you to think in terms of systems, modules, interfaces, and trade-offs. You should be able to propose multiple solutions and compare them objectively. Avoid getting bogged down in implementation details unless I ask.

2. Performance & Reliability Engineer

• When to summon: When you hit a performance bottleneck, need to run load tests, or are designing a high-availability solution.
• Core responsibilities:
• Identify performance bottlenecks in the code (CPU, memory, I/O).
• Be fluent in database query optimization and caching strategies.
• Design stress-testing plans and monitoring metrics.
• Focus on fault tolerance and failure recovery.
• Summoning incantation:

Act as a Staff-level Performance and Reliability Engineer. Your entire world revolves around latency, throughput, resource utilization, and fault tolerance. When you review my code or designs, your #1 priority is to hunt down potential bottlenecks, race conditions, and single points of failure. You should be fluent in concepts like caching strategies (e.g., read-through, write-behind), database indexing, load balancing, and asynchronous processing. Provide concrete, quantifiable optimization suggestions.

3. QA Auditor

• When to summon: When you need to design a test strategy, write test cases, or review the testability of code.
• Core responsibilities:
• Think from the standpoint of a "picky user" and a "breaker."
• Design comprehensive test cases, especially for edge cases and exceptional conditions.
• Assess code testability (e.g., whether modules are decoupled, whether dependencies are easy to mock).
• Advocate Test-Driven Development (TDD) and Behavior-Driven Development (BDD).
• Summoning incantation:

Act as a meticulous QA Auditor. Your job is to break my code. You have a deeply pessimistic and adversarial mindset. When I give you a function or a component, I need you to generate a comprehensive list of test cases, especially focusing on edge cases, invalid inputs, error conditions, and potential security vulnerabilities. You should also critique the code's testability and suggest changes to make it easier to test.

4. Security Consultant

• When to summon: Whenever you are dealing with any code involving user input, authentication, authorization, or data storage, you should "summon" one.
• Core responsibilities:
• Review code with a "hacker's" mindset.
• Identify common vulnerabilities such as SQL injection, XSS, CSRF, and the like.
• Focus on sensitive operations such as password storage, session management, and data encryption.
• Ensure adherence to the principle of "least privilege."
• Summoning incantation:

Act as a paranoid Security Consultant. You are an ethical hacker, and your mission is to find every potential vulnerability in my code before a real attacker does. When reviewing code, you must check for the OWASP Top 10 vulnerabilities. Your analysis should cover input validation, output encoding, authentication, authorization, session management, and data protection. For every vulnerability you find, you must explain the potential attack vector and provide a concrete code example for the fix.

5. UX Designer

• When to summon: When designing frontend UI components or user interaction flows.
• Core responsibilities:
• Examine the product from the user's perspective.
• Focus on usability, accessibility, and information architecture.
• Ensure the consistency and intuitiveness of the UI.
• Offer user-centered feedback and suggestions.
• Summoning incantation:

Act as a pragmatic UX Designer. You are the advocate for the end-user. Your focus is on simplicity, clarity, and accessibility. When I show you a UI design or a user flow, I need you to critique it from a user's perspective. Is it intuitive? Is the cognitive load too high? Does it follow established interaction patterns? Are there any accessibility issues (e.g., for screen reader users)? Provide actionable suggestions to improve the user experience.

6. Technical Writer

• When to summon: When you need to comment your code, document an API, or write a project README.
• Core responsibilities:
• Produce clear, concise, unambiguous technical documentation.
• Excel at explaining complex concepts.
• Keep the documentation's structure and formatting consistent.
• Summoning incantation:

Act as a professional Technical Writer. Your goal is to make my code and documentation understandable to other developers, including my future self. Take the following code snippet and write a clear, concise docstring/comment for it. Explain the "why" behind the code, not just the "what". Ensure the documentation format is clean and follows standard conventions like JSDoc or GoDoc.

This "expert library" is far from exhaustive. You can invent many more, highly specific roles to suit your needs -- a "DevOps Engineer," a "Data Scientist," a "Legal Counsel (to review open-source licenses)," and so on.

The key is to cultivate a habit of "reviewing from multiple angles." When you consider a piece of code "done," pause for five minutes and "summon" the QA Auditor and the Security Consultant in turn, asking each to scrutinize your code once more from their own professional angle, like two lines of crossfire. You will be astonished at how defects lurking in your blind spots immediately come to light.

8.3 Switching Roles Seamlessly in the Same Session Without Causing Confusion

In a complex development process, we often need several "experts" to work in tandem. For example, when building a login form, we might first need a "UX Designer" to plan the layout, then a "programmer" (the default role) to write the code, and finally a "Security Consultant" and a "QA Auditor" to review it.

If every role switch meant clearing the session and rebuilding it, as in Chapter Six, the cost would be prohibitive. We need a lighter, smoother mechanism for switching roles.

The secret lies in managing AI's "center of attention" through clear "scene transitions" and "explicit instructions," so that roles never become confused.

Three Key Techniques for Switching Roles

1. Use "scene separators"

Before switching roles, use a Markdown horizontal rule (---) or a prominent heading to tell AI, both visually and semantically: "The previous scene is over. We are entering a new one."

2. Give explicit "role release" and "role assignment" instructions

Do not assume AI will automatically forget its previous role. Before assigning a new role, it is best to "release" the old one explicitly in a sentence.

3. "Package" the context and pass it along

When switching roles, tell the new role clearly what "input" it needs to attend to. Usually, that input is the previous role's "output."

A Worked Example: A Multi-Role Collaboration Flow for Building a Login Form

Let us look at a complete example.

(Session begins)

You (as Project Manager): We need to build a login form.

(Phase One: Summon the UX Designer)

You:

Scene 1: UX Design

Act as a UX Designer. Your task is to design the user flow and component breakdown for a login form. Focus on simplicity and error handling. Please provide your output as a list of UI components and user interaction steps.

AI (in UX Designer mode): Understood. As a UX Designer, here is my proposed design:

Components:

1. EmailInput
2. PasswordInput (with show/hide toggle)
3. SubmitButton
4. ErrorMessageDisplay
5. ForgotPasswordLink

User Flow:

1. User enters email and password.
2. SubmitButton is disabled until both fields are non-empty.
3. On submit, button shows a loading spinner.
4. On success, redirect to dashboard.
5. On failure (e.g., wrong password), ErrorMessageDisplay shows a clear, non-technical error message. PasswordInput is cleared and focused.

(Phase Two: Switch to the Programmer and Execute the Design)

You: Great design. I approve it.

Scene 2: Implementation

You are now a Senior React/TypeScript developer. Your task is to implement the login form based on the UX design from Scene 1.

Input: The component list and user flow provided above. Action: Please write the code for the main LoginForm component.

AI (in Programmer mode): Got it. Switching to React developer mode. Here is the implementation of the LoginForm component, following the UX specifications.

// ... (generates the React code)

(Phase Three: Switch to the Security Consultant and Audit the Code)

You: The code looks functional.

Scene 3: Security Audit

You are now a paranoid Security Consultant. Your previous context as a developer is irrelevant. Your ONLY focus is security.

Input: The React code for LoginForm generated in Scene 2. Action: Audit this code for any potential security vulnerabilities. Create a list of findings with severity and recommended fixes.

AI (in Security Consultant mode): Understood. Commencing security audit. My developer hat is off.

Security Findings:

• Severity: High
• Finding: The form submits data over plain HTTP in the fetch call. This is vulnerable to man-in-the-middle attacks.
• Recommendation: MUST use HTTPS for the API endpoint.
• Severity: Medium
• Finding: Error messages are too specific ("Invalid password" vs. "User not found"). This allows for user enumeration attacks.
• Recommendation: Use a generic error message like "Invalid email or password" for both cases.
• ... (other findings)

Do you see it? With this combination of ---, Scene X, Act as a..., Input:..., and Action:..., we conduct different "players" (AI roles) the way a conductor leads an orchestra, each performing its own part at the right moment, until they blend into a coherent, high-quality whole -- with no confusion whatsoever.

This is a lightweight yet remarkably powerful method of "session flow control." It lets you subject your working output to a multi-dimensional, multi-faceted, expert-level scrutiny within a single context.

[Ready to Use] 10 Proven High-Performance Role Instructions

To help you put the power of "role locking" to work immediately, here are ten high-performance role instructions that have been battle-tested and cover the entire development process. You can save them in a text snippet tool (such as Alfred or Raycast) and call them up at will.

1. The "Architect" When Starting a Project

Act as a Chief Architect. We are starting a new project. I will describe the business goals, and you will help me decide on the technology stack, architecture pattern (e.g., monolith vs. microservices), and high-level module breakdown. Focus on long-term trade-offs.

2. The "Business Analyst" During Requirements Analysis

Act as a Senior Business Analyst. I will give you a raw user story. Your job is to break it down, identify ambiguities, and generate a list of clarifying questions for the product owner. Do not write any code.

3. The "Senior Debugging Expert" When Solving a Bug

Act as a grizzled Senior Debugging Expert (like Dr. House for code). I'm facing a weird, intermittent bug. I will provide you with the symptoms, error logs, and relevant code. You will ask me a series of sharp, diagnostic questions to help me narrow down the root cause. Propose logging strategies and experiments to isolate the problem.

4. The "Code Cleanliness Engineer" During Refactoring

Act as a "Code Linter" with an obsession for the SOLID principles and clean code. I will provide you with a piece of legacy code. Your task is to critique it, identify "code smells" (e.g., long methods, high coupling), and suggest specific refactoring patterns (e.g., "Extract Method", "Introduce Parameter Object") to improve its structure and readability.

5. The "Git Expert" When Writing Commit Messages

Act as an expert on Conventional Commits. I will give you a git diff of my changes. You will write a perfect, concise, and conventional commit message for me, including the correct type (feat, fix, chore, etc.), scope, and a descriptive body.

6. The "Mentor" When Learning a New Technology

Act as a patient and knowledgeable Tech Tutor. I am trying to learn [e.g., Rust's ownership model]. Explain this concept to me using the Feynman Technique: use simple analogies, avoid jargon where possible, and then test my understanding by asking me to explain it back to you or solve a small problem.

7. The "API Design Master" During API Design

Act as a seasoned API designer, a firm believer in the Richardson Maturity Model. I will describe the resources and actions for a new API. You will design the RESTful endpoints, choose the correct HTTP verbs, define the request/response JSON structures, and specify the appropriate HTTP status codes for all scenarios.

8. The "DBA" During Database Design

Act as a veteran Database Administrator. I will describe my application's data entities and their relationships. You will design the normalized SQL schema, choose the correct data types and constraints, and identify the necessary indexes to ensure query performance.

9. The "Accessibility Specialist" When Reviewing Frontend Components

Act as a Web Accessibility (a11y) Specialist. I will provide you with a React component's code. You must audit it for WCAG 2.1 AA compliance. Check for things like proper ARIA attributes, keyboard navigability, color contrast, and semantic HTML.

10. The "Rubber Duck" When You Are Stuck

Act as my "Rubber Duck". I'm stuck on a problem and need to talk it through. I will explain my problem to you step-by-step. Your role is not to give me the answer directly. Instead, listen carefully, and ask me probing questions that force me to clarify my own thinking, like "What have you tried so far?" or "What do you think is happening at line 52?".

Master these roles and use them flexibly, and your collaboration with AI will rise from a simple "Q&A" dialogue to a "roundtable discussion" that you direct, one gathering the finest minds of the entire industry. You are no longer a solitary developer. You now command a versatile virtual team whose "thinking caps" you can swap at will.