现在很多人的 AI 编码流程大概是这样：先和 AI 讨论需求、拆实现方案，然后让 Codex、Claude Code、Cursor 或 Copilot 直接改本地代码。AI 改完后，如果项目能跑、页面看起来没问题，很多人就准备提交了。问题恰恰出在这里。

以前 review 代码，主要看逻辑对不对、命名清不清楚、有没有明显 bug。现在 AI 一次能改很多文件，而且改得很自然，很多风险不是“代码完全不能跑”，而是混在 diff 里，看起来没那么刺眼。

比如：代码能跑，但测试被删了；功能能过，但权限判断被弱化了；CI 还能跑，但 GitHub Actions 权限被放大了；配置文件看起来正常，但 secret 被写进了代码；甚至 AGENTS.md、CLAUDE.md、Cursor rules 这类文件被改了，后续 AI 的行为规则也跟着变了。

这些问题不一定马上炸，但很适合藏进一次普通提交里。所以我做了一个很小的工具：PatchBrake。

项目地址：https://github.com/RyanCoreAI/patchbrake

Demo 在线体验：https://raw.githubusercontent.com/RyanCoreAI/patchbrake/main/assets/demo.gif

1. PatchBrake 是什么？

PatchBrake 的定位很窄：AI 改完代码后，在提交前扫描这次 diff，看看有没有明显危险信号。

它不是 AI Reviewer，也不调用 LLM。它不会上传你的代码，不会接 SaaS，不会做 Web Dashboard，也不会替你判断业务逻辑。它做的事情更像是提交前的一脚刹车：在代码进入 commit 之前，先把一些高风险 diff 提醒出来。

我反而是故意把它做得很“笨”：只看 diff、只跑本地规则、只报能解释清楚的风险。 因为很多 AI 编码带来的问题，并不需要另一个 AI 来推理，它们本来就是很直接的信号。

比如 staged diff 里出现：

+ permissions: write-all

或者测试被删掉：

- test("rejects anonymous users", () => {
-   expect(() => requireAdmin(null)).toThrow("Unauthorized");
- });

再或者配置里出现：

+ OPENAI_API_KEY="sk-..."

这些不是复杂安全研究问题，而是提交前就应该被提醒的问题。

2. 怎么安装和使用？

先说前提：需要已经安装 Node.js 20+。

npx 本身是 npm 附带的工具。也就是说，如果你的电脑里没有 Node.js / npm，通常也就没有 npx，这时直接运行下面的命令会失败：

npx patchbrake scan --staged

所以第一次使用前，可以先在终端里检查一下：

node --version
npm --version
npx --version

如果这三个命令不存在，先安装 Node.js 20+。安装完成后，一般会自带 node、npm 和 npx。

环境没问题后，就不需要手动安装 PatchBrake 了，直接用 npx 运行：

npx patchbrake scan --staged

如果你想全局安装，也可以：

npm install -g patchbrake
patchbrake scan --staged

实际使用流程很简单。AI 改完代码后，先把准备检查的改动放进 staged 区域：

git add <changed-files>

如果你确认这次所有改动都属于同一个任务，也可以：

git add .

然后运行：

npx patchbrake scan --staged

这里的 staged 不是让你必须立刻提交。它只是告诉 PatchBrake：请检查我准备提交的这批改动。

如果你用的是 Codex 桌面版，也一样。PatchBrake 不关心代码是 Codex 桌面版改的、Claude Code 改的，还是 Cursor 改的。只要最后文件落在本地 Git 仓库里，就可以在项目目录打开终端，先 git add，再运行：

npx patchbrake scan --staged

如果扫出 error，就先修掉，再重新扫描；没有明显风险后，再正常提交。

3. 实际效果

我做了一个测试 diff：新增一个疑似 OpenAI API key、删除一个测试文件、把 GitHub Actions 权限改成 write-all。PatchBrake 扫出来是这样：

这个输出里可以看到三类风险：

• secret-leak：新增了疑似 API key，并且输出里已经脱敏
• deleted-tests：测试文件被删除
• workflow-permissions：GitHub Actions 权限被放大到 write-all

这就是我想要的效果：它不需要理解整个业务，只要能在提交前把这些明显风险拦一下，就已经很有价值。

4. 为什么只扫 diff？

因为 AI 编码真正容易出问题的地方，经常不是“整个仓库历史上有没有漏洞”，而是：这一次 AI 到底改了什么。

你让 AI 重构认证模块，它可能顺手删掉一个断言；你让 AI 改 release workflow，它可能把权限放大；你让 AI 补配置，它可能把 token 写进文件；你让 AI 整理项目规则，它可能改掉 agent 的约束。

这些变化如果进了主分支，后面再查就麻烦了。所以 PatchBrake 的位置很靠前：在 commit 前，多做一次本地 diff 质检。

5. 现在能检查什么？

目前 PatchBrake 主要覆盖这些风险：

• secret-leak：新增 API key、token、private key、.env 风险
• deleted-tests：测试文件、测试用例或断言被删除
• workflow-permissions：GitHub Actions 权限被放大
• migration-risk：危险 migration，比如 DROP、TRUNCATE、无 WHERE 的 DELETE
• prompt-config-drift：AGENTS.md、CLAUDE.md、.cursor/rules、prompt 配置变化
• beta 规则：auth guard 删除、危险 npm script、危险 shell 命令、依赖风险等

它不追求覆盖所有漏洞。我更在意的是，先抓住 AI 改代码时最容易被忽略、但提交前最值得停一下的那几类问题。

6. 它和 Gitleaks / Semgrep / CodeQL 是什么关系？

PatchBrake 不是用来替代这些工具的。

Gitleaks、TruffleHog 更专注 secret scanning；Semgrep、CodeQL 更接近静态分析和 SAST；zizmor 对 GitHub Actions 安全检查更深入。PatchBrake 的目标更小：把 AI 生成代码中常见的 diff 风险，用一个本地 CLI 在提交前统一拦一下。

它更像是 AI coding workflow 前面的一道轻量 safety gate，而不是完整安全平台。

7. 现在还很早

PatchBrake 还是早期版本。我最想要的反馈不是泛泛夸奖，而是这三类：

• false positive：它误报了什么？
• real bad diff：你真的遇到过哪些 AI 生成的危险 diff？
• rule request：你希望它多检查什么？

如果你经常用 Codex、Claude Code、Cursor 或 Copilot 改代码，可以拿自己的项目跑一次：

npx patchbrake scan --staged

如果它帮你拦下过一次低级但严重的 diff 风险，欢迎给个 star，或者直接提 issue，把你的 bad diff case 留下来。

功能可以少，但路径必须清楚。功能多但路径乱，用户只会在页面里迷路。功能少但路径顺，用户至少能走到最后一步。

我设想过一个最典型的使用场景。

晚上 10 点 40，用户刷到一个后端开发实习 JD，投递截止写着今晚 12 点。

他手里有一份简历。问题不是这份简历完全不能用，而是他不知道它现在能不能投。要不要先改项目经历？技能栈够不够？JD 里的 Redis、部署经验、AI 应用经验有没有对应上？还是先导出再说？

如果这个时候，一个简历工具上来先让他在”AI 评分””JD 匹配””模板中心””版本管理”几个入口里自己找路，那它已经输了。

因为用户缺的不是一堆功能按钮，而是一条清楚的路径：

从打开工具，到拿到一份自己敢投出去的简历，中间到底应该走哪几步。

这篇文章讲的就是这条路径，以及我为什么把简喵 V1 的产品流程设计成现在这样。

一、上一篇压成了 10 步，这一篇把它展开

上一篇需求分析里，我把简喵 V1 的核心链路压成了 10 步：

进入简喵 → 创建或导入简历 → 填写基础信息 → AI 评分 → 查看诊断
→ 优化表达 → 粘贴 JD 匹配 → 生成建议 → 确认修改 → 导出 PDF

这一篇不重新发明流程，而是把这 10 步拆开。

每一步只回答四个问题：

用户看到什么？
系统在背后做什么？
AI 在什么时候介入？
这一步失败了，怎么办？

我设计这条流程时，心里有一个很简单的判断：

功能可以少，但路径必须清楚。

功能多但路径乱，用户只会在页面里迷路。功能少但路径顺，用户至少能走到最后一步。

简喵 V1 不应该一开始就做成一个大而全的求职平台。它的第一目标不是覆盖所有求职场景，而是让用户完成一件具体的事：

把一份普通简历改成一份可以投递的简历。

二、入口：为什么是三个，而且第一个不是”上传 PDF”

简喵 V1 的入口，我只保留三个：

手动创建简历。
GitHub 导入项目。
继续优化已有简历。

这三个入口对应三类用户。

手动创建，适合没有现成简历，或者想从头整理内容的人。
GitHub 导入，适合有项目仓库，但不会写项目经历的计算机学生。
继续优化，适合之前已经建过简历，现在想针对新岗位修改的人。

这里有一个我反复纠结过的取舍：

要不要把”上传 PDF / Word，自动解析简历”放在第一入口？

上传解析当然要做。它也是简喵最初设想过的入口之一。

但我不想把它当成 V1 唯一主入口。

原因很现实：简历 PDF 的格式太杂。有的有表格，有的有分栏，有的用了图标，有的文字顺序和视觉顺序对不上。强行解析，很容易出现字段错位、模块识别错误、内容丢失。

一旦用户看到自己的”教育经历”被塞进了”项目经历”，他对后面所有 AI 分析都会失去信任。

所以我的排序是：

V1 先把结构化编辑和 GitHub 导入做稳。
PDF / Word 解析可以作为辅助入口。
等核心链路跑通后，再逐步提高文件解析准确率。

这不是说解析不重要，而是它不应该在第一版里压过主线。

简喵第一版最重要的不是”用户能不能一键上传所有格式的简历”，而是”用户能不能稳定完成一次简历优化流程”。

三、GitHub 导入：它不是所有人的入口，但它是差异化入口

GitHub 导入不是所有用户都会用。

转码用户、非技术岗位用户、已经有工作经历的人，可能不需要这个入口。但对计算机学生来说，它很关键。

很多学生不是没项目，而是项目躺在 GitHub 里，简历上写不出来。

他可能做过课程项目、练手项目、小工具、博客系统、管理后台、爬虫脚本。但一写进简历，就只剩一句：

负责前后端开发。

这句话太空了。

所以 GitHub 导入要解决三个问题：

第一，找到用户的公开仓库。
第二，判断哪些仓库可能适合写进简历。
第三，把项目内容整理成简历项目经历。

一个合理的 GitHub 导入流程应该是：

输入 GitHub 用户名
  ↓
获取公开仓库列表
  ↓
读取仓库名称、简介、README、主要语言、更新时间
  ↓
筛选可能适合写进简历的项目
  ↓
用户手动勾选项目
  ↓
AI 生成项目经历初稿
  ↓
用户确认并修改

这里最关键的一点是：

不能让 AI 全自动决定哪些项目一定要写进简历。

因为 AI 不知道哪个仓库是课程作业，哪个是跟教程敲的 Demo，哪个是 fork 来的，哪个是用户真正投入较多的项目。

系统可以做推荐，但最终选择权必须交给用户。

比如系统可以提示：

这个仓库 README 较完整。
这个仓库最近有更新。
这个仓库主要语言和目标岗位相关。
这个仓库可能是 fork 项目，需要确认本人贡献。
这个仓库描述过短，建议手动补充项目功能和个人职责。

这样更安全。

AI 可以帮用户整理真实信息，但不能替用户认领经历。

这是我给 GitHub 导入划的红线。

四、结构化整理：所有”废话建议”都来自这一步没做好

不管用户是手动创建，还是从 GitHub 导入，进入 AI 分析之前，都要先做一件事：

把简历拆成明确的结构化模块。

比如：

{
  "projects": [
    {
      "name": "简喵 AI 简历优化系统",
      "techStack": ["Spring Boot", "Vue3", "MySQL", "Redis"],
      "description": [
        "负责简历编辑、AI 评分、JD 匹配等核心模块开发"
      ]
    }
  ],
  "skills": ["Java", "Spring Boot", "Vue3", "MySQL", "Redis"]
}

这一步看起来像技术细节，但其实是产品体验的基础。

