一、一句话先说清楚什么是 Context EngineeringContext Engineering上下文工程就是在调用大模型的每一次请求中系统性地设计、组织、压缩和管理送入上下文窗口的全部信息让模型在有限的视野内看到最该看到的、最准确的、最不冗余的内容从而最大化输出质量。如果你觉得这个定义有点抽象用一个比喻来理解大模型是一个超级聪明但只有 7 秒记忆的金鱼。每次你跟它说话它都从头开始只能看到你这次喂给它的那一缸水。Prompt Engineering 教你怎么跟金鱼说话——措辞、语气、结构。而 Context Engineering 教你怎么往鱼缸里放水——放什么水、放多少水、什么时候换水、怎么过滤杂质。说得再直白一点Prompt Engineering关注的是怎么说——措辞、句式、角色设定Context Engineering关注的是给什么——信息来源、优先级、压缩、检索、生命周期前者是话术后者是信息架构。在 AI Coding 时代后者的重要性正在快速超越前者。二、为什么 Context Engineering 正在取代 Prompt Engineering2.1 Prompt Engineering 的天花板2023 年Prompt Engineering 是最火的 AI 技能。人人都在学Few-shotChain of ThoughtRole Play仿佛只要提示词写得够好大模型就能解决一切问题。但很快现实给了所有人一记闷棍模型变聪明了——GPT-4o、Claude 4、o3 这些模型对提示词的敏感度大幅下降你随便说人话它就能理解。精心设计的 prompt 和随便写的 prompt输出差距从 50% 缩小到 5%。任务变复杂了——从帮我写个函数到帮我重构这个 10 万行的项目提示词再怎么写模型也看不到你的代码库。上下文变大了——从 4K 到 128K 再到 1M token窗口越来越大但塞满窗口≠用好窗口。这就引出了一个关键问题当模型本身足够聪明、窗口足够大时瓶颈不再是怎么说而是给什么。2.2 Context Engineering 的崛起2025 年Anthropic、OpenAI、Cursor 团队几乎同时开始强调一个概念Context Engineering 才是 AI 应用的核心竞争力。原因很简单大模型应用的本质就是Context → Model → Output这条流水线。模型是固定的你调用 API权重不可改Output 由 Context 决定。所以你能控制的只有 Context。维度Prompt EngineeringContext Engineering关注对象提示词文本本身送入模型的全部信息核心技能措辞、句式、模板检索、压缩、排序、路由信息来源用户手写数据库、代码库、对话历史、工具结果适用场景单轮简单问答多轮对话、Agent、RAG、AI Coding时代背景2023窗口 4K-8K2025窗口 128K-1M比喻跟金鱼说什么话往鱼缸里放什么水一句话总结Prompt Engineering 是说人话的艺术Context Engineering 是喂信息的工程。前者是入门门槛后者是天花板高度。三、上下文的本质大模型的工作记忆到底是什么要理解 Context Engineering必须先理解上下文在大模型内部到底是什么。3.1 上下文窗口一个物理边界大模型的上下文窗口Context Window本质上是注意力机制Attention能覆盖的 token 数量上限。在 Transformer 架构中Self-Attention 的计算复杂度是 O(n²)——上下文长度翻倍计算量翻 4 倍显存翻 4 倍。这就是为什么上下文窗口不能无限大——不是不想是算力和显存扛不住。模型上下文窗口约等于GPT-3 (2020)2K tokens~1.5K 字GPT-4 (2023)8K-128K~6K-96K 字Claude 4 (2025)200K~150K 字Gemini 2.5 Pro1M-2M~75万-150万字通义千问 Long1M~75万字看起来很大但请注意——窗口大 ≠ 能用好。3.2 Lost in the Middle窗口大了但模型看不见2023 年斯坦福大学发表了一篇著名论文《Lost in the Middle: How Language Models Use Long Contexts》。研究发现一个令人震惊的现象当关键信息位于上下文窗口的中间位置时模型的准确率会断崖式下降。模型对开头和结尾的信息记忆最好对中间的信息几乎视而不见。这就是著名的Lost in the Middle效应。它告诉我们塞满窗口不等于用好窗口——你往 128K 窗口里塞了 100K 的文档模型可能只真正看到了前 10K 和后 10K。信息的位置很重要——最重要的信息要放开头或结尾不能埋在中间。信息越少模型越准——在大多数场景下精准的 5K 上下文 冗余的 100K 上下文。这就是 Context Engineering 要解决的核心问题不是塞多少而是怎么塞。四、上下文的六大来源在真实的 AI 应用中送入大模型的上下文远不止用户输入的一句话。它通常由六个来源拼装而成4.1 System Prompt系统提示定义模型角色、行为规范、输出格式的顶层指令。在整个对话中固定不变通常放在上下文最前面。你是一个资深 Python 后端工程师。请遵循以下规范 1. 使用类型注解 2. 添加 docstring 3. 优先使用标准库 4. 代码必须有异常处理4.2 对话历史Conversation History之前的轮次记录。包含用户消息和模型回复是维持多轮对话连贯性的关键。但它会持续增长是上下文膨胀的主要来源。4.3 检索内容Retrieved Knowledge通过 RAG 从向量数据库、知识库、搜索引擎中检索到的相关文档片段。这部分内容动态变化取决于当前查询的相关性。4.4 工具结果Tool ResultsFunction Calling / MCP 调用外部工具后返回的结果——API 响应、数据库查询结果、命令行输出等。这部分内容往往体积大、噪声多是最需要压缩的来源。4.5 代码库上下文Codebase ContextAI Coding 场景特有——当前项目的文件内容、目录结构、类型定义、依赖关系。这部分内容体积巨大一个中型项目动辄几十万行代码不可能全部塞入窗口。4.6 文件附件File Attachments用户上传的图片、PDF、表格、文档等。多模态模型会把图片转成视觉 token 计入上下文。一张高清图的 token 消耗可能相当于数千字的文本。一个典型的 AI Coding 请求上下文可能是这样组装的[System Prompt] ← 2K tokens (角色规范) [Codebase Context] ← 50K tokens (相关文件类型定义) [Retrieved Knowledge] ← 5K tokens (文档检索结果) [Conversation History] ← 20K tokens (前5轮对话) [Tool Results] ← 10K tokens (上次命令行输出) [File Attachments] ← 5K tokens (截图) [User Message] ← 0.5K tokens (当前用户输入) ───────────────────────────────────── Total: ~92.5K tokens看到这个结构你就明白了——用户输入只占上下文的 0.5%99.5% 的内容都需要工程化管理。这就是 Context Engineering 的战场。五、上下文工程的三大核心挑战挑战一塞不下Context Overflow当上下文总量超过窗口上限时要么报错要么被迫截断。截断不当会导致关键信息丢失。典型场景一个 200K 窗口的模型用户给了 50 个文件 30 轮对话 10 次工具调用结果轻松超过 200K。解法滑动窗口只保留最近 N 轮对话早期对话被丢弃或摘要选择性检索只检索当前查询最相关的 top-K 文档片段而不是全部工具结果压缩API 返回 1000 行 JSON压缩成 10 行关键字段文件按需加载不预加载所有文件只在模型需要时动态注入挑战二记不住Lost in the Middle 注意力衰减即使窗口够大模型对中间和早期信息的记忆力也会衰减。对话越长模型越容易忘记之前说过的话、做过的决定。典型场景一个 Agent 执行了 20 步任务到第 15 步时它已经忘了第 2 步做的关键决定。解法关键信息置顶把重要决定、约束条件放在 System Prompt 或上下文开头而不是埋在对话中间定期摘要每隔 N 轮用一个轻量模型对历史对话生成摘要替换原始对话记忆外置把关键信息写入外部存储文件/数据库需要时再检索回来状态显式化把当前任务状态、已完成步骤、待办事项显式写进上下文而不是让模型从对话历史中推断挑战三找不到Relevance Decay上下文里塞了大量信息但真正相关的信息被噪声淹没。模型看到了但没注意到或者被错误信息误导。典型场景RAG 检索了 20 个文档片段只有 3 个真正相关但模型被其他 17 个不相关片段干扰输出了错误答案。解法相关性排序把最相关的信息放在上下文开头和结尾利用 U 型注意力曲线rerank 重排用 Cross-Encoder 对检索结果二次排序过滤低相关性片段上下文去噪只保留文档中包含答案的段落去掉无关的铺垫和过渡信息密度优化用结构化格式表格、列表、JSON代替大段自然语言提高信息密度六、上下文工程的五大核心策略策略一上下文优先级排序Context Prioritization不是所有信息都同等重要。Context Engineering 的第一步是建立优先级体系优先级信息类型放置位置理由P0最高System Prompt、安全约束上下文最前面全局指令不可遗忘P1当前用户输入、任务目标上下文最后面利用结尾注意力优势P2关键检索结果、相关代码紧邻用户输入之前与当前任务强相关P3对话历史摘要System Prompt 之后提供背景但不喧宾夺主P4最低工具结果、日志输出中间位置压缩后参考性信息可裁剪这个排序策略利用了 LLM 注意力的U 型曲线——开头和结尾的信息被关注最多中间的容易被忽略。策略二上下文压缩与摘要Context Compression当上下文膨胀时压缩是第一手段。常见的压缩策略1. 对话历史摘要# 伪代码每5轮对话触发一次摘要 if len(conversation_history) 10: summary llm.summarize(conversation_history[:-5]) conversation_history [summary] conversation_history[-5:]2. 工具结果提取# 原始API返回2000行JSON {data: [{id: 1, name: foo, desc: ..., metadata: {...}}, ...]} # 压缩后5行关键字段 找到 50 条记录前3条 1. foo (id1) 2. bar (id2) 3. baz (id3)3. 代码上下文裁剪# 原始文件500行 class UserService: def __init__(self, db): ... def get_user(self, id): ... def update_user(self, id, data): ... # ... 还有400行 # 裁剪后只保留签名docstring class UserService: 用户服务管理用户CRUD def get_user(self, id: int) - User: ... def update_user(self, id: int, data: dict) - User: ...策略三分层上下文管理Hierarchical Context把上下文分成多个层级每层有不同的生命周期和更新策略层级内容生命周期更新策略L0 永久层System Prompt、角色设定、安全规则整个会话从不更新L1 会话层任务目标、用户偏好、关键决定整个会话显式更新用户修改时L2 滚动层最近 N 轮对话滚动窗口FIFO 淘汰L3 检索层RAG 检索结果、代码库片段单次请求每次请求重新检索L4 临时层工具结果、中间计算单次请求用完即弃这种分层设计让上下文管理变得可预测、可控制而不是一团乱麻。策略四上下文路由Context Routing不是所有信息都需要送入同一个模型。Context Routing 的思路是根据查询类型动态选择送入哪些上下文。def route_context(query, available_contexts): 根据查询类型路由上下文 query_type classify_query(query) if query_type code_edit: return [codebase, conversation_history, user_message] elif query_type knowledge_qa: return [rag_results, user_message] elif query_type debug: return [error_logs, codebase, stack_trace, user_message] elif query_type architecture: return [project_structure, tech_docs, conversation_history, user_message] else: return [user_message]这种按需注入的策略比一股脑全塞高效得多。策略五上下文生命周期管理Context Lifecycle上下文不是静态的它有自己的生命周期创建 → 使用 → 衰减 → 压缩/归档/销毁。创建用户输入或工具调用产生新的上下文片段使用送入模型参与注意力计算衰减随着对话推进早期上下文的相关性逐渐降低压缩当上下文总量超过阈值时触发摘要/裁剪归档关键信息写入长期记忆文件/数据库供未来检索销毁不再相关的信息被彻底丢弃一个成熟的 AI Coding 工具如 Cursor、Claude Code内部都有一套精密的上下文生命周期管理引擎只是对用户透明而已。七、AI Coding 场景的上下文工程实战7.1 Cursor 的上下文策略Cursor 是目前 AI Coding 工具中上下文工程做得最好的之一。它的核心策略包括-mention 精准注入用户用文件名手动指定要包含的文件避免不相关代码污染上下文Codebase Indexing把整个代码库做成向量索引用户提问时自动检索最相关的代码片段Replay Checkpoint保留对话历史的关键节点支持回退和分支Composer 上下文在多文件编辑模式下维护一个跨文件的共享上下文7.2 Claude Code 的上下文策略Claude CodeAnthropic 出品的 CLI AI Coding 工具的上下文策略更偏向Agent 模式工具驱动上下文模型通过read_file、grep、glob等工具主动获取需要的上下文而不是预加载上下文自动压缩当对话达到窗口的 95% 时自动触发摘要压缩保留关键信息和任务状态CLAUDE.md 永久上下文项目根目录的CLAUDE.md文件作为永久上下文注入类似 System Prompt 的项目级扩展子 Agent 隔离复杂任务拆分给子 Agent每个子 Agent 有独立的上下文窗口完成后只返回结果摘要给主 Agent7.3 GitHub Copilot 的上下文策略Copilot 的上下文策略更轻量级主打无感体验邻居代码注入自动把当前光标附近的代码、同一文件的其他部分、同项目中被 import 的文件作为上下文Tab 补全优化补全场景用小窗口~2K tokens追求低延迟Chat 场景用大窗口workspace 代码库检索用户显式触发时才做全代码库检索7.4 横向对比策略CursorClaude CodeCopilot上下文获取用户mention 自动索引模型主动用工具获取自动邻居代码压缩策略用户手动管理自动摘要压缩窗口满了就截断代码库检索向量索引强grep/glob精准workspace按需永久上下文.cursorrulesCLAUDE.md.github/copilot-instructions子任务隔离Composer 多文件子 Agent 独立窗口无可以看到不同的 AI Coding 工具本质上是在做不同的 Context Engineering 策略选择。工具之间的差距很大程度上就是上下文管理的差距。八、上下文工程代码实战一个最小可运行的上下文管理器下面是一个用 Python 实现的最小上下文管理器演示了分层管理、自动压缩、优先级排序三大核心策略import json from dataclasses import dataclass, field from typing import Optional dataclass class ContextBlock: 上下文块上下文的最小管理单元 content: str priority: int # 0最高, 4最低 layer: str # permanent/session/rolling/retrieval/temporary token_count: int 0 summary: Optional[str] None class ContextManager: 大模型上下文管理器 MAX_TOKENS 128000 # 上下文窗口上限 COMPRESS_THRESHOLD 0.85 # 达到85%时触发压缩 ROLLING_KEEP 10 # 滚动层保留最近N轮 def __init__(self, system_prompt: str): # L0 永久层 self.permanent [ContextBlock( contentsystem_prompt, priority0, layerpermanent )] # L1 会话层 self.session [] # L2 滚动层 self.rolling [] # L3 检索层 self.retrieval [] # L4 临时层 self.temporary [] def add_message(self, role: str, content: str): 添加对话消息到滚动层 block ContextBlock( contentf{role}: {content}, priority2, layerrolling, token_countself._count_tokens(content) ) self.rolling.append(block) self._maybe_compress() def add_retrieval(self, docs: list[str], query: str): 添加RAG检索结果到检索层 # 每次请求前清空旧的检索结果 self.retrieval.clear() for i, doc in enumerate(docs[:5]): # 只保留top-5 block ContextBlock( contentdoc, priority2 if i 2 else 3, # 前两个高优先级 layerretrieval, token_countself._count_tokens(doc) ) self.retrieval.append(block) def add_tool_result(self, result: str): 添加工具结果到临时层 # 工具结果压缩只保留关键信息 compressed self._compress_tool_result(result) block ContextBlock( contentcompressed, priority4, layertemporary, token_countself._count_tokens(compressed) ) self.temporary.append(block) def build_context(self, user_input: str) - str: 组装最终送入模型的上下文 all_blocks ( self.permanent # L0: System Prompt (最前) self.session # L1: 会话状态 self.retrieval # L3: 检索结果 self.temporary # L4: 工具结果 (中间) self.rolling[-self.ROLLING_KEEP:] # L2: 最近对话 ) # 按优先级排序P0最前同优先级保持插入顺序 all_blocks.sort(keylambda b: b.priority) # 组装上下文文本 parts [b.content for b in all_blocks] parts.append(fhuman: {user_input}) # 用户输入放最后 return \n\n.join(parts) def _maybe_compress(self): 检查是否需要压缩上下文 total sum(b.token_count for b in self._all_blocks()) if total self.MAX_TOKENS * self.COMPRESS_THRESHOLD: self._compress_rolling() def _compress_rolling(self): 压缩滚动层把早期对话摘要化 if len(self.rolling) self.ROLLING_KEEP: return old_messages self.rolling[:-self.ROLLING_KEEP] summary_text | .join( b.content[:100] for b in old_messages ) summary_block ContextBlock( contentf[Earlier conversation summary] {summary_text}..., priority3, layersession, token_countself._count_tokens(summary_text) ) self.session.append(summary_block) self.rolling self.rolling[-self.ROLLING_KEEP:] print(f [Context] 压缩了 {len(old_messages)} 条早期对话) def _compress_tool_result(self, result: str) - str: 压缩工具结果 lines result.strip().split(\n) if len(lines) 20: return result # 保留前5行后5行行数统计 return \n.join([ *lines[:5], f... [{len(lines)-10} lines omitted] ..., *lines[-5:] ]) def _all_blocks(self): return self.permanent self.session self.rolling self.retrieval self.temporary staticmethod def _count_tokens(text: str) - int: 粗略估算token数中文约1.5字/token英文约4字符/token return int(len(text) * 0.6) # 使用示例 if __name__ __main__: cm ContextManager( system_prompt你是一个Python后端工程师。遵循PEP8规范使用类型注解。 ) # 模拟多轮对话 cm.add_message(human, 帮我写一个用户注册接口) cm.add_message(assistant, 好的我需要了解你的数据库schema...) cm.add_message(human, 用的是PostgreSQL表结构是...) # 模拟RAG检索 cm.add_retrieval( docs[FastAPI文档片段..., SQLAlchemy教程片段...], query用户注册接口 ) # 模拟工具调用结果 cm.add_tool_result($ psql -c \\d users\n id | int...\n name | varchar...) # 构建最终上下文 context cm.build_context(好的现在帮我实现这个接口) print(f最终上下文: {len(context)} 字符) print(---) print(context[:500] ...)这个示例虽然简化但包含了 Context Engineering 的核心思想分层管理、自动压缩、优先级排序、按需检索。真实的生产级系统如 LangChain 的 Memory 模块、LlamaIndex 的 Context Store会在这个基础上增加更多精细化的策略。九、常见误区与避坑指南误区一上下文窗口越大越好真相窗口大只是能装更多不等于用得更好。Lost in the Middle 效应告诉我们100K 的冗余上下文可能比 5K 的精准上下文效果更差。信息密度 信息量。误区二把所有文件都塞进去模型自己会找真相模型不是搜索引擎。把 50 个文件塞进去模型会被噪声干扰注意力被分散。正确做法是先用检索找到最相关的 3-5 个文件再精准注入。误区三对话历史越长模型越懂我真相对话历史太长会导致三个问题——窗口溢出、注意力衰减、上下文矛盾早期的错误信息干扰后期判断。定期摘要 关键信息外置才是正解。误区四Prompt Engineering 过时了真相Context Engineering包含Prompt Engineering而不是取代它。System Prompt 的设计、Few-shot 示例的选择、输出格式的约束——这些都是 Context Engineering 的组成部分。只是 Context Engineering 的视野更广不仅管怎么说还管给什么。误区五上下文工程只是 RAG 的另一个名字真相RAG 只是 Context Engineering 的一个子集。RAG 解决的是从外部知识库检索信息而 Context Engineering 还包括对话管理、工具结果处理、代码库索引、上下文压缩、优先级排序、生命周期管理……RAG 是一块拼图Context Engineering 是整幅画。误区六工具返回什么就原样塞进上下文真相工具返回的结果尤其是 API 响应、命令行输出往往包含大量冗余信息——HTTP 头、调试日志、空行、元数据。直接塞入上下文不仅浪费 token还会干扰模型注意力。工具结果必须经过压缩和提取再注入上下文。十、上下文工程的未来无限窗口能解决问题吗有人可能会问等上下文窗口做到 10M、100M tokenContext Engineering 是不是就不需要了答案是否定的。原因有三1. 注意力衰减是架构级的Lost in the Middle 效应源于 Transformer 的 Self-Attention 机制本身。只要底层架构不变窗口再大中间信息被忽略的问题就依然存在。即使有 Flash Attention、Sparse Attention、Ring Attention 等优化也只是降低了计算成本没有改变注意力分布的本质。2. 成本和延迟上下文越长推理成本越高、延迟越大。1M token 的请求可能比 10K token 的请求贵 100 倍、慢 10 倍。在商业场景中用 10K 精准上下文达到 1M 全量上下文的效果就是巨大的竞争优势。3. 信息过载是认知问题即使模型能看到100M token太多信息反而会让模型困惑。就像给人一本 10 万页的百科全书让他找答案不如直接告诉他答案在哪一页。Context Engineering 的本质是信息过滤和聚焦这个需求不会因为窗口变大而消失。未来趋势智能上下文路由用一个小模型决定大模型该看哪些上下文实现按需精准注入持久化记忆系统上下文不再局限于单次会话跨会话的记忆存储和检索成为标配上下文编译像编译器优化代码一样对上下文做预处理——去重、排序、压缩、标注多 Agent 上下文隔离复杂任务拆分给多个 Agent每个 Agent 有独立上下文通过消息传递协调上下文可视化与调试开发者能像调试代码一样调试上下文——看到每次请求的完整上下文、token 分布、注意力热力图十一、总结Context Engineering 是 AI Coding 时代的系统设计能力回到开头的比喻——大模型是一条聪明但健忘的金鱼Context Engineering 就是管理鱼缸水的工程。在这个系列的前 20 篇文章中我们讲了很多概念LLM / Transformer是金鱼本身——它的结构和能力Token / Embedding是水分子——信息的基本单位Prompt Engineering是说话方式——怎么跟金鱼沟通RAG是往鱼缸里加水——从外部知识库检索信息Function Calling / MCP是给金鱼装工具——让它能操作外部世界Agent是让金鱼自主游泳——规划和执行多步任务Skill是给金鱼训练技能——扩展它的能力边界Memory是给金鱼装记忆芯片——跨会话记住信息Temperature是调节金鱼的性格——保守还是发散而Context Engineering就是把所有这些组件组装在一起的总工程——它决定每一次请求中金鱼到底能看到什么水、闻到什么味、感受到什么温度。如果说 Prompt Engineering 是 AI Coding 的第一门元技能那 Context Engineering 就是第二门元技能也是更高级的那一门。因为Prompt Engineering 解决的是怎么说——门槛低天花板也低Context Engineering 解决的是给什么——门槛高天花板也高在模型能力趋同、API 价格趋同的未来AI 应用的竞争力将越来越取决于 Context Engineering 的水平。谁的上下文管理做得好谁就能用更低的成本、更快的速度、更高的质量完成任务。这才是 AI Coding 时代真正的系统设计能力。附录彻底讲透系列文章导航本系列致力于把 AI Coding 时代的每一个核心概念彻底讲透。以下是已发布的全部文章#主题文章链接1LLM 大语言模型LLM彻底讲透从下一个词预测到通用人工智能2Transformer 架构Transformer彻底讲透Attention 凭什么成为AI时代的万能胶水3Token 分词Token彻底讲透大模型读不了一个字的秘密4Embedding 向量嵌入Embedding彻底讲透大模型为什么能把猫和狗理解成近亲5Temperature 温度调节Temperature彻底讲透一个参数如何决定大模型的性格6Prompt Engineering 提示工程Prompt Engineering彻底讲透掌握AI Coding的第一门元技能7Function Calling 函数调用Function Calling彻底讲透大模型动手调用外部世界8Agent 智能体Agent彻底讲透让AI从问答工具进化成能自主干活的智能体9Skill 技能Skill彻底讲透技能如何成为大模型能力的真正放大器10MCP 协议MCP彻底讲透AI Coding的万能接口11RAG 检索增强生成RAG彻底讲透让大模型从胡说八道到言之有据12Fine-tuning 微调Fine-tuning彻底讲透AI开发者必须跨越的分水岭13多模态大模型多模态大模型彻底讲透AI Coding为什么必须学会和多感官模型协作14AI 护栏 GuardrailsAI护栏彻底讲透如何用防呆机制让AI真正可用15Reasoning 推理模型Reasoning模型彻底讲透为什么o1/R1让大模型学会先想再答16Vibe Coding 氛围编程Vibe Coding彻底讲透AI Coding的终极形态到底是什么17Context Engineering 上下文工程本文每篇文章都是独立成篇的但它们之间有千丝万缕的联系。建议从 LLM 和 Transformer 读起建立底层认知再逐步向外扩展。而本文的 Context Engineering正是把所有这些概念串联起来的那条主线——因为无论你用 RAG、Agent、Function Calling 还是 Skill最终都要面对同一个问题怎么把这些信息组织好塞进大模型的上下文窗口。希望这个系列能帮你建立完整的 AI Coding 知识体系。我们下篇见。