找工作的时候, 关于一家创业公司能查到的东西其实不少: 融了多少钱, 投资人是谁, 创始人从哪里毕业, 又在采访里讲了一个多大的市场.
但真正想知道的是另外几件事:
- 进去以后要写什么系统, 需要补多少领域知识
- 招聘页面上的技术栈, 是线上已经在用, 还是公司希望以后能用
- 公司说自己在做的业务, 有没有可验证的痕迹; 尤其在金融领域, 该有的牌照在监管登记里查得到吗
创业公司数据库擅长把融资轮次排成一张表, 却不会告诉你一个 Kubernetes preferred 能不能证明生产环境里有 Kubernetes.
于是攒出了 startup-due-diligence 这个仓库: 截至 2026-07-30, 收录 12 家公司, 覆盖日本, 北美, 澳大利亚和跨境市场, 中英双语, 每家一份带来源的档案. 它不判断一家公司值不值得投, 只整理准备加入的工程师需要的公开证据.
融资表之外
投资人和工程师会关心一些相同的东西: 有没有收入, 钱还能烧多久, 产品是不是真的有人用. 这些最后都会变成工资能不能按时发出来.
但工程师还要面对业务施加在系统上的约束. 物流 SaaS 不只是普通的增删改查, 后面还有报关, 货代, 船期, 单据和跨国协作; 支付系统的技术栈即使看起来平平无奇, 背后也可能是多方清算, 商户资金, PCI DSS 和一堆永远不能重复执行的状态机, 而业务能不能上线, 还取决于究竟由哪个法律实体或持牌合作方承担受监管的环节.
官网通常会说产品解决了什么问题, 很少说为了解决它, 工程师每天要和哪些约束打架. 这部分信息散落在产品文档, API 参考, 招聘页面, 技术演讲, 法律条款和监管登记里. 单独看每一份都不像答案, 拼起来才慢慢像.
这类档案本来就该让 AI 做
12 家公司的档案, 主要工作是模型完成的, 而这类活本来就该这么分: 面宽, 每一处都不深, 高度重复, 还要跨语言对齐格式. 找页面, 翻译材料, 抽取数字, 比较版本, 从 sitemap 里定位产品文档 - 模型比人快得多, 也不会因为重复和无聊主动罢工. 至于会不会用另一种方式糊弄, 是下一回事.
不能交出去的是另一件事: 它同样擅长把缺失的连接补成一句读起来合理的话.
- 旧品牌和新品牌共享创始人与域名时, 它倾向于写"公司完成了更名"
- 职位描述里出现 Kubernetes, 它倾向于把 Kubernetes 填进技术栈
- 三家媒体转载同一份新闻稿, 它可能算成三份相互独立的证据
这些错误通常不是事实编错了, 而是证据只走到 A, 结论多走了一步到 B. 而且同一个问题问两次, 多走的那一步还可能不一样.
所以这个项目真正需要维护的不是 prompt, 而是一份协议: 什么来源能证明什么, 日期指的是发布日还是统计日, 招聘要求能支持到哪一层, 来源冲突该保留还是淘汰. 协议既是给人复核的规范, 也是给模型套上的约束.
重点是方法可复核, 不是档案本身
档案一定会过时. 融资数字会变, 网站会改版, 职位会下线, 半年之后每一页都需要重做. 能留下来的是那份协议, 而它的验收标准很直接: 换一个人, 或者换一次对话, 能不能沿着同一套规则重走关键步骤, 并指出分歧发生在哪一步.
协议本身写了不少细则, 但真正在起作用的原则只有三条.
该看什么来源, 由主张的类型决定, 不由来源看起来权不权威. 产品能力看官方文档和 API 参考, 技术栈看公开资源或招聘信息, 而合规资质只有监管机构的登记算数 - 比如一家跨境支付公司宣称持有某个牌照, 在对应的监管登记里却查不到, 那就诚实地写"没查到".
每个事实都要带上有效期和证据强度. 日期负责有效期, "覆盖 194 MW"和"截至 2026-07-27 覆盖 194 MW"是两条不同的信息, 前者半年后就是错的; 标注负责强度, 从招聘信息推出来的技术栈写成"根据招聘信息推断", 读者可以自己决定接不接受这一步.
不确定性留在页面上, 不要顺手消化掉. 以 Shippio 为例, 资本数字在不同页面上出现过五个版本, 口径不一, 页面没有更新日期, 数字也不沿时间单调增加. 最省事的做法是挑一个看起来最新的填进表格, 但那只是把"我不知道"换成了一个看起来很确定的数字. 所以五个版本并列写着, 连"为什么现在不能直接比较"一起写.
三条指向的是同一件事: 让别人能反驳你. 可复核不要求结论一致, 而是每一步都能被单独拿出来检查, 也能被单独推翻一步, 不用整篇重做.
招聘要求不等于生产环境
招聘页面是这类调研里最有用, 也最容易被误用的来源.
Tensor Energy 是个清楚的例子. 公开文档能确认的生产系统包括: AWS IoT Core 上的电池遥测与控制, 基于 TLS 的 MQTT, 用于资产与预测数据的 REST API, 以及围绕日本电力市场交易时点, 至少每 30 分钟重算一次的电池优化.
它的后端职位要求 Go 的生产经验, 同时把 GraphQL, Kubernetes, DevOps, AWS CDK 列为优先而非必需. 其中 AWS CDK 和 IoT 基础设施能在公开文档里交叉确认, GraphQL 和 Kubernetes 则只有招聘信号.
把招聘页面丢给一个总结工具, 最容易得到的是:
技术栈: Go, GraphQL, Kubernetes, AWS CDK.
读起来很顺, 但它悄悄把"希望候选人做过"升级成了"公司正在使用". 更稳妥的写法要拆开: 文档确认了哪些生产系统, 招聘明确要求哪些技术, 哪些只是优先项, 哪些属于候选人的过往经验而不是当前技术栈.
对工程师来说, "进去维护 Kubernetes 集群"和"公司希望你有 Kubernetes 经验, 但公开材料描述的主要是 serverless 架构", 是两份不同的工作.
"没找到"也是一种结果
"这家公司没有技术博客"是一句关于世界的断言.
"截至某日, 在官网导航, sitemap, 招聘页面, GitHub 组织以及公司中英文名称的公开搜索结果中没有找到技术博客"是一句关于调查过程的记录.
前一句很可能是错的: 博客也许在一个没被官网链接的子域名, 也许改过名字, 也许搜索引擎还没收录. 后一句至少可以复核 - 别人知道你在哪里找过, 什么时候找过, 可以从你停下的地方接着走.
所以档案里的 Not publicly disclosed 不是空白字段, 而是带日期和范围的搜索结果.
很多调查看起来像是在找答案, 实际上是在给"我不知道"画一条准确的边界.
这套方法的局限
这套方法依赖公司愿意在公开网络上留下东西. 非常早期的团队可能没有产品文档, 招聘页面和正式新闻稿, 官网只有一句 slogan 和一个联系邮箱. 公开信息少不等于公司差, 只是以公司为中心的调查到这里就走不动了.
公司越早期, 调查重心就越需要从公司转向创始人. 创始人的公开职业账号, 访谈, 播客和活动简介, 可能是产品进度, 招聘计划和第一批客户仅有的当前来源, 也能提供继续向注册信息和后续公告交叉确认的线索.
但调查对象变了, 证据标准不能跟着放松. 创始人的帖子能证明他在某天说过什么, 不能证明那件事已经发生; "计划"和"正在开发"也不能变成现有能力. 早期公司的档案因此可能更短, 更多地方写着"尚未确认", 这是这套方法必须接受的边界.
为什么最后是一堆 Markdown
没有数据库, 没有前端, 每家公司只是一个目录:
companies/
company-name/
README.md
README.zh-CN.mdMarkdown 的好处就是足够低级: 每个结论旁边可以直接放链接, Git 能看见某个数字和某句措辞是在哪一次修改里变的, 公司改名也不需要迁移数据库. 打开 GitHub 就能读, clone 下来就能搜, 想纠错就是一个 diff. 对"可复核"来说, 一份能被 diff 的纯文本比一个漂亮的界面有用得多.
英文页面是事实结构的主版本, 中文页面在相同章节下同步. 两份文档会慢慢漂移: 英文改了融资数字, 中文还停在上一版; 中文少复制一个来源链接, 表面看不出来, 意思已经变了. 所以仓库里有一个很小的校验脚本, 检查中英页面是否成对, 更新日期是否一致, 标题层级与表格行数是否相同, 来源链接集合是否一致, 本地链接是否还能打开.
它不能证明翻译正确, 就像 checksum 不能证明两份错误的数据是对的, 但能抓住维护中最容易悄悄发生的漂移. 写个 README, 最后还是写出了数据一致性检查.
后记
这个项目不会告诉你哪家公司值得加入. 工作内容是否喜欢, 风险是否能接受, 创始人是否值得信任, 团队相处是否舒服, 这些只能在面试和实际接触中判断; 公开资料做不到, 硬做只会把推测包装成结论.
它能做的是把"这家公司听起来还不错"拆成三样东西: 有来源和日期的事实, 尚未解决的冲突与空白, 以及下一次面试应该当面问的问题. 至少可以问出比"你们技术栈是什么"更具体的问题.
仓库里的内容均基于公开信息独立整理, 与相关公司没有任何关系, 也可能不完整或已经过时. 涉及就业或投资决策时, 请直接向公司核实.