如果系统不知道哪一段是项目经历，哪一段是技能栈，哪一段是教育经历，它就只能对整篇文本做泛泛分析。

于是用户会收到这种建议：

建议增强项目亮点。
建议补充量化数据。
建议优化表达方式。

这些建议看起来正确，但没有执行价值。

真正有用的建议应该是：

项目「简喵 AI 简历优化系统」第 2 条描述缺少量化结果，建议补充评分维度数量、接口数量、导出耗时或真实用户反馈等指标。

这两种建议的差别很大。

前者像废话。
后者能直接指导用户修改。

后者成立的前提，是系统知道这条建议对应的是哪个模块、哪个项目、哪一条描述。

所以结构化不是为了让数据看起来整齐，而是为了让 AI 建议能落到具体位置。

五、AI 评分：为什么不是只给一个总分

结构化整理完成后，用户最想知道的问题是：

我这份简历现在到底怎么样？

如果系统只给一个总分，比如：

你的简历得分：78 分。

这个结果其实没什么用。

用户不知道为什么是 78 分，也不知道怎么从 78 分改到 85 分。

所以简喵的评分不能只给总分，而要拆成多个维度。

拆成七个维度，用户才能看到自己具体弱在哪里。

有的人内容很完整，但表达很空。
有的人技术栈写了一长串，但项目经历没有展开。
有的人项目不错，但没有任何量化数据。
有的人简历看起来很丰富，但和目标岗位关系不强。
有的人简历写得很漂亮，但里面的技术点自己讲不清楚。

这些问题不是同一种病，不能用一个总分糊过去。

简历优化的目标也不是单纯把分数顶上去，而是让用户知道：

下一步应该改哪里。

六、JD 匹配：用户要的是行动清单，不是 AI 读后感

评分之后，流程会进入一个分岔：

不粘贴 JD → 做通用简历优化
粘贴 JD → 做岗位匹配分析

这两条路径都要保留。

因为不是所有用户一开始都有明确岗位。有的人只是想先把基础简历改好。

但对准备投递的人来说，JD 匹配才是更高价值的路径。

用户粘贴 JD 后，系统要做的不只是提取关键词，而是完成四件事：

第一，识别岗位类型。
比如后端开发、前端开发、AI 应用开发、测试开发等。

第二，提取核心技能。
比如 Spring Boot、MySQL、Redis、Vue3、TypeScript、Docker、RAG、Prompt 等。

第三，判断能力要求。
比如是否要求项目经验、部署经验、性能优化经验、团队协作经验、AI 应用落地经验。

第四，对比用户简历。
判断哪些已经覆盖，哪些表达不足，哪些完全缺失。

最后给用户看的，不应该是一大段话，而应该是一张行动表。

这种展示方式比一句”你的简历与岗位匹配度较高，但仍需补充部分技能描述”有用得多。

用户需要的是行动清单，不是 AI 读后感。

七、优化建议：必须具体到”哪一条该怎么改”

AI 评分和 JD 匹配之后，才进入真正的优化建议阶段。

这里我给自己定了一条铁律：

优化建议必须具体到位置。

不能只说：

项目经历表达不够专业。

这句话太泛了，用户不知道改哪里。

一条合格的建议，至少要包含四个部分：

问题是什么。
出现在什么位置。
为什么需要改。
可以怎么改。

例如：

问题：项目描述过于空泛
位置：项目经历 > 简喵 AI 简历优化系统 > 第 1 条
原因：只写"完成 AI 简历优化功能"，没有体现技术实现和业务价值
建议：改为"基于 Spring Boot 接入大模型 API，实现简历评分、项目经历润色
和 JD 匹配诊断；通过结构化 Prompt 约束输出格式，并对 AI 返回结果进行字段
校验和异常兜底"

这样的建议，用户才能判断它到底有没有用。

他能看出来：

这个问题是不是准确。
这个建议是不是符合真实经历。
这句话能不能直接用。
有没有需要自己降级或修改的地方。

简喵不能只做”AI 帮你改完”。

更合理的方式是：

AI 给出建议，用户确认后应用。

因为简历是用户自己的，最终责任也在用户自己身上。

八、Before / After：让用户看到”为什么变好了”

用户最关心的不是 AI 说了什么，而是改完到底有没有变好。

所以每条优化建议都应该提供 Before / After 对比。

这个对比很重要。

因为用户可以直观看到差距：

优化前太短。
优化前太泛。
优化前没有技术动作。
优化前没有业务场景。
优化前没有结果证明。
优化前没有岗位关键词。

优化后的目标不是把句子变长，而是补齐信息密度。

说清楚做了什么。
说清楚用了什么技术。
说清楚解决了什么问题。
说清楚结果或价值。
说清楚和岗位有什么关系。

这才是简喵真正要做的事情。

九、确认应用：AI 给方向，用户守底线

AI 生成建议后，不能直接覆盖用户原文。

每条建议应该给用户三个选择：

应用。
编辑后应用。
忽略。

其中”编辑后应用”最重要。

因为 AI 经常会出现一种情况：方向是对的，但措辞过了。

比如它可能建议用户写：

设计高并发缓存架构，显著提升系统吞吐能力。

但如果用户只是给一个课程项目加了 Redis 缓存，这句话就明显过头了。

更真实的写法应该是：

引入 Redis 缓存热点查询结果，减少重复数据库查询，为后续接口性能优化提供基础。

这就是用户确认的价值。

AI 不知道用户真实的参与程度。
AI 不能确认所有数据是否真实。
AI 不知道某个技术点用户到底能不能讲清楚。
AI 有时会把普通项目包装得过于高级。

所以简喵宁可多一步确认，也不能把用户推向过度包装。

简历可以优化，但不能虚构。
表达可以专业，但不能失真。

这条边界很重要。

如果一个 AI 简历工具只追求”看起来更强”，它很容易把用户送进面试风险里。面试官顺着简历一问，用户讲不清楚，反而更糟。

简喵要做的是帮助用户表达真实经历，而不是制造虚假能力。

十、再次评分：闭环比”一键生成”更重要

很多 AI 工具的问题是：给完建议就结束了。

但真实的简历修改从来不是一次完成的。

用户通常会经历这样的过程：

第一次评分
  ↓
发现项目经历太空
  ↓
应用几条建议
  ↓
再次评分
  ↓
发现 JD 匹配还不够
  ↓
补充岗位关键词
  ↓
再次评分
  ↓
调整表达和顺序
  ↓
导出 PDF

所以每次用户应用建议后，系统应该支持重新分析，并展示变化。

例如：

这里的数字只是示意，真正重要的是反馈机制。

没有反馈的修改，很容易变成反复纠结。
有反馈的修改，用户才知道刚才那次调整有没有用。

这也是简喵和普通简历工具的区别。

普通简历工具是静态编辑器。
简喵应该是带反馈的优化系统。

它的核心不是”一键生成完美简历”，而是陪用户一轮轮把简历改清楚。

十一、版本管理：不要让用户输给”最终最终版”

真实投递不是只投一个岗位。

同一个人可能同时投后端、前端、AI 应用开发、测试开发。不同岗位关注的重点不同，所以简历版本也应该不同。

如果没有版本管理，用户很快就会在文件夹里看到这种东西：

简历-最新版.pdf
简历-最终版.pdf
简历-最终最终版.pdf
简历-字节版.pdf
简历-字节修改版.pdf
简历-字节真的最终版.pdf

这不是用户不自律，而是投递场景本身就需要多版本。

所以针对某个岗位完成一轮优化后，系统应该保存一个版本。

版本命名可以来自三个信息：

公司名称。
岗位名称。
创建时间。

例如：

基础版简历
腾讯-后端开发实习-2026.05.21
字节-AI应用开发实习-2026.05.22
阿里-前端开发实习-2026.05.23

但 V1 的版本管理不需要做得很复杂。

第一版只要支持：

复制基础简历生成新版本。
针对某个 JD 保存优化版本。
查看不同版本的修改时间和目标岗位。
导出指定版本 PDF。

这就够了。

不要一开始就做复杂的版本对比、协同编辑、权限共享、访问统计。

那些功能有价值，但不是 V1 的核心。

十二、导出 PDF：流程最后必须落到”能投”

前面所有评分、匹配、优化、版本管理，最后都要落到一份能投递的 PDF 上。

这里我守两条原则。

第一，导出不卡付费弹窗。

这是简喵最初的动机之一。

用户花了半天编辑和优化简历，最后一步才告诉他”导出要付费”，这种体验我自己受够了。

工具可以有使用次数限制。
AI 功能可以有成本控制。
未来也可以思考更清晰的商业模式。

但不应该靠最后一步拦截导出来制造沉没成本。

第二，版式要稳定。

简历 PDF 不需要花哨，但必须清楚、整齐、稳定。

V1 不需要做几十套模板，两套就够：

简约专业版。
技术强化版。

简约专业版适合大多数普通岗位投递。
技术强化版适合技术项目比较多的用户，把项目经历和技术栈展示得更突出。

拖拽式自由排版看起来很强，但开发成本高，也容易让用户把注意力浪费在调样式上。

简喵的重点是内容优化，不是做一个简历版 Photoshop。

十三、异常路径：不能只设计理想情况

产品流程不能只设计理想路径。

真实用户一定会遇到各种问题。

GitHub 用户名输错。
仓库为空。
README 太少，AI 无法判断项目内容。
JD 太短，无法提取有效要求。
用户没有填写项目经历。
AI 返回结果格式异常。
网络中断，分析失败。
导出 PDF 时内容超出一页。

这些情况如果不处理，用户立刻会觉得产品”不靠谱”。

所以每个关键节点都要有异常兜底。

比如 GitHub 导入失败时，不应该只显示：

系统错误。

而应该告诉用户：

没有找到这个 GitHub 用户，请检查用户名是否正确。你也可以直接手动创建简历。

如果仓库 README 太少，可以提示：

该仓库 README 内容较少，AI 可能无法准确生成项目描述。建议你手动补充项目功能、技术栈和个人职责。

如果 JD 太短，可以提示：

当前岗位描述信息不足，可能影响匹配结果。建议粘贴完整 JD，包括岗位职责和任职要求。

如果 AI 分析失败，可以提示：

本次 AI 分析失败，你的简历内容已经保存，可以稍后重试。

异常提示的核心不是”报错”，而是告诉用户下一步怎么办。

用户不怕产品偶尔失败。
用户怕的是失败之后不知道该怎么继续。

十四、简喵 V1 的完整流程图

整理下来，简喵 V1 的完整流程可以这样表示：

进入简喵
  ↓
选择开始方式
  ├─ 手动创建简历
  ├─ GitHub 导入项目
  └─ 继续优化已有简历
  ↓
结构化整理简历内容
  ↓
AI 简历评分
  ↓
查看问题诊断
  ↓
是否粘贴目标 JD？
  ├─ 否：生成通用优化建议
  └─ 是：进行 JD 匹配分析
          ↓
      生成岗位化优化建议
  ↓
查看 Before / After 对比
  ↓
用户选择：应用 / 编辑后应用 / 忽略
  ↓
再次评分
  ↓
保存为新版本
  ↓
导出 PDF

这个流程的核心不是”AI 生成一份简历”。

而是：

用户提供真实经历，系统帮他发现问题、看清差距、优化表达，最后导出一份他自己愿意投出去的简历。

这句话才是简喵 V1 的产品主线。

十五、这篇文章真正想说明什么

产品流程不是把功能按顺序排起来。

它要回答的是：

用户第一步做什么？
每一步为什么存在？
系统在背后处理什么？
AI 的建议如何被用户理解？
用户遇到问题时怎么继续？
最后如何形成一份可投递的简历？

对简喵来说，产品流程的核心不是”上传简历，然后 AI 给建议”这么简单。

真正的流程应该是：

输入真实经历。
结构化整理。
发现简历问题。
对比目标岗位。
生成具体建议。
用户确认修改。
再次评分反馈。
保存岗位版本。
导出 PDF 投递。

这是一条带反馈的写作路径。

传统简历工具更像一次性编辑器：填完、排版、导出。

简喵想做的是迭代式优化工具：分析、修改、反馈、再修改，直到用户拿到一份自己愿意投出去的简历。

