从 0 到百万级关注：我用 TraeCode 做了一款大学生求职应用

• 个人身份：FResume产品开发者、真实求职场景大学生
• 本次使用工具：TRAE CN
• 项目形态：Web 网站 + Chrome 浏览器插件
• FResume：Forge · Find · Focus · Fit · Fill，用 5 个 F 重新做一遍大学生求职
• 产品地址：https://fresume.odsy.com.cn

看完本文，你可以了解到：

• 为什么“ AI 对话模型”不足以解决大学生求职问题
• 我如何把用户反馈转化为 FResume 的产品闭环
• 如何通过事实分层、候选修改和两道确认机制约束 AI 幻觉
• 为什么我要做保留原简历样式的功能
• 如何把 TRAE 从代码生成工具变成产品分析、架构推演和调试协作伙伴
• 百万级关注和近千名内测用户，如何反过来改变产品方向

前言：一份简历，为什么让我决定重做求职流程

今年 6 月，我和很多大三学生一样开始投实习。从零写简历，买模板、开会员、付费请教，花了上百元。简历越来越“专业”，海投数百份，结果却没有明显改善。

更麻烦的是，每看到一个岗位，我都要重新判断：

哪些经历保留，哪些项目突出，哪些表述调整，耗费大量时间去调整简历；

改完简历，还要在各招聘网站重复填姓名、教育、项目、技能；

投递后，状态散落在聊天记录、收藏夹和表格里；

面试结束，很多复盘信息也没留下。

我也试过通用大模型。它能润色，但不能直接改原简历，生成的模板不好看，甚至会编造不存在的数字、职责和技术细节。每次投新岗位都打开 WPS 改，效率很低。

我逐渐意识到：大学生求职缺的不是“帮我写一段话”的 AI，而是一套围绕真实经历持续运转的流程。

于是，我用 TRAE 开发了 FResume。最初它只是一个强调视觉效果的简历 Demo。后来经历百万级关注、近千名学生多轮内测和数次大版本重构，逐步变成覆盖知识沉淀、简历优化、岗位匹配、面试准备、网申辅助、投递记录与复盘回流的求职工作台，并拿到 TRAE AI 创造力大赛的 1 万元奖金。

这篇文章不是功能说明书，而是一次开发实践复盘，想为大家分享我如何借 TRAE，把模糊的个人痛点验证、拆解、重构成真实可用的产品。

痛点：大学生缺的不是一份简历，而是一条完整链路

求职焦虑与混乱流程

作为大三学生，我的求职长期处于“散装”状态。

最典型的一次：秋招集中投递，我一天想投 10 个岗位。每看到一个 JD，就打开 WPS 改简历；改完再去不同网申地址重复填姓名、教育、项目、技能；投递状态散在聊天记录、收藏夹和表格里；面试结束，聊天窗口一关，复盘也没留下。

一开始做需求分析时，我也把问题拆成很多功能点：简历生成、岗位匹配、面试指南、自动填表、投递记录。但随着访谈和内测增加，我发现问题不是功能不够多，而是整个求职过程彼此断裂。

传统求职方式给我的是这样的体验：

• 不了解自己简历里的内容：为了看起来厉害，堆技术栈和高级词，但自己并不清楚它们到底是什么。面试官一追问，就露馅。
• 一份简历投所有岗位：产品、运营、开发都投同一份。即使知道要针对 JD 改，也很难判断该调哪段经历。一个岗位强调数据分析，另一个强调用户研究，而真实经历可能两者都沾，却被压在一页里，或者根本没写进去。传统工具只能改写当前文本，无法从用户过去的经历中重新选择材料。
• 按岗位改简历太耗时：秋招每天投 10 个岗位，如果每个都按 JD 精修一遍，大量时间都浪费在重复编辑上。
• AI 写得更好，却不一定更真实： 通用 AI 的流程通常是：上传简历 + 输入 JD → 直接输出修改后文字。用户不知道哪些来自原简历，哪些来自自己补充，哪些只是 AI 的表达建议，哪些数字和成果是模型推测的。所有内容混在最终文本里，只能逐字检查。对缺少求职经验的学生来说，甚至很难识别哪些表述已经越过事实边界。
• 投递完成，信息却没有积累：简历生成只是开始，后面还有网申、笔试、面试和复盘。每次投递都没有真正的沉淀入口，下一次又像重新开始。

核心矛盾在于：传统工具和通用 AI 回答的是“这段文字怎么改”，但大学生求职真正需要回答的是“我有哪些真实经历、这个岗位该突出什么、哪些不能编、投完如何沉淀、下一次如何复用”。

产品核心定位：从单点生成器到可信求职工作台

FResume 完整闭环

这个矛盾决定了 FResume 的定位。它不是一个更好看的通用对话模型套壳，而是一个完整的求职工作台。

