remoteintech.company 公司档案深度解析：Ollie Order 的远程友好技术栈与招聘画像

这是一篇围绕开源仓库 remoteintech.company（即 remote-jobs 项目）中 Ollie Order 公司档案 展开的技术解读。文章以该档案的 frontmatter 数据模型与正文章节为绝对主体，逐字段拆解其语义，并结合仓库中的 labels.js、company.njk 等源码，说明一份公司档案如何被 Eleventy 渲染为线上页面、如何参与按地区/远程政策/技术栈的标签聚合，以及 SEO 元描述是如何自动生成的。读完你可以完整掌握该档案的全部内容与数据字段含义，并学会用同一套 schema 为其他公司撰写或维护档案。

Ollie Order 是谁：档案开篇的 Company blurb

档案正文的第一个必备章节是 ## Company blurb，在 Ollie Order 这份档案中，它回答了三个问题：公司做什么、服务谁、技术背景如何。

• 产品定位：Ollie Order 为工艺制造商（craft manufacturers）和消费者提供全渠道（omnichannel）销售工具，档案原文将其比作 Square、Shopify、Amazon 与 Alibaba 的交叉体，即既要覆盖线下到线上的多销售渠道，又要支撑平台化的交易与商家管理。
• 行业切入：公司为餐饮酒店行业（hospitality industry）构建了一个订货系统（ordering system），初期聚焦酒类饮料（liquor beverages）——档案特别强调团队热爱精酿啤酒及其生产商与采购方。客户依赖这套软件来经营自己的生意，公司对这一点承担着很高的责任。
• 业务成熟度：档案明确指出公司已产生收入、获得行业积极反馈，管理层有行业巨头背景并有投资者支持，平台累计完成了数亿美元的交易量，服务数百家客户。

这一章节的内容同时被用于生成页面的 meta description。companies.11tydata.js 中的 eleventyComputed 逻辑会通过正则 ##\s*Company\s*blurb\s*\n+([\s\S]*?)(?=\n##|$) 抓取 blurb 章节正文，剥离 Markdown 链接与强调符号、压缩空白后，在句子边界处截断到约 155 字符，作为每个公司页面的搜索引擎描述。换句话说，Ollie Order 档案中这一段文字不仅是人类可读的介绍，也是该页面 SEO 摘要的数据源。

档案的数据骨架：frontmatter 逐字段解析

Ollie Order 档案的 YAML frontmatter 是一份结构化的数据记录，它决定了公司页面如何分类、如何被索引。与 CONTRIBUTING.md 中给出的贡献模板对照，可以逐字段还原其语义：

字段	Ollie Order 档案取值	含义与取值约束（依据 labels.js 与 CONTRIBUTING.md）
title	"Ollie Order"	公司显示名称，同时用于页面 H1 与公司列表排序
slug	ollie-order	页面 URL 标识，必须与文件名 ollie-order.md 一致
website	https://ollieorder.com/	公司官网
careers_url	一份 Google Forms 表单地址	招聘/申请入口；页面按钮会优先展示为 "Apply Now"（见 company.njk）
region	americas	合法值：worldwide、americas、europe、americas-europe、asia-pacific、other；此处映射为 Americas
remote_policy	remote-friendly	合法值：fully-remote、remote-first、hybrid、remote-friendly；此处映射为 Remote Friendly
company_size	medium	合法值：tiny(1-10)、small(11-50)、medium(51-200)、large(201-1000)、enterprise(1000+)
technologies	graphql、javascript、ruby	合法值见 CONTRIBUTING.md 的枚举列表
addedAt / updatedAt	2020-07-19	收录与更新时间，由维护者管理

两个值得注意的细节：

1. remote_policy: remote-friendly 的含义：在 labels.js 的四档远程政策中，"Remote Friendly" 属于比 "Fully Remote"、"Remote First" 更宽松的一档，表示公司允许远程协作但并非全员分布式。Ollie Order 档案正文也印证了这一点——其远程团队目前集中在一个 7 人的工程团队中。
2. technologies 与正文技术栈清单的差异：frontmatter 只登记了 graphql、javascript、ruby 三个标签，而正文 ## Company technologies 章节则列出了 Ruby、Rails、JavaScript、Apollo、GraphQL、React、Rspec、Cypress 八项。这体现了档案的双层信息结构：frontmatter 的 technologies 用于站点级的标签聚合与检索，正文清单则用于完整展示技术栈。

另外，labels.js 的中心化标签表中并没有 graphql 这个 key，因此在渲染技术标签时（company.njk 使用 labels.tech[tech] or tech 的兜底逻辑），Ollie Order 的 graphql 标签会以原始字符串形式展示，而 javascript、ruby 则分别规范化为 "JavaScript" 与 "Ruby"。

远程状态与招聘要求：Remote status 章节

## Remote status 是档案的必备章节之一，也是判断候选人是否匹配的关键信息来源。Ollie Order 档案在此章节透露了以下招聘信息：

• 工程团队规模：目前 7 名工程师。
• 目标职位：资深软件工程师（talented software engineer）。
• 硬性技术栈：Ruby 与 React 的扎实经验是首要要求。
• 加分项（DevOps 方向）：Docker、Buildkite、Postgres、CI、GraphQL 以及 AWS 相关的 DevOps 经验。
• 软素质要求：出色的解决问题的能力和把产品做到极致的自驱力与纪律性；候选人应完整经历过产品周期、理解构建卓越产品所涉及的不同角色。
• 准入门槛：必须至少在某个生产环境运行的 Rails 应用上工作过（experience working on at least one production rails application），否则不予考虑。

