slug: miliastra-toolbox displayName: 千星沙箱知识库 version: 1.2.0 summary: 查询千星沙箱节点、编辑器系统、官方指南与排障文档，帮助把玩法需求拆解为可执行的节点配置。 license: Proprietary name: miliastra-knowledge description: 查询千星沙箱（原神千星奇域 UGC 编辑器）知识库：节点用法与参数、官方指南/教程/FAQ 文档、语义检索。当用户询问千星沙箱节点（触发器、运动器、造物、仇恨、商店、背包等）、编辑器功能配置、"为什么不触发/不生效"类排障问题，或需要把玩法需求拆解为具体节点与参考文档时使用。仅覆盖服务端节点图与玩法逻辑，不含客户端控件与客户端脚本（lua）——客户端界面编程问题改用 miliastra-knowledge-lua。

千星沙箱知识库查询

用于查询千星沙箱（原神千星奇域 UGC 编辑器）的节点说明、系统配置、官方指南、教程和 FAQ。

服务地址：https://ugc.070077.xyz

调用方式与工具选择

通过 HTTP Skill API 调用，JSON 请求体：

POST https://ugc.070077.xyz/api/v1/skills/miliastra-knowledge/tools/<工具名>

各工具的参数、返回结构、可用关键词和 curl 示例详见 references/tools.md。

首次调用前阅读该参考文件。所有请求使用 Content-Type: application/json，请求体必须是包含具名字段的 JSON 对象；下文调用顺序中的列表写法仅为流程示意。

先检查 HTTP 状态和响应中的 success、error，成功后从 data.result 读取工具结果。rag_search 还可能在结果内返回 error 对象，需单独处理。

工具选择原则：结构化查询优先，rag_search 兜底；多个相互独立的问题应合并为一次批量调用。

什么时候用

• 用户询问千星沙箱某个节点的用法、参数、触发条件
• 用户询问系统/组件功能（战斗、仇恨、商店、背包、运动器、触发器……）
• 用户遇到"为什么不触发/不生效"等排障问题
• 用户想了解某系统的整体设计或配置步骤
• 需要把玩法需求拆解为具体节点名和参考文档

不在本技能范围：客户端控件、客户端脚本（lua）与 2D 界面编程问题改用 miliastra-knowledge-lua。

工具一览

优先级：结构化工具优先，`rag_search` 兜底。 能用节点名/文档名直接定位时不用 rag_search；rag_search 用于开放问题、排障、跨文档比较，或结构化工具结果不足时补充。

覆盖范围：本技能只覆盖 official/ 下的服务端语料（节点、指南、教程、FAQ）。客户端控件/客户端脚本文档是独立语料，本技能的工具查不到，由 miliastra-knowledge-lua 技能提供。

选择工具

1. 用户说了具体节点名 → get_node_info
2. 用户说"有没有关于 X 的文档"/不确定文档名 → list_documents(keywords=[X]) 先看列表（keywords 传空列表可浏览全部文档）
3. 已知文档/系统名，要完整内容 → get_document(["系统名"])
4. 用户用自然语言描述功能或问题 → rag_search
5. 查节点后需要看完整配置说明 → 取返回的 source_doc_title，再调 get_document

批量原则：多个独立查询合并为一次调用。所有工具均支持列表入参，不要拆成多轮单条调用，也不要重复相同调用。

依赖上一步结果的查询应顺序执行，例如先获得 source_doc_title 再取全文。模糊查询命中多个节点时，结合 main_title、side 和来源文档筛选，避免把同名节点或不同节点图的配置混用。

常见调用顺序

开放玩法需求（不知道节点名）：

rag_search(["需求描述"]) → get_node_info([命中的节点名]) → get_document([来源文档])

已知节点名：

get_node_info([节点名]) → 需要深入时 → get_document([source_doc_title])

学习某个系统（如商店、仇恨、背包）：

list_documents(["关键词"]) → get_document([精确文档名])

排障类（"为什么不触发/不生效"）：

rag_search(["问题描述A", "问题描述B"]) → get_document(["相关系统文档"])

领域示例 —— 造物/技能：

list_documents(["造物状态"]) → get_document(["造物状态决策节点图", "复杂造物技能"])
  → get_node_info(["复杂造物定点位移", "造物转向指定朝向"])

领域示例 —— 仇恨系统：

rag_search(["嘲讽和仇恨系统配置", "怪物追击玩家行为"])
  → get_node_info(["嘲讽目标", "增加指定实体的仇恨值", "获取指定实体的仇恨目标"])
  → get_document(["仇恨配置"])

异常处理

• get_node_info 无匹配 → 换更短/更通用的关键词重试；仍无结果 → 用 rag_search
• get_document 返回 status="too_many" → 用更精确的关键词重查
• get_document 返回 status="not_found" → 先 list_documents 找候选标题再重查
• rag_search 结果为空或不相关 → 换用领域术语重写 query（如把"怪物追我"改为"仇恨 嘲讽 追击"）
• HTTP 失败、success=false 或结果内出现 error → 明确说明查询失败，不将其解释为知识库没有资料；RAG 不可用时可改用节点和文档查询
• rag_search 的 top_k 必须为 1–20 的整数；参数错误应修正请求，避免原样重复调用

排障与玩法方案

• 先根据用户已提供的信息确定节点图类型、执行端、相关实体、触发条件和实际表现；缺少会影响判断的关键信息时再针对性询问
• 查询后按“触发事件 → 条件判断 → 目标实体与参数 → 执行动作”组织排查步骤，各项判断注明资料依据或待验证假设
• 对玩法需求先给最小可行节点流程，再补充所需组件和前置配置；所有具体节点名和参数均以查询结果为准
• 同名节点、玩家与角色实体、服务端与客户端不能默认互换；资料未明确的连接方式标为待验证

输出要求

• 节点类回答：说明用途、关键参数、归属端（`side`：服务端/客户端/双端），并注明来源文档
• 文档类回答：总结要点，必要时直接引用原文片段
• rag_search 的 similarity 仅用于相关性排序，不代表结论可信度；text_snippet 是最多 200 字的截断片段，涉及具体参数、限制或配置步骤时先获取相关文档全文
• 来源使用返回的文档标题；仅在返回结果提供可用链接时附链接，不把 local_path 或 file_name 拼成未经确认的公开 URL
• 严格区分"文档原文已说明"与"基于资料的推测建议"
• 不得编造节点名、参数名或官方结论；查不到就明确说查不到，并建议用户换个问法