企业官网建设流程全解析

• 数据集

导读

remoteintech.company（Remote In Tech）是一个社区维护的远程友好科技公司目录，其数据全部沉淀在仓库中以 Markdown 加 YAML Frontmatter 编写的公司档案中。本文以目录中的 Procurify 档案 为完整实例，逐层拆解一份公司档案从「字段定义 → 标签体系 → 页面渲染 → 社区校验」的完整生命周期，帮助读者理解如何阅读、编写并复用这类档案数据，同时掌握该目录项目的核心数据建模与构建原理。

一、档案全貌：procurify.md 的文件结构

在 Remote In Tech 仓库中，每家公司对应src/companies/目录下的一个.md文件，文件名即公司 slug。Procurify 的档案位于 src/companies/procurify.md，由两部分组成：

1. YAML Frontmatter（---之间的元数据）：机器的结构化信息，驱动目录的筛选、排序、标签与分类。
2. Markdown 正文（##小节）：面向人的描述内容，包括公司介绍、规模、远程政策、技术栈与申请方式。

该档案的 Frontmatter 字段如下：

正文则包含## Company blurb、## Company size、## Remote status、## Region、## Company technologies、## Office locations、## How to apply七个小节。这套结构并非随意约定，而是被 CONTRIBUTING.md 固化的社区规范，其要求与 procurify.md 的实际内容完全吻合。

二、Frontmatter 字段逐项解读：数据模型与合法取值

要理解每个字段的含义，需要结合仓库中的「标签唯一事实源」src/_data/labels.js 与贡献指南 CONTRIBUTING.md 中定义的合法值。

region：招聘区域

region: americas在 labels.js 中被映射为显示标签Americas。合法取值为worldwide、americas、europe、americas-europe、asia-pacific、other。Procurify 档案正文注明远程工作支持加拿大，属于美洲区域，与americas标签一致。

remote_policy：远程政策

remote_policy: fully-remote对应 labels.js 中的Fully Remote标签。合法取值包括fully-remote、remote-first、hybrid、remote-friendly。Procurify 在正文中自称 "all remote, fully distributed"，属于该目录中最彻底的远程形态——公司全员分布，没有强制集中办公点。

company_size：公司规模

company_size: medium在 labels.js 中定义为「51-200 employees」，与正文中「Company size: 100+」相互印证。合法取值从tiny（1-10 人）到enterprise（1000+ 人）共五档。

technologies：技术栈标签

technologies是一个数组，合法取值由 labels.js 定义，共 25 个规范 slug（如javascript、python、devops、docker等）。Procurify 档案声明了api、devops、javascript、python四项。

这里有一个值得注意的实现细节：api并不在 labels.js 的 tech 映射表中。根据 companyHelpers.js 中getTechLabel的实现return techLabels[tech] || tech;，以及 company.njk 中labels.tech[tech] or tech的模板回退逻辑，未知标签会原样显示为api而不是一个规范化的中文/英文标签。这反映了该目录「标签表为唯一事实源、未知值安全回退」的容错设计。

addedAt / updatedAt：时间字段

addedAt与updatedAt均为2020-11-01，说明该档案自 2020 年 11 月添加后尚未被维护者更新。按 CONTRIBUTING.md 的说明，这两个字段由维护者管理，社区贡献者在提交 PR 时不应自行填写。

三、正文七小节：Procurify 公司画像的完整继承

原档案正文的内容在站点上被完整渲染，逐节解读如下。

Company blurb：业务定位

Procurify 是领先的费用管理、采购与寻源（procurement）软件平台，数百家公司使用它跨部门与团队追踪、控制和分析开支，从而建立更好的开支管控与洞察。

这段描述由 src/companies/procurify.md 提供，是整份档案的信息核心。值得说明的是，它还被自动化地「二次利用」：根据 companies.11tydata.js，构建时会从## Company blurb小节截取正文、剥离 Markdown 标记（text→text，移除*、_、`），压缩空白后在 155 字符附近按句号/空格边界截断，自动生成页面的 meta description。也就是说，blurb 既是正文，又是 SEO 元数据的唯一来源。

Company size：100+

正文注明公司规模为 100 人以上，与 Frontmatter 的medium（51-200 人）标签一致。

Remote status：全远程、完全分布式

Procurify 是一家完全远程、完全分布式的公司，员工可以选择在任何自己最舒服的地方工作。这是目录中fully-remote政策类型的典型代表。

Region：加拿大

远程工作支持加拿大境内（加拿大地区）。与americas区域标签对应，也与其办公室所在地温哥华相吻合。

Company technologies：具体技术栈