这段文字可以还原出一份典型的后端/全栈远程工程师画像：以 Ruby on Rails 为根基，以 React 为前端主力，围绕 GraphQL（Apollo）做 API 层，并需要具备容器化、CI 与云基础设施（AWS + Buildkite + Docker + Postgres）的工程化能力。结合 frontmatter 的 remote_policy: remote-friendly，可以推断该团队的远程协作更偏向"团队内弹性远程 + 核心成员在温哥华办公"的模式，而非全球分布式招聘。

公司技术栈清单：从 Rails 到 Cypress 的完整链路

正文 ## Company technologies 章节给出了比 frontmatter 更完整的技术栈，覆盖了从后端到前端再到测试的闭环：

• 后端：Ruby、Rails —— 与招聘要求中"生产 Rails 应用经验"直接对应。
• API 层：GraphQL + Apollo —— 对应 frontmatter 的 graphql 标签，也出现在招聘加分项中。
• 前端：JavaScript、React。
• 测试：Rspec（Rails 生态的单元/集成测试）、Cypress（端到端测试）。

这条技术栈链路的工程含义是：团队用 Rails 构建业务核心，用 GraphQL（Apollo）统一前后端数据契约，React 负责前端交互，Rspec 保障服务端质量，Cypress 兜住端到端场景——恰好覆盖了招聘信息中提到的 Docker、Buildkite、Postgres、CI 等 DevOps 环节所支撑的完整交付流水线。

规模、地区与办公地点

档案的后半部分提供了三类运营信息：

• ## Company size：正文写明 "200+"。这里有一个可以观察到的细节：frontmatter 的 company_size 取值为 medium，而按 labels.js 的映射，medium 对应的区间是 51–200 人；正文的 "200+" 与这一区间存在轻微出入，反映出档案在更新时正文与结构化字段可能未同步。
• ## Region：Canada, BC —— 即加拿大不列颠哥伦比亚省，对应 frontmatter 的 region: americas。
• ## Office locations：Main Street, Vancouver, BC —— 温哥华 Main Street 是实体办公地点。

这些信息在页面上会被渲染为结构化的分类标签：地区标签指向 /browse/americas/，远程政策标签指向 /browse/remote-friendly/，二者都是根据 frontmatter 字段在 company.njk 中动态生成的链接。

如何申请：How to apply 章节

## How to apply 是档案的第三个必备章节。Ollie Order 档案在此章节说明：有意申请 Software Engineer 职位的候选人需要填写一份 Google Forms 表单。这份表单地址被存放在 frontmatter 的 careers_url 字段中，在页面渲染时，company.njk 会优先使用 careers_url 生成主按钮文案 "Apply Now"，只有当 careers_url 缺失时才回退为 website 并显示 "Visit Website"。从数据模型的角度看，这正是一个"正文说明 + 结构化字段驱动按钮"的典型组合。

从 Markdown 档案到线上页面：渲染与聚合链路

Ollie Order 档案最终以 /companies/ollie-order/ 页面形式呈现，其渲染链路由仓库中几个关键模块协同完成：

1. 布局：companies.json 将目录内所有公司档案统一指定为 company 布局，即 company.njk，它负责输出页面头部、申请按钮、地区/政策标签、正文内容（{{ content | safe }}）、技术栈区块与底部"最后更新"时间。
2. 集合聚合：collections.js 通过 getFilteredByGlob('./src/companies/**/*.md') 收集全部公司档案并按标题字母序排序；getCompaniesByTech 则把档案的 technologies 字段展开成按技术分组的索引——虽然 graphql 不在中心化标签表里，聚合逻辑仍会为其动态创建分组，因此按 GraphQL 检索也能命中 Ollie Order。
3. SEO 元描述：如第一节所述，companies.11tydata.js 从 blurb 章节自动生成不超过 155 字符的页面描述。
4. 标签文案：companyHelpers.js 从 labels.js 再导出标签映射，供 JS 侧集合与模板侧共用，保证 americas、remote-friendly、medium 等枚举值在全站展示为统一文案。

换句话说，你在线上看到 Ollie Order 的完整公司页面，其信息全部来源于这份 60 行不到的 Markdown 档案——结构化的 frontmatter 驱动分类与按钮，正文驱动描述与招聘详情，二者经 Eleventy 构建后合成为最终页面。

复用同一 schema 维护新公司档案

如果你希望以 Ollie Order 档案为范本，为其他公司提交类似档案，仓库提供了明确的操作流程（详见 CONTRIBUTING.md）：

1. 在 src/companies/ 下创建 {slug}.md 文件，slug 必须与 frontmatter 中的 slug 一致。
2. 填写 frontmatter（title、slug、website、careers_url、region、remote_policy、company_size、technologies），并编写包含 ## Company blurb、## Remote status、## How to apply 三个必备章节的正文。
3. 运行 npm run build（依赖 Node.js 22+，见 README.md）验证构建。
4. 打开 Pull Request，由 "Validate Company Profiles" 工作流自动校验字段合法性并给出修改意见。

对照 Ollie Order 档案可以验证：region、remote_policy、company_size、technologies 全部落在 CONTRIBUTING.md 声明的合法取值范围内，addedAt/updatedAt 也遵循"由维护者管理、贡献者不写入"的约定——这份档案本身就是一个完全符合目录 schema 的规范样例，可作为撰写新档案时的结构参考。