1.摘要：
求职计Career-Gambit，赛博军师的锦囊妙计。一个覆盖JD 分析、沟通话术、简历定制到模拟面试 的全链路求职备战平台。
2.背景：
-
身份标签：土建规园行业的“下岗民工” / 零基础代码小白 / 正处于找工作找疯了的状态（
重要的废话：从我这辈开始，三代禁学土建规园，否则逐出家门） -
为什么做：为提高求职命中率，每个岗位的 JD 要逐字分析、简历要反复调、沟通话术要打磨、面试题要准备……全部散落在不同的 AI 聊天窗口和文档里，事后回溯整理耗时费力，且每次沟通都要重复录入背景。基于此，我需要一个能将岗位分析、简历定制、面试备战全链路打通的整合工具，使数据按岗位自动关联流转，而非在不同对话框之间反复粘贴。
-
诚实地说：其实这个工具能提供的帮助，任何一个 AI 聊天工具基本都能完成。它唯一的优点是：把所有求职数据整合在一个地方，按岗位自动流转，不用再翻聊天记录了。
3.实践过程：小白的“野路子”Vibecoding 流程
事先声明：起初根本没觉得能做成，纯属“闲的 + 想试试 TRAE SOLO 内测”，过程中也混用了多个 AI 工具，不知道这是否符合参赛标准。
3.1我的基本流程：
PRD 文档： Gemini 生成
UI/UX 前端设计（用 Google AI Studio 设计界面并 push 到 GitHub）
代码仓库托管（GitHub）
让 SOLO 接管项目（在 Trae 中 git clone，让 AI 索引整个代码库，基本能做到 100% 还原设计）
数据库连接（生成初始化的 SQL 语句在 Supabase 手动执行）
功能开发（按模块逐一迭代，前端、后端、数据库同步推进）
（ 
我也不确定这个流程是不是最优解，欢迎大家评论区指点）
UI /前端设计阶段：术业有专攻，借力工具找准视觉锚点
UI/前端设计： Google AI Studio。一开始想全程用 TRAE SOLO，加了好几个官方 UI skill 和一份 design.md 规范，生成的前端效果始终不满意。最后试了 Google AI Studio，终于给出了我想要的样子，所以就直接延用了。虽然是大家调侃的"AI 紫"，但它几分钟的产出已经是我的一辈子了。
我发现：完全可以先找一个擅长 UI 生成的工具定调，前提是它能直连 GitHub，哪怕只产出半个不完整的页面也行——好的工具已经帮你把视觉基调定好了，剩下的让SOLO接管项目直接基于代码库进行组件复用和样式扩展就行。这比从零开始对着不擅长设计的 AI 描述“我要什么风格”高效得多。
功能开发：大模型的参差，选对大脑是第一要务
TRAE SOLO 接管一切。
我的 UI/前端设计还是半成品，进入功能开发后，前端界面、后端逻辑、数据库结构交叉并行，这才是真正混乱的开始。
一开始没耐心排队，用 Auto 模式，经常性改完网页就崩，复杂的交互逻辑完全无法闭环。即便装了 Skill、写了 Rule、用了 Plan ，某些大模型依然"猪脑过载"——差生文具多，用不明白。后来老老实实排队用 GLM 5.1，事实证明这完全值得等待，应对我这个产品绰绰有余。期间也去 Cursor、VSCode、Codex 薅过其他聪明大模型帮忙。
最终心得就一句：选对大脑，比堆工具更重要。
3.2 核心问题与解决方案
问题一：一次性生成带来的逻辑崩溃
一开始以为给了 PRD 就能一步到位，结果发现一次性下达“帮我完成整个功能”的指令，导致 AI 输出大量逻辑冲突的代码，功能的交互逻辑、关联内容存在大量问题，功能根本跑不通。
解决：模块化拆解，一个模块一个模块地磨。我把整个产品拆成了 6 个核心模块，逐一开发，直到它 100% 还原我的交互构思。
个人仓库（素材中心，所有模块的数据源头）
↓
├── 岗位拆解（JD 分析 + 匹配度 + AI 战略建议）
├── 沟通助手（语气预设 + 技能标签 + AI 生成文案）
├── 简历定制（三种模式：空白组装 / 导入对比 / 借壳重构）
└── 面试备战（AI 出题 + 多版本答案 + 全真模拟面试）
↑ 数据按岗位隔离
投递看板（岗位管理 + 数据导出 + AI 洞察）
从 0 到 1 很快——AI 能迅速给出基本架构和样式。但 从 1 到 100 极磨人——大量精力花在核实交互问题、检查 prompt 合理性、排查数据库加载故障上。
同时，为了治住 AI 的记忆崩溃，写了一套 VibeCoding SOP，核心就两条原则：模块化拆解 + 文档驱动 【Schema.sql(数据结构)和PROJECT_SPEC.md(业务与逻辑蓝图)】 。整个开发被拆成 P1 到 P7 的闭环——每次只让 AI 聚焦一个功能模块，写代码前必须先梳理现有逻辑，由我确认后才放行，绝不让 AI 跳过思考直接动手。其实这和plan模式有点类似，Plan 往往是对某个特定任务的即时拆解，而PROJECT_SPEC.md是对整个开发思路和底层逻辑的持久记录，是全局导航，在必要时被强制读取、强制更新。任何时候打开它，都能看到项目的功能进度、交互逻辑。这种做法很方便我这个开发小白事后回溯。
问题二：数据库与代码脱节
每次让 AI 改了数据库字段，都得去 Supabase 重新执行一遍 SQL，然后数据加载频频出问题。 Supabase 有延迟，实时保存容易造成数据混乱。
解决：
① SOP 强制同步：让 AI 在每次变更后同步更新Schema.sql(数据结构)和PROJECT_SPEC.md(业务与逻辑蓝图) 。但实话说，这也很依赖大模型——聪明的模型会按规则执行，有的完全不受控。所以还是经常性搞不清楚 AI 到底有没有帮我更新好Schema.sql？文件里的 SQL 和 Supabase 里实际执行的到底是不是同一版？
② 保存按钮兜底：因为 Supabase 有网络延迟，实时自动保存容易造成数据混乱（上一个编辑还没写入就开始下一步操作）。我的办法是：所有数据先在 localStorage 存储，只有用户点击「保存」才同步到 Supabase。所以你会发现页面上有很多保存按钮，这是为了数据不丢失而不得已为之的设计缺陷。
关于数据库的新手困惑：功能开发经常伴随数据库结构修改，每次都去执行 SQL 很烦。到底什么时候做数据库最合适？是先设计好表结构再写代码，还是等交互全写完再回头统一调？欢迎有经验的朋友指点。
问题三：文档排版的驯服与妥协
Web 页面导出 Word 和 PDF，折腾了很久都没彻底解决。我给了明确的格式规范，但中文排版术语（“小二号”“五号”“首行缩进2字符”）和代码库的参数体系根本对不上——docx 这类库走的是国际标准，只认数字参数，不认中文字号名，AI 拿到这些词生成的格式全是乱的。PDF 导出也踩了一圈坑：jsPDF 中文显示乱码，html2canvas + html2pdf.js 内容截断，最后换回浏览器原生打印，虽然能出文件，但没法精确控制排版规格，格式对不上规范。
解决： 把中文排版术语全部转成国际通用数字参数——“小二号”写成
size:44，“五号”写成size:21，“首行缩进2字符”写成indentation: {firstLine: 420}，但Word 的首行缩进始终纹丝不动，换了写法就是不动。PDF 同理，“小四号”转12pt，“五号”转10.5pt，转换之后，格式基本生效，但仍有偏差。
算了，先忍着。有没有好心人教教我。
4.成果展示：
-
产品文档：一份详细的《使用指南》，覆盖所有功能说明、操作技巧和最佳实践
核心功能截图
5.效果与总结：
提效对比
| 环节 | 以前 | 现在 |
|---|---|---|
| 岗位分析 | 看 JD费劲，跨行黑话看不懂 | AI一键拆解逐条翻译，并给出匹配度 |
| 简历定制 | 面对 JD 却不知搬哪段经历上场 | AI 自动提取匹配经历，针对性生成 |
| 面试备战 | 心里没底，不知道会问什么、该怎么答 | AI 按岗位生成问题 ，结合个人背景生成匹配自身能力的参考答案 |
| 沟通文案 | 反复改措辞 | AI 根据语气 + 技能标签一键生成 |
| 投递看板 | 投递记录散落各处，看不出规律 | 多岗位统一追踪，AI 分析投递数据 |
感悟
不敢相信一个 零代码小白在 2026 年做出了能用的网页产品。一开始只打算做个本地部署的小工具，在 SOLO 的引导下莫名其妙接了数据库、做了云部署。
以前做产品得先学技术再开发，现在可以 先做出产品再倒推技术栈——有点像"中间汇合"（ 以前：想法-技术-产品；现在：想法-产品-技术），这是一种全新的学习路径， 像是打开了新世界的大门，也让我对代码逻辑和系统架构生出了探索欲。
欠缺
-
还不懂如何从supabase完整导出 Schema.sql，数据库维护和变更依然是最脆弱的环节。
-
GitHub 依旧不会用，不敢合并分支，怕一合全乱，全靠回退保命。这恰好说明 SOLO 真的很适合零基础小白。
局限
-
缺乏行业术语和计算机语言描述能力，在和 AI 交互时以及写这篇文章时，很多地方表达不够精准。
-
求职眼界有限，做得比较基础，期待看到更专业的求职场景和产品思路。
写在最后
你以为产品做出来用上了就能找到工作吗？哈哈哈哈 
。 找工作在我这已经超出了科学范畴。其实我的第一个 Vibecoding 项目是搞玄学的，目前还是个烂尾项目。暂且相信科学先做了求职产品，如果依旧找不到工作——没关系，科学不行，那就回归玄学 
。（没有疯 ）