求职信字母生成器

按 Cover Letter 的四段结构拼出英文正文，顺带算词数、句长和 Flesch 可读性，把「写完了但不知道够不够好」这件事量化出来。

留空时该段自动省略，段落编号会顺延。

Dear Hiring Manager,

I am writing to apply for the Backend Engineer position at Northwind Logistics. I have spent the last four years building order and billing services in Go, PostgreSQL, Kubernetes, and the part of my work I enjoy most is the boring part: keeping a service fast while traffic doubles every quarter.

In my current role I cut p99 order-query latency from 820 ms to 190 ms by moving the hot path onto a read replica and adding two composite indexes. The change also cut monthly infrastructure spend by 18 percent, and it let the on-call rotation drop from weekly to monthly.

Before that I spent two years on a payments team, where I owned the reconciliation job end to end. It taught me that correctness matters more than cleverness when money is involved.

What draws me to Northwind Logistics is that your engineering blog describes a migration to event-driven fulfilment. I have already done that shape of work at a smaller scale, and I would like to do it again with a larger dataset.

I am available for an interview any weekday after 14:00 CST. Thank you for reading this far.

Sincerely,
Zhang Wei
句号词数句子判定

使用方法

五个单行框加一个多行框，填完点「生成求职信」或按 Enter（多行框里按 Ctrl/Cmd+Enter）。四步走：

  1. 在「姓名」填 Zhang Wei（示例默认值，9 字符）。这个名字会同时出现在称呼后的落款处，所以必须落在 2~40 字符内且含拉丁字母。
  2. 在「目标职位」和「公司名」填 Backend Engineer 与 Northwind Logistics，这两项会被塞进第一句和第四段，同一个公司名在正文里出现两次是刻意的——招聘方扫信时会找这个关键词。
  3. 在「量化成绩」填 cut p99 order-query latency from 820 ms to 190 ms。这一栏必须自带数字，因为求职信里唯一能拉开差距的就是数字；检测器会把不含数字的结果标红提示。
  4. 「补充经历」可留空。填了会作为独立第三段插在成绩段之后，默认示例是一段支付对账经历。填完点生成，下方会出现词数、句长表和 Flesch 分数。

页面打开时下方已经有一封完整的示例信（服务端直出，JS 未执行也在），点「载入示例」随时还原。这封信的词数、句长、Flesch 分数和下面句长表里的每一行都是从同一份数据算出来的，求职信字母生成器的体检面板不是估的，是逐句数出来的。

能解决什么

英文求职信难的地方不在于凑不出句子，而在于不知道自己的稿子是长是短、是难读还是好读、有没有全是弱动词。求职信字母生成器把这两件事分开处理：前半段负责按固定结构拼出能用的骨架，后半段负责体检。

场景一：海投同一岗位，替换公司名就能改一封信，不必每次重写。这里公司名在正文出现两次，所以改一个字段能覆盖开头和动机段。

场景二：写完一封 600 词的信，不知道 recruiter 会不会读不完。这里的体检会直接告诉你词数、按每分钟 200 词估算的阅读秒数、以及 Flesch 分数落在哪个学段。

场景三：稿子里全是 "I was responsible for..." 这种被动句。这里会逐句列出被动结构和弱动词的位置，让你知道要改哪一句。

本页不做的事：不生成简历本体。简历里的教育背景、工作时间线、技能分级表都不在求职信里，写进去反而稀释重点，那部分交给 简历生成。也不做多语言版本——模板句式全部是英文，中文求职信的信封与称呼规则完全不同，套这个模板会出错。

原理和变量

四段结构。生成的不是一整块文字，而是四个固定功能的段落：

  1. 称呼 + 目的句：Dear Hiring Manager, 加一句"我申请贵司的 X 职位"。招聘方最先找的就是这句话，所以放最前面。
  2. 能力段：把技能栈和年限拼进去，末尾接一个"我喜欢做的其实是无聊的那部分"式的具体态度句，避免通篇自夸。
  3. 成绩段：把量化成绩原句嵌入，再补一句副作用收益（本例是"值班从每周降到每月"），这一句比主成绩更能打动面试官。
  4. 动机段 + 结尾段：先说为什么选这家公司（要求填入公司名的具体理由位），再说可面试时间，最后落款。

词数口径。用 text.trim().split(/\s+/) 计数，空白连续段算一个分隔符。这与 Word 的字数统计基本一致，但和浏览器自带的 Intl.Segmenter 分词结果会差几个——后者会把 don't、state-of-the-art 这类带连字符和撇号的词算成一个或两个，取决于词表。为避免"同一个词数在不同工具里不一样"的困惑，本页统一用空格切分，并把口径写在这里。