写在最后

如果说上一篇需求分析是在回答”简喵为什么做这些功能”，那这篇产品流程就是在回答”这些功能应该怎么串起来”。

功能孤立存在时，价值很有限。

AI 评分单独存在，只是一个分数。
JD 匹配单独存在，只是一份分析。
AI 润色单独存在，只是一段改写。
PDF 导出单独存在，只是一个工具按钮。

但当它们被串成一条完整路径时，产品价值才会出现：

输入真实经历 → 发现问题 → 岗位匹配 → 优化表达 → 用户确认 → 导出投递。

这才是简喵 V1 要优先打磨的主线。

用户提供真实经历。
系统帮他发现问题。
AI 给出可执行建议。
用户确认并应用。
系统再次反馈。
最后导出一份能投的 PDF。

流程确定之后，下一步不是继续加功能，而是反过来砍功能。

因为流程越清楚，越能看出哪些功能只是看起来有用，实际上会拖慢第一版。

下一篇，我会写简喵的 MVP 范围：哪些功能第一版必须做，哪些听起来合理但要先砍掉，以及我为什么这么取舍。

一个 AI 简历工具不应该从”我想做什么功能”开始，而应该从”用户到底卡在哪里”开始。

写完上一篇《为什么我要做简喵：一个被付费弹窗气出来的项目》之后，有人问我：

你做这个简历工具之前，到底有没有做过调研？还是拍脑袋就开始写代码？

这个问题很现实。

很多学生项目最大的问题，就是一上来先想技术栈：Spring Boot、Vue3、Redis、大模型、Docker、云服务器。看起来很完整，但仔细一问：用户是谁？为什么要用？现在不用你的工具会怎么解决？第一版必须解决哪个问题？

答不上来。

然后项目就会变成一个功能堆砌现场。首页很漂亮，按钮很多，模块很多，最后没人真的用。技术上很忙，产品上很空。

所以在正式做简喵之前，我先做了一轮轻量的需求分析。

说完全靠调研，是假的。说完全拍脑袋，也不准确。

调研的部分，是我和身边一些正在改简历、投实习、准备校招的同学聊了一圈。拍脑袋的部分，是我自己本来就是目标用户之一：普通 CS 本科生，有项目经历，但也会被简历表达、投递匹配、项目包装这些问题卡住。

这篇文章不是一份教科书式的用户调研报告。我不会假装自己做了几百份问卷，也不会堆一堆看起来很专业但没什么用的图表。

这篇文章只想回答一个问题：

简喵第一版到底应该做什么，又应该坚决不做什么？

一、需求分析不是列功能清单

很多人一想到需求分析，第一反应就是列功能。

用户登录。
简历上传。
AI 评分。
AI 润色。
PDF 导出。
JD 匹配。
面试题生成。
多版本管理。
分享链接。
投递追踪。
会员系统。
数据看板。

列完之后，看起来很丰富。

但这不叫需求分析，这叫愿望清单。

真正的需求分析不是问”我能做什么功能”，而是问：

用户现在为什么痛苦？
这个痛苦发生在什么场景？
用户目前怎么解决？
现有方案哪里不好？
如果第一版只做几个功能，哪几个最重要？
哪些功能听起来合理，但现在不该做？

简喵的需求分析也是围绕这些问题展开的。

我不想做一个”功能很多但没人用”的简历工具。第一版的目标只有一个：

让用户在最短路径里，把一份普通简历改得更清楚、更专业、更适合投递。

二、四类核心用户

如果只说”简喵面向大学生和求职者”，这个范围太大，最后做出来一定会失焦。

“大学生”不是一个足够具体的用户画像。

一个大一学生、一个大三找实习的计算机学生、一个跨专业转码的人、一个已经实习过准备秋招的人，他们的问题完全不一样。

所以我把简喵的核心用户拆成四类。

用户 A：有项目，但不会写的计算机学生

这是简喵最核心的用户。

比如一个大三计算机学生，GitHub 上有几个课程项目：图书管理系统、博客系统、待办应用、爬虫脚本。项目不一定多高级，但至少是真的做过。

问题是，一到简历里，他只会写：

负责前端页面开发和后端接口设计。

这句话不能说错，但几乎没有价值。

它没有说明用了什么技术，没有说明具体做了什么模块，没有说明解决了什么问题，也没有说明项目结果。面试官看到这句话，很难判断这个学生到底只是跟着教程敲了一遍，还是理解了项目里的关键设计。

同样一个项目，如果换一种表达，效果就完全不同：

基于 Vue3 和 Spring Boot 实现图书管理系统，负责用户登录、图书检索、借阅记录和后台管理等核心模块；使用 JWT 完成登录认证，基于 MySQL 设计用户表、图书表、借阅记录表等核心数据结构。

这段话并没有把项目吹成很高级的系统，但它至少说清楚了三件事：

第一，用了什么技术。
第二，做了哪些模块。
第三，具备哪些可迁移的开发能力。

这类用户的核心问题不是没有内容，而是不会把内容翻译成简历语言。

他们需要的不是模板，而是项目经历重写能力。

用户 B：有学习经历，但缺少求职化包装的转码用户

第二类用户是转码或跨专业求职的人。

比如一个金融、机械、自动化或其他专业的学生，自学了 Java、前端或 Python，刷了一些算法题，也做了几个项目。但他的简历经常有一个明显问题：学习痕迹很重，求职表达很弱。

常见写法是：

学习了 Spring Boot 框架，完成了一个电商项目。

问题在于，这种表达像学习笔记，不像项目经历。

企业不关心你”学习了什么”，更关心你”能用这些东西解决什么问题”。

同样是电商项目，如果只写”学习并使用 Spring Boot”，会显得很学生气；如果写清楚用户模块、商品模块、订单流程、权限认证、缓存设计、异常处理，可信度就会高很多。

这类用户的核心问题是：

他们有努力痕迹，但不会把学习经历转化成岗位能力证明。

他们需要的是求职化表达，而不是简单润色。

用户 C：有实习或工作经历，但没时间重写简历的人

第三类用户是已经有实习或工作经历的人。

这类人不一定不会写简历，甚至可能比学生更懂怎么表达。但他们的问题是：没时间、没精力、版本太乱。

比如一个前端实习生，去年简历写的是 Vue2 项目，今年主要做 Vue3 + TypeScript，但简历一直没更新。每次准备投递新岗位，都要重新打开旧简历、对照 JD、改项目描述、调整技能栈、导出 PDF。

不同岗位还要不同版本，最后文件夹里出现一堆类似这样的文件：

简历-最新版.pdf
简历-最新版2.pdf
简历-字节版.pdf
简历-腾讯修改版.pdf
简历-最终版.pdf
简历-最终最终版.pdf

看到”最终最终版”这几个字，就知道人类已经输给文件管理了。

这类用户的核心问题不是不会写，而是维护成本太高。

他们需要的是版本管理、JD 匹配和快速改写。

用户 D：面试前不知道怎么准备的人

第四类用户出现在简历投递之后。

很多人以为简历优化的终点是投出去。但实际上，简历上的每一句话都会变成面试里的潜在问题。

你写了 Redis，面试官可能问缓存穿透、缓存雪崩、缓存一致性。
你写了 JWT，面试官可能问 Token 续期、权限校验、Refresh Token。
你写了 Docker 部署，面试官可能问镜像构建、容器编排、日志查看。
你写了 AI 接入，面试官可能问 Prompt 设计、结构化输出、异常重试、成本控制。

很多人简历写得很漂亮，但面试时讲不清楚。

这比简历写得一般更危险。

因为面试官会觉得你不是不会写，而是在包装。简历上写的东西，如果自己讲不清楚，就会从加分项变成扣分项。

这类用户的核心问题是：

不知道自己的简历会被怎么追问。

他们需要的是基于简历内容生成面试题，而不是通用八股题库。

三、四个真实使用场景

有了用户画像，还不够。

因为同一个用户，在不同时间点打开简喵，需求是不一样的。产品不能只看”用户是谁”，还要看”他在什么时候、因为什么打开这个工具”。

我把简喵的核心使用场景分成四个。

场景一：投递前临时改简历

这是最高频、也最真实的场景。

晚上九点，用户在群里看到一个实习内推。岗位 JD 写着：

熟悉 Spring Boot、MySQL、Redis，有项目开发经验优先。

他打开自己的简历，发现项目经历写得很空：

使用 Spring Boot 完成图书管理系统。

他知道这样写不够，但又不知道怎么改。投递截止时间可能就在今晚，手动对照 JD 改简历太慢，找别人帮忙也来不及。

这个时候，他打开简喵，最想完成的动作是：

上传或填写简历。
粘贴目标岗位 JD。
系统指出简历和 JD 的差距。
AI 给出针对该岗位的优化建议。
用户确认后导出 PDF。

这个场景的关键词是：快、准、能投递。

用户不是来研究简历理论的，也不是来欣赏产品交互的。他就是要在短时间内知道：我这份简历哪里不匹配，应该怎么改。

所以 JD 匹配和一键优化，在 V1 里必须优先级很高。

场景二：GitHub 有项目，但简历写不出来

很多计算机学生最真实的情况是：代码仓库里有东西，简历里写不出来。

GitHub 里可能有好几个项目，但项目名称很普通，README 也很粗糙。用户自己回头看时，甚至不知道哪个项目值得放进简历。

这个场景下，简喵要解决三个问题。

第一，帮用户从 GitHub 仓库中筛选更适合写进简历的项目。
第二，提取 README、技术栈、提交记录等信息，理解项目大概做了什么。
第三，把项目内容转化成更适合简历的表达。

这里的重点不是”AI 编一个高级项目”，而是基于用户真实仓库做结构化整理。

如果用户只是做了一个普通图书管理系统，那就不能硬写成”高并发分布式图书智能中台”。那种写法短期看很唬人，面试时也会死得很有节奏。

简喵要做的是把真实项目写清楚，而不是把普通项目吹成宇宙飞船。

场景三：同一份简历要投不同岗位

很多用户只有一份万能简历。

投前端，用这份。
投后端，也用这份。
投 AI 应用开发，还是用这份。
投测试开发，稍微改几个词继续用。

这其实很危险。

不同岗位关注的重点不同。

前端岗位更关心组件化、工程化、性能优化、交互体验。
后端岗位更关心接口设计、数据库、缓存、权限、并发和系统稳定性。
AI 应用岗位更关心模型接入、Prompt、RAG、工具调用、成本控制和异常处理。

同一个项目，可以根据岗位强调不同内容。

比如一个 AI 简历项目：

投后端开发时，可以重点写接口设计、鉴权、限流、缓存、异步任务和部署。
投前端开发时，可以重点写编辑器交互、组件复用、状态管理和导出预览。
投 AI 应用开发时，可以重点写 Prompt 设计、结构化输出、AI 评分、JD 匹配和成本控制。

所以简喵需要支持多版本简历。

但注意，V1 不一定要做复杂的版本协作系统。第一版只要能做到”基于同一份简历生成不同岗位优化版本”，就已经能解决主要问题。

产品第一版最怕把简单需求做成复杂系统。明明只需要一个遮雨棚，最后开始研究穹顶结构，这种事在软件开发里每天都在发生。

场景四：面试前根据简历准备追问

简历优化之后，下一步就是面试准备。

很多用户会犯一个错误：只准备通用八股，不准备自己的简历。

但面试官最容易问的，恰恰是简历上的内容。因为这是你自己写上去的，默认你应该讲得清楚。

如果你写：

使用 Redis 缓存热点数据，提高接口响应速度。

那你至少要能回答：

为什么这个地方适合用缓存？
缓存 key 怎么设计？
数据更新后缓存怎么处理？
有没有考虑缓存穿透？
如果 Redis 挂了怎么办？
性能提升有没有具体数据？

如果这些答不上来，这句简历描述反而会变成风险。

所以简喵不应该只做”写简历”，还应该做”检查这份简历是否经得起追问”。

面试题生成功能就是为这个场景服务的。它不应该生成通用题库，而应该围绕用户简历中的项目、技术栈和具体表述生成追问。

这会让用户知道：哪些内容可以放心写，哪些内容写了但自己讲不清楚，需要补课。

