init
This commit is contained in:
@@ -0,0 +1,29 @@
|
||||
{
|
||||
"name": "AI Data Foundation",
|
||||
"id": "ai-data-foundation",
|
||||
"owner": {
|
||||
"name": "LLM Wiki"
|
||||
},
|
||||
"metadata": {
|
||||
"description": "Evidence-backed Wiki workflows for compiling project materials and answering questions with traceable sources",
|
||||
"version": "0.1.0"
|
||||
},
|
||||
"plugins": [
|
||||
{
|
||||
"name": "llm-wiki",
|
||||
"source": "./",
|
||||
"description": "Compile immutable evidence into a traceable Wiki and answer project questions with Wiki-first retrieval",
|
||||
"version": "0.1.0",
|
||||
"author": {
|
||||
"name": "LLM Wiki"
|
||||
},
|
||||
"keywords": [
|
||||
"wiki",
|
||||
"knowledge-management",
|
||||
"requirements",
|
||||
"traceability"
|
||||
],
|
||||
"category": "workflow"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,18 @@
|
||||
{
|
||||
"name": "llm-wiki",
|
||||
"description": "Evidence-backed Wiki workflows for compiling project materials and answering questions with traceable sources",
|
||||
"version": "0.1.0",
|
||||
"author": {
|
||||
"name": "LLM Wiki"
|
||||
},
|
||||
"keywords": [
|
||||
"wiki",
|
||||
"knowledge-management",
|
||||
"requirements",
|
||||
"traceability"
|
||||
],
|
||||
"skills": [
|
||||
"./.github/skills/llm-wiki-weave",
|
||||
"./.github/skills/llm-wiki-ask"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
name: "LLM-Wiki"
|
||||
description: "This agent coordinates the LLM-Wiki file-based repository workflow. It interprets user commands to weave knowledge or answer questions, managing raw evidence, wiki pages, and output files while ensuring source references."
|
||||
argument-hint: "Command: llm-wiki-weave <stage> | llm-wiki-ask <stage> <question>"
|
||||
tools: [execute, read, edit, search]
|
||||
user-invocable: true
|
||||
disable-model-invocation: false
|
||||
---
|
||||
|
||||
You coordinate the LLM-Wiki workflows for this repository.
|
||||
|
||||
Before accessing stage files, read and follow the repository-root `AGENTS.md`, then load the applicable stage `wiki/AGENTS.md` as directed there. The root file controls project-wide boundaries; the stage file controls local wiki structure and deliverable standards. Do not duplicate those rules in this agent file.
|
||||
|
||||
For this repository, treat the workspace root as the stage root and `wiki/` as the maintained knowledge directory. The retrieval index must be created or updated only at `wiki/index.md`; never create a second index at the workspace root.
|
||||
|
||||
## Dispatch command
|
||||
|
||||
Interpret the first command word in the user's request:
|
||||
|
||||
- `llm-wiki-weave <stage>`: load and follow the `llm-wiki-weave` skill.
|
||||
- `llm-wiki-ask <stage> <question>`: load and follow the `llm-wiki-ask` skill.
|
||||
|
||||
The matching skill is the source of truth for required parameters, validation, file operations.
|
||||
Do not copy or substitute its procedure here.
|
||||
If the command or required arguments are missing, follow the matching skill's prescribed execution mode and do
|
||||
not inspect or modify stage files.
|
||||
|
||||
Apply the loaded skill procedure together with `AGENTS.md`. When they address different concerns, follow both; when a skill defines command-specific behavior, the skill controls that workflow detail.
|
||||
@@ -0,0 +1,96 @@
|
||||
import process from "node:process";
|
||||
|
||||
const chunks = [];
|
||||
|
||||
for await (const chunk of process.stdin) {
|
||||
chunks.push(chunk);
|
||||
}
|
||||
|
||||
let event;
|
||||
|
||||
try {
|
||||
event = JSON.parse(Buffer.concat(chunks).toString("utf8") || "{}");
|
||||
} catch {
|
||||
deny("Raw protection could not parse the tool request.");
|
||||
}
|
||||
|
||||
const toolName = String(
|
||||
event.tool_name ?? event.toolName ?? event.name ?? ""
|
||||
).toLowerCase();
|
||||
const toolInput = event.tool_input ?? event.toolInput ?? event.input ?? {};
|
||||
const readOnlyTool = /(read|search|grep|list|view|fetch|semantic)/.test(toolName);
|
||||
|
||||
if (readOnlyTool) {
|
||||
allow();
|
||||
}
|
||||
|
||||
const rawTargets = collectPathTargets(toolInput).filter(isRawPath);
|
||||
const command = typeof toolInput.command === "string" ? toolInput.command : "";
|
||||
const workingDirectory = String(event.cwd ?? "");
|
||||
const shellTool = /(execute|terminal|shell|bash|powershell|command)/.test(toolName);
|
||||
|
||||
if (shellTool && (isRawPath(command) || isRawPath(workingDirectory))) {
|
||||
deny(
|
||||
"Shell commands that reference raw/ are blocked. Use a dedicated read or search tool to inspect raw evidence."
|
||||
);
|
||||
}
|
||||
|
||||
if (rawTargets.length > 0) {
|
||||
deny(`Modification of raw evidence is forbidden: ${rawTargets[0]}`);
|
||||
}
|
||||
|
||||
allow();
|
||||
|
||||
function collectPathTargets(value, key = "") {
|
||||
if (Array.isArray(value)) {
|
||||
return value.flatMap((item) => collectPathTargets(item, key));
|
||||
}
|
||||
|
||||
if (value && typeof value === "object") {
|
||||
return Object.entries(value).flatMap(([childKey, childValue]) =>
|
||||
collectPathTargets(childValue, childKey)
|
||||
);
|
||||
}
|
||||
|
||||
if (typeof value !== "string") {
|
||||
return [];
|
||||
}
|
||||
|
||||
if (key === "input") {
|
||||
return [...value.matchAll(/^\*\*\* (?:Add|Update|Delete) File: (.+)$/gm)].map(
|
||||
(match) => match[1].trim()
|
||||
);
|
||||
}
|
||||
|
||||
return /(file|path|uri|target|destination|source)/i.test(key) ? [value] : [];
|
||||
}
|
||||
|
||||
function isRawPath(value) {
|
||||
const normalized = String(value)
|
||||
.replaceAll("\\", "/")
|
||||
.replaceAll('"', "")
|
||||
.replaceAll("'", "")
|
||||
.toLowerCase();
|
||||
|
||||
return /(^|[\s/:])raw(?:[\s/]|$)/.test(normalized);
|
||||
}
|
||||
|
||||
function allow() {
|
||||
process.stdout.write(JSON.stringify({ continue: true }));
|
||||
process.exit(0);
|
||||
}
|
||||
|
||||
function deny(reason) {
|
||||
process.stdout.write(
|
||||
JSON.stringify({
|
||||
continue: false,
|
||||
stopReason: reason,
|
||||
hookSpecificOutput: {
|
||||
hookEventName: "PreToolUse",
|
||||
permissionDecision: "deny",
|
||||
permissionDecisionReason: reason
|
||||
}
|
||||
})
|
||||
);
|
||||
process.exit(0);
|
||||
}
|
||||
@@ -0,0 +1,11 @@
|
||||
{
|
||||
"hooks": {
|
||||
"PreToolUse": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "node .github/hooks/protect-raw.mjs",
|
||||
"timeout": 5
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
name: llm-wiki-ask
|
||||
description: "Answer an LLM-Wiki question with wiki-first retrieval. Use for ask commands and questions about a stage."
|
||||
argument-hint: "Stage and question"
|
||||
---
|
||||
|
||||
# Ask With Wiki-First Retrieval
|
||||
|
||||
You are running `ask`.
|
||||
|
||||
`<stage>` and `<question>` are required. If either is missing or empty, stop
|
||||
immediately without reading or writing any stage file. Reply with:
|
||||
|
||||
`Please input stage and question,e.g. ask <stage> "What is discussed in this stage?"`
|
||||
|
||||
1. Read the stage's `wiki/index.md` first.
|
||||
2. Read the most relevant `wiki/*.md` pages.
|
||||
3. Read raw files only for evidence, missing details, or conflict checking.
|
||||
4. Save the answer to `output/ask-<short-question-slug>.md`.
|
||||
5. Include the question, retrieval path separated into wiki hits and raw
|
||||
evidence, concise answer, source references, human-check notes, and whether
|
||||
anything should later be promoted into the wiki.
|
||||
6. Never edit `raw/`.
|
||||
7. Do not edit `wiki/` unless explicitly asked to maintain the wiki.
|
||||
|
||||
In the final response, report the output path, wiki pages used, raw evidence
|
||||
used, and any follow-up maintenance suggestion.
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
name: llm-wiki-weave
|
||||
description: "Weave raw materials into the LLM-Wiki. Use for processing raw files and updating wiki pages."
|
||||
argument-hint: "Stage"
|
||||
---
|
||||
|
||||
# Action: Weave Raw Into Wiki
|
||||
|
||||
You are running `weave`.
|
||||
|
||||
Goal: read the stage's `raw/` materials and update `wiki/` as long-term knowledge.
|
||||
|
||||
Required weave work:
|
||||
|
||||
1. Inspect all files under the stage's `raw/` directory, including nested folders.
|
||||
2. Do not edit any raw file.
|
||||
3. For each meaningful raw file, create or update one `wiki/source-summary-*.md` file.
|
||||
4. Create or update stable `wiki/concept-*.md` pages when multiple raw files support the same reusable idea.
|
||||
5. Update `wiki/index.md` as the stage's retrieval entrance.
|
||||
6. Every generated or updated wiki file must include:
|
||||
- `source_refs`
|
||||
- what the page is useful for
|
||||
- what a human should check
|
||||
- uncertainty or conflict notes when needed
|
||||
7. Keep the pages short enough for a beginner to inspect from the terminal.
|
||||
|
||||
Output in your final response:
|
||||
|
||||
- Files created or updated.
|
||||
- Evidence read.
|
||||
- Any uncertainty that should not be promoted to long-term knowledge yet.
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
# Generated Wiki artifacts
|
||||
/logs/
|
||||
/output/
|
||||
/wiki/*
|
||||
!/wiki/AGENTS.md
|
||||
|
||||
# Operating system and editor temporary files
|
||||
.DS_Store
|
||||
Thumbs.db
|
||||
desktop.ini
|
||||
*.tmp
|
||||
*.swp
|
||||
*~
|
||||
@@ -0,0 +1,118 @@
|
||||
# LLM Wiki Agent
|
||||
|
||||
## Purpose
|
||||
|
||||
This repository turns project evidence into reviewable and traceable knowledge for product requirements, system architecture, development design, delivery planning, and technical decisions.
|
||||
|
||||
Act as the project's requirements analyst, solution architect, and development design collaborator. Treat the wiki as an evidence-backed engineering workspace, not as a generic note collection. Never promote unverified analysis into project truth.
|
||||
|
||||
## Repository Contract
|
||||
|
||||
- `<stage>/raw/` stores original evidence. Never rewrite, rename, move, or delete files under `raw/`.
|
||||
- `<stage>/wiki/` stores maintained and reusable knowledge derived from evidence.
|
||||
- `<stage>/output/` stores task-specific deliverables such as requirement analyses, architecture proposals, development designs, reviews, roadmaps, and answers.
|
||||
- `<stage>/logs/` stores generated daily weave file-processing records. Logs are operational metadata, not evidence, wiki knowledge, or task outputs.
|
||||
- `<stage>` may be the repository root or a stage directory with the same structure.
|
||||
- In this repository, the stage root is the workspace root: `raw/`, `wiki/`, `logs/`, and `output/` are its stage directories. The only maintained Wiki index is `wiki/index.md`; never create or update a root-level `index.md`.
|
||||
- Prefer updating an existing artifact over creating a near-duplicate.
|
||||
- Do not invent mandatory directories, page taxonomies, Frontmatter schemas, or operation logs unless the user, a loaded skill, or the applicable stage `wiki/AGENTS.md` requires them.
|
||||
|
||||
## Raw Evidence Enforcement
|
||||
|
||||
- Read and search operations may access any `<stage>/raw/` directory when a complete evidence chain is required.
|
||||
- Writing, creating, deleting, renaming, moving, or patching anything under a `raw/` directory is forbidden.
|
||||
- The workspace `PreToolUse` hook enforces this rule for supported clients through `.github/hooks/raw-readonly.json`.
|
||||
- Use dedicated read or search tools for raw evidence. Shell commands that reference a `raw/` path are blocked because a hook cannot reliably prove that an arbitrary command is read-only.
|
||||
- Treat the hook as defense in depth. Clients that do not load workspace hooks must still obey this policy and their own sandbox or approval controls.
|
||||
|
||||
## Skill Boundaries
|
||||
|
||||
Skills own repeatable workflows. This file defines project-wide quality and reasoning rules and must not duplicate or override skill procedures.
|
||||
|
||||
- For `llm-wiki-weave <stage>`, load and follow `.github/skills/llm-wiki-weave/SKILL.md` as the source of truth for parameter validation, reads, writes, and completion reporting.
|
||||
- For `llm-wiki-ask <stage> <question>`, load and follow `.github/skills/llm-wiki-ask/SKILL.md` as the source of truth for parameter validation, retrieval, output, and completion reporting.
|
||||
- For direct requirement analysis, architecture design, development design, gap analysis, roadmap, or technical review requests, follow the project-wide evidence and output rules in this file.
|
||||
- Only modify `wiki/` when running weave or when the user explicitly requests wiki maintenance.
|
||||
- Do not modify skill files unless the user explicitly requests a skill change.
|
||||
|
||||
## Weave File Processing Logs
|
||||
|
||||
- Store generated weave processing logs under `<stage>/logs/`.
|
||||
- Use one daily summary file named `<stage>/logs/YYYY-MM-DD-weave.md` based on the local calendar date.
|
||||
- Logs record raw-file processing only. `llm-wiki-ask`, direct analysis, and ordinary wiki editing must not create or modify log files.
|
||||
- Logs are operational control records, not raw evidence, maintained wiki knowledge, task outputs, or valid sources for project claims. Never cite them as evidence, include them in `wiki/index.md`, or use them to answer a project question.
|
||||
|
||||
Before every weave run:
|
||||
|
||||
1. List and read all existing `<stage>/logs/*-weave.md` files before reading raw file contents.
|
||||
2. Reconstruct the latest status of each raw file from its most recent timestamped record across the daily logs.
|
||||
3. List all files under `<stage>/raw/`, including nested folders, and compare their repository-relative paths with the reconstructed status.
|
||||
4. Treat a raw path whose latest status is `completed` as already processed because raw files are immutable. Skip reading and recompiling it when all recorded outputs still exist.
|
||||
5. Process a raw file when it has no log record, its latest status is `pending`, `in_progress`, `failed`, or `missing`, or any recorded output is missing.
|
||||
6. Reprocess a completed file only when the user explicitly requests a rebuild or classification rules require migration. Record the reason in the daily log.
|
||||
7. Do not infer completion only from a similarly named wiki page; the latest log status and recorded outputs are authoritative together.
|
||||
|
||||
For every raw file considered during the run, append records to that day's log:
|
||||
|
||||
- Append `in_progress` before creating or updating wiki pages for a selected file.
|
||||
- Append `completed` only after required pages, source references, and `wiki/index.md` links pass validation.
|
||||
- Append `failed` when processing or validation cannot finish, with a concise blocking reason.
|
||||
- Append `skipped` when an already completed file and all recorded outputs are verified and no reprocessing is needed.
|
||||
- Append `missing` when a previously recorded raw path is unexpectedly absent.
|
||||
- Never delete or rewrite existing records. Correct an error by appending a newer correction record.
|
||||
- Use ISO 8601 timestamps in the UTC+08:00 timezone, written with the `+08:00` offset (for example, `2026-09-23T14:30:00+08:00`), repository-relative paths, and `<br>` between multiple outputs.
|
||||
- Never record secrets, credentials, tokens, or full sensitive data.
|
||||
|
||||
Every daily log must use this table:
|
||||
|
||||
| Timestamp | Raw file | Action | Status | Outputs | Note |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
|
||||
Allowed statuses are `in_progress`, `completed`, `failed`, `skipped`, and `missing`.
|
||||
|
||||
The weave completion report must include processed files, skipped completed files, failed files, and the daily log path. Ask completion reporting remains controlled only by the ask skill and does not include a log.
|
||||
|
||||
## Stage Wiki Instructions
|
||||
|
||||
- Before every weave, ask, or wiki maintenance task, read `<stage>/wiki/AGENTS.md` when it exists; otherwise use the repository-root `wiki/AGENTS.md` as the default.
|
||||
- The applicable `wiki/AGENTS.md` defines that stage's current directory layout, classifications, naming rules, and page standards. A stage-specific file may differ from the root default.
|
||||
- Treat every `wiki/AGENTS.md` as a control file, not project knowledge or evidence. Never cite it, include it in `wiki/index.md`, or use it to answer a project question.
|
||||
- Keep one-off analyses and unapproved proposals in `<stage>/output/`; promote them to maintained wiki knowledge only when the user requests maintenance and the applicable stage rules allow it.
|
||||
|
||||
## Evidence And Traceability
|
||||
|
||||
1. Start with the stage's `wiki/index.md` and relevant maintained wiki pages when they exist.
|
||||
2. Read raw evidence to fill gaps, verify exact wording, or resolve conflicts.
|
||||
3. Distinguish the following information classes in substantial artifacts:
|
||||
- **Source fact**: explicitly supported by repository evidence.
|
||||
- **Analysis**: a reasoned interpretation of source facts.
|
||||
- **Proposal**: a recommended product or technical choice.
|
||||
- **Decision**: a choice explicitly approved by the user or source material.
|
||||
- **Assumption**: a temporary premise requiring validation.
|
||||
- **Open question**: missing information that can materially change scope or design.
|
||||
4. Reference source file paths for facts and decisions.
|
||||
5. Preserve conflicts and uncertainty. State what requires confirmation from product, architecture, security, data owners, or other stakeholders.
|
||||
6. Never present an unsupported implementation choice as an approved requirement.
|
||||
|
||||
## Writing Standard
|
||||
|
||||
- Write generated wiki pages and indexes in the primary language of their source evidence. For multiple sources, use the language of the dominant evidence set unless the user requests another language.
|
||||
- Preserve code, identifiers, protocol names, product names, and exact quotations in their original form when translation would reduce precision.
|
||||
- Keep Markdown concise, concrete, and readable by product, engineering, data, operations, and security stakeholders.
|
||||
- Use tables for comparisons and matrices, and Mermaid diagrams only when they improve understanding.
|
||||
- Avoid repeating raw source text; summarize it and retain references.
|
||||
- Keep maintained wiki pages stable and task outputs specific to one decision or deliverable.
|
||||
- Do not silently change approved scope or decisions while reorganizing content.
|
||||
- Use explicit headings and concrete acceptance criteria. Keep artifact depth proportional to available evidence.
|
||||
|
||||
## Completion Report
|
||||
|
||||
In the final response, report:
|
||||
|
||||
- the task type;
|
||||
- files created or updated;
|
||||
- evidence consulted;
|
||||
- validation performed;
|
||||
- assumptions, unresolved questions, and required follow-up decisions.
|
||||
|
||||
For weave and ask commands, also include every completion item required by the loaded skill.
|
||||
@@ -0,0 +1,72 @@
|
||||
# LLM Wiki
|
||||
|
||||
面向证据型知识库插件。它将原始材料编译为可检索、可审阅、可追溯的 Wiki,并基于已维护知识优先回答项目问题。
|
||||
|
||||
## 功能
|
||||
|
||||
- `llm-wiki-weave`:将 `raw/` 中的原始证据编译为 Wiki 页面、索引和处理日志。
|
||||
- `llm-wiki-ask`:优先从 Wiki 检索项目知识,必要时再核对原始证据。
|
||||
- `raw/` 为只读证据区,禁止改写、移动、重命名或删除其中的文件。
|
||||
|
||||
## 安装
|
||||
|
||||
将本仓库发布到 GitHub 后,使用仓库地址注册 Marketplace,再安装插件。
|
||||
|
||||
其中,插件名为 `llm-wiki`,Marketplace ID 为 `ai-data-foundation`。
|
||||
|
||||
### Copilot CLI
|
||||
|
||||
```bash
|
||||
copilot plugin marketplace add <OWNER>/<REPOSITORY>
|
||||
copilot plugin install llm-wiki@ai-data-foundation
|
||||
```
|
||||
|
||||
本地开发时,在仓库根目录执行:
|
||||
|
||||
```bash
|
||||
copilot plugin marketplace add .
|
||||
copilot plugin install llm-wiki@ai-data-foundation
|
||||
```
|
||||
|
||||
验证安装:
|
||||
|
||||
```bash
|
||||
copilot plugin list
|
||||
```
|
||||
|
||||
### Codex
|
||||
|
||||
```bash
|
||||
codex plugin marketplace add <OWNER>/<REPOSITORY>
|
||||
codex plugin install llm-wiki@ai-data-foundation
|
||||
```
|
||||
|
||||
本地开发时,在仓库根目录执行:
|
||||
|
||||
```bash
|
||||
codex plugin marketplace add .
|
||||
codex plugin install llm-wiki@ai-data-foundation
|
||||
```
|
||||
|
||||
## 使用
|
||||
|
||||
在 Copilot CLI 或 Codex 的交互会话中请求对应技能:
|
||||
|
||||
```text
|
||||
使用 llm-wiki-weave 编译当前 stage(.)。
|
||||
```
|
||||
|
||||
```text
|
||||
使用 llm-wiki-ask 回答当前 stage(.)的问题:“当前需求中哪些能力属于首期范围?”
|
||||
```
|
||||
|
||||
## 目录约定
|
||||
|
||||
```text
|
||||
raw/ # 原始证据,只读
|
||||
wiki/ # 可维护、可复用的长期知识
|
||||
output/ # 一次性分析和问答结果
|
||||
logs/ # weave 处理日志
|
||||
```
|
||||
|
||||
规则位于 `AGENTS.md`,插件清单位于 `.claude-plugin/`,技能位于 `.github/skills/`。
|
||||
@@ -0,0 +1,123 @@
|
||||
# 智能数据平台(AI Data Platform)需求文档
|
||||
**版本:** v1.0.0 | **日期:** 2026-04-08 | **状态:** 草稿
|
||||
|
||||
---
|
||||
|
||||
## 一、项目背景
|
||||
企业日常面对海量业务数据,传统分析模式存在以下问题:用户依赖数据团队写SQL,响应慢,无法即时决策,数据链路不透明,难以追溯数据来源,数据分析和报表生成流程繁琐,ETL 流程复杂且维护成本高。
|
||||
|
||||
为满足企业需求,亟需构建一套以自然语言为入口、以数据仓库为底座、以安全合规为保障的智能数据分析平台,让数据民主化,使业务人员无需懂 SQL 即可完成复杂的数据查询与分析。
|
||||
|
||||
## 二、项目目标
|
||||
构建一套基于 AI 的对话式数据分析 + 数据采集 + 数据仓储 + 数据治理平台,实现从自然语言查询到结果可视化、导出、服务化以及基础数据安全管理的全流程能力,达到为上层应用提供数据支持,如舆情分析和AI Ops。
|
||||
|
||||
## 三、功能需求概览
|
||||
### 聊天式查询(NL2SQL)
|
||||
用户通过对话框输入自然语言,系统自动生成并执行 SQL,返回结构化结果,可多轮对话修正。单次查询行数上限 10,000(管理员可配置),超时 30 秒。
|
||||
|
||||
**核心要点:**
|
||||
|
||||
+ 语义层定义,需要手动维护
|
||||
- 统一指标,绑定唯一聚合逻辑、可用维度(时间/地区等)、过滤条件
|
||||
- 枚举值映射(如 status=1 自动转译为 "完成")
|
||||
- join关系定义避免模型自由关联
|
||||
+ RAG增强的Schema召回,数据库中表较多,无法全部放入Prompt
|
||||
- 表和字段的向量化,按用户问题做相似度召回(Doris混合检索,使用关键词检索 + 向量语义检索)
|
||||
- 相似SQL的样本召回(方案待确定)
|
||||
+ SQL 生成后须经语法验证、安全验证,失败自动重试(最多 3 次,需要携带错误信息修正)
|
||||
+ 表关联关系的知识图谱,可用于join查询(方案待确定)
|
||||
+ 查询历史记录,对比执行准确率
|
||||
|
||||
---
|
||||
|
||||
### 表格/报表结果展示
|
||||
聊天式查询将结果直接返回再对话框中,需要以更专业化的表格与图表形式呈现,支持交互操作。
|
||||
|
||||
**核心要点:**
|
||||
|
||||
+ 表格使用专业表格插件展示,支持简单交互操作,例如过滤,宽度调整等
|
||||
+ 使用 ECharts / DataV 渲染,需要根据字段类型自动推荐图表(折线/柱状/饼图),支持表格与图表的双向联动
|
||||
+ 生成数据摘要(描述)内容
|
||||
+ 表格使用Excel导出,全量数据导出(.xlsx, .csv),中文表头,数值保持格式
|
||||
+ 图表使用PDF导出
|
||||
|
||||
---
|
||||
|
||||
### 结果固化(API/MCP)
|
||||
将保存的查询封装为对外服务,供外部系统集成调用。
|
||||
|
||||
**核心要点:**
|
||||
|
||||
+ 一键"发布为 API",自定义路径、参数等,可生成接口文档;
|
||||
+ 版本管理或变更机制(查询逻辑或Schema变更)
|
||||
+ 支持封装为 MCP Tool(含 `name`/`description`/`inputSchema`用户填写或自动从SQL中提取),供 AI Agent 调用
|
||||
+ 统一 API 网关处理鉴权、限流、CORS、日志、调用监控(QPS、成功率、延迟、错误码分布)
|
||||
|
||||
---
|
||||
|
||||
### 基础 Guardrail
|
||||
在 AI 处理链路中建立安全护栏,防止注入攻击与数据泄露。
|
||||
|
||||
**核心要点:**
|
||||
|
||||
| 环节 | 防护内容 |
|
||||
| --- | --- |
|
||||
| 输入过滤 | 提示词注入、SQL 注入尝试、敏感词、越权意图、超长输入(>2000字符)和LLM Prompt 的注入防护 |
|
||||
| SQL 安全 | 仅允许 SELECT,禁止 DDL/DML,禁止危险函数,表名须在元数据白名单内 |
|
||||
| 输出过滤 | 手机号/身份证自动打码,敏感词屏蔽,越权字段值拦截 |
|
||||
| 审计日志 | 所有请求记录(含拒绝原因),只读不可删,保留 1 年 |
|
||||
|
||||
|
||||
+ 过滤规则可在管理界面配置(敏感词库、黑名单函数),更新即时生效
|
||||
|
||||
---
|
||||
|
||||
### ETL 采集
|
||||
构建全链路数据管道,数据分四层流转。
|
||||
|
||||
**数据分层:**
|
||||
|
||||
| 层次 | 说明 |
|
||||
| --- | --- |
|
||||
| ODS(贴源层) | 原始数据,不做业务加工,按日期分区 |
|
||||
| DWD(明细层) | 字段标准化:手机号、身份证号脱敏<br/>去重:基于业务主键 + 时间戳的拉链表 / 最新记录去重逻辑<br/>质量探针:清洗过程中触发规则校验(非空、长度、正则) |
|
||||
| DWS(汇总层) | 按维度预聚合(日期/省份/品牌/企业) |
|
||||
| ADS(应用层) | 面向查询的宽表,字段含中文注释,NL2SQL 模块优先读取该层 |
|
||||
|
||||
|
||||
**核心要点:**
|
||||
|
||||
+ 清洗规则配置化,无需改代码即可调整
|
||||
+ 基于 Airflow 或轻量调度器管理 ETL 任务,支持手动触发与 DAG 可视化
|
||||
+ 每次 ETL 后自动计算数据质量指标(记录数波动、空值率、时效性),异常告警
|
||||
+ 支持使用Agent完成ETL
|
||||
|
||||
---
|
||||
|
||||
### 后续内容 (先不做)
|
||||
+ 数据级别RBAC,实现行级(RLS)和列级(CLS)精细化数据权限控制。
|
||||
- 行级权限(RLS):以 SQL WHERE 子句定义数据范围,在 SQL 执行前自动注入,用户无感知
|
||||
- 列级权限(CLS):不可见字段自动脱敏(`***`)或直接拒绝查询;敏感字段不注入 NL2SQL Schema
|
||||
- 表级权限:白名单模式,无权表对用户完全透明
|
||||
- 权限管理界面:支持模拟特定用户查询结果(权限验证用)
|
||||
- 权限变更即时生效,触发缓存失效;所有变更写入不可删除的审计记录
|
||||
+ 血缘下钻
|
||||
- 在查询结果中逐级深入分析,并追踪数据来源
|
||||
- 下钻路径可配置(时间:年→月→日;地区:省→市→区县)
|
||||
- 面包屑导航支持任意层级回退
|
||||
- 最小血缘:仅追踪当前数据的直接上游表,用户可点击"查看数据来源"查看
|
||||
- 血缘图谱页:DAG 有向图可视化,支持搜索表名、层级过滤
|
||||
|
||||
---
|
||||
|
||||
## 四、功能验证
|
||||
| 类别 | 关键指标 |
|
||||
| --- | --- |
|
||||
| NL2SQL | NL2SQL 端到端 P95 ≤ 15s;API 调用 P99 ≤ 2s;并发 ≥ 200 用户;100条测试集,SQL 准确率 ≥ 85%;5轮多轮对话正确率 ≥ 90% |
|
||||
| 结果展示 | 5万行 Excel 导出 ≤ 30s;PDF 含图表无乱码 |
|
||||
| 安全Guardrails | SQL注入和LLM Promote注入; |
|
||||
| 浏览器 | Chrome/Edge/Firefox 100+(不支持 IE) |
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,64 @@
|
||||
# Wiki Workspace Instructions
|
||||
|
||||
## Scope
|
||||
|
||||
These instructions control the current `wiki/` directory. Read this file before every weave, ask, or wiki maintenance task.
|
||||
|
||||
This file is operational control metadata. Do not treat it as project knowledge, cite it as evidence, or include it in `wiki/index.md`.
|
||||
|
||||
## Current Layout
|
||||
|
||||
Keep maintained knowledge pages directly under `wiki/` because the current ask skill retrieves `wiki/*.md` non-recursively.
|
||||
|
||||
```text
|
||||
wiki/
|
||||
|-- AGENTS.md
|
||||
|-- index.md
|
||||
|-- source-summary-<slug>.md
|
||||
`-- concept-<slug>.md
|
||||
```
|
||||
|
||||
## Classification And Naming
|
||||
|
||||
- `wiki/source-summary-*`: one source, one page.
|
||||
- `wiki/concept-*`: long-term knowledge page.
|
||||
|
||||
- Use lowercase kebab-case slugs based on subject, not date or author.
|
||||
- Keep one primary category per page and update an existing matching page instead of creating a near-duplicate.
|
||||
- Preserve `source-summary-*` and `concept-*` names required by the weave skill.
|
||||
- Use only the categories listed here unless this file is intentionally revised for the stage.
|
||||
|
||||
## Page Requirements
|
||||
|
||||
Every maintained knowledge page must include:
|
||||
|
||||
- the `source_refs` field: repository-relative evidence paths;
|
||||
- the `Useful for` field: supported questions or decisions;
|
||||
- the `Human check` field: facts, interpretations, or approvals requiring review;
|
||||
- the `Uncertainty and conflicts` field, or its `None identified` state;
|
||||
- a concise body appropriate to its category.
|
||||
|
||||
Do not present proposals or assumptions as approved requirements or decisions.
|
||||
|
||||
## Document Language
|
||||
|
||||
- Use one human-readable language per maintained page and index entry: select the dominant language of its evidence unless the user explicitly requests another language.
|
||||
- Translate all visible headings, descriptions, and explanatory text into that language. Do not mix translated and untranslated headings.
|
||||
- Keep only necessary technical identifiers, code, protocol names, product names, and literal source quotations in their original form.
|
||||
- Preserve the four Page Requirements fields as stable semantic concepts. Translate only their visible headings according to this mapping:
|
||||
|
||||
| Canonical field | Chinese visible heading | English visible heading |
|
||||
| --- | --- | --- |
|
||||
| `source_refs` | 来源 | Source refs |
|
||||
| `Useful for` | 用途 | Useful for |
|
||||
| `Human check` | 人工核查 | Human check |
|
||||
| `Uncertainty and conflicts` | 不确定性与冲突 | Uncertainty and conflicts |
|
||||
| `None identified` | 未发现 | None identified |
|
||||
|
||||
- Do not require an English metadata key, YAML frontmatter, or HTML comment when the selected document language provides an unambiguous visible heading from this mapping.
|
||||
- When a page is updated, normalize its existing visible text to this rule within the edited scope.
|
||||
|
||||
## Index
|
||||
|
||||
- Maintain `wiki/index.md` as the retrieval entry point, grouped in this order: source summaries, concepts. Translate these visible group headings into the index's selected document language.
|
||||
- For each indexed page, include a link, one-sentence retrieval description, and important uncertainty.
|
||||
Reference in New Issue
Block a user