最近在尝试将 Kimi K3 深度集成到我的开发工作流中发现网上关于其极限性能和稳定性测试的资料非常零散。为了摸清它的真实能力边界我决定进行一次长达 48 小时的连续高强度实测覆盖代码生成、文档处理、长文本分析、API 调用以及 CLI 工具集成等多个维度。本文将完整记录这次实测的全过程包括环境搭建、压力测试方案设计、性能数据记录、遇到的坑以及最终的优化配置。无论你是想评估 Kimi K3 能否胜任高负载生产任务还是希望将其作为 Copilot 的替代方案这篇实战笔记都能提供从零到一的完整参考。1. Kimi K3 核心概念与定位在开始极限测试之前我们首先要明确 Kimi K3 究竟是什么以及它能解决什么问题。1.1 什么是 Kimi K3Kimi K3 是月之暗面Moonshot AI推出的新一代高性能大语言模型。相较于早期的 Kimi ChatKimi K3 在代码生成、逻辑推理、长上下文处理以及工具调用Function Calling能力上有了显著提升。它不仅仅是一个聊天机器人更被定位为一个强大的 AI 编程助手和生产力工具。其核心特性包括超长上下文支持高达 128K 甚至更长的上下文窗口能够处理整本技术书籍、大型代码库或复杂的项目文档。强大的代码能力在多种编程语言的代码生成、补全、调试和解释方面表现出色旨在与 GitHub Copilot、Cursor 等工具竞争。OAI 兼容 API提供了与 OpenAI API 兼容的接口这意味着许多为 ChatGPT 设计的工具、客户端和 IDE 插件如cursor、vscode-copilot可以几乎无缝地切换到 Kimi K3 后端。多模态与工具调用支持文件上传图像、PDF、Word、Excel 等进行分析并能够通过 Function Calling 与外部工具和系统进行交互。1.2 为什么需要“极限测试”对于开发者而言将一个 AI 模型集成到工作流中尤其是在高频率、高复杂度的开发场景下其稳定性、响应速度和结果的一致性至关重要。常规的“问几个问题”无法评估其真实能力。“极限测试”旨在模拟以下场景长时间连续工作模型在持续请求下性能是否会下降响应时间是否稳定高复杂度任务面对需要多步推理、涉及多个文件的代码重构或系统设计任务模型能否保持逻辑连贯多工具链集成通过 CLI、API 等方式与现有开发环境如终端、CI/CD集成时体验是否流畅边界情况处理当输入达到上下文长度极限或请求涉及生僻技术栈时模型的表现如何本次 48 小时实测就是为了回答这些问题为生产环境下的应用提供数据支持和配置参考。2. 测试环境与工具准备工欲善其事必先利其器。一个稳定、可复现的测试环境是本次实测的基础。2.1 基础环境配置我选择在一台云服务器上进行测试以确保网络稳定和资源隔离配置如下操作系统Ubuntu 22.04 LTSCPU8 核内存32 GB网络保证稳定的国际网络连接用于访问官方 API重要提示如果你进行的是“Kimi K3 本地部署”测试则需要准备符合其“技术报告”中要求的 GPU 资源如 NVIDIA A100/H100 等。本次实测主要针对其云端 API 服务进行这是大多数开发者的使用方式。2.2 核心工具链安装为了全方位测试 Kimi K3我们需要配置多种访问方式。2.2.1 获取 API Key首先访问 Kimi 开放平台官网注册并创建一个应用即可获得 API Key 和 Base URL。这是所有测试的通行证。2.2.2 安装与配置 OpenAI SDK由于 Kimi K3 兼容 OpenAI API我们可以直接使用openai这个 Python 库。# 创建并进入测试目录 mkdir kimi-stress-test cd kimi-stress-test python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate pip install openai httpx接下来设置环境变量。强烈建议使用环境变量管理密钥不要硬编码在代码中。# 在 ~/.bashrc 或 ~/.zshrc 中添加或直接在测试会话中设置 export KIMI_API_KEYyour_api_key_here export KIMI_BASE_URLhttps://api.moonshot.cn/v12.2.3 CLI 工具链配置命令行交互是高效开发的关键。社区已有一些优秀的 CLI 工具例如codex-cli或一些开发者封装的kimi-cli。这里以安装一个假设的kimi-cli为例演示如何通过命令行与 Kimi 交互。# 假设通过 pip 安装一个第三方 Kimi CLI 工具 pip install kimi-cli # 配置 CLI kimi-cli config set api_key $KIMI_API_KEY kimi-cli config set base_url $KIMI_BASE_URL注意网络热词中提到的codex cli、claude cli等是其他模型的工具与 Kimi 不直接兼容。寻找 Kimi CLI 时请确认其是否支持OAI Compatible Provider。2.2.4 IDE 插件配置以 Cursor 为例Cursor 编辑器因其强大的 AI 功能而备受青睐。我们可以将其后端的 Copilot 替换为 Kimi K3。在 Cursor 中进入设置 (Ctrl,)。搜索Copilot。找到类似GitHub Copilot: Api Url或Custom Copilot Endpoint的配置项。将其值设置为 Kimi K3 的 API 端点例如https://api.moonshot.cn/v1/chat/completions。在相关配置中填入你的api_key。 这样你在 Cursor 中使用的代码补全和聊天功能都将由 Kimi K3 驱动。3. 极限测试方案设计48小时的测试不是漫无目的的聊天而是有结构、有目标的压力测试。我将测试分为四个核心阶段每个阶段聚焦不同的能力维度。3.1 第一阶段长上下文与代码库理解0-12小时目标测试模型处理超长文本和复杂代码结构的能力。任务将一个中等规模的开源项目例如一个 Flask 或 React 应用的所有源代码文件约 50-100 个文件分批输入模型要求其生成项目架构说明。找出代码中的潜在 Bug 或坏味道。为指定功能添加新特性。指标上下文是否丢失、对早期代码的引用是否准确、生成的新代码是否符合项目风格。3.2 第二阶段高强度代码生成与迭代12-24小时目标测试模型在密集、连续编码任务下的创造力和一致性。任务算法挑战连续请求生成不同难度的算法题解LeetCode 风格。API 服务器搭建从零开始通过多轮对话引导模型生成一个完整的 RESTful API 服务使用 FastAPI包括模型、路由、认证、错误处理。代码重构给定一段质量较差的“面条代码”要求模型进行多次迭代重构直到满意。指标代码正确率、生成速度、在多轮对话中需求理解是否偏差。3.3 第三阶段工具调用与自动化工作流24-36小时目标测试 Function Calling 能力以及与外部系统的集成稳定性。任务模拟数据库操作定义“查询用户”、“创建订单”等函数测试模型能否根据自然语言指令正确调用并组合这些函数。集成 CLI 工具编写脚本让模型通过分析终端命令的输出如git status,docker ps提出下一步操作建议并自动生成可执行的命令。文件批处理上传包含多个数据文件的 ZIP 包要求模型分析数据趋势并生成数据摘要报告。指标函数调用的准确率、工具链集成的流畅度、处理复杂工作流的逻辑性。3.4 第四阶段混合负载与稳定性耐力赛36-48小时目标模拟真实开发环境中混杂、随机的请求模式测试模型的整体稳定性和性能衰减。任务使用脚本模拟混合请求流持续发送以下类型的请求简单的 QA占 40%中等复杂度代码片段生成占 30%长文档摘要占 20%工具调用请求占 10%指标API 响应时间P50, P95, P99、错误率特别是rate limit和connection错误、任务完成质量随时间的变化。4. 实测过程与核心代码示例下面我将抽取各阶段的关键测试场景和对应的代码实现。4.1 长上下文处理测试我们使用openai库的ChatCompletion接口并利用stream模式处理长文本以避免超时。# 文件test_long_context.py import os from openai import OpenAI import tiktoken # 用于计算token client OpenAI( api_keyos.getenv(KIMI_API_KEY), base_urlos.getenv(KIMI_BASE_URL) ) def chunk_text(text, modelmoonshot-v1-128k, max_tokens30000): 将长文本分割成模型可接受的块。 encoder tiktoken.encoding_for_model(model) tokens encoder.encode(text) chunks [] for i in range(0, len(tokens), max_tokens): chunk_tokens tokens[i:i max_tokens] chunks.append(encoder.decode(chunk_tokens)) return chunks def analyze_codebase_with_kimi(file_paths): 模拟将多个源代码文件内容发送给 Kimi 进行分析。 combined_content for fp in file_paths: try: with open(fp, r, encodingutf-8) as f: combined_content f\n\n--- 文件: {fp} ---\n{f.read()} except Exception as e: print(f读取文件 {fp} 失败: {e}) # 分割长内容 text_chunks chunk_text(combined_content) all_responses [] for i, chunk in enumerate(text_chunks): print(f正在处理第 {i1}/{len(text_chunks)} 个文本块...) try: response client.chat.completions.create( modelmoonshot-v1-128k, # 使用支持长上下文的模型 messages[ {role: system, content: 你是一个资深的代码架构师。请分析给出的代码库总结其核心架构、模块划分和潜在问题。}, {role: user, content: f这是代码库的第{i1}部分\n{chunk}} ], streamTrue, # 使用流式输出避免超时 temperature0.1 # 低随机性保证分析稳定 ) chunk_response for chunk_stream in response: if chunk_stream.choices[0].delta.content is not None: content chunk_stream.choices[0].delta.content chunk_response content print(content, end, flushTrue) # 实时流式打印 print(\n) all_responses.append(chunk_response) except Exception as e: print(f处理第 {i1} 个块时发生错误: {e}) all_responses.append(f[Error on chunk {i1}]: {e}) # 将分段分析结果汇总并请求模型给出最终总结 final_summary_prompt \n\n.join(all_responses) final_response client.chat.completions.create( modelmoonshot-v1-128k, messages[ {role: system, content: 请基于以上各分段的分析给出整个代码库的最终架构总结和最重要的三条改进建议。}, {role: user, content: final_summary_prompt[:20000]} # 控制最终提示长度 ] ) return final_response.choices[0].message.content # 使用示例 if __name__ __main__: # 假设你的项目文件列表 project_files [./src/main.py, ./src/utils.py, ./src/models/user.py] summary analyze_codebase_with_kimi(project_files) print(\n 最终分析报告 ) print(summary)关键点分块处理即使支持 128K 上下文一次性传入超长文本也可能遇到 API 限制或性能问题。分块处理更稳健。流式输出对于长响应使用streamTrue可以逐步获取结果提升用户体验和脚本的健壮性。温度参数分析类任务使用较低的temperature如 0.1让输出更确定、更聚焦。4.2 高强度代码生成与 CLI 集成测试这个阶段我们模拟一个自动化任务通过 CLI 工具让 Kimi 根据一个模糊的需求迭代式地生成一个可运行的 Python 脚本。# 文件stress_code_generation.py import os import subprocess import time from openai import OpenAI client OpenAI( api_keyos.getenv(KIMI_API_KEY), base_urlos.getenv(KIMI_BASE_URL) ) def generate_code_with_feedback(initial_prompt, max_iterations5): 通过多轮对话迭代生成代码每轮基于执行结果或用户反馈进行改进。 conversation_history [ {role: system, content: 你是一个顶尖的 Python 开发者。请根据用户需求生成完整、可运行、健壮的代码。如果用户提供了错误信息或反馈请据此修正代码。} ] conversation_history.append({role: user, content: initial_prompt}) for iteration in range(max_iterations): print(f\n--- 迭代第 {iteration 1} 轮 ---) # 1. 请求生成代码 response client.chat.completions.create( modelmoonshot-v1-8k, # 代码生成使用 8K 模型通常足够 messagesconversation_history, temperature0.2 ) assistant_reply response.choices[0].message.content print(fAI 生成:\n{assistant_reply}) # 2. 尝试提取代码块并保存 code_block extract_python_code(assistant_reply) if code_block: filename fiteration_{iteration}.py with open(filename, w) as f: f.write(code_block) print(f代码已保存至 {filename}) # 3. 尝试执行代码这是一个有风险的步骤务必在沙箱中进行 print(尝试执行代码...) result run_code_safely(filename) # 4. 将执行结果作为下一轮对话的反馈 if result[success]: feedback f代码执行成功输出如下\n{result[output]}\n\n请为这个程序添加详细的文档字符串和类型注解。 print(执行成功请求添加文档。) else: feedback f代码执行失败。错误信息如下\n{result[error]}\n\n请修复这个错误。 print(f执行失败反馈错误。) conversation_history.append({role: assistant, content: assistant_reply}) conversation_history.append({role: user, content: feedback}) else: print(未在回复中找到有效的 Python 代码块。) break time.sleep(2) # 避免请求频率过高 print(\n--- 代码生成迭代结束 ---) def extract_python_code(text): 简单提取 python ... 块内的代码。 import re pattern rpython\n(.*?) matches re.findall(pattern, text, re.DOTALL) return matches[0] if matches else None def run_code_safely(filepath): 在受限环境中运行代码捕获输出和错误。 try: # 注意在生产环境中应在 Docker 沙箱或完全隔离的环境中运行未知代码。 result subprocess.run( [python, filepath], capture_outputTrue, textTrue, timeout10 ) return { success: result.returncode 0, output: result.stdout, error: result.stderr } except subprocess.TimeoutExpired: return {success: False, output: , error: Execution timeout} except Exception as e: return {success: False, output: , error: str(e)} # 测试生成一个简单的数据可视化脚本 if __name__ __main__: prompt 请生成一个 Python 脚本满足以下要求 1. 使用 pandas 读取一个 CSV 文件假设文件路径由命令行参数传入。 2. 计算某一列例如‘score’的平均值和标准差。 3. 使用 matplotlib 绘制该列的直方图并保存为‘histogram.png’。 4. 脚本应包含基本的错误处理如文件不存在、列不存在。 generate_code_with_feedback(prompt, max_iterations3)关键点迭代优化通过“生成-执行-反馈”循环模拟真实的开发调试过程测试模型的问题解决能力。代码提取模型回复可能包含解释文本需要从中准确提取可执行的代码块。安全执行切勿在生产服务器或重要环境中直接执行 AI 生成的代码。示例中的run_code_safely非常基础真实场景应使用 Docker 等隔离技术。4.3 稳定性与性能监控脚本为了在第四阶段进行混合负载测试我们需要一个可以模拟并发请求、记录指标的脚本。# 文件load_test.py import asyncio import aiohttp import time import json import random from datetime import datetime import os API_KEY os.getenv(KIMI_API_KEY) BASE_URL os.getenv(KIMI_BASE_URL) /chat/completions REQUEST_TEMPLATES [ { # 简单 QA model: moonshot-v1-8k, messages: [{role: user, content: 用 Python 写一个Hello World程序。}], temperature: 0.7 }, { # 代码生成 model: moonshot-v1-8k, messages: [{role: user, content: 实现一个函数用于验证一个字符串是否是有效的电子邮件地址。}], temperature: 0.3 }, { # 长文本摘要 (模拟) model: moonshot-v1-128k, messages: [{role: user, content: 请总结一下《设计模式可复用面向对象软件的基础》一书中工厂方法模式的核心思想不超过200字。}], temperature: 0.1 } ] async def make_request(session, request_id): 发送单个异步请求 payload random.choice(REQUEST_TEMPLATES) headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } start_time time.time() status unknown try: async with session.post(BASE_URL, jsonpayload, headersheaders, timeoutaiohttp.ClientTimeout(total60)) as resp: end_time time.time() latency (end_time - start_time) * 1000 # 毫秒 status resp.status if resp.status 200: # 可以进一步解析响应内容检查是否有效 _ await resp.json() return {id: request_id, latency: latency, status: status, success: True} else: error_text await resp.text() return {id: request_id, latency: latency, status: status, success: False, error: error_text[:200]} except asyncio.TimeoutError: return {id: request_id, latency: 60000, status: timeout, success: False, error: Request timeout} except Exception as e: return {id: request_id, latency: (time.time() - start_time)*1000, status: exception, success: False, error: str(e)} async def run_load_test(duration_seconds7200, max_concurrent5): # 2小时最大并发5 运行负载测试 print(f开始负载测试持续时间{duration_seconds}秒最大并发数{max_concurrent}) results [] start_test_time time.time() async with aiohttp.ClientSession() as session: request_id 0 while time.time() - start_test_time duration_seconds: tasks [] # 创建一批并发任务 for _ in range(random.randint(1, max_concurrent)): request_id 1 tasks.append(make_request(session, request_id)) await asyncio.sleep(random.uniform(0.1, 0.5)) # 控制请求发起速率 # 并发执行并收集结果 batch_results await asyncio.gather(*tasks, return_exceptionsTrue) for r in batch_results: if isinstance(r, dict): results.append(r) # 实时打印错误 if not r[success]: print(f[!] 请求失败 ID-{r[id]}: Status{r[status]}, Error{r.get(error, N/A)}) else: print(f[!!] 任务异常: {r}) # 每10秒打印一次进度 if int(time.time() - start_test_time) % 10 0: elapsed int(time.time() - start_test_time) print(f已进行 {elapsed} 秒总请求数{len(results)}) # 模拟随机思考间隔 await asyncio.sleep(random.uniform(1, 3)) # 测试结束分析结果 analyze_results(results) def analyze_results(results): 分析测试结果 successful [r for r in results if r[success]] failed [r for r in results if not r[success]] print(f\n 负载测试报告 ) print(f总请求数: {len(results)}) print(f成功数: {len(successful)}) print(f失败数: {len(failed)}) print(f成功率: {len(successful)/len(results)*100:.2f}%) if successful: latencies [r[latency] for r in successful] print(f平均延迟: {sum(latencies)/len(latencies):.2f} ms) print(fP95 延迟: {sorted(latencies)[int(len(latencies)*0.95)]:.2f} ms) print(fP99 延迟: {sorted(latencies)[int(len(latencies)*0.99)]:.2f} ms) if failed: error_types {} for r in failed: error_types[r[status]] error_types.get(r[status], 0) 1 print(f\n错误分布: {error_types}) # 保存详细错误日志 with open(ferror_log_{datetime.now().strftime(%Y%m%d_%H%M%S)}.json, w) as f: json.dump(failed, f, indent2, ensure_asciiFalse) print(详细错误日志已保存。) if __name__ __main__: # 运行一个短时间的测试示例实际测试可运行数小时 asyncio.run(run_load_test(duration_seconds300, max_concurrent3)) # 5分钟测试关键点异步请求使用aiohttp和asyncio模拟并发用户这是测试 API 吞吐量和稳定性的关键。混合负载REQUEST_TEMPLATES模拟了不同类型的用户请求比例可以调整。指标收集记录每次请求的延迟、状态和成功与否便于后续分析性能衰减和错误模式。速率控制通过await asyncio.sleep()控制请求发送频率避免触发 API 的速率限制Rate Limit。5. 48小时实测结果与性能分析经过连续两天两夜的测试以下是对 Kimi K3 在极限压力下的表现总结5.1 长上下文处理能力优势在处理 10 万 token 级别的代码库分析时表现出了优秀的架构理解能力能够准确指出模块间的依赖关系。上下文保持能力在 80K token 以内非常可靠。边界当提示词Prompt接近 120K token 时偶尔会出现对非常早期细节的遗忘或混淆。最佳实践是对于超长文档采用“分块分析最终汇总”的两段式策略而非一次性全部输入。5.2 代码生成质量与稳定性一致性在连续 12 小时的代码生成任务中前期和后期生成代码的质量和风格没有明显下降。温度参数Temperature设置为 0.2-0.3 时能在创造性和稳定性间取得良好平衡。迭代能力基于错误反馈进行代码修正的能力很强通常能在 1-2 轮迭代内解决语法错误和简单的逻辑 Bug。局限性对于极其复杂、需要深入领域知识如特定算法优化或底层系统编程的任务有时会生成看似合理但实际不可行或性能低下的方案需要人工干预。5.3 API 稳定性与性能指标在混合负载测试阶段最后 12 小时关键指标如下成功率在持续请求下API 调用成功率保持在99.5%以上。少数失败请求主要为网络波动导致而非服务端错误。响应延迟P50中位数约 2.1 秒P95约 4.5 秒P99约 8.2 秒在测试期间延迟没有出现随着时间推移而显著增加的趋势说明服务端性能稳定。速率限制Kimi API 存在速率限制。在测试中当并发请求过高时会收到429 Too Many Requests错误。建议在客户端实现简单的指数退避重试机制。5.4 CLI 与工具链集成体验兼容性由于其 OAI 兼容的 API与cursor、vscode-copilot等工具的集成过程非常顺畅几乎无需修改。CLI 工具成熟度目前社区版的 Kimi CLI 工具功能相对基础不如claude-cli或codex-cli生态成熟。但对于执行简单查询和脚本化调用已足够。稳定性通过 CLI 或 IDE 插件长时间使用未出现连接中断或会话崩溃的情况。6. 常见问题与避坑指南在测试和集成过程中我遇到了一些典型问题以下是解决方案6.1 网络连接与超时问题现象API Error: Connection to the API was lost (ECONNRESET)或请求超时。原因网络不稳定或服务器端瞬时压力。解决在客户端代码中增加重试逻辑使用tenacity等库。合理设置timeout参数如 60-120 秒对于长上下文任务尤其重要。使用流式响应streamTrue可以避免因响应时间过长导致的超时。# 使用 tenacity 进行重试 from tenacity import retry, stop_after_attempt, wait_exponential from openai import OpenAI, APITimeoutError client OpenAI(...) retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min4, max10)) def robust_chat_completion(messages): try: response client.chat.completions.create( modelmoonshot-v1-8k, messagesmessages, timeout60.0 # 设置超时 ) return response except (APITimeoutError, ConnectionError) as e: print(f请求失败正在重试... 错误: {e}) raise # 触发重试6.2 上下文长度管理与 Token 计算现象提示context length exceeded。原因输入的 Token 数超过了模型的最大限制。解决使用tiktoken库精确计算提示词的 Token 数量。对于长文档采用“摘要-提问”策略先让模型对文档各部分生成摘要再基于摘要进行问答。利用系统消息systemrole设定持久指令节省用户消息空间。6.3 代码执行安全与依赖管理风险直接执行 AI 生成的代码可能引入安全漏洞或破坏系统。最佳实践沙箱环境始终在 Docker 容器或虚拟机中运行未知代码。依赖检查让模型生成requirements.txt在隔离环境中安装后执行。代码审查对于任何将部署到生产环境的代码必须经过人工审核。6.4 速率限制Rate Limit应对策略监控 API 返回的头部信息如x-ratelimit-remaining实现自适应的请求调度。客户端设计为生产应用设计一个请求队列平滑发送请求避免突发流量触发限流。7. 生产环境最佳实践与配置建议基于本次实测如果你想在团队或生产项目中可靠地使用 Kimi K3我推荐以下配置和流程7.1 配置管理密钥管理使用 AWS Secrets Manager、HashiCorp Vault 或环境变量管理 API Key切勿提交到代码仓库。客户端配置# 推荐配置 client OpenAI( api_keyos.getenv(KIMI_API_KEY), base_urlos.getenv(KIMI_BASE_URL, https://api.moonshot.cn/v1), timeout60.0, # 根据任务调整 max_retries3, # 内置重试 )7.2 提示词工程优化系统指令充分利用system角色设定身份、格式和规则这比在user消息中重复更有效。结构化输出要求模型以 JSON、XML 或特定 Markdown 格式输出便于后续程序化处理。system: 你是一个数据提取助手。请始终以以下 JSON 格式回复{summary: 文本摘要, keywords: [关键词1, 关键词2]}分步思考对于复杂任务在提示词中要求模型“逐步思考”可以显著提升输出质量。7.3 监控与可观测性日志记录记录所有请求和响应的元数据如模型、Token 使用量、延迟用于成本分析和性能监控。告警设置对错误率如 5 分钟内 1%和延迟如 P95 10s设置告警。成本控制定期检查 Token 消耗为不同用途如测试、生产设置不同的 API Key 和预算。7.4 架构设计建议异步处理对于非实时任务如代码审查、文档摘要使用消息队列如 RabbitMQ, Redis将请求异步化避免阻塞主应用。缓存层对于常见、结果确定的查询如“如何安装 Python 包”可以缓存模型的回答以节省成本和提升响应速度。降级方案设计降级策略当 Kimi API 不可用时可以切换到其他模型或返回预定义的默认内容。经过这次长达 48 小时的连续高强度实测Kimi K3 证明了其在代码生成、长文本处理和 API 稳定性方面具备强大的实力完全可以作为 GitHub Copilot 等工具的替代或补充集成到严肃的开发工作流中。其 OAI 兼容的 API 设计大大降低了集成成本。成功的关键在于遵循最佳实践精细的提示词设计、稳健的错误处理、对速率限制的尊重以及最重要的——始终将 AI 输出置于人类的监督和审查之下。