四、四个核心痛点

用户和场景确定之后，简喵真正要解决的痛点就清楚了。

痛点一：项目经历写不具体

这是最常见的问题。

很多学生写项目经历时，停留在”我参与了什么””我负责了什么”，但没有写清楚”我具体做了什么”。

比如：

负责后端接口开发。

这句话太空。它没有告诉别人你设计了哪些接口，处理了哪些业务，使用了哪些技术方案，遇到了什么问题，最后实现了什么效果。

更好的写法应该是：

基于 Spring Boot 设计用户登录、简历管理、AI 评分等核心接口，使用 JWT 完成用户身份认证，并通过统一异常处理和参数校验提升接口稳定性。

这不是简单把句子变长，而是补齐了技术动作和业务场景。

简喵要解决的第一件事，就是帮用户把空泛表达改成具体表达。

痛点二：不会量化成果

第二个痛点是不会量化。

简历里经常出现这些句子：

提升了系统性能。
优化了用户体验。
提高了开发效率。
完成了项目核心功能。

这些句子看起来都没错，但说服力很弱。

因为它们没有数字，也没有判断标准。

更好的表达应该是：

将接口平均响应时间从 300ms 降至 120ms。
封装 15 个可复用组件，减少重复页面开发。
设计 8 张核心业务表，支撑用户、简历、评分记录等模块。
通过 Redis 缓存热点数据，降低重复查询压力。

当然，并不是所有学生项目一开始都有真实数据。很多课程项目没有用户量，也没有压测记录。

所以简喵不能直接替用户编数字。

正确做法应该分成两层。

如果用户提供了真实数据，AI 帮他放到合适的位置，组织成更有说服力的表达。

如果用户没有数据，AI 应该提示”建议补充可量化指标”，并告诉他可以补哪些指标，比如接口响应时间、页面数量、组件数量、数据表数量、功能模块数量、测试覆盖范围等。

这点很重要。

AI 简历工具最危险的地方，就是为了让简历好看而制造虚假信息。简喵要做的是提示用户补证据，而不是替用户编证据。

痛点三：不知道岗位关键词

第三个痛点是用户不知道不同岗位在看什么。

很多人投递时只看岗位名称，不会认真分析 JD。看到”后端开发实习生”，就把自己的通用简历扔过去。至于 JD 里到底强调 MySQL、Redis、微服务、消息队列、Linux、Docker 还是高并发，他没有认真拆。

这样投出去，简历就很容易和岗位要求错位。

简喵的 JD 匹配功能要解决这个问题。

它应该从岗位描述中提取几个信息：

岗位核心技能。
高频关键词。
加分项。
隐含能力要求。
简历中已经覆盖的内容。
简历中缺失或表达不足的内容。

比如 JD 要求：

熟悉 Spring Boot、MySQL、Redis，了解 Linux 部署，有 AI 应用开发经验优先。

而用户简历里只写了：

使用 Java 完成后端开发。

那系统就应该提示：

Spring Boot 没有明确出现。
MySQL 相关设计没有展开。
Redis 没有体现。
Linux / 部署经验没有体现。
AI 应用开发经验如果有，应该放到项目亮点中。

这样用户才知道该往哪里改。

简喵不是让用户迎合 JD 编经历，而是帮助用户把已有经历中和 JD 相关的部分提出来。

痛点四：表达太口语化

第四个痛点是表达不专业。

很多学生简历里的句子，像是在和同学聊天：

搞定了跨域问题。
写了很多页面。
做了登录功能。
用 Redis 做了缓存。
把项目部署到了服务器。

这些表达太口语，不适合简历。

不是因为它们不真实，而是因为它们没有形成专业表达。

可以改成：

简喵的 AI 润色不应该只是让句子变得”高级”，而应该让表达变得更准确。

这也是我不喜欢很多 AI 简历工具的原因：它们会把普通经历润色成一堆漂亮但空洞的词。看起来高级，实际没有信息量。AI 味重到像刚从提示词工厂流水线下来。

简喵要避免这种问题。

五、用户、场景、痛点和功能的对应关系

把前面的内容整理一下，简喵的核心逻辑其实很清楚。

这张表才是功能设计的基础。

不是因为”AI 评分听起来很酷”，所以我要做 AI 评分。
不是因为”面试题生成看起来很完整”，所以我要做面试题生成。
不是因为”多版本管理像专业工具”，所以我要做多版本管理。

而是因为这些功能分别对应了真实用户在真实场景里的真实卡点。

功能必须从问题里长出来，而不是从开发者脑子里冒出来。

六、V1.0 功能取舍：MoSCoW 分级

把用户、场景和痛点整理完之后，才能进入功能设计。

我用 MoSCoW 方法给简喵 V1.0 做了优先级划分。

MoSCoW 分成四类：

Must Have：第一版必须有，没有就跑不通核心流程。
Should Have：很重要，但可以在核心流程跑通后补。
Could Have：有了更好，但不影响第一版验证。
Won’t Have：当前阶段明确不做，避免范围失控。

Must Have：第一版必须做

V1 的核心链路应该是：

用户输入简历内容。
系统分析问题。
AI 给出优化建议。
用户确认修改。
导出可投递版本。

只要这条链路跑通，简喵就有基本价值。

Should Have：重要，但可以稍后做

这些功能都重要，但它们不能抢走 V1 的开发资源。

第一版最重要的是证明：用户愿不愿意用简喵来改简历内容。

Could Have：有更好，没有也能用

Could Have 的原则是：如果顺手能做，可以做；如果要牺牲核心功能进度，直接砍。

Won’t Have：V1 明确不做

这里最关键的是最后两项。

简喵可以帮用户表达真实经历，但不能替用户伪造经历。

AI 简历工具如果没有边界，很容易变成”求职包装机器”。它能让简历短期更好看，但也会让用户在面试里暴露得更快。

我希望简喵做的是增强真实表达，而不是制造虚假能力。

七、判断需求优先级的三个问题

为了避免功能越做越散，我给简喵设了三个判断问题。

问题一：没有这个功能，核心流程能跑通吗？

如果不能跑通，就是 Must Have。

比如 PDF 导出。没有它，用户即使完成了优化，也没法拿去投递。那前面的评分和润色就只是演示功能。

再比如简历内容编辑。没有编辑能力，用户就无法确认和修改 AI 建议，产品也不可能形成闭环。

问题二：这个功能解决的是”卡住”，还是”锦上添花”？

“不会写项目经历”是卡住。
“不知道 JD 关键词”是卡住。
“导出 PDF”是卡住。

但”分享链接访问统计”不是卡住。它有价值，但不是第一版必须解决的问题。

V1 应该优先解决用户卡住的地方，而不是做一堆看起来完整但不影响主流程的功能。

问题三：技术复杂度会不会拖慢 V1？

有些功能价值很高，但复杂度也高。

比如 PDF / Word 解析。

用户当然希望直接上传已有简历，然后系统自动识别内容。但现实是，简历格式千奇百怪，PDF 里可能有表格、分栏、图标、文本框、特殊字体。解析出来经常顺序错乱、字段丢失、格式混乱。

如果 V1 一开始就死磕 PDF 解析，很可能会把大量时间耗在边缘问题上，最后核心的 AI 优化反而做不好。

所以我的取舍是：

V1 优先支持结构化编辑和 GitHub 导入。
PDF / Word 解析可以做基础版，但不把它当成唯一入口。
等核心流程验证后，再逐步提升解析准确率。

这是一个典型的产品取舍：不是这个功能不重要，而是现在不该让它拖慢主线。

八、简喵 V1 的核心流程

经过上面的分析，简喵 V1 的核心流程可以压缩成一句话：

让用户输入真实经历，AI 帮他发现问题、优化表达、匹配岗位，并导出一份可投递简历。

对应流程是：

进入简喵
  ↓
创建或导入简历
  ↓
填写基础信息、教育经历、项目经历、技能栈
  ↓
AI 进行简历评分
  ↓
用户查看问题诊断
  ↓
选择项目经历或整份简历进行优化
  ↓
粘贴目标岗位 JD 做匹配分析
  ↓
生成针对岗位的优化建议
  ↓
用户确认修改
  ↓
导出 PDF

这个流程不复杂，但它必须稳定。

比起做十个半成品功能，我更希望 V1 把这条链路打磨清楚。

九、这篇文章真正想说明什么

这篇文章不是为了证明我做了多专业的用户调研。

恰恰相反，简喵的前期调研很轻量。它更像一个学生项目在启动前应该做的最低限度思考：

用户是谁？
用户什么时候用？
用户最痛的地方是什么？
第一版解决哪个问题？
哪些需求先不做？
为什么不做？

只要这几个问题想清楚，项目就不会一开始失控。

很多项目不是死在技术难度上，而是死在需求膨胀上。今天加一个模板市场，明天加一个在线协作，后天加一个会员系统，大后天又想做投递管理。最后看起来像一个完整求职平台，实际每个功能都浅得像雨后积水。

简喵第一版要克制。

它不做大而全的求职平台，也不做复杂排版工具。它先解决一个最核心的问题：

帮助用户把真实经历写得更清楚、更专业、更适合投递。

这就是 V1 的边界。

十、写在最后

需求分析不是把所有想法都写下来，然后一个个塞进项目里。

真正重要的是判断：

什么是用户现在最痛的？
什么是第一版必须解决的？
什么是看起来有用但会拖慢主线的？
什么是绝对不能做的？

对简喵来说，第一版最重要的不是功能数量，而是核心链路能不能跑通。

用户能不能输入真实经历。
系统能不能指出简历问题。
AI 能不能给出可用的优化建议。
用户能不能根据目标岗位调整简历。
最后能不能导出一份可以投递的 PDF。

如果这些能跑通，简喵就不是一个空壳项目。

下一篇，我会继续写简喵的产品流程设计：用户从打开简喵，到拿到一份优化后的简历，中间到底要经过哪些步骤，每一步页面应该解决什么问题，以及异常情况应该怎么处理。

下面是简喵当前开发版本的部分界面。功能和样式还会继续迭代，但核心方向已经确定：让用户不只是”做出一份好看的简历”，而是写出一份更清楚、更专业、更适合投递的简历。

简喵的核心工作台：围绕简历分析、AI 优化、JD 匹配和面试准备组织功能。

用户可以上传简历，也可以直接编辑内容，让 AI 基于真实信息进行分析，而不是套一段通用模板。

系统会从多个维度分析简历问题，比如内容完整度、表达质量、项目亮点和量化表达。

简喵最核心的价值不是”帮你写漂亮话”，而是把原本模糊、平淡的经历，转化成更适合求职场景的表达。

简历优化不是终点。简喵还会根据简历内容生成可能被追问的面试题，帮助用户提前准备。

GitHub仓库地址：https://github.com/RyanCoreAI/AIResume

一次很普通但很不舒服的经历

去年 11 月的一个晚上，我用一款在线简历工具改简历。

基本信息、教育经历、项目经历、技能标签、自我评价，每一栏我都认真填了。项目经历改了好几遍，自我评价那段甚至来回调整了五六次。那种状态很熟悉：你明明只是想写一份简历，结果慢慢进入一种”再改一点就好了”的循环。

一个多小时后，我终于点了”导出 PDF”。

然后，弹出了付费窗口。

那一刻我第一反应不是”贵不贵”，而是”我被套路了”。

如果一开始告诉我导出要付费，我其实可以接受。工具有成本，服务要收费，这都很正常。但真正让人不舒服的是：它先让你把所有内容都填进去，让你投入时间、精力和耐心，等你已经不想重来一遍时，再在最后一步告诉你：想拿走结果，先付费。

这不是单纯的收费策略，而是在利用沉没成本。

你填的不是简历，是逃跑成本。每多填一栏，你就更不愿意放弃。等你终于走到最后一步，系统才把门关上。互联网产品把人性研究得这么熟，结果用来卡一个学生导出 PDF，属实有点荒谬。

最后我做了一件很笨但很多人可能都做过的事：截图，然后在 Word 里手动复刻版式，调整字号、行距、边距，再导出 PDF。效果不算好看，但至少能用。

那天之后，我开始想一个问题：

