# EvoX Intelligent Evolution System and AI Native Research Practice Course Lecture Notes

Class Hours: 1 · Courseware Pages: 16

## Reading Navigation

- [Lesson 7 | Topic: AI Native Research Paradigm and EvoX Practical Entry Point](#lecture-lesson-1)

---

<a id="lecture-lesson-1"></a>

## Lesson 7 | Topic: AI Native Research Paradigm and EvoX Practical Entry Point

<a id="lecture-page-1"></a>

### AI Native Research Paradigm and EvoX Practical Entry Point

*Page 1*

> **Page Objective:** Master the practical path for entering EvoX in an AI Native environment, and appreciate the core research principle: "Code is cheap. Taste matters."

> **Page Objective**
>
> This is the opening page of Lesson 7, setting the tone for the entire unit "AI Native Research Paradigm and EvoX in Practice." Learners need to establish two understandings: first, the practical path for efficiently conducting EvoX experiments with the help of AI tools like Codex in an AI Native environment; second, when code can be automatically generated, the truly irreplaceable abilities of a researcher—taste and the ability to ask key questions—which is the phrase repeatedly emphasized on this page: Code is cheap. Taste matters.

> **Lecture Sequence**
>
> 1. Start with the scenario. Explain that under the AI Native way of working, "manual labor" such as writing experiment scripts, building EvoX optimization pipelines, and running comparative experiments can be largely handled by AI tools, and researchers no longer need to write line by line. This directly changes the rhythm of doing research: from "can I write it" to "is it worth doing."
>
> 2. Then move to the method. When using tools like Codex to conduct EvoX experiments, the typical approach is to clearly state your experimental intent, problem setup, and evaluation criteria, let the tool generate a runnable program skeleton, and the researcher focuses on checking whether the experimental design holds and whether the results are credible.
>
> 3. Finally, highlight the core principle. Since code has become cheap, what is scarce becomes judgment: whether the topic is valuable, whether the baseline is fair, whether the metrics are meaningful, and whether the conclusions hold. Taste determines the research direction, and the ability to ask questions determines the research depth.

**Key Teaching Points**

- AI tools reduce implementation cost, not the research threshold
- The threshold has shifted from "programming proficiency" to "problem taste." When using tools like Codex, the human role is to pose good questions, set evaluation criteria, and scrutinize generated results, rather than passively accepting output. "Code is cheap. Taste matters." does not negate engineering ability; it reminds us that in the era of automated programming, taste and the ability to ask questions are the researcher's true moat.

**Comprehension Check**

Ask a learner to explain in their own words where a researcher's time should be redirected in EvoX experiments if code can be automatically generated. A qualified answer should point to judgment-oriented work such as problem selection, experimental design, and result evaluation, not just "letting AI write faster."

> **Transition Hint**
>
> After confirming that learners can articulate the core relationship of "implementation cost decreases, judgment value increases," proceed to subsequent pages to unfold specific EvoX practical steps and examples.

<a id="lecture-page-2"></a>

### AI Native Research Paradigm and EvoX Practical Entry Point

*Page 2*

> **Page Objective:** Understand the overall path and core research principles for entering EvoX in an AI Native environment.

> **Page Objective**
>
> Connect "AI Native research paradigm" and "EvoX practical entry point" into a single path—when implementation cost decreases, researchers should shift attention from writing code to posing questions, defining evaluation, judging direction, and critiquing results, and remember the core principle "Code is cheap. Taste matters."

> **Lecture Sequence**
>
> First explain the paradigm shift, then read the architecture diagram, then explain that EvoX is not a single-algorithm tool but a runnable, composable, continuously explorable intelligent evolution system; finally land on the practical entry point: shifting from "choosing an algorithm" to "designing the process."

**Key Teaching Points**

- Large models, GPUs, Agents, and automated workflows have become default research infrastructure. Implementation code, batch experiments, and expanded search are becoming increasingly cheap
- AI is responsible for implementing answers, accelerating experiments, and expanding search
- Humans are responsible for direction, constraints, taste, and key decisions. Human attention moves up from "typing code" to "setting standards, making trade-offs, and examining results." Starting from "real problems · research taste," humans pose questions, set standards, and judge direction
- After being transformed into executable exploration, it is carried by AI infrastructure and then handed to EvoX. EvoX has four internal stages: problem definition (objective conflicts, constraints), evaluation design (metrics, weights, thresholds), evolution process (candidate solutions, batch iteration), and Runtime scheduling (compute, concurrency, reproducibility). It outputs multiple candidate solutions, verifiable results, and continuous evolution, forming criticizable and reproducible research output, and returns to the starting point through a "critique and acceptance" feedback loop. Inheriting the lineage of evolutionary computation, it is oriented toward complex multi-objective, open exploration, and system-level continuous evolution. It is not a single solver but a runnable, composable, continuously explorable engineering foundation: the products of one experiment can be inherited by the next, and the search process itself can continuously evolve. The four handles remain problem definition, evaluation design, evolution process, and Runtime scheduling. A typical misconception is treating the entry point as "picking one among several algorithms." The correct starting point is to first identify objective conflicts and constraints, and transform the problem into an executable, comparable, and continuously evolvable exploration process. Humans first define objective conflicts, constraints, and acceptance criteria
- AI rapidly generates and iterates code
- EvoX runs in batches and compares candidate solutions
- Ultimately forming criticizable and verifiable results. For example, in multi-objective optimization experiments, one should not let AI ghostwrite all the code and then directly trust the output; instead, machines should handle implementation and exploration, and humans should handle definition and judgment. Code is cheap. Taste matters. When code is no longer scarce, problem taste, evaluation criteria, trade-off judgment, and acceptance ability are the research competitiveness that is harder to replace.

**Exercise Handling**

This page includes 5 multiple-choice questions. The correct option for Question 1 is "shifting from writing code implementation to posing questions, defining evaluation criteria, and judging direction"; feedback point: implementation and batch exploration can be delegated to AI, and the human core responsibility is to pose questions, define standards, and judge results. The correct option for Question 2 is "a runnable, composable, continuously explorable intelligent evolution system and engineering foundation"; if wrong, remind students not to reduce EvoX to some algorithm. The correct option for Question 3 is "first identify objective conflicts and constraints, and transform the problem into an executable exploration process"; emphasize that the entry point is not algorithm selection or parameter setting. The correct option for Question 4 is "when code is no longer scarce, problem taste, evaluation criteria, and acceptance judgment become scarcer abilities";

It does not negate implementation and verification, but emphasizes the shift in scarcity. The correct option for Question 5 is "letting AI ghostwrite all the code and then directly adopting its running results without manually defining objectives and standards"; this conflicts with the division of labor in which "AI implements and explores, humans define and judge."

Design a multi-objective optimization experiment using EvoX. The scenario requires simultaneously optimizing cost, performance, and robustness, with the three metrics conflicting with one another and constrained by compute budget and delivery cycle. The human-machine division of labor should be written as: humans are responsible for definition and judgment—posing questions, explicitly writing objective conflicts and constraints, designing evaluation metrics and acceptance thresholds, and making directional judgments and critical acceptance in the face of results; AI is responsible for implementation and exploration—rapidly generating and iterating code, running candidate solutions in batches, expanding search, and accelerating experiments. The two form a closed loop of "humans set direction—AI expands exploration—humans perform acceptance."

If objective conflicts are not explicitly defined, evaluation criteria are vague, and constraints are ignored, it becomes difficult to judge which results are better, reproduce them, or accumulate them; one should instead focus on process design, clarify problem definition and evaluation methods, plan candidate solution generation, batch run comparison, and Runtime scheduling, and incorporate each round of results into critique and acceptance.

**Classroom Activity**

Ask students to choose a familiar problem, write the objective conflict and acceptance criteria in one sentence, and then explain which part is handled by AI and which by EvoX. Comprehension check: randomly ask students to restate "why define evaluation first, then touch code," and point out the role of the feedback loop in the architecture diagram. Transition hint: after confirming that students can distinguish cheap capabilities from scarce capabilities, proceed to the next page's example problems, applications, or summary.

<a id="lecture-page-3"></a>

### Large Model Capability Boundaries and Continuously Evolving Systems

*Page 3*

> **Page Objective:** Understand the gap between the growth of large model capabilities and building systems that adapt to the real world over the long term.

**Key Teaching Points**

- When you see claims like "model capability improvement," ask two follow-up questions: where do this round's <em>effective results</em> accumulate? Who inherits them in the next round? If you cannot answer, then only single-call capability has improved, not the system's long-term adaptive capacity.
- First produce candidates → then verify against reality → accumulate into the repository → inherit and evolve again. The order cannot be changed: without candidates there is nothing to test, without testing there is no accumulation, and without accumulation there is no inheritable starting point.
- Two common misunderstandings: treating "good performance on a single task" as "the system can adapt over the long term"; and treating "unverified candidates" as "existing conclusions." The self-check method is to see whether this result has crossed real verification and whether it has been written into an inheritable project version.

Page Objective**

A large model's "capability growth" and a system's "long-term adaptation" are not the same thing. Learners need to understand why making model capabilities stronger does not automatically mean the project can continue to evolve in the real world, and what links a system-level closed loop should consist of.

Lecture Sequence**

It is recommended to proceed in the order of "capability components → why they are not enough → four-step closed loop → relationship between components and the system → misconception self-check." First explain clearly what large models can do, then create a cognitive gap (single-run strength ≠ long-term stability), then provide the closed-loop structure as the solution, and finally close with the pair of concepts "component—system."

Key Teaching Points**

1. Three types of capabilities provided by large models. They can already reliably handle strong understanding, generation, and tool invocation: parsing goals and constraints into executable task descriptions; producing candidate hypotheses, code, experimental designs, and documents; and connecting external resources such as retrieval, computation, compilation, and simulation. Therefore, integrating large models into research and engineering processes as "intelligent components" is already a realistically usable practice. But it must be made clear: these three capabilities answer "can a single task be done correctly," not "can long-term tasks continue to be done correctly."

2. Why strong single-run capability is not enough. Real engineering projects often last months or even years, while a single Agent's context will eventually be exhausted. If experience cannot be accumulated, each round of work must start from zero, and capability growth will not automatically translate into long-term adaptive capability. This is a good point to propose: the object of evolution needs to be expanded into a persistently existing "software world," relying on project-level persistence so that experience is not lost with a single experiment.

Intelligent components propose hypotheses, modifications, or implementations; at this moment they are only candidates, not conclusions. Real verification: candidates must pass through real environments, simulations, or experiments, and cross gates such as compilation, testing, behavior checks, and upper-level acceptance. Result accumulation: only valid results that pass verification are written into the accepted project version and become reusable assets. Re-evolution: subsequent work inherits the accumulated results and continues to propose candidates on that basis. The mnemonic is "first produce candidates → then verify against reality → accumulate into the repository → inherit and evolve again." Emphasize the logical dependencies: without candidates there is nothing to test, without testing there is no accumulation, and without accumulation there is no inheritable starting point.

4. Use a multi-Agent collaborative system like Genesis as a closed-loop example. The lifecycle of Agents participating in the work is limited; upper-level executors understand goals and recursively decompose tasks, lower-level executors complete local implementation and testing, and continue recursing downward when necessary; candidate modifications are submitted only as candidates and must pass compilation, testing, behavior checks, and upper-level acceptance before being accepted; failed attempts are rejected, and verified results are written into the project version, becoming the historical basis for subsequent executors. In scenarios such as compiler refactoring and scientific software upgrades, this mechanism demonstrates high reliability and runtime speedup.

Capability components are responsible for producing high-quality candidates at a single point, while the system closed loop is responsible for determining which candidates are worth keeping, how they are kept, and how they are inherited by the next round. Without the closed loop, the stronger the capability, the more unverified candidates it will produce; without strong components, the closed loop lacks a source of high-quality candidates.

6. Common misconceptions and self-check methods. The most common misreading is equating "model capability improvement" directly with "the system can adapt over the long term." The criterion is not how well the model performs on some task, but whether effective results can be stably accumulated and inherited by the next round of work. Two follow-up questions can be taught to learners: where do this round's effective results accumulate? Who inherits them in the next round? If you cannot answer, only single-call capability has improved. Another misconception is treating "unverified candidates" as "existing conclusions"; the self-check method is to see whether they have crossed real verification and been written into an inheritable project version.

Material Clues**

On the left is the "large model capabilities" component area, listing understanding, generation, and tool invocation; on the right is the "continuously evolving system closed loop," formed by four nodes in a cycle: candidate generation, real verification, result accumulation, and re-evolution, with "capability components need to be organized by the system" marked in the middle. During explanation, you can lead students through the closed loop along the arrows, then point back to the left side to explain that components have long-term value only when organized by the system.

Exercise Clues and Answer Guidance**

The correct positioning of large models in the process (intelligent components that can be organized by the system, handling understanding, generation, and tool invocation); why capability growth does not equal long-term adaptation (a single session's context will be exhausted, and unverified results cannot accumulate into inheritable assets); the correct order of the closed-loop stages (candidate generation → real verification → result accumulation → re-evolution); the threshold for code entering project history in Genesis (passing compilation, testing, and behavior checks and being accepted at the upper level); and the accurate formulation of the "component—system" relationship.

The case question requires designing a system-level closed loop for a long-term scientific computing laboratory, and providing mechanisms for "failed solutions being repeatedly retried" and "new members unable to inherit early conclusions." Key answer points are: use strict acceptance gateways and decision records to reject unaccepted candidates and preserve reasons for failure, and use project-level persistence to write accepted results into the accepted project version; also point out that merely improving model capability can only raise the quality of a single candidate, while the root of these two problems lies in the lack of verification, recording, and accumulation.

Comprehension Check**

Why stronger models do not equal a project that can evolve over the long term, and what problem each of the four closed-loop steps solves. If the answer remains at "the model is very powerful," prompt them to return to the two follow-up questions "where do effective results accumulate, and who inherits them" to complete it.

Transition Hint**

After confirming that learners can distinguish "the quality of a single candidate" from "system-level screening, accumulation, and inheritance," proceed to the next page's applications, example problems, or hands-on practice.

<a id="lecture-page-4"></a>

### Transforming Real Problems into EvoX Exploration Processes

*Page 4*

> **Page Objective:** Master how to define variable objects, evaluation criteria, and retention mechanisms when facing real problems.

> **Page Objective**
>
> Master how to define variable objects, evaluation criteria, and retention mechanisms when facing real problems, and understand the order of "do problem transformation first, then talk about algorithm selection."

> **Lecture Sequence**
>
> Real problem (requirements describable) → variable object definition (variables samplable) → evaluation criteria construction (objectives computable) → retention and selection mechanism (candidates inheritable) → EvoX iterative exploration (each generation reproducible) → candidate solution output (conclusions measurable).
>
> When evaluation is distorted, fall back to evaluation criteria construction; when diversity collapses, fall back to the retention mechanism.
>
> 3. Then unfold the four acceptance conditions in order, and use supercritical airfoil design to explain the mapping method.
>
> 4. Finally, test understanding through five true/false questions and the battery pack cooling plate case.

**Key Teaching Points**

- Transforming a real problem into an EvoX exploration process means that before writing any algorithm configuration, first rewrite the vague engineering or research requirement into an evolutionary problem definition that is "samplable, evaluable, retainable, and iteratively verifiable." What EvoX takes on is an exploration pipeline; it needs to know in what space to sample, by what standard to score, and which results are worth continuing. This information can only come from the problem itself. Algorithms can only find answers within a definition and cannot recover the correct answer from a wrongly defined problem. Translate real-world requirements into decision variables, determine the representation, dimensions, and boundaries, and distinguish continuous parameters, discrete structures, and even program-level objects. Boundaries that are too narrow will exclude the true optimal solution from the search space
- Variables samplable. Decompose vague objectives into computable objective functions and constraints, clarifying maximization metrics, hard constraints, and multi-objective trade-offs. When feedback is sparse or simulation is expensive, introduce surrogate models to replace costly computation. Acceptance condition: objectives computable, and under the same input the results are stable and reproducible. Define how candidates are saved, compared, and continued, so that the evolutionary process has memory, direction, and diversity, rather than rounds of unrelated one-off trial and error. Acceptance condition: candidates inheritable. The transformation result must be reproducible, measurable, and iteratively verifiable, and each step must be able to answer "is this change truly better." Missing variables will misrepresent the solution space, and distorted evaluation will push the whole optimization off course
- Neither type of deviation can be compensated for by subsequent operators or more iterations. In supercritical airfoil design, the variable object is the geometric perturbation parameters of the baseline airfoil
- The evaluation criteria are multi-objective metrics such as lift-to-drag ratio, drag divergence, and robustness, with surrogate models used to control simulation cost
- The retention mechanism is to output a diverse set of candidate solutions balancing all metrics and hand it to domain experts for trade-off decisions. For the same real problem, simply changing the variable boundaries or evaluation criteria will completely change the exploration conclusions.

**Keyword Coverage**

- Problem transformation, variable object definition, variables samplable, evaluation criteria construction, objectives computable, retention and selection mechanism, candidates inheritable, EvoX iterative exploration, each generation reproducible, evaluation distortion, diversity collapse, surrogate models, supercritical airfoil.

**Exercise Handling**

The correct answer is "because the transformation determines the search space and evaluation criteria, and the algorithm can only find answers within this definition." When explaining, emphasize that the transformation answers "what can change" and "how to evaluate after the change," and that the upper limit of the exploration space and the optimization direction are both determined by it; sampling cost or operator type is not the key.

The correct answer is "the search space is too narrow, the true optimal solution is not in it, and subsequent operators and iterations cannot compensate." Missing variables is a deviation in the transformation stage, and evaluation functions, retention mechanisms, and operators will not create undefined dimensions out of thin air.

The correct answer is "use surrogate models for low-cost approximate evaluation while explicitly preserving the trade-off relationships among multiple objectives and hard constraints." When evaluation is expensive and objectives conflict, the correct approach is to reduce the cost of a single evaluation and explicitly express conflicts and constraints, rather than cutting the number of iterations or simply combining them with weights.

The correct answer is "allow candidates to be saved, compared, and continued, so that the evolutionary process has memory, direction, and diversity." The retention mechanism is not responsible for evaluation, nor for correcting variable boundaries.

The correct answer is "each step should be reproducible and able to answer 'is this change truly better,' otherwise deviations will be amplified during iteration." A final overall review cannot replace step-by-step verification; missing variables and evaluation distortion occur in the transformation stage, and iteration will only amplify the deviation.

When the answer is correct, affirm that the student can connect it to the concepts on this page and explain the basis; when the answer is wrong, ask the student to return to the corresponding paragraph, find the key evidence or example, and then judge again.

> **Exercise Clues**
>
> - Optimization of the channel geometry of a battery pack cooling plate. Using only channel width as the decision variable while ignoring discrete structural degrees of freedom such as channel routing, topology form, branch level count, and inlet/outlet positions belongs to too narrow a definition of the variable object, and the truly optimal geometry may not be in the search space
> - Using only maximum temperature as the sole objective and leaving pressure drop and temperature uniformity to empirical judgment belongs to distorted evaluation criteria, and multi-objective conflicts are not explicitly modeled
> - A single 3-hour simulation multiplied by 200 generations, lacking evaluation cost control and a reproducible verification criterion, and directly picking the individual that "looks best" from the results, cannot answer "is this change truly better." For variable objects, include continuous parameters (channel width, depth, wall thickness) together with discrete structures (channel topology, branch level count, inlet/outlet positions), specify the value ranges or encoding method, and distinguish fixed quantities; the verification condition is that variables are samplable. For evaluation criteria, write maximum temperature, pressure drop, and temperature uniformity as explicit multi-objective objective functions, write pressure drop upper limits and manufacturability as hard constraints, use surrogate models for most of the evaluation and periodically calibrate with real simulations; the verification conditions are that objectives are computable and stable and reproducible under the same input. For the retention mechanism, preserve a diverse set of candidates spanning objective trade-offs rather than a single optimal solution, define comparison rules and continuation rules, and monitor homogenization with diversity metrics; the verification condition is that candidates are inheritable. During runs and verification, record reproducible metrics generation by generation
> - If evaluation credibility decreases, fall back to evaluation criteria construction and recalibrate
> - If diversity collapses, fall back to the retention mechanism and adjust the screening and continuation strategy.

**Classroom Activity**

Ask students to use one sentence to rewrite "make this design better" into an exploration problem definition containing variable objects, evaluation criteria, and a retention mechanism, and then check each other's work to see whether it satisfies "samplable, computable, inheritable, reproducible."

**Comprehension Check**

Randomly ask a student to summarize the key points of this page in their own words, and the teacher supplements the omitted acceptance conditions and feedback loops based on the answer.

> **Transition Hint**
>
> After confirming that students can state "define first, then start the optimizer" and the two types of fallback mechanisms, proceed to the next page's example problems, applications, or summary.

<a id="lecture-page-5"></a>

### Multi-Objective Optimization and Multi-Solution Exploration

*Page 5*

> **Page Objective:** Recognize the complexity of multi-objective tension in the real world and the necessity of retaining a set of candidate solutions.

> **Page Objective**
>
> Recognize the complexity of multi-objective tension in the real world, understand why it is necessary to retain a set of candidate solutions, and master Pareto dominance, the Pareto front, the cost of scalarization, and the two-dimensional evaluation of convergence and diversity.

**Key Teaching Points**

- Is this really a multi-objective problem? The criterion is not "the number of objectives is greater than 1," but whether the objectives trade off against one another. Take supercritical airfoil design as an example: lift-to-drag ratio, structural strength, stall margin, and manufacturing/simulation cost constrain one another, and improving the lift-to-drag ratio often means structural loads and manufacturing costs rise simultaneously. If all objectives can be improved simultaneously without loss, the problem degenerates into a single-objective one, and multi-solution exploration is both unnecessary and a waste of compute. Opposite directions and mutual trade-offs are what constitute a true multi-objective problem. 2. Pareto Dominance and the Pareto Front Solution A dominates solution B if and only if A is no worse than B on all objectives (for every objective i, fᵢ(A) ≤ fᵢ(B)) and is strictly better on at least one objective (there exists j such that fⱼ(A) < fⱼ(B)). Any dominated solution has a replacement that is "at least as good and better somewhere," so it has no retention value. All solutions not dominated by any other solution constitute the Pareto front—solutions on the front do not dominate one another, and which is more suitable depends on preference, not on mathematics. 3. The Cost of Single-Objectiveization Scalarization methods such as weighted sum and ε-constraint compress a vector objective into a scalar, which is convenient in engineering but comes at a concrete cost: obscuring the trade-off structure—once weights are fixed, the shape of the front and the alternative directions become invisible, and decision-makers can only see one score. Weights must be given in advance—yet real preferences often cannot be formalized in advance and often become clear only gradually during review. Limited coverage—weighted sum usually can only reach individual touchpoints on the front, and some sections of a non-convex front are difficult to attain. Once later review changes the weights, the entire search must be rerun, which is exactly the opposite of "one exploration for multiple rounds of decision freedom." Convergence and Diversity Convergence (whether the solution set approaches the true front) and diversity (whether the solutions cover different sections of the front). The two often pull against each other: once selection pressure leans too heavily toward "better," the population collapses to a point or small segment of the front, appearing to converge quickly while losing trade-off information. Therefore, population diversity must be explicitly maintained, together with selection pressures such as crowding distance, decomposition, and indicator-driven methods (such as hypervolume). The Decision Position Shifts The optimizer is only responsible for producing a comparable candidate set, while final selection is completed by preferences or domain experts; the optimizer should not prematurely converge on behalf of decision-makers. The practical reason for retaining a differentiated candidate set is "hedging"—when preferences are unknown, change with context, or constraints will be revised during implementation, a diverse solution set is more valuable than a single "optimal solution." In terms of implementation interfaces, multi-objective problems should be defined as vector-valued evaluation functions (returning multiple objective values at once) and output as a set of candidate solutions, rather than scalar fitness with a single return value. The number of return values of the evaluation function determines the objective dimension, and the output structure determines whether diversity can be preserved.

> **Material Clues**
>
> - The page provides a two-dimensional Pareto front scatter plot, with the horizontal axis being Objective 1 structural mass (smaller is better) and the vertical axis being Objective 2 manufacturing cost (smaller is better). The figure marks non-dominated solutions, dominated solutions, the Pareto front, scalarization hit points, improvement directions, sparse regions, and dense regions. This figure can be used to intuitively explain dominance relations, front shape, and diversity, and to show that weighted sum usually can only hit individual points on the front.

> **Exercise Clues**
>
> - The page contains 5 single-choice questions and 1 case study. Question 1 tests the determination of Pareto dominance; the correct option is "Solution A dominates Solution B if and only if A is no worse than B on all objectives and is strictly better on at least one objective." When guiding, emphasize that both conditions must hold simultaneously; solutions that are better in some respects and worse in others do not dominate each other and will remain on the Pareto front together. Question 2 tests the basis for judging a multi-objective problem; the correct option is "the objectives point in opposite directions, and improving one necessarily comes at the cost of degrading another." When guiding, point out that conflict is the essence of multi-objective problems; the key is not the number of objectives but the trade-off conflict relationship. Question 3 tests judgment about scalarization methods; the correct option is "scalarization obscures the trade-off structure and requires weights to be given in advance, while real preferences often cannot be formalized in advance." When guiding, remind students of the two costs: obscuring the trade-off structure and requiring weights to be given in advance. Question 4 tests the relationship between convergence and diversity; the correct option is "the two often pull against each other, and excessive pursuit of convergence easily causes the population to collapse to individual sections of the front." You can ask in return: if all solutions crowd onto one point of the front, although it looks convergent, can decision-makers still make choices? Question 5 tests the division of labor between optimizer and decision-maker; the correct option is "the optimizer outputs a set of comparable non-dominated candidates, and final selection is left to preferences or domain experts." When guiding, explain that the decision position has shifted, and the value of multi-objective optimization lies precisely in retaining a candidate set. The case study centers on the multi-objective trade-offs of a supercritical airfoil. Question 1 requires explaining why it constitutes a true multi-objective problem, and the risk in the review stage of using a weighted total score to output a single "optimal airfoil." Key answer points: the objectives point in opposite directions and constrain one another, and cannot be improved simultaneously without loss
> - A weighted total score obscures the trade-off structure and requires weights to be given in advance; once the weights are adjusted, the search must be rerun, and the simulation budget is hard to bear. Question 2 requires explaining how to define the evaluation function and output structure, and how to select at the review site. Key answer points: change the evaluation function to vector-valued form, returning a quadruple (lift-to-drag ratio, structural mass, stall margin, manufacturing and simulation cost)
> - The output is a set of candidate solutions, that is, a set of mutually non-dominated Pareto front solutions
> - At the algorithm level, explicitly maintain diversity, with selection pressures such as crowding distance, decomposition, or hypervolume
> - At the review site, make trade-offs from the candidate set according to real preferences. When the answer is correct, affirm that the student can connect it to the concepts on this page and explain the basis
> - When the answer is wrong, ask the student to return to this page's explanation, find the key evidence or example, and then judge again.

**Classroom Activity**

Ask students to give an everyday example of multi-objective conflict (such as the trade-off among performance, price, and battery life when buying a phone), explain why there is no single optimal solution, and discuss the value of retaining a set of candidate solutions.

**Comprehension Check**

Randomly ask a student to summarize the key points of this page in their own words, and the teacher supplements omitted keywords such as Pareto dominance, Pareto front, convergence, diversity, population collapse, and vector-valued evaluation function.

> **Transition Hint**
>
> After confirming that students can state the essence of multi-objective problems (objective conflict) and the significance of the Pareto front and diversity, proceed to the next page's example problems, applications, or summary.

**Source Basis**

From the EvoClass draft, page 7-7.

<a id="lecture-page-6"></a>

### MetaDE: Using Evolutionary Algorithms to Improve Evolutionary Algorithms

*Page 6*

> **Page Objective:** Understand how to treat the method that generates candidate solutions itself as the object of evolution.

**Key Teaching Points**

- The inner layer answers "what is computed," and the outer layer answers "how to compute better." Only one signal is passed between the two layers—task performance, that is, fitness.
- Do not treat the solution obtained by the inner layer as the final output of MetaDE. The real output is a transferable algorithm configuration: the configuration remains effective on new instances of the same type, while a single solution is often already outdated.
- Close the lecture notes and ask yourself: one outer-layer evaluation is roughly equal to how many complete inner-layer runs? If you cannot answer, it means you have not yet grasped MetaDE's cost structure and why parallelism is necessary.

【Page Objective】

Understand how to treat the method that generates candidate solutions itself as the object of evolution, that is, MetaDE's bi-level optimization closed loop in which an evolutionary algorithm improves an evolutionary algorithm.

【Lecture Sequence】

Who chooses mutation strategy, crossover rate CR, scaling factor F, and population size NP in the first place?

The outer layer encodes configurations and evolves them, while the inner layer runs DE in parallel on real tasks and returns performance evaluations.

Move from "finding solutions" up to "finding methods that can find solutions."

Configuration issued → inner-layer solving → performance returned → outer-layer update; evaluation cost is high, and GPU parallelism is the key enabling condition.

5. Summarize the essence in one sentence and discuss common misconceptions, then conduct exercises and comprehension checks.

【Key Teaching Points】

The inner layer receives a specific set of DE configurations, runs a complete solve on a real task, produces candidate solutions, and returns comparable performance evaluations; the outer layer encodes DE configurations, hyperparameters, or strategy combinations as individuals, uses task performance as fitness, and updates the next generation of configurations through selection, recombination, and mutation.

Traditional DE outputs a solution vector; MetaDE outputs a set of algorithm configurations that can stably produce better solutions on this type of task. The search object rises from "answers" to "the machine that produces answers," so that the results of one outer-layer search can be transferred and reused on other instances of the same family.

The whole system is connected by one closed loop—the outer layer issues configurations → the inner layer executes solving → performance is returned → the outer layer updates the next generation of configurations accordingly. For an individual in the outer layer to obtain fitness, it must pay the cost of one complete inner-layer run (often multiple parallel runs), so evaluation cost management and parallel scheduling are core to system design. It is precisely because GPUs can run large numbers of inner-layer tasks simultaneously that this kind of "expensive-to-evaluate" meta-optimization becomes engineering-feasible.

The inner layer is responsible for "what is computed," and the outer layer is responsible for "how to compute better." The two layers share the same fitness signal—task performance—which is exactly why they can form a closed loop.

【Keyword Coverage】

Bi-level optimization, inner layer, outer layer, fitness, configuration issued, performance returned, GPU parallelism, evaluation cost, differential evolution configuration (mutation strategy, crossover rate CR, scaling factor F, population size NP).

【Exercise Clues】

The outer-layer evolution object is algorithm configurations; the inner-layer responsibility is to receive configurations, solve on real tasks, and return performance evaluations; the order of the information closed loop is configuration issued → inner-layer solving → performance returned → outer-layer update; compared with traditional DE, the goal shifts from finding the optimal solution for a single problem to finding algorithms and configurations that can better produce solutions; the main computational overhead comes from the fact that evaluating an outer-layer individual requires paying the cost of a complete inner-layer run, and GPU parallelism runs large numbers of inner-layer tasks simultaneously, making meta-optimization engineering-feasible.

When the answer is correct, affirm that the student can connect it to the concepts on this page and explain the basis; when the answer is wrong, prompt them to return to this page's explanation, find the key evidence or example, and then judge again.

Logistics route solver configuration MetaDE. The inner layer runs DE completely on real delivery tasks, obtains route solutions and average transportation cost, and returns them as comparable performance evaluations. The outer layer encodes DE configurations (such as [mutation strategy DE/best/1, CR = 0.7, F = 0.5, NP = 60]) as individuals, uses average transportation cost as fitness, performs selection, recombination, and mutation, and generates the next generation of configuration populations. When the GPU budget is limited, hierarchical evaluation (first coarse screening with a small number of representative tasks, then re-evaluating only the top configurations on the full task set) and batch parallel scheduling (packaging the inner-layer runs corresponding to all individuals in the same generation into batches and submitting them to the GPU) can be used to reduce evaluation cost or improve search efficiency;

You can also reduce the outer-layer population size or use surrogate models to approximately predict performance, but you must trade off between search diversity and estimation bias. The reasons all revolve around "outer-layer fitness depends on complete inner-layer runs" and "parallelism can amortize the waiting time of a single individual."

【Common Misconceptions】

Do not treat the solution obtained by the inner layer as the final output of MetaDE. The real output is a transferable algorithm configuration: the configuration remains effective on new instances of the same type, while a single solution is often already outdated.

【Comprehension Check】

One outer-layer evaluation is roughly equal to how many complete inner-layer runs? If you cannot answer, it means you have not yet grasped MetaDE's cost structure and why parallelism is necessary. You can also ask students to summarize the responsibilities of the inner and outer layers and the closed-loop order in their own words.

【Transition Hint】

After confirming that students can state "the inner layer answers 'what is computed,' the outer layer answers 'how to compute better,' and the two layers share the fitness signal of task performance," proceed to the next page's example problems, applications, or summary.

<a id="lecture-page-7"></a>

### AI Native Way of Working and Convenient Entry Points

*Page 7*

> **Page Objective:** Experience an AI-native workflow that does not require memorizing installation commands or complicated interfaces.

> **Page Objective**
>
> Understand the AI Native way of working and convenient entry points, shifting the starting point of using EvoX from memorizing installation commands and complicated interfaces to expressing experimental intent in natural language. After learning, students should be able to explain the meaning of "conversation as entry point" and distinguish the parts handled by AI tools and by researchers.

> **Lecture Sequence**
>
> First compare the traditional approach with the AI Native approach; then explain the complete process as "natural language intent → AI understanding and execution → EvoX experimental output"; finally use the warehouse robot obstacle-avoidance pathfinding case to demonstrate how to describe an experiment to AI using the trio of "objective—constraints—acceptance."

**Key Teaching Points**

- Use natural language to describe the task, constraints, and acceptance goals, and AI is responsible for understanding the code and executing it. No need to master installation commands, dependency configuration, and complicated interface calls in advance. Framework installation, runtime configuration, and algorithm selection or generation can all be assisted by AI. Conversation becomes a convenient entry point connecting researcher intent and EvoX experimental output. Researchers focus on problem taste, multi-objective trade-offs, solution acceptance, and critical judgment. In the traditional approach, to start an EvoX experiment, one must first remember commands, dependencies, and interfaces
- The AI Native way of working moves the entry point up to "intent expression." You describe on what problem, under what constraints, and by what standard of acceptance, and tools like Codex are responsible for translating intent into executable code and environment operations, and returning runtime status. In this way, the starting point of an experiment is no longer command memory but a clear problem definition. Warehouse robot obstacle-avoidance pathfinding. You can use natural language to ask AI to call EvoX NSGA-II, perform multi-objective optimization on GPU, and output visualized routes. Here three types of information should be distinguished: the intent is "for warehouse robot obstacle-avoidance pathfinding, use EvoX NSGA-II to perform multi-objective optimization on GPU"
- The objectives are shortest path length, maximum safety distance, and lowest energy consumption
- The constraint is to return results within 5 minutes
- The acceptance goal is to output the Pareto front and visualized routes, and preserve reproducible run results. AI tools are responsible for understanding code, configuring the environment and dependencies, selecting or generating algorithms, executing on GPU, and returning status
- Human responsibility, meanwhile, moves up to problem definition, evaluation criteria setting, multi-objective trade-offs, solution acceptance, and critical judgment.

**Exercise Handling**

If asked "what is the core concept," one should grasp "experience an AI-native workflow that does not require memorizing installation commands or complicated interfaces." If asked to judge which statement is most reasonable, one should choose the option that connects to the concepts on this page and gives evidence or examples; relying only on feelings, changing all factors at once, or skipping the materials and directly memorizing answers do not meet the requirements. Regarding "quickly completing environment configuration and algorithm design," one should also explain with evidence or examples, rather than merely remembering the conclusion.

**Comprehension Check**

Ask students to explain in their own words the relationship of "natural language intent → AI understanding and execution → EvoX experimental output," and explain why researchers still need to review whether constraints are satisfied, whether the Pareto front is reasonable, and whether the routes are safe and feasible. After confirming that students can distinguish AI's execution responsibilities from human judgment responsibilities, proceed to subsequent practical content.

<a id="lecture-page-8"></a>

### Warehouse Robot Pathfinding Task in Practice

*Page 8*

> **Page Objective:** Understand how to quickly use EvoX through AI to solve a specific obstacle-avoidance pathfinding problem.

> **Lecture Sequence**
>
> Shelves, aisles, obstacles, start point, and end point are all determined, and a collision-free and preferably short path must be found.
>
> 2. Point out that path length and obstacle-avoidance safety are usually inconsistent, so this is a typical multi-objective optimization problem rather than a single-objective shortest path problem.
>
> 3. Explain that AI acts as a "task translator," converting natural language task descriptions into executable EvoX calls, reducing manual coding and parameter configuration.
>
> 4. EvoX NSGA-II performs population evaluation and search in parallel on GPU, retaining multiple compromise solutions and forming a route family from "short but risky" to "long but safe."
>
> Visualize candidate route maps and convergence trend curves to observe feasibility and search progress.

**Key Teaching Points**

- Fixed warehouse layout, obstacle environment, robot start point, and end point. Path key points, curve control points, turning radius, speed profile, etc. Minimize path length
- Minimize collision risk or maximize collision-free feasibility. Routes must remain within aisles, must not pass through shelves or obstacles, and must satisfy robot kinematic constraints. Automatically convert natural language descriptions into executable EvoX calls, reducing configuration cost
- Does not replace the optimization algorithm itself. Evaluate large numbers of candidate routes in parallel, accelerating NSGA-II iteration
- Does not change the fact that multi-objective problems have compromise solutions. Visualize route maps to observe path feasibility, diversity, and recommended collision-free routes
- Use convergence trend curves to judge whether a plateau has been reached. Define objectives and constraints first, then tune parameters
- Feasibility takes priority over path length
- Use convergence trends to decide whether to continue iterating or stop.

**Exercise Handling**

Task input elements -> fixed warehouse layout, obstacle environment, start point, and end point. Feedback: task input defines the environment, constraints, and start/end conditions.

Two objectives handled by NSGA-II -> path length and obstacle-avoidance safety. Feedback: a shorter path may pass closer to obstacles, and safety requirements may lengthen the path.

AI's main value -> automatically converting task descriptions into executable EvoX calls. Feedback: AI is the task translation and call generation layer, reducing configuration cost.

GPU advantage -> parallel evaluation of large numbers of candidate routes, accelerating NSGA-II iteration. Feedback: GPU accelerates evaluation and search and does not change the essence of multi-objective compromise.

Visualized route maps and convergence trends -> respectively observe route feasibility, diversity, and recommended collision-free routes; and whether the optimization process converges. Feedback: route maps show spatial solution quality, and convergence trends show search progress in the time dimension.

Define decision variables, two optimization objectives, and constraints; explain the division of labor among AI, EvoX NSGA-II, and GPU, and explain how convergence trends assist decision-making. Key answer points: AI parses task descriptions into EvoX calls; NSGA-II evaluates in parallel on GPU, and non-dominated sorting and crowding distance preserve compromise solutions; outputs visualized routes and convergence curves; if the curve is flat, the gain is limited, and if it is still decreasing, the number of iterations or population size can be increased.

**Comprehension Check**

Randomly ask a student to summarize the key points of this page in their own words, and the instructor supplements omitted keywords based on the answer.

> **Transition Hint**
>
> After confirming that students can state the core relationships on this page, proceed to the next page's example problems, applications, or summary.

<a id="lecture-page-9"></a>

### Experimental Results and Visualization Analysis

*Page 9*

> **Page Objective:** Learn to interpret convergence trends in the optimization process and complete result data.

> **Page Objective**
>
> Learn to interpret convergence trends in the optimization process and complete result data, and understand that "process trends + final results" must corroborate each other; conclusions cannot be drawn from a single best result alone.

> **Lecture Sequence**
>
> 1. First read the convergence curve to judge whether the search process is advancing.
>
> 2. Then look at the final routes and metric table under the fixed warehouse layout to judge whether the solution is usable.
>
> 3. Use complete experimental data to support reproducible conclusions.
>
> 4. Handle common misjudgments through exercises and cases.

**Key Teaching Points**

- Two types of evidence are indispensable. The curve answers "is the search moving," while routes and metrics answer "is the result usable." Only when the convergence trend shows that the search is advancing, the route visualization and metric table show that the solution is usable, and both conditions hold simultaneously can a conclusion be drawn. Missing either half makes it only a conjecture. Continuous improvement, stable decline in the early and middle stages or stable rise in composite metrics
- Oscillation, fluctuating up and down without a long-term trend, may come from evaluation noise, constraint conflicts, or excessive diversity
- Stagnation, a section that is almost flat but may still improve later
- Premature convergence, flattening completely very early and never recovering, often due to loss of population diversity or premature compression of the solution space. When "late stagnation/premature?" appears in the later part of the curve, it must be distinguished in combination with logs and cannot be directly written as "converged." For route comparison under a fixed warehouse layout, superimpose the optimal route and comparison routes on the same fixed warehouse map, and check whether the path is truly reachable, whether obstacle avoidance is reasonable, and whether the last segment near the endpoint is stable. Fixed layout is a key constraint, making route differences across runs or parameter settings attributable to the optimization itself rather than map changes. The metric table can give an intuitive comparison: path length 128.4 vs. 156.9, total turns 6 vs. 9, composite cost 1.00 vs. 1.21, reflecting the optimal route's advantages on multiple metrics. Runtime configuration and random seed, iteration logs, values of each objective by generation, final routes, and evaluation results. If the curve no longer improves noticeably late in the process, use the complete logs to judge whether it is premature convergence, evaluation saturation, or already close to a usable solution
- Rerun or cross-check if necessary. A curve that smoothly flattens early does not automatically mean the optimal solution has been found, nor does it automatically mean the algorithm has failed
- A route that looks nice also does not mean the search is stable. A single best result may be a true improvement or a product of random fluctuation or evaluation saturation; process trends and final results must corroborate each other.

**Keyword Coverage**

- Convergence trends, route verification, fixed warehouse layout, reproducibility, premature convergence, evaluation saturation, hypervolume indicator, path length, total turns, composite cost.

> **Exercise Clues**
>
> - Five multiple-choice questions revolve around the core judgments of this page. Question 1 asks about the relationship between the convergence curve and final route visualization; the correct direction is "the curve reflects whether the search process is advancing, while routes and the metric table reflect whether the final solution is usable; the two need to be judged together." Question 2 asks how to handle a situation where objective values remain flat for a long time after generation 200; the correct direction is "use complete logs to determine whether it is premature convergence, evaluation saturation, or already close to a usable solution, and rerun with adjusted strategies if necessary." Question 3 asks what reproducible conclusions should save and verify; the correct direction is "runtime configuration, random seed, iteration logs, values of each objective, final routes, and evaluation results." Question 4 asks the purpose of a fixed warehouse layout; the correct direction is "to make route differences across runs or algorithms attributable to the optimization itself rather than environmental changes." Question 5 asks for a rigorous interpretation of "very smooth and stops changing very early"; the correct direction is "check whether there is evaluation saturation or premature loss of population diversity, and cross-validate through reruns and metrics." Answer feedback: when correct, explain that the judgment connects to this page's concepts and gives a basis
> - When wrong, return to this page's explanation, find the key evidence or example, and then judge again. In "reproducing multi-objective pathfinding under a fixed warehouse layout," if the curve flattens after generation 180 and a decent candidate route is obtained, one needs to collect and verify runtime configuration and random seed, iteration logs, values of each objective by generation, final routes and evaluation results under the fixed layout, and the key metric table, and it is recommended to rerun or cross-check. A single best result cannot be used alone, because a single-point optimum may come from random fluctuation or evaluation saturation, cannot show whether the search is truly advancing, and cannot be reproduced by others. If after rerunning the curve shape is similar but the final route differs, compare metric distributions rather than single-point values, verify whether the seed and configuration are consistent, check for premature convergence or evaluation saturation, and if necessary increase the number of iterations, adjust the diversity maintenance strategy, or revise the evaluation function, and provide typical routes and statistical summaries in the report.

**Comprehension Check**

Randomly ask a student to summarize in their own words the relationship of "curves show trends, routes show implementation" and "process trends and final results are both indispensable," and the teacher supplements omitted keywords based on the answer. Students can be asked to give an example from their own experience explaining why looking only at the curve or only at the route may lead to misjudgment.

> **Transition Hint**
>
> After confirming that students can state that convergence curves and route visualization need to be judged together, proceed to the next page's example problems, applications, or summary.

<a id="lecture-page-10"></a>

### The Easier the Tools Are to Use, the Clearer Human Responsibility Becomes

*Page 10*

> **Page Objective:** Recognize the shift in the role and responsibility of human researchers after the spread of automated tools.

> **Page Objective**
>
> Understand that after the spread of automated tools, researchers' responsibility does not become lighter; instead, it moves up from "implementation" to "definition and adjudication." This page should make students remember one sentence: the easier the tools are to use, the clearer human responsibility becomes.

**Key Teaching Points**

- AI and EvoX press the execution cost of "idea → code → experiment" very low, and rapidly generating candidate implementations, batch parameter tuning, and plotting curves all become easy. But lower execution cost does not mean judgment cost disappears. Models cannot answer three前置 questions for researchers: is this problem worth studying? Are the objectives accurate? Is the comparison fair? Running successfully, compiling successfully, passing tests, and improving metrics are only candidate signals, not proof that a scientific conclusion holds. On the left is the AI / tool execution layer, responsible for generating candidate code, batch experiments and parameter tuning, automatic plotting and visualization, and enabling rapid elimination of low-value implementations
- On the right is the human responsibility layer, responsible for posing key questions, defining objectives and evaluation criteria, ensuring fair comparison, verifying whether conclusions are valid, and making value judgments and exercising taste. In the middle is the "non-outsourceable judgment" gate; acceptance criteria cannot be compromised, and candidate modifications must pass human adjudication. Genesis's acceptance gateway is precisely the engineering embodiment of this boundary: candidate modifications must pass compilation, testing, behavior checks, and upper-level acceptance before entering project history. In EvoX multi-objective experiments, Agents can rapidly generate candidate solutions, tune parameters, and plot, but researchers still need to review: do the objective functions represent real needs? Is candidate diversity obscured by metrics? Are failure modes selectively displayed? At this point, the value of tools is to let low-value implementations be eliminated faster and make high-value judgment the bottleneck earlier. The Turing hint also lands here: there is much to do ahead. Code is cheap. Taste matters. The core ability is to pose key questions and control conclusions in a reproducible way
- Researchers' taste determines what kind of scientific value technological convenience ultimately translates into.

**Keyword Coverage**

- Execution cost, judgment cost, non-outsourceable judgment, scientific validity, acceptance gateway, candidate signals, fair comparison, value judgment and taste. Source basis: this page unfolds around "responsibility moves up: from implementation to definition and adjudication" and "result validity takes priority over successful execution." Material clues: a left-right comparison diagram can be used to highlight the division of labor between the AI / tool execution layer and the human responsibility layer, with "non-outsourceable judgment" emphasized in the middle.

**Exercise Handling**

Question 1 should choose "passing compilation, testing, behavior checks, and upper-level acceptance"; the feedback point is: no matter how fast or beautiful the charts are, they are only candidate signals; the key is the acceptance gateway. Question 2 should choose "problem selection, objective definition, and evaluation criteria still need to be undertaken by humans"; the feedback point is: tools accelerate execution, not cancel judgment. Question 3 should choose "whether the problem is worth studying, whether the objectives are accurate, and whether the comparison is fair"; the feedback point is: these three are preconditions for scientific validity. Question 4 should prioritize reviewing "whether the objective functions represent real needs, whether candidate diversity is obscured by metrics, and whether failure modes are selectively displayed"; the feedback point is: improving metrics does not equal a valid conclusion.

Question 5 should choose "after implementation cost decreases, researchers' taste and judgment determine what kind of scientific value technological convenience translates into"; the feedback point is: Code is cheap refers to lower implementation cost, and Taste matters means judgment and taste are more important.

In the Genesis multi-Agent project, Agents can propose candidate patches, run tests, and summarize metrics, but approving entry into project history, setting acceptance criteria, and interpreting conclusions must be the responsibility of humans. Non-outsourceable judgments include: whether improving stability is a real need, how stability is defined, whether the benchmark represents real scenarios, and whether baselines, variables, and failure modes are treated consistently. If only "benchmark metric improvement" is used as the acceptance criterion, risks may come from objective function bias, overfitting to the benchmark, selective display of successful cases, hidden failure modes, or unfair comparison.

The improvement direction is to add baseline reproduction, variable control, ablation experiments, failure mode reporting, multi-objective trade-offs, and extrapolation boundary checks to the acceptance gateway, and require humans to confirm whether the objective functions represent real needs and whether the comparison is fair.

First ask whether it is worth doing, then ask how to implement it; treat acceptance criteria as your own responsibility; taste determines where technological convenience goes. Comprehension check: ask students to state in one sentence what the most important non-outsourceable judgment on this page is, and explain how to verify it. Transition hint: after confirming that students can distinguish "candidate signals" from "scientific conclusions" and can state the boundary between the execution layer and the responsibility layer, proceed to the next page's applications or summary.

<a id="lecture-page-11"></a>

### Research Core: The Ability to Pose Key Questions

*Page 11*

> **Page Objective:** Master the core questioning ability that is more important than writing code in the era of automated programming.

> **Page Objective**
>
> This page should make students understand that in AI Native research, automated programming and large models have already pressed the cost of "implementing answers" very low, so the focus of research has shifted upward from "can it be built" to "is it worth doing, and where should it be done." The researcher's core ability is to pose key questions and safeguard direction, trade-off criteria, and scientific significance.

**Key Teaching Points**

- 1. The change in cost structure is the logical starting point of this page. Code generation, solution search, and experiment execution can all be delegated to AI
- When answers become cheap, what becomes scarce is "asking the right questions." AI is responsible for expanding the answer space and execution paths, while humans are responsible for problem definition and direction control, and responsibility moves upward accordingly. 2. Using the page's mind map, break the key questioning ability into six types of elements and explain each one clearly: objectives and conflicts—what quantity is truly to be improved, how to trade off among multiple objectives, and which has priority
- Constraints and boundaries—which conditions are non-negotiable, and how large the solution space is
- Evaluation and verification—whether metrics are observable, and what the verification protocol and evaluation budget are
- Candidates / solution space—what kind of diversity and robustness are needed
- Failure criteria—what kind of result should be judged a failure
- Human-machine division of labor and taste—AI expands answers, humans control direction. Students can be prompted to remember these six categories as a self-check list. 3. The essence of key questioning is not probing implementation details, but transforming vague intuition into a research structure that is testable, evolvable, and division-of-labor ready. Question quality determines solution space quality: the clearer the problem definition, the more likely search and evolution will land in meaningful regions, and the more likely outputs will be interpretable and reusable
- The vaguer the definition, the more the model can only randomly probe in an overly large space, and the results often appear feasible but cannot be accumulated. 4. Human-machine division of labor and the researcher's core taste. AI expands the answer space and execution paths, while humans control direction, trade-off criteria, and scientific significance. Take the practice of system-level continuous evolution like Genesis as an example: candidate modifications must pass compilation, testing, and upper-level acceptance before entering the accepted project version and becoming the historical basis for subsequent work
- If the evaluation protocol and failure criteria are not clearly defined at the questioning stage, the acceptance gate has no basis for judgment, and AI output can only remain a one-off code artifact, unable to accumulate across contexts and task cycles. Core taste consists of three judgments: what is worth asking, what evidence is acceptable, and what solution, although feasible, is not worth doing. Rewrite it as "What is the real conflict? How are objectives and constraints quantified? What are the evaluation budget and verification standards? What diversity and robustness are needed? What kind of result should be judged a failure?" In this way, AI can efficiently implement answers, and humans have a basis for acceptance. The five multiple-choice questions correspond respectively to the five judgments on this page—why the core of research has shifted upward, the essence of key questioning, the elements a key question needs to clarify, the relationship between question quality and solution space, and the triple judgment of core taste. There is no need to read them one by one; students can answer first, then correct with feedback such as "what is pressed down is implementation cost, not judgment cost" and "vagueness is not freedom." The case question asks students to rewrite "use EvoX for optimization" into a problem card covering objectives and conflicts, constraints and boundaries, evaluation and verification, and failure criteria, and explain how question quality determines whether the experiment can accumulate into project outcomes capable of continuous evolution. Reference points: Genesis treats submitted code as candidate modifications, and only those passing compilation, testing, and upper-level acceptance enter the accepted version
- Without observable metrics, verification protocols, and failure criteria, acceptance has no basis
- AI is responsible for generating candidates, searching, and running tests, while humans are responsible for defining objectives, hard constraints, evaluation budgets, and failure criteria and making acceptance judgments. Randomly ask a student to restate the six self-check items in their own words and give a vague requirement from their own research, then try to rewrite it on the spot. After confirming that students can state the two relationships "running successfully does not mean worth investing in" and "question quality determines solution space quality," proceed to the next page.

<a id="lecture-page-12"></a>

### Human-Machine Division of Labor: AI Implements Answers, Humans Control Direction

*Page 12*

> **Page Objective:** Clarify the division of labor and collaboration between AI and researchers in the process of scientific exploration.

**Key Teaching Points**

- Before each experiment, ask yourself three questions: who chose this problem? Who set the evaluation criteria? Who accepts the conclusion? If the answers to all three point to "me," the division of labor is healthy; if they all point to the model, direction control has already been lost.
- Once evaluation criteria can be rewritten by an automated process, optimization will quietly shift toward "the metric that is easiest to improve." Setting objective functions and constraints as read-only is the first gate to prevent drift.
- AI expands bandwidth, humans safeguard meaning—what is delivered is not more numbers, but conclusions that hold up.

### Page Objective

Clarify the division of labor and collaboration between AI and researchers, define the boundary between the AI execution layer and the human control layer, and understand why "AI expands exploration bandwidth, humans safeguard scientific meaning."

### Lecture Sequence

Leave implementation and exploration to AI, and leave direction and judgment to researchers.

Human-machine collaboration closed loop. The AI execution layer includes answer implementation, batch experiment running, candidate solution search, and result feedback; the human control layer includes problem definition, direction selection, evidence judgment, and scientific significance acceptance. The two sides are coupled through "results go up, standards go down": AI pushes candidate answers and experimental feedback to researchers, and researchers hand goals, constraints, and acceptance criteria back to AI.

Rapidly implement answers, run experiments in batches, search candidate solutions, and provide feedback. Once the problem and evaluation criteria are clear, AI can provide a runnable and verifiable solution in a very short time, turning trial and error from a scarce resource into a routine operation.

Pose key questions, set objectives, constraints, and evaluation criteria, judge whether evidence is credible, and complete scientific significance acceptance. It is necessary to distinguish "results that run" from "results that are reliable," and identify overfitting, data leakage, and metric manipulation.

If either side is absent, it fails. With only AI, you get large numbers of meaningless results; with only humans, exploration bandwidth is limited. Taking multi-objective evolutionary exploration as an example, AI can automatically generate and run large numbers of candidate solutions, while researchers decide whether optimization objectives, constraints, and evaluation metrics reflect the real problem, and screen out directions that are scientifically credible and worth continuing to explore.

Also handing evaluation criteria to AI to decide automatically. In this way, the system will very efficiently optimize an objective that does not reflect the real scientific problem, producing large numbers of results that "look reasonable" but are meaningless. Any decision that changes "what counts as good" must remain on the human side.

Who chose this problem? Who set the evaluation criteria? Who accepts the conclusion? If the answers to all three questions point to "me," the division of labor is healthy; if they all point to the model, direction control has already been lost.

AI expands bandwidth, humans safeguard meaning—what is delivered is not more numbers, but conclusions that hold up.

### Key Teaching Points

Answer implementation, batch experiment running, candidate solution search, and result feedback; the core is to press implementation cost close to zero.

Problem definition, direction selection, evidence judgment, and scientific significance acceptance; the core is to keep judgment cost in one's own hands.

AI expands exploration bandwidth, and humans control direction and acceptance criteria.

Once evaluation criteria can be rewritten by an automated process, optimization will quietly shift toward "the metric that is easiest to improve." Setting objective functions and constraints as read-only is the first gate to prevent drift.

It is not about producing more numerical results, but about results being truly scientifically meaningful; only then does quantity have value.

### Keyword Coverage

AI execution layer, human control layer, human-machine collaboration closed loop, exploration bandwidth, evaluation criteria drift, read-only objective functions, scientific significance acceptance, three self-check questions.

### Exercise Handling

The correct answer is "rapidly implement answers, run experiments in batches, and search candidate solutions." AI handles implementation and exploration; deciding problem value, judging evidence credibility, and accepting scientific significance belong to the human control layer.

The correct answer is "because only when results are truly scientifically meaningful does quantity have value." Quantity comes from AI's exploration bandwidth, and value comes from human judgment of scientific significance.

The correct answer is "whether optimization objectives, constraints, and evaluation metrics reflect the real problem." Candidate generation and batch running belong to the AI execution layer; researchers must hold the line at the level of "what counts as good."

The correct answer is "to allow researchers to focus their attention on direction judgment and acceptance criteria." What AI expands is breadth, and what humans provide is direction; the two are complementary rather than mutually substitutable.

The correct answer is "the system will efficiently optimize an objective that does not reflect the real scientific problem, producing large numbers of seemingly reasonable but meaningless results." Handing evaluation criteria to the system is equivalent to letting the evaluated set the exam paper; any decision that changes evaluation criteria must retain human review.

### Case Handling

1. The AI execution layer includes candidate formulation generation, batch simulation runs, performance metric collection, and population updates; these belong to implementation and exploration. The human control layer includes the material system to search, performance objectives and process constraints, whether metrics reflect real physical meaning, and whether final candidates are worth continuing to invest in experimentally; these belong to direction and judgment. The basis for the division is: any decision that changes "what counts as good" must remain on the human side; any work that executes already-set standards at larger scale can be delegated to AI.

2. If AI is allowed to automatically adjust performance metric weights through meta-optimization, the main risk is evaluation criteria drift: once the optimized system also holds the power to evaluate itself, it will lean toward "the metric that is easiest to improve," and the high-scoring formulations produced may be physically unrealizable or practically worthless, while often appearing very reasonable on the surface and difficult to identify at a glance. Protective designs include: declare objective functions and constraints as controlled and read-only; allow meta-optimization only to adjust a small number of hyperparameters within human-specified boundaries and set upper and lower limits; set acceptance gates independent of the optimization objective, such as real synthesis and characterization experiments; and any weight change must be explicitly reviewed by researchers and recorded, ensuring that directional decisions are traceable.

### Classroom Activity

Ask students to use an example close to their own learning or research experience to restate the division of labor "AI implements answers, humans control direction," and explain the relationship between this example and the three self-check questions.

### Comprehension Check

AI execution layer, human control layer, human-machine collaboration closed loop, metric drift, three self-check questions. Supplement omitted keywords based on the answer.

### Transition Hint

After confirming that students can state the core relationship "AI expands exploration bandwidth, humans control direction and acceptance criteria," proceed to the next page's example problems, applications, or summary.

<a id="lecture-page-13"></a>

### Core Principle: Code is cheap. Taste matters

*Page 13*

> **Page Objective:** Appreciate the Turing philosophy and EvoX's ultimate goal of building open infrastructure.

> **Page Objective**
>
> Understand the core principle "Code is cheap. Taste matters," and appreciate the Turing philosophy and EvoX's ultimate goal of building open infrastructure.

**Key Teaching Points**

- 1. Code is cheap is an objective description of the engineering status quo. When the marginal cost of code generation and implementation is pressed close to zero by large models and tensorized foundations, code is no longer a barrier, nor a unit for measuring research contribution. "Running successfully" degenerates from an achievement to a prerequisite, from a displayable result to an admission ticket for continuing work. 2. Taste matters repositions human responsibility after the human-machine division of labor. When "AI implements answers, humans control direction" becomes the default division of labor, what is truly scarce on the human side is the ability to pose key questions, set evaluation criteria, and judge direction amid multi-objective conflicts. 3. Problem selection—which problem to work on determines the upper limit more than what method to use; when the direction is wrong, the faster the implementation, the more wasteful it is
- Design of objective functions and evaluation criteria—once the metrics are chosen wrongly, the model will only converge efficiently in the wrong direction
- Trade-off criteria for multi-objective decisions—preferences among performance, reproducibility, maintainability, and deployment cost must be explicitly declared, not decided on the fly
- Interpretation and attribution of results—distinguish "happened to run" from "truly understood," and judge where the gains actually come from. 4. Taste must be testable. Taste is not an aesthetic assertion, nor can it be adjudicated by seniority or voting. It must be falsified by "entering the real environment—receiving real feedback": write judgments as verifiable hypotheses and revise them through failures and successes in real scenarios. Otherwise, the discussion reduces to a dispute over preferences. 5. The significance of infrastructure is to give taste a place to land. EvoX's ultimate goal is precisely to build open infrastructure that can enter real environments and receive real feedback. An open, decoupled, composable foundation lowers deployment cost enough that good ideas can enter real scenarios at low cost, be screened, accumulated, and inherited—and judgment thereby gains a carrier that can be repeatedly refined. Code cheap does not mean engineering can be omitted. Acceptance gateways, reproducibility, maintainability, and feedback loops still constitute real thresholds. Taste is precisely embodied in trade-off judgments about these thresholds: what kind of feedback is worth trusting, what kind of metrics must be upheld, and what kind of failed attempts should be rejected rather than merged. The value of Genesis-style mechanisms also lies here—candidate modifications can become the historical basis inheritable by subsequent executors only after passing compilation, testing, behavior checks, and upper-level acceptance. We can only see a very short distance ahead, but we can see that there is a great deal there waiting to be done. Rather than arguing about the specific form of the endgame of intelligence, it is better to first build open infrastructure that can continuously enter real scenarios and receive real feedback, so that each round of exploration can be verified and inherited. The page uses a trend chart to show implementation cost continuously declining and judgment value continuously rising, with their intersection forming an inflection point, meaning that judgment becomes the key variable. Below the figure are EvoX vision keywords: open, composable, real feedback, continuous evolution.

**Exercise Handling**

This page has five multiple-choice questions, respectively checking understanding of the engineering meaning of Code is cheap, the direction of the scarcity shift, the falsifiability of taste, the four engineering thresholds, and the purpose of EvoX infrastructure. After answering, check against the feedback and focus on distinguishing "implementation-side indicators" from "judgment-side capabilities": lines of code, completion accuracy, framework popularity, and commit frequency cannot replace judgment about "what should be accepted." The case question asks the team to list the links that should be prioritized for investment and design a candidate modification acceptance process that tests taste;

Reference directions include problem selection and objective definition, objective function and evaluation criteria design, acceptance gateways and multi-objective trade-off criteria, result interpretation and attribution, and the closed loop of "candidate modification—isolated testing—evaluation scoring—upper-level acceptance—historical inheritance—feedback return."

**Comprehension Check**

Randomly ask a student to summarize the key points of this page in their own words, and the instructor supplements omitted keywords based on the answer, such as "running successfully is only an admission ticket," "taste must be falsifiable," and "four engineering thresholds."

> **Transition Hint**
>
> This page follows the previous page's division of labor "AI implements answers, humans control direction" and gives the core principle supporting this division; the next page will move to hands-on practice in guiding AI through dialogue to complete EvoX tasks.

<a id="lecture-page-14"></a>

### Classroom Activity: Guiding AI Through Dialogue to Complete EvoX Tasks

*Page 14*

> **Page Objective:** Verify the basic optimization task process in an AI Native environment through hands-on practice.

**Classroom Activity**

Guiding AI through dialogue to complete EvoX tasks

> **Page Objective**
>
> Complete the minimal closed loop of "prompt → generate → run → accept" in a real EvoX environment. The focus is not merely obtaining a readable piece of code, but verifying the AI Native way of working: humans give direction, AI gives implementation, humans perform acceptance.

> **Lecture Sequence**
>
> First explain the activity task, then break down how to construct the prompt, then explain how to accept the run results, and finally handle unsatisfactory results by adding constraints and return to the human-machine division of labor.

**Key Teaching Points**

- Use a conversational prompt to drive AI to generate and run a basic EvoX optimization task, then inspect the output like an engineer. Optimization problem and objective function (for example, minimizing the Rastrigin function), search space and dimensions (for example, 10 dimensions and value ranges), algorithm or operators (for example, DE algorithm, crossover and mutation operators), population size and iteration generations (for example, population 128, 200 generations), computing platform (CPU or GPU tensorization), expected output (best value, convergence curve, run log). Too coarse will trigger default configurations, making it hard to judge whether it matches intent
- Too detailed will degenerate into manual coding. The appropriate approach is to clarify constraints and acceptance criteria and leave implementation details to AI. For example, specify the problem, algorithm, population size, and number of iterations, but there is no need to prescribe how specific interfaces are called. Whether it truly executes, rather than only providing code, can be checked through terminal logs and runtime
- Whether the convergence curve is monotonically improving and free of abnormal oscillation
- Whether the best value matches the known magnitude of the problem, for example, the global optimum of the Rastrigin function is 0
- Whether the random seed and configuration are reproducible; after fixing the seed, repeated runs should yield the same or similar results. When results fall short of expectations, prioritize adding constraints through dialogue, for example, "fix seed=42 and rerun, and give the mean and variance of three repetitions," and observe whether AI can iteratively correct rather than rewrite. Humans are responsible for problem definition, metric criteria, and result judgment
- AI is responsible for interface selection, code organization, and debugging execution. Only perform process verification for the basic task; do not expand into follow-up topics such as MetaDE bi-level evolution, multi-objective trade-offs, or Genesis multi-Agent. Reference prompt example: "Use EvoX to solve for the minimum of the Rastrigin function (10 dimensions), using the DE algorithm, population 128, 200 generations, using the GPU tensorized backend, fixed seed=42
- Please run directly and return the best fitness, convergence curve plot, and run log." Whether it truly runs, whether the shape of the convergence curve is reasonable, whether the best value is close to 0, and whether repeated runs are consistent.

> **Exercise Clues**
>
> - There is no need to specify the exact number of lines of code for the algorithm implementation
> - The key evidence for verifying real execution is the terminal iteration logs and convergence curve
> - When results are poor, the most effective approach is to add constraints, such as fixing the random seed and repeating runs
> - Humans are mainly responsible for defining the problem, metric criteria, and result judgment
> - Prompt granularity should clarify constraints and acceptance criteria and leave implementation details to AI. If students answer incorrectly, guide them back to "prompt elements," "run checklist," and "human-machine division of labor" to find the basis. 20-dimensional Ackley function, CMA-ES, population 64, 500 iterations, CPU, fixed seed=123; if the curve oscillates sharply early and the best value is far greater than 0, possible reasons include too large a step-size parameter, insufficient population diversity, mismatch between algorithm parameters and problem dimension, and random seed causing initial exploration fluctuation. Additional constraints can fix the seed and repeat three times, calculate mean and variance
> - Require output of the best value change per generation
> - Adjust the step size or population size and rerun. During acceptance, in addition to the best value, also check whether it truly executed, the shape of the convergence curve, the magnitude of the best value, reproducibility, and reasonableness of runtime. Students can be divided into groups with role assignments: one person constructs prompts, one observes run logs and convergence curves, and one gives an acceptance conclusion against the checklist
> - Record one failure or unsatisfactory result and try to improve it by adding constraints.

**Comprehension Check**

Randomly ask a student to summarize the key points of this page in their own words, and the instructor supplements prompt elements, the four acceptance questions, and the principle of iterating rather than rewriting based on the answer.

> **Transition Hint**
>
> After confirming that students can state the core relationship "humans give direction, AI gives implementation, humans perform acceptance," proceed to the next page's example problems, applications, or summary.

<a id="lecture-page-15"></a>

### Course Summary: AI Native Workflow and Scientific Taste

*Page 15*

> **Page Objective:** Summarize EvoX's AI Native workflow and critical thinking in human-machine collaboration.

> **Page Objective**
>
> As the conclusion of the whole course, this page converges EvoX's AI Native workflow and the researcher's irreplaceable scientific taste into the same conclusion: when tools press the cost of "implementing answers" extremely low, "defining what is worth doing and judging what results are credible" becomes the watershed of research value.

> **Lecture Sequence**
>
> On the left is the AI Native workflow, starting from natural language dialogue, completing environment configuration, constructing problems and constraints, driving evolutionary runs and batch exploration, and visualizing and reviewing results; on the right is human scientific taste, responsible for defining problems, setting objectives and constraints, making multi-objective trade-offs, and judging result credibility and evolution direction.
>
> AI implements answers, humans control direction; in one sentence, Code is cheap. Taste matters.
>
> What the workflow compresses is the path cost from idea to first runnable experiment; responsibility rises with convenience; scientific taste has identifiable landing points; critical thinking has four structured questions; project-level and system-level continuous evolution still require humans to set acceptance criteria and evolution direction.
>
> What is scarce is not code, but judgment; workflow proficiency determines how fast you can run, while scientific taste and critical thinking determine whether the direction is right.

**Key Teaching Points**

- Use natural language dialogue as the entry point to drive EvoX's full-chain experiments. What it reduces is the path cost from "idea" to "first runnable experiment," not the experiment itself, nor does it replace problem definition and result judgment. Script skeletons, parameter interfaces, and plotting code can take shape faster, so researchers gain a higher frequency of experimental iteration. The easier the tool is to use, the clearer human responsibility becomes. Automation transfers execution burden, not judgment responsibility. When AI produces candidate solutions within minutes, "whether multi-objective trade-offs are reasonable," "whether metric improvements are credible," and "which direction to explore next" still must be answered by researchers. Convenience increases trial-and-error throughput and equally amplifies the propagation speed of wrong decisions. Problem definition determines what is studied and what is abandoned
- Objective and constraint setting translates vague intent into optimizable objective functions and hard constraints
- Multi-objective trade-offs give defensible preferences among convergence speed, diversity, robustness, and cost
- Result credibility judgment distinguishes "it ran" from "the conclusion holds"
- Evolution direction setting determines where the next round of exploration goes, rather than passively accepting the current optimum. These are not computational problems but problems of value and judgment. Do the assumptions hold? AI may have silently filled in unstated premises
- Are the metrics misread? Improvements may come from data leakage, changes in evaluation criteria, or overfitting
- Can the results be reproduced? Random seeds, parallel scheduling, and dependency versions all affect reproducibility
- Are boundaries and failure modes tested? Do they still hold under extreme constraints, sparse data, or high-dimensional situations? AI is responsible for implementation and batch exploration, and humans are responsible for direction and value judgment. No matter how high the degree of automation, acceptance criteria and evolution direction still need to be set by humans
- If this judgment is lacking for a long time, gaps in taste will be amplified by time into technical debt that is difficult to repay. AI implements answers, humans control direction. Before handing a task to AI each time, first think clearly about what the acceptance criteria are.

**Keyword Coverage**

- AI Native workflow, scientific taste, critical thinking, human-machine division of labor, execution burden, judgment responsibility, problem definition, objectives and constraints, multi-objective trade-offs, result credibility, evolution direction, technical debt, Code is cheap. Taste matters.

> **Exercise Clues**
>
> - The exercises on this page revolve around cost compression, responsibility transfer, landing points of scientific taste, critical verification, and risks of continuous evolution. When handling them, first let students judge "what is replaced by automation and what is not replaced," then return to the two-step framework of "run first, verify second."

**Exercise Handling**

Tools compress the implementation cost from idea to first runnable experiment, but do not change the difficulty of problem definition and result judgment. When giving feedback, remind students to distinguish "execution burden" from "judgment responsibility."

Faster output speed makes unverified conclusions more easily transmitted as confirmed results. When giving feedback, emphasize that convenience increases trial-and-error throughput and proportionally amplifies the propagation speed of wrong decisions.

Problem definition, objective and constraint setting, multi-objective trade-offs, result credibility judgment, and evolution direction setting. When giving feedback, explain that these links are problems of value and judgment, not computational problems.

Implicit assumptions that AI silently filled in without stating, and whether evaluation criteria were changed. When giving feedback, point out that the focus of critical verification is assumptions, metric criteria, reproducibility, and boundary conditions, not presentation form.

Gaps in taste are continuously amplified by time and accumulate into technical debt that is difficult to repay. When giving feedback, reiterate that automation can only guarantee "it runs," not "it runs in the right direction."

When facing candidate solutions and recommended rankings given by AI, first check whether objectives and constraints match the real business requirements, then verify metric criteria and baselines, check the distribution and robustness of the solutions on the trade-off front, perform boundary and failure mode tests, and fix random seeds, dependency versions, and experimental configurations to ensure reproducibility. If the mainline solution is decided entirely according to AI's recommended ranking and the direction is automatically advanced, the risk is outsourcing the value judgment of multi-objective trade-offs, with the wrong direction repeatedly inherited by subsequent iterations, and "it runs" being mistaken for "the direction is correct." When resetting the division of labor, let AI handle implementation and batch exploration, while humans clarify objective weights and hard constraints, set acceptance criteria, retain the right to review and veto, and specify hypotheses and verification methods for the next round of exploration.

**Classroom Activity**

Ask students to restate the "four self-check questions" in their own words and give an example close to their own learning or research experience to explain how skipping verification can mistake "it ran" for "it holds up."

**Comprehension Check**

Randomly ask a student to summarize the key points of this page and answer "what does workflow proficiency determine, and what do scientific taste and critical thinking determine." The instructor supplements omitted relationships based on the answer: the former determines speed, and the latter determines direction and value.

> **Transition Hint**
>
> After confirming that students can distinguish "running successfully" from "holding up," and "implementing answers" from "controlling direction," proceed to the next page's example problems, applications, or summary.

<a id="lecture-page-16"></a>

### Appendix and Open Source Community Entry Points

*Page 16*

> **Page Objective:** Obtain EvoX official communication channels and continuous learning resources.

> **Page Objective**
>
> As the course appendix, this page summarizes the official community entry points for the EvoX intelligent evolution system and AI Native research practice, and explains the channels for continued learning, asking questions, and participating in frontier exploration after class.

**Key Teaching Points**

- First distinguish the two official entry points. The official WeChat public account is "演化机器智能" (Evolutionary Machine Intelligence), used to publish course updates, technical articles, event notices, and frontier interpretations, suitable for systematically tracking the direction of intelligent evolution. The official QQ exchange group number is 297969717, used for real-time questions, discussion, and peer exchange, making it easy to get feedback on specific problems. Both point to "continuous participation in frontier exploration of intelligent evolution," not replacing classroom learning, but forming a cycle of "learning—practice—exchange—relearning." After joining, first browse pinned announcements and historical messages to understand the rules and existing resources, then participate in discussions in combination with your research direction. When asking questions, provide clear background, specific questions, and methods already tried
- Actively participating in others' discussions can also deepen understanding. Regularly check frontier content and turn community resources into research capability. The exercises on this page revolve around three facts and two attitudes. The public account name is "演化机器智能"
- The QQ group number is 297969717
- The purpose of the community entry points is to provide channels for continued learning, asking questions, and frontier exploration after class
- To obtain resources after class, one should follow the public account and join the QQ group through the official entry points
- Community use should involve actively asking questions, sharing, and participating in discussions, rather than using it only before exams, joining unofficial groups, or lurking. The case study can guide students to write down the two official channels and give at least two suggestions for continuous learning, such as following public account updates, asking questions and exchanging in the group, tracking frontier developments, participating in open source projects or online activities, and applying what is learned in the course to actual research and sharing experience.

**Comprehension Check**

Ask students to explain in their own words what each of the two official entry points is suitable for, and restate the correct practices after joining the community. If students only remember the names but cannot state the uses, have them look back at the page to compare the two entry points.

> **Transition Hint**
>
> After confirming that students can state the relationship between the official entry points and the continuous learning cycle, proceed to the next page.