In the AI Era, How to Use Codex to Build a Personal Learning System

From “Let AI Answer Questions” to “Let AI Drive Skill Growth”

AI has already driven the cost of acquiring knowledge very low.

In the past, to learn a new field, you might first find courses, buy books, organize materials, and then spend a long time building a knowledge framework. Now, just throw a question at a large model, and within minutes you get concept explanations, learning paths, case studies, and even runnable project code.

But many people quickly find: information has increased, but learning hasn’t really become stable.

You ask many questions, but haven’t formed your own knowledge system; you’ve generated several study plans, but find it hard to stick with them; you understand the AI’s answers, but when faced with a real task, you still can’t execute; you’ve collected a large number of prompts, but each new conversation requires reintroducing the background, goals, progress, and blockers.

The problem isn’t that AI isn’t powerful enough, but that we still treat it as a “temporary Q&A tool.”

One conversation can solve a local problem, but it cannot natively manage long-term goals, learning progress, ability changes, error records, and project outcomes. The truly worth-thinking question is no longer “How can AI make me a study plan,” but:

How can we turn AI into a long-term execution engine for a personal learning system?

The open-source project Goal Learning OS provides a very inspiring direction: using Codex as the core, organizing the learning process into a local repository, and depositing goals, knowledge maps, daily tasks, exercises, tests, mistakes, reflections, and project outcomes into maintainable files.

The key here is not just “let AI help me learn,” but to turn learning into a system that can run, check, and iterate.

When learning enters a repository, goals are no longer just slogans, tasks are no longer temporary advice, mistakes are no longer forgotten, and projects no longer wait until the end. Codex reads the existing state, continues to the next step, updates files, runs checks, and helps you turn scattered conversations into a continuous capability-building project.

1. What’s Truly Scarce in the AI Era Is Not Knowledge, but the Learning Loop

Traditional learning methods usually focus on three questions: what to learn, what to read, what to remember.

But a learning system that truly builds skills must also answer another set of questions:

Why learn this content today? What task should be completed after learning? How to prove that you’ve truly mastered it? Where should mistakes be recorded? When to retest? How does today’s learning feed into the final project? If progress doesn’t meet expectations, how should the route be adjusted?

These questions may not sound as sexy as a “learning roadmap,” but they determine whether learning translates into ability.

A complete learning loop should at least include the following chain:

Goal Definition
→ Knowledge Decomposition
→ Task Execution
→ Active Practice
→ Output/Outcome
→ Test Verification
→ Mistake Recording
→ Route Adjustment
→ Project Delivery

Many AI study plans cover only the first two steps: goals and content. They tell you what to learn in week one, what in week two, and recommend resources. It looks complete. But the real break in learning often happens later: no practice, no verification, no mistake recording, no retesting, and no project handover.

So you get the illusion: “I have already ‘learned’ this topic.”

But when you need to independently complete a real task — like designing an Agent workflow, writing an automation script, or building a set of market research prompt systems — you find only scattered concepts in your mind, with no callable methods.

An effective personal learning system must cover the entire loop. It doesn’t just tell you “what to learn today”; it also defines what must be completed today, to what level is considered passing, which mistakes need retraining, how current results feed into the final project, and whether the next step should be to continue, catch up, or lower difficulty.

This is precisely why Codex is more suitable than ordinary conversational AI.

Ordinary chatbots excel at explaining problems; Codex is better at maintaining state. It can read files, understand directory structures, modify content, execute commands, run tests, and continue working based on existing records.

That means we can manage “learning” itself as a long-term project.

2. Why Codex: Learning Needs an Execution Engine That Can Read and Write State

If you just want to ask a concept, any large model can give a decent answer.

But the core of a personal learning system isn’t a single answer; it’s long-term state management.

Where did you stop today? What wasn’t completed yesterday? What mistakes have you made in the last three times? Which module of the final project has been pushed forward? Which concepts need retesting in three days? Does the current plan exceed the daily 60-minute time budget?