能不能做一个真正免费的简历工具？
不靠最后一步卡导出收费。
不只是给用户一堆模板。
而是认真帮用户把简历内容写清楚。

这就是简喵的起点。

大学生写简历的真正问题：不是没经历，是不会翻译

做简喵之前，我一直以为很多同学写不好简历，是因为经历太少。

后来我发现并不完全是这样。

很多计算机专业的学生，其实并不是完全没有东西可写。他们做过课程设计，写过实验室项目，参加过比赛，搭过小工具，甚至维护过自己的 GitHub 仓库。但这些经历一旦放进简历里，就会变成非常干的一句话：

负责前端页面开发和后端接口设计。

这句话不能说错，但几乎没有信息量。

它没有告诉别人你用了什么技术，没有告诉别人你解决了什么问题，没有告诉别人你做到了什么程度，也没有体现你在项目中的具体价值。

同样一个 Vue + Spring Boot 项目，可以写成：

负责前端页面开发和后端接口设计。

也可以写成：

基于 Vue3 和 Spring Boot 实现图书管理系统，负责用户登录、权限控制、图书检索、借阅记录管理等核心模块；封装 20+ 个可复用组件，设计 RESTful 接口并完成 MySQL 表结构设计，支持多角色用户的基础权限管理。

这两段描述背后的项目可能差不多，但给人的感觉完全不同。

前者像是在说”我参与过”。
后者是在说”我具体做了什么，并且能复用到真实开发中”。

这就是简历表达里的”翻译”问题。

学生做过的事情，需要被翻译成招聘方能看懂的能力语言。项目不是简单堆技术名词，而是要说明场景、职责、动作、结果和可迁移能力。

很多人不是没经历，而是没有把经历翻译成简历语言。

你调接口调到凌晨，简历上写”参与项目开发”。
你把一个功能从需求做到上线，简历上写”完成相关模块”。
你做了权限、缓存、异常处理、部署，简历上只写”熟悉后端开发”。

真正亏的不是你没做事，而是你做过的事没有被看见。

市面上的简历工具，很多只解决了”排版”

我试过不少简历工具，最后发现它们大概可以分成两类。

第一类是排版工具。

它们提供很多模板，能让简历看起来更整齐、更漂亮。这个方向当然有价值，因为一份排版混乱的简历确实会降低阅读体验。但问题是，排版只能解决”看起来怎么样”，不能解决”到底写什么”。

第二类是模板填充工具。

你输入一个岗位名称，它给你生成一些看起来很专业的描述。短期看很方便，但问题也很明显：这些内容往往太通用。不同的人投同一个岗位，生成出来的描述可能非常接近。HR 一天看很多简历，这种模板味很容易被识别出来。

这两类工具之间，有一块很重要的空白：内容层。

也就是帮助用户判断：

我的项目里哪些内容值得写？
这一句话是不是太空？
哪里需要补充量化结果？
哪些技术点适合放前面？
这份简历和目标岗位到底匹不匹配？
面试官看到这段项目经历可能会追问什么？

这些问题，才是很多学生真正卡住的地方。

简喵想做的不是另一个”简历版 Word”，也不是批量制造 AI 味简历的模板机器。

我更希望它成为一个简历内容助手：帮用户看懂自己的经历，整理自己的项目，优化自己的表达，并且尽量保留真实经历本身。

简喵想解决什么问题

一句话概括：

简喵是一个 AI 简历优化与 JD 匹配系统，帮助用户把真实经历转化成更专业、更清楚、更适合投递的简历表达。

它目前围绕几个核心功能展开。

第一，简历上传与内容解析。

用户可以上传已有简历，也可以直接编辑简历内容。系统会尽量识别不同模块，比如教育经历、项目经历、技能栈、自我评价等，为后续分析做准备。

第二，AI 简历评分。

简喵会从多个维度分析简历，而不是只给一个笼统总分。比如内容是否完整，表达是否具体，项目是否有亮点，量化信息是否足够，结构是否清晰，和目标岗位是否匹配。

我不想做那种”你的简历 82 分，请继续努力”的空洞评分。分数本身没意义，真正有用的是指出哪里扣分、为什么扣分、怎么改。

第三，项目经历优化。

这是简喵最核心的部分。

很多学生的项目并不差，但表达非常弱。简喵会尝试把”负责后端开发”这种描述，改成更具体的项目 bullet，比如使用了什么技术、解决了什么问题、完成了什么模块、产生了什么结果。

这里的重点不是编造经历，而是把已经存在的信息表达清楚。

第四，JD 匹配诊断。

很多人投简历时只有一个动作：海投。

但不同岗位对关键词、项目方向和能力证明的要求并不一样。后端开发、AI 应用开发、前端工程、算法实习，它们关注的点完全不同。

所以简喵会支持用户粘贴目标岗位 JD，然后分析简历中哪些内容已经匹配，哪些内容表达不足，哪些关键词缺失，哪些项目应该被重点突出。

第五，面试题生成。

简历不是写完就结束了。

你写上去的每一句话，都可能在面试里被追问。比如你写 Redis，面试官可能问缓存穿透、缓存雪崩、数据一致性；你写 JWT，面试官可能问 Token 续期、权限校验、Refresh Token；你写 AI 接入，面试官可能问 Prompt 设计、异常处理、成本控制和限流。

所以简喵会根据用户简历内容生成可能的面试追问，让用户提前知道自己写上去的东西是否真的能讲清楚。

为什么一定要免费导出

我做简喵的第一个情绪来源，就是被”最后一步付费导出”恶心到。

所以这个项目有一个很明确的原则：不靠卡导出收费。

编辑可以免费，预览可以免费，导出也应该免费。

当然，AI 功能本身有调用成本，完全无限制并不现实。后续我会通过次数限制、缓存、限流、任务队列和成本控制来处理这个问题。但这和”你都填完了，现在不给钱就不能导出”不是一回事。

我反感的不是工具收费，而是不透明地利用用户投入。

如果未来简喵真的需要商业化，也应该把边界提前说清楚，而不是把用户逼到最后一步才亮出价格。

这点对我很重要。

我做这个项目，不只是为了做一个工具

说实话，简喵不只是一个工具项目。

它对我来说还有另一层意义：这是我用来训练自己完整工程能力的项目。

一个真正能上线、能被别人使用的 AI 应用，不只是调用一次大模型 API。它要考虑很多更现实的问题：

文件上传怎么做安全校验？
PDF 和 Word 解析失败怎么办？
大模型输出不是 JSON 怎么处理？
用户连续点击评分会不会烧掉 API 额度？
接口超时怎么重试？
AI 服务不可用时怎么降级？
简历数据怎么保护隐私？
导出 PDF 怎么保证格式稳定？
项目部署到服务器后怎么排查问题？
日志怎么记录，错误码怎么设计，成本怎么审计？

这些东西，学校不会完整教，普通教程也很少讲。很多教程只讲”如何调通一个 Demo”，但真实项目最难的部分往往在 Demo 之后。

所以我想用简喵把这些问题完整走一遍。

从需求分析到产品流程，从前端编辑器到后端接口，从 AI Prompt 到 JSON 校验，从 Redis 限流到 Docker 部署，从 README 到技术博客，我希望它最后不是一个只能截图展示的课程作业，而是一个能被认真讲清楚的作品。

一个帮别人写简历的工具，自己首先要成为一个值得写进简历的项目。

这句话其实就是我做简喵的核心动机。

这个系列会写什么

这篇文章只是开始。

简喵后面会整理成一个完整系列，我会尽量把产品设计、技术实现、工程取舍和项目复盘都写出来。不是只写”我用了什么技术”，而是写清楚”为什么这么做””踩了什么坑””最后怎么解决”。

这个系列大概分成几个部分。

第一部分是产品决策。

我会写清楚为什么选择简历优化这个方向，目标用户是谁，核心场景是什么，第一版 MVP 应该做什么，又有哪些功能暂时不该做。

第二部分是系统设计。

包括技术选型、整体架构、数据库设计、前后端模块拆分，以及为什么使用 Spring Boot、Vue3、MySQL、Redis 和大模型 API 组合。

第三部分是 AI 工程。

这是我认为最有价值的一部分。大模型接入不是简单发请求，还要处理 Prompt 稳定性、结构化输出、JSON 校验、异常重试、成本控制、限流和降级。

第四部分是业务功能。

包括简历评分、项目经历优化、JD 匹配、面试题生成、隐私保护、权限设计和导出能力。

第五部分是部署和复盘。

包括 Docker 部署、服务器配置、日志排查、项目 README、简历写法，以及这个项目如何成为一个真正能展示工程能力的作品。

我不打算把它写成”跟着我一步一步复制代码”的教程。那种文章已经太多了，而且大多数看完也只是多了一个本地 Demo。

我更想写的是，一个普通 CS 本科生如何从 0 开始，把一个 AI 应用项目做成可以展示、可以复盘、可以写进简历、也能被别人理解的完整作品。

这篇文章写给谁

如果你正在找实习或准备校招，但不知道简历为什么投出去没反应，这个系列会适合你。

如果你也在做 AI 应用项目，但感觉自己只是”套了一个 API”，不知道怎么把项目做得更像真实工程，这个系列也会适合你。

如果你想写技术博客，但不知道写什么，这个系列也可以作为一个参考：一个项目不是只能写一篇总结，而是可以拆成需求、架构、功能、问题、取舍、复盘和求职表达。

我不想把简喵包装成一个宏大的产品，也不想说它能解决所有求职问题。

它现在还只是一个正在开发和打磨中的项目。它肯定会有 bug，会有不成熟的地方，也会有很多需要迭代的功能。

但至少它从一个真实问题开始。

我自己被简历工具的付费导出卡过，我也见过很多同学明明做过项目，却在简历上写得像没做过一样。我知道这个问题不是虚构出来的，也不是为了做项目硬找的选题。

这就是我愿意继续做下去的原因。

结尾

简历写不好，不一定是你没有能力。

很多时候，是你没有把自己的经历翻译成别人能快速理解的语言。

简喵想做的，就是帮你完成这一步：把真实经历整理出来，把模糊表达改清楚，把项目价值讲明白，把简历从”我好像做过一些东西”变成”我能证明自己做成过什么”。

这也是我做这个项目的原因。

下一篇，我会写简喵的需求分析：目标用户是谁、他们在什么场景下打开这个工具、最痛的痛点是什么，以及第一版 MVP 到底应该做哪些功能。

2026 年，我想把自己的技术方向收得更清楚一点。

过去一段时间，我花了不少时间使用 AI 工具。ChatGPT、Claude、DeepSeek、Cursor、Claude Code，这些工具确实很有用。它们可以帮我解释报错、生成代码、梳理思路、改文章，也能让我更快完成一些以前需要查很久的事情。

但用得越多，我越感觉到一个问题：只会使用 AI 工具，并不能形成真正稳定的竞争力。因为工具本身会越来越普及，今天我会用，明天别人也会用。真正能拉开差距的，不是用过多少工具，而是能不能借助这些工具做出一个真实项目。

所以我今年的重点不是继续收藏更多工具，而是把 AI 能力接入到具体应用里。简单说，就是从”工具使用者”往”项目构建者”转。

为什么不能只停留在 AI 工具使用

会用工具已经不稀缺

现在很多人都会用 AI 写代码、改简历、总结文章、生成方案。这当然是好事，AI 工具降低了学习和开发的门槛，也确实能提升效率。

但如果一个人的能力只停留在”我会让 AI 帮我写代码”，那其实很危险。因为这件事本身并不稀缺，而且很难证明自己真正理解项目。比如我说我会用 Claude Code 或 Cursor，这只能说明我知道这个工具。但别人真正关心的是：我用它做出了什么？项目有没有上线？核心模块怎么设计？数据库怎么设计？接口失败怎么处理？大模型输出不稳定怎么办？如果这些问题讲不清楚，工具使用经验就会显得很薄。

AI 提高效率，但不替代判断

AI 很适合辅助学习和开发，但它不能替我做判断。

它可以给我生成一段代码，但这段代码是否适合当前项目，需要我判断。它可以给我几个技术方案，但最终选择哪个方案，需要我承担后果。它可以帮我写 Prompt，但用户到底需要什么，还是要我自己想清楚。它可以解释报错，但项目结构、数据流和权限设计，不能完全交给它。

