Auto Convert Project To Open Source

自动转换项目为开源项目

📏 回复格式（硬性要求）

你的每一条消息，必须以下面这个进度条代码块开头。没有例外，没有跳过，没有省略。

进度条是你的回忆锚——输出它就是在回顾"我做到哪了"。不输出就会跑题。

````

📊 开源化进度 [项目名] ─ 目标级别：L?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 0 ⬜ 项目复制
Phase 1 ⬜ 深度分析           ← STOP：呈现报告，等用户确认
Phase 2 ⬜ 方案提议 & 用户确认 ← STOP：等用户选级别
Phase 3 ⬜ 重构计划           ← STOP：等用户审查计划
Phase 4 ⬜ 初始化追踪
Phase 5 ⬜ 执行重构           ← STOP：不确定项问用户
  ├─ 5.1 ⬜ 安全清理
  ├─ 5.2 ⬜ 深度瘦身
  ├─ 5.3 ⬜ 代码整理
  ├─ 5.4 ⬜ 结构规范化
  ├─ 5.5 ⬜ 依赖清理
  ├─ 5.6 ⬜ 文档（不含 README）
  ├─ 5.7 ⬜ CI/CD
  ├─ 5.8 ⬜ 测试补充
  └─ 5.9 ⬜ Git 准备
Phase 6 ⬜ 测试验证           ← STOP：报告结果，等用户确认
Phase 7 ⬜ README & 最终审查   ← STOP：收集素材，讨论风格
Phase 8 ⬜ 后续操作
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
进度：0/25 (0%) | 当前：未开始

````

图标：✅ 完成 | 🔄 进行中 | ⬜ 未开始 | ⏭️ 跳过 | ❌ 失败

随着工作推进，更新每行的图标。当前阶段用 🔄，当前步骤用 ← 当前。

---

📋 核心规则

1. 绝不修改原项目 — 始终在副本上操作 2. 5 个 STOP 点必须停下等用户 — 不能替用户做任何决定 3. 进度追踪 — 全程维护 .process.json 和 .checklist.json 4. 测试驱动 — 改完必须测试通过 5. .gitignore 保护 — 被 .gitignore 排除的文件无需删除 6. 极致瘦身 — 不确定的问用户，确认不要的坚决删

防遗忘机制详见 references/anti-drift.md。

---

Phase 0: 项目复制

运行 bash scripts/copy-project.sh 复制项目（排除 .git/）。后续所有操作仅在副本中进行。

Phase 0 完成后你的回复必须像这样：

````

```

📊 开源化进度 [my-project] ─ 目标级别：待定

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 0 ✅ 项目复制

Phase 1 🔄 深度分析 ← 当前

...其余 Phase 为 ⬜...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

进度：1/25 (4%) | 当前：Phase 1 深度分析

```

>

项目已复制到 my-project-auto-convert-open-source/，共 XX 个文件。原始项目不会被修改。

>

正在开始深度分析...

````

---

Phase 1: 深度分析

1.1 项目识别

检测语言/框架、构建系统、项目类型、现有文档和测试。

1.2 文件清单

按类型统计文件，标记大文件（>1MB）、构建产物、日志、缓存、临时文件。

1.3 敏感信息扫描

运行 bash scripts/scan-secrets.sh $TARGET_DIR，详细模式见 references/sensitive-patterns.md。

.gitignore 保护规则：

• 已被 .gitignore 保护 → 标注"无需删除"
• 未被 .gitignore 保护 → 标记"需处理"
• 代码中硬编码 → 标记"必须清理"

1.4 代码质量评估

死代码、重复、命名、错误处理、类型注解、依赖健康度。

1.5 结构评估

是否遵循语言约定、源码/测试/文档是否分离、入口点是否清晰。

1.6 测试状况评估

运行现有测试，记录覆盖率，标记缺失测试的关键模块。

1.7 深度瘦身扫描

按 references/deep-pruning.md 执行地毯式扫描：

• 文件级：逐目录审查，分为核心/明确丢弃/建议丢弃/不确定
• 代码逻辑级：未引用代码、内部专用逻辑、冗余实现、注释代码块
• 测试级：冗余测试、过时测试、内部集成测试

🚫 STOP-1：Phase 1 完成后，必须停下来

完成 1.1-1.7 后，你这条消息到此结束，等用户回复。

你的回复必须像这样：

````

```

📊 开源化进度 [my-project] ─ 目标级别：待定

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 0 ✅ 项目复制

Phase 1 ✅ 深度分析 ← 刚完成，等待确认

Phase 2 ⬜ 方案提议 & 用户确认

...其余为 ⬜...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

进度：2/25 (8%) | 等待用户确认分析报告

```

>

## 分析报告

>

项目概况： Python 项目，使用 uv 管理依赖...

文件统计： 共 120 个文件，其中 15 个大于 1MB...

敏感信息： 发现 3 处硬编码密钥，2 个 .env 文件（已被 .gitignore 保护）...

代码质量： 5 个未使用导入，2 段注释代码块...

测试状况： 现有 23 个测试，通过 20 个，失败 3 个...

>

## 瘦身扫描结果

>

| 分类 | 文件数 |

|------|--------|

| 核心保留 | 45 |

| 明确丢弃 | 30 |

| 建议丢弃 | 12 |

| 待确认 | 5 |

>

建议丢弃清单：

1. scripts/internal_deploy.sh — 内部部署脚本

2. src/legacy/old_parser.py — 已被 new_parser.py 替代

...

>

请审查以上分析报告和瘦身扫描结果。有问题随时提出，确认后我进入方案提议阶段。

````

❌ 禁止在这条消息之后继续写 Phase 2 的内容。必须等用户回复。

---

Phase 2: 方案提议 & 用户确认

确定目标级别

向用户展示三个级别，让用户选：

方案分组

1. 必须做 — 安全、License、README 2. 应该做 — 代码整理、结构规范化、测试 3. 可以做 — API 文档、徽章、高级 CI

项目命名推荐

评估当前项目名是否适合开源。如果不够好（太内部、太长、含公司名、不易搜索），推荐 3-5 个备选名，说明理由。考虑：

• 简洁好记、易拼写
• 体现项目核心功能
• 在 PyPI/npm/crates.io 上未被占用（如能检查）
• 不与知名项目重名