These questions can’t be reliably solved by a “memory-capable chat window.” A more reliable approach is to write the learning state into files, letting AI read facts from files each time instead of guessing from conversation context.

That’s where Codex’s advantage lies. It can directly enter the local project environment:

Read files
Understand directory structure
Modify learning records
Generate daily tasks
Maintain error logs
Push project documentation
Run check scripts
Continue work based on existing state

Under this model, the learning system can be split into three layers.

Layer 1 is Codex. It is responsible for understanding goals, reading state, executing tasks, updating files, and running checks.

Layer 2 is AGENTS.md. It acts as the operating rules for the learning system, telling Codex what to do each time it enters the repository, which files must be updated, under what circumstances to test, how to record mistakes, and which tasks must be done by the learner personally.

Layer 3 is the Learning Repository, which stores goals, knowledge maps, routes, daily tasks, exercises, tests, mistakes, projects, and final results.

With these three layers combined, the role of AI changes.

It’s no longer just an assistant that answers questions, but a learning operating system that continuously executes around goals. Every time you open the repository, it can see your current progress, historical mistakes, unfinished tasks, and project status, then continue from the first incomplete step.

For knowledge workers, creators, and developers, this is crucial. Because what you truly want isn’t just “to know a bit more,” but “to continuously form deliverable skills.”

3. Design the Learning Process as a Repository, Not a Plan

A mature personal learning system should not consist of just a 30-day plan.

A plan only answers “what do I want to do in the future”; a repository answers “what is actually happening now.”

It preserves both the route and the traces of execution; both knowledge and mistakes; both exercises and project outcomes. You can start with the following structure:

learning-repo/
├── AGENTS.md
├── README.md
├── progress.md
│
├── 00_meta/
│   ├── intake.md
│   ├── assumptions.md
│   └── sources_policy.md
│
├── 01_maps/
│   ├── knowledge_map.md
│   ├── core_concepts.md
│   └── learning_dependencies.md
│
├── 02_roadmap/
│   ├── 30_day_plan.md
│   ├── weekly_milestones.md
│   └── final_project_plan.md
│
├── 03_daily_tasks/
│   ├── day_01.md
│   ├── day_02.md
│   └── ...
│
├── 04_glossary/
├── 05_exercises/
├── 06_mistakes/
├── 07_cases/
├── 08_tests/
├── 09_project/
└── 10_outputs/

This structure isn’t meant to create management burden, but to make the key variables in learning explicit.

progress.md records overall progress, avoiding repeated background descriptions. 01_maps stores knowledge maps and concept dependencies, preventing learning from becoming a pile of materials. 02_roadmap manages phase goals and milestones. 03_daily_tasks turns daily learning into executable tasks. 05_exercises preserves practice processes. 06_mistakes records errors and retest arrangements. 09_project hosts the final project, ensuring learning doesn’t stay at the note-taking level.

What really matters is that all files can be read and updated by Codex.

This means the learner doesn’t have to explain from scratch each time: “Where did I get to before, what is my goal, what are my foundations, where am I stuck recently.” This information is already in the repository. Codex just needs to continue based on the real state, not regenerate a seemingly complete new plan from temporary chat.

4. A Good Learning Repository Needs at Least Six Core Modules

1. Goal Module: Define the Ability Outcome First, Not the Learning Content

The learning system must first clarify not “what do I want to learn,” but “what can I do after learning?”

“Learn prompt engineering” is a vague goal because it’s hard to judge completion status. A better goal would be:

In 30 days, be able to independently design, test, and optimize a set of prompt workflows for market research, and form reusable templates.

This goal includes time, capability, scenario, and deliverables. When Codex sees such a goal, it can generate targeted tasks.

A goal file should record at least seven types of information: current foundation, learning purpose, daily available time, final deliverable, usage scenario, main constraints, and success criteria.

