数据库分布式数据库后端OLAP【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址https://gitcode.com/GitHub_Trending/ti/tidb点击查看免费下载本文以docs/agents/目录的官方入口 docs/agents/README.md 为核心骨架完整展开 TiDB 仓库中面向 AI Agent 的文档体系目录分层规则、策略与操作文档的职责边界、可复制执行的测试命令手册单元测试、failpoint、集成测试、RealTiKV、子系统架构索引与组件级深度笔记的组织方式。读完后你可以直接按文档中的命令模板在本地运行 TiDB 的各类测试并理解仓库如何为 Agent 协作设计策略在根、操作在docs/agents/、组件笔记按模块分目录的三层结构。一、Agent 文档体系的定位与目录布局docs/agents/README.md 明确了该目录的唯一职责它是 Agent 面向文档agent-facing documentation的单一顶层入口the single top-level home for agent-facing documentation。README 给出的布局Layout规则分为两层跨领域Cross-cutting的运行手册和检查清单统一放在docs/agents/*.md顶层。当前包含docs/agents/testing-flow.md —— 测试执行命令手册Unit/Integration/RealTiKVdocs/agents/architecture-index.md —— 子系统路径导航索引docs/agents/agents-review-guide.md —— 对 Agent 文档本身变更的评审指南docs/agents/notes-guide.md —— 组件笔记的放置与更新规则。组件专属Component-specific笔记放在docs/agents/component/子目录。当前仓库中已有四个组件目录docs/agents/ddl/DDL 执行框架的深度笔记9 个文件从执行流、作业生命周期到 add-index、modify-column、分区 DDL 的逐篇深潜docs/agents/dxf/DXFDistributed eXecution Framework分布式执行框架导航笔记docs/agents/executor/执行器相关开发笔记如 FULL OUTER JOIN 的分阶段实现记录docs/agents/import-into/IMPORT INTO 的冲突解决与清理排障笔记。这种顶层放横切 runbook、子目录放组件笔记的分层方式使得新增组件时只需在docs/agents/下开新文件夹而不必改动任何横切文档。二、职责边界策略归 AGENTS.md操作归 docs/agents/README 的 Maintenance 一节给出了两条维护规则这是理解整个体系的钥匙策略级policy-level要求保留在仓库根部的 AGENTS.md操作性operational细节保留在docs/agents/下的文档中。AGENTS.md 本身定义了仓库级默认约束术语优先级MUST 为必需、SHOULD 为推荐、MAY 为可选根部AGENTS.md是仓库全局默认更深层路径新增的AGENTS.md对其子树 SHOULD 具有更高优先级。五条不可妥协项Non-negotiables正确性优先TiDB 是分布式 SQL 数据库小改动可能改变 SQL 语义、一致性或集群行为、不做臆测性实现不发明不存在的 API/默认值/协议行为、diff 保持最小、留下可验证证据跑定向检查并报告精确命令、尊重生成代码不手改生成产物须从源输入重新生成。快速决策矩阵Quick Decision Matrix将任务类型 → 必须执行的动作列表化例如——使用 failpoint 的包跑单元测试 MUST 先启用后禁用 failpoint录制集成测试 MUST 使用 recording 命令而不是-recordRealTiKV 测试 MUST 后台启动 playground、跑完清理 playground 数据bug 修复 MUST 补回归测试并验证修复前失败、修复后通过纯格式 PR MUST NOT 跑昂贵的realtikvtest。构建流Build Flow明确列出必须运行make bazel_prepare的触发条件清单新克隆工作区、WORKSPACE/DEPS.bzl/BUILD.bazel/MODULE.bazel等 Bazel 文件变更、Go 源文件增删改名、已有 Go 文件的 import 段变更、新增顶层func TestXxx(t *testing.T)、go.mod/go.sum依赖变更、Bazel 测试目标更新、本地 Bazel 依赖/工具链报错。推荐本地构建顺序为# 仅在满足触发条件时执行 make bazel_prepare # 然后继续常规本地构建步骤 make bazel_bin make gogenerate # 可选重新生成生成代码 go mod tidy # 可选go.mod/go.sum 有变更时这些目标在当前仓库 Makefile 中均可确认存在bazel_prepare注释为 Update and generate BUILD.bazel files. Please run this before commit.、bazel_bin、gogenerate以及bazel_test其依赖链为bazel-failpoint-enable bazel_prepare印证了文档中make bazel_test已内置 failpoint 启用的说法。同时AGENTS.md特别强调make bazel_lint_changed在本地 macOS 环境可能缓慢且耗资源Agent MUST NOT 在用户未显式要求时运行它。任务 → 验证矩阵Task - Validation Matrix按改动范围给出最小验证集例如改pkg/planner/**规则需定向 planner 单测并视需要更新 testdata改tests/integrationtest/t/**需录制并核对了r目录中再生成结果的正确性改pkg/ddl/**需 DDL 专项测试与兼容性影响检查。Agent 输出契约Agent Output Contract交付变更时必须报告改动的文件、所用验证档位WIP/Ready/Heavy及原因、风险正确性/兼容性/性能、实际执行的精确命令、以及本地未验证的内容。docs/agents/agents-review-guide.md 则进一步固化了这条边界任何新的 MUST/SHOULD/MAY/MUST NOT 策略必须先落在AGENTS.mddocs/agents/下的文档只能解释或举例策略不得引入新的策略范围评审时还要重点检查高风险策略门Bazel 元数据规则的无歧义性、PR 要求的Issue Number:行、测试策略与 runbook 无矛盾等并提供了可复制的快速验证命令例如# 检查策略锚点 grep -n Task - Validation Matrix\|Testing Policy\|make bazel_prepare AGENTS.md # 确保规范性关键词未被反引号包裹 rg -n -P (MUST(?: NOT)?|SHOULD|MAY) AGENTS.md docs/agents/agents-review-guide.md # 确保本次变更删除/重命名的路径不再被 Markdown 文档引用 git diff --name-status base_ref...HEAD | \ awk $1D{print $2} $1 ~ /^R[0-9]*/{print $2} | \ while read -r old_path; do [ -n ${old_path} ] rg -n --fixed-strings ${old_path} --glob *.md . || true done评审完成的验收标准包括AGENTS.md与变更后的docs/agents/文档之间无策略矛盾、关键规则无歧义措辞、无失效路径引用、且最终评审意见附带具体证据路径 执行过的精确命令。三、测试执行手册testing-flow.md 的完整命令面docs/agents/testing-flow.md 是整个docs/agents/体系中实操密度最高的文档声明自己是命令 playbook 的规范操作参考canonical operational reference并规定.agents/skills/下的技能应当指向这里而不是复制长命令块。其内容按测试面分为四段。3.1 单元测试/pkg/...pushd pkg/package_name go test -run TestName -tagsintest,deadlock popd要点优先定向运行-run TestName仅在确有需要时才跑整包-record只用于明确支持录制的测试套件运行成功后要复查改动的 result/testdata 文件。3.2 failpoint 判定与启用对于使用 failpoint 的包手册给出了判定命令决定是否需要启用 failpointrg -n --fixed-strings -- failpoint. pkg/package_name rg -n --fixed-strings -- testfailpoint. pkg/package_name # 若存在 BUILD.bazel还需检查 failpoint 依赖 test -f pkg/package_name/BUILD.bazel rg -n --fixed-strings -- com_github_pingcap_failpoint//:failpoint pkg/package_name/BUILD.bazel有命中则用 failpoint 启用方式运行无命中则普通运行并在报告中说明判定证据特别提醒-tagsintest,deadlock并不会启用 failpoint。启用运行使用封装脚本 tools/check/failpoint-go-test.sh./tools/check/failpoint-go-test.sh pkg/package_name -run TestName从脚本头部的 usage 说明可以确认其行为启用 failpoint → 运行go test→ 清理阶段始终禁用 failpoint未传-tags时默认-tagsintest,deadlock需要nextgen时显式传-tagsintest,deadlock,nextgen。底层启用/禁用路径由tools/check/failpoint-state.sh串行化文档因此警告不要在同一 worktree 的并行 Agent 任务中直接调用tools/bin/failpoint-ctl。走 Bazel 的路径则对应make bazel-failpoint-enable/make bazel-failpoint-disable使用make bazel_test时无需单独执行 enable该目标已依赖bazel-failpoint-enable但结束后仍要执行 disable。3.3 集成测试/tests/integrationtest测试输入在tests/integrationtest/t期望结果在tests/integrationtest/r两者均为仓库顶层 tests/integrationtest/ 下的真实目录pushd tests/integrationtest ./run-tests.sh -r TestName popd文档给出的映射示例若改的是t/planner/core/binary_plan.test则TestName就是planner/core/binary_plan。结果文件通常不需手工编辑确需编辑时保持最小改动并在报告前核实正确性。3.4 RealTiKV 测试/tests/realtikvtest用于依赖真实 TiKV/TiUP Playground 行为的用例。完整生命周期为后台启动 playground → 等待 PD 就绪 → 跑测试 → 强制清理 → 验证清理tiup playground --mode tikv-slim --tag realtikvtest PLAYGROUND_PID$! # 默认 PD 为 127.0.0.1:2379端口被占时使用非默认端口或端口偏移 tiup playground --mode tikv-slim --tag realtikvtest --pd.port 12379 # 或 tiup playground --mode tikv-slim --tag realtikvtest --port-offset 10000 PD_ADDR127.0.0.1:2379 # 若以 --pd.port 12379 或 --port-offset 10000 启动则 PD_ADDR127.0.0.1:12379 until curl -sf http://${PD_ADDR}/pd/api/v1/version /dev/null; do sleep 1; donego test -run TestName -tagsintest,deadlock ./tests/realtikvtest/dir/... # 非默认 PD 示例 go test -run TestName -tagsintest,deadlock ./tests/realtikvtest/dir/... -args \ -tikv-path tikv://127.0.0.1:12379?disableGCtrue[ -n ${PLAYGROUND_PID:-} ] kill ${PLAYGROUND_PID} 2/dev/null || true [ -n ${PLAYGROUND_PID:-} ] wait ${PLAYGROUND_PID} 2/dev/null || true rm -rf ${HOME}/.tiup/data/realtikvtest # 清理校验PD 端点应不可达 ! curl -sf http://${PD_ADDR}/pd/api/v1/version文档还推荐了一个带trap cleanup EXIT INT TERM的 cleanup-safe 模板保证长时本地调试时即使中断也能自动回收 playground 进程和${HOME}/.tiup/data/realtikvtest数据目录。--tag realtikvtest的作用正是让数据退出后仍保留在该目录、从而可以在清理阶段删除。默认不加-v仅调试时添加。替代工作流位于 tests/realtikvtest/scripts/classic/ 与 tests/realtikvtest/scripts/next-gen/两者均含bootstrap-test-with-cluster.sh、run-tests.sh、run-tests-with-gotest.sh等脚本分别对应经典模式与 next-gen 模式。四、架构索引architecture-index.md 的子系统导航docs/agents/architecture-index.md 自称是快速子系统发现的导航索引navigation index for quick subsystem discovery硬性要求仍留在根部AGENTS.md。它规定四步使用法把任务映射到一个主属子系统 → 找覆盖相同行为的既有测试 → 复用既有 fixture/testdata 再考虑新形状 → 仅在跨模块影响明确时才扩展到相邻子系统。索引覆盖的核心子系统与路径均与仓库当前目录结构一致子系统关键路径典型改动Planner 与优化pkg/planner/、pkg/planner/core/base/、pkg/planner/core/operator/logicalop/、pkg/planner/core/operator/physicalop/规则匹配、计划形状、基于代价的选择首查测试为pkg/planner/core/casetest/与pkg/planner/core/casetest/rule/testdata/执行与表达式pkg/executor/、pkg/expression/运行时算子语义、内建函数行为、求值边界Session/变量/协议pkg/session/、pkg/sessionctx/、pkg/sessionctx/variable/、pkg/server/会话生命周期、语句上下文、协议层行为DDL 与元数据pkg/ddl/、pkg/infoschema/、pkg/meta/、pkg/meta/autoid/schema 演化、元数据持久化、ID 生成存储与分布式执行pkg/kv/、pkg/store/、pkg/distsql/、pkg/tablecodec/KV 语义、存储集成、分布式查询路径Domain 与统计pkg/domain/、pkg/statistics/schema/统计生命周期、基数/估算行为Parser 与 ASTpkg/parser/SQL 语法、AST 节点、解析行为测试面Test Surfaces划分为三类包内单测pkg/**本地、集成测试输入tests/integrationtest/t/、期望输出tests/integrationtest/r/、RealTiKV 测试tests/realtikvtest/当行为依赖真实 TiKV/PD 交互时使用。文档还给出常见跨模块路径作为调用链心智模型Planner → Executor → Expression查询语义、Session/Variables → Executor用户可见运行时行为、DDL → Infoschema/Meta → Domainschema 生命周期、Store/KV/DistSQL → Executor分布式执行行为。从源码结构看这份索引与仓库顶层目录逐一对应pkg/planner/下确实存在core/、casetest/等目录tests/integrationtest/顶层同时存在t/与r/两个子目录印证了索引的输入/期望输出划分。五、组件级笔记ddl、dxf、import-into、executor 四个子目录README 声明的四个组件目录各自遵循导航优先、指向源码的写法以下逐一说明其骨架。5.1docs/agents/ddl/DDL 执行框架的 Read-First 索引docs/agents/ddl/README.md 开头即给出 DDL 的心智模型TiDB DDL 是基于作业job-based且由 owner 驱动的——SQL DDL 语句被转换为持久化的 DDL 作业由DDL owner调度 worker 逐步推进 schema 状态并等待全集群 schema 版本同步。文档点名的最常见错误是在pkg/executor/SQL 执行层直接实现 DDL 行为那会绕过作业持久化/owner 故障切换可恢复性、schema 状态机delete only→write only→reorg→public、schema 版本 diff 更新与集群同步、以及 MDL/lease 安全机制。该 README 还要求 Agent 在动pkg/ddl/之前书面回答 8 个前置问题是否 job-based 或元数据快速路径、需要哪些 schema 状态迁移、是否需要 reorg/backfill 扫描及其 checkpoint、取消/回滚语义、对 schema 版本与 follower 同步的影响、涉及哪些系统表如mysql.tidb_ddl_job与mysql.tidb_ddl_reorg及字段向后兼容性、MDL 阻塞与写冲突的在线行为、最小回归测试与可确定性化的 failpoint。文档提供了按任务分篇的索引01 执行流、02 作业生命周期、03 reorg/backfill、04 开发检查清单、05 文件地图、06 add-index 深潜、07 modify-column 深潜、08 分区 DDL 深潜均为docs/agents/ddl/下的真实文件、一个 mermaid 时序图Session →pkg/executor/ddl.go的DDLExec→pkg/ddl/executor.go→JobSubmitter→mysql.tidb_ddl_job→ owner 的jobScheduler→ worker →pkg/ddl/schemaver/syncer.go的Syncer以及一张先看哪里的代码地图pkg/executor/ddl.go、pkg/ddl/ddl.go、pkg/ddl/executor.go、pkg/ddl/job_submitter.go、pkg/ddl/job_scheduler.go、pkg/ddl/job_worker.go、pkg/ddl/systable/manager.go、pkg/domain/domain.go。根部 AGENTS.md 对此有对应硬约束改 DDL 行为前 MUST 先读docs/agents/ddl/README.md调试时这些文档只能当假设MUST 用代码/测试验证若实现与文档行为不一致MUST 随代码一起更新文档并在 PR/issue 中说明。5.2docs/agents/dxf/DXF 框架导航docs/agents/dxf/README.md 是 DXFDistributed eXecution Framework的导航地图范围涵盖核心框架pkg/dxf/framework/、IMPORT INTO 应用pkg/dxf/importinto/、DDL 分布式 backfill 应用pkg/ddl/、SQL 入口pkg/executor/与pkg/executor/importer/、以及运行时 bootstrap 与 ownership 循环所在的pkg/session/与pkg/domain/。其阅读规则与全仓库一致包有doc.go时先读DXF 从pkg/dxf/framework/doc.go开始。框架地图按职责切分framework/proto/任务类型/步骤常量、task-subtask 模型、状态机枚举、framework/handle/提交/等待/暂停恢复/取消/修改 API、framework/storage/任务管理器与 dist-task 表持久化、framework/scheduler/owner 侧调度、framework/taskexecutor/节点侧执行、framework/planner/逻辑计划到物理计划/任务创建、operator/算子流水线工具。文档进一步给出运行时流程速览业务逻辑构建任务元数据并提交 → storage 持久化 task/subtask 状态 →Domain在每个节点启动 executor-manager 循环 → scheduler-manager 循环仅在本节点为 DDL owner 时运行 → scheduler 扩展推进步骤并派发子任务 → executor 扩展执行子任务并汇报状态/摘要以及新增任务类型的检查清单先在pkg/dxf/framework/proto/定义任务类型与步骤枚举step.go明确禁止修改既有常量值以保向后兼容、实现scheduler.Extension与taskexecutor.Extension、注册scheduler.RegisterSchedulerFactory/taskexecutor.RegisterTaskType/ 可选scheduler.RegisterCleanerFactory并要求GetNextStep从任务基础状态出发保持确定性。两条关键不变量值得注意任务 rank 同时驱动调度与抢占rank 高 (priority, create_time, id)元组小RequiredSlots是预留基线实际运行可通过ExtraParams.MaxRuntimeSlotsTargetSteps使用更少的 slot。5.3docs/agents/import-into/冲突解决排障地图docs/agents/import-into/README.md 聚焦只读单个包时容易漏掉的冲突解决与清理行为范围为 IMPORT INTO 作业/任务生命周期mysql.tidb_import_jobs DXF 任务、全局排序冲突检测/收集/解决、后处理校验与清理。它给出两条步骤流本地排序路径StepInit - ImportStepImport - ImportStepPostProcess - StepDone全局排序路径StepInit - ImportStepEncodeAndSort - ImportStepMergeSort - ImportStepWriteAndIngest - ImportStepCollectConflicts - ImportStepConflictResolution - ImportStepPostProcess - StepDone后三个为可选子任务阶段。排障示例包括collect-conflicts / conflict-resolution 步骤为何被跳过当collectConflictInfos未发现已记录冲突时不生成 spec可检查各阶段 meta 的RecordedConflictKVCount 0与后处理为何跳过 checksumTooManyConflictsFromIndex在有限内存 row-key 集合超限——约 step 内存的一半——时被置位后处理据此跳过最终 checksum。5.4docs/agents/executor/特性开发笔记docs/agents/executor/fullouter_join_dev_note.md 展示了另一种笔记形态特性开发的过程追踪。它记录了 TiDB 添加 SQL 标准FULL OUTER JOIN的四步计划语法/AST 恢复/特性门 → root planner → root HashJoin v1 执行 → TiFlash MPP shuffle join、初始目标范围FULL OUTER JOIN ... ON ...、Volcano planner、root HashJoin v1、由tidb_enable_full_outer_join门控且默认OFF、初始非目标USING/NATURAL FULL OUTER JOIN、Cascades planner、IndexJoin/MergeJoin/HashJoin v2 等以及按主题的 Decision Log决策日志。这是 notes-guide 中决策与实现计划留痕规范的实例。六、notes-guide组件笔记的放置、更新与拆分规则docs/agents/notes-guide.md 规定了组件笔记的三条操作规则是维护docs/agents/component/子目录的规范位置与布局笔记放在docs/agents/component/靠近所属组件优先复用既有文件夹新增文件夹时应在本指南中加一条简短说明使其可被发现本指南不维护组件文件夹的完整内联列表——以docs/agents/目录本身为当前文件夹名的唯一事实来源与docs/agents/README.md的 Layout 一节互为呼应。更新规则主题/根因重叠时更新既有小节只有真正全新的主题才追加带日期的新小节。大笔记拆分单文件超过 2000 行时按功能拆分并更新所有指向旧路径的引用。指南末尾还固定了一条索引IMPORT INTO 笔记位于docs/agents/import-into/README.md。七、配套生态.agents/skills 技能与 PLANS.md ExecPlanREADME 声明的策略/操作二分法之上仓库还有一套被两份顶层文件支撑的配套机制技能库 .agents/skills/README.md仓库级技能存放于.agents/skills每个技能的内容与引用集中在各自的技能文件夹内如.agents/skills/skill/SKILL.md及references/。当前仓库中存在九个操作工作流技能tidb-verify-profile选择 WIP/Ready/Heavy 验证档位、tidb-bazel-prepare-gate判定是否需要make bazel_prepare、tidb-failpoint-test-runnerfailpoint 启用/禁用判定与安全跑单测、tidb-integrationtest-recorder集成测试录制流、tidb-realtikv-runnerRealTiKV 启停清理纪律、tidb-test-diff-triage测试 diff 归因failpoint vs 上游 vs 本地回归、tidb-issue-metadata-guard与tidb-pr-metadata-guardissue/PR 模板与元数据守护、tidb-change-instruction-critic实现前评估修复方案。该 README 明确了三层分工策略与验证/报告要求用AGENTS.md构建/测试命令 playbook 用docs/agents/testing-flow.md技能提供指向这些 playbook 的入口工作流——这正对应 AGENTS.md 中政策归AGENTS.md、详细命令 playbook 归docs/agents/*、技能提供入口工作流的表述。ExecPlan 规范 PLANS.md定义执行计划ExecPlan——一份自包含的、可供无仓库背景的执行者人或无状态 Agent从头到尾完成特性交付的活文档。其不可协商要求包括完全自包含、随进展持续更新、让新手也能端到端实现、产出可演示的行为而不只是源码编辑、用白话定义非显见术语并强制每个计划维护Progress、Surprises Discoveries、Decision Log、Outcomes Retrospective四个活章节。AGENTS.md 的 ExecPlans 一节将其挂入流程编写复杂特性或重大重构时从设计到实现都应使用符合PLANS.md格式的 ExecPlan并在实现推进期间保持其为活文档。八、从文档到行动一份可直接使用的操作速查把上述文档串起来Agent或人类在 TiDB 仓库中完成一次改动验证的最小闭环是定位按 docs/agents/architecture-index.md 把任务映射到主属子系统找到同行为的既有测试与 testdata改动前阅读目标包的doc.go若存在——这是 AGENTS.md Pre-flight Checklist 的第 2 条。判定构建前置对照Build Flow的触发清单或.agents/skills/tidb-bazel-prepare-gate决定是否需要make bazel_prepare需要则把生成的BUILD.bazel/*.bazel/*.bzl变更纳入 diff。选择最小验证集按Task - Validation Matrix定测试面命令一律取自 docs/agents/testing-flow.md单测用go test -run TestName -tagsintest,deadlockfailpoint 包改用./tools/check/failpoint-go-test.sh集成测试用tests/integrationtest/run-tests.sh -r TestName后核对r/下 diffRealTiKV 用例按后台 playground → 轮询 PD 就绪 → 测试 → kill rm -rf ${HOME}/.tiup/data/realtikvtest→ curl 校验端点不可达的完整生命周期执行。按档位交付迭代中用WIP验证档位交付前用Ready档位代码改动要求make lint并按 Agent Output Contract 报告文件、档位、风险、精确命令与未验证项。文档自洽若改动本身涉及AGENTS.md、.agents/skills/或docs/agents/下任何文件先按 docs/agents/agents-review-guide.md 的六组检查清单优先级与范围、结构与去重、高风险策略门、测试/验证一致性、PR/Issue 策略一致性、引用与路径卫生自查并用其中的快速验证命令留证。九、小结docs/agents/目录体系的设计可以用 docs/agents/README.md 的两段话概括布局上横切 runbook 居顶层、组件笔记按子目录归位维护上策略进根部AGENTS.md、操作留在docs/agents/。围绕这一中心testing-flow.md 提供可复制粘贴的四类测试命令面含 failpoint 判定与 RealTiKV 清理纪律architecture-index.md 提供子系统到路径与测试面的映射agents-review-guide.md 与 notes-guide.md 分别约束文档自身的变更评审与笔记生长方式ddl/、dxf/、import-into/、executor/四个组件目录则以Read-First 索引 代码地图 决策留痕的形态承载各模块的深度知识。技能库.agents/skills/与PLANS.md的 ExecPlan 规范则分别负责工作流入口与长任务交付共同构成一套策略、操作、组件知识三层分离且互相不重复的 Agent 文档体系。赞分享数据库分布式数据库后端OLAP【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址https://gitcode.com/GitHub_Trending/ti/tidb点击查看免费下载相关推荐Data-Juicer 官方文档导航解析Sphinx 文档站点的索引架构与目录体系Data Juicer 官方文档导航解析Sphinx 文档站点的索引架构与目录体系 Data Juicer 项目通过 Sphinx 构建的在线文档站点其入口人工智能大模型数据工程数据清洗数据增强数据质检Wand-Enhancer 使用教程本地补丁免费解除 Wand 2 小时限制附手机远程面板完整指南Wand Enhancer 使用教程本地补丁免费解除 Wand 2 小时限制附手机远程面板完整指南 Wand Enhancer 是一款针对 Wand原 W桌面应用前端Just the Docs 导航系统完全指南主导航、面包屑、子页目录与页内导航的配置与源码解析Just the Docs 导航系统完全指南主导航、面包屑、子页目录与页内导航的配置与源码解析 Just the Docs 的默认页面布局内置了一套完整的文档文档静态站点UI组件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考