企业官网建设流程全解析

• 数据集

导读

kea 是 remote-in-tech 远程友好型科技公司目录中收录的一家餐饮行业对话式 AI 公司，其档案位于 kea.md。本文以该档案为完整样本，逐字段拆解这份远程职位目录中公司档案的 frontmatter 数据模型与 Markdown 正文规范，并结合仓库中的标签体系、集合（collection）构建与页面布局源码，还原「一条公司数据从 Markdown 档案到可浏览的远程职位页」的完整链路。读完本文，你将掌握本目录的字段取值规则、标签分类逻辑，以及如何按规范为一家远程公司新建档案。

档案本体：kea 的完整数据快照

kea 的档案由两部分构成：以---包裹的 YAML frontmatter（机器可读的结构化元数据）和其后的 Markdown 正文（面向读者的自然语言信息）。二者共同决定了该档案在站点上的呈现方式与在浏览、检索系统中的归属。

Frontmatter 字段与取值

以下是 kea 档案 frontmatter 的原始内容：

--- title: "kea" slug: kea website: https://kea.ai careers_url: https://careers.kea.ai region: americas remote_policy: remote-friendly company_size: small technologies: - javascript addedAt: 2022-04-26 updatedAt: 2022-04-26 ---

逐字段解读如下：

值得注意的是，kea 正文中的「Company technologies」一节列出了JavaScript / AWS / PostgreSQL / Mocha / Python / Cypress / Chai / Twilio / Docker共 9 项技术栈，而 frontmatter 的technologies数组只收录了javascript。这是本目录数据模型的一个关键设计：只有进入受控白名单的技术标签才会被纳入索引与浏览体系，正文中的长列表用于展示完整栈信息，白名单标签用于结构化归类。

Markdown 正文的必需章节

kea 的正文完整覆盖了 CONTRIBUTING.md 规定的三个必需章节：

• Company blurb——"kea builds conversational AI for restaurants."（一句话业务定位，同时被自动抽取为页面的 meta description）；
• Remote status——"Fully-remote. Must be in North or Latin America."（远程实践方式与地域限制）；
• How to apply——指向招聘页的申请入口。

此外还包含了可选的Company size（20-50）、Region（North and Latin America）、Company technologies与Office locations（California, USA）章节。kea 的案例说明了一个典型规律：即便公司在欧美均设有实体办公地点，其招聘仍可在全远程模式下进行，但地域范围受限（仅北美与拉美）——这正是remote_policy: remote-friendly与region: americas两字段的组合语义。

字段合法性：标签白名单与数据契约

frontmatter 中的region、remote_policy、company_size、technologies并非自由文本，而是受控枚举。仓库中的 labels.js 是这套标签体系的唯一事实来源，定义如下：

region: { worldwide, americas, europe, americas-europe, asia-pacific, other } remotePolicy: { fully-remote, remote-first, hybrid, remote-friendly } companySize: { tiny(1-10), small(11-50), medium(51-200), large(201-1000), enterprise(1000+) } tech: { javascript, typescript, react, nodejs, python, ruby, go, java, php, rust, dotnet, elixir, scala, swift, cloud, devops, docker, kubernetes, mobile, data, ml, sql, postgres, nosql, search }

这套白名单同时被两处消费：Nunjucks 模板通过全局数据级联以labels.*形式读取，JavaScript 侧则通过 companyHelpers.js 重新导出后供 collections.js 使用。kea 的取值全部命中白名单：region: americas、remote_policy: remote-friendly、company_size: small、technologies: [javascript]，属于完全合规的档案。

从源码结构看，白名单之所以如此设计，是因为它支撑了三个核心浏览维度的稳定分页与计数（count统计），自由文本会破坏分组聚合的确定性。这也是为什么正文中出现的 PostgreSQL、Mocha、Twilio 等未收录技术不会进入technologies数组——它们没有被定义标签。

渲染链路：一条档案如何变成可浏览的页面

布局与页面组装

companies.json声明了所有公司档案统一使用company布局（对应 company.njk）。该模板的核心逻辑：

• 优先显示careers_url对应的「Apply Now」按钮，否则退化为website的「Visit Website」；
• 根据region、remote_policy渲染可点击的标签，分别链接到/browse/{region}/与/browse/{remote_policy}/浏览页；
• 遍历technologies数组渲染 Tech Stack 标签，链接到/browse/{tech}/；
• 依据updatedAt展示「Last updated」日期（经formatDate过滤器格式化为MMMM D, YYYY）。

以 kea 为例，页面上会呈现「Americas」区域标签、「Remote Friendly」政策标签以及「JavaScript」技术标签三个浏览入口，配一个指向careers.kea.ai的「Apply Now」主按钮。

meta description 的自动生成

companies.11tydata.js 是公司档案的共享计算数据层。它为所有未显式设置description的档案自动生成 SEO meta 描述：用正则定位## Company blurb标题，抽取其后的正文段落，清洗掉 Markdown 链接、强调符号与多余空白，再截断至约 155 字符（优先在句号处截断）。kea 的 blurb 较短，会被完整保留为页面描述，这就是机器可读数据与正文自然语言衔接的自动化环节。

集合聚合与浏览页

eleventy.config.js 注册了companies、featuredCompanies、recentCompanies、companiesByRegion、companiesByTech、companyTags等集合。其中：

• getCompaniesByRegion以region字段为键将全部约 800 家档案分组——kea 会落入americas组；
• getCompaniesByTech以technologies数组为键分组——kea 会因javascript标签出现在 JavaScript 技术浏览页；
• getCompanyTags则汇总全部档案生成带count统计的标签清单，并按数量降序排列。

由此可以推断：remote_policy: remote-friendly让 kea 出现在「Remote Friendly」政策浏览页；company_size: small供按规模筛选（当前主要由标签体系支撑展示）。一条档案的字段值，决定了它在多个浏览维度中的可见位置。

实操：按规范为远程公司新增档案

若要将一家类似 kea 的公司加入目录，按 CONTRIBUTING.md 的流程操作：

1. 在src/companies/下创建{slug}.md，文件名必须与 frontmatter 的slug一致；
2. 按模板填写 frontmatter，并补齐## Company blurb、## Remote status、## How to apply三个必需正文章节；
3. 运行npm run build验证构建（该命令会先清理dist、src/_includes/css、src/_includes/scripts，再执行 Eleventy 生产构建，最后用 pagefind 生成站内搜索索引，详见 package.json）；
4. 提交 Pull Request，由「Validate Company Profiles」自动化校验机器人审查字段合法性与内容完整性。

校验要点包括：region、remote_policy、company_size、technologies必须命中 CONTRIBUTING.md 表格中的合法值；careers_url必须指向公司自己的招聘页而非销售页；档案需具备有意义的内容。addedAt/updatedAt由维护者管理，贡献者不应在 PR 中填写。

总结

以 kea 档案为窗口可以看到，remote-in-tech 目录的每条公司数据都遵循「受控枚举的 frontmatter + 结构化正文」双重契约：白名单字段（region / remote_policy / company_size / technologies）驱动标签聚合与浏览分页，正文章节驱动页面展示与 SEO 描述自动生成，最终由 company.njk 布局与各集合统一渲染输出。理解这套模型，既能快速读懂目录中的任意一家公司档案，也能按照同一套规范贡献新的远程公司条目。

• 数据集