For example, if you want to learn AI Agent design, the goal shouldn’t be “master Agent.” More suitable would be:

Goal: Complete a personal task-decomposition Agent within 30 days.
Background: Can use ChatGPT, know a little Python, no complete Agent project done.
Time: 60 minutes per day.
Deliverable: A runnable minimum project, a usage guide, a set of test cases.
Success criteria: Can input a complex goal, output an executable task decomposition, and handle insufficient information, task conflicts, and failure rollback.

The more specific the goal, the easier it is for the system to decide what to do today and whether you are truly improving.

2. Knowledge Map Module: Understand the Structure Before Going into Details

The most common problem for beginners learning an unfamiliar field is not learning too little, but diving into details too early.

For example, learning about Agents, many people immediately start studying frameworks, plugins, tool calls, and various paper terms. As a result, they see a bunch of concepts but don’t know their relationships, nor which content can be temporarily skipped.

The knowledge map is meant to solve scope and dependency issues. It needs to answer: What main problems does this field solve? What are the core modules? What dependencies exist between concepts? What must be mastered at the entry level? What content can be skipped first? Where are beginners most likely to misunderstand?

Taking Agent learning as an example, a more reasonable order might be:

Ordinary prompts
→ Multi-step workflows
→ Tool calls
→ Context management
→ State and memory
→ Output checking
→ Failure rollback
→ Agent evaluation

The value of this map is not to make you learn more, but to help you take fewer detours. It helps you control scope, understand dependencies, and avoid learning tools while lacking basics, while also being led astray by new concepts.

3. Route Module: Turn Learning Plans into Capability Upgrade Routes

An effective 30-day route should not be just a course catalog.

It should revolve around gradual capability upgrades.

A typical rhythm could be:

Days 1–7: Build global understanding, master basic concepts
Days 8–14: Train core skills, complete single-point exercises
Days 15–21: Combine multiple skills, push through a real project
Days 22–30: Test, fix, polish, and deliver the project

Daily tasks shouldn’t just say “read such and such material” or “understand this concept.” It should at least include: today’s goal, learning content, targeted practice, verifiable output, self-testing, project progress, and completion criteria.

For example, when learning “prompt constraint design,” the day’s task shouldn’t be just “read about prompt constraints.” A more effective task would be: find three ambiguous prompts, add input, output, and constraints to each, test with normal, edge, and stress scenarios, compare output stability before and after, save the best version to the prompt library, and record unresolved issues.

At that point, the learning outcome is no longer “I understand,” but “I completed a tested, reusable deliverable.”

4. Execution Module: Continue Daily from the First Uncompleted Step

The most common failure point in learning isn’t lack of planning, but the high cost of restarting each day.

Once you need to spend ten minutes recalling “what I did yesterday, where to start today, which file to update,” learning is easily interrupted.

With Codex’s execution module, the startup cost can be reduced to near zero. After entering the repository each day, let Codex first read progress.md and the current day’s task file, identify the first uncompleted step, and then proceed in a fixed rhythm.

You can use instructions like this:

Continue today's learning.
First read progress.md and today's task file,
identify the first incomplete step.
Do not generate all answers at once.
Proceed in the order of "explain – practice – check – record."
After completing, update:
1. progress.md
2. Today's task file
3. Exercise records
4. Mistake records
5. Project progress

Here is a key point: do not let AI generate all answers at once.

True learning requires the learner to think first, try first, and make mistakes first. Codex can explain, generate questions, check, and record, but it cannot complete all exercises on your behalf. Otherwise, you’ll end up with a beautiful set of files, not your own ability.

5. Feedback Module: Turn Mistakes into Input for the Next Round of Training

The quality of a learning system depends mainly on the feedback mechanism, not the plan itself.

A mistake should not just be recorded as “I was wrong here.” It should at least include: what the mistake is, which task it occurred in, how it was understood at the time, what the correct understanding is, the root cause, how to re-practice, and when to retest.

