用词很重要，擅用工具也很重要，工具与用词共同构建了我们的认知。词会影响我们如何命名一个现象、把它归入什么问题；工具（豆包/ChatGPT，百度/Google）会影响我们从哪里获取信息、用什么方式展开推理。二者共同构成认知入口：同一个问题，换一组词，边界会变；换一个工具，路径也会变。最终，它们一起影响我们能看到什么、怎么判断，以及做出什么决策。

OPC 是个人借技术栈完成企业级产出，FDE 是工程团队把前沿技术部署进真实业务场景。

OPC（一人公司）

在中国当前的政策背景下，OPC指的是一人公司，也就是人工智能驱动的“单人企业/超级个体”。

OPC一词的由来

1. 词源及国际起源
   OPC（一人公司） 这一缩写最早于 2013 年在印度《公司法》中正式确立，它定义了只有一个股东且承担有限责任的法律公司实体。
   一人有限责任公司的法律概念在许多司法管辖区早在“OPC”这一缩写成为主流之前就已存在。中国早在2005年就将一人有限责任公司纳入公司法，但直到2025年底，“OPC”这一缩写在国内才开始广泛使用。

2. OPC 如何在中国成为热门词汇（2025-2026 年）
   随着大型语言模型、人工智能代理、低代码工具和云计算的大规模商业化，中国OPC的定义已经超越了纯粹的法律术语：现在它指的是一位利用人工智能技术的独立创业者，他可以独自使用数字工具完成整个业务链（研发、设计、营销、运营、客户服务），而无需庞大的固定团队。

中国政府积极推动OPC

1. 稳定就业，促进大众创业
2. 促进微型创新，填补产业空白
   大型企业专注于大众化、标准化的主流市场，而OPC则具有决策链短、迭代速度快、对小众、个性化市场需求敏感的特点。它们涵盖了大型企业忽略的细分领域（垂直人工智能服务、定制化跨境电商、数字文化创作、小型智能硬件）。
3. 加速数字经济和人工智能产业化
   “AI+”国家战略要求人工智能在民用领域得到广泛应用。OPC是生成式人工智能、云计算、算力资源和数字工具最直接的基层用户。
4. 优化经济结构，降低工业运营成本
   与重工业项目或大型工业园区相比，支持OPC生态系统所需的政府前期投资要少得多，但经济回报却更快。一位拥有人工智能工具的创业者就能以极低的成本实现传统小型团队的产出。

FDE（前沿部署工程师）

FDE是来自技术供应商的软件工程师，他们与客户的业务和工程团队密切合作，有时几乎就像是嵌入式成员一样。这并不一定意味着工程师每天都要到办公室，尽管对于大型部署项目来说，出差和现场工作是常见的。

FDE一词的由来

• 该术语由美国科技公司 Palantir 在 2010 年代提出并推广，用于企业大数据交付团队。
• 后来，SaaS、AI、云计算公司在全球范围内采用了这一角色和交付模式；随着大型 AI 模型规模扩大，这一模式在2024年后进入了中国的数字产业政策讨论。

FDE如何运作

他们的工作不仅仅是解释供应商的产品，而是要让产品在生产环境中解决客户的实际问题：理解工作流程、设计解决方案、编写代码、集成系统、部署系统，并帮助用户采用。OpenAI 将其前沿部署工程师 (FDE) 描述为负责需求发现、技术范围界定、系统设计、构建和生产部署；Palantir 也类似地将这一角色描述为与客户紧密合作、与最终用户共同实施解决方案的工程师。

一个有用的心理模型是：

FDE = 软件工程师 + 解决方案架构师 + 实施负责人 + 技术产品经理

具体定义因公司而异。在 Palantir，前沿部署工程师 (FDE) 可能负责在 Palantir 平台上配置数据模型和工作流程。而在人工智能公司，FDE 可能围绕公司模型构建代理、评估、后端服务、数据管道和云基础设施。

FDE 实施流程

