01Git 关联现状诊断
你问"不应该是 1 个项目 1 个内容么"——完全正确，但目前只有 xingtu-site 做到了。现状如下：
| 位置 | git 现状 | GitHub 关联 | 判定 |
|---|---|---|---|
xingtu-site/（个人站点） | ✅ 独立 .git（今天 14:46 创建） | ✅ git@github.com:xingtu1996/xingtu-site.git（已 push） | ✅ 正确形态 |
xingtu/（工作区根） | ❌ 无独立 .git，嵌套在家目录大仓库（git root = ~） | ❌ 无 remote | ⚠ 混乱根源 |
08_开源与作品集/tokenhub_bench/ | ❌ 未建 git | ❌ 无远程仓库 | 待规划 |
混乱根源：xingtu 所有文件都在家目录仓库（
~）的跟踪范围内，但没有自己的提交历史 / remote / 版本线。之前 git status 显示 547 项未跟踪（含 中台工程仓 等无关项目），就是这个原因——工作区与家目录互相污染。你的直觉是对的：1 个项目 = 1 个独立 git 仓库（含 GitHub remote）。xingtu 工作区、xingtu-site、每个开源项目都应各自独立。
02仓库规划：1 项目 1 仓库映射表
| 仓库 | 本地路径 | GitHub 建议 | 用途 | 优先级 |
|---|---|---|---|---|
| xingtu 工作区 | ~/工作室/xingtu | xingtu1996/xingtu-workspace（私有） | 自媒体运营工作区：内容/运营/台账/素材/规则/SOP——独立 git init + 私有远程 | P0 立刻 |
| xingtu-site | …/xingtu/xingtu-site | ✅ 已关联 xingtu1996/xingtu-site | 个人独立站（Cloudflare Pages 部署） | 已完成 |
| 开源项目（每项目 1 仓库） | 08_开源与作品集/<项目>/ | xingtu1996/<项目>（公开） | tokenhub_bench 等——发布才建仓库（走 04_开源SOP） | 按需 |
| 知识库（可选独立） | 06_个人知识库_Obsidian/ | xingtu1996/kb-wiki（私有） | LLM Wiki 知识库（见④）——也可并入工作区仓库 | 二选一 |
核心动作：给 xingtu 工作区
git init 独立成库（.gitignore 已就位，敏感文件已忽略，可安全入私有仓库），解除与家目录大仓库的嵌套。之后 git status 在家目录层面不再出现 547 项噪音。03散乱文件归位方案
根目录 26 个非目录文件，按"锚点留根 / 内容进 02 / 运营进 03 / 调研进 07 / 灵感进 02 池"分组归位（全部 mv，先备份，等你确认后执行）：
| 目标位置 | 文件 | 说明 |
|---|---|---|
| 留根（锚点） | README.md HARNESS.md DIRECTORY.md 行途Harness控制台 工作看板Canvas | 路标/说明书/注册中心/可视化入口 |
| 02_内容仓库 (Content Hub) | 行途系列内容文档：体系手册 / 可视化看板 / 目录树 / 四大空间设计 / 经历素材库设计 / 防弹工作法 / 域名系列×3 / 会话沟通记录 / 白盒教程 / 域名建站实战手记 | 内容成品与教程类 |
| 03_运营工具箱 | CodeMax_DS选型 CodingPlan_全网选型 CodingPlan_用量对照 AI编程订阅选型 benchmark_*.csv codemax_usage_queries.sql 个人工作台_知识可视化看板 全平台自动发布方案 GitHub改名决策复盘 | 运营/选型/工具分析类 |
| 02 灵感池 | 矩阵想法.txt | 灵感素材 |
| 07_调研与情报工作台 | 行途个人站从0到1白盒教程_2026-08.html（内容成品则归 02） | 教程/调研产物二选一 |
撞名目录清理：
02_内容仓库（44K 空壳）含 AI进化时间线与内容体系/（3 个 md），Content Hub 内也有同名子目录——先 diff 两处内容，空壳目录整体 safe-delete（可还原）。根目录收口目标：只留「README / HARNESS / DIRECTORY / 控制台 / 工作看板」5 个锚点 + 待执行提案文档，其余全部下沉到对应目录。
04LLM Wiki 知识编译层（融合你的实践）
你给的 LLM Wiki 理念（Raw→Wiki→Schema 三层 + AI 知识编译）正好把 xingtu 的"素材→知识→内容"链路升级为可生长的结构化知识网络——比临时翻书（RAG）高效的本质：AI 摄入时即编译，查询时直接命中结构化页。
三层架构 ↔ xingtu 现有目录映射
| 层 | 理念 | xingtu 载体 | AI 职责 |
|---|---|---|---|
| Raw 层 | 原始不可变资料 | 05_竞品参考 · 04_会话与复盘 · 07_调研素材库 · 02_灵感与选题池 · Web Clipper 剪藏 | 只存不改，留原始证据 |
| Wiki 层 | AI 编译的结构化知识 | 06_Obsidian（主题页/摘要/对比）· 11_素材卡（结构化）· 02_文章成品 | 按 Schema 自动生成 md 页、双向链接、矛盾标注、增量更新（像 Git 版本演进） |
| Schema 层 | 知识加工规则 | rules/RULES.md · workflows/ · specs/_TEMPLATE/ · 各空间模板 · 待建 06_Obsidian/AGENTS.md | 定义"怎么加工"的规则，AI 按规则编译 |
🔧 待建：06_Obsidian/AGENTS.md（知识编译规则，Schema 层落地）
# kb-wiki · 知识编译规则（AGENTS.md） > 本文件是知识库的「加工宪法」：AI 按此规则把 Raw 素材编译成 Wiki 结构化页。 ## 三层目录 raw/ 原始不可变（剪藏/会话/调研素材）——只存不改 wiki/ AI 编译页（实体页/主题页/对比页）——双向链接 + 矛盾标注 templates/ 页面模板 ## 编译规则（AI 执行） 1. 实体/概念页：一页一主题（如 "LLM原理"、"Harness"），标题即实体名 2. 双向链接：页内用 [[双链]] 关联相关页，新概念自动建页 3. 矛盾标注：两源冲突时保留双方 + 标注 ⚠冲突（来源A vs 来源B） 4. 增量更新：编译是编辑已有页，不重复建页（像 Git commit，非覆盖重写） 5. 来源必录：每页底部挂来源 + 验证程度（BUL-003：实测/引用/估算） ## 治理（健康检查） - 孤儿页 / 断链 / 30 天未更新页 → 周度清单 - 采集来源：Web Clipper → raw/；会话 → 04_；WorkBuddy 定时同步 → 编译
🔧 知识编译工作流（WorkBuddy 自动化）
采集Web Clipper / 会话 / IMA → Raw
→
编译AI 按 AGENTS.md → Wiki 页
→
查询优先检索结构化 Wiki
→
治理健康检查 / 矛盾标注
与 xingtu 的咬合点：07 调研结论 → 编译进 wiki（主题页）；11 素材卡 → 成为 wiki 实体页的"证据锚"；02 文章成品 → 从 wiki 主题页"生长"出来。这样"素材→知识→内容"是同一个网络，不再是三个孤立文件夹。适用建议采纳：从 AI 工具链这一个垂直领域起步（12 研究室天然是原料源）。
05待确认执行清单（全部等你点头才动）
- ① git init xingtu 工作区 —— 独立成库（私有 remote
xingtu1996/xingtu-workspace），解除家目录嵌套；gitignore 已就位，敏感文件已忽略 - ② 散乱文件归位 —— 按③分组
mv下沉（先 backup-before-op 快照），撞名02_内容仓库空壳 diff 后 safe-delete - ③ 建 06_Obsidian/AGENTS.md —— Schema 层落地 +
raw/wiki/templates目录（纯新增，零风险） - ④ 知识库仓库二选一 —— kb-wiki 独立私有仓 vs 并入工作区仓库（建议先并入，轻量起步）
- ⑤ xingtu-site 后续 —— 已正确，无需动；页面内容填真实链接即可
安全承诺不变：所有移动用
mv、绝不 rm -rf、改动前 backup-before-op.sh、删除走 safe-delete.sh 可还原。你说"动手"我按 ①→②→③ 顺序执行。