For example:

Mistake:
Understood an Agent's "memory" as saving the entire historical dialogue.

Reason:
Did not differentiate between working memory, long-term memory, and external state.

Correction:
Redraw the responsibility boundaries of the three memory types.

Retest task:
Design a minimal memory structure for a customer service Agent.

Retest time:
Two days from now.

The meaning of mistake recording is not to save failures, but to provide input for the next round of training.

If you keep making mistakes on the same concept, the system should lower difficulty, increase practice, adjust explanations, or postpone subsequent tasks. A good learning system won’t pretend the plan is always correct; it dynamically adjusts the route based on actual performance.

6. Project Module: Let Daily Learning Feed into a Real Deliverable

Learning projects cannot be left until the last few days.

If the goal is to learn Agent design, the final project could be a “personal task-decomposition Agent.” This project should enter the learning process from the first week.

Week 1: define the Agent’s goal, use scenario, and input/output. Week 2: design the task decomposition flow and prompt templates. Week 3: add tools, checking mechanisms, and failure rollback. Week 4: complete testing, documentation, and usage examples.

That way, each day’s learning produces project components: a knowledge map, a prompt template, a set of test cases, a tool definition, an error handling flow, a piece of runnable code, or a page of project documentation.

The final project is no longer an extra assignment after learning; it’s a natural outcome of the entire learning process.

5. Design Six Operating Modes for Codex

If you want the learning system to run stably, it’s recommended not to use vague commands in every conversation with Codex, but to preset several operating modes.

The clearer the mode, the easier it is for Codex to do the right thing.

BOOTSTRAP: Initialize the Learning Repository

This is the mode used when creating the learning system for the first time.

Codex needs to analyze the learning goal, identify existing foundations, build a knowledge map, generate a learning route, create a project plan, generate the first day’s tasks, and write the operating rules.

Example instruction:

I want to master the basic design methods of AI Agents within 30 days.
My background: can use ChatGPT, know a little Python, but haven't done an Agent project.
Daily available time: 60 minutes.
Final project: complete a personal task-decomposition Agent.

Please create a local learning repository,
including knowledge map, 30-day route, daily tasks, exercises, tests, mistake records, and final project.

DAILY_RUN: Execute Daily Learning

This is the most commonly used mode.

Codex reads the current state, finds the first incomplete step, and proceeds in the rhythm of “explain – practice – check – record.” The focus is not to generate a large amount of content at once, but to let the learner complete real exercises and outputs.

STAGE_TEST: Conduct Phase Tests

It is recommended to conduct a phase test every 7 days.

The test should cover at least: concept understanding, practical application, case analysis, project progress, and self-reflection. After the test, Codex should give a score, identify weak areas, update mistake records, generate reinforcement tasks, and adjust the next phase route.

PROJECT_BUILD: Advance the Final Project

This mode pushes forward one small deliverable at a time.

For example: complete one functional module, add a set of tests, modify one prompt, write one page of product documentation, fix one bug, polish one piece of documentation.

The advantage of incremental progress is that the project doesn’t become a last-minute rush. Learning gets closer to the deliverable every day.

REPLAN: Re-route Based on Actual Situation

Plans will inevitably be interrupted by reality.

Maybe time becomes scarce, goals change, or a certain topic is harder than expected. At this point, don’t regenerate a completely new plan, and even more importantly, don’t delete completed records.

The correct approach is to keep the history, reassess the current state, compress or adjust future tasks, retain core exercises and project outputs, and update milestones and completion criteria.

For example, if daily learning time drops from 60 to 30 minutes, you can reduce reading materials, but you shouldn’t remove exercises, tests, and reflections. These are often the parts that truly build ability.

EXPERT_ROOM: Handle Complex Sticking Points from Multiple Perspectives

When you encounter a complex problem, you can ask Codex to start a multi-role analysis.

For example, if you still cannot clearly distinguish Workflow from Agent, you can ask:

