企业官网建设流程全解析

简介：这份资源围绕GPT-4在简历生成场景中的落地应用展开，面向希望借助大模型提升求职文书效率的开发者与求职者，尤其适合具备一定Python基础、想了解AI个性化写作服务实现思路的人群。压缩包共23个文件，约452KB，以py源码与pyc编译文件为核心，配合yaml部署配置、Dockerfile、toml与lock依赖清单，以及md说明、pdf文档和license等，覆盖从模型调用、数据库交互到容器化部署的完整链路。目录中可见gpt_model、functions、queries、settings等模块，分别承担模型封装、业务逻辑、数据查询与参数配置职责，deploy与templates则对应部署编排与页面模板，便于读者理解一个AI简历服务的工程结构。目前已有90人学习下载，可借此参考GPT-4接入方式、提示词组织与项目分层设计，快速搭建属于自己的智能简历生成原型。

1. 用 GPT-4 生成简历：从一段 JD 到一份能投递的文档

投过简历的人都懂那种感觉：盯着空白文档半小时，写出来的东西自己都不想看第二遍。用 GPT-4 模型生成简历这件事，核心不是让 AI 替你编经历，而是把「你已有的素材」重新组织成招聘方想看的结构。我做过一个最小闭环：输入一段岗位 JD 加自己的原始经历，输出一份 Markdown 简历，再转成 PDF 投出去。整个过程不需要任何第三方简历平台，本地跑就行。

这套方案适合三类人：一是海投时想针对不同 JD 快速改简历的；二是经历零散、不知道怎么组织语言的；三是想批量生成多版本简历做 A/B 测试的。它解决的是「表达」问题，不是「造假」问题——素材必须真实，GPT-4 只负责措辞和排版逻辑。下面把我实际跑通的路径拆开讲，包括 prompt 怎么写、参数怎么调、哪些地方会翻车。

2. 先搞清楚 GPT-4 生成简历的边界在哪

2.1 它能做什么、不能做什么

GPT-4 在简历场景里最擅长的三件事：把口语化描述改写成专业表达、按 JD 关键词调整措辞侧重、把零散经历归纳成 STAR 结构。比如你写「帮公司搞了个数据看板」，它能改成「主导搭建业务数据看板，覆盖 6 条业务线，日均查询 200+ 次」。

它不擅长的是：判断你的经历是否真实、了解你所在行业的隐性偏好、处理需要具体数字但你没提供的场景。我见过有人让 GPT-4 直接生成一份完整简历，结果全是「负责 XX 工作，提升了效率」这种空话——因为模型没有你的真实素材，只能编。所以正确用法是「你给料，它加工」，不是「它给料，你签字」。

还有一个边界：GPT-4 对国内某些行业的术语理解有偏差。比如「中台」「闭环」「抓手」这类词它用得比真人还溜，但放到传统制造业简历里就显得很怪。所以生成后必须人工过一遍，把不自然的词换掉。

2.2 为什么选 GPT-4 而不是其他模型

我对比过几个方案。本地跑 Llama 系列做简历生成，中文表达明显生硬，STAR 结构经常缺「Result」部分；用 Claude 效果接近 GPT-4，但 API 接入成本略高。GPT-4 的优势在于：中文简历的语料它见过足够多，对「负责」「主导」「参与」这类动词的层级区分比较准，而且 JSON 模式输出稳定，方便后续程序化处理。

如果你只是偶尔改一份简历，直接用网页版对话就行。但如果要批量生成、或者想把流程嵌到自己的工具里，走 API 更可控。下面给的代码都是 API 路径，网页版用户可以把 prompt 直接复制过去用。

3. 用 API 跑通最小生成流程

3.1 环境准备与依赖安装

我习惯用 Python 跑这类文本生成任务，依赖少、调试快。需要装 openai 库和 python-dotenv 管理密钥。

pip install openai python-dotenv

然后在项目根目录建一个.env文件，写入你的 API Key：

OPENAI_API_KEY=sk-你的密钥

