1. 团队经验为什么会“人一走就断档”几乎每个研发团队都经历过这种场景某个核心模块只有老王一个人熟他请假一周线上出问题没人敢动新人入职三个月还在问“这个配置为什么要这么写”同一个坑去年踩过一次今年换了一批人又踩一遍。代码有 Git 管着需求有文档记着唯独“为什么这么做”“当时踩过什么坑”“这个方案被否决的真实原因”这类隐性经验散落在聊天记录、会议纪要和老员工的脑子里随时可能蒸发。腾讯开源的 TeamAI 想解决的正是这件事。它把自己定位成“AI 管理的瑞士军刀”核心思路不是再做一个聊天机器人而是把 AI Agent 嵌进团队日常的协作流里让经验在产生的那一刻就被结构化沉淀下来而不是等到离职交接时才临时抱佛脚。配套的teamai-cli是一个命令行入口把 Agent 能力、Git 工作流、团队知识库串成一条线。这篇文章我会从实际落地的角度把 TeamAI 到底解决什么问题、核心机制怎么运转、怎么一步步接进现有项目、以及我在实操中踩过的坑全部摊开讲清楚。适合读这篇的人有三类一是想给团队引入 AI 协作但不知道从哪下手的技术负责人二是天天和 Git、CI 打交道想搞清楚 AI Agent 到底能帮上什么忙的一线开发三是正在评估“AI Agent 和普通 LLM 调用有什么区别”的工程师。我会尽量少讲概念多讲“这个东西装上去之后你的日常会变成什么样”。2. TeamAI 到底把 AI 放在了团队的哪个位置2.1 它不是又一个聊天窗口而是协作链路上的一个节点大多数人第一次接触 AI Agent脑子里浮现的是一个对话框你问它答。但 TeamAI 的设计逻辑不一样它把自己放在“团队协作链路”上而不是“个人问答工具”上。区别在哪个人问答工具的知识是临时的关掉窗口就没了而 TeamAI 的每一次交互都可以选择性地沉淀成团队共享的经验资产。举个具体例子。新人接手一个模块传统做法是翻文档、问同事。用 TeamAI 的做法是他在项目目录下通过teamai-cli发起一次针对该模块的询问Agent 会结合仓库里的代码、历史提交信息、以及团队之前沉淀的经验条目给出一个带上下文的回答。更关键的是如果这次问答产生了新的有价值结论它可以被标记并回写到团队知识库里下一个人再问同样的问题拿到的就是升级后的答案。这就是“经验自动传承”的真实含义不是靠某个人主动写文档而是让沉淀成为协作过程的副产品。2.2 Agent、LLM、AI 模型三者在这里的分工热词里有个高频问题“agent 和 llm 和 ai 模型有什么区别deepseek 属于哪个”。放到 TeamAI 的语境里这个区分特别重要因为它直接决定了你能用它做什么、不能做什么。AI 模型是最底层的“大脑”比如各类大语言模型它负责理解和生成文本。你可以把它理解成一个博学但失忆的顾问每次对话它都不记得上次说过什么。LLM大语言模型是 AI 模型里专门处理语言的那一类是当前 Agent 能力的主要来源。AI Agent是在 LLM 之上加了一层“手脚”和“记忆”的系统。它知道去哪里查资料、能调用哪些工具、记得之前发生过什么、能按步骤完成一个多步任务。TeamAI 里的 Agent 之所以能“管理团队经验”靠的就是这层记忆和工具调用能力。单纯调一个 LLM你问它“我们项目为什么用这个鉴权方案”它只能瞎猜而 Agent 能去读你的仓库、翻你的提交历史、查你团队沉淀的知识条目然后给出有依据的回答。这个差别是能不能真正落地到团队场景的分水岭。2.3 为什么入口是 CLI 而不是网页teamai-cli选择命令行作为主要入口这个决策我认为非常务实。团队经验产生的高频场景几乎都在开发者的本地终端里提交代码时、排查问题时、review 别人的改动时。如果沉淀经验需要你切到浏览器、登录、找到对应项目、再手动录入那这件事的完成率会低得可怜。CLI 的好处是它能贴着 Git 工作流走。你在git commit前后顺手就能触发一次经验记录不需要离开当前上下文。这种“零切换成本”的设计是经验能不能真正沉淀下来的关键。我见过太多团队买了知识管理工具最后变成僵尸系统根本原因就是录入成本太高。3. teamai-cli 的安装与项目接入实操3.1 环境准备先把 Git 这条地基打牢TeamAI 深度依赖 Git所以第一步不是装 TeamAI而是确认你的 Git 环境是干净的。很多人 Git 装完能用就没管了但后面 Agent 读取提交历史、分析变更时配置不规范会直接导致信息缺失。先确认版本git --version建议 2.30 以上。然后配置基础身份信息这一步新手经常漏git config --global user.name 你的名字 git config --global user.email 你的邮箱如果你用 Gitee 或自建 Git 服务还需要配置密钥。生成密钥的命令是ssh-keygen -t ed25519 -C 你的邮箱生成后把公钥内容贴到对应平台的密钥设置里。这里有个实操心得密钥不要设空密码虽然设了每次推送要输一次但安全性值得。如果你嫌麻烦可以用 ssh-agent 缓存而不是直接留空。提示TeamAI 分析提交历史时作者信息、提交时间、变更范围都是重要输入。如果团队里有人用默认的rootlocalhost提交Agent 在归因经验时会丢失“这是谁的经验”这个维度传承效果会打折。接入前统一规范一遍提交身份收益比你想的大。3.2 安装 teamai-cli 与初始化安装方式通常通过包管理器或直接下载二进制。以常见的 Node 环境为例npm install -g teamai-cli装完后验证teamai-cli --version接着在项目根目录初始化cd your-project teamai-cli init初始化过程会做几件事识别当前仓库、生成配置文件、建立本地经验库的索引。这一步我建议在项目根目录执行而不是子目录否则 Agent 扫描范围会不完整读不到全量提交历史。初始化完成后你会看到一个配置文件里面通常包含模型接入信息、知识库路径、以及 Agent 的行为开关。这里不要急着全开先跑通最小闭环。3.3 第一次跑通让 Agent 读一遍你的仓库初始化后先做一次“冷启动”扫描teamai-cli sync这个命令会让 Agent 遍历仓库的提交历史、目录结构、关键文件建立初始认知。第一次跑会比较慢取决于仓库大小。我实测一个中等规模、两年历史的仓库大概几分钟。跑完之后试着问一个具体问题teamai-cli ask 这个项目的鉴权逻辑是怎么演进的如果 Agent 能结合提交历史给你讲出“某次提交把 session 换成了 token原因是……”说明链路通了。如果它只会泛泛而谈多半是同步没做全或者模型接入配置有问题。注意第一次同步不要贪多先把主分支跑通。有些团队仓库里有大量历史遗留分支和废弃代码全量喂进去反而会稀释 Agent 的判断质量。我的做法是先只同步主分支和近一年的活跃分支。4. 让经验真正“自动传承”的核心机制4.1 经验条目的结构化为什么不能只存聊天记录很多团队尝试过把聊天记录导出当知识库结果基本都失败了。原因很简单聊天记录是非结构化的检索时噪音太大而且没有“这条经验适用于什么场景”的元信息。TeamAI 的做法是把经验拆成结构化条目通常包含几个维度场景描述什么情况下会遇到、结论应该怎么做、依据为什么这么做、关联代码涉及哪些文件或提交。这种结构让 Agent 在检索时能精准匹配而不是靠关键词碰运气。我自己的体会是“依据”这一栏是灵魂。只记“结论”的知识库过半年就没人敢信了因为不知道当时的约束条件还在不在。记了依据后来人才能判断“这个结论现在还成立吗”。4.2 触发沉淀的时机贴着 Git 走经验沉淀最怕“事后补录”。TeamAI 把触发点设计在 Git 操作附近这是它最聪明的地方。几个典型时机提交时一次非平凡的提交往往包含一个决策。可以在提交信息里带上标记让 Agent 自动提取。排查问题时问题解决的那一刻是经验最鲜活的时候此时记录成本最低。代码评审时评审意见里藏着大量“为什么不能这么写”的经验。实操中我建议团队约定一个轻量规则凡是花了超过半小时才解决的问题解决后顺手记一条。不要追求完整先记下来后面可以补。这个习惯坚持一个月知识库的密度就会有质变。4.3 检索与复用新人上手速度的真实变化沉淀是手段复用才是目的。TeamAI 的检索不是简单的全文搜索而是 Agent 结合当前上下文去“理解”你的问题然后从经验库里找最相关的条目。这里有个反直觉的点检索质量高度依赖经验条目的“场景描述”写得够不够具体。如果一条经验的场景描述是“关于缓存的问题”那它几乎检索不到如果写成“用户登录后短时间内重复请求导致缓存击穿”命中率会高得多。所以我在团队里推行的规范是场景描述必须包含“什么条件下”和“什么现象”。新人上手速度的变化我观察下来主要体现在两个环节一是环境搭建和配置类问题基本可以自助解决二是“为什么这么设计”的疑问不用再打扰老员工。这两块省下来的时间累积起来相当可观。5. 实操中踩过的坑与排查链路5.1 同步后 Agent 答非所问从索引查起第一次用的时候我遇到 Agent 回答明显和仓库内容对不上。排查链路是这样的第一步确认同步是否真的完成。查看同步日志发现有几个大文件因为体积超限被跳过了。这些文件恰好是核心配置导致 Agent 对项目理解有偏差。第二步检查索引是否过期。我在同步后又做了几次提交但没重新 syncAgent 读的还是旧索引。第三步确认模型接入是否正常。有时候是模型服务本身响应异常返回了兜底答案。解决办法很直接养成提交后顺手 sync 的习惯或者配置成定时任务。另外对于体积大的关键文件可以单独指定纳入分析而不是让它被自动跳过。5.2 经验条目越积越多反而不好用用了一段时间后知识库膨胀检索质量反而下降。这是典型的“垃圾进垃圾出”。排查下来发现两个问题一是重复条目太多同一个结论被不同人记了好几遍措辞还不一样。二是过期条目没清理比如某个方案后来被推翻了但旧经验还在库里Agent 检索到就会给出错误建议。我的处理方式是引入定期梳理机制每月花半小时过一遍新增条目合并重复的、标记过期的。同时给条目加上“有效期”或“最后确认时间”字段Agent 在检索时优先用较新的。这件事听起来麻烦但比起被错误经验误导的代价完全值得。5.3 团队协作中的权限与边界问题经验库是团队共享的但有些内容涉及敏感信息比如内部架构细节、客户数据。TeamAI 在配置上支持对知识库做范围划分但实操中容易忽略。我的建议是从一开始就划清边界。哪些内容可以进共享库哪些只能留在本地团队要有明确约定。不要等到出了问题再补救。另外Agent 读取仓库时如果仓库里有敏感配置文件要提前排除避免被无意中纳入分析。提示接入前先做一次仓库“体检”把不该被 AI 读取的文件密钥、证书、内部文档通过配置排除掉。这一步花十分钟能省掉后面很多麻烦。6. 把 TeamAI 用出效果的几个关键习惯工具本身只是载体能不能让经验真正传承下去取决于团队的使用习惯。我总结了几条实操中验证有效的做法。第一降低单次记录的门槛。不要要求写得多完整一句话场景加一句话结论就能存。完整度可以后面补但“当时不记事后想不起来”是最大的损失。第二把 Agent 的回答当作起点而非终点。它给的建议要经过人判断尤其是涉及架构决策的。Agent 擅长的是“帮你回忆起当时发生了什么”而不是“替你做决定”。第三定期回看知识库的检索命中率。如果发现很多问题 Agent 都答不上来说明沉淀的场景覆盖不够反过来指导团队该往哪个方向补。第四新人入职第一周就让他用起来。让新人通过提问去熟悉项目同时他的提问本身也是“哪些经验缺失”的信号一举两得。关于扩展方向TeamAI 这类工具后续很可能会和 CI 流程结合得更紧比如在流水线里自动检测“这次改动是否触碰了历史踩坑点”。如果你们团队已经在用 Jenkins 之类的工具可以留意这方面的集成能力。我个人比较期待的是它能把代码评审意见也纳入经验提取那样沉淀的密度会再上一个台阶。最后分享一个我自己的小技巧我会在每次解决完一个棘手问题后用teamai-cli记一条然后在提交信息里引用这条经验的编号。这样以后任何人git blame到这行代码都能顺着编号找到当时的完整决策背景。这个习惯坚持下来代码和历史经验就真正长在了一起而不是两张皮。 TeamAI 实战：用 AI Agent 让团队经验自动传承
1. 团队经验为什么会“人一走就断档”几乎每个研发团队都经历过这种场景某个核心模块只有老王一个人熟他请假一周线上出问题没人敢动新人入职三个月还在问“这个配置为什么要这么写”同一个坑去年踩过一次今年换了一批人又踩一遍。代码有 Git 管着需求有文档记着唯独“为什么这么做”“当时踩过什么坑”“这个方案被否决的真实原因”这类隐性经验散落在聊天记录、会议纪要和老员工的脑子里随时可能蒸发。腾讯开源的 TeamAI 想解决的正是这件事。它把自己定位成“AI 管理的瑞士军刀”核心思路不是再做一个聊天机器人而是把 AI Agent 嵌进团队日常的协作流里让经验在产生的那一刻就被结构化沉淀下来而不是等到离职交接时才临时抱佛脚。配套的teamai-cli是一个命令行入口把 Agent 能力、Git 工作流、团队知识库串成一条线。这篇文章我会从实际落地的角度把 TeamAI 到底解决什么问题、核心机制怎么运转、怎么一步步接进现有项目、以及我在实操中踩过的坑全部摊开讲清楚。适合读这篇的人有三类一是想给团队引入 AI 协作但不知道从哪下手的技术负责人二是天天和 Git、CI 打交道想搞清楚 AI Agent 到底能帮上什么忙的一线开发三是正在评估“AI Agent 和普通 LLM 调用有什么区别”的工程师。我会尽量少讲概念多讲“这个东西装上去之后你的日常会变成什么样”。2. TeamAI 到底把 AI 放在了团队的哪个位置2.1 它不是又一个聊天窗口而是协作链路上的一个节点大多数人第一次接触 AI Agent脑子里浮现的是一个对话框你问它答。但 TeamAI 的设计逻辑不一样它把自己放在“团队协作链路”上而不是“个人问答工具”上。区别在哪个人问答工具的知识是临时的关掉窗口就没了而 TeamAI 的每一次交互都可以选择性地沉淀成团队共享的经验资产。举个具体例子。新人接手一个模块传统做法是翻文档、问同事。用 TeamAI 的做法是他在项目目录下通过teamai-cli发起一次针对该模块的询问Agent 会结合仓库里的代码、历史提交信息、以及团队之前沉淀的经验条目给出一个带上下文的回答。更关键的是如果这次问答产生了新的有价值结论它可以被标记并回写到团队知识库里下一个人再问同样的问题拿到的就是升级后的答案。这就是“经验自动传承”的真实含义不是靠某个人主动写文档而是让沉淀成为协作过程的副产品。2.2 Agent、LLM、AI 模型三者在这里的分工热词里有个高频问题“agent 和 llm 和 ai 模型有什么区别deepseek 属于哪个”。放到 TeamAI 的语境里这个区分特别重要因为它直接决定了你能用它做什么、不能做什么。AI 模型是最底层的“大脑”比如各类大语言模型它负责理解和生成文本。你可以把它理解成一个博学但失忆的顾问每次对话它都不记得上次说过什么。LLM大语言模型是 AI 模型里专门处理语言的那一类是当前 Agent 能力的主要来源。AI Agent是在 LLM 之上加了一层“手脚”和“记忆”的系统。它知道去哪里查资料、能调用哪些工具、记得之前发生过什么、能按步骤完成一个多步任务。TeamAI 里的 Agent 之所以能“管理团队经验”靠的就是这层记忆和工具调用能力。单纯调一个 LLM你问它“我们项目为什么用这个鉴权方案”它只能瞎猜而 Agent 能去读你的仓库、翻你的提交历史、查你团队沉淀的知识条目然后给出有依据的回答。这个差别是能不能真正落地到团队场景的分水岭。2.3 为什么入口是 CLI 而不是网页teamai-cli选择命令行作为主要入口这个决策我认为非常务实。团队经验产生的高频场景几乎都在开发者的本地终端里提交代码时、排查问题时、review 别人的改动时。如果沉淀经验需要你切到浏览器、登录、找到对应项目、再手动录入那这件事的完成率会低得可怜。CLI 的好处是它能贴着 Git 工作流走。你在git commit前后顺手就能触发一次经验记录不需要离开当前上下文。这种“零切换成本”的设计是经验能不能真正沉淀下来的关键。我见过太多团队买了知识管理工具最后变成僵尸系统根本原因就是录入成本太高。3. teamai-cli 的安装与项目接入实操3.1 环境准备先把 Git 这条地基打牢TeamAI 深度依赖 Git所以第一步不是装 TeamAI而是确认你的 Git 环境是干净的。很多人 Git 装完能用就没管了但后面 Agent 读取提交历史、分析变更时配置不规范会直接导致信息缺失。先确认版本git --version建议 2.30 以上。然后配置基础身份信息这一步新手经常漏git config --global user.name 你的名字 git config --global user.email 你的邮箱如果你用 Gitee 或自建 Git 服务还需要配置密钥。生成密钥的命令是ssh-keygen -t ed25519 -C 你的邮箱生成后把公钥内容贴到对应平台的密钥设置里。这里有个实操心得密钥不要设空密码虽然设了每次推送要输一次但安全性值得。如果你嫌麻烦可以用 ssh-agent 缓存而不是直接留空。提示TeamAI 分析提交历史时作者信息、提交时间、变更范围都是重要输入。如果团队里有人用默认的rootlocalhost提交Agent 在归因经验时会丢失“这是谁的经验”这个维度传承效果会打折。接入前统一规范一遍提交身份收益比你想的大。3.2 安装 teamai-cli 与初始化安装方式通常通过包管理器或直接下载二进制。以常见的 Node 环境为例npm install -g teamai-cli装完后验证teamai-cli --version接着在项目根目录初始化cd your-project teamai-cli init初始化过程会做几件事识别当前仓库、生成配置文件、建立本地经验库的索引。这一步我建议在项目根目录执行而不是子目录否则 Agent 扫描范围会不完整读不到全量提交历史。初始化完成后你会看到一个配置文件里面通常包含模型接入信息、知识库路径、以及 Agent 的行为开关。这里不要急着全开先跑通最小闭环。3.3 第一次跑通让 Agent 读一遍你的仓库初始化后先做一次“冷启动”扫描teamai-cli sync这个命令会让 Agent 遍历仓库的提交历史、目录结构、关键文件建立初始认知。第一次跑会比较慢取决于仓库大小。我实测一个中等规模、两年历史的仓库大概几分钟。跑完之后试着问一个具体问题teamai-cli ask 这个项目的鉴权逻辑是怎么演进的如果 Agent 能结合提交历史给你讲出“某次提交把 session 换成了 token原因是……”说明链路通了。如果它只会泛泛而谈多半是同步没做全或者模型接入配置有问题。注意第一次同步不要贪多先把主分支跑通。有些团队仓库里有大量历史遗留分支和废弃代码全量喂进去反而会稀释 Agent 的判断质量。我的做法是先只同步主分支和近一年的活跃分支。4. 让经验真正“自动传承”的核心机制4.1 经验条目的结构化为什么不能只存聊天记录很多团队尝试过把聊天记录导出当知识库结果基本都失败了。原因很简单聊天记录是非结构化的检索时噪音太大而且没有“这条经验适用于什么场景”的元信息。TeamAI 的做法是把经验拆成结构化条目通常包含几个维度场景描述什么情况下会遇到、结论应该怎么做、依据为什么这么做、关联代码涉及哪些文件或提交。这种结构让 Agent 在检索时能精准匹配而不是靠关键词碰运气。我自己的体会是“依据”这一栏是灵魂。只记“结论”的知识库过半年就没人敢信了因为不知道当时的约束条件还在不在。记了依据后来人才能判断“这个结论现在还成立吗”。4.2 触发沉淀的时机贴着 Git 走经验沉淀最怕“事后补录”。TeamAI 把触发点设计在 Git 操作附近这是它最聪明的地方。几个典型时机提交时一次非平凡的提交往往包含一个决策。可以在提交信息里带上标记让 Agent 自动提取。排查问题时问题解决的那一刻是经验最鲜活的时候此时记录成本最低。代码评审时评审意见里藏着大量“为什么不能这么写”的经验。实操中我建议团队约定一个轻量规则凡是花了超过半小时才解决的问题解决后顺手记一条。不要追求完整先记下来后面可以补。这个习惯坚持一个月知识库的密度就会有质变。4.3 检索与复用新人上手速度的真实变化沉淀是手段复用才是目的。TeamAI 的检索不是简单的全文搜索而是 Agent 结合当前上下文去“理解”你的问题然后从经验库里找最相关的条目。这里有个反直觉的点检索质量高度依赖经验条目的“场景描述”写得够不够具体。如果一条经验的场景描述是“关于缓存的问题”那它几乎检索不到如果写成“用户登录后短时间内重复请求导致缓存击穿”命中率会高得多。所以我在团队里推行的规范是场景描述必须包含“什么条件下”和“什么现象”。新人上手速度的变化我观察下来主要体现在两个环节一是环境搭建和配置类问题基本可以自助解决二是“为什么这么设计”的疑问不用再打扰老员工。这两块省下来的时间累积起来相当可观。5. 实操中踩过的坑与排查链路5.1 同步后 Agent 答非所问从索引查起第一次用的时候我遇到 Agent 回答明显和仓库内容对不上。排查链路是这样的第一步确认同步是否真的完成。查看同步日志发现有几个大文件因为体积超限被跳过了。这些文件恰好是核心配置导致 Agent 对项目理解有偏差。第二步检查索引是否过期。我在同步后又做了几次提交但没重新 syncAgent 读的还是旧索引。第三步确认模型接入是否正常。有时候是模型服务本身响应异常返回了兜底答案。解决办法很直接养成提交后顺手 sync 的习惯或者配置成定时任务。另外对于体积大的关键文件可以单独指定纳入分析而不是让它被自动跳过。5.2 经验条目越积越多反而不好用用了一段时间后知识库膨胀检索质量反而下降。这是典型的“垃圾进垃圾出”。排查下来发现两个问题一是重复条目太多同一个结论被不同人记了好几遍措辞还不一样。二是过期条目没清理比如某个方案后来被推翻了但旧经验还在库里Agent 检索到就会给出错误建议。我的处理方式是引入定期梳理机制每月花半小时过一遍新增条目合并重复的、标记过期的。同时给条目加上“有效期”或“最后确认时间”字段Agent 在检索时优先用较新的。这件事听起来麻烦但比起被错误经验误导的代价完全值得。5.3 团队协作中的权限与边界问题经验库是团队共享的但有些内容涉及敏感信息比如内部架构细节、客户数据。TeamAI 在配置上支持对知识库做范围划分但实操中容易忽略。我的建议是从一开始就划清边界。哪些内容可以进共享库哪些只能留在本地团队要有明确约定。不要等到出了问题再补救。另外Agent 读取仓库时如果仓库里有敏感配置文件要提前排除避免被无意中纳入分析。提示接入前先做一次仓库“体检”把不该被 AI 读取的文件密钥、证书、内部文档通过配置排除掉。这一步花十分钟能省掉后面很多麻烦。6. 把 TeamAI 用出效果的几个关键习惯工具本身只是载体能不能让经验真正传承下去取决于团队的使用习惯。我总结了几条实操中验证有效的做法。第一降低单次记录的门槛。不要要求写得多完整一句话场景加一句话结论就能存。完整度可以后面补但“当时不记事后想不起来”是最大的损失。第二把 Agent 的回答当作起点而非终点。它给的建议要经过人判断尤其是涉及架构决策的。Agent 擅长的是“帮你回忆起当时发生了什么”而不是“替你做决定”。第三定期回看知识库的检索命中率。如果发现很多问题 Agent 都答不上来说明沉淀的场景覆盖不够反过来指导团队该往哪个方向补。第四新人入职第一周就让他用起来。让新人通过提问去熟悉项目同时他的提问本身也是“哪些经验缺失”的信号一举两得。关于扩展方向TeamAI 这类工具后续很可能会和 CI 流程结合得更紧比如在流水线里自动检测“这次改动是否触碰了历史踩坑点”。如果你们团队已经在用 Jenkins 之类的工具可以留意这方面的集成能力。我个人比较期待的是它能把代码评审意见也纳入经验提取那样沉淀的密度会再上一个台阶。最后分享一个我自己的小技巧我会在每次解决完一个棘手问题后用teamai-cli记一条然后在提交信息里引用这条经验的编号。这样以后任何人git blame到这行代码都能顺着编号找到当时的完整决策背景。这个习惯坚持下来代码和历史经验就真正长在了一起而不是两张皮。