Flesch Reading Ease。公式是 206.835 − 1.015 × (词数/句数) − 84.6 × (音节数/词数)。音节数按元音组估算，词尾哑 e（长度大于 3 且已有元音）不计一个音节。示例信实测：词数 197、句数 11、音节 298，平均每词 1.51 个音节，Flesch = 60.7，落在"高中毕业到大学"区间——英文母语者一眼能读完，符合简历筛选场景。

句长阈值 35 词。这不是从规范里来的经验值，而是从示例信反推的：11 句里最长的一句 38 词，正是那句从 I have spent 拖到 every quarter 的能力段。它的信息密度其实不低，但读者要在中间记住四个技术名词，负担偏重，所以 35 词作为提醒线。

被动语态正则的坑。检测式写成 \b(am|is|are|was|were|be|been|being)\s+(\w{2,}(?:ed|en)|不规则表)。词干只要求 2 字母以上，是因为 given、taken 这类过去分词本身很短，卡成 4 字母会漏判。同时必须配一张假被动排除表：is involved、is available、was based 都是系表结构不是被动语态，不排掉就会满屏误报。实测三条反例 is that / was in / is involved 全部被正确排除，三条正例 was rewritten / were given / been fixed 全部被抓出。

量化表达的正则。要求数字后面必须跟单位或百分号：\b\d[\d,.]*\s*(%|percent|ms|hours|weeks|months|...)\b。不加单位约束的话，14:00 会被切成 14 和 00 两个"量化成果"，纯属噪声。示例信实测命中 3 处：820 ms、190 ms、18 percent。

完整示例

下面全部数字来自页面默认那封信（数值仅作演示），控件默认值、这里的示例、下面句长表逐行一致：

  • 词数 197，字符数 1123（含空格与换行），非空白字符 921。
  • 段落 7 段（称呼 / 能力 / 成绩 / 补充 / 动机 / 结尾 / 落款），平均每段 28.1 词。
  • 正文句数 11 句，正文词数 194，平均句长 17.6 词。
  • 超 35 词的句子 1 句，最长句 38 词。
  • Flesch = 60.7，音节 298，每词 1.51 个音节。
  • 被动语态 0 处，弱动词 0 处，带单位量化表达 3 处。
  • 按每分钟 200 词的常见扫读速度，全文约 59 秒读完。

对照着改：把「量化成绩」那一栏删掉数字再生成一次，词数会掉到 190 上下，但体检面板的「量化表达」会变成 0 处并给出警告——这正是这个字段存在的意义，它逼你把成果写成可验证的样子。求职信字母生成器判断一篇稿子能不能用，看的就是这几项：篇幅在 150~400 词、平均句长低于 35 词、被动语态 0 处、量化表达至少 2 处。

输入范围与对照表

五个字段各有硬边界，越界不会静默截断，而是直接告诉你哪个字段超了多少：

字段允许长度示例值越界时会发生什么
姓名 Name2~40 字符，且至少 1 个拉丁字母Zhang Wei（9）纯中文姓名被拒，因为拼出的称呼与落款会是空的
目标职位2~60 字符Backend Engineer（16）超 60 截断会让第一句语法崩，直接报错
公司名2~60 字符Northwind Logistics（19）同上，动机段会缺主语
技能栈2~80 字符Go, PostgreSQL, Kubernetes（26）空值会让能力段只剩年限
量化成绩8~160 字符，且需含数字cut p99 order-query latency…（49）不含数字时生成成功但体检面板标红警告
补充经历20~400 字符，可留空Before that I spent two years…（138）留空整段省略；不足 20 字符按留空处理

Flesch 分档与本页的建议读法：

分数区间对应学段（英文母语者经验）求职信场景怎么办
90~100小学几乎不会出现，真出现了说明全是短句堆砌，专业度不足
80~89中学句子偏短，理工科简历可接受，文案岗会显得单薄
70~79大一至高二最舒服的区间，读者不费力
60~69高中毕业至大学示例信落在这里（60.7），正常可用
50~59大学句子偏长，建议拆句
40 以下难读技术词堆得太密，重写能力段

下方句长表逐句列出词数与判定，表头四列：句号、词数、句子、判定。首屏 12 行，点「加载更多」每次加 12 行；超过 12 句的信（补充经历写长了会这样）才能看到全表。

边界与精度

词数上限来自哪里。没有硬上限，但超过 400 词面板会给出提醒——这是英文求职信的常见上限，示例信 197 词处在中位。低于 150 词会提醒太短，因为 Cover Letter 的作用是补充简历没讲清的部分，几十词连这个作用都撑不住。

Flesch 是估算，不是测量。音节靠元音组数猜，business 这类词的音节数取决于词表（business 实际 3 个音节，元音组法会算成 2 个），所以同一封信在不同工具里可能差 0.5~2 分。它适合看趋势（改稿前后比较），不适合当合规指标。

句长统计有两次口径差异。句号切分用 [.!?](?=\s|$)，所以 U.S. 这类带点缩写会被误切成一个"句"。示例信不含缩写，检测到超长句时建议你手工确认一次。真要处理缩写，得引入缩写白名单，这里不做，因为一张白名单表的体积就够再写一个工具了。

