年轻的英国公司
英国公开登记显示，该公司于 2026 年 3 月注册，目前为 active，并列有两名董事。
状态CEO DISCOVERY
模式FDE POD
门槛先验证
01 / 为什么重要
持续 Build，通过 GitHub 产生了创始人注意力。
对方以创始人身份表示，他通过 GitHub 发现 Pengyi，看到持续交付的痕迹并主动发起联系。这不只是一次普通求职机会，也说明公开、持续的工程产出能够带来入站职业机会与商业机会。
可见的工程产出→创始人主动触达→需求沟通→明确交付
02 / 证据账本
把事实、公司声明和推断分开。
FDE 定位
官网将业务描述为嵌入客户组织的 AI-native 工程 Pod，覆盖需求到生产交付。
商业进展
ARR、客户数量和量化基金客户均属于公司侧声明，需要在沟通中继续核验。
真实团队规模
两名公开董事不等于总员工人数。“两三人运营团队”仍然只是合理假设。
03 / 前沿部署工程
输入模糊需求，输出可运行系统。
发现问题
确定真实工作流、用户、约束和经济结果。
系统设计
明确边界、集成、数据契约和评估门槛。
快速交付
在客户真实环境内完成一个窄而可运行的 vertical slice。
运营迭代
补齐权限、测试、监控、故障处理和持续迭代。
FDE 既不是只交 PPT 的顾问，也不是只接固定 Ticket 的工程师，而是在同一责任闭环内结合需求发现、系统设计、编码、部署和客户沟通。
04 / 创始人操作系统
敢想，敢做，敢直接触达。
选择明确细分定位建立可信展示界面直接联系人才与客户销售具体业务结果持续交付并获得留存
最大的启发
小型技术创始团队不会等待一切完美，而是先形成明确 Offer、建立网站、主动联系 Builder 和客户，再从真实沟通中学习。
真正决定公司质量的因素
客户结果、安全性、可重复交付、人员利用率、客户留存和降低创始人依赖。展示获得注意力，运营与交付获得信任。
05 / 20 分钟 DISCOVERY
短时间沟通，高信息密度决策。
背景
为什么联系 Pengyi？是雇佣、合同、合作还是客户项目？
交付
前 30 天负责什么？代码、评估和故障如何审查？
商业
项目如何定义范围、定价，并转化为长期合作？
边界
合同、数据访问、安全、IP，以及一个明确下一步。
06 / PENGYI 公司假设
面向量化与金融团队的 AI-native R&D Engineering。
工作流审计
梳理决策、证据、数据和失败点。
可运行切片
交付边界明确的 Agent 或 Quant 原型。
生产控制
补齐测试、权限、部署与监控。
评估与维护
持续维护、测量并升级交付系统。
不要从一个空壳公司开始。先获得一个真实用户、一个边界明确的 Offer、一次完整交付和一个可量化结果。