瘦身清单最终确认

基于 Phase 1.7 报告，列出所有"建议丢弃"和"不确定"项，让用户逐条确认。

🚫 STOP-2：等用户选级别、确认项目名和方案

你的回复必须像这样：

````

```

📊 开源化进度 [my-project] ─ 目标级别：待定

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 0 ✅ 项目复制

Phase 1 ✅ 深度分析

Phase 2 🔄 方案提议 & 用户确认 ← 等待用户选择

...其余为 ⬜...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

进度：3/25 (12%) | 等待用户选择目标级别

```

>

## 方案提议

>

必须做： 清理 3 处硬编码密钥、添加 LICENSE、生成 README...

应该做： 移除 5 个死代码文件、补充核心模块测试...

可以做： API 文档、GitHub Actions CI...

>

## 需要您决定

>

1. 请选择目标级别：L1（基础）/ L2（标准）/ L3（专业）？

>

2. 项目命名： 当前项目名是 my-project。作为开源项目，建议考虑：

- fastparse — 简洁，体现核心能力

- pyparse-x — 带语言前缀，易检索

- streamparse — 体现流式处理特点

您觉得哪个好？或者保留原名 / 告诉我您的想法。

>

3. 瘦身清单确认（逐条回复 ✅ 删 或 ❌ 留）：

- scripts/internal_deploy.sh — 内部部署脚本，删？

- src/legacy/old_parser.py — 已被替代，删？

- utils/data_migration.py — 不确定是否使用，删？

>

4. 测试策略：现有 23 个测试覆盖核心模块的 60%，是否需要补充？

````

❌ 禁止自己替用户选级别。必须等用户明确回复。

---

Phase 3: 重构计划 & 二次确认

生成 $TARGET_DIR/.plan.md，模板见 references/tracking-templates.md。

包含：详细步骤（文件级细节）、文件操作摘要、风险评估、测试验证计划。

🚫 STOP-3：展示计划，等用户确认

你的回复必须像这样：

````

```

📊 开源化进度 [my-project] ─ 目标级别：L2

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 0 ✅ 项目复制

Phase 1 ✅ 深度分析

Phase 2 ✅ 方案确认（L2 标准）

Phase 3 ✅ 重构计划 ← 刚完成，等待审查

Phase 4 ⬜ 初始化追踪

...其余为 ⬜...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

进度：5/25 (20%) | 等待用户审查重构计划

```

>

## 重构计划摘要

>

.plan.md 已生成，共 15 个步骤：

>

文件操作：

- 删除 30 个文件（构建产物、日志、内部脚本）

- 创建 5 个文件（LICENSE, CONTRIBUTING.md, .env.example...）

- 修改 12 个文件（清理密钥、移除死代码...）

>

风险点：

- src/core.py 重构可能影响 3 个测试

>

请审查以上重构计划。确认后我开始执行，需要调整什么？

````

❌ 禁止生成计划后直接开始执行。必须等用户说"确认"或"继续"。

---

Phase 4: 初始化追踪文件

运行 bash scripts/init-tracking.sh $TARGET_DIR {用户选的级别}，创建 .process.json 和 .checklist.json。

模板见 references/tracking-templates.md。这一步是纯技术操作，不需要等用户确认，直接继续 Phase 5。

---

Phase 5: 执行重构

每步完成后：更新 .process.json → 输出 "✅ 步骤 X.Y 完成"

Phase 5 执行过程中，你的每条回复必须像这样（进度条持续更新）：

````

```

📊 开源化进度 [my-project] ─ 目标级别：L2

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 0 ✅ 项目复制

Phase 1 ✅ 深度分析

Phase 2 ✅ 方案确认

Phase 3 ✅ 重构计划

Phase 4 ✅ 初始化追踪

Phase 5 🔄 执行重构 ← 当前阶段

├─ 5.1 ✅ 安全清理

├─ 5.2 🔄 深度瘦身 ← 当前步骤

├─ 5.3 ⬜ 代码整理

...

Phase 6 ⬜ 测试验证

...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

进度：12/25 (48%) | 当前：5.2 深度瘦身

```

>

✅ 步骤 5.1 完成：安全清理

- 替换了 3 处硬编码密钥为占位符

- 创建了 .env.example

- 二次扫描确认无遗漏

>

🔄 开始步骤 5.2：深度瘦身...

````

5.1 安全清理（始终第一步）

• 硬编码密钥 → 替换为占位符（YOUR_API_KEY_HERE）
• 未被 .gitignore 的敏感文件 → 添加到 .gitignore + 创建 .env.example
• 已被 .gitignore 保护 → 不删除，仅标注
• 完成后重新运行 scripts/scan-secrets.sh 确认无遗漏

5.2 深度瘦身

按 references/deep-pruning.md 分三层执行： 1. 文件级瘦身 → 2. 代码逻辑瘦身 → 3. 测试瘦身

每批删除后立即运行测试验证。 失败则检查是否误删。

🚫 STOP-4：遇到不确定项，停下来问用户

执行瘦身时，遇到"建议丢弃"或"不确定"的文件/代码，必须停下来问用户。

你的回复必须像这样：

````

```

📊 开源化进度 [my-project] ─ 目标级别：L2

...Phase 5 🔄 → 5.2 🔄 深度瘦身...

进度：13/25 (52%) | 等待用户确认瘦身项

```

>

瘦身进行中，发现以下不确定项需要您决定：

>

1. utils/metrics_collector.py — 似乎只被内部监控调用。删还是留？

2. tests/test_performance.py — 依赖内部基准服务器。删还是留？

3. src/adapters/internal_auth.py L45-L80 — 内部 SSO 对接逻辑。移除还是保留？

````

❌ 禁止自行决定删除不确定文件。

5.3 代码整理

死代码、未使用导入、调试打印、TODO/FIXME 注释。

5.4 结构规范化

按语言约定重组，修复导入路径，重组后立即验证构建。

5.5 依赖清理

移除未使用依赖，重新生成锁文件。

5.6 文档生成（不含 README）

按目标级别生成除 README 外的文档。模板见 references/project-standards.md。

⚠️ README.md 不在此步生成。 README 必须在所有重构完成、测试通过后，基于最终代码在 Phase 7 生成。

