使用方法
- 先填事实字段。示例：职位 后端工程师、专注领域 数据管道与实时可视化、技术栈 Python、Go、ClickHouse、Kafka、可验证事实 主导过日均 2 亿行日志的实时聚合链路、年限 8、协作意愿 欢迎交流数据架构。
- 选字数档位。示例选「标准档 60~100 字」。四档是本页的核心维度：同一组字段，一句话档给 1 句，简历档给 4 句，长文档给 6 句。
- 点「生成简介」，或按 Enter。结果区给出四行分句式纯文本，下方逐行标注每句的字素簇字数（示例 20 / 35 / 19 / 15 字），并给出合计 89 字（去掉换行符）。
- 看达标徽标：89 字落在标准档 60~100 区间内，显示绿色「符合标准档」。如果选了简历档而字段不够，页面会提示「当前字段撑不到 120 字，请补充可验证事实」而不是硬凑。
- 要拿去贴到具体平台，用「复制简介」；要横向比对四档字数，用「加载更多」展开对照表或导出 CSV（带 BOM）。
这个简介生成器能解决什么问题
写简介最常见的卡点不是文笔，是不知道写多少字。同一个「后端工程师」，写在 GitHub bio 里要 30 个字符，写在简历个人概述里要 150 字，写在「关于我们」页要 400 字。多数人凭感觉写，写完发现超限只能删，删完又觉得信息不够。
第二个卡点是写出来的内容没有可验证的事实。「热爱技术、追求极致、不断学习」这类句子放在谁的简介里都成立，等于没写。本页的结构强制第 3 段是「可验证事实」——你必须填进一个带数字的句子（日均 2 亿行、8 年、5 个项目），填不出来就说明你对这段经历还没有提炼。这一栏留空时页面会直接告诉你缺了什么。
第三个卡点是字数统计口径混乱导致的「明明没超」。含 emoji 的简介在不同工具里显示的长度不一样，你按 A 工具的数字发到 B 平台就超了。本页用 Intl.Segmenter 按字素簇统计，同时把各平台按字符（码元）计的数字也算出来，两者的差额明确告诉你。
本页与同类页面的机制差异必须说清，因为它决定了你该用哪一个。站内有两个直接相关的页面：随机简介（/suijigongju/suijijianjieshengchengqi/）靠随机词表拼装，完全不需要你填任何东西，产出的是虚构人设，适合起网名、占位、批量造测试数据；虚拟简介同理，产出的是「虚拟身份」的配套介绍。本页不使用任何随机数 —— 逻辑是「句式模板 + 你填的事实字段」，同样输入永远得到同样输出，可以逐版对比、可以拿去 A/B、可以放心写进正式材料。这个机制差别比功能列表重要得多。
本页也不做：不做平台定制（要 Instagram 风格或 DatingApp 风格请用对应页面，那两页有各自的语调和字段）；不做 emoji 装饰与营销话术（输出是纯文本分句，不加任何装饰符号，你可以自己加）；不做 SEO 关键词堆砌（那是关键词组合工具的职责）；不做英文简介的分词处理（Intl.Segmenter 用 'zh' locale 切分，英文按空格分句的规则需要另设 locale）。
原理与规则说明
字数按字素簇统计，这是本页的技术核心。「字数」这个词有四种可能的口径，混用就会算错：
- UTF-16 码元（
String.prototype.length）：JavaScript 最常见的写法，也是最不可信的。任何非 BMP 字符（绝大多数 emoji、扩展汉字、罕见姓氏用字）占 2 个码元，所以'👍'.length === 2，而人眼看它是 1 个字。 - 码点（
[...s].length）：把代理对合成 1 个，但仍会把 ZWJ 连接序列拆开。实测'👨👩👧👦 家庭'的码点数是 10，而人眼看到的是 4 个字（1 个家庭序列 + 空格 + 2 个汉字）。 - 字素簇（
Intl.Segmenter，granularity: 'grapheme'）：唯一等于人眼所见「字」的口径。同一串的实测值是 4。本页全部字数都用这个口径。 - UTF-8 字节（
TextEncoder）：用于数据库列宽、短信计费、流量估算，跟「字数」完全不是一回事，不可混用。
差距有多大，实测一组对照：'点赞 👍🏽 挥手 👋🏻' 的码元数是 15、码点数是 11、字素簇数是 9 —— 同一个字符串三种口径差 6，接近 50%。含国旗的 '🇨🇳🇯🇵' 更极端：码元 8、码点 4、字素簇 2，差 4 倍。
为什么不能静默降级。Intl.Segmenter 的浏览器支持是 Chrome / Edge 87+、Safari 14.1+、Firefox 125+（2024 年 4 月才进入 Firefox Stable 正式版）。在不支持的浏览器里，Intl.Segmenter 整体是 undefined，直接调会抛异常。本页的处理是回退到码点口径，并在结果区显式标注「当前浏览器不支持 Intl.Segmenter，已按码点统计，emoji 组合序列会被多数」。原因是：默默换个口径继续报数字，比明确告知用户「这个数偏大了」危险得多 —— 前者会让用户拿着错的数字去卡平台上限。
字素簇的一个实现陷阱：Intl.Segmenter.prototype.segment() 返回的不是字符串数组，而是 SegmentData 对象数组，字符串在对象的 .segment 属性上。写成 [...seg.segment(s)].join('') 会得到一串 [object Object]。正确写法是取出 .segment 再 join —— 这是本页实现里最容易写错的一步，也是本页必须自己数一遍字符而不能信某些现成库的原因。
句式骨架是固定的四段：[身份定位] + [专注领域/技术栈] + [可验证事实] + [协作意愿]。四档的区别只在取哪几段、每段写多细：一句话档只取第 1 段并压成一句；标准档取第 1、4 段（身份 + 意愿）；简历档四段全取；长文档在四段之外增加「方法论」与「当前关注」两段，总计 6 段。骨架固定的好处是输出可预测，你每次都知道第 2 行会是什么。
字段护栏的具体数字：职位 30 字、专注领域 24 字、技术栈 70 字（按「最多 5 项、每项 12 字」折算，用顿号分隔）、可验证事实 40 字、协作意愿 20 字、年限 0~60 的整数。这些上限不是随便定的 —— 它们保证单段不会长到把整档撑爆，比如技术栈 5 项 × 12 字 = 60 字，加上「熟悉」二字正好落在 62 字左右，标准档还放得下；如果允许无限制填，一句「熟悉 Rust / Go / Java / Python / C++ / Kubernetes / Kafka / ClickHouse / Flink / Spark」就能把标准档挤爆。
裁剪用整行保留式，不按字数硬截。理由是硬截会把句子砍成半句（示例里按 40 字硬截会得到「后端工程师 · 专注数据管道与实时可视化熟悉 Python / Go / Cli」，这种残句贴出去很尴尬）。本页的逻辑是逐句累加，加下一句会超上限就停，因此每一句都是完整的。
遵循的规范：字素簇切分依据 Unicode 标准的 UAX #29「Unicode Text Segmentation」中的 Grapheme Cluster Boundary 算法，Intl.Segmenter 是 ECMA-402 定义的宿主接口；平台上限取各产品当前的公开限制（GitHub bio 160 字符、X/Twitter bio 160 字符、LinkedIn about 2600 字符、Instagram bio 150 字符）。
完整示例（数值仅作演示）
示例条件：职位「后端工程师」、专注领域「数据管道与实时可视化」、技术栈「Python、Go、ClickHouse、Kafka」、可验证事实「主导过日均 2 亿行日志的实时聚合链路」、年限 8、协作意愿「欢迎交流数据架构」，标准档。逐项算下来：
- 第 1 行「后端工程师 · 专注数据管道与实时可视化」= 20 字（码元也是 20，两者相同说明这段纯 BMP 字符）；
- 第 2 行「熟悉 Python、Go、ClickHouse、Kafka」= 35 字；
- 第 3 行「主导过日均 2 亿行日志的实时聚合链路」= 19 字；
- 第 4 行「欢迎交流数据架构与可观测性实践」= 15 字；
- 四行合计含 3 个换行符 = 92，只算文字 = 89 字；
- 89 落在标准档 60~100 区间 → 符合标准档，且不足 120，所以选简历档时会提示字段不够；
- 换成一句话档时，只取第 1 段的「后端工程师，专注数据管道」= 12 字 —— 低于 20 的下限，页面会提示偏短；
- 若把技术栈换成含 emoji 的「Python、Go 🛠️、ClickHouse」，字素簇仍是 5 个技术名，但平台字符数会多 1，因为 🛠️ 占 2 个码元。
这些数字与下方对照表、以及「载入示例」后生成的结果区完全同源，可以逐位核对。其中最值得留意的是 89 这个数比直觉少：很多人凭感觉觉得这段「挺长的」，但按字素簇一数字只有 89，离简历档的 120 还差 31 字 —— 这就是本页存在的意义。以上数值仅作演示。
输入范围与对照表
下表列出四档的字数区间、句数与本例实测值。默认显示 4 行，点「加载更多」会追加「平台上限对照」与「口径对照」两组共 20 行，可导出成 CSV（带 BOM，Excel 直接打开不乱码）。当前选中的档位会高亮。
| 档位 | 目标字数 | 句数 | 本例实测 | 适用位置 |
|---|---|---|---|---|
| 标准档（当前） | 60~100 | 2~4 | 89 字 | 个人主页简介、GitHub bio |
| 一句话档 | 20~40 | 1 | 12 字（偏短） | 社交资料末行、App 副标题 |
| 简历档 | 120~200 | 4 | 89 字（不足） | 简历个人概述、LinkedIn about |
| 长文档 | 300~500 | 6 | 不足 | 个人介绍页、关于我们 |
字数很长的四档差异说明：同样这六个字段，一句话档 12 字、标准档 89 字，差 7.4 倍。这不是同一段文字的「详略版」，而是四种不同的文体：一句话档是一句定语，标准档是两到四句的陈述，简历档要求可验证事实，长文档还要交代方法论。选错档位比写得好不好影响更大。
平台上限（字符口径，不是字素簇口径）：
| 平台 | 字段 | 上限（字符） | 本页 89 字示例折算 |
|---|---|---|---|
| GitHub | bio | 160 | 占 56%，放得下 |
| X / Twitter | bio | 160 | 占 56%，放得下 |
| bio | 150 | 占 59%，放得下 | |
| about | 2600 | 占 3.5%，远低于上限 |
「本页 89 字示例折算」这一列假设示例里没有非 BMP 字符，此时字素簇数与字符数相等。如果简介里有 3 个非 BMP emoji，平台看到的字符数就是 89 + 3 = 92。换算公式：平台字符数 = 字素簇数 + 非 BMP 字素簇个数。
输入范围、边界与精度说明
- 六个字段的长度上限是硬边界：职位 30、专注领域 24、技术栈 70、可验证事实 40、协作意愿 20、年限 0~60 整数。超长会被截断并提示，不是静默丢弃也不是报错拒绝 —— 你填了 45 字的职位，页面会用前 30 字并告诉你截掉了 15 字。
- 技术栈最多 5 项，第 6 项及以后会被忽略并提示「技术栈最多 5 项，已忽略第 6 项及以后」。每项还会再单独截到 12 字。
- 年限必须是 0~60 的整数，step 设为 1，填 8.5 会被原生校验拦下，页面也会再判一次。填负数或超过 60 会明确提示允许范围。
- 字段全空的处理：职位和专注领域是必填，两者至少填一项才能生成，否则页面会告诉你缺哪个字段。年限、技术栈、协作意愿是选填，缺了不影响生成，但生成结果会明显更短 —— 页面会在结果区提示「当前字段较少，输出仅 X 字」。
- 「可验证事实」留空时的处理：页面不会替你编一句。它会跳过第 3 段继续生成，然后提示「未填可验证事实，输出缺少最关键的一段」。这是刻意的：编造事实比留空危害更大。
- 不会为了凑字数而重复或注水。选了长文档档而字段不足时，页面直接说「当前字段撑不到 300 字」，并告诉你最缺哪一段。这是本页与那些「自动扩写到指定字数」的生成器最大的区别 —— 扩写出来的都是废话。
- 档位判定用的是「符合 / 偏短 / 超出」三态，不是精确匹配。落在区间内显示绿色，低于下限显示黄色「偏短」，高于上限显示红色「超出」，并告诉你超了多少。避免用户为了差 1 个字去反复改字段。
- 不使用随机数，输出可复现。这是本页与站内那两个随机 / 虚拟简介页最本质的区别。代价是同一个输入每次都一样；好处是你可以只改一个字就看到差异，逐版对比自己的简介，而不是每次刷新都换一批内容。
常见问题
为什么我的简介明明只有 89 字，贴到平台却提示超长？
最可能是两个原因。一是平台按字符（码元）计，你按字素簇计：每个非 BMP emoji 占 2 个码元，一个 👨👩👧👦 家庭序列占 14 个码元但人眼只算 4 个字，含这类内容的简介会大幅超出你的预期。换算公式是「平台字符数 = 字素簇数 + 非 BMP 字素簇个数」。二是平台还会计入换行和空格，而很多人只数字符。本页的输出区把这两个数都列出来，复制前对一下就知道差在哪。
选了长文档档，为什么它不帮我把简介扩写到 500 字？
这是刻意的设计。自动扩写出来的内容必然是废话 —— 「我深知持续学习的重要性」「我相信团队协作的力量」这类句子加到 500 字里，读者不会觉得信息更多，只会觉得敷衍。本页的做法是告诉你「当前字段撑不到 300 字，最缺的是第 3 段可验证事实」，让你去补真实内容。如果你确实需要一个长文档，那需要的是更多事实（做过哪些项目、解决过什么问题、量化结果如何），而不是让机器帮你注水。
「随机简介」和这个有什么区别？我该用哪个？
机制完全不同。随机简介那页用随机词表拼装，不需要你填任何东西，产出的是虚构人设，适合起网名、占位、批量造测试数据。本页用「句式模板 + 你填的事实字段」，不含任何随机数，同样输入永远得到同样输出，可以逐版对比、可以拿去 A/B、可以放心写进正式材料或简历。判断标准很简单：要写真实的自己 → 用本页；要造假的、随机的、批量生成的 → 用那页。
为什么有人的简介里能写出很长的故事，我写出来总是很干？
差的不是文笔，是可验证细节的密度。比较一下：「熟悉 React」和「把某电商站的首屏时间从 3.2 秒压到 1.1 秒，改动只用了两个组件」—— 后者信息量是前者的十几倍。本页第 3 段的「可验证事实」就是逼你填这一句。填的时候问自己三个问题：数字是多少？规模多大？前后对比如何？三个里能答出两个，这句话就有价值。
为什么我的浏览器上字数显示得比同事多？
如果你们其中一个用的是 2024 年 4 月之前的 Firefox 版本，那边还没有 Intl.Segmenter，会回退到码点口径，emoji 会被多数。页面在这种情况下会在结果区明确标注「已按码点统计，emoji 组合序列会被多数」，不会默默换口径。Chrome 87+、Edge 87+、Safari 14.1+ 不受影响。想要一致口径，换到这几个浏览器即可。
技术栈写了 8 个，为什么只保留了 5 个？
护栏规定最多 5 项、每项 12 字。这不是随意定的：一句话档的整档上限才 20~40 字，标准档 60~100 字，如果技术栈不加限制，「熟悉 Rust / Go / Java / Python / C++ / Kubernetes / Kafka / ClickHouse / Flink / Spark」这一句就 50 字出头，加上其他两段直接把标准档挤爆。所以页面会主动截断并告诉你忽略了第几项。真的需要都写上，那就该用长文档档，并把技术栈放到第 5 段而不是第 2 段。
输出里能加 emoji 吗？
可以，但要注意计数。纯文本的「·」分隔符已经在用了，emoji 你可以自己加。关键是这个加法会让平台字符数按 2 递增：加 3 个非 BMP emoji，本页显示的字素簇数只按人眼算 +3，而平台字符数 +6。GitHub bio 只有 160 字符，加 emoji 前最好先用本页的「复制简介」核对一遍平台字符数那栏。
这个页面会把我填的职位、事实这些信息传到哪吗？
哪也不去。生成逻辑就是字符串拼接加上一个 Intl.Segmenter 循环计数，没有 fetch、没有 XHR、没有第三方库、没有 localStorage 持久化。你可以在开发者工具的 Network 面板里确认：页面加载后不再发出任何请求，刷新一下输入就清空了。简历信息属于敏感内容，这一点值得确认一下。
相关工具
- 随机简介生成器：随机词表拼装虚构人设，无需填字段，适合批量占位；本页是真实事实 + 四档字数。
- Instagram 简介生成器：带平台语调和 emoji 习惯，产出直接适配 150 字符上限。
- DatingApp 简介生成器：交友场景的语料与字段完全不同，需要的是另一套模板。
- 字数统计工具：粘贴任意文本查它自己的字数，可用来复核本页输出的数字。
- 字符数统计工具：按码元计的字数，正好对应各平台的上限口径，与本页的字素簇口径互为对照。
- 标语生成器：需要的是一句浓缩口号而不是分句介绍，输出形态不同。
- SEO与营销：查看全部 SEO 与营销工具。