Obsidian – Vibecoding

开始创建一个文件夹，开始落地此功能。方便后面多人协作 vibecoding开发。

# 已有代码仓库首次分析提示词

你现在需要分析一个已有代码仓库，并为后续开发建立可靠上下文。

## 工作范围

请先读取并分析仓库，当前阶段禁止修改、删除或创建项目文件。只有在完成分析并得到明确授权后，才可以修改代码。

请优先阅读：

- `AGENTS.md`、`CLAUDE.md`、`CONTRIBUTING.md` 等规则文件
- `README.md`
- `package.json`、`pom.xml`、`build.gradle`、`go.mod` 等构建文件
- 配置文件和环境变量说明
- 数据库迁移文件
- 主要源码目录
- 测试目录
- CI/CD 和部署配置

## 分析内容

请输出以下内容，并为关键结论注明依据文件路径。

### 1. 项目概况

- 项目名称
- 项目用途
- 解决的问题
- 主要使用者
- 当前成熟度和开发状态

### 2. 技术栈

说明以下内容：

- 编程语言
- 前端和后端框架
- 数据库、缓存、消息队列
- 构建工具和测试框架
- 部署方式
- 外部服务和第三方依赖

无法确认的内容标记为“未确认”，不要猜测。

### 3. 运行方式

根据仓库实际内容给出：

```bash
# 安装依赖
# 启动开发环境
# 构建项目
# 运行测试
# 运行代码检查
```

如果命令未经验证，请明确标记；不要编造命令。

### 4. 仓库结构

说明主要目录和文件的职责，重点包括：

- 项目入口
- 核心业务代码
- API、控制器或路由
- 数据访问层
- 配置目录
- 公共工具
- 测试目录
- 脚本和部署文件

### 5. 核心模块

对每个主要模块使用以下格式：

```markdown
## 模块名称

- 代码位置：
- 主要职责：
- 入口文件：
- 关键类或函数：
- 依赖的其他模块：
- 相关接口：
- 相关数据库表：
- 相关测试：
```

### 6. 数据和外部依赖

分析：

- 数据库连接和迁移方式
- 实体、表或数据模型
- 外部 API
- 文件存储
- 缓存和消息队列
- 身份认证与权限
- 环境变量

请识别敏感配置，但绝对不要输出真实密码、密钥、Token 或隐私数据。

### 7. 测试现状

说明：

- 已有测试类型和位置
- 测试命令
- 已覆盖的模块
- 明显缺少测试的部分
- 失败、跳过或不稳定的测试

可以运行安全的只读检查或测试命令，但不要修改项目文件。

### 8. 风险和问题

列出发现的问题。每项包含：

- 问题位置
- 问题表现
- 可能影响
- 建议处理方式
- 优先级：高 / 中 / 低

关注配置、安全、依赖、可维护性、测试、文档、启动流程、模块耦合、数据库和部署风险。

### 9. 推荐的第一个开发任务

根据仓库现状推荐一个小而明确的起步任务。

要求：

- 范围清晰
- 尽量涉及少量文件
- 可以独立验证
- 不要一次性重构整个项目
- 不要主动扩展需求

使用以下格式：

```markdown
# 推荐任务

## 任务名称

## 任务目标

## 需要修改的文件

## 不应修改的部分

## 实施步骤

1. ...
2. ...
3. ...

## 验收标准

- [ ] ...
- [ ] ...
- [ ] ...

## 验证命令

```bash
...
```
```

## 最终输出：Obsidian 项目笔记

最后生成一份可以直接复制到 Obsidian 的 Markdown：

```markdown
# 项目名称

## 项目用途

## 仓库位置

## 技术栈

## 启动方式

## 测试方式

## 目录结构

## 核心模块

## 数据库和外部依赖

## 当前状态

## 已知问题

## 推荐的下一步

## 相关文件

- `文件路径`
```

## 分析原则

- 先分析，后建议。
- 以实际代码、配置和命令为依据。
- 不要根据目录名称猜测功能。
- 不要修改项目文件。
- 不要输出真实密钥、密码、Token 或隐私数据。
- 不确定的内容必须标记为“不确定”或“未确认”。
- 关键结论注明文件路径。
- 输出具体、简洁、可执行。
- 不提出与当前项目无关的大规模重构。