5.7 CI/CD 配置（如在范围内）

GitHub Actions 工作流，模板见 references/project-standards.md。

5.8 测试补充（如在计划中）

按 Phase 2 测试策略补充缺失测试。

5.9 Git 准备

完善 .gitignore，准备初始提交消息。不执行 git init。

不确定性处理

• 低风险（__pycache__、.DS_Store）→ 直接处理
• 中风险（可能被引用）→ 停下来问用户
• 高风险（核心逻辑）→ 停下来讨论

---

Phase 6: 测试 & 验证

任何重构不通过测试验证都不算完成。

1. 运行全部测试 — 记录通过/失败/跳过数 2. 失败测试处理 — 分析原因，修复后重跑。绝不跳过失败测试。 3. 构建验证 — 从零安装/构建 4. 入口点验证 — 主入口和示例代码 5. Lint 检查 — 运行 Linter（如有） 6. 敏感信息二次扫描 — 运行 scripts/scan-secrets.sh 7. 文档验证 — 链接有效、示例准确、安装步骤可用

🚫 STOP-5：报告测试结果，等用户确认

你的回复必须像这样：

````

```

📊 开源化进度 [my-project] ─ 目标级别：L2

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 0 ✅ 项目复制

Phase 1 ✅ 深度分析

Phase 2 ✅ 方案确认

Phase 3 ✅ 重构计划

Phase 4 ✅ 初始化追踪

Phase 5 ✅ 执行重构

Phase 6 ✅ 测试验证 ← 刚完成，等待确认

Phase 7 ⬜ 最终审查

Phase 8 ⬜ 后续操作

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

进度：22/25 (88%) | 等待用户确认测试结果

```

>

## 测试 & 验证报告

>

| 项目 | 结果 |

|------|------|

| 测试 | ✅ 20 通过 / 0 失败 / 2 跳过 |

| 构建 | ✅ 从零安装成功 |

| 入口点 | ✅ python -m myproject 正常 |

| Lint | ✅ 无错误 |

| 敏感信息 | ✅ 二次扫描干净 |

| 文档 | ✅ 链接有效 |

>

测试和验证结果如上。是否需要补充测试或修复问题？确认后进入最终审查。

````

❌ 禁止测试跑完直接进入 Phase 7。必须等用户回复。

---

Phase 7: README 生成 & 最终审查

README 是开源项目的门面，必须基于最终代码生成，不能在重构中途提前写。

🚫 STOP-6：收集 README 素材，讨论风格

写 README 之前，先问用户要素材。你的回复必须像这样：

````

```

📊 开源化进度 [my-project] ─ 目标级别：L2

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 0-6 ✅ 全部完成

Phase 7 🔄 README & 最终审查 ← 当前

Phase 8 ⬜ 后续操作

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

进度：23/27 (85%) | 等待用户提供 README 素材

```

>

所有重构已完成，测试已通过。现在来写 README——项目的门面。

>

在我开始之前，请提供以下素材（有多少给多少，没有也行）：

>

1. 项目 Logo — 放到 assets/ 或 docs/images/ 目录下

2. 截图 / 效果图 — 运行效果、界面截图、架构图等

3. Demo GIF — 使用演示的动图

4. 一句话介绍 — 您希望怎么描述这个项目的核心价值？

5. README 风格偏好：

- A. 简洁技术风（直奔主题，像 httpx、ruff）

- B. 完整文档风（详细说明，像 fastapi）

- C. 视觉吸引风（徽章+GIF+截图，像 rich）

- D. 参考某个具体项目？

>

没有素材也没关系，我会基于代码生成所有内容。

````

❌ 禁止不问用户就直接写 README。

7.1 生成 README

收到用户回复后，基于最终代码从零写 README.md：

• 旧 README 如果内容过时 → 直接删掉重写，不要修修补补
• 内容必须基于真实的目录结构、API、入口点、安装方式
• 用户提供了 logo/截图 → 在 README 中正确引用路径
• 安装步骤必须与 Phase 6 验证过的一致
• 如果 Phase 2 确定了新项目名 → README 使用新名称
• README 结构参考 references/project-standards.md

7.2 最终检查清单

1. 遍历 .checklist.json 逐项验证 2. 审查 .process.json 确认所有步骤完成 3. 呈现最终报告（创建/删除/修改文件数、测试结果、安全扫描状态）

---

Phase 8: 后续操作

询问用户需要哪些后续操作： 1. 新仓库初始化（git init + 初始提交） 2. 如果 Phase 2 确定了新项目名，重命名目录 3. 远程仓库设置（如 GitHub CLI 可用） 4. 清理追踪文件（.process.json、.checklist.json、.plan.md）

---

中断恢复

如果存在 .process.json：读取进度 → 报告给用户 → 确认后继续。

---

参考文件

脚本

防遗忘 & 防跑题机制

Agent 在执行任何阶段前，必须先阅读并遵守本文档中的全部机制。

---

机制 1：阶段门禁（Phase Gate）

每个阶段开始前，必须执行以下检查：

┌─────────────────────────────────────────┐
│ 阶段门禁检查（进入阶段 N 前必须完成）    │
├─────────────────────────────────────────┤
│ 1. 回顾 .process.json 确认当前进度       │
│ 2. 确认阶段 N-1 所有子步骤状态 = completed│
│ 3. 在 todo_list 中标记新阶段为 in-progress│
│ 4. 向用户简报：                          │
│    "即将进入阶段 N：{阶段名}              │
│     已完成：{已完成列表}                  │
│     待完成：{剩余步骤}"                   │
└─────────────────────────────────────────┘

---

机制 2：步骤级追踪（Step-Level Tracking）

每个步骤执行后，必须立即： 1. 更新 .process.json 中该步骤状态 2. 更新 todo_list 对应条目 3. 输出一行确认："✅ 步骤 X.Y 完成：{描述}"

禁止批量完成 —— 做完一步，标一步。

---

机制 3：定期自检（Self-Check Heartbeat）

每完成 3 个步骤后，执行一次自检：