I still cannot accurately distinguish between Workflow and Agent.
Please start a multi-role analysis:
1. Domain expert explains the difference;
2. Socratic coach checks my understanding through questions;
3. Practical mentor designs a 20-minute exercise;
4. Project lead explains how they apply to my project;
5. Reviewer points out common misconceptions.

Finally, write the conclusion into the knowledge base,
and write the misunderstanding into mistake_book.md.

The value of this mode is to avoid AI giving only a “seemingly correct” explanation. Complex sticking points are often not hard because of the knowledge itself, but because your understanding, scenario, task, and judgment criteria are mixed together. Once separated from multiple perspectives, the problem is easier to locate.

6. Turn Learning Methods into System Actions

Many learning recommendations mention the Feynman technique, deliberate practice, spaced repetition, and Bloom’s taxonomy.

These methods themselves are fine, but the problem is that they often remain at the slogan level.

The truly effective approach is to translate methods into tasks that Codex can execute.

For the Feynman technique, don’t just write “understand this concept.” Have the learner complete a set of actions: explain in their own words, identify vague expressions, supplement a case, find loopholes in the explanation, then re-explain.

For retrieval practice, don’t let AI give the answer first. The learner should answer without checking materials first, then Codex compares, corrects, records, and schedules retests.

For spaced repetition, don’t just re-read notes. The system can generate different forms of testing after one day, three days, and seven days based on mistake records.

Bloom’s levels of ability can also directly enter task design:

Remember: can define
Understand: can explain
Apply: can solve a problem
Analyze: can compare and diagnose
Evaluate: can judge the pros and cons of a solution
Create: can use it in their own project

Ordinary concepts should at least reach “Apply”; project core knowledge should reach “Create.”

For example, if you learn about an “Agent’s failure rollback mechanism,” being able to explain the concept counts only as understanding. Being able to design a failure rollback flow for a customer service Agent counts as application. Being able to compare costs and risks of different rollback schemes counts as analysis and evaluation. Being able to write it into your own project and pass a test counts as creation.

Learning methods only truly change outcomes when translated into concrete actions.

7. Why a Learning System Must Have Automated Checks

Large models are very good at generating well-structured content.

But “looks complete” does not equal truly usable.

A learning repository might have a beautiful directory but lack key files; might have 30 days of tasks but some days have no practice; might have daily learning content but no clear output; might have tests but no mistake records; might have a final project plan but the project doesn’t start until the last few days.

These problems are easy to overlook if left to AI self-assessment.

Therefore, you should convert quality standards into executable checks as much as possible. For example, use scripts to check: whether directories and files are complete, whether daily tasks include goal, practice, output, and acceptance criteria, whether there is a phase test each week, whether the project starts early, whether each mistake has a retest task, whether learning time exceeds budget, and whether the final deliverable has documentation and usage examples.

The principle behind this is simple:

Don’t rely on AI alone to judge whether its output is adequate; establish external verification mechanisms as much as possible.

Software projects use tests to ensure code quality; personal learning systems can also use rules, checklists, and scripts to ensure learning quality.

If you use Codex to learn programming, this is especially natural. You can have it generate exercises and run tests; have it write project docs and check directory structures; have it summarize mistakes and generate retest tasks based on mistakes.

Once learning acquires engineering attributes, it no longer relies entirely on passion and discipline, but on system design.

8. The Right Division of Labor Between Human and AI

A Codex-based learning system is not about having AI replace the learner, but redefining the responsibilities of human and AI.

Codex is better suited for: decomposing goals, building knowledge structures, generating targeted exercises, maintaining files and progress, summarizing mistakes, adjusting learning routes, running checks, and organizing project documentation.

The learner must be responsible for: completing exercises personally, thinking before looking at answers, judging the reliability of AI outputs, providing real scenarios and constraints, making key decisions, taking responsibility for the final outcome, and forming their own explanations and methods.