我现在对 AI 工具的理解是：它是放大器，不是方向盘。如果我有清楚的目标，它能帮我更快推进；如果我自己方向不清楚，它只会帮我更快制造一堆碎片。所以今年我会继续用 AI，但不会把”会用 AI”当成终点。

我的技术定位

我更适合先做 AI 应用开发

我现在不会把自己定位成大模型底层研究者，也不会假装自己在做算法突破。对我目前的阶段来说，更实际的方向是 AI 应用开发，也就是把大模型能力接入到具体场景里，做成用户可以使用的功能。比如简历优化、知识库问答、内容生成、文档分析、面试辅助、学习规划、个人效率工具。

这些方向不一定听起来最硬核，但它们很贴近实际产品，也适合我现在用项目来训练综合能力。我现在最需要的不是空谈 AI 趋势，而是把一个 AI 应用项目从 0 做到上线。

技术主线：AI 应用开发 + Java 后端工程化

我今年的技术主线会放在两个方向上。

第一个是 AI 应用开发，重点是需求分析、Prompt 设计、大模型 API 接入、结构化输出、异常兜底、成本控制和隐私保护。第二个是 Java 后端工程化，重点是 Spring Boot、MySQL、Redis、JWT、接口设计、权限控制、异常处理、日志、限流、Docker、Nginx 和服务器部署。

这两个方向必须结合起来。如果只有 AI，没有后端工程能力，项目很容易变成一个临时 demo；如果只有后端，没有 AI 应用场景，项目又容易变成普通管理系统。我希望做的是二者结合：用后端工程能力支撑 AI 应用，让项目真正可用、可部署、可展示。

今年的第一个重点项目：简喵

为什么选择 AI 简历项目

我今年准备重点做的项目叫”简喵”，一个 AI 简历优化项目。选择这个方向不是因为它最热门，而是因为我自己确实遇到过类似问题。

有一次我在网上用简历模板，填了很久，最后导出 PDF 的时候才提示要付费。当时的体验很差。后来我就想，能不能做一个对学生更友好的免费简历工具。但真正开始思考这个项目后，我发现问题不只是”免费导出”。

很多大学生写简历的难点，其实是不会表达自己的经历：做过项目，但写得很平；学过技术，但不知道怎么写进项目描述；有一些成果，但不会量化；投不同岗位，也不知道简历应该怎么调整。所以简喵的核心不只是模板，而是帮助用户把已有经历整理成更适合求职场景的表达。

第一版想做到什么程度

简喵第一版不会一上来做得很复杂。我希望先完成一个基本闭环：用户注册登录；上传 PDF 或 Word 简历；系统解析简历文本；用户输入目标岗位；AI 分析简历内容；输出评分、问题和优化建议；生成项目经历改写示例；保存历史分析记录；部署到服务器，能够在线访问。

这个版本不一定完美，但要真实可用。我不想做一个只能截图展示的项目，至少要能让别人打开链接体验，能看到功能流程，能通过文章了解背后的技术设计。

我需要补的后端能力

不只写接口

以前我有时候会把后端理解成写接口、查数据库、返回结果。但真正做项目以后，会发现后端需要考虑的问题更多：用户有没有登录？接口有没有权限校验？用户能不能访问别人的简历？上传文件有没有格式和大小限制？AI 调用失败时怎么提示？日志会不会记录用户隐私？大模型 API 会不会被刷爆？数据库表以后能不能扩展？上线后出问题怎么排查？这些问题才是项目真正容易暴露短板的地方。

所以我今年会重点补后端工程化，而不是只追求功能表面能跑。

围绕项目补技术

我不打算孤立地学一堆技术名词，而是围绕简喵这个项目去补。

Spring Boot 用来搭建后端接口和业务模块；MySQL 用来保存用户、简历、岗位和分析记录；Redis 用来做限流、验证码、缓存或调用次数控制；JWT 或 Session 用来处理登录和接口鉴权；Docker 用来保证部署环境一致；Nginx 用来做反向代理和静态资源访问；阿里云服务器用来让项目真正上线；大模型 API 用来完成简历分析和优化建议生成。

这些技术只有放进具体项目里，才不会停留在”我学过”的层面。以后我写技术文章，也会尽量从项目问题出发，而不是单独写概念。比如我更想写：简喵为什么需要 Redis 限流；大模型 API 为什么不能暴露在前端；简历上传为什么要做文件校验；Prompt 为什么要要求结构化输出；日志为什么不能打印完整简历内容。这种写法对我自己也更有帮助。

AI 应用开发真正要解决的问题

调 API 只是第一步

很多 AI 项目看起来像是”接入一个模型接口”。但我现在越来越觉得，调用 API 只是最简单的一步。真正困难的是让模型能力变成稳定的产品功能。

以简喵为例，如果我只是把用户简历直接丢给大模型，然后让它”帮我优化一下”，这个功能可能偶尔能用，但很难稳定。它可能输出很空泛的建议，可能格式每次都不一样，可能编造用户没有的经历，可能忽略目标岗位，可能返回太长前端不好展示，也可能超时、失败、成本失控。所以 AI 应用开发要考虑的不只是”能不能回答”，还要考虑结果是否稳定、可解析、可保存、可展示、可追踪。

Prompt、结构化输出和兜底

我需要在项目里重点处理几个问题。

第一是 Prompt 设计。模型需要知道它的角色、任务、输入内容、评分维度、输出格式和限制条件。第二是结构化输出。如果模型只返回一大段文字，前端展示和后端保存都会很麻烦，所以最好让它输出固定字段，比如总分、优势、问题、修改建议、项目经历改写等。第三是异常兜底。模型不一定每次都按要求返回，它可能输出非法 JSON，也可能缺字段，还可能调用失败，后端必须能处理这些情况，而不是直接让用户看到一堆错误。

这些内容会是我做简喵时重点记录的部分。

项目必须上线

本地能跑不算结束

今年我给自己定了一个比较硬的要求：项目尽量都要上线。因为本地能跑，只能说明功能初步完成，真正部署到服务器以后，才会遇到更多实际问题：环境变量怎么配置、数据库连接怎么处理、前后端跨域怎么解决、Nginx 怎么配置、HTTPS 证书怎么申请、服务器端口怎么开放、日志怎么查看、移动端访问是否正常。这些问题不一定复杂，但如果没有亲自部署过，就很难真正理解。

上线后项目才更像作品

如果一个项目只有代码仓库，没有在线地址，没有截图，没有 README，没有部署说明，也没有复盘文章，别人很难判断它的完成度。我希望简喵最后至少具备这些东西：在线体验地址、GitHub 仓库、项目截图、功能说明、技术栈说明、系统架构说明、部署文档、项目复盘、面试问答整理。这样它才不只是一个练手项目，而是一个能被展示、能被理解、能被追问的作品。

博客在这条路线里的作用

写博客不是额外任务

我以前会觉得，项目先做，文章以后有空再写。但现在我觉得，博客本身就是项目的一部分。因为项目完成以后，如果没有文档和复盘，很多价值是展示不出来的。尤其是对普通本科生来说，项目文章可以补充简历里写不下的内容。

简历只能写几行，博客可以把背后的思考写清楚：为什么做这个项目、技术选型怎么定、数据库怎么设计、Prompt 怎么写、权限怎么处理、上线遇到什么问题、项目有哪些不足。这些内容写出来后，项目会更可信，自己也会更清楚。

博客、GitHub、在线地址要形成闭环

我希望最后形成一个比较完整的证据链：博客文章说明我理解项目；GitHub 仓库说明我写了代码；在线地址说明项目可以访问；README 说明我能整理文档；项目复盘说明我能总结问题；简历 bullet 说明我能把项目价值表达出来。这几个东西合在一起，才是一个项目真正对求职有帮助的地方。

2026 年的几个目标

经营好 yanxai.com

第一个目标是把 yanxai.com 持续更新起来。不是追求一开始有多少访问量，而是先把内容结构搭好。我会先写博客定位、技术路线、简喵项目开篇，然后围绕项目继续写需求分析、技术选型、系统架构、数据库设计、Prompt 设计、部署上线和复盘文章。

完成简喵 MVP

第二个目标是完成简喵的第一版。第一版不追求功能非常多，但必须有完整流程：注册登录、简历上传、文本解析、目标岗位输入、AI 分析、结果展示、历史记录和部署上线。只要这个闭环跑通，后面才能继续优化。

补齐工程细节

第三个目标是把项目做得更像真实系统。包括权限校验、统一异常处理、日志脱敏、Redis 限流、接口文档、部署文档、项目截图、测试账号和 README。这些细节可能不会让项目看起来更炫，但会让它更可靠。

转化成简历和面试材料

第四个目标是把简喵整理成能真正放进简历的项目。这包括项目描述、技术栈、亮点 bullet、1 分钟项目介绍、3 分钟项目介绍，以及一套常见面试问题。项目不是写完代码就结束，能不能讲清楚也很重要。

我会怎样使用 AI 工具

我不会减少使用 AI 工具，相反我会更系统地用。我会用它们辅助查问题、写代码、解释框架、分析方案、优化文章、模拟面试。但我会尽量避免直接把 AI 的输出当成自己的理解——AI 生成的代码，我要能看懂；AI 给出的方案，我要能判断；AI 写出的解释，我要能验证；AI 帮我整理的文章，我要加入自己的真实经历。否则很容易出现一种假象：内容看起来很完整，但其实自己没有真正掌握。

这也是我写博客时需要注意的地方。文章可以参考 AI 的帮助，但最终必须写成自己的表达，写出自己真实做项目时遇到的问题。

写在最后

2026 年，我不想只停留在会用 AI 工具。

工具当然重要，但它不是终点。对我来说，更重要的是借助工具做出真实项目，把功能部署上线，把过程写清楚，把项目转化成简历和面试里能讲得明白的材料。

所以今年的路线会比较明确：围绕 AI 应用开发做项目；用 Java 后端补工程能力；把项目部署到线上；用博客记录过程和复盘；最后把这些内容变成可以展示的作品集。

这条路不一定很快，也不会一开始就很漂亮。但至少我现在知道自己要往哪里走。后面，yanxai.com 会持续记录这个过程。

• Claude Code：Anthropic 出的终端 AI 编程神器，公认最好用的代码 Agent 界面：能读整个项目、改文件、跑命令、Git 操作、多轮思考，体验顶级、但锁死 Claude 官方模型，贵且容易封号。
• DeepSeek V4 Pro：国产顶级大模型，代码能力接近 Claude Opus，中文更强、价格极低、国内直连、不封号，而且原生兼容 Claude 协议，换个地址就能用。

两者结合，等于白嫖顶级编程体验。

一、前置准备

1. 安装 Git（没有必须装）

1. 打开浏览器访问 Git 官网下载：https://git-scm.com/download/win
2. 下载完成后双击安装包，全部默认下一步，不用改任何配置。
3. 安装结束后不用打开 Git，直接关闭安装窗口即可。

2. 安装 Node.js

1. 浏览器打开 Node.js 官网：https://nodejs.org/
2. 下载 LTS 长期稳定版（推荐）。
3. 双击安装包，全程默认下一步，勾选 Add to PATH（默认已勾选）。
4. 安装验证：右键开始菜单 → 打开 Windows PowerShell，依次输入两条命令，能输出版本号就是安装成功：

node -v
npm -v

3. 申请 DeepSeek 官方 API Key

1. 浏览器打开 DeepSeek 官网：https://www.deepseek.com/
2. 右上角登录 / 注册账号（手机号登录即可）。
3. 进入个人控制台 → 找到「API 密钥管理」。
4. 点击「创建密钥」，复制生成的 sk- 开头密钥，粘贴到记事本保存（只显示一次，关掉就看不到）。

4. 新建专属工作文件夹

随便找一个磁盘，比如 D 盘，新建文件夹：D:\AI\ClaudeCode。进入这个文件夹，空白处右键 → 选择 在此处打开 Windows PowerShell，后续所有命令都在这个窗口执行。

二、完整安装 Claude Code 官方客户端

Claude Code 项目文档：https://code.claude.com/docs/en/overview