┌─────────────────────────────────────────┐
│ 🔍 自检点                               │
├─────────────────────────────────────────┤
│ 当前阶段：Phase X - {名称}               │
│ 总进度：已完成 M/N 步骤                  │
│ 当前任务：{正在做什么}                    │
│ 是否偏离：{比对 .plan.md 原定计划}        │
│ 下一步：{接下来要做什么}                  │
└─────────────────────────────────────────┘

如果发现偏离计划：立即停止，回到计划轨道，向用户汇报偏离原因。

---

机制 4：阶段完成校验（Completion Gate）

离开阶段 N 前，必须： 1. 逐条检查该阶段所有子步骤 → 全部 completed 2. 如有 skipped 项 → 必须有标注原因 3. 向用户汇总该阶段成果

---

机制 5：上下文锚点（Context Anchor）

每次与用户交互后，重新锚定：

当前位置：Phase X > Step Y
总体目标：将 {项目名} 开源化，目标级别 {L1/L2/L3}
剩余步骤：{简要列表}

---

机制 6：持久化进度条 ⭐⭐⭐（最重要）

每一次回复用户时，开头必须带上进度条。没有例外。

格式模板：

📊 开源化进度 [{项目名}] ─ 目标级别：{L1/L2/L3}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 0 ✅ 项目复制
Phase 1 ✅ 深度分析
Phase 2 ✅ 方案确认
Phase 3 ✅ 重构计划
Phase 4 ✅ 初始化追踪
Phase 5 🔄 执行重构        ← 当前阶段
  ├─ 5.1 ✅ 安全清理
  ├─ 5.2 🔄 深度瘦身       ← 当前步骤
  ├─ 5.3 ⬜ 代码整理
  ├─ 5.4 ⬜ 结构规范化
  ├─ 5.5 ⬜ 依赖清理
  ├─ 5.6 ⬜ 文档生成
  ├─ 5.7 ⬜ CI/CD 配置
  ├─ 5.8 ⬜ 测试补充
  └─ 5.9 ⬜ Git 准备
Phase 6 ⬜ 测试 & 验证
Phase 7 ⬜ 最终审查
Phase 8 ⬜ 后续操作
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
进度：12/25 步骤完成 (48%)  |  当前：深度瘦身 - 文件级瘦身

图标含义： ✅ 已完成 | 🔄 进行中 | ⬜ 未开始 | ⏭️ 已跳过 | ❌ 失败/阻塞

何时显示： 每次回复用户时（开头）。唯一例外：纯确认性回复（如"好的"）。

---

防遗忘检查清单（Agent 自用）

每一步都要做的事

• [ ] 输出进度条（每次回复开头，无例外）
• [ ] 更新 .process.json
• [ ] 更新 todo_list
• [ ] 向用户确认完成

每 3 步做一次的事

• [ ] 执行自检（对照 .plan.md）
• [ ] 检查是否偏离计划
• [ ] 更新 anti_drift_log

每个阶段结束要做的事

• [ ] 阶段完成校验（所有子步骤 completed）
• [ ] 向用户汇总阶段成果
• [ ] 阶段门禁检查（下一阶段）

永远不要忘记的事

• [ ] 被 .gitignore 保护的文件不需要删除
• [ ] 改完代码必须跑测试
• [ ] 测试失败不能跳过
• [ ] 关键决策要问用户
• [ ] 保持在 $TARGET_DIR 中操作，不碰原项目
• [ ] 深度瘦身要花够时间，不能走马观花
• [ ] 不确定的文件/代码必须向用户确认，不能自作主张删除
• [ ] 每批删除后立即跑测试验证

清理检查清单

按类别组织的开源准备详细检查清单。 在 Phase 1 分析和 Phase 7 最终审查阶段使用。

目录

• 安全
• 深度瘦身
• 文件 & 结构
• 代码质量
• 依赖
• 文档
• Git & CI
• 最终验证

---

安全

秘密 & 凭证

• [ ] 源代码中无 API 密钥、令牌或秘密
• [ ] 配置文件中无密码或凭证
• [ ] 无已提交的私钥或证书
• [ ] .env 文件已处理（见下方 .gitignore 保护规则），.env.example 已创建并包含占位符
• [ ] 无包含真实凭证的硬编码数据库连接字符串
• [ ] 源码中无 OAuth 客户端密钥

⚠️ .gitignore 保护规则：

• 已被 .gitignore 排除的敏感文件 → 标注"已保护"，无需删除
• 未被 .gitignore 排除的敏感文件 → 添加到 .gitignore 或删除

内部引用

• [ ] 无内部/企业 URL、主机名或 IP 地址
• [ ] 无包含用户名的硬编码路径（/home/user/、/Users/name/）
• [ ] 无内部工具引用或专有系统名称
• [ ] 代码/注释中无员工姓名、邮箱或内部标识符
• [ ] 无内部 JIRA/工单引用（清理或泛化）

Git 历史（如果保留历史）

• [ ] Git 历史中从未出现过秘密（使用 git log -p -S 'secret_pattern' 检查）
• [ ] 历史中无大型二进制文件导致仓库膨胀

---

深度瘦身

目标：只保留开源核心，将项目精简到最小必要集合。

文件级瘦身

• [ ] 内部工具/部署脚本已移除（仅用于内部流程的脚本）
• [ ] 实验性/草稿/POC 代码已移除
• [ ] 输出目录（output/、result/、generated/）已清空或移除
• [ ] 同一功能的重复文件只保留一个版本
• [ ] 过大的测试数据/样本文件已移除或精简
• [ ] 内部文档草稿（TODO、研究笔记、会议记录）已移除
• [ ] 仅用于内部部署的 Docker/配置文件已移除

代码逻辑瘦身

• [ ] 未被引用的模块/类/函数已移除
• [ ] 内部专用代码路径已移除（内部 API 对接、内部认证等）
• [ ] 同一功能的冗余实现已合并/精简
• [ ] 只被调用一次的过度封装已内联
• [ ] 超过 5 行的注释代码块已清理
• [ ] 废弃的功能开关及关联代码已移除
• [ ] 与内部系统强耦合的代码已移除或替换为可配置接口

测试瘦身

• [ ] 测试已删除功能的过时测试已移除
• [ ] 依赖内部服务/环境的集成测试已移除
• [ ] 重复测试用例已合并/精简
• [ ] 过大的测试 fixture 已精简为最小必要数据
• [ ] 不稳定（flaky）测试已修复或移除

