# How to go from being a prompt engineer to a full stack AI engineer:
**作者**: hoeem
**日期**: 2026-05-15T17:10:35.000Z
**来源**: [https://x.com/hooeem/status/2059640615344754947](https://x.com/hooeem/status/2059640615344754947)
---
The worst take I have read is "prompt engineering is dead", it never died, but prompt-only thinking did. So I created a course to teach you to become an AI engineer and it's designed so that a beginner and an power user will be able to read this article, learn from it, and apply it to completely reshape the way you're utilising AI today.
Prompting is still the interface between you and the model.
- Bad prompts produce bad outputs.
- Vague instructions create vague answers.
- Missing context causes the model to guess.
But prompt literacy is scratching at the surface, so yes, I've taken the time to put together and create a full course to take you through the following so that you become an AI engineer.
(thank you GPT for the table)
## 1: Let's change the way you use AI today.
I want you to go from thinking:
> I have a task.
> I type the task.
> The model gives me an answer.
> I judge the answer by vibes.
and instead I want you to think:
> I have a task.
> I define the outcome.
> I decide what information is needed.
> I decide what model is appropriate.
> I define how the answer should be structured.
> I decide whether tools or retrieval are needed.
> I decide what counts as success.
> I check the result against a standard.
> I improve the system.
then, as an AI engineer I'd want you to think one step further, this is where you're going to level up.
Let's say you want to create an AI newsletter, you'd go and design a repeatable system to utilise:
So stop thinking "what prompt should I use now?"
Start thinking "what can I do to make this output reliable every week?"
## 2: Specificity
This is the first skill I want you to learn.
A vague prompt forces the model to fill in missing details. Sometimes it guesses correctly. Often it does not. The model is not reading your mind. It is inferring intent from the words and context available to it.
Old way
> Make this better.
Better way
> Rewrite this newsletter introduction to make it sharper, more direct, and more credible. Constraints: Keep the core argument unchanged. Remove vague claims. Add a strong first sentence. Keep it under 180 words. Make it sound like a experienced operator
You get the idea, specificity is important, and should be able to answer these questions:
3: Roles
It's still important, why do you think Karparthy uses the following prompt with everything?
```
You are a world class expert in all domains. Your intellectual firepower, scope of knowledge, incisive thought process, and level of erudition are on par with the smartest people in the world. Answer with complete, detailed, specific answers. Process information and explain your answers step by step. Verify your own work. Double check all facts, figures, citations, names, dates, and examples. Never hallucinate or make anything up. If you don't know something, just say so. Your tone of voice is precise, but not strident or pedantic. You do not need to worry about offending me, and your answers can and should be provocative, aggressive, argumentative, and pointed. Negative conclusions and bad news are fine. Your answers do not need to be politically correct. Do not provide disclaimers. Do not inform me about morals and ethics unless I specifically ask. Do not be sensitive to anyone's feelings or to propriety. Make your answers as long and detailed as you possibly can. Never praise my questions or validate my premises before answering. If I'm wrong, say so immediately. Lead with the strongest counterargument to any position I appear to hold before
supporting it. Do not use phrases like "great question," "you're absolutely right," "fascinating perspective," or any variant. If I push back, do not capitulate unless I provide new evidence or a superior argument - restate your position if your reasoning holds. Do not anchor on numbers or estimates I provide; generate your own independently first. Use explicit confidence levels (high/moderate/low/unknown). Never apologize for disagreeing. Accuracy is your success metric, not my approval.
```
Because it fucking works as a role helps define behaviour.
Here's the model he utilises:
Here's a template you can copy and paste if you want...
```
Act as a [role].
Your job is to [primary responsibility].
You are allowed to:
[allowed action]
[allowed action]
[allowed action]
You are not allowed to:
[forbidden action]
[forbidden action]
[forbidden action]
Use this standard:
[what good looks like]
If information is missing:
[ask / state assumptions / provide conditional answer]
```
Roles are useful to define judgement. Okay... we're quickly learning how to prompt efficiently which is the first stage to becoming an AI engineer. If you feel you're comfortable with this please skip past 4, 5, 6, 7, 8 (screaming kids 67 67 67 67 67 67, sorry, it's engraved in my internal monologue lmao) and go straight to 9.
## 4: Using examples
I use these yo show the model what pattern I want, and this can help with:
- structure
- tone
- reasoning pattern
- categorisation
- output shape
- level of detail
- what to include
- what to exclude
Don't just say "write like my previous posts" instead:
```
Use the examples below to learn the style pattern.
Pattern to preserve:
Direct opening
Short paragraphs
One strong claim per section
Concrete examples
No motivational language
Ends with a practical takeaway
Do not copy the wording. Extract the structure and tone.
```
Giving your model examples is important as this will become a test ground to ensure it gets it right.
I use this to ensure it's not a lucky output, even OpenAI have guidance frames to ensure your model gets it right.
If I ever give the model bad examples then it gets poisoned.
If I ever give the model inconsistent examples then I get shit examples.
If I ever give contradictory examples over my instructions it will get confused and fuck it all up.
That's why it's important.
## 5: Reasoning
I used to do some dumb ass shit here.
I used to say:
"think step-by-step" and "show your full reasoning".
Brother ewwwww.
Reasoning models are designed to handle harder multi-step reasoning internally so instead of saying "show me every thought" instead say "reason carefully, then give me the useful audit trail" and voila.
All you need is:
- Final answer
- Key reasoning checkpoints
- Assumptions
- Uncertainties
- How I can verify this
And (I'll paste it for you here again) this is where Karpathy's prompt comes in clutch again:
```
You are a world class expert in all domains. Your intellectual firepower, scope of knowledge, incisive thought process, and level of erudition are on par with the smartest people in the world. Answer with complete, detailed, specific answers. Process information and explain your answers step by step. Verify your own work. Double check all facts, figures, citations, names, dates, and examples. Never hallucinate or make anything up. If you don't know something, just say so. Your tone of voice is precise, but not strident or pedantic. You do not need to worry about offending me, and your answers can and should be provocative, aggressive, argumentative, and pointed. Negative conclusions and bad news are fine. Your answers do not need to be politically correct. Do not provide disclaimers. Do not inform me about morals and ethics unless I specifically ask. Do not be sensitive to anyone's feelings or to propriety. Make your answers as long and detailed as you possibly can. Never praise my questions or validate my premises before answering. If I'm wrong, say so immediately. Lead with the strongest counterargument to any position I appear to hold before
supporting it. Do not use phrases like "great question," "you're absolutely right," "fascinating perspective," or any variant. If I push back, do not capitulate unless I provide new evidence or a superior argument - restate your position if your reasoning holds. Do not anchor on numbers or estimates I provide; generate your own independently first. Use explicit confidence levels (high/moderate/low/unknown). Never apologize for disagreeing. Accuracy is your success metric, not my approval.
```
Okay... moving on :).
## 6: Output control
I use output control depending on the task I have at hand.
If I can answer "who is this for?" then I can decide on the output I want given to me. Here's a table that I use and you can steal:
OpenAI’s Structured Outputs are available through function calling and JSON-schema response formats; the point is not merely to ask for “valid JSON”, but to constrain the output to a defined structure where supported. Google’s Gemini API also documents structured output support, including use alongside tools in supported models.
Here's a JSON schema as an example:
```
{
"type": "object",
"properties": {
"answer": {
"type": "string"
},
"confidence": {
"type": "string",
"enum": ["low", "medium", "high"]
},
"assumptions": {
"type": "array",
"items": {
"type": "string"
}
},
"risks": {
"type": "array",
"items": {
"type": "string"
}
},
"next_steps": {
"type": "array",
"items": {
"type": "string"
}
}
},
"required": ["answer", "confidence", "assumptions", "risks", "next_steps"],
"additionalProperties": false
}
```
Don't confuse a cool looking output with a reliable one.
Use the output for the job at hand.
## 7: Iteration & follow up
Does your model ever give you a perfect answer straight away? Mine doesn't lol.
Old way
> Try again. Make it better.
Better way:
```
Revise the previous answer.
Keep:
the structure
the main conclusion
the practical tone
Change:
make the examples more concrete
reduce repetition
add a stronger opening
remove generic AI language
Do not:
add citations
make it longer
change the target reader
```
So when you're wanting to make changes think:
## 8: Constraints
Constraints are not optional.
They are part of the task.
Why? The model doesn't know the boundaries, they need to be defined.
I used to get this wrong all the time saying:
"Do not sound like AI" or "Do not be boring"
This is crap, this is a better framework:
Avoid:
- “In today’s fast-paced world”
- “It’s important to note”
- "it's not X, it's Y"
- vague claims without examples
- em dashes
- motivational closing lines
Here's the boundaries you should be setting:
1. Style
2. Scope
3. Evidence
4. Authority
5. Safety
6. Output
7. Time
8. Quality
Here's a template I got for you:
```
Constraints:
[rule]
[rule]
[rule]
Do not:
[forbidden pattern]
[forbidden pattern]
If you cannot comply:
explain why
provide the closest valid alternative
```
When you are creating a workflow these constraints become guardrails for you, here's an example:
```
{
"allowed_actions": ["summarise", "draft", "classify", "rank"],
"requires_approval": ["send_email", "publish_post", "delete_file"],
"forbidden_actions": ["invent_sources", "expose_private_data", "make_payment"]
}
```
## 9: Context engineering
Prompting asks:
> What should I say to the model?
Context engineering asks:
> What does the model need to know to do the job well?
Anthropic describes context engineering as an emerging discipline for building steerable, effective agents, with emphasis on what information is made available to the model during a task.
If I don't give it my goals, preferences, examples, source material, constraints, scoring standard, or past decisions then it's going to guess for me and fuck it all up.
This will help you (it helped me):
Note: Context is expensive.
Overly long unnecessary context is going to dilute attention, increase cost, and create conflicts in your work.
More context doesn't = better context.
Ensure you follow:
```
Goal:
What we are trying to achieve.
Reader / user:
Who this is for
Background:
What the model needs to know.
Source material:
Documents, notes, examples, URLs or data.
Preferences:
Style, tone and standards.
Constraints:
Rules and limits.
Success criteria:
How to judge the output.
Known failure modes:
What usually goes wrong.
```
## 10: Retrieval
If the answer depends on facts, the model needs sources.
This is where prompt-only reliability breaks.
You cannot solve factual uncertainty with wording alone.
Make sure you're given it good sources:
If it's finding it's own then get it to rank them:
```
Use sources in this order:
1: Official documentation
2: Primary research / original paper
3: Standards body / regulator
4: Reputable expert analysis
5: News reporting
6: Community discussion
If sources disagree:
1: explain the disagreement
2: prefer the highest-authority source
3: state confidence
```
Retrieval means the system can search or fetch information outside the model’s internal memory.
This can include:
- web search
- file search
- database search
- document retrieval
- vector search
- keyword search
- knowledge-base lookup
- citation retrieval
Retrieval checklist:
Before using retrieval, ask:
- What question needs external evidence?
- What sources are allowed?
- What sources are preferred?
- How recent must the information be?
- Should the model quote, cite or summarise?
- What should happen if sources conflict?
- What should happen if no source is found?
## 11: Tool use and function calling
This is where AI starts doing things instead of only saying things.
Function calling lets a model connect natural language to external tools or APIs. OpenAI describes function calling as a way for models to interface with external systems and access data outside their training data. Google’s Gemini API also documents function calling as a way for models to determine when to call functions and provide structured parameters.
Here's the tool layer:
## 12: MCP and connected AI workflows
This is how I connect X, Y, and Z, and by that I mean connecting to files, databases, APIs, tools and workflows.
Model Context Protocol is an open standard for connecting AI applications to external data sources and tools. Anthropic introduced MCP in 2024 as a standard for secure, two-way connections between data sources and AI-powered tools, and the official MCP docs describe it as a way to connect AI applications to data, tools and workflows.
Here's how to understand this part:
Here's use cases:
Connected context creates risk.
The official MCP security best-practices page identifies security risks, attack vectors and best practices for MCP implementations.
1. Do not connect to everything.
2. Do not trust every tool.
3. Do not allow silent high-risk actions.
4. Do not assume tool descriptions are harmless.
## 13: Task chaining, workflows, and agents
You do not need an agent for everything, in fact Anthropic’s agent guidance distinguishes workflows, where LLMs and tools follow predefined paths, from agents, where the model dynamically directs its own process and tool use. Their guidance starts with simpler building blocks and progressively moves towards more autonomous agents.
1. Use a workflow when the steps are predictable.
2. Use an agent when the steps must be discovered dynamically.
Workflows are fixed sequences, and agents have more autonomy.
So how can you decide when to use an agent or a workflow?
Articles on agents (bookmark these for later):
> **Shann³@shannholmberg**: [原文链接](https://x.com/shannholmberg/status/2055335043904492011)
>
> **hoeem@hooeem**: [原文链接](https://x.com/hooeem/status/2037250422403113188)
>
Articles on workflows (bookmark these for later):
> **hoeem@hooeem**: [原文链接](https://x.com/hooeem/status/2020522623134822537)
>
> **Ronin@DeRonin_**: [原文链接](https://x.com/DeRonin_/status/2043722737080819983)
>
## 14: Testing testing one two three
OpenAI’s prompt-engineering guidance recommends creating evals to monitor prompt performance, especially as prompts become more complex or model snapshots change.
Karpathy's auto research does this on autopilot so I'd learn how to set this up:
> **hoeem@hooeem**: [原文链接](https://x.com/hooeem/status/2030720614752039185)
>
## 15: Guardrails
Oi, don't start yawning.
OpenAI describes this as the checks that run alongside agents to check on their inputs + outputs.
Copy and paste this:
```
# Guardrail Architect Prompt
## Role
You are a guardrail and approval-model architect for AI systems.
Your job is to review any prompt, skill, workflow, automation, assistant instruction, agent design, or tool-using system and add appropriate guardrails.
Guardrails are not moral decoration.
They are engineering controls.
A guardrail defines what the system must:
- allow
- block
- flag
- ask
- refuse
- validate
- escalate
- log
- stop
Your goal is to make the system safer, more reliable, more controllable, and less likely to cause damage when it has access to tools, external actions, sensitive information, current information, or ambiguous instructions.
---
# Core principle
A chatbot can be wrong.
A tool-using system can be wrong and do something.
Therefore, every action-taking AI system needs an approval model.
Do not simply say:
> Be careful.
Instead, define:
- what the system may do without approval
- what requires user approval
- what is forbidden
- what must be validated
- what must be escalated
- what must stop the workflow
- what to do when uncertain
---
# Input I will provide
I will paste one of the following:
- A prompt
- A custom GPT instruction
- An agent workflow
- A tool-using system
- An automation spec
- A research workflow
- A content workflow
- A coding workflow
- A data-processing workflow
- A business process
- A partially written skill
Your task is to add the right guardrails.
---
# System to review
text
[PASTE THE PROMPT / WORKFLOW / SKILL / AGENT SPEC HERE]
```
Analyse it and ensure there's a guardrail layer:
1. Identify the system’s purpose.
2. Identify what actions it can take.
3. Classify the risk level of each action.
4. Decide which actions are allowed without approval.
5. Decide which actions require approval.
6. Decide which actions are forbidden.
7. Add input guardrails.
8. Add output guardrails.
9. Add tool guardrails.
10. Add data/privacy guardrails.
11. Add scope guardrails.
12. Add cost/usage guardrails.
13. Add stopping conditions.
14. Add uncertainty rules.
15. Add escalation rules.
16. Create a copy-paste guardrail policy that can be inserted into the original prompt.
You don't want your agent deleting all your emails or something dumb.
## 16: Image prompting
I believe this is an important skill set as an AI engineer.
Especially with how useful it is for everything you do.
OpenAI’s image-generation guidance describes GPT image models as capable of generation and editing from prompts, and its prompting guidance focuses on controllability, deliverable clarity and production-oriented outputs.
That means the prompt should describe the deliverable, not just the scene.
Here's a template to follow:
```
Goal:
What the image is for.
Deliverable:
Poster, infographic, carousel slide, thumbnail, product mockup or storyboard.
Canvas:
Aspect ratio, pixel size and orientation.
Audience:
Who will see it.
Subject:
What appears.
Composition:
Layout, framing and hierarchy.
Style:
Visual language, texture, typography and mood.
Text:
Exact words, placement and hierarchy.
Constraints:
What must not change and what to avoid.
Iteration:
One controlled change at a time.
```
## 17: Multimodal prompting
I no longer give my AI only text.
I also give it:
- screenshots
- charts
- PDFs
- spreadsheets
- images
- diagrams
- audio transcripts
- UI mockups
- code files
- documents
- slide decks
I then tell the model what kind of reading to perform.
## 18: Building your AI engineering stack
I am proud of this section as this is where the course comes together because the goal is to build reusable AI systems.
Now the following can be an article itself so if you're tired.
Bookmark this post. Come back to this bit later.
I can't create this article on "becoming an AI engineer" and make it a 15 minute read.
Here's the full stack in action:
How do you get started? First ask yourself:
1. What task is this system for?
2. What outcome should it produce?
3. What context does it need?
4. What output format is useful?
5. Does it need external sources?
6. Does it need tools?
7. Should it be a workflow or an agent?
8. How will quality be evaluated?
9. What needs approval?
10. What should be logged and improved?
Once you have that you can begin...
## Step 1: define the purpose layer
The purpose layer answers one question:
> What is this AI system actually for?
Most weak AI systems fail here because the purpose is vague.
Bad purpose:
> Help me with research.
Better purpose:
> Turn messy source material into accurate, structured research briefs that I can use to write articles, make decisions or create content.
Your purpose layer should define:
System name:
[Name of your AI system]
Primary job:
This system helps me [do what task] by [how it helps].
User:
This system is for [me / my team / my clients / my audience].
Main output:
The system produces [briefs / drafts / analyses / plans / reports / images / decisions / summaries].
Success looks like:
A good output is [accurate / useful / structured / specific / sourced / ready to publish / ready to review].
This system does not:
It does not [send / publish / delete / spend / make final decisions / invent sources / operate without approval].
Example purpose statements
For research:
> This system turns messy notes, articles and source material into structured research briefs with clear findings, source hierarchy, uncertainty and content angles.
For content:
> This system turns raw ideas into publishable article drafts, social posts and visual concepts while preserving my tone, standards and positioning.
For operations:
> This system turns incoming information into prioritised tasks, summaries, decisions and follow-up actions, with approval required before anything is sent or changed.
For learning:
> This system helps me learn a topic by breaking it into lessons, examples, checks for understanding and progressive exercises.
## Step 2: define the prompt layer
The prompt layer defines how the model should behave.
This is where classic prompt engineering still matters.
But it is not enough to say:
> Act as an expert.
You need to define:
- role
- job
- standards
- decision rights
- boundaries
- uncertainty behaviour
Plug-and-play prompt layer
Role:
You are my [role].
Job:
Your job is to [specific responsibility].
Primary standard:
Prioritise:
1. [standard 1]
2. [standard 2]
3. [standard 3]
4. [standard 4]
You are allowed to:
- [allowed action]
You are not allowed to:
- [forbidden action]
When uncertain:
If information is missing, weak or ambiguous, you must [ask / state assumptions / give conditional answer / lower confidence].
Reasoning style:
Think carefully before answering. Do not provide a long chain-of-thought. Give the conclusion, key reasoning checkpoints, assumptions, uncertainty and verification path.
Prompt layer template
> You are my [role].Your job is to [specific responsibility].Prioritise:[standard 1]
> [standard 2]
> [standard 3]
> [standard 4]
> You may:[allowed action]
> [allowed action]
> [allowed action]
> You may not:[forbidden action]
> [forbidden action]
> [forbidden action]
> If information is missing or uncertain, you must [ask / state assumptions / flag uncertainty / provide conditional answer].When explaining decisions, do not provide a long chain-of-thought. Provide the conclusion, key reasoning checkpoints, assumptions, confidence and verification path.
## Step 3: define the context layer
The context layer is what the model needs to know to do the job properly.
Most people underbuild this layer.
They ask for high-quality output while giving the model almost no useful context.
The context layer should include:
Plug-and-play context layer
Goal context:
The goal of this task is [goal].
User / audience context:
This is for [person / audience / customer / reader].
Project context:
This belongs to [project / business / content system / research workflow].
Source material:
Use the following sources, notes or files: [source material].
Preferences:
Follow these preferences: [tone, style, depth, format, examples].
Constraints:
Respect these constraints: [length, scope, platform, legal, factual, technical, brand].
Decision history:
These decisions are already locked: [decisions].
Known failure modes:
Avoid: [generic output, hallucinated sources, weak examples, verbosity, overconfidence, tone drift].
Context pack template
> Goal:
> [What we are trying to achieve]User / audience:
> [Who this is for]Project context:
> [What this task belongs to]Source material:
> [Documents, notes, examples, URLs, files or data]Preferences:
> [Tone, style, depth, examples, format]Constraints:
> [Rules, limits, exclusions]Locked decisions:
> [Decisions already made]Known failure modes:
> [What usually goes wrong]
## Step 4: define the output layer
The output layer controls what the model returns.
Do not leave this vague.
Bad output instruction:
> Give me the answer.
Better output instruction:
> Return a structured answer with summary, assumptions, recommendation, risks, next steps and confidence.
The output format depends on how you will use the answer.
Plug-and-play output layer
Primary format:
Return the output as [Markdown / table / checklist / JSON / brief / report / draft].
Required sections:
Include:
1. [section 1]
2. [section 2]
3. [section 3]
4. [section 4]
Confidence:
Include confidence level: low, medium or high.
Uncertainty:
Flag anything uncertain, missing or assumed.
Actionability:
End with clear next steps.
Markdown output template
> Return the answer in this structure:Summary
> Main recommendation
> Key reasoning checkpoints
> Assumptions
> Risks
> Next steps
> Confidence level
JSON output template
Use this when another system needs to parse the answer:
```
{
"summary": "",
"recommendation": "",
"key_points": [],
"assumptions": [],
"risks": [],
"next_steps": [],
"confidence": "low | medium | high"
}
```
Use this for stricter output control:
```
{
"type": "object",
"properties": {
"summary": {
"type": "string"
},
"recommendation": {
"type": "string"
},
"key_points": {
"type": "array",
"items": {
"type": "string"
}
},
"assumptions": {
"type": "array",
"items": {
"type": "string"
}
},
"risks": {
"type": "array",
"items": {
"type": "string"
}
},
"next_steps": {
"type": "array",
"items": {
"type": "string"
}
},
"confidence": {
"type": "string",
"enum": ["low", "medium", "high"]
}
},
"required": [
"summary",
"recommendation",
"key_points",
"assumptions",
"risks",
"next_steps",
"confidence"
],
"additionalProperties": false
}
```
## Step 5: define the retrieval layer
The retrieval layer controls external knowledge.
Use retrieval when the model needs information beyond the prompt.
This includes:
- current information
- private files
- company documents
- research papers
- product specs
- laws or regulations
- prices
- schedules
- uploaded files
- knowledge bases
- previous notes
Do not rely on model memory for current or source-sensitive claims.
Plug-and-play retrieval layer
Use retrieval when:
- information may have changed
- source verification is required
- the answer depends on files, documents or external data
- the model needs evidence
- factual accuracy matters
Do not use retrieval when:
- the answer can be completed from supplied context
- the task is pure rewriting
- the task is brainstorming
- the user explicitly says not to browse or search
Source hierarchy:
Use sources in this order:
1. [highest-authority source]
2. [second-best source]
3. [third-best source]
4. [weak signal source]
Citation rule:
Cite sources for claims that are current, factual, disputed or high-stakes.
Conflict rule:
If sources disagree, explain the disagreement and prefer the highest-authority source.
Missing source rule:
If no reliable source is available, say so and lower confidence.
Retrieval policy template
> Use retrieval when the answer depends on current, external, private or source-sensitive information.Source hierarchy:Official documentation or original source
> Primary research or regulator
> Reputable expert analysis
> Major publication
> Community discussion as weak signal only
> If sources conflict, explain the conflict.If no reliable source is found, say so.Do not invent sources.Include citations when factual claims depend on retrieved information.
## Step 6: define the tool layer
The tool layer controls what the model can do.
A tool could be:
- web search
- file search
- calculator
- code execution
- database lookup
- calendar access
- email drafting
- document editing
- CRM lookup
- image generation
- API call
- browser automation
- spreadsheet analysis
The tool layer needs a permission model.
The question is not just:
> What tools can the model use?
The real question is:
> What tools can the model use, under what conditions, with what approval?
Plug-and-play tool layer
Available tools:
The system may use:
- [tool 1]
- [tool 2]
- [tool 3]
Use tools when:
- [condition]
Do not use tools when:
- [condition]
Allowed without approval:
- [safe action]
Requires approval:
- [risky action]
Forbidden:
- [forbidden action]
Tool failure behaviour:
If a tool fails, the system must explain the failure, continue only if possible and lower confidence.
Tool policy template
> Available tools:[tool]
> [tool]
> [tool]
> Use tools when:the task requires current information
> the task depends on files or private data
> calculation or execution is needed
> an external action is required
> Do not use tools when:supplied context is enough
> the task is pure rewriting
> the task is brainstorming
> Allowed without approval:read approved sources
> summarise
> classify
> draft
> Requires approval:send
> publish
> delete
> buy
> modify records
> contact people
> Forbidden:expose credentials
> bypass access controls
> invent sources
> execute destructive actions without approval
## Step 7: decide workflow or agent
This is one of the most important decisions.
Do not build an agent by default.
An agent is not automatically better than a workflow.
A workflow is better when the path is predictable.
An agent is better when the path must be discovered dynamically.
Plug-and-play workflow template
Workflow name:
[Name]
Trigger:
This workflow starts when [event / user request / schedule].
Inputs:
- [input 1]
- [input 2]
- [input 3]
Steps:
1. [step 1]
2. [step 2]
3. [step 3]
4. [step 4]
5. [step 5]
Human checkpoints:
Approval is required before [action].
Output:
The workflow produces [final output].
Failure handling:
If [failure], the system should [response].
Builder note: workflow pseudo-code
```
workflow [workflow_name]:
trigger: [trigger]
input:
- [input_1]
- [input_2]
steps:
1. [step_1]
2. [step_2]
3. [step_3]
4. [step_4]
approval_required_before:
- [action]
output:
- [final_output]
failure_handling:
- if [failure], then [response]
```
Plug-and-play agent template
Agent name:
[Name]
Goal:
The agent is responsible for [goal].
Available tools:
- [tool 1]
- [tool 2]
- [tool 3]
Planning rule:
The agent must create a short plan before acting.
Action rule:
The agent may take one tool action at a time.
Observation rule:
After each action, the agent must update its understanding based on the result.
Approval rule:
The agent must ask before [risky action].
Stopping condition:
The agent stops when [condition].
Failure condition:
The agent stops and asks for help when [condition].
Final output:
The agent returns [output format].
Builder note: agent loop pseudo-code
```
agent_loop(goal):
plan = create_plan(goal)
while not complete:
next_action = choose_next_action(plan, observations)
if requires_approval(next_action):
ask_for_approval(next_action)
result = execute(next_action)
observations.append(result)
plan = update_plan(goal, observations)
if stopping_condition_met(goal, observations):
complete = true
if failure_condition_met(observations):
stop_and_ask_for_help()
return final_output
```
## Step 8: define the evaluation layer
The evaluation layer tells you whether the system worked.
Without evals, you are judging by vibes.
That is not good enough for repeated or serious workflows.
Plug-and-play evaluation layer
Success criteria:
A good output must be:
- [criterion 1]
- [criterion 2]
- [criterion 3]
- [criterion 4]
Scoring rubric:
Score each output from 1–5 on:
1. Accuracy
2. Completeness
3. Usefullness
4. Format adherence
5. Source quality
6. Specificity
7. Risk control
Pass threshold:
The output passes if it scores [score] or above.
Automatic failure:
The output fails automatically if it:
- invents facts
- invents sources
- ignores the required format
- performs a forbidden action
- misses the core task
- gives high confidence without evidence
## Step 9: define the guardrail layer
The guardrail layer defines what the system must not do.
Guardrails are not there to make the system polite.
They are there to make the system controlled.
Plug-and-play guardrail layer
Allowed without approval:
- [safe action]
Requires approval:
- [risky action]
Forbidden:
- [forbidden action]
Must flag:
- [uncertainty]
- [missing information]
- [weak source]
- [conflict]
- [risk]
Must stop when:
- [stop condition]
Escalation rule:
If the system cannot proceed safely, it must [ask user / pause / return partial answer / request more information].
Guardrail table:
## Step 10: define the logging layer
If you want the system to improve, you need to know what happened.
The logging layer records:
- what task was run
- what input was used
- what prompt version was used
- what tools were called
- what sources were used
- what output was produced
- how it scored
- what failed
- what should be improved
## Step 11: define the improvement layer
The improvement layer turns one-off prompting into an evolving system.
After each use, ask:
Again, I direct you to utilise auto research to support with this (I asked you to bookmark it earlier in this article wink wink):
OKAY OKAY!
## 19: Summary
You've made it! You're now an AI engineer who has gone from only prompting to building better systems with an AI engineer stack.
You can now use the following checklists to ensure you have become an AI engineer:
Prompt quality checklist
- Clear task
- Clear goal
- Audience defined
- Context supplied
- Constraints included
- Output format specified
- Failure modes listed
- Success criteria defined
Context quality checklist
- Goal included
- Relevant background included
- Source material supplied
- Preferences included
- Constraints included
- Irrelevant context removed
- Conflicting context resolved
Output schema checklist
- Correct format chosen
- Required fields defined
- Optional fields handled
- Empty states defined
- No extra keys allowed where needed
- Confidence included where useful
- Errors handled
Retrieval checklist
- External facts require sources
- Source hierarchy defined
- Recency requirement stated
- Conflicting sources handled
- Missing evidence flagged
- Citations included where needed
Tool-use checklist
- Tool purpose clear
- Parameters defined
- When to use tool defined
- When not to use tool defined
- Tool failure behaviour defined
- Approval rules defined
- Logs captured
Workflow vs agent checklist
Use a workflow if:
- steps are predictable
- sources are known
- tools are fixed
- risk is low
- reliability matters more than flexibility
Consider an agent if:
- steps are unknown
- tool choice is dynamic
- open-ended search is required
- iterative planning is needed
- the system can be properly guarded
Eval checklist
- Normal cases
- Messy cases
- Edge cases
- Adversarial cases
- Clarification cases
- Refusal cases
- Scoring rubric
- Failure log
- Regression testing
Guardrail checklist
- Allowed actions defined
- Approval actions defined
- Forbidden actions defined
- Sensitive data handled
- Stop conditions defined
- Escalation defined
- Tool permissions scoped
Image prompting checklist
- Goal
- Deliverable
- Canvas
- Audience
- Subject
- Composition
- Style
- Text
- Constraints
- Iteration instruction
AI engineering stack checklist
- Prompt layer
- Context layer
- Output layer
- Retrieval layer
- Tool layer
- Workflow / agent layer
- Evaluation layer
- Guardrail layer
- Logging layer
- Improvement loop
## BOOM. BOOM. BOOM.
## that's 3 big booms.
maybe I have brainrot?
OH, THIS TOOK ME AGES. ON A DAY WHERE IT IS 27 DEGREES.
SO PLEASE.
IF YOU ARE THERE.
READING THIS.
LEAVE A LIKE OR A REPLY OR SOMETHING PLEASE.
I AM FED UP OF THINKING I'M JUST WRITING TO BOTS.
## 相关链接
- [hoeem](https://x.com/hooeem)
- [@hooeem](https://x.com/hooeem)
- [14K](https://x.com/hooeem/status/2059640615344754947/analytics)
- [May 16](https://x.com/shannholmberg/status/2055335043904492011)
- [1.2M](https://x.com/shannholmberg/status/2055335043904492011/analytics)
- [Mar 27](https://x.com/hooeem/status/2037250422403113188)
- [Feb 8](https://x.com/hooeem/status/2020522623134822537)
- [783K](https://x.com/hooeem/status/2020522623134822537/analytics)
- [Apr 14](https://x.com/DeRonin_/status/2043722737080819983)
- [Mar 9](https://x.com/hooeem/status/2030720614752039185)
- [601K](https://x.com/hooeem/status/2030720614752039185/analytics)
- [so.Do](https://so.do/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:19 PM · May 27, 2026](https://x.com/hooeem/status/2059640615344754947)
- [14K Views](https://x.com/hooeem/status/2059640615344754947/analytics)
- [View quotes](https://x.com/hooeem/status/2059640615344754947/quotes)
---
*导出时间: 2026/5/28 09:26:49*
---
## 中文翻译
# 如何从提示词工程师进阶为全栈 AI 工程师：
**作者**: hoeem
**日期**: 2026-05-15T17:10:35.000Z
**来源**: [https://x.com/hooeem/status/2059640615344754947](https://x.com/hooeem/status/2059640615344754947)
---
我读过的最糟糕的观点是“提示词工程已死”，它从未消亡，死的是那种认为“仅靠提示词就能解决一切”的思维。所以我创建了一门课程来教你成为一名 AI 工程师，其设计初衷是让初学者和高级用户都能阅读这篇文章，从中学习，并应用它来彻底重塑你目前利用 AI 的方式。
提示词仍然是你与模型之间的接口。
- 糟糕的提示词会产生糟糕的输出。
- 模糊的指令会得到模糊的回答。
- 缺失上下文会导致模型进行猜测。
但是，仅仅掌握提示词素养只是蜻蜓点水，所以是的，我花时间整理并创建了一门完整的课程，带你通过以下内容，从而成为一名 AI 工程师。
（感谢 GPT 生成的表格）
## 1：让我们改变你今天使用 AI 的方式。
我希望你从这种思维方式转变：
> 我有一个任务。
> 我输入这个任务。
> 模型给我一个答案。
> 我凭感觉评判这个答案。
转变为这种思维方式：
> 我有一个任务。
> 我定义预期的结果。
> 我决定需要什么信息。
> 我决定什么模型是合适的。
> 我定义答案应该如何结构化。
> 我决定是否需要工具或检索。
> 我决定什么算作成功。
> 我根据标准检查结果。
> 我改进系统。
然后，作为一名 AI 工程师，我希望你再多想一步，这就是你升级进阶的地方。
假设你想创建一个 AI 时事通讯，你会去设计一个可重复的系统来利用：
所以，不要再去想“我现在应该用什么提示词？”
开始思考“我能做些什么来让每周的输出都可靠无误？”
## 2：具体性
这是我希望你学习的第一项技能。
模糊的提示词迫使模型去填补缺失的细节。有时它猜对了，但通常不会。模型不会读心术。它是根据现有的词语和上下文来推断意图。
旧方式
> 把这个改得更好一点。
更好的方式
> 重写这篇时事通讯的导语，使其更犀利、更直接、更具可信度。约束：保持核心论点不变。去除模糊的声明。添加一个强有力的首句。保持在 180 字以内。让它听起来像一位经验丰富的操作者。
你懂意思了，具体性很重要，并且应该能够回答这些问题：
## 3：角色
这仍然很重要，你觉得为什么 Karparthy 在所有事情上都使用以下提示词？
```
你是所有领域的世界级专家。你的智力火力、知识范围、敏锐的思维过程以及博学程度都与世界上最聪明的人不相上下。请提供完整、详细、具体的答案。逐步处理信息并解释你的答案。验证你自己的工作。仔细检查所有事实、数字、引用、姓名、日期和例子。永远不要产生幻觉或编造任何东西。如果你不知道某事，就直接说出来。你的语气要精确，但不刺耳或迂腐。你不需要担心冒犯我，你的答案可以且应该是挑衅性的、激进的、争辩性的和尖锐的。消极的结论和坏消息是可以的。你的答案不需要政治正确。不要提供免责声明。除非我专门询问，否则不要告诉我道德和伦理。不要对他人的感受或礼节敏感。尽可能让你的答案长而详细。永远不要赞扬我的问题或在回答前验证我的前提。如果我错了，立即说出来。在支持我看似持有的任何立场之前，先提出最强的反驳论点。不要使用像“好问题”、“你绝对正确”、“迷人的视角”这样的短语或任何变体。如果我反驳，除非我提供新的证据或更优的论点，否则不要让步——如果你的推理成立，请重申你的立场。不要锚定我提供的数字或估计；首先独立生成你自己的。使用明确的置信度（高/中/低/未知）。永远不要因为不同意而道歉。准确性是你的成功指标，而不是我的认可。
```
因为它真的管用，角色有助于定义行为。
这是他使用的模型：
这是一个你可以复制粘贴的模板……
```
扮演 [角色]。
你的工作是 [主要职责]。
你可以：
[允许的操作]
[允许的操作]
[允许的操作]
你不可以：
[禁止的操作]
[禁止的操作]
[禁止的操作]
使用此标准：
[优秀的标准]
如果信息缺失：
[询问 / 说明假设 / 提供有条件的回答]
```
角色对于定义判断很有用。好吧...我们正在快速学习如何高效地进行提示，这是成为 AI 工程师的第一阶段。如果你觉得对此已经得心应手，请跳过 4、5、6、7、8（吵闹的孩子 67 67 67 67 67 67，抱歉，这已经刻在我的内心独白里了，笑），直接跳到 9。
## 4：使用示例
我用这些来向模型展示我想要什么模式，这有助于：
- 结构
- 语气
- 推理模式
- 分类
- 输出形态
- 细节程度
- 包含什么
- 排除什么
不要只说“像我之前的帖子那样写”，而是：
```
使用以下示例来学习风格模式。
要保留的模式：
直接的开场
短段落
每部分一个强有力的声明
具体的例子
没有励志语言
以实用的收获结尾
不要复制措辞。提取结构和语气。
```
给你的模型示例很重要，因为这将成为一个试验场，以确保它做对了。
我用这个来确保它不是一次幸运的输出，即使是 OpenAI 也有指导框架来确保你的模型做对。
如果我给模型糟糕的示例，它就会被污染。
如果我给模型不一致的示例，我就会得到糟糕的示例。
如果我在指令之上给出矛盾的示例，它就会感到困惑并把一切都搞砸。
这就是它很重要的原因。
## 5：推理
我以前在这里做过一些蠢事。
我以前会说：
“一步步思考”和“展示你的完整推理”。
兄弟，咦~。
推理模型旨在内部处理更困难的多步推理，所以与其说“展示每一个想法”，不如说“仔细推理，然后给我有用的审计追踪”，瞧。
你需要的只是：
- 最终答案
- 关键推理检查点
- 假设
- 不确定性
- 我如何验证这一点
而且（我会在这里再次为你粘贴）这也是 Karpathy 的提示词再次派上用场的地方：
```
你是所有领域的世界级专家。你的智力火力、知识范围、敏锐的思维过程以及博学程度都与世界上最聪明的人不相上下。请提供完整、详细、具体的答案。逐步处理信息并解释你的答案。验证你自己的工作。仔细检查所有事实、数字、引用、姓名、日期和例子。永远不要产生幻觉或编造任何东西。如果你不知道某事，就直接说出来。你的语气要精确，但不刺耳或迂腐。你不需要担心冒犯我，你的答案可以且应该是挑衅性的、激进的、争辩性的和尖锐的。消极的结论和坏消息是可以的。你的答案不需要政治正确。不要提供免责声明。除非我专门询问，否则不要告诉我道德和伦理。不要对他人的感受或礼节敏感。尽可能让你的答案长而详细。永远不要赞扬我的问题或在回答前验证我的前提。如果我错了，立即说出来。在支持我看似持有的任何立场之前，先提出最强的反驳论点。不要使用像“好问题”、“你绝对正确”、“迷人的视角”这样的短语或任何变体。如果我反驳，除非我提供新的证据或更优的论点，否则不要让步——如果你的推理成立，请重申你的立场。不要锚定我提供的数字或估计；首先独立生成你自己的。使用明确的置信度（高/中/低/未知）。永远不要因为不同意而道歉。准确性是你的成功指标，而不是我的认可。
```
好吧...继续 :).
## 6：输出控制
我根据手头的任务使用输出控制。
如果我能回答“这是给谁看的？”，那么我就能决定我想要的输出。这是我使用的一张表，你可以拿去用：
OpenAI 的结构化输出可通过函数调用和 JSON 模式响应格式获得；重点不仅仅是要求“有效的 JSON”，而是在支持的情况下将输出限制为定义的结构。Google 的 Gemini API 也记录了结构化输出支持，包括在支持的模型中与工具一起使用。
这是一个 JSON 模式示例：
```
{
"type": "object",
"properties": {
"answer": {
"type": "string"
},
"confidence": {
"type": "string",
"enum": ["low", "medium", "high"]
},
"assumptions": {
"type": "array",
"items": {
"type": "string"
}
},
"risks": {
"type": "array",
"items": {
"type": "string"
}
},
"next_steps": {
"type": "array",
"items": {
"type": "string"
}
}
},
"required": ["answer", "confidence", "assumptions", "risks", "next_steps"],
"additionalProperties": false
}
```
不要把看起来很酷的输出与可靠的输出混淆。
针对手头的工作使用输出。
## 7：迭代与跟进
你的模型有没有一开始就给你完美的答案？我的没有，哈哈。
旧方式
> 再试一次。做得更好。
更好的方式：
```
修改之前的答案。
保留：
结构
主要结论
实用语气
更改：
使例子更具体
减少重复
添加更强的开场
去除通用的 AI 语言
不要：
添加引用
让它变长
更改目标读者
```
所以当你想要做出改变时，请思考：
## 8：约束
约束不是可选的。
它们是任务的一部分。
为什么？模型不知道边界，需要被定义。
我以前经常搞错，说：
“不要听起来像 AI”或“不要无聊”
这很糟糕，这是一个更好的框架：
避免：
- “在当今快节奏的世界”
- “值得注意的是”
- “这不是 X，而是 Y”
- 没有例子的模糊声明
- 破折号
- 励志的结尾句
这是你应该设定的边界：
1. 风格
2. 范围
3. 证据
4. 权威性
5. 安全性
6. 输出
7. 时间
8. 质量
这是我为你准备的模板：
```
Constraints:
[规则]
[规则]
[规则]
Do not:
[禁止的模式]
[禁止的模式]
If you cannot comply:
explain why
provide the closest valid alternative
```
当你创建工作流时，这些约束将成为你的护栏，这是一个例子：
```
{
"allowed_actions": ["summarise", "draft", "classify", "rank"],
"requires_approval": ["send_email", "publish_post", "delete_file"],
"forbidden_actions": ["invent_sources", "expose_private_data", "make_payment"]
}
```
## 9：上下文工程
提示词问的是：
> 我应该对模型说什么？
上下文工程问的是：
> 模型需要知道什么才能把工作做好？
Anthropic 将上下文工程描述为一门新兴的学科，用于构建可引导、高效的智能体，强调在任务期间向模型提供什么信息。
如果我不给它我的目标、偏好、示例、原始材料、约束、评分标准或过去的决定，那么它就会替我猜测，并把一切都搞砸。
这会帮到你（它帮到了我）：
注意：上下文是很昂贵的。
过长的不必要的上下文会稀释注意力，增加成本，并在工作中产生冲突。
更多的上下文 ≠ 更好的上下文。
确保你遵循：
```
Goal:
我们要努力实现的目标。
Reader / user:
这是给谁的
Background:
模型需要知道什么。
Source material:
文档、笔记、示例、URL 或数据。
Preferences:
风格、语气和标准。
Constraints:
规则和限制。
Success criteria:
如何判断输出。
Known failure modes:
通常哪里会出错。
```
## 10：检索
如果答案取决于事实，模型需要来源。
这是仅靠提示词的可靠性失效的地方。
你无法仅靠措辞来解决事实上的不确定性。
确保你给它好的来源：
如果是它自己找的，那就让它对它们进行排名：
```
按此顺序使用来源：
1：官方文档
2：主要研究 / 原始论文
3：标准机构 / 监管机构
4：信誉良好的专家分析
5：新闻报道
6：社区讨论
如果来源有冲突：
1：解释冲突
2：优先考虑权威最高的来源
3：说明置信度
```
检索意味着系统可以搜索或获取模型内部记忆之外的信息。
这可以包括：
- 网络搜索
- 文件搜索
- 数据库搜索
- 文档检索
- 向量搜索
- 关键词搜索
- 知识库查找
- 引文检索
检索清单：
在使用检索之前，请问：
- 什么问题需要外部证据？
- 允许什么来源？
- 首选什么来源？
- 信息必须有多新？
- 模型应该引用、引用还是总结？
- 如果来源冲突应该怎么办？
- 如果找不到来源应该怎么办？
## 11：工具使用和函数调用
这就是 AI 开始做事而不仅仅是说话的地方。
函数调用允许模型将自然语言连接到外部工具或 API。OpenAI 将函数调用描述为模型与外部系统交互并访问训练数据之外的数据的一种方式。Google 的 Gemini API 也将函数调用记录为模型确定何时调用函数并提供结构化参数的一种方式。
这是工具层：
## 12：MCP 和连接的 AI 工作流
这就是我连接 X、Y 和 Z 的方式，也就是说连接到文件、数据库、API、工具和工作流。
模型上下文协议 (MCP) 是一种将 AI 应用连接到外部数据源和工具的开放标准。Anthropic 在 2024 年引入了 MCP，作为数据源与 AI 驱动的工具之间安全、双向连接的标准，官方 MCP 文档将其描述为连接 AI 应用与数据、工具和工作流的一种方式。
这是理解这部分的方法：
这是用例：
连接的上下文会产生风险。
官方 MCP 安全最佳实践页面指出了 MCP 实施的安全风险、攻击向量和最佳实践。
1. 不要连接所有东西。
2. 不要信任每个工具。
3. 不要允许静默的高风险操作。
4. 不要假设工具描述是无害的。
## 13：任务链、工作流、a