正文列出的技术栈比 Frontmatter 标签更详细：ReactJS、Typescript、Docker、Python/Django、NodeJS、RESTful APIs。可以观察到两类信息的粒度差异：Frontmatter 的technologies用于目录级筛选聚合，因此只使用标签表内的规范 slug；而正文用于面试者了解实际工程栈，可以写得更具体。这种「标签归类 + 正文细化」的双层写法是高质量档案的推荐模式。

Office locations：温哥华（加拿大不列颠哥伦比亚省）

即便公司全远程，档案仍保留实体办公室信息，便于求职者了解公司实体归属。

How to apply：通过官网招聘页申请

Procurify 将所有空缺职位列在官网 careers 页面。在 company.njk 布局中，按钮链接的取值逻辑为careers_url or website：由于本档案没有单独声明careers_url，按钮会回退到 Frontmatter 的website字段（此处恰好就是 careers 页面地址），并按模板规则显示为 "Visit Website" 文案。

四、从 Markdown 到页面：档案数据如何被消费与渲染

一份procurify.md在构建时会被多个 Eleventy 集合与模板消费，这是理解该目录项目工程结构的关键。

集合（Collections）层面的聚合

src/_config/collections.js 定义了目录的各类视图：

• getAllCompanies（L24-L30）：按title字母序排序全部公司档案；
• getCompaniesByRegion（L50-L68）：按region字段分组，Procurify 归入americas组；
• getCompaniesByTech（L71-L91）：遍历每家公司 Frontmatter 的technologies数组做分组，因此 Procurify 会出现在api、devops、javascript、python四个技术浏览页下；
• getCompanyTags（L134-L194）：基于集合动态生成technology、region、remote-policy三类标签页及其公司列表。

这些集合在 eleventy.config.js 中通过eleventyConfig.addCollection(...)注册，并由 companies.11tydata.js 提供按档案计算的派生数据（meta description）。

模板（Layout）层面的渲染

公司档案统一使用 src/_layouts/company.njk 布局：

• 头部渲染标题与按钮（L9-L16）；
• region、remote_policy会渲染为可点击的分类标签，指向/browse/浏览页（L17-L22），标签文案来自全局数据级联的labels.*；
• 若technologies非空，渲染独立的Tech Stack区块，每个技术同样链接到对应浏览页（L29-L38）；
• 页脚在存在updatedAt时通过formatDate('MMMM D, YYYY')过滤器显示 "Last updated: November 1, 2020"（L54-L56）；
• 布局还声明了schema: Organization结构化数据头。

因此，社区维护者只需按规范填写 Markdown，分类标签、SEO 描述、浏览页聚合与结构化数据便全部自动生成，这正是该目录项目「以内容文件为唯一输入」的静态站点设计精髓。

五、社区校验与质量标准：档案如何被审查

CONTRIBUTING.md 明确了一套可复用的校验口径，Procurify 档案恰好是合规范例：

• 必填小节：## Company blurb、## Remote status、## How to apply三个标题必须存在（本档案全部具备），## Company size、## Region、## Company technologies为常用可选小节；
• 文件名与 slug 一致：slug: procurify对应文件procurify.md；
• 字段合法取值：region、remote_policy、company_size、technologies均有白名单校验（见 CONTRIBUTING.md 的 Valid Field Values 表格）；
• 自动化验证：涉及公司档案的 PR 会触发Validate Company ProfilesGitHub Action 自动检查并在 PR 上评论问题、阻塞合并；
• 收录标准：公司须直接雇佣员工、提供真正的远程岗位、属于科技行业且可核实信息。

这套机制保证了上千份档案（当前src/companies/目录下已积累数百个.md档案，构建时通过getFilteredByGlob('./src/companies/**/*.md')全量加载）在规模增长的同时保持字段一致性与可机器解析性。

六、使用建议与信息时效提示

以 Procurify 档案为参照，读者在使用这类社区维护的远程公司目录时应注意三点：

1. 以官网招聘页为准：目录档案由社区维护，存在滞后可能。从 Frontmatter 看，该档案addedAt与updatedAt均为 2020-11-01，尚未反映后续变化，申请时应通过其 careers 页面核实最新在招岗位与申请入口。
2. 利用标签体系筛选：在站点上可通过区域（Americas）、远程政策（Fully Remote）、技术（JavaScript / Python / DevOps / API）标签反向定位同类公司，其数据源正是本档案的 Frontmatter 字段。
3. 区分两类技术信息：Frontmatter 的technologies服务于目录聚合，正文的Company technologies服务于求职调研，阅读时两者互补、不可互相替代。

通过这份档案，既可以快速掌握 Procurify 的远程招聘画像，也能完整理解 Remote In Tech 项目「一份 Markdown 档案 → 结构化标签 → 自动生成浏览页与 SEO 元数据」的端到端数据流水线。

• 数据集