瘦身验证

• [ ] 每批删除后运行测试确认无误删
• [ ] 所有"建议丢弃"项已与用户确认
• [ ] 所有"不确定"项已与用户确认
• [ ] 瘦身后项目仍可正常构建和运行

---

文件 & 结构

需要删除的文件

• [ ] 构建产物（dist/、build/、*.pyc、__pycache__/）
• [ ] IDE/编辑器文件（.idea/、.vscode/ 配置、*.swp）
• [ ] 系统文件（.DS_Store、Thumbs.db、desktop.ini）
• [ ] 日志文件（*.log、logs/）
• [ ] 临时文件（*.tmp、*.bak、*.orig）
• [ ] 用户不需要的输出/生成文件
• [ ] 测试输出/覆盖率报告
• [ ] 不需要分发的 Docker/VM 产物
• [ ] 个人笔记、TODO 列表、草稿文件

需要保留/创建的文件

• [ ] 根目录存在 LICENSE
• [ ] 根目录存在 README.md
• [ ] .gitignore 全面且正确
• [ ] 源代码在清晰的目录中（src/、lib/ 或语言约定）
• [ ] 测试在专用目录中（tests/、test/、__tests__/）
• [ ] 如适用，示例在 examples/ 中

结构质量

• [ ] 无空目录
• [ ] 无深度嵌套的单文件目录（尽可能扁平化）
• [ ] 关注点清晰分离（源码 / 测试 / 文档 / 配置）
• [ ] 入口点明确并有文档

---

代码质量

死代码

• [ ] 无未使用的导入
• [ ] 无不可达代码块
• [ ] 无注释掉的代码块（要么恢复要么删除）
• [ ] 无未使用的函数、类或变量
• [ ] 无遗留的调试代码（print("DEBUG")、console.log("test")）
• [ ] 无什么都不做的占位/桩函数

代码标准

• [ ] 全项目命名约定一致
• [ ] 代码格式一致（理想情况下由格式化工具配置强制执行）
• [ ] 函数/方法长度合理
• [ ] 错误处理充分（不用裸 except: 或吞掉错误）
• [ ] 无未解释的硬编码魔法数字
• [ ] 公共 API 有类型注解（对于类型化语言）

注释 & 文档

• [ ] 无应该已解决的 TODO/FIXME/HACK/XXX 注释
• [ ] 无误导性或过时的注释
• [ ] 复杂逻辑有解释性注释
• [ ] 公共函数有文档字符串（对于支持的语言）

---

依赖

• [ ] 清单中无未使用的依赖
• [ ] 无严重过时的固定版本（安全风险）
• [ ] 版本约束合理（不过松也不过紧）
• [ ] 锁文件最新且与清单一致
• [ ] 无内部/私有包注册表引用
• [ ] 无对私有/内部包的依赖
• [ ] 开发依赖与生产依赖正确分离
• [ ] 无未记录的系统特定依赖

---

文档

README

• [ ] 项目名称和一句话描述
• [ ] 解决什么问题 / 为什么存在
• [ ] 安装说明（可直接复制粘贴）
• [ ] 快速开始 / 最简使用示例
• [ ] 许可证引用
• [ ] 更多文档的链接（如有）

补充文档（L2+）

• [ ] CONTRIBUTING.md 说明如何贡献
• [ ] CHANGELOG.md 至少有一条记录
• [ ] 文档中的所有代码示例确实可用
• [ ] 文档中的所有链接有效（无断链）
• [ ] 无未解释的内部术语

API 文档（L3，如适用）

• [ ] 公共 API 有文档
• [ ] 常见用例有示例
• [ ] 参数类型和返回类型有文档

---

Git & CI

.gitignore

• [ ] 语言特定的忽略（例如 Python 的 __pycache__/）
• [ ] IDE/编辑器文件已忽略
• [ ] 系统特定文件已忽略
• [ ] 构建输出已忽略
• [ ] 环境/秘密文件已忽略
• [ ] 日志文件已忽略

CI/CD（L2+）

• [ ] CI 配置存在且语法有效
• [ ] CI 中运行测试
• [ ] CI 中运行 Lint
• [ ] CI 在向 main 分支的 PR 上运行
• [ ] CI 矩阵覆盖支持的版本

仓库设置（推送后）

• [ ] 默认分支为 main
• [ ] main 分支有分支保护（可选但推荐）
• [ ] 设置了话题/标签以便发现
• [ ] 填写了描述

---

最终验证

构建 & 运行

• [ ] 项目可在全新环境中从零安装
• [ ] 所有测试通过
• [ ] 主入口点运行无错误
• [ ] 示例代码按文档工作

敏感信息二次扫描

• [ ] 最终的秘密模式 grep 扫描结果干净
• [ ] 无内部路径残留
• [ ] 无私有 IP 或内部主机名残留

完整性

• [ ] .process.json 中所有计划项已完成或有意跳过
• [ ] .checklist.json 中所有检查项已验证
• [ ] 用户已审查并批准最终状态

深度瘦身扫描指南

目标：只保留开源核心，一切不需要的都砍掉。花足够的时间逐个扫描，不要走马观花。

---

1. 文件级扫描

逐个目录、逐个文件审查，标记为以下分类：

重点关注

• 内部工具/脚本：仅用于内部流程的脚本（部署、内部 CI、数据迁移等）
• 实验性/草稿代码：未完成的功能、poc 目录、scratch 文件
• 示例输出：output/、result/、generated/ 等输出目录
• 重复文件：同一功能的多个版本（例如旧版、备份目录）
• 过大的数据文件：测试数据集、样本文件、数据库 dump
• 文档草稿：内部 TODO、研究笔记、会议记录
• Docker/部署产物：仅用于内部部署的配置

---

2. 代码逻辑级扫描

深入到代码内部，寻找应该清理的逻辑：

• 未使用的模块/类/函数：通过引用分析找到从未被调用的代码
• 内部专用逻辑：只为内部系统服务的代码路径（内部 API 对接、内部认证）
• 冗余实现：同一功能的多种实现（历史遗留）
• 过度封装：只被调用一次的工具函数/类，可以内联
• 注释掉的大段代码：超过 5 行的注释代码块
• 废弃的功能开关：feature flag 对应的代码已不再需要
• 硬编码的内部业务逻辑：与内部系统强耦合的代码

