01 — 你的 CC Harness 体系全景审计

体系定位

你在 Claude Code 原生能力之上，搭建了一套 个人级 AI 工作流操作系统。它不是一个独立框架，而是通过 CC 的 CLAUDE.md / commands / skills / hooks / memory 这些原生扩展点，组合出了一套完整的 agent harness。

核心理念可以概括为：让 CC 记住你是谁、知道该怎么做、做完能自我维护。

一、五层上下文体系

你的上下文是分层注入的，从全局到局部逐级叠加：

Layer 0  ~/.personal_env          凭证层（API keys, tokens）
Layer 1  ~/.claude/CLAUDE.md      全局人设（VPS、域名、偏好）
Layer 2  ~/Dev/CLAUDE.md          工作区导航（29 repos 地图、技术栈、常用命令）
Layer 3  项目级 CLAUDE.md          项目指南（20+ 个，每个项目独立）
Layer 4  ~/.claude/projects/*/memory/  持久记忆（17 个项目级记忆目录）

优势：CC 每次进入一个项目，自动加载 Layer 1-3 + 对应 Layer 4，不需要手动喂上下文。

当前规模：

全局 CLAUDE.md: ~50 行
工作区 CLAUDE.md: ~180 行
项目级 CLAUDE.md: 20+ 个，合计约 2000+ 行
记忆文件: 17 个项目目录，合计 60+ 个 .md 文件

二、技能系统（Commands + Skills）

Commands（43 个，31 活跃 + 12 归档）

你的 commands 是 prompt 模板，用 Markdown 写的工作流指令。用 /command 触发，CC 把它当作详细任务说明来执行。

分类统计：

类别	数量	代表
Repo 管理	7	/audit, /promote, /ship, /pull, /groom, /repo-map, /health
文档处理	10	/review, /review-deep, /md2word, /draft, /fix-heading, /fix-numbering, /fix-refs, /edit-docx, /revise, /dissect-report
Dashboard & 分析	5	/dashboard, /auggie-dash, /auggie-fix, /scan, /cmd-stats
会话管理	4	/handoff, /recap, /context, /harness
部署 & 运维	2	/deploy, /tidy
其他	3	/reminder, /migrate, /prep-basic-info

管理机制：

统一存放在 cc-configs/commands/，通过 symlink 到 ~/.claude/commands/
/cmd-stats 统计使用频率，零使用的归档到 archive/
编排型 command（如 /groom 调用 /pull → /audit → /promote → /ship）不归档

Skills（14 个，4 全局 + 10 项目级）

Skills 是 自动触发的领域知识包。不需要手动调用，CC 根据项目上下文自动加载。

全局: context, structure, plan-first, quarto
水利领域: eco-flow, capacity, zdys, water-src, risk-map, water-quality, resources
业务: bid（标书写作）
管理: harness（配置分发）

分发机制: harness.yaml 定义哪些 skill 绑定到哪些项目，harness.py sync 执行分发。

Agents（2 个）

bid-chapter-writer — 标书章节写作子代理
project-content-checker — Dashboard 项目完整性检查

三、自动化管线

Hooks（3 个触发点）

Hook	触发时机	动作
Stop	CC 完成任务	macOS 通知弹窗 + Glass 音效
SessionEnd	会话结束	运行 task_analyzer.py 更新 tasks.json
PostToolUse (devtools)	文件编辑后	git_auto_stage.sh 自动暂存

数据管线

CC Sessions (JSONL)
    │
    ├──→ cclog (索引 + 浏览 + 静态站点)
    │
    └──→ task_analyzer.py (Haiku LLM 分析)
              │
              ↓
         tasks.json
              │
              ├──→ repo-dashboard (Web UI)
              └──→ /scan command (CC 内查看)

注册表驱动

所有工具从注册表读取数据，不硬编码：

注册表	路径	消费者
repo-map.json	~/Dev/configs/	git_smart_push, /pull, /ship, dashboard, /audit
tasks.json	~/Dev/configs/	dashboard, /scan
harness.yaml	cc-configs/	/harness, harness.py

四、外部工具链

工具	用途	入口
repo_manager.py (63KB)	promote / audit / screenshot	CLI 或 /promote
cclog	会话浏览、搜索、统计、摘要、静态站点	CLI
repo-dashboard	项目状态 Web UI	dashboard.tianlizeng.cloud
auggie-dashboard	Auggie 索引状态监控	Streamlit
cf_api.py	Cloudflare DNS + Access 管理	CLI 或 CC 内调用
health_check.py	跨项目健康检查	CLI 或 /health

五、跨会话连续性

机制	用途	持久性
Memory 文件	用户画像、项目上下文、行为反馈、外部引用	永久（手动或 /recap 更新）
HANDOFF.md	未完成任务的架构决策和下一步	临时（下次会话消费后可删）
tasks.json	跨项目任务状态总览	持续更新（SessionEnd hook 触发）
cclog SQLite	全量会话历史索引	累积

六、体系特征总结

做得好的：

注册表驱动 — 单一数据源，不硬编码，所有工具共享
分层上下文 — 全局 → 工作区 → 项目 → 记忆，自动叠加
Hook 自动化 — 完成通知、自动暂存、会话结束分析
归档机制 — /cmd-stats 数据驱动，不用的 command 及时归档
Harness 分发 — 一处维护，多处分发，skill 和 command 集中管理
凭证隔离 — ~/.personal_env 统一管理，从不硬编码

可以改进的（详见 02 和 03）：

Memory 搜索能力弱（纯索引，无全文搜索）
Skill 不会自我进化（纯手动维护）
缺少多渠道入口（只有 CLI + Raycast）
缺少定时任务调度（依赖 hook，无 cron）
会话回忆依赖外部工具（cclog 和 CC 内记忆断裂）
用户建模粗糙（一个 user_role.md 远不够）