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 健康表给出量化目标。

MetricTarget
Broken links0
Orphan pages0
Oversized pages0
Pages without domain0
Pages without summary0
Pages without updated date0

4. Core Pages

系统级文档与可执行入口(脚本/配置用纯文本相对路径,不用 wikilink):

  • 架构总览:docs/architecture.md
  • 升级计划(Phase 1-5):docs/upgrade-plan.md
  • 治理与运维:docs/governance.mddocs/operations.md
  • 风格与全局样式:docs/rules.mddocs/style.mddocs/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.pyfrontmatter schema 校验
scripts/health/score_pages.py页面健康评分
scripts/build/build_chunks.pyRAG 切块(无依据拒答数据源)
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.js scheduled 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 μ/Ω/²/³ 等混用。
  • 样式复用优先 + 三层设计系统:能复用绝不再写;改样式前先动 :root token,再动 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

下一步可执行动作:

  1. 运行 python3 scripts/lint/lint_pages.py --path wiki/domains/ai-system/dashboard.mdpython3 scripts/lint/check_links.py,确认本页 0 error / 0 warning、链接全解析。
  2. 跑一次 scripts/automation/system_content_health.py(或现有健康脚本),把 §3 健康表的六项实测值对照 Target,记录偏差到 wiki/audits/
  3. 起草 wiki/domains/ai-system/overview.md,把本 dashboard 中标「(计划)」的 overview 落成真实页,并回填 backlink 到本 dashboard。
  4. 对 ask-eval 最近一批 weak/fail 用例,逐条判别 variance vs 真缺口,真缺口的命中页补关键词密集小节。
  5. push 后跑 bash apps/web/scripts/deploy-pages.sh(--commit-message 用 ASCII)验证站点可访问。