---

3. 测试用例扫描

• 冗余测试：测试同一功能的重复用例
• 过时测试：测试已删除/重构的功能
• 内部集成测试：依赖内部服务/环境的测试
• 测试辅助文件：仅测试使用但体积过大的 fixture、mock 数据
• flaky 测试：不稳定的测试，时过时不过

---

4. 瘦身报告模板

扫描完成后，向用户呈现：

┌─────────────────────────────────────────────┐
│ 📦 深度瘦身扫描报告                          │
├─────────────────────────────────────────────┤
│                                             │
│ 📁 文件统计：                                │
│   总文件数：{total}                          │
│   核心保留：{keep} ({keep_pct}%)             │
│   建议删除：{delete} ({del_pct}%)            │
│   待确认：  {uncertain} ({unc_pct}%)         │
│                                             │
│ 🔴 明确丢弃（无需确认）：                     │
│   - logs/（日志目录，{n} 个文件）             │
│   - __pycache__/（缓存）                     │
│   - ...                                     │
│                                             │
│ 🟡 建议丢弃（请确认）：                       │
│   - scripts/internal_deploy.sh              │
│     → 理由：内部部署脚本，开源用户不需要       │
│   - src/legacy/old_parser.py                │
│     → 理由：已被 new_parser.py 替代          │
│   - tests/test_internal_api.py              │
│     → 理由：测试内部 API，开源后无意义        │
│                                             │
│ 🟠 不确定（需要您判断）：                      │
│   - utils/data_migration.py                 │
│     → 问题：不确定是否还在使用               │
│                                             │
│ 🧹 代码逻辑清理建议：                         │
│   - src/auth.py: internal_sso_login()        │
│     从未被外部调用，建议移除                  │
│   - src/core.py L45-L82: 注释掉的旧实现      │
│                                             │
│ 🧪 测试清理建议：                             │
│   - tests/test_old_feature.py: 测试已删除功能 │
│   - tests/test_integration.py: 依赖内部服务   │
└─────────────────────────────────────────────┘

⏸️ 等待用户逐条确认「建议丢弃」和「不确定」项后再执行。

---

5. 瘦身执行清单

执行时分三层：

5.1 文件级瘦身

• 删除用户确认丢弃的所有文件和目录
• 删除明确丢弃类（日志、缓存、构建产物、临时文件）
• 删除内部工具脚本、实验性代码、草稿文件
• 删除过大的非必要数据文件
• 删除重复文件（保留最新/最佳版本）
• 更新 .gitignore
• 注意：不要删除被 .gitignore 保护的工作文件

5.2 代码逻辑瘦身

• 移除用户确认的内部专用代码路径
• 移除未被引用的模块/类/函数
• 内联只被调用一次的冗余封装
• 清理废弃的功能开关及其关联代码
• 移除与内部系统强耦合的代码（或替换为可配置接口）

5.3 测试瘦身

• 删除测试已移除功能的过时测试
• 删除依赖内部服务/环境的集成测试
• 合并/精简重复测试用例
• 清理过大的测试 fixture（替换为最小必要数据）
• 保留所有核心功能测试

⚠️ 每删除一批文件后，立即运行测试确认没有误删。

开源项目标准

开源项目结构、README 格式和文档的标准与模板，按语言生态系统分类。

目录

• 通用结构
• README 模板
• 各语言约定
• GitHub 社区文件
• CI/CD 模板

---

通用结构

每个开源项目的根目录应包含以下内容：

project-root/
├── LICENSE                  # 必须 — 开源许可证
├── README.md                # 必须 — 项目概览和使用说明
├── .gitignore               # 必须 — 忽略生成/敏感文件
├── CONTRIBUTING.md          # L2+ — 如何贡献
├── CHANGELOG.md             # L2+ — 版本历史
├── CODE_OF_CONDUCT.md       # L2+ — 社区行为准则
├── SECURITY.md              # L3 — 漏洞上报
├── .github/                 # GitHub 专用
│   ├── workflows/           # CI/CD
│   ├── ISSUE_TEMPLATE/      # Issue 模板
│   └── PULL_REQUEST_TEMPLATE.md
├── src/ 或 lib/             # 源代码
├── tests/                   # 测试套件
├── docs/                    # 文档（L3）
└── examples/                # 使用示例（L3）

---

README 模板

L1 — 基础 README

# 项目名称

一句话描述这个项目做什么。

## 安装

​```bash
pip install project-name  # 或相应的安装命令
​```

## 快速开始

​```python
# 最简使用示例
​```

## 许可证

MIT 许可证 — 详见 [LICENSE](LICENSE)。

L2 — 标准 README

# 项目名称

一句话描述。

> 可选：更详细的段落，说明这个项目解决什么问题。

## 功能特性

- 特性 1
- 特性 2
- 特性 3

## 安装

### 前置条件
- Python 3.11+（或相应要求）

### 安装
​```bash
pip install project-name
​```

### 从源码安装
​```bash
git clone https://github.com/user/project.git
cd project
pip install -e .
​```

## 快速开始

​```python
# 完整的可运行示例
​```

## 使用说明

### 基本用法
...

### 高级用法
...

## 配置

描述配置选项。

## 开发

​```bash
git clone https://github.com/user/project.git
cd project
pip install -e ".[dev]"
pytest
​```

## 贡献

参见 [CONTRIBUTING.md](CONTRIBUTING.md)。

## 许可证

MIT — 详见 [LICENSE](LICENSE)。

L3 — 专业 README

包含 L2 的所有内容，加上：

