# 6 AI Concepts You Must Master to Build Production-Ready AI Systems
**作者**: Rahul
**日期**: 2026-06-18T09:29:58.000Z
**来源**: [https://x.com/sairahul1/status/2067540315620405543](https://x.com/sairahul1/status/2067540315620405543)
---
I watched a $200 bill appear on an AWS account overnight.
Not because the system crashed.
An agent ran in a loop for six hours with no stop condition, calling the OpenAI API on every iteration.
Every monitoring dashboard said it was healthy.
Nobody noticed until the invoice hit in the morning.
That is what happens when you build AI systems without understanding how they actually work.
Most people learn AI engineering backwards.
Install a library. Follow a tutorial. Call an API. Get something working. Feel like progress.
Then something breaks in a way that makes no sense.
They change numbers randomly until it stops.
That is not engineering. That's hope with a keyboard.
Here are the 6 concepts that fix this.
## The one sentence that explains everything
Every AI system, no matter how complex, is just:
Memory (RAG) + Thinking (LLM + Tokens) + Actions (Agents) + Measurement (Evals)
…assembled through Context Engineering.
That's the whole field.
Everything below is just unpacking what each part actually means.
## 1. Tokens and the Context Window
LLMs don't read words. They read chunks called tokens.
"engineering" → 1 token
"unbelievable" → 2 tokens Spaces and punctuation count too.
Every model has a context window — a hard limit on tokens it can hold at once.
→ Claude: 200,000 tokens
→ GPT-5: 400,000 tokens
Think of it like a whiteboard in a meeting room.
The model only works with what's currently on the board.
When the board fills up, old notes get erased to make room.
The model doesn't lose the ability to think.
It loses access to the earlier information.
Why this breaks production systems:
→ Tokens cost money — every API call bills per input and output token
→ Long chat histories fill the window fast
→ When context fills up, earlier instructions get silently dropped
→ What goes into context is an engineering decision, not a default
The failure that proves it:
A team built a customer support agent with full 12-month chat history as context on every request.
Worked beautifully in testing with 5 interactions.
In production, after 50 interactions, the agent started ignoring its own system prompt.
The instructions were still there.
They were buried under 80,000 tokens of conversation history.
The model had effectively stopped attending to them.
The fix wasn't a better model.
It was summarizing older history to keep the window focused.
The uncomfortable truth:
Most "prompt engineering failures" are actually token and context window failures in disguise.
Engineers blame the prompt when the real problem is that the critical instruction is on line 3 of a 500-line context, and the model stopped weighting it.
## 2. Embeddings and Vector Search
Embeddings turn meaning into numbers so "similar" can be calculated mathematically.
The problem they solve:
You have 50,000 documents. A user asks a question. You need the 3 most relevant ones — without reading all 50,000 every time.
Keyword search fails here.
If the document says "automobile" and the user asks about "cars," keyword search misses it.
Not because the answer isn't there. Because the words didn't match.
Embeddings solve this differently.
An embedding model converts text into a vector — a list of numbers representing meaning in mathematical space.
Semantically similar text → numerically similar vectors.
"car" and "automobile" → close together
"car" and "photosynthesis" → far apart
How vector search actually works:
1. Every document gets converted to a vector and stored
2. The user's question also becomes a vector
3. The system finds stored vectors closest to the question vector
4. Those are your most relevant documents
This isn't approximate magic. It's geometry.
Similarity is a real mathematical property you can calculate.
Where this shows up in production:
→ Semantic search in any document system
→ Finding similar products, articles, user profiles
→ The retrieval step in RAG (next concept)
→ Memory in AI agents
## 3. RAG (Retrieval-Augmented Generation)
Instead of training a model on your data, you retrieve the relevant data at query time and feed it to the model as context.
The problem RAG solves:
LLMs know a lot. They don't know your data.
Your company's internal docs. Your product database. Your customer support history.
None of that was in the training set.
Two options: train a model on your data (expensive, slow, goes stale instantly) or give the model your data exactly when it needs it.
RAG is the second option, done systematically.
The 3-step pipeline:
→ RETRIEVE:
question becomes a vector → vector database finds the most similar stored documents → top 3-5 chunks retrieved
→ AUGMENT:
retrieved documents get added to the model's context → prompt becomes "using this context, answer this question"
→ GENERATE:
model answers grounded in your actual data — not hallucinated
Where RAG breaks down:
→ Bad retrieval = bad answer. The model can only work with what it received
→ Poor chunking splits the answer from its context
→ The model can still hallucinate if retrieval finds nothing useful
A real RAG failure:
A team built an internal knowledge assistant for a 500-page technical manual.
Worked perfectly in demos. In production, answers were vague and sometimes wrong.
The problem: chunk size.
They'd split the manual into 1,000-token chunks by raw character count.
Tables split mid-row. Step-by-step instructions split mid-step.
The retrieval was finding the right general area — but missing the actual answer.
Halving the chunk size and adding overlap fixed 80% of the problems overnight.
The hard opinion:
RAG is overrated when your retrieval is bad.
The LLM cannot fix bad retrieval. It can only hallucinate around it.
If you're seeing wrong answers, stop tweaking your prompt.
Start measuring your retrieval precision.
That's where the answer is.
## 4. The Agentic Loop
Agents work by repeatedly choosing an action, executing it, observing the result, and deciding what to do next — until the task is done.
A regular LLM call is stateless. You ask, it answers, done.
An agent is stateful. It acts, observes, decides, repeats.
The loop in plain English:
1. Receive a goal
2. Decide the next action
3. Execute it — search, code, read a file
4. Observe the result
5. Decide the next action based on what was learned
6. Repeat until the goal is complete
7. Return the final answer
Tools are what give agents their power.
Without tools, an LLM only responds with text.
With tools, it can search the web, read files, write code, call APIs, trigger any action you define.
Three things beginners always get wrong:
→ Agents without stop conditions run forever. You must define when to stop — step limit, time limit, or goal condition
→ More tools ≠ better performance. Too many tools confuse the model about which to use
→ Tool errors need explicit handling. A silent failure makes the agent confidently produce garbage
The $200 overnight failure, in detail:
The agent had no maximum step count. Its goal: research a topic and produce a summary.
One of its web search tools returned an empty result.
The agent didn't know how to stop.
It kept searching, retrying, generating intermediate summaries — each one triggering another search.
Six hours later: 847 LLM calls. 2.1 million tokens consumed. A coherent-looking but completely circular summary. A $200 invoice.
The fix was three lines: a max step counter, an explicit handler for empty results, an escalation path when confidence was low.
The same agent now completes in under 12 calls on average.
The opinion you need to hear:
Most agents fail not because the model is bad — but because engineers treat the loop like it's self-managing.
It is not.
Guardrails, stop conditions, error handlers — built in from the start, not added after the first incident.
## 5. Evals (Evaluation)
Evals are how you know whether your AI system is actually working — and whether a change made it better or worse.
This is the concept most tutorials skip because it's unglamorous.
It's also what separates engineers who build demos from engineers who build production systems.
The problem without evals:
You change your prompt. Update your retrieval logic. Switch to a newer model.
Did it get better?
You don't know. You could manually check a few examples — but that's a feeling, not evidence.
What evals actually look like:
→ A golden dataset: 25-50 real inputs with known correct outputs, covering main use cases plus 5 known tricky edge cases
→ Binary metrics where possible:
— Did the RAG system retrieve the correct document? Yes/No
— Did the agent complete without error? Yes/No
— Did the response contain the required information? Yes/No
→ Aggregate scores tracked over time:
— Retrieval accuracy: 89% → change made → 84%. Regression found.
— Task completion rate: 76% → new agent version → 81%. Improvement confirmed.
The eval cycle:
Deploy → Measure with evals → Find failures → Add failures to golden dataset → Fix → Run evals again → Compare scores → Ship only if numbers improved
The honest truth:
"Helpfulness: 3.7/5" tells you nothing actionable.
"Retrieved the correct document: 84% of the time" tells you exactly where the problem is and how much a fix improved it.
An AI system without evals is not a product.
It's a demo you cannot confidently change.
## 6. Context Engineering
The discipline of deciding exactly what information goes into the model's context window, how it's structured, and what gets left out.
Here's the opinion that makes people uncomfortable:
Context engineering matters more than prompt engineering.
A mediocre prompt in a well-curated context outperforms a brilliant prompt buried in noise — every single time.
Most teams spend 80% of their optimization effort on the prompt and almost none on the context.
The results reflect that.
The naive approach fails:
Include everything. All the history. All the retrieved documents. Every tool description. The system prompt. The user message. All of it.
This fails for a consistent reason: the model gets confused about what matters most.
There's a documented effect called "lost in the middle" — information buried deep in a long context is less likely to be used.
What context engineering actually involves:
→ Selection: which documents, facts, or history does this specific decision need?
→ Compression: can older parts of the conversation be summarized to save tokens?
→ Ordering: critical instructions belong at the beginning and end — not the middle
→ Pruning: what can be removed without affecting output quality?
→ Structure: headers, separators, labeled sections affect how reliably the model uses information
A practical example:
An agent has been running for 45 minutes. It's accumulated 80,000 tokens of conversation history. Its window is 128,000.
You don't want to lose the original goal and constraints, even as history fills the window.
Context engineering: compress older tool outputs, summarize earlier reasoning, keep the task definition prominent throughout the session.
Prompt engineering is writing good instructions.
Context engineering is building the environment in which those instructions are actually followed.
## How these 6 concepts form one system
MEMORY → RAG + Embeddings (what the system knows)
THINKING → LLM + Tokens + Context Window (how it reasons with what it knows)
ACTIONS → Agentic Loop + Tools (what it can do in the world)
MEASUREMENT → Evals (how you know it's working)
GLUE → Context Engineering (what decides what flows between all of the above)
A simple chatbot is just Thinking.
A customer support agent is Memory + Thinking + Actions.
A reliable production system adds Measurement.
The sophistication is in how well the pieces connect.
The flow for any single request:
User question
→ Context Engineering decides what to include
→ Embeddings retrieve relevant Memory (RAG)
→ Tokens determine how much fits in the window
→ LLM reasons over the assembled context
→ Agentic Loop decides if more information is needed
→ Evals measure whether the output was actually correct
## Where to start
You don't need to master all six at once.
→ Start with tokens and context windows — they affect everything you build → Add embeddings when you need semantic search or memory
→ Learn RAG when you need to ground a model in your own data
→ Learn the agentic loop when you need automation
→ Add evals before you ship anything to production
→ Apply context engineering as everything else becomes intuitive
That sequence isn't arbitrary.
Each concept makes the next one learnable.
## The honest final take
Most teams that struggle with AI in production aren't struggling with the wrong model or the wrong library.
They're struggling because they skipped one of these six concepts.
The agent loops forever because nobody thought about stop conditions.
The RAG answers are wrong because nobody measured retrieval.
The prompt stops working over long sessions because nobody understood how the context window fills up.
These aren't sophisticated problems.
They're basic ones, dressed up in technical vocabulary.
The tools change every six months.
These six concepts are how the tools work.
Learn the concepts, and you'll never be confused by a new tool again.
More importantly — you'll never spend $200 watching an agent loop through the night, wondering what went wrong.
If this was useful:
→ Repost to share it with every AI engineer you know
→ Follow @sairahul1 for more systems and breakdowns like this
→ Bookmark this — you'll reference it the next time something breaks in production
I write about AI, building products, and systems that work while you sleep.
## 相关链接
- [Rahul](https://x.com/sairahul1)
- [@sairahul1](https://x.com/sairahul1)
- [281K](https://x.com/sairahul1/status/2067540315620405543/analytics)
- [@sairahul1](https://x.com/@sairahul1)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [5:29 PM · Jun 18, 2026](https://x.com/sairahul1/status/2067540315620405543)
- [281.6K Views](https://x.com/sairahul1/status/2067540315620405543/analytics)
- [View quotes](https://x.com/sairahul1/status/2067540315620405543/quotes)
---
*导出时间: 2026/6/19 12:34:21*
---
## 中文翻译
# 构建生产级 AI 系统必须掌握的 6 个 AI 概念
**作者**: Rahul
**日期**: 2026-06-18T09:29:58.000Z
**来源**: [https://x.com/sairahul1/status/2067540315620405543](https://x.com/sairahul1/status/2067540315620405543)
---
我眼睁睁看着 AWS 账户里一夜之间多了一张 200 美元的账单。
这不是因为系统崩溃。
而是一个 Agent（智能体）在没有停止条件的情况下循环运行了六个小时，每次迭代都调用 OpenAI API。
每一个监控仪表盘都显示系统状态健康。
直到第二天早上账单发来，才有人发现异常。
这就是在不了解 AI 系统实际运作原理的情况下构建系统会发生的事情。
大多数人对 AI 工程的学习顺序是错的。
安装一个库。跟着教程走。调用一个 API。跑通一个东西。感觉自己在进步。
然后系统以一种莫名其妙的方式崩了。
他们开始随机修改数字，直到问题不再出现。
这不是工程。这是在用键盘许愿。
以下 6 个概念可以解决这个问题。
## 一句话解释一切
每个 AI 系统，无论多复杂，本质上只是：
记忆 (RAG) + 思考 (LLM + Tokens) + 行动 + 测量 (Evals)
……通过上下文工程组装起来。
这就是这一领域的全部。
下面的内容只是为了详细解释每一部分的真正含义。
## 1. Token 和上下文窗口
大语言模型（LLM）不读单词。它们读取被称为 Token 的数据块。
"engineering" → 1 个 token
"unbelievable" → 2 个 token。空格和标点符号也算。
每个模型都有一个上下文窗口——即它能一次性容纳的 Token 数量硬性上限。
→ Claude: 200,000 tokens
→ GPT-5: 400,000 tokens
把它想象成会议室里的白板。
模型只处理当前写在板子上的内容。
当白板写满时，旧的笔记会被擦除以腾出空间。
模型并没有失去思考能力。
它只是失去了对先前信息的访问权限。
为什么这会破坏生产系统：
→ Tokens 需要花钱——每次 API 调用都对输入和输出 Token 计费
→ 长对话历史会迅速填满窗口
→ 当上下文填满时，较早的指令会被悄悄丢弃
→ 放入上下文的内容是一个工程决策，而非默认选项
那个证明这一点的失败案例：
一个团队构建了一个客服 Agent，在每次请求时将完整的 12 个月聊天历史作为上下文。
在 5 次交互的测试中表现完美。
在生产环境中，经过 50 次交互后，Agent 开始忽略它自己的系统提示词。
指令还在那里。
但它们被掩埋在 80,000 个 Token 的对话历史之下。
模型实际上已经停止关注它们了。
解决方案不是更好的模型。
而是总结较旧的历史记录，以保持窗口聚焦。
令人不适的真相：
大多数“提示工程失败”实际上是 Token 和上下文窗口失败的伪装。
工程师们责怪提示词，但真正的问题在于关键指令位于 500 行上下文的第 3 行，而模型已经不再对其加权。
## 2. 嵌入与向量搜索
嵌入将意义转化为数字，以便通过数学计算“相似度”。
它们解决的问题：
你有 50,000 份文档。用户问了一个问题。你需要找到最相关的 3 份——而不想每次都读完所有 50,000 份。
关键词搜索在这里会失效。
如果文档里写的是“automobile”（汽车），而用户问的是“cars”，关键词搜索就会漏掉。
不是因为答案不在那里。而是因为单词不匹配。
嵌入用不同的方式解决这个问题。
嵌入模型将文本转换为向量——一组代表数学空间中意义的数字。
语义相似的文本 → 数值上相似的向量。
"car" 和 "automobile" → 距离很近
"car" 和 "photosynthesis"（光合作用） → 距离很远
向量搜索的实际工作原理：
1. 每个文档被转换为向量并存储
2. 用户的问题也变成向量
3. 系统找到存储的向量中最接近问题向量的那些
4. 这些就是最相关的文档
这不是近似的魔法。这是几何学。
相似性是一个可以计算的真实数学属性。
在生产中的应用场景：
→ 任何文档系统中的语义搜索
→ 查找相似的产品、文章、用户画像
→ RAG 中的检索步骤（下一个概念）
→ AI Agent 的记忆
## 3. RAG（检索增强生成）
不是在你的数据上训练模型，而是在查询时检索相关数据并将其作为上下文提供给模型。
RAG 解决的问题：
LLM 知道很多。它们不知道你的数据。
你公司的内部文档。你的产品数据库。你的客服历史。
这些都不在训练集中。
两个选择：用你的数据训练模型（昂贵、缓慢、瞬间过时）或者在模型需要时精确地提供数据。
RAG 是第二种选择，且做得很有条理。
三步流程：
→ 检索 (RETRIEVE)：
问题变成向量 → 向量数据库找到最相似的存储文档 → 检索出前 3-5 个块
→ 增强 (AUGMENT)：
检索到的文档被添加到模型的上下文中 → 提示词变为“使用此上下文回答这个问题”
→ 生成 (GENERATE)：
模型基于真实数据回答——而非幻觉
RAG 在哪里会出错：
→ 糟糕的检索 = 糟糕的答案。模型只能处理它收到的内容
→ 不当的切分把答案与其上下文分开了
→ 如果检索没找到有用的东西，模型仍然会产生幻觉
一个真实的 RAG 失败案例：
一个团队为一份 500 页的技术手册构建了一个内部知识助手。
演示中非常完美。在生产中，答案含糊其辞，有时甚至是错的。
问题：块大小。
他们按原始字符数将手册切分为 1,000 token 的块。
表格从中间断开。分步指令在步骤中间被切断。
检索找到了大致正确的区域——但错过了真正的答案。
将块大小减半并增加重叠，一夜之间解决了 80% 的问题。
直白的观点：
当你的检索很烂时，RAG 被高估了。
LLM 无法修复糟糕的检索。它只能围绕它产生幻觉。
如果你看到错误的答案，停止调整提示词。
开始测量你的检索精度。
答案就在那里。
## 4. 代理循环
Agent 通过反复选择一个动作、执行它、观察结果、并决定下一步做什么来工作——直到任务完成。
普通的 LLM 调用是无状态的。你问，它答，结束。
Agent 是有状态的。它行动、观察、决策、重复。
用大白话描述这个循环：
1. 接收目标
2. 决定下一个动作
3. 执行它——搜索、写代码、读文件
4. 观察结果
5. 根据学到的东西决定下一个动作
6. 重复直到目标完成
7. 返回最终答案
工具是赋予 Agent 力量的关键。
没有工具，LLM 只能用文字回应。
有了工具，它可以搜索网络、读文件、写代码、调用 API、触发你定义的任何动作。
初学者总是搞错的三件事：
→ 没有停止条件的 Agent 会永远跑下去。你必须定义何时停止——步数限制、时间限制或目标条件
→ 工具更多 ≠ 性能更好。工具太多会让模型困惑该用哪个
→ 工具错误需要显式处理。静默失败会让 Agent 自信地制造垃圾
那笔 200 美元的过夜故障，详情如下：
Agent 没有最大步数限制。它的目标：研究一个主题并生成摘要。
它的一个网络搜索工具返回了空结果。
Agent 不知道如何停止。
它不停地搜索、重试、生成中间摘要——每一个都触发另一次搜索。
六小时后：847 次 LLM 调用。消耗 210 万 Token。一份看起来连贯但完全在循环的摘要。一张 200 美元的账单。
修复方法只有三行代码：一个最大步数计数器、一个空结果的显式处理器、一个低置信度时的升级路径。
同样的 Agent 现在平均在 12 次调用内完成任务。
你需要听到的观点：
大多数 Agent 失败不是因为模型差——而是因为工程师把循环当成自管理的。
它不是。
护栏、停止条件、错误处理器——从一开始就要构建进去，而不是在第一次事故发生后才添加。
## 5. Evals（评估）
Evals 是你了解 AI 系统是否真正有效——以及某个改动是让它变好了还是变差了——的方法。
这是大多数教程跳过的概念，因为它不够光鲜。
这也是区分构建演示的工程师和构建生产系统的工程师的关键。
没有 Evals 的问题：
你修改了提示词。更新了检索逻辑。切换到了更新的模型。
它变好了吗？
你不知道。你可以手动检查几个例子——但这是一种感觉，不是证据。
Evals 实际上是什么样的：
→ 一个黄金数据集：25-50 个带有已知正确输出的真实输入，涵盖主要用例加上 5 个已知的棘手边缘情况
→ 尽可能使用二元指标：
— RAG 系统检索到了正确的文档吗？是/否
— Agent 完成任务时出错了吗？是/否
— 响应包含所需信息吗？是/否
→ 随时间跟踪的汇总分数：
— 检索准确率：89% → 做出修改 → 84%。发现回归。
— 任务完成率：76% → 新 Agent 版本 → 81%。确认改进。
评估周期：
部署 → 用 Evals 测量 → 发现失败 → 将失败加入黄金数据集 → 修复 → 再次运行 Evals → 比较分数 → 仅在数字改进时发布
诚实的真相：
“有用性：3.7/5” 告诉你不了任何可执行的情报。
“检索到正确的文档：84% 的时间” 告诉你确切的问题所在以及修复带来了多少改进。
没有 Evals 的 AI 系统不是产品。
它是一个你无法自信修改的演示。
## 6. 上下文工程
一门决定究竟哪些信息进入模型的上下文窗口、如何构建结构以及舍弃什么的学科。
这里有一个让人不舒服的观点：
上下文工程比提示工程更重要。
精心策划的上下文配上平庸的提示词，总是胜过埋在噪音中的绝妙提示词。每一次都是。
大多数团队将 80% 的优化精力花在提示词上，而几乎不花在上下文上。
结果反映了这一点。
天真的方法会失败：
包括所有东西。所有历史。所有检索到的文档。每个工具描述。系统提示词。用户消息。全部。
这失败的原因很一致：模型搞不清楚什么是最重要的。
有一个记录在案的现象叫“迷失在中间”——被埋在长上下文深处的信息被使用的可能性较低。
上下文工程实际上涉及：
→ 选择：这个特定决策需要哪些文档、事实或历史？
→ 压缩：对话的较旧部分可以被总结以节省 Token 吗？
→ 排序：关键指令属于开头和结尾——而不是中间
→ 剪枝：可以删除什么而不影响输出质量？
→ 结构：标题、分隔符、标记的段落会影响模型使用信息的可靠性
一个实际的例子：
一个 Agent 已经运行了 45 分钟。它积累了 80,000 token 的对话历史。它的窗口是 128,000。
你不想丢失最初的目标和约束，即使历史记录填满了窗口。
上下文工程：压缩旧的工具输出，总结先前的推理，在整个会话中保持任务定义的突出。
提示工程是写好指令。
上下文工程是构建一个真正遵循这些指令的环境。
## 这 6 个概念如何构成一个系统
记忆 → RAG + 嵌入 (系统知道什么)
思考 → LLM + Tokens + 上下文窗口 (它如何推理它所知道的)
行动 → 代理循环 + 工具 (它在世界上能做什么)
测量 → Evals (你怎么知道它在工作)
胶水 → 上下文工程 (决定上述所有之间流动的是什么)
一个简单的聊天机器人只是思考。
一个客服 Agent 是记忆 + 思考 + 行动。
一个可靠的生产系统增加了测量。
精妙之处在于各部分连接得有多好。
任何单个请求的流程：
用户提问
→ 上下文工程决定包含什么
→ 嵌入检索相关记忆 (RAG)
→ Tokens 决定窗口能装下多少
→ LLM 对组装好的上下文进行推理
→ 代理循环决定是否需要更多信息
→ Evals 测量输出是否真的正确
## 从哪里开始
你不需要一次掌握全部六个。
→ 从 Tokens 和上下文窗口开始——它们影响你构建的一切
→ 当你需要语义搜索或记忆时添加嵌入
→ 当你需要将模型建立在你自己的数据基础上时学习 RAG
→ 当你需要自动化时学习代理循环
→ 在向生产环境发布任何东西之前添加 Evals
→ 当其他一切变得直观时应用上下文工程
这个顺序并非随意。
每个概念都让下一个概念变得可学。
## 诚实的最后总结
大多数在生产环境中挣扎于 AI 的团队，不是在纠结于错误的模型或错误的库。
他们挣扎是因为跳过了这六个概念中的一个。
Agent 永远循环是因为没人考虑停止条件。
RAG 答案错是因为没人测量检索。
长时间会话中提示词失效是因为没人理解上下文窗口是如何填满的。
这些不是复杂的问题。
它们是基本问题，披着技术词汇的外衣。
工具每六个月变一次。
这六个概念是工具的运作原理。
学习这些概念，你永远不会再被新工具搞糊涂。
更重要的是——你永远不会为了看 Agent 整夜循环而花掉 200 美元，还纳闷哪里出了问题。
如果有用：
→ 转发给你认识的每个 AI 工程师
→ 关注 @sairahul1 以获取更多类似的系统和拆解
→ 收藏这篇——下次生产环境出问题时你会参考它
我写关于 AI、构建产品以及在你睡觉时运行的系统的内容。