Project Showcase Enhancer

个人项目展示增强器 (Project Showcase Enhancer)

模型要求

本技能依赖高推理能力的大模型。 在开始任何分析前，向用户确认当前使用模型，并明确告知：

• 推荐模型：Claude Opus 4.6 / DeepSeek v4 Pro / GPT 5.6 或同等级别的高推理模型
• 低推理模型可能导致：代码理解肤浅、商用推演模板化、面试题预测质量差
• 如果当前模型不满足要求，建议用户切换后再使用

核心理念

采用 硬编码字典快速扫描 + LLM 深度语义理解 的混合架构，而非单纯依赖其中一种：

1. 快速扫描层（脚本）：scripts/scan_project.js 用硬编码字典在秒级完成目录遍历、技术栈识别、依赖提取，输出结构化 JSON——确定性高、速度快、不消耗 token
2. 深度理解层（LLM）：基于扫描 JSON + 实际阅读关键源文件，进行语义级的架构分析、代码质量评估、业务逻辑梳理——只有 LLM 能做的事
3. 推演共创（对话）：与用户多轮对话，将 Demo 推演为商用级产品方案
4. 包装输出（模板）：基于 assets/ 下的模板生成项目展示文档 + 面试备考手册

---

内置资源

---

工作流程

阶段 0：项目定位（入口）

首次触发时，向用户确认以下信息（一次性问完，不要逐个问）：

1. 项目路径：要分析的项目代码在哪个目录？
2. 使用场景：用于个人简历 / 面试 / GitHub 展示 / 作品集网站？
3. 目标岗位方向（可选）：前端 / 后端 / 全栈 / 产品 / 架构等——用于面试题预测的针对性
4. 特别说明（可选）：用户对这个项目的原始想法、希望突出的点

如果用户提供了简历文件，运行 scripts/parse_file.py 将 PDF/DOCX 转为纯文本，供阶段 3 面试准备使用。

---

阶段 1：深度代码理解

1.1 快速扫描（脚本层）

首先运行扫描脚本获取结构化数据：

node scripts/scan_project.js <项目目录>

该脚本输出 JSON，包含：

• techStack：按 runtime/framework/build/css/test/orm/deploy 分类的技术栈清单
• dependencies：完整依赖列表（从 package.json 等提取）
• directoryStructure：全目录树（含职责标注）
• entryFiles：检测到的入口文件
• configFiles：配置文件清单
• readmeContent：README 原文（最多 5000 字符）
• packageJson：项目元信息
• fileStats：文件统计

1.2 深度阅读（LLM 层）

基于扫描 JSON，LLM 应完成以下分析：

• 技术栈深度分析：扫描 JSON 给出了依赖列表，LLM 需要分析每个关键依赖的用途、版本是否合理、是否有替代方案
• 目录与模块理解：扫描 JSON 给出了目录树 + 职责标注，LLM 应阅读关键目录下的核心文件，理解模块划分和数据流
• 入口文件解读：阅读入口文件，理解启动流程、路由结构、中间件链
• 配置文件分析：阅读 .env / application.yml 等，理解部署环境、第三方服务依赖
• README 意图提取：从 README 中提取用户的原始产品意图

1.3 代码质量评估

对以下维度给出客观评分（1-10）和具体说明：

每个评分附带具体证据（文件名 + 行号或具体现象）。

1.4 现状总结

用一段话描述项目的当前状态，向用户展示并确认后进入阶段 2。

---

阶段 2：商用推演对话

2.1 理解用户愿景

通过对话了解（一次问 2-3 个问题）：

• 目标用户：谁会使用？规模多大？
• 核心卖点：差异化优势是什么？
• 商业模式（可选）：如何变现？
• 上线紧迫度：计划多久上线？MVP 范围是什么？

2.2 差距分析

基于阶段 1 的代码画像 + 阶段 2.1 的愿景，列出 Demo → 商用的差距：

【功能差距】
- 缺失：{功能点} — {优先级：P0/P1/P2} — {说明}

【工程化差距】
- 缺失：{工程实践} — {为什么需要} — {建议方案}

【运维差距】
- 缺失：{运维能力} — {为什么需要} — {建议方案}

2.3 演进路线图

第一阶段（MVP）  — {目标}
  1. {关键任务}
  2. {关键任务}

第二阶段（完善）  — {目标}
  1. {关键任务}
  2. {关键任务}

第三阶段（商用）  — {目标}
  1. {关键任务}
  2. {关键任务}

2.4 确认

向用户展示完整差距分析 + 路线图，确认后进入阶段 3。

---

阶段 3：生成交付物

3.1 项目展示文档

读取 assets/showcase-template.md，基于阶段 1 和阶段 2 的分析填充模板。

填充要求：

• 核心亮点：从技术深度、架构设计、产品思维等角度提炼 5 个亮点，每个亮点有具体证据支撑
• 功能模块：按业务领域组织
• 技术栈：完整选型表，每项说明选型理由
• 架构设计：整体架构 + 数据流 + 核心设计决策
• 演进记录：从 Demo 到商用的变化
• 部署说明：可执行的部署步骤

输出位置：{项目名称}-展示文档.md

3.2 面试备考手册

读取 assets/interview-prep-template.md，基于项目理解 + 岗位方向生成。

15 道面试题规则：

1. 必问题（5 题）：做项目的候选人必然被问到（介绍项目、负责部分、最大挑战、技术选型理由、重来会改什么）
2. 针对性题（5 题）：针对项目的技术决策、架构设计、代码薄弱点——每题关联阶段 1.3 的低分维度或阶段 2.2 的差距项
3. 追问题（5 题）：针对技术亮点深挖——每题关联具体代码文件或设计决策

每道题结构：题目 → 考察点 → 答题策略 → STAR 框架

输出位置：{项目名称}-面试备考手册.md

3.3 最终确认

两份文档生成后，向用户展示摘要，确认内容准确性和输出格式。

---

触发短语参考

• "分析/看看/梳理/帮我看下我的项目"
• "帮我包装/展示/介绍个人项目"
• "这个项目怎么推演/演进到商用"
• "生成/写一份项目展示文档/说明书"
• "项目亮点怎么提炼/怎么写"
• "从面试角度/面试官视角审视这个项目"
• "准备项目相关的面试/面试题"
• "我的作品集项目怎么展示"

---

重要约束

1. 脚本优先：阶段 1 必须先运行 scan_project.js 获取结构化数据，再进行 LLM 深度分析
2. 不跳过对话：每个阶段向用户确认后进入下一阶段
3. 不明知故问：用户已提供的信息不重复提问
4. 用代码说话：阶段 1 分析必须引用具体文件名、函数名、代码片段
5. 亮点不虚构：展示文档中的亮点必须有代码或架构层面的依据
6. 面试题有针对性：每道面试题必须关联项目中的具体代码/设计