注意不要把.env提交到 git，加进.gitignore。我见过有人把密钥硬编码在脚本里然后传到公开仓库，第二天就被刷爆了额度——这种血泪经验一次就够了。

3.2 构造简历生成的核心 Prompt

Prompt 的质量直接决定输出质量。我的做法是把 prompt 拆成四块：角色设定、输入素材、输出格式、约束条件。下面是我实际用的模板：

import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) SYSTEM_PROMPT = """你是一位有 10 年经验的资深 HR 和技术面试官。 你的任务是把候选人的原始经历改写成一份专业简历。 要求： 1. 使用 STAR 结构（情境、任务、行动、结果）组织每段经历 2. 动词分层：主导 > 负责 > 参与，根据原始描述判断层级 3. 每段经历必须包含至少一个量化结果，如果原始素材没有数字，用 [待补充] 标记 4. 不要编造任何未提供的经历、公司名、时间 5. 输出 Markdown 格式，包含：个人信息、技能栈、工作经历、项目经历、教育背景 """ def generate_resume(jd_text, raw_experience): user_prompt = f"""目标岗位 JD： {jd_text} 我的原始经历： {raw_experience} 请根据 JD 调整措辞侧重，生成简历。""" response = client.chat.completions.create( model="gpt-4", messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_prompt} ], temperature=0.3, max_tokens=2000 ) return response.choices[0].message.content

这段代码的关键在temperature=0.3。简历生成不需要创意，需要稳定和准确，温度调高会让模型自由发挥，容易编出你没做过的事。max_tokens=2000对一份简历够用，如果你的经历特别多可以调到 3000，但注意 GPT-4 的输出上限。

System prompt 里那条「没有数字用 [待补充] 标记」是我踩坑后加的。早期版本让模型自己填数字，结果它给我编了个「提升 300% 效率」——面试时被追问怎么算的，直接露馅。现在用占位符，生成后自己填真实数据，安全得多。

3.3 把 JD 和经历喂进去的实操细节

JD 不要整段复制，先手动删掉「五险一金」「弹性工作」这类无关信息，只留职责描述和任职要求。原始经历也别一股脑倒进去，按「公司-时间-做了什么-结果」的格式整理成条目，模型理解起来更准。

我一般会跑两轮：第一轮生成初稿，第二轮把初稿和 JD 一起再喂进去，让模型检查关键词覆盖度。第二轮 prompt 可以这样写：

def refine_resume(draft, jd_text): response = client.chat.completions.create( model="gpt-4", messages=[ {"role": "system", "content": "你是简历优化专家，检查简历与 JD 的关键词匹配度，列出缺失的关键词并建议补充位置。"}, {"role": "user", "content": f"JD：{jd_text}\n\n简历初稿：{draft}"} ], temperature=0.2 ) return response.choices[0].message.content

这一步能帮你发现「JD 里要求 Kubernetes，但你简历里只写了 Docker」这类问题。注意它只负责指出缺口，补不补、怎么补还是你自己决定。

4. 避坑与常见问题排查

4.1 生成内容全是空话，没有具体细节

现象：输出里大量「负责 XX 工作，提升了团队效率」这类无信息量句子。

原因：原始素材太笼统，模型没有具体内容可加工，只能套模板。

解决：喂素材时强制自己回答三个问题——做了什么动作、用了什么工具、产生了什么可衡量的结果。哪怕结果是「把周报时间从 2 小时压缩到 30 分钟」这种小事，也比「提升了效率」强。

4.2 模型编造了不存在的经历

现象：简历里出现你没做过的项目或没掌握的技术。

原因：temperature 设太高，或者 prompt 里没有明确禁止编造。

解决：temperature 压到 0.2-0.3，system prompt 里加「禁止编造未提供的经历」。生成后逐条核对，发现编造的直接删。

4.3 中文表达有翻译腔

现象：出现「负责了 XX 的开发和维护工作」这种英式中文。

原因：GPT-4 的中文输出有时受英文语料影响。