阶段	FDE 的作用	客户侧提供什么	典型输出
1. 发现	通过访谈用户、观察现有工作流程、识别技术限制和瓶颈，解决以下问题：	企业主、领域专家、工程师、代表性案例	已定义的用例、当前工作流程、成功指标
2. 范围界定	决定哪些功能需要构建，哪些功能不需要构建；识别集成、安全需求、依赖关系和风险。	关于优先事项、环境、数据访问和合规性的决策	工作范围、架构、实施计划
3. 原型	使用真实数据或代表性数据构建工作版本	快速的用户反馈和测试系统访问权限	可演示的试点或概念验证
4. 生产化	新增身份验证、API、数据管道、测试、监控、评估、错误处理和部署基础架构	安全审查、生产准入和内部工程支持	生产就绪型应用程序或工作流程
5. 采用	与用户协作，改善用户体验，编写系统文档，并消除操作障碍。	愿意测试和改变工作流程的用户	培训、文档、推广计划和采用数据
6. 交接或扩展	知识转移、运营稳定并确定下一个有价值的用例	长期内部所有者	运行手册、所有权模式、待办事项和扩展路线图

这个过程通常是迭代式的，而非传统的“先编写需求文档，六个月后交付”的项目模式。前沿部署工程师（FDE）会构建一个产品，观察用户如何与之交互，并据此调整系统。

FDE 与其他角色有何不同？

角色	主要职责
销售工程师	在销售过程中演示产品并证明其技术适用性
解决方案架构师	设计架构并建议组件之间的组装方式。
顾问	就战略、流程、组织或实施方面提供建议
系统集成商	执行既定的集成或转型项目，通常会用到多家供应商。
客户成功经理	推动用户采纳、提升账户健康状况并创造持续的业务价值
技术支持工程师	诊断并解决产品故障
FDE	直接与客户合作，编写或交付软件，以产生可衡量的生产成果。

企业实际能获得什么？

1. 切实可行的解决方案，而不仅仅是建议
2. 与现有环境集成
3. 明确的架构和实施方案
4. 评估框架
5. 生产和运营控制
6. 知识转移和赋能
7. 与供应商直接沟通的反馈渠道

由于前沿部署工程师 (FDE) 位于客户交付和供应商核心产品团队之间，因此客户的问题可能会比通过普通支持更快地传达给产品和研发团队。FDE 通常会将客户反复提出的需求转化为可复用的工具、平台功能或产品改进。不过，也不宜假定每个提出的功能请求都会被纳入供应商的官方产品路线图。

FDE 合作通常不包括：

• 无限定制开发
• 一位长期专属工程师
• 24小时生产支持
• 供应商底层平台或源代码的所有权
• 承诺无限期维护所有定制组件
• 供应商路线图变更的保证
• 交接完成后完全独立于供应商
• 负责修复底层数据质量
• 负责技术范围之外的组织变革或用户采纳工作

客户必须贡献什么

FDE 合作并不能取代客户参与。它通常需要：

• 一位负责任的企业主
• 技术所有者
• 联系领域专家和最终用户
• 及时的基础设施和数据访问
• 安全和法律审查
• 明确优先事项的决策
• 代表性测试用例
• 一个最终能够掌控解决方案的内部团队

如果没有这些，即使是强大的 FDE 也可能因访问请求、不明确的要求或利益相关者对所需工作流程存在分歧而受阻。

请将这些项目写入合同或工作说明书中。

在将“一次完整的 FDE 合作”视为一项实质性承诺之前，可以先明确以下几点：

1. 分配方式： FDE 是专职的、兼职的还是跨账户共享的？
2. 持续时间： 服务期从何时开始，何时结束？
3. 交付成果： 将交付哪些具体的系统、集成和文档？
4. 验收标准： 哪些指标或测试可以确定部署已完成？
5. 环境： 谁提供开发、测试和生产基础设施？
6. 代码所有权： 谁拥有自定义代码、配置、提示、评估和数据管道？
7. 维护： 上线后谁来修复自定义组件？
8. 支持： 针对生产环境中发生的事件，有哪些响应时间和升级路径？
9. 安全性： FDE 可以访问哪些数据，以及如何撤销访问权限？
10. 交接： 包括哪些培训、文档和知识转移？
11. 职责划分： 客户团队负责哪些职责？
12. 退出计划： 如果 FDE 合作或供应商关系终止，哪些方面可以继续有效运作？

结论

从客户角度看，购买的其实是与供应商产品接近的技术实现。

一次成功的完整 FDE 合作能带来：

针对有价值的业务问题，制定了范围明确、集成、评估和可投入生产的解决方案，并提供了足够的文档、操作控制和知识转移，以确保其持续有效运行。

衡量成功的最有力标准并非原型有多么出色，也并非有多少工程师参加会议，而是系统是否被投入生产，并在目标工作流程中带来可衡量的改进。