被动语态检测是启发式，不是语法分析。它只认"be 动词 + 过去分词"的表面结构，识别不了 He was gone 这类系表加形容词的情况（虽然排除表能盖住常见几个），也识别不了省略 be 的被动（The service rewritten overnight）。它的作用是提醒你回头看一遍，不是判定你写错了。示例信实测 0 处被动，这不是因为规则严格，而是因为每句都写了主语 I。

字符长度按 UTF-16 计。中文姓名填进「姓名」框会被拒绝，但如果放进「补充经历」框，一个汉字算 1 个字符、读起来却比 1 个英文字母长得多。补充经历以英文写为准，混排中文会让 Flesch 音节估算失真（汉字没有元音，会被当成 0 或 1 个音节）。

模板句是死的，变量是活的。五个字段替换进去后，段落骨架和衔接句不会变。所以同一份模板生成的信，用词习惯会高度相似——批量投递时这可能是优点（快），也可能是缺点（HR 一眼看出模板）。真要个性化，改「量化成绩」和「补充经历」两栏就够了，改动成本最低而效果最明显。

常见问题

为什么叫「求职信字母生成器」，它生成的是字母吗？

不是。这个名字来自英文原名 cover letter generator 的直译，cover letter 是「求职信」，指 accompanies a resume 的那封陈述信，不是「生成字母」。站内同分类下还有随机字母生成器、字母统计等完全不同的工具，本页做的是英文求职信正文拼装。名字沿用了工具库的注册名，语义以本页说明为准。

生成的信能直接投吗？

不能直接投，但可以直接改。模板只提供骨架，四段衔接句是通用表达，真正决定成败的是你填进去的量化成绩和对公司的具体理由。示例里"820 ms 降到 190 ms"是编的演示数字，投递前必须换成你自己的真实数据。另外 Cover Letter 通常需要针对每家公司单独改，批量群投同一封信在多数招聘流程里是减分项。

称谓应该写具体人名还是 Dear Hiring Manager？

查到名字就写名字（Dear Ms. Alvarez,），查不到才退回 Dear Hiring Manager,。本页默认用后者，因为模板无法判断你是否知道 recruiter 姓名。正文里不要写 Dear Sir or Madam，这种句式在英语母语职场里显得疏远。

词数比目标少会被判失败吗？

不会，只提示。低于 150 词或超过 400 词时面板会给提醒色，但生成结果照常输出——因为不同国家、不同年限的目标区间差别很大，机器不该替你做这个决定。示例信 197 词落在 150~400 的中位偏下，够用。

为什么我的信被标出被动语态，但我读着不像？

大概率是系表结构被误判了，比如 is involved（"钱牵涉其中"）、is available（"我周三有空"）这类。检测器内置了 20 个常见假被动词的排除表，但英语形容词后缀是 -ed 的词远不止这些。如果提示出现在你认为没问题的地方，按原句自查一遍即可，不必照着改。

Flesch 60 分算好还是不好？我不会算这个。

对求职信来说 60~79 都属正常，示例 60.7 属于"读者不费力"的下沿。真正要警惕的是低于 50：那说明你的句子普遍在 25 词以上且技术词密集，HR 扫读时会跳。这个分数不用你手算，页面每次生成后直接给。

能生成中文求职信吗？

不能。模板句式全部是英文，中文求职信在称呼（"尊敬的 X 先生"）、自我评价用词、结尾敬语上规则完全不同，套用英文骨架会产出不通顺的东西。中文简历与求职信模板请用 简历生成，那里的字段是按国内投递习惯设计的。

我的信息会不会被传出去？

不会。姓名、职位、公司名这些只作为字符串拼进 DOM，没有任何 fetch、XMLHttpRequest 或表单提交，刷新页面即消失。你可以在浏览器开发者工具的 Network 面板里自查，整个交互过程是零请求。这封信往往包含真实姓名和求职意向，更不该过第三方服务器。

相关工具

  • 简历生成——简历本体在这里生成，本页只做 Cover Letter，两者配合才是完整投递材料。
  • 简历摘要生成器——简历顶部的 3~4 行自我概述，和求职信开头段作用相近但长度受限。
  • FleschKincaid计算器——只算可读性不生成内容，要单独核对别的英文文案时用。
  • LinkedIn标题生成器——线上档案的 headline 也要和这封信的口径一致，两边说法不同会露馅。
  • Cold邮箱生成器——主动挖掘的冷邮件是另一套写法，跟投递用的求职信不是一回事。
  • 邮箱主题行生成器——投递附件的邮件主题行，常和正文一起被改。
  • SEO与营销分类——同分类 85 个工具，还有隐私政策、服务条款、FAQ 结构化数据等合规文本生成器。