FResume = 可追溯的求职工作流

围绕这条流程，我把 FResume 概括为 5 个 F：

• Forge ：构造简历，把分散经历整理成结构化职业素材
• Find ：发现岗位，集中查看和筛选校招信息
• Focus ：聚焦表达，针对具体内容进行分析和优化
• Fit ：匹配岗位，根据 JD 快速且保留原简历样式的生成适配岗位的简历
• Fill ：辅助网申，通过浏览器插件减少重复填写

这五个动作不是五个彼此孤立的页面，而是同一份用户事实在不同求职阶段中的流转。

TRAE 如何进入我的研发流程

开发 FResume 之前，我对 AI 编程工具的理解主要是“生成代码”。真正持续使用 TRAE 后，我发现更有价值的部分不是一次生成多少代码，而是它能否参与问题定义、方案比较、重构和验证。

我逐渐固定了和 TRAE 的协作输入：业务目标、现有实现、失败方案、约束条件、验收标准。

比如修简历格式时，我不只说“修复错乱”，而会说明原始文件职责、AI 可改范围、必须可回滚、历史版本要求，以及怎样算修复成功。

这样，讨论就从“改一段代码”变成“修正系统模型”。FResume 后续几次关键重构，都是在这种协作中逐步明确的。

我的开发历程：流量验证了需求，反馈推翻了最初方案

第一阶段：做给自己用的简历 Demo

FResume 的起点很简单：先解决我和身边人的简历问题。

初版强调动态交互和视觉表现，发到抖音后获得百万级关注，大量用户留言、进群。但流量没有证明产品成立。

首轮反馈指出：界面吸引人，真正提升求职效率的能力不够。用户要的是上传简历、针对岗位修改，并直接用于投递。

⚠️ 教训：传播数据能验证共鸣，不能代替价值验证。

第二阶段：近千名用户把功能清单变成工作流

在多个用户群内测后，近千名学生给出了具体反馈：

• 同一份简历投不同岗位不知道怎么调
• 生成内容不敢确定有没有编造
• 下载后格式不稳
• 招聘网站重复填表
• 投递后不知道用了哪版简历
• 面试后不复盘，下次继续犯错

我用 TRAE 帮我进行反馈分类，并重新映射到用户旅程。产品从“简历生成页面”扩展为知识库、简历、匹配、投递、复盘五个模块。

⚠️ 教训：复杂产品不是把功能都加上，而是找到一条让数据持续流动的主流程。

第三阶段：从“能生成”重构为“可信、可控、可回滚”

功能增加后，旧架构问题集中暴露：

• 上传文件、知识库、简历版本和生成文件职责混乱
• AI 修改可能覆盖原文
• 岗位匹配只给结果，用户不知道为什么增删经历
• 一处失败可能阻断整条流程

我没有继续打补丁，而是和 TRAE 多轮推演，重新确定内容主线：

原始上传文件（只读来源）
→ 知识库（事实、素材、多个表达版本）
→ 简历草稿（某求职用途下的结构化内容）
→ 简历修订（冻结快照，可比较、可恢复）
→ 模板产物（DOCX / PDF / PNG）

这次重构确立了一个原则：文件只是输入和输出，真正的业务状态必须存在于结构化数据和版本快照中。

我与 TRAE 的实践

左右滑动查看更多精彩内容

遇到的难题与解法

难题一：AI 优化简历，怎样不替用户编造人生？

难题：只靠 Prompt 写“禁止虚构”不够，模型仍可能补上看似合理但不存在的数字、职责和技能。

解法：把真实性做成机制。原始来源只读；事实素材必须确认；AI 只产候选，附修改理由、来源和风险；岗位匹配设两道门，先确认调整方案，再逐项确认最终内容。

实践心得：高风险内容不能只依赖 Prompt，要有来源追踪、结构校验、人工确认和版本回滚。

难题二：从“保留 Word 原格式”到重新定义文档职责

难题：让 AI 改写后回填 Word，复杂表格、文本框、分页和 run 拆分会导致格式错位，补丁越打越多。

解法：原始 Word/PDF 冻结为只读来源；AI 改结构化简历卡片；确认后生成修订快照；用内置模板输出 DOCX/PDF/PNG；超页先调间距字号，再给 AI 精简候选，删内容必须确认。

实践心得：长期靠补丁维持时，先检查对象职责。输入、业务数据、输出文件各承担一种职责。

难题三：怎样管理“一份简历的很多版本”？

难题：主简历、通用版、A 公司版、B 岗位版不断派生，用户说不清从哪来、投哪个、最终用哪版。

解法：把自由画布改成受约束版本树；区分简历（用途）、修订（内容快照）、产物（模板文件）。历史简历不静默更新，继续修改产生 V2/ V3，不覆盖 V1。