1. PowerShell 全局安装 Claude Code

在刚才打开的 PowerShell 里，直接复制粘贴回车：

npm install -g @anthropic-ai/claude-code

等待下载安装完成（出现一堆 ok、version 即完成）。

2. 验证是否安装成功

继续输入命令回车：

claude --version

能输出版本号 = 安装成功。

3. 初次初始化（只看流程，不登录）

输入命令进入 Claude Code 终端界面：

claude

会进入官方欢迎初始化页面，不用登录、不用绑定账号，直接放着就行，后面配置会跳过登录。

三、安装 CCswitch 模型切换插件（核心关键）

作用：一键切换 Claude Code 底层模型，换成 DeepSeek V4 Pro

方式一：Git 克隆安装（推荐，无多余软件）

依旧在刚才的 PowerShell 窗口，逐行复制执行：

git clone https://github.com/op7418/guizang-ppt-skill.git ~/.claude/skills/guizang-ppt-skill

克隆完成无报错，就是安装成功。

方式二：不会用 Git 就手动下载

1. 浏览器打开 GitHub 搜索：op7418/guizang-ppt-skill
2. 进入仓库 → Code → Download ZIP 下载压缩包。
3. 解压后把整个文件夹放到路径：C:\Users\你电脑用户名\.claude\skills\，没有 skills 文件夹就自己新建一个。

四、图形化 CCswitch 配置 DeepSeek V4 Pro（一步一步照着填）

1. 回到 PowerShell，输入命令打开 CCswitch 面板：

/skills

找到 guizang-ppt-skill 启用，打开可视化配置面板。

2. 面板右上角点击 + 添加提供商

3. 提供商预设选择：DeepSeek，自动填充：请求地址、协议格式，不用手动改。

4. 手动填写以下内容（严格照抄）：

• 提供商名称：DeepSeek-V4Pro
• API Key：粘贴你之前复制的 sk-xxxx 完整密钥
• 模型名称填写：deepseek-v4-pro

5. 高级设置（必勾）：

• API 兼容格式：选择 Anthropic Message 原生兼容
• 勾选：跳过 Claude 官方初次登录引导
• 勾选：强制替换默认模型

6. 点击 测试供应商，提示「测试连接成功、模型响应正常」再下一步。

7. 点击 设为默认启用，此时 Claude Code 底层已经换成 DeepSeek V4 Pro。

JSON 配置如下（记得填写 API Key）：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "",
    "ANTHROPIC_MODEL": "Deepseek-V4-Pro",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "DeepSeek-V4-Flash",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "Deepseek-V4-Pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "Deepseek-V4-Pro"
  },
  "hooks": {
    "Stop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "async": true,
            "command": "powershell -Command \"(New-Object Media.SoundPlayer 'C:\\Windows\\Media\\Windows Notify.wav').PlaySync(); Add-Type -AssemblyName System.Windows.Forms; [System.Windows.Forms.MessageBox]::Show('Claude 任务已完成/中断', 'Claude Code', 'OK', 'Information')\""
          }
        ]
      }
    ],
    "Notification": [
      {
        "matcher": "permission_prompt|idle_prompt",
        "hooks": [
          {
            "type": "command",
            "async": true,
            "command": "powershell -Command \"(New-Object Media.SoundPlayer 'C:\\Windows\\Media\\Windows Exclamation.wav').PlaySync(); Add-Type -AssemblyName System.Windows.Forms; [System.Windows.Forms.MessageBox]::Show('Claude 需要你输入/授权', 'Claude Code', 'OK', 'Warning')\""
          }
        ]
      }
    ]
  },
  "includeCoAuthoredBy": false
}

五、无工具手动配置兜底方案（不用 CCswitch 也能用）

1. 找到用户配置目录

打开此电脑，地址栏直接粘贴：

C:\Users\%USERNAME%\.claude

2. 新建 / 编辑 settings.json 文件

在 .claude 文件夹里，新建文本文档，改名为 settings.json。注意：后缀从 .txt 改成 .json。

右键用记事本打开，粘贴下面内容，把 sk-你的DeepSeek-API-Key 换成你自己的：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "sk-你的DeepSeek-API-Key",
    "ANTHROPIC_MODEL": "deepseek-v4-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "deepseek-v4-pro",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "deepseek-v4-pro"
  }
}

保存关闭。

3. 跳过官方登录强制引导

回到 C:\Users\你的用户名 根目录，新建文件 .claude.json，粘贴内容：

{
  "hasCompletedOnboarding": true
}

保存，彻底跳过登录步骤。

六、完整验证是否真正接入 DeepSeek V4 Pro

1. 关闭所有 PowerShell 窗口，彻底关掉。
2. 重新进入文件夹 D:\AI\ClaudeCode，空白右键 → 在此处打开 PowerShell。
3. 输入命令进入 Claude Code：

claude

4. 在 Claude Code 内部输入查看模型命令：

/model

显示 deepseek-v4-pro = 切换成功。

5. 实测发消息测试，输入：

帮我用Java SpringBoot写一个简单的Controller示例，带完整注释

能正常生成代码、响应流畅，就是完全配置好了。

七、常见报错超详细解决

1. 输入 claude 不是内部命令

原因：Node.js 没装 / 没加到系统环境变量。
解决：重装 Node.js 并重启电脑。

2. 一直弹窗要求登录 Anthropic 账号

解决：检查 C 盘用户目录下 .claude.json 是否写了："hasCompletedOnboarding": true

3. 测试供应商失败、接口报错

1. API Key 不要有空格、不要多复制字符
2. Base URL 必须严格是：https://api.deepseek.com/anthropic
3. 关掉科学上网、代理，用本地网络

4. Git 克隆不是内部命令

原因：Git 没装或没加到环境变量。
解决：重装 Git，安装时默认勾选 Add to PATH。

5. 模型切过去还是 Claude 原版

解决：重启终端 → 重新 /model 查看 → CCswitch 重新设为默认。

八、日常固定使用流程（以后每次都这么开）

1. 打开 D:\AI\ClaudeCode 文件夹
2. 空白右键 → 在此处打开 PowerShell
3. 输入：claude 回车
4. 直接发需求：写 Java、写 Vue3、写项目架构、写简历，全部自动走 DeepSeek V4 Pro。

九、接入 PPT-skill 能力

GitHub 仓库：https://github.com/op7418/guizang-ppt-skill

手动 Git 克隆：

git clone https://github.com/op7418/guizang-ppt-skill.git ~/.claude/skills/guizang-ppt-skill

安装好后就有制作 PPT 的能力了。之后说”一份杂志风PPT”就会自动触发。

总结

整套流程走完，你拥有了：

• 顶级编程交互体验（Claude Code 界面）
• 国产模型的价格和速度（DeepSeek V4 Pro 国内直连）
• PPT 自动生成能力（guizang-ppt-skill）

两句话总结：Claude Code 的壳，DeepSeek 的脑，PPT 随手搞。

Hexo 是一个基于 Node.js 的静态博客框架，一条命令就能把 Markdown 文章生成完整的 HTML 站点。Matery 是 Hexo 生态中最受欢迎的 Material Design 风格主题之一，自带响应式布局、暗黑模式、代码高亮、相册灯箱、搜索、评论等全套功能。

相比 WordPress 需要服务器和数据库，Hexo 的纯静态方案配合 GitHub Pages 零成本、免运维、加载快，非常适合个人博客。

本教程最终效果预览：https://ryancoreai.github.io

读完这篇教程，你将拥有一个完全免费、加载飞快、可深度定制的个人博客站点。

一、环境准备

1.1 安装 Node.js

• 官网：https://nodejs.org/
• 下载 LTS（长期支持版），一路 Next 默认安装即可
• 验证安装（打开终端或 Git Bash）：

node -v
npm -v

1.2 安装 Git

• 官网：https://git-scm.com/
• 默认安装，验证：

git --version

1.3 注册 GitHub 账号

• 注册地址：https://github.com/

二、创建 GitHub 仓库（关键：命名规则）

1. 登录 GitHub → 右上角 + → New repository
2. 仓库名必须严格写：你的用户名.github.io
   • 例：用户名是 peter-create-ai → 仓库名 peter-create-ai.github.io
3. 选 Public
4. 其他默认 → Create repository

这个仓库就是你的博客站点入口，GitHub 会自动把它识别为 GitHub Pages 站点。

三、安装 Hexo 并初始化博客

3.1 换国内镜像（下载提速）

npm config set registry https://registry.npmmirror.com

3.2 全局安装 Hexo

npm install -g hexo-cli

验证：

hexo -v

3.3 创建博客项目

hexo init blog
cd blog
npm install

完成后目录结构：

blog/
├── _config.yml        # 全局配置文件（核心）
├── source/
│   └── _posts/        # 文章 Markdown 放这里
├── themes/            # 主题目录
├── scaffolds/         # 文章模板
└── package.json       # 插件依赖

四、安装必备插件

在博客根目录 (blog/) 执行以下命令：

4.1 部署插件

npm install hexo-deployer-git --save

将生成的静态文件推送至 GitHub Pages。

4.2 搜索插件

npm install hexo-generator-search --save

生成 search.xml，供 Matery 主题的本地搜索功能使用。

4.3 中文链接转拼音

npm i hexo-permalink-pinyin --save

文章标题包含中文时，URL 自动转为拼音，避免链接中出现乱码。

4.4 RSS 订阅 + 站点地图（SEO 优化）

npm install hexo-generator-feed --save
npm install hexo-generator-sitemap --save

这两个插件为搜索引擎提供标准化的内容索引，利于收录。

4.5 静态资源压缩（加载速度优化）

npm install hexo-all-minifier --save

自动压缩 HTML、CSS、JS、图片，显著减少页面体积。

五、配置 _config.yml（核心步骤）

用编辑器打开 blog/_config.yml，按以下内容修改：

5.1 网站基本信息

title: 我的博客
subtitle: ''
description: '记录学习与思考'
keywords: blog, tech, AI
author: 你的名字
language: zh-CN
timezone: ''

# URL 配置
url: https://peter-create-ai.github.io
root: /
permalink: :year/:month/:day/:title/
permalink_defaults:
pretty_urls:
  trailing_index: true
  trailing_html: true

5.2 文章与分页

new_post_name: :title.md
default_layout: post
titlecase: false
external_link:
  enable: true
  field: site
filename_case: 0
render_drafts: false
post_asset_folder: false
relative_link: false
future: true
highlight:
  enable: false
prism_plugin:
  mode: 'preprocess'
  theme: 'tomorrow'
  line_number: false
index_generator:
  path: ''
  per_page: 12
  order_by: -date

关键点：

• post_asset_folder: false —— 图片统一管理更方便（见下文图片管理章节）
• highlight.enable: false —— 关闭 Hexo 默认高亮，改用主题自带的 Prism

5.3 搜索配置

search:
  path: search.xml
  field: post

5.4 中文链接转拼音配置

permalink_pinyin:
  enable: true
  separator: '-'

5.5 RSS 配置

feed:
  enable: true
  type:
    - atom
    - rss2
  path:
    - atom.xml
    - rss.xml
  limit: 20
  content: true
  content_limit: 200
  order_by: -date
  autodiscovery: true

5.6 Sitemap 配置

sitemap:
  path: sitemap.xml
  template:
  rel: false
  tags: true
  categories: true

5.7 部署配置（到你的 GitHub 仓库）

deploy:
  type: git
  repo: https://github.com/peter-create-ai/peter-create-ai.github.io.git
  branch: main

把所有 peter-create-ai 替换成你自己的 GitHub 用户名。

六、安装并启用 Matery 主题

6.1 下载主题

cd themes
git clone https://github.com/blinkfox/hexo-theme-matery.git
cd ..

6.2 启用主题

在 _config.yml 中修改：

theme: hexo-theme-matery

七、配置 Matery 主题（themes/matery/_config.yml）

Matery 主题有自己的配置文件 themes/matery/_config.yml，一定要改，否则首页显示的是默认信息。

7.1 首页个人信息

# 首页大图轮播
cover:
  enable: true
  length: 5           # 展示文章数
  showTitle: true     # 显示文章标题