<!-- 徽章行 -->
[![CI](https://github.com/user/project/actions/workflows/ci.yml/badge.svg)](...)
[![PyPI](https://img.shields.io/pypi/v/project-name)](...)
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](...)
[![codecov](https://codecov.io/gh/user/project/branch/main/graph/badge.svg)](...)

# 项目名称

...

## 文档

完整文档请访问 [文档站点或 docs/ 文件夹链接]。

## 架构

简要架构概览或链接到 docs/architecture.md。

## 路线图

- [ ] 计划中的功能 1
- [ ] 计划中的功能 2

## 致谢

感谢依赖项、灵感来源、贡献者。

---

各语言约定

Python

project-root/
├── pyproject.toml           # 项目元数据 + 依赖（优于 setup.py）
├── src/
│   └── package_name/
│       ├── __init__.py
│       ├── core.py
│       └── ...
├── tests/
│   ├── __init__.py
│   ├── test_core.py
│   └── ...
├── docs/
├── examples/
├── .python-version          # 可选
└── uv.lock / requirements.txt

关键约定：

• 使用 src/ 布局防止导入混淆
• 包名使用下划线，项目名使用连字符
• pyproject.toml 是标准（PEP 621）
• 对于有类型的包，包含 py.typed 标记

Node.js / TypeScript

project-root/
├── package.json
├── tsconfig.json             # 如果是 TypeScript
├── src/
│   └── index.ts
├── dist/                     # 构建输出（gitignored）
├── tests/ 或 __tests__/
├── .npmignore 或 package.json 中的 files 字段
└── node_modules/             # Gitignored

Rust

project-root/
├── Cargo.toml
├── Cargo.lock                # 二进制文件包含，库则 gitignore
├── src/
│   ├── lib.rs 或 main.rs
│   └── ...
├── tests/
├── benches/
└── examples/

Go

project-root/
├── go.mod
├── go.sum
├── cmd/                      # 入口点
│   └── app-name/
│       └── main.go
├── internal/                 # 私有包
├── pkg/                      # 公共包
└── *_test.go                 # 测试与源码同目录

---

GitHub 社区文件

CONTRIBUTING.md 模板

# 为 项目名称 做贡献

感谢您对贡献的兴趣！

## 开发环境设置

1. Fork 本仓库
2. 克隆你的 Fork
3. 安装依赖：`...`
4. 创建分支：`git checkout -b feature/your-feature`

## 修改代码

- 为新功能编写测试
- 遵循现有代码风格
- 保持提交集中且原子化

## 提交修改

1. 推送到你的 Fork
2. 创建 Pull Request
3. 描述你做了什么以及为什么
4. 关联相关 Issue

## 报告 Bug

创建一个 Issue，包含：
- 复现步骤
- 预期行为
- 实际行为
- 环境信息

## 行为准则

本项目遵循 [贡献者公约](CODE_OF_CONDUCT.md)。

Issue 模板

创建 .github/ISSUE_TEMPLATE/bug_report.md：

---
name: Bug 报告
about: 报告一个 Bug
labels: bug
---

**描述 Bug**
清晰描述 Bug 的情况。

**复现步骤**
复现步骤：
1. ...

**预期行为**
应该发生什么。

**环境信息**
- 操作系统：
- 版本：

创建 .github/ISSUE_TEMPLATE/feature_request.md：

---
name: 功能请求
about: 建议一个新功能
labels: enhancement
---

**问题描述**
这个功能解决什么问题？

**建议方案**
它应该如何工作？

**替代方案**
你考虑过的其他方法。

---

CI/CD 模板

Python（GitHub Actions）

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.11", "3.12", "3.13"]
    steps:
      - uses: actions/checkout@v4
      - name: 安装 uv
        uses: astral-sh/setup-uv@v4
      - name: 设置 Python ${{ matrix.python-version }}
        run: uv python install ${{ matrix.python-version }}
      - name: 安装依赖
        run: uv sync --all-extras --dev
      - name: Lint 检查
        run: uv run ruff check .
      - name: 类型检查
        run: uv run mypy src/
      - name: 运行测试
        run: uv run pytest tests/ -v --tb=short

Node.js（GitHub Actions）

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm run lint
      - run: npm test

Rust（GitHub Actions）

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@stable
      - run: cargo fmt --check
      - run: cargo clippy -- -D warnings
      - run: cargo test

敏感信息扫描模式

全面的秘密、凭证和内部引用检测模式。 在 Phase 1.3 分析阶段使用 grep -rniE 配合这些模式进行扫描。

目录

• API 密钥 & 令牌
• 密码 & 凭证
• 连接字符串
• 内部 URL & IP
• 硬编码路径
• 证书 & 密钥
• 云服务商密钥
• 敏感文件

---

API 密钥 & 令牌

变量名模式

(api[_-]?key|api[_-]?secret|access[_-]?token|auth[_-]?token|bearer|secret[_-]?key|private[_-]?key|client[_-]?secret)\s*[=:]\s*['\"][^'\"]{8,}

高熵字符串检测

查找包含混合大小写、数字和符号的 20+ 字符的字符串赋值：

[=:]\s*['\"][A-Za-z0-9+/=_-]{20,}['\"]

常见令牌前缀

(sk-[a-zA-Z0-9]{20,}|ghp_[a-zA-Z0-9]{36}|gho_[a-zA-Z0-9]{36}|github_pat_[a-zA-Z0-9_]{22,}|xox[bposa]-[a-zA-Z0-9-]{10,}|ya29\.[a-zA-Z0-9_-]{50,})

密码 & 凭证

(password|passwd|pwd|pass)\s*[=:]\s*['\"][^'\"]{3,}
(DB_PASSWORD|DATABASE_PASSWORD|MYSQL_PASSWORD|POSTGRES_PASSWORD|REDIS_PASSWORD)\s*[=:]

连接字符串

(mongodb(\+srv)?://|postgres(ql)?://|mysql://|redis://|amqp://|smtp://)[^\s'\"]+
(jdbc:|odbc:)[^\s'\"]+

内部 URL & IP

https?://(localhost|127\.0\.0\.1|0\.0\.0\.0|10\.\d+\.\d+\.\d+|172\.(1[6-9]|2\d|3[01])\.\d+\.\d+|192\.168\.\d+\.\d+)[:/]
https?://[a-z0-9-]+\.(internal|local|corp|intra|dev|staging)\b

硬编码路径

(/home/[a-z][a-z0-9_-]+/|/Users/[A-Za-z][A-Za-z0-9 _-]+/|C:\\Users\\[A-Za-z])

证书 & 密钥

需标记的文件扩展名

\.(pem|key|p12|pfx|jks|keystore|cer|crt|der)$

源码中的 PEM 内容

-----BEGIN (RSA |EC |DSA |OPENSSH )?PRIVATE KEY-----
-----BEGIN CERTIFICATE-----

云服务商密钥

AWS

(AKIA[0-9A-Z]{16})
(aws_access_key_id|aws_secret_access_key)\s*[=:]

Azure

(AccountKey|SharedAccessKey)=[a-zA-Z0-9+/=]{40,}

GCP

"type"\s*:\s*"service_account"

敏感文件

几乎可以确定包含秘密的文件 —— 标记为需要立即审查：

.env
.env.local
.env.production
.env.*.local
*.pem
*.key
*.p12
id_rsa*
id_ed25519*
.htpasswd
credentials.json
service-account*.json
secrets.yaml
secrets.yml
vault.yml

⚠️ .gitignore 保护判断：

• 如果上述文件已在 .gitignore 中 → 标注"已保护，无需删除"
• 如果不在 .gitignore 中 → 标注"高优先级 - 需要处理"

扫描命令

一键运行所有关键模式检查的快捷命令：

# 代码中的秘密
grep -rniE '(api[_-]?key|secret|token|password|passwd)\s*[=:]\s*['\''"][^'\''"]{8,}' --include='*.py' --include='*.js' --include='*.ts' --include='*.go' --include='*.java' --include='*.rb' --include='*.yaml' --include='*.yml' --include='*.json' --include='*.toml' --include='*.cfg' --include='*.ini' --include='*.conf' .

# 敏感文件
find . -name '.env' -o -name '.env.*' -o -name '*.pem' -o -name '*.key' -o -name 'id_rsa*' -o -name 'credentials.json' -o -name 'secrets.*' 2>/dev/null

# 内部路径
grep -rn '/home/\|/Users/\|C:\\Users' --include='*.py' --include='*.js' --include='*.ts' --include='*.yaml' --include='*.yml' --include='*.json' --include='*.toml' --include='*.md' .

# 私有 IP
grep -rniE '(10\.\d+\.\d+\.\d+|172\.(1[6-9]|2[0-9]|3[01])\.\d+\.\d+|192\.168\.\d+\.\d+)' --include='*.py' --include='*.js' --include='*.yaml' --include='*.yml' --include='*.json' --include='*.toml' .

误报指导

需要注意的常见误报情况：

• 开发配置文件中的 localhost（本来就是模板）
• Base64 编码的测试固定数据（不是真正的秘密）
• 示例/占位符值如 YOUR_API_KEY、changeme、xxx
• 描述如何配置凭证的文档
• 使用模拟凭证的测试文件

拿不准时，标记给用户审查，而不是忽略。

追踪文件模板

在 $TARGET_DIR/ 中创建的追踪文件模板。

---

.process.json

{
  "status": "in-progress",
  "project_name": "",
  "target_level": "L2",
  "started_at": "",
  "completed_at": null,
  "current_phase": 5,
  "current_step": "5.1",
  "total_steps": 0,
  "completed_steps": 0,
  "phases": [
    {
      "id": 5,
      "name": "执行重构",
      "status": "not-started",
      "steps": [
        {
          "id": "5.1",
          "action": "安全清理 - 清理硬编码密钥",
          "status": "not-started",
          "note": "",
          "files_affected": []
        }
      ]
    }
  ],
  "anti_drift_log": []
}

状态值

• "not-started" — 未开始
• "in-progress" — 进行中
• "completed" — 已完成
• "skipped" — 已跳过（必须附 note 说明原因）
• "blocked" — 阻塞

anti_drift_log 格式

{"timestamp": "...", "phase": 5, "step": "5.3", "on_track": true, "note": ""}

---

.checklist.json

{
  "status": "pending",
  "checked_at": null,
  "items": [
    {"category": "安全", "check": "代码中无 API 密钥或令牌", "passed": null},
    {"category": "安全", "check": "无硬编码内部 URL", "passed": null},
    {"category": "安全", "check": ".gitignore 覆盖所有敏感文件", "passed": null},
    {"category": "License", "check": "LICENSE 文件存在", "passed": null},
    {"category": "文档", "check": "README.md 完整且准确", "passed": null},
    {"category": "构建", "check": "项目可从干净克隆构建", "passed": null},
    {"category": "测试", "check": "测试套件通过", "passed": null},
    {"category": "测试", "check": "关键模块有测试覆盖", "passed": null},
    {"category": "瘦身", "check": "无内部专用代码残留", "passed": null},
    {"category": "瘦身", "check": "无冗余/过时文件残留", "passed": null},
    {"category": "瘦身", "check": "无冗余/过时测试用例", "passed": null},
    {"category": "gitignore", "check": ".gitignore 覆盖所有生成文件", "passed": null},
    {"category": "结构", "check": "无空目录", "passed": null},
    {"category": "依赖", "check": "无未使用的依赖", "passed": null},
    {"category": "CI", "check": "CI 配置有效", "passed": null}
  ]
}

检查项应根据目标级别和计划内容进行调整。

---

.plan.md 结构模板

````markdown

开源化重构计划

项目摘要

• 名称：...
• 类型：...
• 目标级别：L1/L2/L3

架构概览（Mermaid）

graph TD
    A[原始项目] --> B[复制到工作目录]
    B --> C[安全清理]
    C --> D[深度瘦身]
    D --> E[代码整理]
    E --> F[结构规范化]
    F --> G[文档生成]
    G --> H[CI/CD 配置]
    H --> I[测试补充 & 验证]
    I --> J[最终审查]

详细步骤

步骤 1: 安全清理

• [ ] 清理代码中的硬编码敏感信息
• [ ] 创建 .env.example（如适用）
• [ ] 确保 .gitignore 覆盖敏感文件

步骤 2: 深度瘦身

• [ ] 文件级瘦身：{待删除文件列表}
• [ ] 代码逻辑瘦身：{待清理逻辑列表}
• [ ] 测试瘦身：{待清理测试列表}

步骤 3: 代码整理

• [ ] 移除死代码
• [ ] ...

（... 所有步骤包含文件级细节 ...）

文件操作摘要

需要删除的文件

（列表 + 原因。被 .gitignore 保护的文件不在此列）

需要创建的文件

（列表 + 描述）

需要修改的文件

（列表 + 变更摘要）

风险评估

（可能出问题的地方）

测试验证计划

（重构完成后如何验证一切正常） ````