diff --git a/doc/实践总结与心得.md b/doc/实践总结与心得.md
deleted file mode 100644
index 18a987f..0000000
--- a/doc/实践总结与心得.md
+++ /dev/null
@@ -1,110 +0,0 @@
-# GitLink 智能化能力提升项目 — 实践总结与心得
-
-> 《软件演化与运维》课程实践
-> 2026-06-30 | 刘焱 · 赵昌 · 曾蔚然（组长）
-
----
-
-## 一、项目概述
-
-本项目围绕 GitLink 平台的官方命令行工具 gitlink-cli，完成了四大子任务：
-
-| 子任务 | 内容 | 权重 | 状态 |
-|--------|------|------|------|
-| 子任务一 | 增加和完善 GitLink-CLI 能力 | 50% | ✅ |
-| 子任务二 | 编写和丰富 GitLink Skills | 20% | ✅ |
-| 子任务三 | 构建端到端自动化工作流 | 20% | ✅ |
-| 子任务四 | 应用 GitLink 辅助科研 | 加分 | ✅ |
-
-**交付规模：** 47 个文件 · ~5,800 行代码 · 14 轮迭代 · 全部验证通过
-
----
-
-## 二、各子任务完成情况
-
-### 子任务一：CLI 能力扩展
-
-- 新增 23 个 Shortcut 命令组、181+ 个子命令
-- 新增 REPL 交互模式（命令面板 + 输出视口）
-- 输出格式优化（表格渲染、JSON/Table/YAML）
-- 20 个单元测试文件
-- 4 平台包管理（npm、Homebrew、Scoop、Chocolatey）
-- DevOps CI/CD 流水线（GitLink + GitHub Actions）
-
-### 子任务二：AI Agent Skills
-
-- 11 个 Claude Code Skills（.claude/skills/）
-- 29 个官方 Skills（skills/）
-- 涵盖：Issue 分拣、代码审查、健康度报告、自动 Release、合规检查等
-- 全部在 Claude Code 平台端到端验证
-
-### 子任务三：端到端工作流
-
-**场景 A — 社区运营自动化：**
-- 三阶段流水线：Issue 分拣 → 周报生成 → Release Notes
-- 4 个 Bash 脚本 + 2 个 JS 分析引擎
-- 自动生成 HTML 可视化报告
-
-**场景 B — 代码质量看门人：**
-- 四阶段门禁：PR 采集 → 审查 → CI 检查 → 质量评分
-- 加权评分模型：CodeReview×40% + CI×30% + 设计一致性×30%
-
-### 子任务四：科研辅助
-
-**模块 C — 科研项目洞悉：**
-- 8 维数据采集，4 维度加权评分
-- 真实数据分析：16 贡献者、15 Issues、Go 93.8%
-
-**模块 D — 热点追踪与知识图谱：**
-- 多关键词搜索、实体关系提取
-- 交互式 HTML 知识图谱（缩放/拖拽/高亮/导出）
-- 覆盖 33 个仓库、19 个主题标签、11 种语言
-
----
-
-## 三、实践心得
-
-### 1. 从"手动操作"到"Agent 驱动"的思维转变
-
-本次实践让我们深刻体会到 AI Agent 对开发模式的改变。gitlink-cli 的 Skills 体系让 Claude Code 可以直接调用 GitLink 平台能力，开发者从"记命令、敲命令"变成了"说需求、看结果"。这种 Agent 驱动的工作方式在子任务三的工作流自动化中体现得尤为明显——我们不只写工具，更是在编排 AI 的工作流程。
-
-### 2. 端到端集成的价值
-
-子任务一和子任务二的工作是"造零件"（CLI 命令 + Skill 文档），子任务三和子任务四才是"组装产品"。最初的 Skills 是独立的知识库，通过工作流脚本串联后，才真正发挥了 1+1>2 的效果。比如社区运营工作流把 issue-triage、project-health、release-auto 三个 Skills 串联起来，实现了从 Issue 创建到版本发布的完整闭环。
-
-### 3. 可复现性的重要性
-
-所有脚本参数化设计（`DRY_RUN` 模式、`OWNER/REPO` 参数）让我们深刻体会到好的设计对调试的帮助。最初几次测试时数据写死的脚本出了问题后很难定位，重构为参数化后，不仅可以在不同仓库间复用，出错时也能快速定位是哪个环节的问题。
-
-### 4. 数据驱动决策
-
-科研洞察模块的 4 维度评分模型让我们看到数据如何转化为可量化的结论。"综合评分 4.8/10" 不是拍脑袋出来的，而是从 8 个数据维度、经过加权计算得到的。这种数据驱动的方式同样适用于项目管理——通过周报中的趋势数据来判断社区健康度，比凭感觉准确得多。
-
-### 5. 跨平台兼容的挑战
-
-Windows 环境下的 MSYS2 路径问题（`/e/` vs `E:\`）让我们花了不少时间调试。最终通过 `process.argv` 传参而不是直接拼接路径解决了问题。这提醒我们，跨平台工具开发时，路径处理要格外谨慎，最好使用框架提供的抽象层。
-
-### 6. 团队协作的节奏
-
-三人小团队的分工模式（一人底层架构、一人命令实现、一人统筹协调）效率很高。Git 的 Issue 系统作为任务追踪工具效果不错，但文档同步仍然是个痛点——同一份报告在多人之间流转时，版本管理需要更加规范。
-
----
-
-## 四、存在问题与改进方向
-
-| 问题 | 说明 | 改进方向 |
-|------|------|----------|
-| CLI 版本碎片化 | npm 版与源码版命令集不一致 | 统一构建发布流程 |
-| API 字段不一致 | GitLink API 返回的字段名与文档有时不符 | 增加 API 适配层 |
-| 测试覆盖不足 | 子任务三/四缺少自动化测试 | 补充 CI 中的集成测试 |
-| 报告手动生成 | 需要手动运行脚本生成报告 | 集成到 DevOps 流水线自动生成 |
-
----
-
-## 五、总结
-
-通过本次实践，我们从用户变成开发者，真正理解了"智能化能力提升"的含义——不只是增加功能，更是让工具具备被 AI 理解和调用的能力。gitlink-cli 的 Skills 体系和工作流脚本，展示了 CLI 工具在 AI 时代的演进方向：从"人类操作工具"到"AI 编排工具"。
-
-> 最终交付：47 个文件 · ~5,800 行代码 · 14 轮迭代 · 全部验证通过
-> 
-> 贡献者：刘焱（78 commits）、赵昌（46 commits）、曾蔚然组长（9 commits）