# 头像 & 社交链接
profile:
  avatar: /medias/avatar.jpg
  name: Ryan Guo      # 你的名字
  socialLinks:
    - icon: fab fa-github
      url: https://github.com/你的用户名
    - icon: fas fa-envelope
      url: mailto:你的邮箱@gmail.com

7.2 导航菜单

menu:
  Home: /
  Archives: /archives
  Categories: /categories
  Tags: /tags
  About: /about
  Friends: /friends
  # 不需要的注释掉即可

7.3 文章与代码块配置

# 文章展示
postInfo:
  date: true
  update: true
  wordCount: true      # 需 hexo-wordcount 插件
  totalCount: true
  min2read: true
  readCount: true

# 代码块功能
code:
  break: false         # 是否强制折行
  lang: true           # 显示语言标签
  copy: true           # 一键复制按钮
  shrink: false        # 代码块折叠

7.4 评论系统（推荐 Giscus）

# Giscus —— 基于 GitHub Discussions，免费、无广告、开源
giscus:
  enable: true
  repo: 你的用户名/你的用户名.github.io
  repoID: 你的仓库ID
  category: Announcements
  categoryID: 你的分类ID

申请 Giscus 非常简单：访问 giscus.app，填入仓库名，自动生成配置。

7.5 搜索 & 打赏

# 本地搜索（需 hexo-generator-search 插件）
search:
  enable: true

# 打赏
reward:
  enable: false        # 需要时改为 true
  QRCode:
    - /medias/reward/wechat.png
    - /medias/reward/alipay.jpg

7.6 首页文章摘要

Matery 默认在首页显示文章全文，建议配合 <!-- more --> 使用摘要截断：

这是文章开头，会显示在首页卡片中。

<!-- more -->

从这里开始的内容，需要点击文章进去才能看到。

八、创建 Matery 必需的页面

Matery 主题依赖以下页面结构，逐个创建：

7.1 分类页

hexo new page categories

编辑 source/categories/index.md：

---
title: categories
type: "categories"
layout: "categories"
---

7.2 标签页

hexo new page tags

编辑 source/tags/index.md：

---
title: tags
type: "tags"
layout: "tags"
---

7.3 关于页

hexo new page about

编辑 source/about/index.md：

---
title: about
type: "about"
layout: "about"
---

内容自由发挥，放自我介绍、联系方式等。

7.4 友链页

hexo new page friends

编辑 source/friends/index.md：

---
title: friends
type: "friends"
layout: "friends"
---

九、文章图片管理方案（推荐）

在 source/ 下创建 images/ 文件夹，所有图片统一放在这里：

source/
├── images/
│   ├── avatar.png
│   └── blog01.jpg
└── _posts/
    └── 你的文章.md

文章内引用图片

格式固定：

![图片描述](/images/图片名.jpg)

示例：

![博客配图](/images/blog01.jpg)

建议分类管理

图片多了可以建子目录：

![生活照](/images/life/001.jpg)
![学习笔记](/images/study/note01.webp)

图片命名规则

• 使用英文 + 数字命名，如 blog01.jpg
• 避免中文和空格
• 建议压缩后再上传（推荐在线工具 TinyPNG 或 squoosh）

为什么不用 post_asset_folder？
每次新建文章自动创建同名文件夹会分散图片管理。统一放在 /images/ 下，路径固定、好找、可复用。

十、写第一篇完整文章

9.1 新建文章

hexo new "我的第一篇博客"

生成文件：source/_posts/我的第一篇博客.md

9.2 文章 Front-matter 完整写法

---
title: 我的第一篇博客
date: 2026-05-10 12:00:00
categories: 生活
tags:
  - 随笔
  - 日常
top: true       # 置顶，放在首页最上面
cover: true     # 首页轮播大图展示
toc: true       # 显示文章目录（默认就是 true）
---

9.3 Matery 文章专属配置项

9.4 Markdown 正文示例

以下是文章正文的常见写法，直接复制模板修改即可：

二级标题和段落

## 二级标题 后用空行分隔正文。正文直接写，无需额外标记。

列表

- 列表项 1
- 列表项 2
  - 嵌套子项

插入图片

![插图](/images/blog01.jpg)

文字样式

**加粗文字** 和 *斜体文字*

引用块

> 学而不思则罔，思而不学则殆

行内代码

用 `hexo server` 命令启动本地预览。

Java 代码块

```java
public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}
```

提示：展示 “如何在 Markdown 里写代码块” 时，外层用四个反引号 ```` `````` ` 包裹，内层的三个反引号就不会被解析为结束标记。

写好文章后，配合 Matery 的目录导航和代码高亮，阅读体验就是上面这样。

十一、本地预览

hexo server

浏览器打开 http://localhost:4000

边写边预览，修改保存后页面自动刷新。按 Ctrl+C 停止服务。

十二、发布上线

11.1 一键部署命令

hexo clean && hexo g && hexo d

命令含义：

• hexo clean —— 清空旧生成的静态文件
• hexo g (generate) —— 生成新的静态 HTML
• hexo d (deploy) —— 推送至 GitHub Pages

11.2 访问博客

https://你的用户名.github.io

部署后等待 1-2 分钟，GitHub Pages 会自动刷新。

部署成功后，你的博客主页大概长这样。Matery 的大图轮播 + Material Design 卡片布局，颜值在线。

十三、部署英文作品集（进阶：单仓库多站点）

如果你的英文作品集（Portfolio）也需要上线，可以和博客共用一个 GitHub Pages 仓库：

1. 单独创建一个 Portfolio 项目，使用 Cactus 或其他主题
2. Portfolio 的 _config.yml 中设置 root: /portfolio/
3. 在博客部署前，把 Portfolio 的 public/ 复制到博客的 public/portfolio/ 下

这样就能同时拥有：

• 中文博客：https://用户名.github.io
• 英文作品集：https://用户名.github.io/portfolio/

十四、主题美化：统一配色方案

Matery 默认使用绿色作为主题色。以下是以紫色（#8b5cf6）为例的替代方案。

13.1 修改的完整文件清单

13.2 颜色映射表

13.3 批量查找替换命令（Bash）

# 在 themes/matery 目录下查找所有绿色残留
grep -rn "42b983\|0f9d58\|4cbf30\|38a274\|3ecf8e\|0ba360\|3cba92" \
  --include="*.css" --include="*.ejs" .

十五、关闭不需要的功能

14.1 统计与分析

编辑 themes/matery/_config.yml：

# 关闭百度统计
baiduAnalytics:
  enable: false
  id:

# 关闭 Google Analytics
googleAnalytics:
  enable: false
  id:

# 关闭百度推送
baiduPush: false

14.2 移除不用的插件

npm uninstall hexo-theme-landscape hexo-renderer-pug

hexo-theme-landscape 是 Hexo 默认主题，已用 Matery 就不需要了。hexo-renderer-pug 是 Pug 模板引擎，Matery 用的是 EJS。

十六、日常写作工作流

新文章

hexo new "文章标题"

本地预览

hexo server

访问 http://localhost:4000 实时查看效果。

发布上线

hexo clean && hexo g && hexo d

一句话总结

写 Markdown → hexo server 预览 → hexo clean && hexo g && hexo d 发布

十七、常见问题排查

Q1：部署后页面空白 / 404？

检查 _config.yml 中的 url 和 root：

• 根站点：root: /
• 子目录站点：root: /子目录名/

Q2：图片显示不出来（裂图）？

1. 确认图片放在了 source/images/ 下
2. 引用路径必须以 /images/ 开头，如 ![图](/images/xxx.jpg)
3. 不要用相对路径 ../images/

Q3：部署后网站没变化？

• GitHub Pages 有 1-5 分钟缓存，等一等
• 强制刷新浏览器：Ctrl+Shift+R
• 检查 GitHub 仓库的 Actions 页面是否显示绿色对勾

Q4：想要自定义域名？

1. 在 source/ 下创建 CNAME 文件，写入你的域名（如 blog.example.com）
2. 去域名 DNS 服务商添加 CNAME 记录指向 你的用户名.github.io
3. GitHub 仓库 Settings → Pages → Custom domain 填写域名

Q5：如何添加评论系统？

推荐 Giscus（基于 GitHub Discussions），比 Gitalk 更简单，无需申请 OAuth App：

1. 访问 giscus.app，填入仓库名
2. 在 GitHub 仓库 Settings → Features 中开启 Discussions
3. 把生成的配置填入 themes/matery/_config.yml：

giscus:
  enable: true
  repo: 你的用户名/你的用户名.github.io
  repoID: 从 giscus.app 获取
  category: Announcements
  categoryID: 从 giscus.app 获取
  mapping: pathname
  lang: zh-CN

Matery 还支持 Gitalk、Valine、Waline、Twikoo 等，按需选择即可。

Q6：代码块没有语法高亮？

确认 _config.yml 中启用了 Prism.js：

prismjs:
  enable: true
  preprocess: true

Matery 主题内置了 Prism.js 的支持，开启后代码块会自动应用 Okaidia 暗色主题 + 行号。

Q7：首页显示文章全文而不是摘要？

在文章中加入 <!-- more --> 标签，前面的内容作为摘要显示在首页卡片中，后面的内容只有点进去才能看到。

总结

这篇保姆级教程从一个空仓库开始，手把手带你完成了：

1. 环境搭建 → Node.js + Git + GitHub 仓库
2. 博客创建 → Hexo 初始化 + 必备插件
3. 核心配置 → _config.yml 网站配置 + Matery 主题配置
4. 内容写作 → Front-matter 配置 + Markdown 规范 + 图片管理
5. 主题美化 → 全站配色统一（紫/蓝/任意色）
6. 功能增强 → 评论系统（Giscus）+ 搜索 + RSS + Sitemap
7. 部署发布 → 一键推送到 GitHub Pages
8. 进阶扩展 → 多站点部署、自定义域名、代码高亮（Prism.js 暗色主题）

如果你已经跟着教程做完了所有步骤，恭喜——你现在拥有的是一个零成本、完全自定义、加载飞速、好看又好用的个人博客。

写吧。写得越多，收获越多。

时光辗转，终于拥有了属于自己的一方小天地 —— 这个简简单单的个人博客，算是我在网络世界里留下的专属角落。不用迎合繁杂的社交节奏，不用刻意伪装情绪，只想在这里记录生活、沉淀心情，把日常里的点滴感悟、细碎美好都好好珍藏。

一路走来，总觉得生活需要一个可以安放思绪的地方。平日里忙碌于日常琐事，被学习和生活的节奏推着往前走，很多瞬间的感慨、突然冒出的想法，往往转瞬即逝，来不及细细回味。而搭建这个博客，于我而言，不仅是一次尝试新鲜事物的体验，更是给自己留一份慢下来的底气。在这里，我可以随心所欲写下所见所闻、所思所感，不用拘泥格式，不用纠结文笔，只以最真实的状态与自己对话。
生活本就是由无数平凡的瞬间拼凑而成。清晨推开窗扑面而来的清风，午后窗边洒落的一缕暖阳，傍晚天边渐变的晚霞，还有闲暇时安静看书、放空发呆的时光，这些看似微不足道的小美好，其实都是生活赠予我们的温柔。往后我想在博客里，记录下这些温柔片刻：偶尔是生活里的小确幸，偶尔是成长路上的小迷茫，偶尔是读到好书的心得体会，也会分享一些日常感悟与细碎心事。
人总要学会和自己独处，学会在喧嚣中守住内心的平静。现在的我们总是被短视频、碎片化信息包围，很难静下心来好好沉淀。而写作与记录，是最好的沉淀方式。敲下文字的过程，也是梳理情绪、理清思绪的过程，那些想不通的烦恼、藏在心底的情绪，落笔之后往往会豁然开朗。
这个博客没有华丽的修饰，没有刻意的迎合，只有最真实的自我表达。往后的日子里，我会坚持在这里更新，把生活的烟火气、成长的点点滴滴都一一记录。不求有人刻意驻足，只愿多年后回头翻看，能清晰记得此刻的心境与时光。
也愿每一个偶然闯入这里的人，都能在文字里找到一丝共鸣，卸下疲惫，收获一份平静与治愈。往后余生，以文字为伴，以时光为笺，慢慢记录，慢慢成长，不负生活，不负自己。