The most dangerous way to learn is to have AI generate both questions and answers, complete the project, write summaries, and then treat all that as one’s own learning output.

That’s not AI-assisted learning; it’s AI-replaced learning.

A good learning system should increase the learner’s thinking density, not reduce the learner’s participation. AI can automate low-value tasks like organizing, scheduling, recording, and checking, freeing the learner from repetitive labor. But true understanding, judgment, trade-offs, and creation must still happen with the learner.

Otherwise, no matter how complete the repository is, it’s just a pile of files generated by AI.

9. From a 30-Day Plan to a Personal Capability Infrastructure

A truly valuable learning system should not end on day 30.

After the first cycle, you can continue into a new capability phase:

Cycle 1: Understand basics, complete minimal project
Cycle 2: Solve real cases, increase project complexity
Cycle 3: Package personal skills and standard workflows
Cycle 4: Build Agents or automation systems
Cycle 5: Form portfolio, product, or business delivery capability

Each cycle should inherit the knowledge map, mistake records, project results, test results, common templates, unresolved issues, and capability assessments from the previous cycle.

Over time, this repository will gradually evolve from a learning plan into a personal capability infrastructure.

It doesn’t just record what you’ve read; it reflects what you truly mastered, what tasks you can complete, where you repeatedly err, which training mode works best for you, what reusable outcomes you’ve accumulated, and what’s most worth learning next.

In the past, knowledge management mainly managed notes and materials.

In the AI era, a personal learning system should manage goals, tasks, practice, feedback, capability evidence, and project outcomes.

This is also why tools like Codex deserve to be re-understood. Their value is not just “help me write code,” but making personal capability growth something that can be organized, run, and iterated like a software project.

10. You Can Start with a Minimal Version

If you don’t want to build a full repository from the start, you can begin with a minimal version.

Just five files:

AGENTS.md        # Learning system operating rules
progress.md      # Current progress and status
knowledge_map.md # Knowledge map
daily_task.md    # Today's tasks
mistakes.md      # Mistakes and retest records

Then give Codex a start instruction:

Please treat this repository as my personal learning system.
Each time we start learning, first read AGENTS.md, progress.md, and daily_task.md.

You should:
1. Find the first incomplete task;
2. Proceed in the rhythm of "explain – practice – check – record";
3. Do not directly complete the exercises for me;
4. Check and probe my answers;
5. Write mistakes into mistakes.md;
6. After learning, update progress.md;
7. If the plan seems unreasonable, suggest adjustments, but do not delete historical records.

This minimal version can already solve many problems: no need to re-introduce background each time, no manual sorting of mistakes, no hunting for progress in a pile of chat records, and no worry that the learning plan is completely out of sync with actual execution.

Once it runs smoothly, gradually add routes, exercises, tests, project, and output directories.

Don’t pursue a perfect system from the start. First, get it running.

Conclusion: Don’t Just Use AI to Get Answers, Use AI to Build Abilities

AI has dramatically lowered the cost of obtaining answers.

But obtaining answers is not the same as obtaining ability.

What truly determines learning effectiveness is still whether goals are clear, tasks are specific, practice is sufficient, feedback is timely, mistakes are retrained, knowledge enters real projects, and outcomes are tested and delivered.

Codex’s value is not just helping people write code. With local files, project rules, command execution, testing mechanisms, and continuous context, it can become the execution engine for a personal learning system.

In this system, goals are written into the repository, tasks are continuously executed, practice produces real output, mistakes are permanently recorded, abilities are verified through tests, knowledge enters actual projects, routes adjust based on feedback, and outcomes are checked before delivery.

Learning thus no longer relies on scattered enthusiasm and short-term willpower, but begins to become an engineered system that can be designed, run, verified, and continuously optimized.

The truly competitive people in the AI era are not necessarily those who know the most answers.

But those who can, with the help of AI, continuously build new abilities and translate those abilities into real outcomes.