chore: remove deprecated kcl-openapi tool links

Signed-off-by: peefy <xpf6677@163.com>

Author: Peefy

docs/user_docs/guides/working-with-konfig/1-overview.md

@@ -28,9 +28,9 @@ Konfig provides users with an out-of-the-box and highly abstract configuration i
 - **Core model**:
   - **Front-end model**: The front-end model is the "user interface", which contains all configurable attributes exposed to users on the platform side. Some repetitive and deducible configurations are omitted, and essential attributes are abstracted and exposed to users. It has user-friendly features, such as `server.k`.
   - **Back-end model**: The back-end model is "model implementation", which is the model that makes the properties of the front-end model effective. It mainly contains the rendering logic of the front-end model instance. The back-end model can use KCL to write validation, logic judgment, code fragment reuse and other code to improve the reusability and robustness of the configuration code, and is not sensitive to users, such as `server_backend.k`.
-- **Domain model**: It is a model that does not contain any implementation logic and abstraction. It is often generated by tool transformation and does not need to be modified. It corresponds to the real effective YAML attribute one by one. The domain model needs to be further abstracted and is generally not directly used by users. For example, `kusion_kubernetes` is the domain model library of Kubernetes scenarios.
+- **Domain model**: It is a model that does not contain any implementation logic and abstraction. It is often generated by tool transformation and does not need to be modified. It corresponds to the real effective YAML attribute one by one. The domain model needs to be further abstracted and is generally not directly used by users. For example, `k8s` is the domain model library of Kubernetes scenarios.
 
-In addition, the core model simplifies the configuration code of front-end users through two layers of abstraction: the front-end model and the back-end model. The domain model is automatically generated through the [KCL OpenAPI tool](/docs/tools/cli/openapi/quick-start).
+In addition, the core model simplifies the configuration code of front-end users through two layers of abstraction: the front-end model and the back-end model. The domain model is automatically generated through the KCL import tool.
 
 ## Docs
 

i18n/zh-CN/docusaurus-plugin-content-docs/current/user_docs/guides/working-with-konfig/1-overview.md

@@ -28,9 +28,9 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
 - **核心模型**：
   - **前端模型**：前端模型即「用户界面」，包含平台侧暴露给用户的所有可配置属性，其中省略了一些重复的、可推导的配置，抽象出必要属性暴露给用户，具有用户友好的特性，比如 server.k。
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
-- **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
+- **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，k8s 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL Import 工具自动生成。
 
 ## 文档
 

i18n/zh-CN/docusaurus-plugin-content-docs/version-0.4.4/user_docs/guides/working-with-konfig/1-overview.md

@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。

i18n/zh-CN/docusaurus-plugin-content-docs/version-0.4.5/user_docs/guides/working-with-konfig/1-overview.md

@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。

i18n/zh-CN/docusaurus-plugin-content-docs/version-0.4.6/user_docs/guides/working-with-konfig/1-overview.md

@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。

i18n/zh-CN/docusaurus-plugin-content-docs/version-0.5.0/user_docs/guides/working-with-konfig/1-overview.md

@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。

i18n/zh-CN/docusaurus-plugin-content-docs/version-0.5.1/user_docs/guides/working-with-konfig/1-overview.md

@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。

i18n/zh-CN/docusaurus-plugin-content-docs/version-0.5.2/user_docs/guides/working-with-konfig/1-overview.md

@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。

i18n/zh-CN/docusaurus-plugin-content-docs/version-0.5.3/user_docs/guides/working-with-konfig/1-overview.md

@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。

i18n/zh-CN/docusaurus-plugin-content-docs/version-0.5.4/user_docs/guides/working-with-konfig/1-overview.md

@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。