目标
希望可以获取到当前历史项目的核心基本信息，协助 ai 更好的理解项目，进行编码。
比如项目的核心作用、技术选型、目录结构、编程风格、等等。
给出对应的提示词，可以获取到一个项目的上述核心基本信息，你可以适当扩展，让其更加丰富实用。
提示词
下面给你一份“项目核心信息采集 · 项目理解阶段专用 Prompt（适用于历史项目 / 存量项目）”。
它的定位非常明确：不是写代码，而是强制 AI 先“读懂项目”，形成一份结构化的“项目画像（Project Profile）”，供后续编码、评审、重构、排错使用。
这份提示词可以：
- 作为 gemini-cli / LLM 的第一步固定指令
- 作为 CI / Agent Workflow 中的「理解阶段」
- 生成一个
PROJECT_PROFILE.md或PROJECT_CONTEXT.md
一、使用方式（你可以这样用）
你可以直接对 LLM 说：
请严格按照以下提示词执行，不要直接生成代码
然后附上下面这段 Prompt。
二、项目核心信息采集 Prompt（推荐完整版）
你当前的首要任务不是编码，而是【理解项目】。
这是一个已经存在一段时间的历史项目，请你在不引入任何主观臆断、不做架构重构建议的前提下，
系统性地提取、归纳并输出该项目的【核心基本信息】，用于后续开发与维护。
你的输出目标是：生成一份【项目核心画像（Project Profile）】，输出到 PROJECT_PROFILE.md。
====================
一、阅读范围与顺序（强制）
====================
在分析前，你必须尽可能阅读以下内容（若存在）：
1. README.md / README_zh.md
2. 项目根目录结构
3. 核心模块的入口文件
4. 构建与依赖配置文件（如 pom.xml / package.json / build.gradle）
5. 代码中的注释、TODO、FIXME
6. 最近的变更记录（如 CHANGELOG、commit message）
如果信息缺失或无法判断，请明确标注「未知 / 无法从当前材料确认」。
====================
二、你需要输出的内容结构（必须完整）
====================
请严格按照以下结构输出，不要合并、不要求简化。
---
## 1. 项目整体概述（Project Overview）
- 项目的核心作用是什么？
- 它解决什么问题？
- 在系统/业务链路中处于什么位置？
- 项目更像是：
- 核心系统 / 支撑系统 / 工具型系统 / 平台型系统？
- 是否存在明确的上下游依赖？
【注意】
- 只描述“它现在是什么”，不要描述“它应该是什么”
---
## 2. 技术选型与技术栈（Technology Stack）
请列出并分类说明：
### 2.1 主要技术栈
- 语言与版本
- 主框架与版本
- 构建工具
- 运行环境假设
### 2.2 关键依赖与中间件
- 数据存储（数据库 / KV / 文件）
- 消息 / 事件系统
- RPC / API 方式
- 第三方服务依赖
并尝试判断：
- 哪些是「核心依赖」
- 哪些是「历史遗留依赖」
---
## 3. 项目结构与模块划分（Structure & Modules）
请结合目录结构说明：
- 项目整体是：
- 单体 / 模块化单体 / 多模块 / 多服务？
- 主要目录或模块的职责是什么？
- 哪些模块是“业务核心”？
- 哪些模块更偏向基础设施或通用能力？
如果结构存在不一致或演进痕迹，请如实描述。
---
## 4. 编程模型与代码风格（Programming Model & Style）
请总结当前项目中**实际采用的**（而非理论最佳）：
- 分层方式（如 Controller / Service / Domain / DAO）
- 状态管理方式（如前端状态 / 后端事务）
- 异常处理风格
- 日志风格与规范
- 命名习惯
【重点】
- 描述“事实”，不要评价优劣
---
## 5. 核心设计约束与隐含规则（Implicit Constraints）
请尽可能识别：
- 明确存在但未写成文档的设计约束
- 代码中反复出现的“隐含规则”
- 例如：某类逻辑只能在某层出现
- 某些操作必须同步 / 必须幂等
- 明显不能随意改动的部分（高风险区）
如果无法确认，请说明依据不足。
---
## 6. 项目成熟度与演进阶段判断（Project Maturity）
基于客观迹象判断：
- 项目大致处于哪个阶段：
- 初创 / 稳定期 / 高负载期 / 维护期
- 是否存在明显技术债聚集区？
- 是否能看出多次人员/团队交接痕迹？
禁止给出“改进建议”，只做状态判断。
---
## 7. 风险点与不确定性清单（Risk & Unknowns）
请列出：
- 你在理解项目过程中遇到的主要不确定点
- 哪些信息如果缺失，会显著影响后续编码判断
- 哪些地方需要人类进一步确认
---
## 8. 总结：项目画像速览（One-Page Summary）
用不超过 10 条要点，总结该项目最重要的事实，例如：
- 它“最怕被怎么改”
- 它“最重要的稳定性来源”
- 它“最典型的工程风格”
====================
三、行为约束（非常重要）
====================
在本次任务中，你【禁止】：
- 给出任何重构建议
- 对技术选型进行价值判断
- 引入最佳实践对比
- 生成或修改任何代码
你的唯一目标是：**帮助后续 AI 或人类“正确理解这个项目”**。
如果某些信息无法确定，请明确说明“不确定”，而不是猜测。
三、这个 Prompt 的工程价值（为什么它很重要）
这份提示词本质上解决的是你之前反复提到的一个核心问题：
“计算机语言是确定的，人类语言是模糊的，如何最大化消除中间的信息损耗”
它的作用是：
- 把一个项目从「代码堆」 ➜ 压缩成一份结构化、可复用的“上下文快照”
-
让后续所有 AI 行为：
- 不再凭经验“脑补”
- 不再随意套模板
- 而是基于真实项目约束
四、强烈建议的进阶用法（非常适合你）
你可以把它产品化成一套固定流程：
-
Step 1：运行该 Prompt
- 产出：
PROJECT_PROFILE.md
- 产出：
-
Step 2：人工快速 Review + 修正
- 标注哪些是“AI 判断”，哪些是“事实”
-
Step 3：后续所有编码 Prompt
-
强制要求：
「你必须基于 PROJECT_PROFILE.md，而不是通用经验」
-
这一步，会显著降低你之前吐槽的：
- 发散
- 幻觉
- 自作聪明
- 不尊重项目现实