解决：在 system prompt 里加一句「使用简洁的中文书面语，避免翻译腔」。如果还有问题，生成后自己改一遍，把「进行了 XX 的操作」改成「操作了 XX」。

4.4 API 调用超时或返回截断

现象：请求卡住，或者返回内容到一半就没了。

原因：max_tokens 设太小，或者网络波动。

解决：max_tokens 至少设 1500，简历长的话设 2500。加个重试逻辑：

import time def call_with_retry(func, max_retries=3): for i in range(max_retries): try: return func() except Exception as e: if i == max_retries - 1: raise time.sleep(2 ** i)

4.5 生成的简历格式在 PDF 里乱掉

现象：Markdown 转 PDF 后排版错乱，表格溢出。

原因：Markdown 表格列数太多，或者用了 PDF 渲染器不支持的语法。

解决：简历里少用复杂表格，技能栈用列表代替。转 PDF 推荐用 pandoc 加 LaTeX 模板，或者直接粘到 Typora 导出。我一般用 pandoc：

pandoc resume.md -o resume.pdf --pdf-engine=xelatex -V mainfont="Noto Sans CJK SC"

中文字体必须指定，否则 PDF 里中文全是方块。

5. 批量生成多版本简历与效果验证

5.1 用循环批量跑不同 JD

海投时最耗时的就是针对每个岗位改简历。我的做法是把多个 JD 存成列表，循环调用生成函数，每个版本单独存文件：

jds = { "backend": "负责后端服务开发，要求熟悉 Python、MySQL、Redis...", "data": "负责数据 pipeline 搭建，要求熟悉 Spark、Flink..." } raw_exp = open("my_experience.txt", encoding="utf-8").read() for name, jd in jds.items(): resume = generate_resume(jd, raw_exp) with open(f"resume_{name}.md", "w", encoding="utf-8") as f: f.write(resume) print(f"已生成 {name} 版本")

跑完你会得到几份侧重点不同的简历。注意每份都要人工过一遍，尤其是技能栈部分——模型可能会根据 JD 把你没写过的技术也加进去。

5.2 怎么判断生成质量好不好

我自己的验收标准有三条：一是每段经历都有具体动作和结果，没有空话；二是 JD 里的核心关键词在简历里出现了至少一次；三是通读一遍没有让你觉得「这不是我」的句子。第三条最主观但也最重要——简历可以优化表达，但不能变成另一个人。

如果要做更客观的对比，可以把生成前后的简历分别让 GPT-4 打分：

def score_resume(resume, jd_text): response = client.chat.completions.create( model="gpt-4", messages=[ {"role": "system", "content": "你是技术面试官，根据 JD 给简历打分（1-10），指出三个最需要改进的点。"}, {"role": "user", "content": f"JD：{jd_text}\n\n简历：{resume}"} ], temperature=0.1 ) return response.choices[0].message.content

这个分数只能当参考，别太当真。模型打分有随机性，同一份简历跑两次可能差一两分。它的价值在于帮你发现明显短板，比如「项目经历缺少技术深度」这种反馈。

5.3 一个容易被忽略的细节：时间线一致性

批量生成时，不同版本的简历可能对同一段经历的时间描述不一致。比如 A 版本写「2021.03-2023.06」，B 版本写「2021.03-至今」。投不同公司时如果被背调发现时间线对不上，会很麻烦。我的习惯是把时间、公司名、职位这些硬信息单独存一个 JSON，生成时作为固定上下文注入，不让模型自由发挥。

import json facts = { "company": "XX 科技", "title": "后端工程师", "period": "2021.03-2023.06" } fact_str = json.dumps(facts, ensure_ascii=False) # 把 fact_str 拼进 user_prompt，并加一句「以下信息不可修改」

这个习惯是我被一次背调电话问懵之后养成的。当时两个版本的入职时间差了半个月，虽然最后解释清楚了，但那种尴尬不想再经历第二次。希望帮到你。

本文还有配套的精品资源，点击获取