Dashboard - AI System (LLM Wiki 系统本身)
导读
1. Domain Purpose
这个领域不是某个技术主题,而是 LLM Wiki 系统本身 —— 把分散的阅读、ingest、复盘、产出沉淀成一个可检索、可审计、可生成的个人知识基建。它的目的是让「写过的内容不丢、读过的来源可追溯、关键判断可复盘、需要时一键生成报告/PPT」。换句话说,系统本身要像它服务的那些工程主题一样,有硬约束、有健康指标、有失效模式。本 dashboard 是这套系统的「作战控制台」:看一眼就知道系统现在健康吗、在跑什么、下一步动哪里。
2. Current Focus
当前最重要的几条主线(System View):
- Phase 1-5 升级已全部上线,进入「稳态运维 + 局部增强」阶段:重心从「建能力」转向「保质量、降熵」。
- 内容健康长期保持 0 缺口:broken links / orphan / SVG mirror gap 三项要持续压到 0,任何 ingest 后立刻回归。
- AI 搜索答案稳定性:
/api/ask链路(DeepSeek-V3.1 → Gemini → DeepSeek-R1 + 原文兜底)的 expect_terms 命中要稳,域外拒答靠top_sem<0.5守死。 - 多域 dashboard 数据真实性 (HARD):invest/work/growth/english/reading 各域数据只录事实、不编造。
- 设计系统三层落地:
_tokens.css/_atoms.css/ app-css / atoms*.tsx,改样式严格分层,避免 react-patch 反复微调。
3. Knowledge Map
Architecture(五层栈)
系统从源头到产出是一条单向流水线,每一层职责单一、可独立验证:
- Markdown as source —— 知识的唯一真源。
wiki/pages/人工主题页 + 各域 dashboard;一切派生物都从 markdown 重建。 - Git as version control —— 版本与可追溯层。canonical 内容进 git,本地运行态(
wiki/state/、.obsidian/)不进;wiki 改动自动 commit + push。 - Web UI as interface —— 阅读与检索层。Cloudflare Pages 站点 + Pagefind 四分面搜索 + Cmd+K +
/map知识地图。 - AI as reasoning and production layer —— 推理与生成层。Cloudflare Worker
/api/ask多模型链 + 无依据拒答 + probes 探针 +gen_output输出器。 - Export layer: PDF / PPT / reports —— 交付层。从 markdown 生成 daily / weekly digest、复盘文案、报告与 PPT,面向 iPhone GitHub app 与离线交付。
System Health(健康闭环)
健康层由一组 linter 充当「测试」:lint_pages 编码呈现契约、check_links 编码无断链契约、check_schema 编码 frontmatter 契约、system_content_health 编码无 orphan / 无 SVG mirror gap 契约。下方 §3 健康表给出量化目标。
| Metric | Target |
|---|---|
| Broken links | 0 |
| Orphan pages | 0 |
| Oversized pages | 0 |
| Pages without domain | 0 |
| Pages without summary | 0 |
| Pages without updated date | 0 |
4. Core Pages
系统级文档与可执行入口(脚本/配置用纯文本相对路径,不用 wikilink):
- 架构总览:
docs/architecture.md - 升级计划(Phase 1-5):
docs/upgrade-plan.md - 治理与运维:
docs/governance.md、docs/operations.md - 风格与全局样式:
docs/rules.md、docs/style.md、docs/global-style.md - 设计系统契约:
wiki/internal/design-system.md - 内容健康审计:
wiki/audits/system-content-health.md
Core Files / 可执行入口(Watchlist):
| File | 作用 |
|---|---|
| scripts/lint/lint_pages.py | 页面呈现契约 lint |
| scripts/lint/check_links.py | 断链检查 |
| scripts/lint/check_schema.py | frontmatter schema 校验 |
| scripts/health/score_pages.py | 页面健康评分 |
| scripts/build/build_chunks.py | RAG 切块(无依据拒答数据源) |
| scripts/gen_output.py | 报告/PPT 输出器 |
- 系统本身的概览页 → ai-system overview(计划)
- AI 搜索链路详解页 → ai-search-pipeline(计划)
5. Active Questions
还没收口的问题:
- ask-eval 的 weak/fail 到底是真覆盖缺口还是 LLM variance? 现状是单次 weak 先看
src_miss是否为空再判断;需要更稳的判别口径。 - Oversized pages 的阈值与拆分策略:超大页何时强制拆 hub、何时仅加 SVG 锚点,缺统一规则。
- cold source manifest 的回收边界:超大 PDF 转 cold 后,什么条件下要重新拉回 hot?
- 多模型链成本与延迟:DeepSeek → Gemini → R1 的 fallback 触发率是否过高,有没有可前置的便宜判别?
- 域专属 dashboard 数据新鲜度:
emit_domains.py各域数据多久回归一次才不算「过期但仍展示」?
6. Projects / Workflows
Active Workflows(自动化,全部 GitHub Actions / Worker cron,严禁 launchd)
推进中的长期工作流:
- 内容健康回归:每次 ingest 后跑 lint_pages + check_links + check_schema + system_content_health,目标四项归 0。
- Daily / Weekly digest:
generate_daily.py/generate_weekly_digest.py产出,经 GitHub iPhone app 阅读。 - Followup ping:走 worker
index.jsscheduled handler +wiki/followups.json,零 GH minutes。 - Ingest 流水线:剪藏一键 / 公众号 TG 转发 → workflow_dispatch → LLM 结构化入库。
- CF Pages 本地部署:push 后跑
bash apps/web/scripts/deploy-pages.sh(--commit-message用 ASCII,CJK 会报 UTF-8 错)。 - 多域 dashboard 数据 emit:
scripts/dashboards/emit_domains.py拉各域真实数据喂前端。
7. Decisions / Conclusions
已形成、当作硬约束执行的关键判断(Decision Log):
- Markdown 是唯一真源:任何随本机环境变化或高频脏工作树的派生态,不进 git(
docs/architecture.md§1-§2)。 - Linter 即测试:新增风格偏好先加/改 lint 规则,再迭代页面,不靠人肉记忆。
- 无依据拒答:
/api/ask命中不足时宁可拒答,域外靠top_sem<0.5确定性拒答,不编造。 - 图优先 + hand-SVG only:≥3 项相关内容先想 SVG/table;图一律手画,不用 mermaid/D2;提交前必 rsvg-convert + Read PNG。
- 公式全局 LaTeX:
$...$内禁止 Unicode μ/Ω/²/³ 等混用。 - 样式复用优先 + 三层设计系统:能复用绝不再写;改样式前先动
:roottoken,再动 atom,最后才 page override。 - 不付美国海外 API、不用 launchd:LLM 限国内可支付渠道,自动化一律走 GitHub Actions / Worker cron。
8. Review Queue
需复盘 / 更新 / 拆分的页面或主题:
- ai-system 域目前只有本 dashboard,缺 overview 与各子系统说明页 → 优先补 overview(计划)。
docs/下多份风格文档(rules / style / global-style)职责重叠 → 评估是否合并去重(参 R7,避免两套规范并存)。- Oversized pages 清单 → 定期跑健康评分,挑超阈值页拆 hub 或加 SVG。
- ask-eval 不稳定用例 → 对反复 weak 的 query,在命中页补关键词密度高的小节(§2.4 法)。
- DEPRECATED 历史自动化记录(launchd agents) → 确认全部迁出后归档,避免误用。
9. Recent Outputs
最近产出(报告 / 脚本 / 模板):
- 内容健康审计:
wiki/audits/system-content-health.md(0 缺口)。 - 架构审计:
wiki/audits/2026-05-28-arch-audit.md、密度审计wiki/audits/2026-05-24-density-audit.md。 - 多域 dashboard app 上线:
apps/invest-dashboard(多域下拉 + 多主题 + 实时行情)。 - 设计系统三层契约文档:
wiki/internal/design-system.md。 - Phase 1-5 升级落地:Pagefind 检索 /
/map知识地图 /build_chunks无依据拒答 / probes /gen_output输出器。 - 复盘文案生成器:
scripts/build/generate_review_copy.py(域无关)。
10. Next Actions
下一步可执行动作:
- 运行
python3 scripts/lint/lint_pages.py --path wiki/domains/ai-system/dashboard.md与python3 scripts/lint/check_links.py,确认本页 0 error / 0 warning、链接全解析。 - 跑一次
scripts/automation/system_content_health.py(或现有健康脚本),把 §3 健康表的六项实测值对照 Target,记录偏差到wiki/audits/。 - 起草
wiki/domains/ai-system/overview.md,把本 dashboard 中标「(计划)」的 overview 落成真实页,并回填 backlink 到本 dashboard。 - 对 ask-eval 最近一批 weak/fail 用例,逐条判别 variance vs 真缺口,真缺口的命中页补关键词密集小节。
- push 后跑
bash apps/web/scripts/deploy-pages.sh(--commit-message用 ASCII)验证站点可访问。