# You can go from zero to hireable AI engineer in 4 months. Here's the exact path.
**作者**: AI Guides
**日期**: 2026-07-07T16:32:16.000Z
**来源**: [https://x.com/free_ai_guides/status/2074531958600638877](https://x.com/free_ai_guides/status/2074531958600638877)
---
AI engineering is one of the best-paid, fastest-growing jobs in tech right now. And the door to it just got wider than it's ever been.
Most guides get this wrong. They hand you a wall of theory, tell you to master linear algebra and neural network math, and lose you by week two.
Or they bury you in 80 links with no order and no verdict, so you spend more time deciding what to study than actually studying.
I read through the popular roadmaps, tested the tools they recommend, and built the version I'd hand to a friend who's switching careers and has real work to do.
No math degree. No 4-year plan.
Four focused months, one clear pick per skill, real prompts you can copy, and the mistakes that quietly kill most career switches before they start.
Here's why I think the timing matters, then the full path.
## Why the door is open (and I can prove it)
You've probably been told AI is going to take jobs.
Here's the part that gets less airtime: it's creating a specific, well-paid category of job faster than almost anything else in the market, and the usual gatekeeper is falling away.
PwC's 2026 Global AI Jobs Barometer analyzed over a billion job ads across six continents. Three findings matter for anyone thinking about a switch.
First, jobs that require AI skills are growing about eight times faster than the overall market. AI-skill roles grew 69% while the total jobs market grew 9%.
That's not a rounding error. That's a category pulling away from everything around it.
Second, the pay premium is real and rising. Workers with AI skills command a 62% wage premium over comparable roles without them, up from 57% the year before.
Companies are paying more, not less, for people who can actually build with these tools.
Third, and this is the one that changes the math for career switchers: the degree requirement is falling, and it's falling fastest for exactly these roles.
PwC found that the share of AI-augmented jobs requiring a degree dropped from 66% to 59% between 2019 and 2024.
For jobs where AI automates parts of the work, it fell further, from 53% to 44%. Employers are dropping the credential filter faster in AI-exposed work than anywhere else.
There's one more number worth sitting with. In the US, entry-level roles most exposed to AI grew 35% since 2019.
Over the same period, other entry-level roles declined 10%. The bottom rung of the AI ladder is getting wider while the rest of the entry-level market shrinks.
Now the honest counterweight, because I'm not here to sell you a fantasy.
PwC also found that AI-exposed entry-level roles increasingly ask for skills that used to be reserved for senior people: judgment, communication, the ability to own an outcome instead of a task.
The bar isn't lower across the board. It moved. It's less "do you have the credential" and more "can you actually make this work and explain why it works."
Read that as bad news if you're a fresh graduate with no work history. Read it as good news if you're switching from another career, because you already have the thing they're now asking for.
You've shipped things. You've dealt with stakeholders. You've owned outcomes under pressure.
A 22-year-old with a CS degree usually hasn't. If you pair your existing judgment with the technical skills in this guide, you're not behind the new grads.
On the axis employers care most about, you're ahead of them.
That's the switcher's edge, and almost no roadmap tells you about it. Keep it in your back pocket for the whole four months. It's the reason this is realistic for you specifically.
A quick word on the money, because you'll want the real numbers before you commit four months.
I'll give the full breakdown at the end with sources, but the short version: as of mid-2026, Glassdoor puts the average US AI engineer salary at around $143,500, with a typical range of roughly $115,000 to $181,000.
Senior roles run much higher. Recruiters placing people in production AI work report mid-level base salaries clustering between $155,000 and $200,000.
These aren't hype figures pulled from a hype thread. They're current, and I'll show you where each one comes from.
## What an AI engineer actually does (the 60-second version)
Before the plan, let's kill the biggest source of intimidation, because it stops more people than any technical hurdle.
When most people hear "AI engineer," they picture someone in a lab training a giant model from scratch, surrounded by GPUs and math they'll never understand.
That's a different job. It's called a research scientist or an ML researcher, there are relatively few of them, and it usually does require the advanced degrees.
The AI engineer job that's growing eight times faster than the market is a different thing entirely.
You build products and features on top of models that already exist. You take Claude, or GPT, or an open-source model, and you make it do a specific, reliable job inside a real application.
In practice, that means you connect to model APIs, design the prompts and the context you feed them, get structured data back out, wire the model up to tools and databases, make it retrieve the right information, handle everything that can go wrong, and deploy it so real people can use it.
It sits between software engineering, product work, and applied AI. You're a builder, not a researcher.
Here's the one-line test I'd use. If you can make an LLM do a specific job reliably inside an app, and you understand enough to fix it when it breaks, you're an AI engineer. That's the whole thing.
Everything in this guide is aimed at getting you to that sentence being true about you.
You do not need to know how a transformer works internally. You do not need calculus. You do not need to be able to derive backpropagation.
You need to be a competent builder who understands how to work with these models in the real world.
That's a learnable skill, and four focused months is enough to get functional at it.
## Read this before Month 1: the 4 mistakes that kill career switches
I'm putting this before the roadmap on purpose.
Most guides bury the mistakes at the end, but the mistakes that end a career switch happen in week two, not month three. If you only remember one section of this guide, make it this one.
I've watched people, including an earlier version of me, make every one of these. None of them are about intelligence.
They're about strategy. Fix the strategy and the four months actually work.
Mistake 1: Starting with theory and math.
You get excited, you want to do this right, so you go find a machine learning course and start with linear algebra, gradient descent, and the math behind neural networks.
Three weeks later you've watched a lot of lectures, you can't build anything, and you feel like an impostor. So you quit.
The fix: skip it. For the job you're targeting, you don't need to derive the math.
You need to build.
You'll pick up the concepts you actually need as you hit them in real projects, and they'll stick because they'll be attached to something you built.
Theory-first is the single most common reason smart people wash out of this. Don't start there.
Mistake 2: Watching tutorials instead of building.
This one's sneaky because it feels like progress. You watch a four-hour Python course, nod along, feel like you learned something. You didn't.
You watched someone else learn something. The moment you open a blank file, none of it is there.
The fix: the 30-minute rule. For every hour you spend watching or reading, spend at least 30 minutes building something with no tutorial open.
Type the examples yourself. Break them. Change them. Get errors and fix them. The errors are the learning.
A person who builds badly for four months beats a person who watches perfectly for four months, every single time.
Employers can see the difference in ten seconds of looking at your GitHub.
Mistake 3: Learning tools instead of skills.
You hear that LangChain is the thing, so you go deep on LangChain.
Six months later the field has moved, everyone's on something else, and your LangChain knowledge feels wasted. So you chase the new tool.
Then that one changes too. You're always behind because you're optimizing for the wrong layer.
The fix: learn the skill under the tool. The skill of writing a prompt that produces reliable output doesn't expire when a framework updates.
The skill of getting structured data from a model, or evaluating whether your system actually works, or deciding when a task needs an agent versus a single call, those transfer across every tool that will ever exist.
Learn tools as a way to practice skills, not as the goal. This guide is organized around skills for exactly this reason.
Mistake 4: Waiting until you feel ready to build in public.
You decide you'll start sharing your work, applying for roles, or offering freelance services once you're "ready."
You will never feel ready. Ready is a feeling that arrives after you start, not before.
Meanwhile the people getting hired and getting clients are the ones who started sharing rough work months before they felt qualified.
The fix: start building in public in Month 1. Post the small thing you made. Write up what you learned.
Put every project on GitHub the day you finish it, even the ugly ones.
The gap between "I'm learning" and "I'm building visibly" is where most switchers get stuck for a year. Close it early.
Nobody is watching closely enough for your early work to embarrass you, and the compounding starts the day you begin.
Keep these four in view the whole way through.
The roadmap below is designed to avoid all of them by default: skill-first, build-first, tool-agnostic, public from day one.
## Month 1: Python and the plumbing
Your goal this month: become a functional Python developer who can call an API, manage a small project, and stop Googling basic syntax.
Not an expert. Functional.
Everything in Months 2 through 4 assumes you can write clean Python and work in a terminal. This is the foundation, and rushing it will hurt you later.
Here's the thing to internalize before you start: AI engineering is software engineering first. The AI part sits on top of a normal software stack.
If the stack underneath is shaky, the AI part never gets reliable. So Month 1 is about getting comfortable enough with the basics that they stop being in your way.
I'll give you one primary pick per skill, with a clear verdict on why. I'm deliberately not handing you five options per topic. Choice is the enemy of momentum.
Pick the one I point at, and only branch out if it genuinely isn't working for you.
Python
Python is the language of this entire field. Almost every library, API, tutorial, and job you'll touch over the next four months is in Python. You learn it, and everything else gets easier.
My pick: CS50P, Harvard's Introduction to Programming with Python. Free, rigorous, and it forces you to actually solve problems instead of watching someone else solve them.
The problem sets are the whole value. It's more demanding than a gentle YouTube course, and that's the point.
You want the version that makes you struggle a little, because the struggle is where the skill forms.
Find it at cs50.harvard.edu/python.
If CS50P feels too steep as an absolute beginner, the freeCodeCamp Python course on YouTube is a softer on-ramp, but treat it as a warm-up, not the main event.
Come back to CS50P once you're not scared of a blank file.
What to actually focus on, in rough order: variables and data types, loops and conditionals, functions, then the collection types (lists, dictionaries, sets, tuples).
Then file handling and reading and writing JSON, which you'll use constantly with AI APIs.
Then just enough classes and object-oriented basics to read other people's code without panic.
Then error handling with try and except.
Finally, virtual environments and pip, so you can install packages without breaking your system.
Don't try to memorize any of this. Understand it well enough to look it up fast, and build with it until it sticks.
Your Month 1 build target for Python: a small command-line tool that does something real.
An expense tracker that reads and writes to a JSON file is a good one. Or a script that calls a free public API and prints the results in a clean format.
Something with maybe 60 to 100 lines of your own code.
It doesn't matter if it's ugly. It matters that you wrote it.
## Learning with AI from day one
This is where I'd do something the old roadmaps don't: use AI to learn AI, starting in week one.
You have access to the best patient tutor ever built, and it costs nothing on the free tiers. When you hit an error you don't understand, don't spend 40 minutes on a forum.
Paste it into Claude or ChatGPT and ask it to explain the error in plain English and walk you toward the fix without just handing you the answer.
Here's a copy-paste prompt I'd set up on day one. Save it.
This is the first of several artifacts in this guide worth bookmarking.
Prompt: Your Python learning partner
(Framework: FAG Learning Partner, by AI Guides)
```
Your job: act as my patient Python tutor while I learn to code as a career switcher.
Context about me:
- I am learning Python to become an AI engineer.
- I am a complete beginner at coding but not at working hard.
- I learn best by doing, not by being handed answers.
What to do:
- When I paste an error, explain in plain English what it means and what
is likely causing it. Do not just give me the fixed code.
- Point me toward the fix with a hint first. Only show the full solution
if I ask twice.
- When I share code I wrote, tell me one thing that works and one thing
I could improve. Keep it to those two.
- After I get something working, ask me one short question that checks
whether I actually understood it.
Rules:
- No jargon without a one-line plain-English definition next to it.
- Assume I want to learn, not just pass. Slightly slower is fine.
- If I am about to build a bad habit, say so directly and kindly.
Output: conversational, short, one concept at a time.
```
Use that every day this month. It turns the frustrating parts of learning to code into a conversation instead of a wall.
It also gets you fluent at prompting, which is the core skill of Month 2, before you even know that's what's happening.
One caution so you don't build the wrong habit: use the AI to understand and unblock, not to write the whole thing for you.
If you let it write your code while you watch, you're back to Mistake 2.
Make it explain. You type.
Git and GitHub
Git is how developers save, version, and share code.
GitHub is where your work lives in public and becomes a portfolio.
You'll use both constantly, and for a career switcher, GitHub is the closest thing you have to a resume until you have one.
My pick: GitHub Skills. Free, interactive, and built by GitHub inside GitHub itself, so you learn the tool by using it. Start there rather than reading about Git in the abstract.
Find it at skills.github.com.
If the branching and merging model confuses you, and it confuses everyone at first, the Learn Git Branching visual tool makes it click by letting you see the branches move.
What to focus on: the core loop of init, add, commit, push, and pull. Then branching and merging.
Then what a .gitignore file does and why you never commit secrets or API keys to a public repo, which matters enormously once you're working with paid APIs.
Then how to write a basic README, because your READMEs are going to do real work in your job search later.
The habit to build this month: every project you touch, even a 20-line script, goes in a GitHub repo the day you make it.
This is Mistake 4's fix in practice. You're building in public, quietly, from the start.
By Month 4 you'll have a trail of work instead of a blank profile.
The terminal
You'll run scripts, install packages, and manage projects from the command line constantly.
Being slow or scared in the terminal is a real drag on everything else, and it's an easy thing to fix.
My pick: a short beginner terminal course to cover the basics, then just live in it. The MIT "Missing Semester" materials go deeper if you want them, but for Month 1 you only need navigation and running things.
Learn cd, ls, pwd, mkdir, and rm for moving around and managing files.
Learn cat and grep for reading and searching.
Learn how to run a Python script from the terminal and how to set an environment variable, which you'll need the moment you're handling API keys.
You don't need to become a shell wizard. You need to stop hesitating.
A week of using the terminal for everything, even things you'd normally do with a mouse, gets you there.
APIs, JSON, and HTTP
This is the bridge to Month 2.
From the first day of building with LLMs, you'll be making API calls, which means you need to understand how web APIs work before you touch OpenAI's or Anthropic's tools.
My pick: the MDN Web Docs HTTP overview for the concepts, plus the Python requests library documentation for doing it in code.
MDN explains how requests and responses work more clearly than anything else that's free.
Then requests shows you how to make those calls in Python in a few lines.
What to focus on: what GET and POST requests are and how to make them in Python.
Reading and writing JSON, which is the format every AI API speaks.
HTTP status codes and what the common ones mean, especially 200 for success, 401 for a bad API key, 429 for rate limiting, and 500 for a server error, because you'll see all of these constantly.
What an API key is and how basic authentication works.
And a light introduction to what async and await do in Python, which you'll need when you start streaming responses from models later.
Don't go deep on async now.
Just know it exists and roughly what problem it solves.
Your build target here: a Python script that calls a free public API, one that needs no key like the Open-Meteo weather API, and prints the result as clean formatted output.
This is a tiny version of exactly what you'll do all through Month 2, just without the AI part yet.
A quick note on SQL
You don't need to be a data person, but you'll regularly need to look at and query data, and basic SQL saves you constantly.
My pick is SQLBolt, which is free, interactive, and teaches you the core of SQL in about 20 short in-browser lessons.
Find it at sqlbolt.com.
Focus on SELECT, WHERE, GROUP BY, JOIN, and ORDER BY.
That's enough for now.
You can go deeper the moment a project demands it.
Month 1 milestone
By the end of the month, you should be able to write a Python program that reads and writes files, calls an API, and handles its own errors without crashing.
You should version that code with Git and have it live in a GitHub repo.
You should move around the terminal without hesitating. You should understand what an HTTP request is and make one in Python.
And you should be able to run a basic SQL query.
If you can do those things, you have the foundation.
Most people who quit never get here, and getting here is genuinely the hardest part because it's the least exciting.
It gets more fun from Month 2 on, because from here you're building with AI.
## Month 2: Build with LLM APIs
Your goal this month: build real AI-powered features using model APIs.
By the end, you should be comfortable writing prompts that produce reliable output, getting structured data back from a model, making the model call your own functions, managing a conversation, and handling everything that can break.
This is the core of the whole job. Everything after this builds on it.
This is the month where it starts to feel real. You stop doing setup and start making models do things.
Take your time here.
Depth in Month 2 pays off more than depth anywhere else in the guide.
Prompting that actually works
Prompting isn't asking a chatbot a question nicely.
It's the skill of writing instructions that produce consistent, reliable output from a system that's fundamentally probabilistic.
As an AI engineer, you'll spend more time here than you'd expect, and getting good at it is the highest-leverage thing you can do this month.
My pick: Anthropic's interactive prompt engineering tutorial on GitHub. It's the most hands-on resource that exists, broken into chapters with real exercises you run against the Claude API.
You practice writing and fixing prompts yourself instead of reading about it, which, if you remember Mistake 2, is the entire point.
Find it in the anthropics/prompt-eng-interactive-tutorial repo. Once you've worked through it, Anthropic's and OpenAI's official prompt engineering docs are the reference you'll come back to.
What to focus on: the difference between a system message and a user message, and why that difference matters.
Why specificity beats politeness every time.
Chain-of-thought prompting, where you ask the model to reason step by step before answering, which measurably improves results on anything with logic in it.
Using examples inside your prompt, called few-shot prompting, to show the model the format you want.
And developing a feel for how small wording changes produce large output changes, which only comes from doing it a lot.
A build exercise that teaches this fast: take one real task, like summarizing a document or classifying a piece of feedback, and write five different prompts for it.
Run all five.
Compare the outputs side by side. You'll see immediately how much prompt design drives reliability, and that lesson sticks better than any lecture.
Structured outputs
In a real application, you almost never want a paragraph of text back from a model.
You want structured data your code can parse, store, and use. Structured outputs solve this by forcing the model to return data that matches a schema you define.
This is one of those skills that separates a demo from something that actually works inside software.
My pick: the Instructor library for Python, backed by OpenAI's and Anthropic's official structured output docs.
Instructor is the cleanest way to get structured data out of any major model using Pydantic, which is a Python library for defining the shape of your data.
It works across providers with the same code and retries automatically when the model returns something malformed.
It's close to what a lot of working engineers actually use, which makes it worth learning on real projects rather than a toy version.
What to focus on: defining a Pydantic model that describes the data you want, passing that schema to the API, and handling the case where the model refuses or returns something unexpected.
Understand the difference between true structured outputs, where the schema is enforced, and looser JSON mode, where it isn't guaranteed.
Here's your second bookmarkable artifact, a prompt pattern for reliable structured extraction that works even before you add a library on top.
Prompt: Structured data extraction
(Framework: FAG Extractor, by AI Guides)
```
Your job: extract structured data from the text I provide and return it
as clean JSON.
What to do:
- Read the input text carefully.
- Pull out only the fields listed under Output below.
- If a field is missing from the text, use null. Do not guess or invent.
- Return only the JSON object. No explanation, no markdown, no preamble.
Rules:
- Every value must be traceable to something in the input text.
- Dates in YYYY-MM-DD format. Numbers as numbers, not strings.
- If the text is ambiguous, prefer null over a confident wrong answer.
Output: a JSON object with these fields:
{
"field_one": string or null,
"field_two": number or null,
"field_three": list of strings or empty list
}
Input text:
[PASTE THE TEXT HERE]
```
The tested-failure note, because I promised you the honest version: the first time you do this, the model will sometimes wrap the JSON in markdown code fences, or add a friendly sentence before it, and your parser will choke.
That's normal. The fix is to strip code fences before parsing, and to be explicit in the prompt that you want only the JSON object, which the pattern above does.
Once you've hit this once and handled it, you'll handle it forever.
Your build target: a receipt or invoice parser.
Feed it raw messy text like "Invoice 123, $45.99 for 3 widgets, due March 30" and get back a clean structured object with the invoice number, amount, item count, and due date.
This is a genuinely useful little tool and a good portfolio piece.
Tool calling
Tool calling is what turns a text generator into something that can take actions: search the web, query a database, call your API, run code.
It's one of the most important skills in this whole guide, and it's the foundation of everything in Month 3.
The mental model that makes it click: the model doesn't run your functions.
It looks at the conversation, decides a tool should be used, and returns a structured request naming the function and the arguments.
Your code runs the function and hands the result back to the model. The model is the decision-maker. Your code is the hands.
My pick: OpenAI's function calling guide and Anthropic's tool use docs, read together.
The concepts are identical across both, the syntax differs slightly, and seeing both makes the underlying pattern obvious.
Then work through a runnable notebook example, like the one in the OpenAI cookbook, so you see the full loop end to end instead of in pieces.
What to focus on: describing your functions clearly in a schema, parsing the model's tool-call response, running the function and feeding the result back, and handling the case where the model decides no tool is needed.
The quality of your tool descriptions matters more than beginners expect, which is a theme that comes back hard in Month 3.
Your build target: a small assistant with three tools, like get_weather, calculate, and search_notes where search_notes just looks through a hardcoded dictionary.
Wire them all up and watch the model decide which one to call based on what you ask.
The moment you see it pick the right tool on its own, the concept lands permanently.
Conversation state and streaming
Two smaller but essential skills round out the month.
Models have no memory between calls. A conversation is something you manage by sending the full message history with every request.
Understanding this is fundamental, and it surprises almost everyone at first.
My pick is OpenAI's and Anthropic's messages documentation.
Focus on how the messages array is structured, why you append both the user's messages and the model's replies, what happens when you exceed the context window, and basic strategies for trimming old messages.
Build a simple multi-turn terminal chatbot that keeps history and has a reset command. It's small and it teaches the concept completely.
Streaming means showing the model's output as it's generated, word by word, instead of making the user wait for the whole thing.
It makes apps feel dramatically faster.
My pick is the official streaming docs from either provider, plus Simon Willison's clear write-up of how streaming works underneath.
Focus on setting the stream option, iterating over the chunks, and assembling the full response from the pieces.
For anything a real person will use, streaming is almost always the right call.
Nobody wants to stare at a spinner for ten seconds.
Cost, failure, and one security idea
Three things that separate a hobby project from something you'd put in front of users.
Cost and tokens: models charge per token, which is roughly three-quarters of a word.
Input and output tokens are priced differently.
Learn to estimate what a request will cost before you send it, keep the provider pricing pages bookmarked, and internalize one rule that saves real money: don't use the biggest, most expensive model for simple tasks.
A cheaper model is often more than good enough, and the cost difference at scale is enormous.
Failure handling: APIs fail.
Rate limits get hit, requests time out, the model returns malformed output.
Handling this gracefully is what makes something production-ready.
Learn to catch rate-limit errors and retry with a growing delay between attempts, called exponential backoff.
The Tenacity library in Python does this with a single decorator.
Learn to validate the model's output before you trust it, and never let an unexpected response crash your whole app.
Prompt injection, briefly: this is the top security risk in LLM apps.
It happens when untrusted user input gets combined with your instructions, letting a user override or hijack what your system does.
You don't need to become a security expert this month, but you need to know it exists before you ship anything.
The OWASP guide on it is the authoritative reference.
The core defenses: don't trust unvalidated model output to take consequential actions automatically, and give your tools the least access they need to do their job.
Month 2 milestone
By the end of the month, you should be able to write prompts that produce reliable output for a given task, get structured JSON out of a model with Pydantic and Instructor, wire up tool calling so a model can run your Python functions, stream a response in real time, manage multi-turn conversation history, estimate the token cost of a request before sending it, handle API errors and bad output without crashing, and explain what prompt injection is.
That's a real, employable skill set on its own.
Plenty of paid AI features in production do exactly this and no more.
But the next month is where you build the thing that actually gets you hired.
## Month 3: RAG and agents, the skills that get you hired
Your goal this month: build systems that let models answer from your documents instead of only their training data, and build systems that take multiple steps on their own.
These two skills, retrieval and agents, are the most in-demand practical abilities in AI engineering right now.
Almost every real company use case, from support bots to internal knowledge tools to document analysis, is built on them.
I've compressed what a lot of roadmaps spread across two months into one, because you don't need to master every advanced variation to be employable.
You need to build one solid retrieval system and one solid agent, understand why each piece is there, and be able to debug them when they break.
That's the bar. Let's hit it.
RAG, in plain English first
RAG stands for retrieval-augmented generation.
Strip the jargon and it's simple: you give the model a library to look things up in, so it doesn't have to have memorized everything, and so it can answer questions about your specific documents.
The flow is: you take your documents, break them into chunks, convert each chunk into a list of numbers that captures its meaning, and store those.
When a user asks a question, you convert their question into numbers the same way, find the chunks whose numbers are closest, and hand those chunks to the model along with the question.
The model answers using what you gave it. That's RAG. Everything else is refinement.
Let's build up the pieces.
Embeddings
An embedding is a piece of text turned into a long list of numbers that represents its meaning.
The useful property: text that means similar things ends up with similar numbers, close together in this number-space.
That closeness is what makes search-by-meaning possible, which is the engine under RAG.
My pick for building the intuition: the Stack Overflow blog's intuitive introduction to text embeddings, which focuses on the mental model rather than the math, plus OpenAI's embeddings guide when you're ready to generate them in code.
Focus on understanding what a vector is conceptually, why similar text produces similar vectors, and roughly how you measure the distance between two of them.
You do not need the math behind how embeddings are produced. You need to know how to use them.
A tiny build that teaches this completely: take 20 sentences on related topics, turn each into an embedding, and write a small function that, given a new sentence, returns the three most similar from your set.
That's RAG in miniature. Once you've built this, the full version is just the same idea at scale.
Chunking
Your documents are too big to embed whole, so you break them into chunks before embedding.
How you chunk directly controls how well your system finds the right information.
Even a perfect retrieval setup fails if the underlying chunks are bad.
My pick: start with LangChain's RecursiveCharacterTextSplitter, with a chunk size around 500 characters and an overlap around 50.
That overlap matters, because it stops you losing meaning at the boundary where one chunk ends and the next begins.
This is the sensible default that gives you a working baseline.
The core trade-off to hold in your head: chunks too big lose precision, chunks too small lose context.
Start with the default, then adjust based on what your retrieval is actually getting wrong.
Vector databases
Once you have embeddings, you need somewhere to store and search them fast. That's what a vector database does.
My pick for learning: Chroma. It runs locally with no infrastructure to set up, which is exactly what you want while you're learning.
You don't need managed cloud scale yet, and adding it early just gives you more to configure and break.
Chroma lets you focus on the concepts.
Find it at docs.trychroma.com.
Learn to create a collection, insert embeddings along with metadata like the source and section, query by similarity to get the top matches, and filter by metadata at query time.
You do not need to understand the indexing algorithms underneath. You need to use them.
When you eventually need production scale, pgvector is the natural next step if your app already uses a Postgres database, and there are managed options when you want someone else to run it.
But that's a Month 4 or on-the-job concern. For now, Chroma, locally, is enough.
Making retrieval actually good
Basic similarity search gets you a demo.
A few refinements get you something that works reliably, and knowing these is what separates people who copied a tutorial from people who understand the system.
Metadata filtering: tag every chunk with useful information when you store it, like the source file, the date, the section, or the category.
Then filter on those at query time. This is the difference between a toy and a system where a user can ask "only show me results from the Q4 report" and actually get them.
Reranking: your first search is fast but approximate.
A reranker takes the top handful of results and re-scores them for true relevance to the question, which noticeably improves quality for a small speed cost.
The pattern is: retrieve a broad set quickly, then rerank down to the best few. Cohere's reranking docs are the cleanest place to learn this, and it's often one line to add.
Debugging retrieval, because most RAG failures are retrieval failures, not model failures.
When your system gives a bad answer, the model usually isn't the problem.
The retrieval handed it the wrong chunks.
Learn the common failure modes: the question and the relevant chunk don't match in number-space even though the info is there (fixable by rewriting the query), the relevant info is split across two chunks (fixable with more overlap), or the right chunk exists but didn't make the top results (fixable by retrieving more, then reranking down).
When an answer is wrong, check what got retrieved before you blame the model. This one habit will save you enormous frustration.
Grounding and citations: a good RAG system doesn't just answer, it tells you where the answer came from, which builds trust and makes debugging far easier.
Pass the source information for each chunk into your prompt, and instruct the model to cite it.
Here's your third artifact, the grounding prompt that keeps a RAG system honest.
This is the one I'd bookmark above all the others, because it's the difference between a system that makes things up and one you can trust.
Prompt: Grounded RAG answering
(Framework: FAG Grounding, by AI Guides)
```
Your job: answer the user's question using only the provided context.
What to do:
- Read the context chunks below. Each has a source label.
- Answer the question using only information found in the context.
- After each claim, cite the source label it came from, like [source: filename, p.3].
- If the context does not contain the answer, say exactly:
"I don't have enough information in the provided documents to answer that."
Rules:
- Never use knowledge from outside the provided context.
- Never guess. Never fill gaps with what sounds plausible.
- If the context partly answers the question, answer that part and say
clearly what is missing.
Context:
[PASTE RETRIEVED CHUNKS WITH SOURCE LABELS HERE]
Question:
[USER QUESTION HERE]
```
That "say exactly this when you don't know" instruction is doing heavy lifting. It's the single most effective way to cut hallucinations in a retrieval system, because it gives the model an approved way to admit ignorance instead of inventing an answer to seem helpful.
Your RAG build
Use a framework to tie this together rather than building every piece from scratch.
My pick for a first RAG system is LlamaIndex, which is built search-first and gets you a working pipeline in a short amount of code.
LangChain is the other major option and shines more for the multi-step agent work coming next, so you'll meet it in a moment.
Your build target, and this is a real portfolio piece: a "chat with your documents" app.
Ingest 10 to 20 PDFs or text files, your own notes or a set of product docs work well, build something that takes a question, retrieves the most relevant chunks with reranking, and returns a cited answer.
Put a simple interface on it.
This is the project that makes hiring managers take you seriously, because it's exactly the kind of thing companies are paying to have built right now.
Agents
Halfway through the month, shift to agents.
An agent sounds like magic and is genuinely simple once you see it: it's a loop where the model repeatedly decides the next step, takes it using a tool, looks at the result, and decides again, until the task is done.
The mental model: an agent is a while loop with a model making the branching decisions.
The thinking happens in the prompt. The branching is the model choosing which tool to use. The doing is your code running that tool.
Everything else is plumbing. Once that clicks, even complicated agent frameworks become readable.
My pick, and I'd read this before writing a single line of agent code: Anthropic's "Building Effective Agents."
It's the clearest writing on how agents work in practice, from the team that builds the models.
Pair it with a hands-on framework course when you're ready to build, like the intro to LangGraph, which is the most widely used framework for orchestrating agents.
What to focus on: the loop of perceive, decide, act, observe, and how it knows when to stop.
What happens when a tool call fails inside the loop. How to write tool descriptions the model can actually use, because a vaguely described tool gets called wrong or ignored.
And managing state, which is the shared memory that flows through the agent as it works.
The single most valuable exercise this month: build a small agent from scratch with no framework at all, using just the model API directly.
Give it three tools, a goal, and a loop. This teaches you what the frameworks are hiding, and it makes every framework you touch afterward make sense.
Do this before you touch LangGraph.
When not to use an agent
This is one of the most overlooked skills in the field, and knowing it marks you as someone with judgment rather than someone chasing the shiny thing.
Agents are exciting, and they're also slower, more expensive, less predictable, and harder to debug than simpler approaches.
Reaching for the simplest thing that works is a sign you know what you're doing.
The decision framework, worth memorizing: use a single model call if the task fits in one prompt with the right context.
Use a fixed workflow, a chain of steps you define, if the steps are predictable.
Use an agent only when the number of steps is genuinely unpredictable and needs the model to decide dynamically.
A chain of three fixed calls will always be faster, cheaper, and easier to debug than an agent that might make three calls. Reserve agents for genuinely open-ended tasks.
Between a single call and a full agent is a large, productive middle ground: workflows.
Chaining, where one call's output feeds the next.
Routing, where you classify the input and send it to a specialized handler.
Parallelization, where you run several calls at once and combine them.
Most real problems are best solved with a workflow, not an agent, and Anthropic's agents piece covers these patterns well.
Evals, briefly but seriously
You need to know whether your system actually works, not just whether it worked on the two examples you tried by hand.
That's what evaluations are for. Build a small set of 20 to 30 representative inputs with expected outputs or a scoring rubric, and run your system against all of them whenever you change a prompt, swap a model, or adjust your retrieval.
Tools like DeepEval for general use and Ragas for RAG specifically make this manageable.
The mindset that matters more than the tool: every prompt change or model swap you make without running evals is a gamble.
The people who ship reliable AI run evals constantly, and starting this habit now, even in a small way, puts you ahead of a lot of people already working in the field.
Month 3 milestone
By the end of the month, you should be able to explain what an embedding is and why similar text produces similar vectors, chunk a document sensibly, store and query embeddings in a vector database with metadata filtering, add reranking to improve results, debug a retrieval failure instead of blaming the model, build a complete RAG pipeline that returns grounded cited answers, implement an agent loop from scratch, decide correctly whether a task needs a single call, a workflow, or an agent, and run a basic eval to check your work.
That's the employable core.
If Months 1 through 3 are solid, you can build the things companies are hiring for.
Month 4 is about proving it and getting paid.
## Month 4: Ship it, show it, get hired
Your goal this month: take everything you've built and make it real, then turn it into a job or paid work.
This is where most people stall.
They can build a demo but can't ship something that survives real use, and they can't convert their skills into income.
This month fixes both. It's shorter on new concepts and heavier on doing, because at this point doing is what matters.
Enough deployment to be dangerous
You don't need to become an infrastructure expert.
You need to be able to put a working AI app somewhere real people can use it, without it falling over or bankrupting you.
The minimum viable knowledge: learn enough Docker to package your app so it runs the same everywhere, which kills the "works on my machine" problem.
Learn to deploy that container somewhere.
And learn the cost and reliability basics that stop a bug from becoming a disaster: set hard spending limits on your API accounts, add caching so you're not paying for the same request twice, and add rate limiting so one user can't run up your bill.
Docker's official getting-started guide covers the packaging.
For the AI-specific cost side, the core moves are caching identical requests, using cheaper models where they're good enough, and setting a hard monthly spend cap so a runaway loop can't cost you $500 overnight.
You also want basic observability, which is a fancy word for being able to see what your app is doing.
LLM apps have a specific problem: the model can return a perfectly successful response that's also useless or wrong, and normal monitoring won't catch that.
A tool like Langfuse traces every model call, showing you the prompt, the response, the token cost, and the latency, which makes debugging and cost control far easier.
Set this up on one project so you understand the pattern.
Don't over-invest here.
One app, deployed properly, with cost controls and basic tracing, teaches you everything you need and gives you something real to show.
Depth in deployment can come on the job.
The part every other roadmap skips: turning projects into a job.
You've built three real projects. Now make them work for you, because a great project nobody sees does nothing for your career.
Your portfolio is three deployed projects, each with a README that does actual work.
And here's the move almost nobody makes, the one that will set you apart: in each README, include a section on what went wrong and what you'd do differently.
Most portfolios pretend everything worked perfectly, which reads as either dishonest or shallow.
A README that says "here's where my first approach failed, here's what I learned, here's how I fixed it" signals exactly the judgment employers said they're now screening for.
It's the switcher's edge from the intro, made visible.
Nobody expects a career switcher to have a perfect project. They're impressed by one who clearly understands their own work deeply enough to critique it.
Structure each README like this: the problem the project solves, who would use it, the approach you took and why, what went wrong and what you learned, and how to run it.
Five sections.
That's a better portfolio than most people with a CS degree have.
The resume and profile move: you don't need to pretend you have years of experience.
You need one clear line that says what you can do.
Something like "I build production LLM applications: RAG systems, agents, and API integrations. Here are three I've shipped."
Then link the projects. Your existing career is an asset, not something to hide.
"Former [your field] who now builds AI systems" is a stronger story than "junior developer," because it comes with the domain knowledge and judgment that a pure junior lacks.
If you're switching from finance, you understand finance problems an AI could solve.
If you're switching from healthcare, same. Lean into it.
Building in public as your pipeline: through this whole month, keep posting what you build and what you learn.
The best opportunities I've seen come to people who were visible, not to people who quietly applied to 500 listings.
Write up your projects. Share the mistake you fixed. The compounding is real, and by now you have real work to share, so it's easier than it was in Month 1.
Pick a direction
By Month 4 you can point your skills at whatever fits your goals. Three directions, pick one to go deeper on rather than spreading thin.
The AI product engineer path, best if you want a startup job fast: you build AI-powered products real users touch.
You already have most of this from Months 1 through 3.
Go deeper on building complete, polished apps and on the product side, meaning how the app handles the model being wrong, how it shows loading states, how users give feedback.
Ship two or three things people can actually try.
The applied ML path, best if you want deeper technical roles: go beyond API calls into fine-tuning, when to fine-tune versus just prompt better, running open-source models locally with a tool like Ollama, and inference optimization.
The decision framework to hold onto: start with prompting, add retrieval if the model needs your specific data, and only fine-tune when prompting and retrieval genuinely can't hit the quality you need.
Fine-tuning is often reached for too early.
The AI automation path, best if you want to earn from businesses immediately: focus on automating real business workflows, chaining AI across tools like email, CRMs, documents, and spreadsheets.
Tools like n8n for visual workflows and LangGraph for the code-heavy ones.
A sellable build here: a lead-qualification system that pulls in leads, uses a model to research and score each one, drafts personalized outreach, and logs everything.
Businesses pay real money for exactly this.
Month 4 milestone
By the end of the month, you should have a deployed AI app with proper cost controls, three portfolio projects each with an honest README, a clear one-line pitch of what you build, a visible trail of work in public, and a chosen direction you're going deeper on.
At that point you're not "someone learning AI." You're someone who ships AI systems, which is the thing the market is paying for.
## The honest part
I told you at the start I wasn't going to sell you a fantasy, so here's the straight version before the money numbers.
Four months of focused work makes you employable at a junior level or ready to take freelance work. It does not make you a senior engineer.
Senior comes from years of shipping real things under real constraints, and no guide compresses that.
What four months buys you is the ability to build, ship, and deploy AI systems that solve real problems, which is a genuinely valuable and genuinely hireable place to be.
This assumes real work, roughly 15 to 20 hours a week, actually building and not just watching.
If you can only give it 7 hours a week, this is an 8-month path, and that's completely fine.
The timeline stretches, the destination doesn't change. What kills people isn't a slow pace. It's stopping.
Consistency beats intensity here every time.
And the whole thing rests on one behavior from the mistakes section: build, don't just watch.
Every month has a project. Do the projects. A person who builds four rough projects in four months is employable.
A person who watches four months of perfect tutorials is not. That's the entire game.
The money, with sources
Now the numbers you actually want, all current and all sourced, because loose salary claims are how these guides lose credibility.
As of June 2026, Glassdoor puts the average US AI engineer salary at roughly $143,500, with a typical range of about $115,000 at the 25th percentile to $181,000 at the 75th, and top earners reported up to around $223,000.
Senior AI engineers average around $285,000, with a typical range of roughly $221,000 to $375,000, which shows how steep the jump is once you have real experience.
Those are Glassdoor's figures based on submitted salaries.
Recruiters who place people in genuine production AI work report mid-level base salaries clustering between $155,000 and $200,000, based on signed offers rather than surveys, which lines up with the Glassdoor range and gives you a second independent read.
And the broader market backdrop from PwC's 2026 Barometer, which I opened with: AI-skill jobs growing about eight times faster than the overall market, a 62% wage premium for AI skills, and degree requirements falling fastest in exactly these roles.
Those aren't from a hype thread. They're from an analysis of over a billion job ads.
Freelance and consulting numbers vary too much to quote precisely without misleading you, so I'll say only this: the rates for RAG implementation, agent building, and LLM integration are high, and a switcher with three solid deployed projects and a clear pitch can start charging for that work well before they'd land a full-time role.
The projects are the proof. Build them and the earning options open up.
## Start this week
Here's what I'd actually do, today, if I were you.
Pick the Month 1 Python project, the little command-line tool. Open a code editor.
Start CS50P's first problem set. Set up the learning-partner prompt so the AI tutors you through the frustrating parts.
Make a GitHub repo and put your first ugly file in it. That's the whole first week.
Don't wait until you feel ready, because ready comes after you start, not before.
Don't map out all four months in perfect detail before you write a line of code, because the plan is already here and the planning is just a comfortable way to avoid starting.
The gap between learning and building is where people lose a year. Close it this week.
Four months of real work genuinely changes what's possible for you.
The door is more open than it's been at any point before now, the credential barrier is falling, and the market is paying more for these skills than almost anything else in tech.
You have the guide. The only variable left is whether you build.
Save this and come back to it each month as you go. I'll keep it updated as tools and numbers change.
Follow @free_ai_guides for the updates ❤️
## 相关链接
- [Machina reposted](https://x.com/EXM7777)
- [AI Guides](https://x.com/free_ai_guides)
- [@free_ai_guides](https://x.com/free_ai_guides)
- [197K](https://x.com/free_ai_guides/status/2074531958600638877/analytics)
- [cs50.harvard.edu/python](http://cs50.harvard.edu/python)
- [skills.github.com](http://skills.github.com/)
- [docs.trychroma.com](http://docs.trychroma.com/)
- [@free_ai_guides](https://x.com/@free_ai_guides)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:32 AM · Jul 8, 2026](https://x.com/free_ai_guides/status/2074531958600638877)
- [197.8K Views](https://x.com/free_ai_guides/status/2074531958600638877/analytics)
- [View quotes](https://x.com/free_ai_guides/status/2074531958600638877/quotes)
---
*导出时间: 2026/7/29 21:52:11*
---
## 中文翻译
# 你可以在 4 个月内从零基础成长为受聘的 AI 工程师。以下是确切的路径。
**作者**: AI Guides
**日期**: 2026-07-07T16:32:16.000Z
**来源**: [https://x.com/free_ai_guides/status/2074531958600638877](https://x.com/free_ai_guides/status/2074531958600638877)
---
AI 工程是目前科技界薪酬最高、增长最快的工作之一。而进入这扇大门的门槛，现在比以往任何时候都要低。
大多数指南都搞错了方向。它们塞给你一大堆理论，让你先掌握线性代数和神经网络数学，结果在第二周就让你望而却步。
或者，它们用 80 个毫无顺序和结论的链接把你埋没，导致你花在决定“学什么”上的时间比实际学习的时间还多。
我通读了流行的路线图，测试了它们推荐的工具，并构建了一个我会交给正在转行且有实际工作要做的朋友的版本。
不需要数学学位。不需要 4 年规划。
专注的四个月，每项技能一个明确的选择，可以直接复制的真实提示词，以及那些在大多数人开始之前就悄无声息地扼杀转行之路的错误。
以下是我为什么认为时机很重要的原因，以及完整的路径。
## 为什么大门敞开（而且我可以证明）
你可能听说过 AI 将会取代工作。
这里有一个较少被提及的部分：它正在创造一种特定的、高薪的工作类别，其速度比市场上几乎所有其他事物都要快，而且传统的守门人正在消失。
PwC 的 2026 年全球 AI 就业晴雨表分析了六大洲超过 10 亿条招聘广告。有三个发现对于任何考虑转行的人都很重要。
首先，需要 AI 技能的工作增长速度大约是整个市场的 8 倍。AI 技能岗位增长了 69%，而整个就业市场仅增长了 9%。
这四舍五入的误差。这是一个正在拉开与其他领域差距的类别。
其次，薪资溢价是真实存在的且在上升。拥有 AI 技能的工人比没有该技能的同类职位薪资高出 62%，高于前一年的 57%。
公司愿意为那些真正能使用这些工具的人支付更高的费用，而不是更低。
第三，这对转行者来说改变了游戏规则：学位要求正在下降，而且恰恰是在这些岗位上下降得最快。
PwC 发现，在 2019 年至 2024 年间，需要学位的 AI 增强型工作岗位占比从 66% 下降到了 59%。
对于 AI 自动化部分工作的岗位，这一比例下降得更多，从 53% 降至 44%。雇主在 AI 相关工作中放弃学历筛选的速度比其他任何地方都要快。
还有一个值得关注的数字。在美国，自 2019 年以来，受 AI 影响最大的入门级岗位增长了 35%。
在同一时期，其他入门级岗位下降了 10%。AI 梯子的最底层正在变宽，而其他入门级市场正在萎缩。
现在说一个诚实的反面观点，因为我不是来这里向你推销幻想的。
PwC 还发现，受 AI 影响的入门级岗位越来越要求那些以前留给资深人员的技能：判断力、沟通能力，以及能够对结果负责而不是对任务负责的能力。
门槛并没有全面降低。它转移了。它不再问“你有这个证书吗”，而是问“你真的能让这东西运转起来并解释为什么它有效吗”。
如果你是一个没有工作经验的应届毕业生，把这读作坏消息。如果你是从其他职业转行过来的，把这读作好消息，因为你已经拥有他们现在要求的东西了。
你交付过产品。你处理过利益相关者的关系。你在压力下对结果负责过。
一个拥有计算机科学学位的 22 岁年轻人通常没有这些经历。如果你将现有的判断力与本文中的技术技能结合起来，你并没有落后于新毕业生。
在雇主最关心的轴线上，你领先于他们。
这就是转行者的优势，几乎没有任何路线图会告诉你这一点。在这四个月里把它放在你的后口袋里。这就是为什么这对你来说是现实的。
简单说一下钱，因为你在投入四个月之前会想要真实的数字。
我会在最后给出包含来源的详细细分，但简短版本是：截至 2026 年年中，Glassdoor 显示美国 AI 工程师的平均薪水约为 143,500 美元，典型范围大致在 115,000 美元到 181,000 美元之间。
资深角色的薪水要高得多。负责安排从事实际生产 AI 工作的人员的招聘人员报告称，中级基础薪水集中在 155,000 美元到 200,000 美元之间。
这些不是从炒作帖子中提取的数字。它们是当前的，我会向你展示每一个数字的来源。
## AI 工程师实际上做什么（60 秒版本）
在开始计划之前，让我们消除最大的畏难情绪，因为它阻止的人比任何技术障碍都多。
当大多数人听到“AI 工程师”时，他们脑海中浮现的是一个人在实验室里从零开始训练一个巨大的模型，周围是 GPU 和他们永远无法理解的数学。
那是另一份工作。它被称为研究科学家或机器学习研究员，这样的人相对较少，而且通常确实需要高级学位。
比市场增长快 8 倍的 AI 工程师工作完全是另一回事。
你在现有模型之上构建产品和功能。你拿 Claude、GPT 或一个开源模型，让它在实际应用程序中完成一项特定、可靠的工作。
实际上，这意味着你连接到模型 API，设计你输入的提示词和上下文，获取结构化数据输出，将模型连接到工具和数据库，使其检索正确的信息，处理可能出错的所有事情，并将其部署以便真实的人可以使用它。
它位于软件工程、产品工作和应用 AI 之间。你是构建者，而不是研究人员。
这是我会使用的一句话测试。如果你能让 LLM 在应用程序中可靠地完成一项特定工作，并且你足够了解它以便在它坏掉时修复它，那么你就是一名 AI 工程师。这就是全部。
本指南中的所有内容都是为了让你能够真实地说出这句话。
你不需要知道 Transformer 内部是如何工作的。你不需要微积分。你不需要能够推导反向传播。
你需要成为一名有能力的构建者，了解如何在现实世界中与这些模型协作。
这是一项可以学习的技能，专注的四个月足以让你掌握它的功能性。
## 第 1 个月之前必读：扼杀转行者的 4 个错误
我故意把这个放在路线图之前。
大多数指南把错误放在最后，但结束转行生涯的错误发生在第二周，而不是第三个月。如果你只记得本指南的一个部分，那就让它成为这一部分。
我看着很多人，包括早期的我自己，犯了每一个错误。它们都与智力无关。
它们与策略有关。修正策略，这四个月才能真正奏效。
错误 1：从理论和数学开始。
你很兴奋，你想做对，于是你去找一门机器学习课程，从线性代数、梯度下降和神经网络背后的数学开始。
三周后，你看了很多讲座，但你什么也构建不出来，你觉得自己像个冒名顶替者。于是你退出了。
修正方法：跳过它。对于你的目标工作，你不需要推导数学。
你需要构建。
当你在实际项目中遇到概念时，你会顺手学会它们，而且它们会留下来，因为它们与你构建的东西相关联。
“理论优先”是聪明人在这个领域半途而废的最常见原因。不要从那里开始。
错误 2：看教程而不是构建。
这一点很狡猾，因为它感觉像是在进步。你看了一个 4 小时的 Python 课程，点头附和，觉得自己学到了东西。其实你没有。
你看着别人学到了东西。当你打开一个空白文件的那一刻，什么都不存在了。
修正方法：30 分钟法则。每花一个小时观看或阅读，至少花 30 分钟在没有打开教程的情况下构建一些东西。
自己输入示例。打破它们。更改它们。遇到错误并修复它们。错误就是学习本身。
一个构建得很糟糕 4 个月的人，每次都能胜过一个观看教程 4 个月完美无缺的人。
雇主在看你 GitHub 的十秒钟内就能看出其中的区别。
错误 3：学习工具而不是技能。
你听说 LangChain 是关键，于是你深入研究 LangChain。
六个月后，领域已经发生了变化，每个人都在用别的东西，你的 LangChain 知识感觉被浪费了。于是你去追逐新的工具。
然后那个工具也变了。你总是落在后面，因为你在错误的层级上进行优化。
修正方法：学习工具底层的技能。编写能够产生可靠输出的提示词的技能不会因为框架更新而过期。
从模型获取结构化数据的技能，或者评估你的系统是否真的有效，或者决定一个任务是需要代理还是单次调用，这些技能在任何未来存在的工具中都是通用的。
将学习工具作为练习技能的一种方式，而不是作为目标。本指南正是出于这个原因围绕技能组织的。
错误 4：等待你觉得准备好公开构建。
你决定一旦你“准备好”了，就开始分享你的作品、申请职位或提供自由职业服务。
你永远不会觉得准备好了。准备是一种在开始之后才出现的感觉，而不是之前。
与此同时，那些被录用和获得客户的人，是那些在觉得自己合格之前的几个月就开始分享粗糙作品的人。
修正方法：在第 1 个月就开始公开构建。发布你做的小东西。写下你学到的东西。
把你完成的每个项目都放在 GitHub 上，即使是那些丑陋的。
“我在学习”和“我在公开构建”之间的差距，是大多数转行者被困住一年的地方。尽早缩小它。
没有人会密切关注你的早期工作以至于让你尴尬，而且复利效应从你开始的那一天就开始了。
在这整个过程中都要牢记这四点。
下面的路线图设计就是为了默认避免所有这些问题：技能优先、构建优先、工具无关、从第一天起就公开。
## 第 1 个月：Python 和基础管道
你这个月的目标：成为一名功能性的 Python 开发人员，能够调用 API、管理一个小项目，并不再需要谷歌搜索基本语法。
不是专家。功能性的。
第 2 到第 4 个月的所有内容都假设你能写出干净的 Python 并在终端中工作。这是基础，急于求成以后会害了你。
在开始之前要吸收的一点：AI 工程首先是软件工程。AI 部分位于正常的软件栈之上。
如果底下的栈不稳固，AI 部分就永远无法可靠。所以第 1 个月是关于对基础感到足够舒适，让它们不再成为你的阻碍。
我将为每项技能提供一个主要选择，并清楚地说明原因。我故意不给你每个主题五个选项。选择是动力的敌人。
选择我指出的那一个，只有在它真的不适合你时才分支出去。
Python
Python 是整个领域的语言。在接下来的四个月里，你接触的几乎每个库、API、教程和工作都是 Python 的。学会了它，其他一切都会变得更容易。
我的选择：CS50P，哈佛大学 Python 编程导论。免费、严谨，它强迫你真正解决问题，而不是看着别人解决。
问题集是全部的价值。它比温和的 YouTube 课程要求更高，这正是重点。
你想要那个让你有点挣扎的版本，因为正是挣扎形成了技能。
在 cs50.harvard.edu/python 找到它。
如果 CS50P 对绝对的初学者来说太陡峭，YouTube 上的 freeCodeCamp Python 课程是一个更温和的入口，但把它当作热身，而不是主要活动。
一旦你不再害怕空白文件，就回到 CS50P。
实际要关注的内容，大致顺序：变量和数据类型，循环和条件，函数，然后是集合类型（列表、字典、集合、元组）。
然后是文件处理以及读写 JSON，你在使用 AI API 时会不断用到这个。
然后是足够的类和面向对象基础，以便在阅读别人的代码时不至于恐慌。
然后是使用 try 和 except 进行错误处理。
最后是虚拟环境和 pip，这样你就可以安装包而不破坏你的系统。
不要试图记住任何这些东西。理解它们足以让你快速查找，并用它们构建直到它们粘在脑子里。
你第 1 个月的 Python 构建目标：一个能做真实事情的小型命令行工具。
一个读写 JSON 文件的费用跟踪器是个不错的选择。或者一个调用免费公共 API 并以干净格式打印结果的脚本。
大概 60 到 100 行你自己的代码。
它丑陋没关系。重要的是你写了它。
## 从第一天起利用 AI 学习
这是我会做一些旧路线图没有做的事情：用 AI 来学习 AI，从第一周开始。
你可以使用有史以来构建的最好的耐心导师，而且在免费层上它不花一分钱。当你遇到一个你不理解的错误时，不要在论坛上花 40 分钟。
把它粘贴到 Claude 或 ChatGPT 中，让它用通俗的英语解释错误，并引导你找到解决方案，而不是直接给你答案。
这是我会第一天设置的一个复制粘贴提示词。保存它。
这是本指南中几个值得收藏的工件中的第一个。
提示词：你的 Python 学习伙伴
（框架：FAG Learning Partner，作者 AI Guides）
```
你的工作：作为我耐心的 Python 导师，而我作为转行者正在学习编程。
关于我的背景：
- 我学习 Python 是为了成为一名 AI 工程师。
- 我是一个编程初学者，但并不是不努力工作的人。
- 我通过做来学习，而不是被给予答案。
做什么：
- 当我粘贴错误时，用通俗英语解释它的意思以及可能的原因。不要直接给我修复后的代码。
- 首先通过提示指向修复方向。只有我问两次时才显示完整的解决方案。
- 当我分享我写的代码时，告诉我一件有效的事情和一件我可以改进的事情。只限于这两点。
- 在我让东西工作起来之后，问我一个简短的问题，检查我是否真的理解了它。
规则：
- 任何行话旁边都要有一行通俗英语的定义。
- 假设我想学习，而不仅仅是通过。稍微慢一点没关系。
- 如果我要养成一个坏习惯，请直接而善意地指出来。
输出：对话式，简短，一次一个概念。
```
这一个月每天都使用它。它将学习编程的挫败部分变成了一场对话，而不是一堵墙。
它还让你在不知不觉中变得流利于提示词编写，这是第 2 个月的核心技能。
一个警告，以免你养成错误的习惯：使用 AI 来理解和消除阻碍，而不是让它为你编写整个东西。
如果你让它编写代码而你看，你就回到了错误 2。
让它解释。你打字。
Git 和 GitHub
Git 是开发者保存、版本控制和共享代码的方式。
GitHub 是你的工作公开存在的地方并成为作品集。
你会不断使用两者，对于转行者来说，在你拥有简历之前，GitHub 是你最接近简历的东西。
我的选择：GitHub Skills。免费、交互式，由 GitHub 在 GitHub 内部构建，所以你通过使用工具来学习工具。从这里开始，而不是抽象地阅读关于 Git 的内容。
在 skills.github.com 找到它。
如果分支和合并模型让你困惑，而且起初每个人都困惑，Learn Git Branching 可视化工具通过让你看到分支移动来让你豁然开朗。
关注什么：init、add、commit、push 和 pull 的核心循环。然后是分支和合并。
然后是 .gitignore 文件的作用以及为什么你永远不要把机密或 API 密钥提交到公共仓库，这在你使用付费 API 时非常重要。
然后是如何编写基本的 README，因为你的 README 稍后会在你的求职中发挥实际作用。
这个月要养成的习惯：你接触的每个项目，即使是一个 20 行的脚本，在你制作的那一天都要放入一个 GitHub 仓库。
这是错误 4 的修正实践。你在从一开始就安静地公开构建。
到了第 4 个月，你将有一串作品，而不是一个空白的个人资料。
终端
你将不断地在命令行运行脚本、安装包和管理项目。
在终端中迟缓或害怕会对其他一切产生真正的阻碍，而且这是一个容易解决的问题。
我的选择：一个简短的初学者终端课程来涵盖基础知识，然后就生活在其中。如果你愿意，MIT 的“Missing Semester”材料会更深入，但对于第 1 个月，你只需要导航和运行东西。
学习 cd、ls、pwd、mkdir 和 rm 用于移动和管理文件。
学习 cat 和 grep 用于阅读和搜索。
学习如何从终端运行 Python 脚本以及如何设置环境变量，这是你在处理 API 密钥时立刻需要的。
你不需要成为 shell 向导。你需要停止犹豫。
一个星期使用终端做所有事情，甚至是你通常用鼠标做的事情，就能让你到达那里。
API、JSON 和 HTTP
这是通往第 2 个月的桥梁。
从使用 LLM 构建的第一天起，你就会进行 API 调用，这意味着在你接触 OpenAI 或 Anthropic 的工具之前，你需要了解 Web API 是如何工作的。
我的选择：MDN Web Docs HTTP 概念介绍，加上 Python requests 库文档用于在代码中实现。
MDN 比任何其他免费资源都更清楚地解释了请求和响应是如何工作的。
然后 requests 向你展示如何在几行 Python 代码中进行这些调用。
关注什么：GET 和 POST 请求是什么以及如何在 Python 中进行它们。
读写 JSON，这是每个 AI API 使用的格式。
HTTP 状态代码以及常见代码的含义，特别是 200 表示成功，401 表示错误的 API 密钥，429 表示速率限制，500 表示服务器错误，因为你会经常看到所有这些。
什么是 API 密钥以及基本身份验证是如何工作的。
以及关于 Python 中的 async 和 await 做什么的简要介绍，当你以后开始从模型流式传输响应时你会需要这个。
现在不要深入研究 async。
只要知道它的存在以及大致解决了什么问题。
你在这里的构建目标：一个调用免费公共 API 的 Python 脚本，一个不需要密钥的 API，比如 Open-Meteo 天气 API，并将结果打印为干净的格式输出。
这是你在整个第 2 个月要做的微小版本，只是还没有 AI 部分。
关于 SQL 的简短说明
你不需要成为数据人员，但你会经常需要查看和查询数据，基本的 SQL 可以不断救你。
我的选择是 SQLBolt，它是免费的、交互式的，在大约 20 个简短的浏览器内课程中教你 SQL 的核心。
在 sqlbolt.com 找到它。
关注 SELECT、WHERE、GROUP BY、JOIN 和 ORDER BY。
目前这就够了。
一旦项目有需求，你可以更深入。
第 1 个月的里程碑
到月底，你应该能够编写一个读写文件、调用 API 并处理自己的错误而不崩溃的 Python 程序。
你应该使用 Git 对代码进行版本控制并将其放在 GitHub 仓库中。
你应该毫不犹豫地在终端中移动。你应该理解什么是 HTTP 请求并用 Python 发出一个请求。
你应该能够运行基本的 SQL 查询。
如果你能做到这些，你就有了基础。
大多数放弃的人从未到达这里，而到达这里确实是最难的部分，因为它是Least令人兴奋的。
从第 2 个月开始会变得更有趣，因为从这里开始你是在与 AI 一起构建。
## 第 2 个月：使用 LLM API 构建
你这个月的目标：使用模型 API 构建真实的 AI 驱动功能。
到最后，你应该能够熟练地编写产生可靠输出的提示词，从模型获取结构化数据，使模型调用你自己的函数，管理对话，并处理可能出错的一切。
这是整个工作的核心。之后的一切都建立在此基础上。
从这个月开始，它开始感觉真实了。你停止做设置，开始让模型做事情。
在这里花点时间。
第 2 个月的深入程度比本指南中任何其他地方的深入程度回报都更高。
真正有效的提示词编写
提示词编写不仅仅是礼貌地向聊天机器人提问。
它是编写指令的技能，以便从一个根本上是概率性的系统中产生一致、可靠的输出。
作为一名 AI 工程师，你会在这里花费比预期更多的时间，而且在这方面做得好是这个月你可以做的最高杠杆的事情。
我的选择：Anthropic 在 GitHub 上的交互式提示词工程教程。这是最实用的资源，分为章节，包含你针对 Claude API 运行的真实练习。
你亲自练习编写和修复提示词，而不是阅读关于它的内容，如果你记得错误 2，这就是全部重点。
在 anthropics/prompt-eng-interactive-tutorial 仓库中找到它。一旦你完成了它，Anthropic 和 OpenAI 的官方提示词工程文档是你将回来的参考资料。
关注什么：系统消息和用户消息之间的区别，以及为什么这种区别很重要。
为什么具体性总是胜过礼貌性。
思维链提示词，即你在回答之前要求模型逐步推理，这可以显著改善任何有逻辑内容的结果。
在你的提示词中使用示例，称为少样本提示词，以向模型展示你想要的格式。
并且培养一种感觉，了解微小的措辞变化如何产生巨大的输出变化，这只能通过大量实践来获得。
一个能快速教授这个的构建练习：拿一个真实的任务，比如总结文档或分类反馈，并为它编写五个不同的提示词。
运行全部五个。
并排比较输出。你会立即看到提示词设计如何驱动可靠性，这一课比任何讲座都更深刻。
结构化输出
在实际应用程序中，你几乎从来不希望从模型那里得到一段文本。
你希望你的代码可以解析、存储和使用的结构化数据。结构化输出通过强制模型返回匹配你定义的模式的数据来解决这个问题。
这是将演示与在软件内部实际工作的东西区分开来的技能之一。
我的选择：用于 Python 的 Instructor 库，由 OpenAI 和 Anthropic 的官方结构化输出文档支持。
Instructor 是使用 Pydantic（一个用于定义数据形状的 Python 库）从任何主要模型获取结构化数据的最干净方式。
它使用相同的代码跨提供商工作，并在模型返回格式错误的内容时自动重试。
它接近许多工作工程师实际使用的东西，这使得它值得在实际项目上学习，而不是玩具版本。
关注什么：定义一个描述你想要的数据的 Pydantic 模型，将该模式传递给 API，并处理模型拒绝或返回意外内容的情况。
理解真正的结构化输出（强制执行模式）和较松散的 JSON 模式（不保证）之间的区别。
这是你的第二个可收藏的工件，一个可靠的可靠结构化提取的提示词模式，即使你在上面添加库之前它也能工作。
提示词：结构化数据提取
（框架：FAG Extractor，作者 AI Guides）
```
你的工作：从我提供的文本中提取结构化数据并将其作为干净的 JSON 返回。
做什么：
- 仔细阅读输入文本。
- 仅提取下面输出下列出的字段。
- 如果文本中缺少某个字段，请使用 null。不要猜测或编造。
- 仅返回 JSON 对象。不要解释，不要 markdown，不要前言。
规则：
- 每个值都必须能追溯到输入文本中的某些内容。
- 日期格式为 YYYY-MM-DD。数字作为数字，而不是字符串。
- 如果文本模棱两可，宁愿选择 null 也不要自信地给出错误答案。
输出：具有以下字段的 JSON 对象：
{
"field_one": string or null,
"field_two": number or null,
"field_three": list of strings or empty list
}
输入文本：
[PASTE THE TEXT HERE]
```
关于经过测试失败的说明，因为我承诺给你诚实的版本：第一次这样做时，模型有时会将 JSON 包裹在 markdown 代码块中，或者在它之前添加一个友好的句子，你的解析器会窒息。
这是正常的。修复方法是在解析之前剥离代码块，并在提示词中明确你只想要 JSON 对象，上面的模式就是这样做的。
一旦你遇到过一次并处理了它，你就会永远处理它。
你的构建目标：一个收据或发票解析器。
向它提供原始的混乱文本，如“发票 123，3 个小部件 45.99 美元，3 月 30 日到期”，并返回一个干净的具有发票编号、金额、项目数量和到期日期的结构化对象。
这确实是一个有用的小工具和一个很好的作品集项目。
工具调用
工具调用是将文本生成器变成可以采取行动的东西的关键：搜索网络、查询数据库、调用你的 API、运行代码。
这是整个指南中最重要的技能之一，也是第 3 个月一切的基础。
让它变得清晰的心理模型：模型不运行你的函数。
它查看对话，决定应该使用工具，并返回一个命名函数和参数的结构化请求。
你的代码运行该函数并将结果交回给模型。模型是决策者。你的代码是双手。
我的选择：OpenAI 的函数调用指南和 Anthropic 的工具使用文档，一起阅读。
两者的概念是相同的，语法略有不同，同时看到两者使潜在模式变得明显。
然后通过一个可运行的笔记本示例，比如 OpenAI cookbook 中的那个，以便你看到完整的循环端到端，而不是零碎的。
关注什么：清楚地用模式描述你的函数，解析模型的工具调用响应，运行函数并将结果反馈，以及处理模型决定不需要工具的情况。
你的工具描述的质量比初学者预期的更重要，这是在第 3 个月会猛烈回归的一个主题。
你的构建目标：一个具有三个工具的小助手，比如 get_weather、calculate 和 search_notes，其中 search_notes 只是查找一个硬编码的字典。
将它们全部连接起来，并观看模型根据你的提问决定调用哪一个。
当你看到它自动选择正确的工具的那一刻，这个概念就永久落地了。
对话状态和流式传输
两个较小但必不可少的技能为本月画上句号。
模型在调用之间没有记忆。对话是你通过每次请求发送完整消息历史来管理的东西。
理解这一点是根本的，而且起初几乎每个人都感到惊讶。
我的选择是 OpenAI 和 Anthropic 的消息文档。
关注消息数组是如何结构化的，为什么你要附加用户的消息和模型的回复，当你超过上下文窗口时会发生什么，以及修剪旧消息的基本策略。
构建一个简单的多回合终端聊天机器人，它保留历史记录并有一个重置命令。它很小，但它完全教授了这个概念。
流式传输意味着在生成模型输出时逐字显示，而不是让用户等待整个内容。
它使应用程序感觉快得多。
我的选择是任一提供商的官方流式传输文档，加上 Simon Willison 关于流式传输在底层如何工作的清晰解释。
关注设置 stream 选项，迭代块，并从片段组装完整响应。
对于任何真实的人会使用的东西，流式传输几乎总是正确的选择。
没有人想盯着旋转图标十秒钟。
成本、失败和一个安全想法
三件事将业余项目与你可以放在用户面前的项目区分开来。
成本和令牌：模型按令牌收费，这大约是单词的四分之三。
输入和输出令牌的定价不同。
学会在发送请求之前估算它的成本，保留提供商定价页面的书签，并内化一条省真钱的规则：不要对简单任务使用最大、最昂贵的模型。
更便宜的模型通常足够好，而且大规模的成本差异是巨大的。
失败处理：API 会失败。
达到速率限制，请求超时，模型返回格式错误的输出。
优雅地处理这些是使某个东西生产就绪的关键。
学会捕获速率限制错误并在尝试之间以增长的延迟重试，称为指数退避。
Python 中的 Tenacity 库通过单个装饰器完成此操作。
学会在信任之前验证模型的输出，并且永远不要让意外的响应使你的整个应用程序崩溃。
简短的提示词注入：这是 LLM 应用程序中的首要安全风险。
当不受信任的用户输入与你的指令结合时，就会发生这种情况，允许用户覆盖或劫持你的系统所做的事情。
你这个月不需要成为安全专家，但在你发布任何东西之前你需要知道它的存在。
OWASP 关于它的指南是权威参考。
核心防御：不要信任未经验证的模型输出来自动执行后果性的操作，并给你的工具提供完成工作所需的最低权限。
第 2 个月的里程碑
到月底，你应该能够编写对给定任务产生可靠输出的提示词，使用 Pydantic 和 Instructor 从模型获取结构化 JSON，连接工具调用以便模型可以运行你的 Python 函数，实时流式传输响应，管理多回合对话历史，在发送之前估算请求的令牌成本，处理 API 错误和错误输出而不崩溃，并解释什么是提示词注入。
这本身就是一个真正的、可雇佣的技能组合。
生产中许多付费的 AI 功能正是做这个，没有更多。
但下个月是你构建真正让你被雇佣的东西的地方。
## 第 3 个月：RAG 和代理，让你被雇佣的技能
你这个月的目标：构建让模型从你的文档而不是仅从他们的训练数据中回答的系统，以及构建可以自行采取多个步骤的系统。
这两项技能，检索和代理，是 AI 工程目前需求最大的实践能力。
几乎每个真实的企业用例，从支持机器人到内部知识工具再到文档分析，都是建立在它们之上的。
我将许多路线图跨越两个月的内容压缩到了一个月，因为你不需要掌握每一个高级变体才能被雇佣。
你需要构建一个可靠的检索系统和一个可靠的代理，理解为什么每个部分都在那里，并能够在它们坏掉时调试它们。
这就是标准。让我们达到它。
RAG，首先用通俗英语说
RAG 代表检索增强生成。
去掉行话，它很简单：你给模型一个库来查找东西，这样它就不必记住所有内容，并且它可以回答关于你的特定文档的问题。
流程是：你获取你的文档，把它们分成块，将每个块转换成一个捕获其含义的数字列表，并存储这些。
当用户问问题时，你以同样的方式将他们的问题转换为数字，找到数字最接近的块，并将这些块连同问题一起交给模型。
模型使用你给它的东西回答。这就是 RAG。其他一切都是改进。
让我们构建这些部分。
嵌入
嵌入是一段文本转换为代表其含义的长数字列表。
有用的属性：含义相似的文本最终会有相似的数字，在这个数字空间中靠得很近。
这种接近性使按含义搜索成为可能，这是 RAG 下的引擎。
我构建直觉的选择：Stack Overflow 博客关于文本嵌入的直观介绍，它侧重于心理模型而不是数学，加上 OpenAI 的嵌入指南，当你准备好在代码中生成它们时。
关注概念上理解什么是向量，为什么相似的文本产生相似的向量，以及大致如何测量两者之间的距离。
你不需要知道嵌入是如何产生的背后的数学。你需要知道如何使用它们。
一个完全教授这个的小构建：拿 20 个关于相关主题的句子，将每个变成一个嵌入，并编写一个小函数，给定一个新句子，返回你的集合中最相似的三个。
这是微缩版的 RAG。一旦你构建了这个，完整版本只是相同想法的规模化。
分块
你的文档太大而无法整体嵌入，所以你在嵌入之前将它们分成块。
你如何分块直接控制你的系统找到正确信息的程度。
即使是一个完美的检索设置，如果底层的块不好，也会失败。
我的选择：从 LangChain 的 RecursiveCharacterTextSplitter 开始，块大小约为 500 个字符，重叠约为 50。
这种重叠很重要，因为它阻止你在一个块结束和下一个块开始的边界上丢失含义。
这是给你一个工作基线的合理默认值。
要牢记的核心权衡：块太大失去精度，块太小失去上下文。
从默认开始，然后根据你的检索实际出错的地方进行调整。
向量数据库
一旦你有了嵌入，你需要一个地方来快速存储和搜索它们。这就是向量数据库所做的。
我的学习选择：Chroma。它在本地运行，无需设置基础设施，这正是你在学习时想要的。
你还不需要托管云规模，过早添加它只会给你更多的配置和破坏空间。
Chroma 让你专注于概念。
在 docs.trychroma.com 找到它。
学习创建集合，插入嵌入以及元数据如来源和部分，通过相似性查询以获得最佳匹配，并在查询时按元数据过滤。
你不需要理解底层的索引算法。你需要使用它们。
当你最终需要生产规模时，如果你的应用程序已经使用 Postgres 数据库，pgvector 是自然的下一步，当你想要别人运行它时有托管选项。
但那是第 4 个月或工作上的关注点。目前，本地的 Chroma 就足够了。
让检索真正变得好
基本的相似性搜索给你一个演示。
一些改进给你可靠工作的东西，知道这些将复制教程的人与理解系统的人区分开来。
元数据过滤：在存储时用有用的信息标记每个块，比如源文件、日期、部分或类别。
然后在查询时过滤这些。这是玩具与系统之间的区别，用户可以问“只向我显示 Q4 报告的结果”并且实际上得到它们。
重排序：你的第一次搜索是快速但近似的。
重排序器获取前几个结果并重新评分它们以确定与问题的真实相关性，这以小的速度代价显著提高质量。
模式是：快速检索广泛集，然后重排序到最好的几个。Cohere 的重排序文档是学习这一点的最干净的地方，通常是一行添加。
调试检索，因为大多数 RAG 失败是检索失败，而不是模型失败。
当你的系统给出错误答案时，模型通常不是问题。
检索给了它错误的块。
学习常见的失败模式：问题和相关块在数字空间中不匹配，即使信息存在（可以通过重写查询来修复），相关信息分散在两个块中（可以通过更多重叠来修复），或者正确的块存在但没有进入前几个结果（可以通过检索更多，然后重排序下来来修复）。
当答案错误时，检查检索到了什么，然后再责怪模型。这一个习惯将为你节省巨大的挫折感。
基础和引用：一个好的 RAG 系统不仅回答，它还告诉你答案来自哪里，这建立了信任并使调试容易得多。
将每个块的源信息传递到你的提示词中，并指示模型引用它。
这是你的第三个工件，保持 RAG 系统诚实的基础提示词。
这是我会书签超过其他的那个，因为它是制造东西的系统和你可以信任的系统之间的区别。
提示词：基础 RAG 回答
（框架：FAG Grounding，作者 AI Guides）
```
你的工作：仅使用提供的上下文回答用户的问题。
做什么：
- 阅读下面的上下文块。每个都有一个源标签。
- 仅使用在上下文中找到的信息回答问题。
- 在每个声明之后，引用它的源标签，如 [source: filename, p.3]。
- 如果上下文不包含答案，请确切地说：
“我在提供的文档中没有足够的信息来回答这个问题。”
规则：
- 永远不要使用提供的上下文之外的知识。
- 永远不要猜测。永远不要用听起来合理的东西填补空白。
- 如果上下文部分回答了问题，回答那部分并清楚地说明缺少什么。
上下文：
[PASTE RETRIEVED CHUNKS WITH SOURCE LABELS HERE]
问题：
[USER QUESTION HERE]
```
那个“当你不知道时确切地说这个”指令正在做繁重的工作。这是在检索系统中减少幻觉的最有效方法，因为它给了模型一个批准的方式来承认无知，而不是为了显得有帮助而编造答案。
你的 RAG 构建
使用一个框架将这一切联系起来，而不是从头开始构建每个部分。
我的第一个 RAG 系统的选择是 LlamaIndex，它是构建为优先搜索的，并在少量代码中给你一个工作的管道。
LangChain 是另一个主要选择，对于接下来的多步代理工作更出色，所以你很快就会遇到它。
你的构建目标，这是一个真正的作品集项目：一个“与你的文档聊天”的应用程序。
摄取 10 到 20 个 PDF 或文本文件，你自己的笔记或一组产品文档效果很好，构建一些东西，它接收问题，使用重排序检索最相关的块，并返回一个引用的答案。
在它上面放一个简单的界面。
这是让招聘经理认真对待你的项目，因为这正是公司现在花钱构建的那种东西。
代理
在本月的一半，转移到代理。
代理听起来很神奇，一旦你看到它就真的很简单：它是一个循环，模型反复决定下一步，使用工具采取它，查看结果，再次决定，直到任务完成。
心理模型：代理是一个带有模型进行分支决策的 while 循环。
思考发生在提示词中。分支是模型选择使用哪个工具。做是你的代码运行该工具。
其他一切都是管道。一旦这一点清楚了，即使是复杂的代理框架也变得可读。
我的选择，在我写一行代理代码之前我会读这个：Anthropic 的“构建有效的代理”。
这是关于代理在实践中如何工作的最清晰的写作，来自构建模型的团队。
当你准备好构建时，将其与动手框架课程配对，比如 LangGraph 介绍，这是编排代理的最广泛使用的框架。
关注什么：感知、决定、行动、观察的循环，以及它如何知道何时停止。
当工具调用在循环内失败时会发生什么。如何编写模型可以实际使用的工具描述，因为模糊描述的工具被错误调用或忽略。
以及管理状态，这是流经代理工作的共享记忆。
本月最有价值的练习：完全从头开始构建一个小代理，不使用任何框架，只使用模型 API。
给它三个工具，一个目标和一个循环。这教你框架隐藏了什么，并且让你之后接触的每个框架都有意义。
在接触 LangGraph 之前做这个。
何时不使用代理
这是该领域最被忽视的技能之一，知道它标志着你是一个有判断力的人，而不是一个追逐闪亮事物的人。
代理令人兴奋，它们也更慢、更昂贵、更不可预测，并且比更简单的方法更难调试。
伸手去拿最简单的可行东西是你知道你在做什么的标志。
决策框架，值得记住：如果任务在一个带有正确上下文的提示词中适合，则使用单个模型调用。
如果步骤是可预测的，则使用固定工作流，即你定义的一系列步骤。
仅当步骤的数量真正不可预测并且需要模型动态决定时才使用代理。
三个固定调用的链总是比可能进行三次调用的代理更快、更便宜且更容易调试。将代理保留给真正的开放性任务。
在单个调用和完整代理之间有一个巨大、富有成效的中间地带：工作流。
链接，其中一个调用的输出馈送下一个。
路由，你分类输入并将其发送到专门的处理器。
并行化，你同时运行几个调用并将它们组合。
大多数实际问题最好用工作流解决，而不是代理，Anthropic 的代理文章很好地涵盖了这些模式。
评估，简要但严肃
你需要知道你的系统是否真的有效，而不仅仅是在你手动尝试的两个例子上是否有效。
这就是评估的目的。构建一组 20 到 30 个具有预期输出或评分标准的代表性输入，并在每次更改提示词、交换模型或调整检索时，针对所有这些运行你的系统。
像 DeepEval 这样用于一般用途的工具和像 Ragas 这样专门用于 RAG 的工具使这变得可控。
比工具更重要的是心态：你在没有运行评估的情况下所做的每个提示词更改或模型交换都是一个赌博。
那些发布可靠 AI 的人不断运行评估，现在开始这种习惯，即使是以小的方式，也使你领先于许多已经在该领域工作的人。
第 3 个月的里程碑
到月底，你应该能够解释什么是嵌入以及为什么相似的文本产生相似的向量，明智地对文档进行分块，在带有元数据过滤的向量数据库中存储和查询嵌入，添加重排序以改善结果，调试检索失败而不是责怪模型，构建一个完整的 RAG 管道，返回基础引用答案，从头实现代理循环，正确决定任务是需要单个调用、工作流还是代理，并运行基本评估以检查你的工作。
这就是可雇佣的核心。
如果第 1 到第 3 个月是稳固的，你可以构建公司正在招聘的东西。
第 4 个月是关于证明它并获得报酬。
## 第 4 个月：发布它，展示它，被雇佣
你这个月的目标：把你构建的一切变成现实，然后把它变成工作或有偿工作。
这是大多数人停滞的地方。
他们可以构建一个演示，但不能发布在真实使用中幸存下来的东西，也不能将他们的技能转化为收入。
这个月修复了两者。它的新概念较少，更多的是关于做，因为在这个阶段做才是最重要的。
足以危险的部署知识
你不需要成为基础设施专家。
你需要能够将一个工作的 AI 应用程序放在真实的人可以使用的地方，而不会让它崩溃或让你破产。
最小可行性知识：学习足够的 Docker 来打包你的应用程序，以便它在任何地方运行相同，这解决了“在我的机器上工作”的问题。
学习将容器部署到某个地方。
并学习成本和可靠性基础知识，以阻止错误变成灾难：在你的 API 账户上设置硬性支出限制，添加缓存这样你就不为相同的请求支付两次，并添加速率限制这样一个用户就不能让你的账单爆炸。
Docker 的官方入门指南涵盖了打包。
对于 AI 特定的成本方面，核心举措是缓存相同的请求，在足够的地方使用更便宜的模型，并设置硬性每月支出上限，以便失控循环不能在一夜之间花费你 500 美元。
你还想要基本的可观察性，这是一个花哨的词，能够看到你的应用程序在做什么。
LLM 应用程序有一个特定问题：模型可以返回一个完全成功的响应，但也是无用的或错误的，正常的监控不会捕获那个。
像 Langfuse 这样的工具跟踪每个模型调用，向你显示提示词、响应、令牌成本和延迟，这使得调试和成本控制容易得多。
在一个项目上设置它，以便你理解模式。
不要在这里过度投资。
一个应用程序，正确部署，具有成本控制和基本跟踪，教你所需的一切并给你一些真实的东西来展示。
部署的深度可以在工作中获得。
每个其他路线图跳过的部分：将项目变成工作。
你已经构建了三个真实的项目。现在让它们为你工作，因为一个没人看到的好项目对你的职业生涯没有任何作用。
你的作品集是三个部署的项目，每个都有一个做实际工作的 README。
这里有一个几乎没有人做的举动，那个让你脱颖而出的举动：在每个 README 中，包括一个关于哪里出错了以及你会做什么不同的部分。
大多数作品集假装一切都完美，读起来要么不诚实要么肤浅。
一个说“这是我的第一次方法失败的地方，这是我从中学到的，这是我如何修复它的”README，准确地表明了雇主说他们现在正在筛选的判断力。
这是介绍中转行者的优势，变得可见。
没有人期望转行者拥有完美的项目。他们给一个能够深刻理解自己的工作足以批评它的人留下深刻印象。
像这样构建每个 README：项目解决的问题，谁会使用它，你采取的方法和原因，哪里出错了以及你学到了什么，以及如何运行它。
五个部分。
这比大多数拥有计算机科学学位的人的作品集都要好。
简历和个人资料举动：你不需要假装你有多年的经验。
你需要一条清晰的线索说明你能做什么。
像这样的“我构建生产 LLM 应用程序：RAG 系统、代理和 API 集成。这是我发布的三个。”
然后链接项目。你现有的职业是一项资产，而不是要隐藏的东西。
“前[你的领域]现在构建 AI 系统”是一个比“初级开发者”更强的故事，因为它伴随着纯粹初级所缺乏的领域知识和判断力。
如果你从金融转行，你理解 AI 可以解决的金融问题。
如果你从医疗保健转行，也是如此。依靠它。
作为你的管道公开构建：在这个整个月，继续发布你构建的东西和你学到的东西。
我见过的最好的机会是给那些可见的人，而不是那些悄悄申请 500 个列表的人。
写下你的项目。分享你修复的错误。复利是真实的，现在你有真实的工作可以分享，所以比第 1 个月更容易。
选择一个方向
到了第 4 个月，你可以将你的技能指向适合你目标的任何东西。三个方向，选择一个更深入而不是分散。
AI 产品工程师路径，最适合如果你想要一份初创公司工作快：你构建真实用户接触的 AI 驱动产品。
你已经拥有第 1 到第 3 个月的大部分内容。
更深入地构建完整、精致的应用程序和产品方面，意味着应用程序如何处理模型错误，它如何显示加载状态，用户如何给出反馈。
发布两三个人们可以实际尝试的东西。
应用 ML 路径，最适合如果你想要更深入的技术角色：超越 API 调用进入微调，何时微调而不仅仅是更好地提示，使用像 Ollama 这样的工具在本地运行开源模型，以及推理优化。
要保留的决策框架：从提示词开始，如果模型需要你的特定数据则添加检索，并且只有在提示词和检索真的无法达到你需要的质量时才微调。
微调通常过早地被追求。
AI 自动化路径，最适合如果你想立即从企业赚钱：专注于自动化真实的业务工作流，跨工具链接 AI，如电子邮件、CRM、文档和电子表格。
像 n8n 这样的用于可视化工作流的工具和 LangGraph 用于繁重的代码工作。
这里可出售的构建：一个线索资格系统，它获取线索，使用模型研究和评分每个线索，起草个性化外展，并记录所有内容。
企业为此支付真金白银。
第 4 个月的里程碑
到月底，你应该有一个具有适当成本控制的已部署 AI 应用程序，三个作品集项目每个都有一个诚实的 README，一条清晰的关于你构建什么的一句话推介，一个可见的公开工作痕迹，以及一个你正在更深入选择的 chosen 方向。
在那时你不是“正在学习 AI 的人”。你是一个发布 AI 系统的人，这是市场正在付费的东西。
## 诚实的部分
我在开始时告诉过你我不会向你推销幻想，所以在金钱数字之前这里是直白的版本。
专注的四个月工作使你在初级水平上可雇佣，或者准备接受自由职业工作。它不会让你成为高级工程师。
高级来自在真实约束下发布真实事物的多年经验，没有指南能压缩那个。
四个月给你买的是构建、发布和部署解决真实问题的 AI 系统能力，这确实是一个有价值且可雇佣的地方。
这假设真实工作，大约每周 15 到 20 小时，实际构建而不仅仅是观看。
如果你每周只能给它 7 小时，这是一个 8 个月的路径，这完全没问题。
时间线拉长，目的地不改变。扼杀人的不是慢节奏。是停止。
一致性在这里总是胜过强度。
整个事情依赖于错误部分的一个行为：构建，不要只是观看。
每个月都有一个项目。做这些项目。一个在四个月内构建四个粗糙项目的人是可雇佣的。
一个观看四个月完美教程的人不是。这就是整个游戏。
金钱，附带来源
现在是你真正想要的数字，所有当前的都有来源，因为松散的薪资声明是这些指南失去信誉的方式。
截至 2026 年 6 月，Glassdoor 显示美国 AI 工程师的平均薪水约为 143,500 美元，典型范围大约在 25 百分位的 115,000 美元到 75 百分位的 181,000 美元，最高收入者报告高达约 223,000 美元。
高级 AI 工程师平均约 285,000 美元，典型范围大约在 221,000 美元到 375,000 美元，这表明一旦你有真实经验，跳跃是多么陡峭。
这些是基于提交薪水的 Glassdoor 数字。
将人员安置在真实生产 AI 工作中的招聘人员报告称，基于签署的报价而不是调查，中级基础薪水集中在 155,000 美元到 200,000 美元之间，这与 Glassdoor 范围一致，并给你第二次独立读取。
以及 PwC 2026 年晴雨表的更广泛市场背景，我在开始时打开的：AI 技能工作增长比整个市场快大约 8 倍，AI 技能的 62% 工资溢价，以及学位要求恰好在这些角色中下降最快。
这些不是来自炒作帖子。它们来自对超过 10 亿条招聘广告的分析。
自由职业和咨询数字变化太大，无法精确引用而不误导你，所以我只会说：RAG 实施、代理构建和 LLM 集成的费率很高，并且一个拥有三个可靠的已部署项目和清晰推介的转行者可以在他们获得全职角色之前很长时间就开始为此工作收费。
项目就是证明。构建它们，赚钱的选择就会打开。
## 这周开始
如果我是你，今天我会实际做的事情。
选择第 1 个月的 Python 项目，那个小型命令行工具。打开一个代码编辑器。
开始 CS50P 的第一个问题集。设置学习伙伴提示词，以便 AI 辅导你通过挫败的部分。
创建一个 GitHub 仓库并将你的第一个丑陋文件放入其中。这就是整个第一周。
不要等到你觉得准备好了，因为准备在你开始之后到来，而不是之前。
在写一行代码之前不要完美地规划所有四个月，因为计划已经在这里，规划只是避免开始的一种舒适方式。
学习和构建之间的差距是人们失去一年的地方。这周缩小它。
四个月的真实工作真正改变了你可能的范围。
大门比以前任何时候都更开放，凭证障碍正在下降，市场为这些技能支付的薪酬几乎比科技界的任何其他东西都多。
你有指南。剩下的唯一变量是你是否构建。
保存这个，在你进行时每个月回来。我会随着工具和数字的变化更新它。
关注 @free_ai_guides 获取更新 ❤️
## 相关链接
- [Machina reposted](https://x.com/EXM7777)
- [AI Guides](https://x.com/free_ai_guides)
- [@free_ai_guides](https://x.com/free_ai_guides)
- [197K](https://x.com/free_ai_guides/status/2074531958600638877/analytics)
- [cs50.harvard.edu/python](http://cs50.harvard.edu/python)
- [skills.github.com](http://skills.github.com/)
- [docs.trychroma.com](http://docs.trychroma.com/)
- [@free_ai_guides](https://x.com/@free_ai_guides)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:32 AM · Jul 8, 2026](https://x.com/free_ai_guides/status/2074531958600638877)
- [197.8K Views](https://x.com/free_ai_guides/status/2074531958600638877/analytics)
- [View quotes](https://x.com/free_ai_guides/status/2074531958600638877/quotes)
---
*导出时间: 2026/7/29 21:52:11*