我做个人知识库这件事做了快两年。最深的感受就是记笔记的爽感和用笔记的痛苦是成正比的。文件夹建了几十个标签打了几百个真到要用的时候还是 CtrlF 翻半天最后往往翻不到只能靠模糊记忆重新整理一遍。直到我把 Obsidian 的整个 vault 当成工作区交给 Codex 用才开始真正解决“积累归积累、干活归干活”之间的断层。这篇文章我就把整套方案从头到尾写一遍。包括 Codex 和 Obsidian 各自怎么准备、知识库要怎么设计 AI 才读得懂、真实任务里让它“接着你的积累干活”是怎么发生的以及我踩过的几个坑。适合已经把 Obsidian 当主力笔记工具、又想用 AI Agent 类工具干点正事的人参考。如果你还没怎么建过知识库也可以照着搭一套不用掌握什么复杂理论。1. 为什么是“接着你的积累干活”AI 与知识库之间的本质关系先说一个最容易误解的点。很多人以为让 AI 读知识库就是把 AI 的对话框打开、让它“记住”你的全部笔记然后你想要什么它就能答什么。实际上 AI 没有这种能力。现在主流的大模型 Agent比如 Codex它的工作方式是你给我一个目录我在目录里自己逛自己读文件自己调用命令行工具然后基于读到的内容行动。它不会无缘无故知道你硬盘里有什么。1.1 一个老问题笔记越记越多用的时候越难用Obsidian 用户的典型困境是这样的前期热情高涨插件装了几十个双链连得密密麻麻每天往库里塞资料。到了某个临界点笔记多到连自己都搜不动。搜索关键词太宽结果几十篇太窄一篇都出不来。而且笔记里的信息往往是碎片化的搜到了标题还得打开正文重新理解一遍效率跟没记一样。我自己的转折点是开始处理一个拖了很久的项目复盘。当时项目里出过一次线上故障我第二天写了详细的排查记录放到 Obsidian 里就再没看过。两个月后另一个项目出现疑似相同的报错我想把当时的结论调出来花了整整一个晚上从关键词搜到文件浏览愣是没找到。最后还是翻了聊天记录才找到结论。那一刻我意识到笔记系统的价值不在“记录”而在“被调用”。不能被调用的知识本质上是沉没资产。后来我用 Codex 在同一个 vault 里做检索和总结把那个故障记录的标题、标签、关键词结构重新整理了一遍。再遇到同类问题直接问一句“订单超时排查的结论在哪个文件里”它花十几秒就能把路径和要点列出来。这种体验才是“积累有用”该有的样子。1.2 Codex 的工作方式和 Obsidian 的契合点为什么偏偏是 Codex 加 Obsidian而不是别的组合关键在于它们共享同一个文件系统。Obsidian 的 vault 本质就是一个本地文件夹里面全是 Markdown 文件。Codex 这类命令行 Agent天然就是在目录里干活的。你把它启动在 vault 根目录它就能用相对路径读取每一篇笔记能 grep 关键词能按文件名排序能读懂 frontmatter甚至能改文件。这意味着你不需要二次维护一套知识库格式不需要导出 PDF不需要给 AI 做联网接口。你平时怎么写笔记它就怎么读。相比之下其他路线的问题都出在“中间层”。有的做法是把笔记导入向量库做成 RAG 检索听起来高级但多了一道同步和索引的环节索引源头的笔记只要改了格式向量库就要重新切分、重新嵌入维护成本一下子就上来了。还有的做法是把笔记内容手工 Copy 给对话窗口一次只能塞一点上下文爆掉以后照样茫然。Codex 加 Obsidian 走的是“原样读取”的路线从组织方式上说最省事从可靠性上说也不容易失真。当然这不是说嵌入式向量检索不好。我自己的判断是当知识库笔记超过几千篇、且以碎片化记录为主时向量检索会体现出优势但如果笔记以主题型、结构化为主文件系统加关键词检索已经完全够用还能省下大量 token 成本。大多数个人知识库一年下来一两百篇有效笔记远没到需要向量库的地步。先把 Codex 这套轻量方案用起来等规模真不够了再换不会亏。2. 底层逻辑Codex 怎么“读”你的知识库要让 Codex 当好你的知识库管家你得先理解它的“记忆”机制。它不像是装在你脑子里的外挂硬盘它更像一个临时的项目助理当场读什么就记住什么没读过的内容它连名字都不知道。所以知识与它之间的桥梁不是它自己凭空想出来的而是你通过目录结构和文件内容给它铺出来的。2.1 上下文窗口和文件路径AI 的“临时记忆”与“长期记忆”每次和 Codex 对话时它会把你当前对话的所有内容放进上下文窗口包括你给的指令、它读过的文件内容、它自己的推理过程。这个窗口是有上限的。你可以把上下文窗口理解成 AI 的“临时记忆”而你的 Obsidian vault 是“长期记忆”。临时记忆很贵、很短不可能一次性把整个库装进去长期记忆很大、很便宜但需要 AI 去主动读取才能进入临时记忆。这个机制带来一个关键约束你必须让 Codex 知道它该读哪些文件。最直接的办法就是给它文件路径。比如你让它“读一下 notes/projects/2025-06-order-timeout.md”它就会精准地把那篇笔记加载进来。你如果只说“看看关于订单超时的笔记”它可能先去搜索再候选几个文件挑它认为最相关的读。这个过程通常也管用但效率明显更低而且选错文件的概率更高。所以我在知识库设计里一直强调一个原则让文件路径本身就携带信息。一篇笔记叫什么名字放在哪个目录下frontmatter 里写了哪些标签这些都是在帮 Codex 缩小范围。路径即是索引命名即是检索。2.2 检索不是靠魔法四层过滤结构的设计思路Codex 在知识库里找东西走的路径基本是这样的先看当前目录有没有值得扫描的入口文件比如 README 或索引再看具体主题目录下有哪些笔记然后根据用户指令里的线索决定读哪几篇最后在读到的笔记里提取答案。这个过程可以理解成一层一层地“剥洋葱”。基于这个行为模式我把知识库设计成了四层过滤结构。第一层是 vault 根目录的入口页。我会放一个 README.md用三五十行说明这个库有哪些主题分区、每个分区大概放什么、遇到哪类问题该去哪个目录找。Codex 在不确定方向时会先读这个文件做路线参考这对它来说就像一张地图。第二层是各个主题分区的 MOCMap of Content。比如“后端开发”“个人项目”“读书笔记”各有一个 MOC 文件里面列出该分区下的重点笔记和一句话摘要。MOC 是 AI 和人都能快速浏览的目录页它把“一堆文件名”变成“一组有逻辑的入口”。第三层是单篇笔记内部的结构。每篇笔记有 frontmatter、有标题、有结论先行的小节。Codex 读取一篇笔记时能快速通过标题和加粗段落抓住主旨而不是整篇滑动找重点。第四层是代码和配置类内容的额外索引。比如我有个 area/project-config 目录里面存各种项目配置模板我会在目录里放一个>codex --version如果能正常输出版本号说明基础安装没问题。接着是登录。Codex 需要用到账号凭据命令通常是codex login执行后终端会提示你打开浏览器完成授权或者提供一个认证链接。完成授权后凭据会保存在本地的配置目录里之后一段时间内不需要重复登录。如果反复提示登录失败或组织设置加载异常大概率是本地配置目录里的旧凭据过期了或者配置文件里写了一个当前账号不存在的 organization 字段。这时候我建议先检查配置文件把过期的 organization 项去掉重新登录。Codex 允许通过配置文件指定模型。默认情况下使用它自带的模型配置文件通常位于用户目录下的.codex/config.toml位置可以参考官方文档。一个示意配置长这样model gpt-5-codex model_provider openai如果你用的环境支持接入其他模型也可以配成类似下面的形式注意字段名以官方文档为准model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY我自己的习惯是保持默认模型用于日常工作流这样官方的功能更新能直接体验到同时保留第二套备用模型配置。切换时只需改动 config.toml 里的 model 字段启动新对话前确认加载的是哪一套配置文件就行。这里有个容易混淆的概念需要提醒Codex 的“配置文件”和“对话记忆”无关。它只在每次新对话启动时读取配置决定用什么模型、什么服务地址。至于这个对话里它已经读过了哪些笔记都只存在于当前对话的上下文里退出就没了。所以不要指望靠配置文件实现长期记忆长期记忆要靠 Obsidian 的文件结构去承载。3.3 第一个联动测试让 Codex 在库目录里干活环境装好后先做一次小规模测试确认 Codex 真的能读 Obsidian 里的文件。进入 vault 目录cd ~/Documents/knowledge-base codex启动成功后在对话框里输入一个简单指令请列出这个目录下所有的 Markdown 文件按文件夹分组展示并告诉我每个文件夹大致的内容主题。如果 Codex 正常工作它会扫描目录、读取文件名并按你的要求输出分组结果。你不需要让它做多复杂的事只要确认“它能看到文件、能按路径访问”。这一步如果通了后面所有知识库玩法都能往上接。如果它回答得比较概括比如只说了几个顶层目录不要慌这可能是它没有递归逐层扫描。你可以追问一句请仔细查看每个子目录下的文件我需要完整的文件清单。多轮对话在这里优势很明显Codex 会在当前上下文里保留上一个结果然后继续补充。这种“追问”式的用法在后面实操里几乎天天用到。4. 知识库结构设计AI 能读懂、好检索的笔记模板有了环境打底接下来是核心工程把知识库调整成 AI 友好的形态。不是要推翻你原来的笔记习惯而是在现有文件基础上加几个“路牌”让 Codex 知道往哪儿走。4.1 首页与 MOC知识库的目录总入口我在 vault 根目录放一个README.md作用类似于整个库的“总目录页”。Codex 无论接到什么任务如果它不知道从哪儿下手会先看一眼这个文件。所以这份 README 不能只是自我介绍要有明确的导航指引。我的一份简化版长这样# Knowledge Base 这个库用于个人项目积累与技术学习记录。 ## 主题分区 - projects/当前正在进行的项目笔记每个项目一个子目录 - areas/长期维护的领域知识如数据库、运维、前端 - resources/读书笔记、文章摘录、工具评测 - inbox/未整理的临时想法定期清空 - archive/已完结的项目和过时笔记尽量不回头翻 ## 使用约定 - 每篇笔记必须有 frontmatter包含 title、tags、created、updated - 项目笔记先写背景和结论再写过程 - 配置类内容放进 projects/项目名/config ## AI 助手引导 如果你是人类用户让 Codex 来检索这个库建议先读 projects/ 下的 MOC 文件 再用 grep 搜索关键词如果找不到再回到这个 README 确认分区结构。最后这段“AI 助手引导”看起来像是在给 AI 写使用说明其实它确实是。Codex 读取 README 时这段话能帮它快速理解任务路线避免它毫无头绪地全库遍历。各主题分区里的 MOC 同样重要。比如projects/_MOC.md会写成# 项目笔记索引 ## 当前活跃项目 - [[order-service-2025]] 订单服务优化。核心问题超时链路。 - [[api-gateway-refactor]] 网关重构。核心问题鉴权流程。 ## 检索清单 - 超时排查 - order-service-2025/02-timeout-analysis.md - 网关鉴权 - api-gateway-refactor/auth-flow.mdMOC 的题眼是“一句话摘要加路径”。Codex 读到这样的 MOC 就能迅速锁定目标条目而不必把所有项目笔记翻一遍。人眼扫这份 MOC 也很快一举两得。4.2 frontmatter 元数据给 AI 的“路牌”每篇笔记顶部建议写一个标准 frontmatter。Obsidian 原生支持 YAML 格式的元数据Codex 也能直接解析。一个干净的示例--- title: 订单超时问题排查总结 tags: - 订单系统 - 超时 - 故障排查 created: 2025-06-12 updated: 2025-06-20 status: 已完成 ---为什么这组字段够了因为模型读文件时frontmatter 是前几行相当于整个文件的“摘要预告”。title告诉它主题tags告诉它概念归属created/updated帮助它判断时效性status避免它把草稿当定论。标签的用法需要克制。我见过很多笔记的 tags 列了十几个例如 “bug”“问题”“线上”“性能”“优化”“排查”……这种无边界打标的后果是检索时每个词都能命中等于没有命中。我的方法是先定一套固定标签比如按“领域场景状态”打标领域用“订单”“网关”“数据库”这类业务词场景用“故障排查”“性能优化”“方案设计”这类动作词状态用“已完成”“进行中”“草稿”。新增标签前先问一句这个标签能不能在多篇笔记里复用如果只能用在单一笔记上就不要做标签写进正文里就好。4.3 标签与双链保持适度、避免过度设计Obsidian 用户常用的双链[[笔记名]]对 Codex 来说是一把双刃剑。它读正文时能看到[[order-service-2025]]但它不会自动像浏览器一样点开链接阅读目标文件。它只把链接当成普通文本。所以如果你的知识库严重依赖双链表达上下文——比如“结论见 [[某篇笔记]]”——Codex 可能抓不到那个结论。解决办法是重要信息不要只藏在双链的另一端要在当前笔记里写清楚结论再用双链做补充参考。比如写“超时阈值已调整为 500ms详见 [[order-service-2025]]”这样 Codex 就算不去追链接也能拿到核心结论。另一个容易踩的坑是文件名重复。Obsidian 会警告你两个笔记同名但很多人不理会。Codex 读到同名文件时路径就容易发生歧义。我建议文件名保持唯一并带上主题前缀比如projects/order-service-2025/timeout-analysis.md而不是放一个孤零零的timeout.md。文件名一旦能自解释很多检索问题就自动消失了。知识库的设计不必一步到位。你可以先从“给自己看”的笔记改起每次写新笔记时把 frontmatter 补全把项目目录下的 MOC 顺手更新一行。积累到几十篇以后你自然会发现哪些标签有用、哪些目录该合并。AI 友好的结构不是一次装修而是持续生长的房子。5. 实战演示Codex 接管个人知识库中的一个现实任务前面讲了一堆原理这节用一个接近真实的场景完整展示 Codex 怎么把知识库里积累的资料变成可用的答案。我用自己的项目笔记举个例子你替换成自己的笔记内容即可。5.1 任务背景从历史笔记中找回一次故障排查结论假设我的 Obsidian 库里有一个projects/order-service-2025目录里面存了订单服务相关的笔记包括需求文档、配置模板、故障记录。现在遇到一个新问题订单超时率突然升高想确认之前是不是遇到过类似情况当时的结论是用什么方案解决的。按以前的习惯我得凭记忆搜“订单”“超时”这类关键词再一篇篇打开判断相关度。现在直接在 vault 目录启动 Codex输入在 projects/order-service-2025/ 目录里找一找有没有关于订单超时的故障排查笔记。如果有请把当时的背景、根因结论、处理方案、后续验证结果总结一下并标注对应文件路径。第一条指令不用写太长。Codex 会先扫描目录结构找到候选文件后再逐个读取。它会优先匹配文件名带 timeout、超时字样的笔记然后看 frontmatter 里的 tags进一步确认。5.2 Codex 按线索定位笔记、读取内容并给出结论如果路径下有这样一篇笔记--- title: 订单超时排查记录-2025-06-12 tags: [订单系统, 超时, 故障排查] status: 已完成 --- ## 背景 6 月 12 日订单超时率从 0.1% 升到 2.3%主要集中在下单支付回调环节。 ## 根因 支付回调接口在高峰期出现缓慢数据库连接池参数过小导致大量线程 等待获取数据库连接回调请求积压最终触发超时。 ## 处理方案 将连接池最大连接数从 20 调高到 50并增加连接回收检测同时给回调 接口加上独立线程池。 ## 验证结果 调整后超时率在 30 分钟内回落到 0.08%连续观察 72 小时无反弹。 ## 相关链接 [[db-connection-pool-notes]]Codex 读完这篇笔记后会整理出一份简明总结并且大概率会引用原文中的关键句子同时标注这篇笔记的路径。这就是它“读懂了”的直接表现——它不是你问什么就抄什么而是把分散在“背景”“根因”“方案”“验证结果”四段里的信息重新组织成一个连贯回答。如果它给的总结太浅比如只说“这里有一条故障记录”你可以追一层请阅读这篇笔记的详细内容把根因和处理方案展开我判断一下是否适用于当前场景。这一问Codex 就会把那篇笔记完整读进上下文再给出细节。多轮问答在这里非常自然像和一个已经翻了文件的项目助理在说话。5.3 结果验证怎样判断 AI 真的读懂了“读懂了”不是一句抽象评价是可以验证的。我会用三个标准判断回答质量。第一能不能给出来源路径。一个真正读到文件的回答会附带至少一个具体文件路径。如果回答里没有路径我要么催它“来源是哪个文件”要么怀疑它是在凭训练数据里的泛化知识瞎编。第二能不能经受细节追问。比如我追问“当时的连接池参数是从多少调到多少”如果它回答得出来说明它确实读了正文细节而不是只看了摘要。如果答不上来就说“这个问题需要再确认”然后主动去翻文件这是可靠的表现。第三引用的结论是否和笔记原文一致。Codex 在总结长段落时偶尔会加入自己的“合理推测”而这种推测未必是事实。所以如果笔记里有明确的数字如“超时率从 2.3% 降到 0.08%”它输出的数字必须能对上。对不上就需要让它重新读原文并明确要求“只基于笔记内容回答不要推测”。这套验证方法不只是用在故障排查场景任何“让 AI 从知识库里取答案”的任务都适用。不验证AI 就可能在你的知识库里“一本正经地胡说八道”验证了它才是可用的工具。6. 知识入库与日常维护让积累系统持续转下去把这套流程跑通以后真正难的不是用而是持续维护。知识库一旦不更新AI 再聪明也找不到过时问题的答案但更新频率太高人又容易累到放弃。我用的是一套很简单的入库工作流分享出来供你参考。6.1 入库工作流搜集、加工、归档三步第一步搜集。任何一闪而过的想法、看到的有用资料、项目里踩过的坑先丢进inbox目录。这一步不要加工文件名可以乱一点内容可以是大段复制粘贴甚至可以只有一句话。目标是“先捕获不丢失”。第二步加工。每周安排一次统一整理把 inbox 里的临时笔记逐条加工成规范笔记。加工的动作包括改写正文结构、补全 frontmatter、移动到对应主题目录、更新所属领域的 MOC。这里有个小技巧整理笔记时把结论放在最前面。Codex 读长笔记时开头段落就是它的第一判断依据。一篇笔记如果前三行能说清“这是什么、结论是什么、适用于什么场景”AI 后面怎么读都不会跑偏。第三步归档。已经完成、不会再频繁变动的笔记放进archive。归档的意义不仅是让当前目录清爽更重要的是让 Codex 在活跃目录内检索时减少干扰。比如它找“当前订单项目的配置”就不该翻到去年已下线的旧项目笔记。归档就是在告诉 AI这些是历史档案优先级低于活跃内容。这套流程单看很普通但它能跑下去的原因是“不加负担”。你平时该记什么还记什么只是多了每周一次的结构化加工。加工频率太低inbox 会堆积频率太高坚持不了。一周一次对我来说刚好。6.2 Codex 生成内容回填知识库闭环的关键一步Codex 不只是知识库的读者它还可以是作者。我这里特别建议一种用法让 Codex 把一次解决问题的过程“回填”成一篇文章。比如刚才的故障排查Codex 最终给出了完整结论我会接着让它请把刚才的排查结论整理成一篇笔记文件放在 projects/order-service-2025/ 下命名为 timeout-analysis-2025-06-20.md要求包含 frontmatter、背景、根因、处理方案、验证结果并更新 MOC 索引。Codex 会在指定路径生成一篇新 Markdown 笔记。你只需要在发布前快速校对一遍确保它没有扭曲原意、没有把推测写成事实然后这篇笔记就正式进入知识库成为下一次检索的素材。这样做最大的好处是积累不再依赖你手动写总结。项目过程中你已经把关键决策告诉过 Codex它替你把这些零散对话固化成了文件。下次启动一个新的 Codex 会话它又是从这个库开始读之前那次的经验就成了“前车之鉴”。这比任何“记忆插件”都可靠因为记忆被写成了实体。6.3 安全红线什么内容绝不能放进 AI 知识库个人知识库放进 AI Agent 工作流绕不开隐私和安全问题。我给自己定了几条硬规矩建议你也照着检查一遍。第一密码、密钥、Token、API Key 一类凭据绝不进库。如果你确实需要记录这类内容用专门的密码管理器不要在 Markdown 里明文保存。Codex 在使用过程中可能把文件内容发送给模型服务端处理这个行为本身是工作流的一部分但明文密钥一旦被读取风险面就无限放大了。第二工作区里涉及他人隐私的敏感信息尽量脱敏后再入库。比如讨论一个线上 bug完全可以把用户名换成“userA”、订单号改写成“ORD10001”。笔记的功能是沉淀技术结论不是复刻真实生产数据。第三需要长期保密、且和知识检索关系不大的内容我建议放在 vault 之外。例如个人财务记录、家庭地址、身份信息这类高频使用但没必要让 AI 参与的内容单独存一个加密笔记或者干脆不放 Obsidian。知识库不是保险柜它是“半公开的工作台”。安全原则只有一句话凡是你不介意 AI 服务方看到的内容才放进去。先定这个底线后面怎么用都不会太失控。7. 踩坑记录与使用技巧我在实践中遇到的问题最后把实际使用中的几个高频问题集中说一下。这些问题几乎每个人都会遇到写全排查链路不现实但把解决方向讲清楚你遇到时能少翻一会文档。7.1 登录与配置文件最常见的第一道门槛Codex 登录不上是我被问得最多的问题。常见原因有三个版本一个是凭据过期一个是配置文件里残留了不存在的组织字段还有一个是安装后没有重新加载配置。我的排查顺序一般是先执行登录看看有没有明确的报错文案如果登录成功但组织加载失败打开配置文件检查 organization 相关字段是否需要删除或更新然后重启一个新对话确认配置生效。这里要特别提醒Codex 很多配置修改后需要新对话才生效当前对话不会感知配置变更。另外如果你发现自己用了一组好用的自定义模型配置别频繁改动 config.toml。每改一次都要重新验证一次新对话能否正常连接模型服务。切换模型前最好在终端里先跑一个极短的问题测试比如“用一句话说明你现在可用的模型是什么”确认通了再切入正式任务不然容易浪费一两轮 token。7.2 上下文超限和检索不到提示词与文件组织的相互作用个人知识库里最容易出现的问题是上下文超限。一旦你在对话里让 Codex 读了太多大文件它可能忘了前面的内容甚至直接报错。我的办法是把任务拆小。比如先让它列目录再让它确定范围最后才让它精读一两篇。每个步骤输入尽量克制不把“给我找”“给我总结”“给我生成报告”压在同一句话里。检索不到目标文件通常是命名和标签的问题。我在 4.2 里强调过标签复用原则原因就在这里。如果检索不到我会先检查自己的 prompt 里有没有含糊词比如“之前那个项目”“那个问题”这类词 AI 无法对应到具体文件。换用具体领域词加场景词比如“订单 超时 连接池”效果立刻不一样。另外注意别把大型日志或完整文档复制进笔记里。Codex 读文件是按内容全量读的一个 50MB 的日志文本哪怕只是放在库的某个角落也可能把你宝贵的上下文窗口吃掉。日志只保留关键片段完整数据放 vault 之外备份。7.3 让体验更顺滑的几个小配置与收尾心得最后聊几个使用细节。第一我发现把 Codex 的启动目录固定为 vault 根目录并且 alias 成一个短命令能显著降低每次使用的心智负担。比如在 shell 配置里加一行alias kbcd ~/Documents/knowledge-base codex之后每次想跟自己的知识库对话终端里输入kb就够了。第二Obsidian 可以正常开着让 Codex 读文件两边不会冲突但注意不要在 Obsidian 里同时打开一个文件做大量手动保存操作。Markdown 文件本身很小冲突概率极低但为了避免读到写了一半的内容我会在让 Codex 读某个大文件前先确认 Obsidian 那边没有未保存的改动。第三我强烈建议每篇笔记的更新时间在 frontmatter 里记录。Codex 能读 timestamp 字段这会帮助它区分“这篇结论已经过时”和“这篇是有效的”。我自己维护的惯例是每次 Codex 修改或回填笔记时让它顺手更新updated字段。这样长期下来知识库的时效性能维持在一个比较健康的状态。结合这段实操这套 Codex 加 Obsidian 的工作流真正改变的是你处理积累的姿态。以前我总觉得自己记了笔记就该自动有用其实不会。笔记只是混沌的原材料需要一个能按路径、按意图去调用它的执行者。Codex 恰好能扮演这个角色而 Obsidian 最稳定的价值是它把所有积累都留在了本地纯文本里随时可以被任何自动化工具接手不被任何一家厂商的格式绑死。我后来所有的自动化尝试都从这个“文件就是接口”的底座上长出来的。