实践心得：涉及 AI 修改，历史结果必须是稳定快照，可追溯、可回退。

难题四：功能越来越多，新用户却越来越不会用

难题：功能更完整，首次使用压力反而更大。

解法：重设首次体验：可从零创建或上传简历；AI 解析预填；用户只处理低置信度、冲突和异常；高置信度默认通过但可改；按导入、优化、匹配、生成、投递逐步展开；先看结果，再介绍高级能力。

实践心得：不要把模型不确定性全变成表单负担。能可靠预填的就预填，把注意力留给真正有风险的部分。

一句话总结：四个难题指向同一原则：AI 负责候选和推演，用户掌握确认权，系统负责来源、版本和回滚。

从网站到浏览器插件：把能力放回投递现场

网页端适合整理知识和生成简历，但真正填写网申时，用户停留在招聘网站中。如果必须反复切回 FResume，流程仍然会被打断。

因此，我使用 Chrome Extension Manifest V3 开发了侧边栏插件，让用户在招聘页面直接调用网申包、复制常用字段并记录投递信息。侧边栏不覆盖招聘网站主体，投递完成后还能关联公司、岗位、简历版本和时间。

我也没有把体验完全押在“自动识别所有 DOM 并一键填写”上。招聘网站结构经常变化，完全自动化很容易因为页面更新而失效。FResume 因此保留截图识别字段、生成标准网申包和一键复制等降级路径。即使自动识别不可用，用户仍然可以完成投递。

实践心得：自动化功能必须设计可用的降级路径。第三方页面不受自己控制时，稳定完成任务比展示一次完美自动化更重要。

产品架构速览

FResume 整体架构图

效果验证：从关注度到真实 offer

作品的前期关注度：

内测用户：

真实反馈：

在前段时间的 TRAE AI 创造力大赛也是用这个作品获得了 10000 元奖金：

7 条 TRAE 产品开发实践

1. 先讲清业务约束，再让 AI 写代码

复杂功能的质量取决于上下文质量。将目标、现状、失败方案、硬约束和验收标准一起交给 TRAE，比一句“帮我实现”更容易获得可落地结果。

1. 让 TRAE 同时给出多个方案和取舍

对于文档解析、版本模型、异步任务等架构问题，我更关注方案的失败边界，而不是代码看起来是否完整。先比较，再实施，可以减少在错误方向上的投入。

1. 用失败样本推进调试

“格式有问题”很难定位；具体说明是哪类文件、哪个段落、预期结果和实际结果，TRAE 才能帮助建立最小复现并补充回归测试。

1. 把 AI 输出当候选，不当最终事实

这既是我使用 TRAE 的原则，也是 FResume 的产品原则。代码、架构建议和简历内容都需要经过验证，AI 负责加速探索，人负责确认边界。

1. 用户反馈要映射到流程，不要直接变成功能

用户说“想自动填表”，背后可能是“不想重复输入”；用户说“想多生成几个版本”，背后可能是“无法管理岗位差异”。先找到真实任务，再决定产品形态。

1. 重构时先划分职责，再搬代码

FResume 最大的稳定性提升，不来自某个新的文档库，而来自重新定义原始文件、知识库、简历快照和输出产物之间的关系。

1. 只公开可以解释和复现的数据

百万级关注、近千名内测和真实 offer 都有对应材料。技术指标则应同时说明样本、基线和方法。AI 项目尤其需要避免用不可验证的数字制造确定感。

写在最后

从解决自己的求职问题，到 Demo 获得百万级关注，再到现在2千名用户，FResume 的方向不断发生变化。

初版解决的是“能不能快速做出来”；第一次迭代解决的是“用户到底需不需要”；全流程重构解决的是“各个功能能不能形成闭环”；最新的可信架构解决的是“AI 修改能不能被理解、确认和恢复”。

这个过程中，TRAE 帮助我的不只是生成前端页面、后端接口和处理脚本。更重要的是，它让我可以用更低的成本反复讨论方案、检查假设、构造失败场景，并在发现模型不对时重新设计系统。

FResume 也不是要替代求职者思考。它希望把重复填表、格式整理、信息检索和版本记录交给工具，把经历挖掘、岗位选择、事实确认和面试复盘留给用户。

人的工作没有消失，只是从机械重复转移到了更重要的判断上。

对我而言，这才是使用 TRAE 开发 FResume 最值得沉淀的经验：

AI 编程的价值，不是让开发者少思考，而是让我们更快抵达真正值得思考的问题。

最后给大家安利一下 TRAE 官方的社区，本人极力推荐，是最具活力、温度与价值的普惠AI社区！

本文作者嘉良 ，TRAE 深度用户,来源@TRAE.ai。

原文链接：https://mp.weixin.qq.com/s/M_LekM4Zwq0GvRIwxKUpxA