不接注定烂尾的单
如果判断这件事用现有系统配置就能解决，或者这个场景 AI 根本帮不上忙，我们会直接说，哪怕这单不做。销售提成不挂项目金额，挂验收结果。
让系统真正被用起来，是我们唯一的标准
幻方造梦是一家把「交付结果」而不是「交付清单」写进考核标准的软件、AI 与安全服务公司。我们的组织不是按技术栈切的，而是按交付链路切的：前面有人扎在现场定义问题，中间有人把一次性定制抽象成可复用能力，后面有人保证系统过得了审计、也扛得住攻击。这一页讲的是这套组织为什么长成现在这样，以及它会在哪里失灵。
公司简介
我们按交付链路搭组织，不按技术栈搭组织
2018 年创业时我们只做两件事：写业务系统，做安全方案与等保整改。这两件事在多数公司分属两个部门，在我们这里从第一天起就是同一批人。做等保整改时你会发现，很多系统不是被攻破的，是设计时就没打算让人审计。软件和安全放在一起看，同一个需求的落点会完全不同。
后来做 AI 项目，同一个规律又出现了一次：模型是最干净的部分，真正卡住项目的是没人写下来的流程、对不上的主数据、和说不清归属的权限。这三样东西远程问不出来，只能进驻现场解决。组织最终就定成了现在这样。前面有人扎在客户现场定义问题，中间有人把定制工作抽象成可复用能力，后面有人保证系统过得了审计。这条链路上任何一环断掉，交付都会退化成「做完验收、然后烂在角落里」。
关键数据
八年下来，这些数字是客户给的
- 累计交付项目 300+ 个
- 客户覆盖医疗、教育、企业、政府、能源、交通、金融、零售八大行业
- 客户续约率 88%，平均合作年限 3.6 年
- 在跑项目 40+ 个，按期交付率 96%
口径说明：续约率按年度到期的服务合同计；按期交付率按合同约定的里程碑计；在跑项目含已交付未验收的部分。以上为累计口径，不区分业务线。
2018
公司成立年份
128人
团队规模
70%
技术与产品岗占比
6城
服务网络覆盖城市
发展历程
八年，六个关键节点
没有跳跃式的故事，也没有一次「战略转型」。每一块新业务，都是上一个项目里被客户逼出来的问题：系统上线没人用，于是有了驻场；驻场工程师被重复劳动淹没，于是有了智能体；智能体要过等保，又回头加固了安全这条线。
幻方造梦 · 八年
从 5 人的技术小组
到 128 人的交付团队
到 128 人的交付团队
2018
公司成立
几位互联网公司的工程师与产品经理创业。第一年只接两类活：写业务系统、做安全整改。一个做研发、一个做安全，谁都不肯先放下自己那摊。
2019
安全服务能力成型
做软件时客户不断要求补等保材料，我们索性把这件事做成独立能力：组建专职安全团队，渗透测试、代码审计与应急响应开始单独立项。
2021
FDE 交付模式产品化
连着几个项目栽在同一件事上：系统上线了没人用。于是把「工程师必须驻场」从习惯变成制度，结算方式也从人天改成按交付效果。
2023
组建 AI 团队
客户开始问「能不能让系统自己判断」，于是成立算法与大模型应用团队，第一批项目几乎全是内部知识库问答。
2024
智能体业务规模化
RAG 与多智能体工作流跑进零售、制造、金融客户的生产环境。踩坑最集中的不是模型，是权限过滤和知识版本管理。
2026
四类业务并线
FDE 人员服务、智能体开发、软件开发与网络安全四条线并行，服务客户突破 200 家。
我们的坚持
有些事我们不肯让步
工程师必须在现场
远程发一份需求文档不叫交付，它只证明文档写完了。关键节点我们的工程师一定在客户那里，跟一线坐在同一间屋子里，而不是隔着电话听转述。
不签范围待定的合同
「需求待定、范围后议」看着灵活，实际是把风险留给了甲方。范围谈不清楚我们就不开工，而不是先签下来，后面靠变更单一点点加钱。
团队与组织
四支队伍，覆盖从设计到交付的全链路
四支队伍不是各管一段就交棒。每两队之间都有明确的交付物：产品交出的不是需求文档，是能直接拆成测试用例的验收标准；工程交出的不是代码，是能在客户环境里一键起来的镜像与部署脚本；AI 团队交出的不是模型，是带失败案例的评测报告；交付团队交出的不是验收单，是客户自己人能照着跑的运维手册。少一样，下一环就接不住。
产品与设计团队
负责把「客户说想要什么」翻译成「系统到底该做什么」。成员多来自企业信息化岗或行业一线，不是纯互联网产品背景。这份工作得先听懂业务方在说什么。
- 现场访谈与业务流程还原
- 交互设计与高保真原型
- 验收标准定义，可直接拆成测试用例
工程研发中心
从架构设计到上线运维。交付标准只有一条：能在客户环境里一键起来。「在我机器上能跑」不算。
- 微服务架构与 API 设计
- 多端应用与设计系统建设
- CI/CD、监控与容灾方案
AI 与算法团队
专注大模型应用落地。我们的规矩是评测先于开发：项目启动先定测试集，没有测试集不写第一行代码。
- Agent 编排与工具调用
- RAG 检索与知识治理
- 分层评测、失败模式记录与推理成本优化
FDE 交付与安全团队
前置交付工程师长期驻场客户现场；安全团队负责系统集成、渗透测试、应急响应与等保合规交付。两者放在一支队伍里，是因为「被攻破的系统」和「没人用的系统」往往同一个病因：设计时没考虑真实环境。
- 驻场交付工程师，按项目固定配置、不中途轮换
- 安全工程师持 CISP / CISSP 资质
- 同时承接客户技术团队的培养与能力移交
人员安排
谁会被派到你的项目上
选供应商时最该问、却最少被问的一个问题是：具体是谁来做，以及他们会不会中途被调走。这一节把这件事写清楚。
Echo 从行业里来，不从应届生里来
负责定义问题的驻场分析师，我们更愿意找做过甲方的人：前信息科负责人、前业务主管、前运维经理。他们知道流程为什么会变成现在这样。这件事简历上写不出来，只能靠待过。
Delta 是工程通才，不是某一栈的专家
负责解决问题的部署工程师，要求是能在数据不全、需求天天变的环境下持续交付。我们不招「追求代码十年可维护」的完美主义者，那种人在这里会非常痛苦。
一个项目固定一组人，换人要你签字
驻场人员中途更换必须经客户书面确认。这条写进合同，是因为交付中断最常见的起因不是技术问题，而是「熟悉这个客户的人被调去别的项目了」。
交接靠文档，不靠记忆
项目结束前必须留下 Runbook 与架构图，而且要经过一次验证：由没参与过这个项目的人，照着文档独立处置一次故障。跑不通就不算交付完成。