精选项目

验证先行：多站点 Hyper-V 与 SCVMM 驻场项目

服务对象：一家全球 IT 服务公司的州政府最终客户 · 依据 Dell 驻场合同交付

客户的工程师已经完成了最繁重的工作：主机部署到位，故障转移群集组建完毕，跨两个站点的网络架构搭建完成。他们要的不是重建——而是确定性。是否建得正确？能否经得起运行？管理层应该是什么样子？

我们围绕这个问题来组织整个驻场项目。前三周是纯粹的验证：主机配置、群集行为、存储与网络路径——按部就班地逐项测试，发现随做随记。不沿用任何既有假设，也不给"应该没问题"留情面。

在这个经过验证的基础上，我们设计了 SCVMM 目标架构并在两个站点完成搭建，随后开展赋能培训，让客户团队能够运营这套如今属于他们自己的平台。

我们之所以讲这个故事，正是因为项目中段发生的一幕：客户的工程团队评审了我们的目标架构设计，并对其中一项核心决策提出质疑——在网络配置上，Network ATC 与 SCVMM 之间的归属边界应该划在哪里。他们的坚持是对的。我们修订了设计，1.1 版承载着他们的评审成果：职责划分更加清晰，由实际运营平台的人逐行确认。

有些咨询公司会把这称为范围摩擦。我们则称之为项目按设计运转——我们与客户共同做工程，而不是对着客户做工程。能经受住客户自己工程师检验的设计，远比从未被质疑过的设计更有价值。

我们离开时留下的是：验证报告、修订后的目标架构设计、构建文档，以及一支有能力运营平台的团队。驻场的每个工时都留下了一份交付物。

应用迁移方法论的工业化

与 Dell 合作的进行中应用迁移项目 · B2B2B 交付

应用迁移很少败在工具上。它们败在缝隙里——败在探查与规划之间，败在某人脑子里的操作步骤与凌晨两点实际执行的手册之间，败在"我们可以回滚"与一份真实、经过测试的回滚方案之间。

在与 Dell 的合作项目中，我们将 Dell 的三阶段迁移方法论工业化：不是一套幻灯片框架，而是一座受治理的迁移工厂。

工厂如此运转：

• 阶段关卡。 每个阶段都终止于一道关卡，关卡有明确的进入与退出标准。任何事项都不会凭惯性继续推进。
• 生成的运维手册——以及生成的回滚方案。 对每个迁移批次，工厂都会以一致、可评审的形式产出前进路径与回退路径。回滚方案不是事后补充；它每一次都与运维手册同步生成。
• 人工通过/中止决策。 AI 智能体负责准备依据——探查结果汇总、依赖关系映射、验证检查、文档。每一道关卡的决策都由人做出。没有任何迁移步骤会仅凭智能体的判断而执行。
• 全程可追溯。 每个决策与操作都有日志记录、可以归因：做了什么、何时、由谁执行、经谁批准。

对于本页所声称的内容，我们刻意保持克制。这是一个关于方法论与能力的故事：该工厂已在与 Dell 的进行中项目内完成产品化，并以 B2B2B 模式交付给 Dell 的客户。我们将在客户迁移完成之后再发布成果——绝不提前。

如果您的迁移积压清单看起来像一长排英雄式的一次性项目，工厂模式就是另一种选择：交付物具备工业级一致性，每道关卡都有人的判断。

智能体交付，工程师监督

我们的交付模式 · Gus IT 每个项目的运行方式

认真采购的买家对 AI 驱动交付提出的第一个问题，正是该问的那个：让 AI 智能体接近生产基础设施，安全吗？

我们的回答是一套严格的分工，适用于每一个项目。

我们的 AI 智能体做什么：那些消耗资深工程师时间、又容易诱发人为失误的重复性工程工作。它们在整个环境中执行探查，把配置归纳为文档，生成运维手册与回滚方案，执行验证检查，并保持记录始终是最新的——稳定一致，全天候，不知疲倦。

它们绝不做什么：批准设计。在无人监督下触碰生产系统。做出通过/中止决策。

每个项目都有一位具名的资深工程师，负责设计审批以及每一个改变系统状态的操作。我们的自动化按安全试运行（dry-run）标准构建：可以在不触碰生产系统的情况下预演，并且每个阶段在承载任何变更之前，先承载一份回滚方案。每个操作——无论出自人还是智能体——都有日志记录、可以归因，您始终知道是谁决策、谁执行。

这对您意味着什么：您在交付物上获得工厂级的一致性——文档真正完整，运维手册真正最新——而无需把判断权交给机器。工程师不是事后批改 AI 的作业；工程师本身就是工作必须通过的那道关卡。

这不是实验室概念。这就是我们今天交付签约工作的方式，包括在合作伙伴与渠道合同下执行的项目。

如果您正在权衡 AI 是否应该进入您的交付链条——或者它进入之后该如何治理——请把您最尖锐的问题带到评估通话中来。这套模式生来就是为接受拷问而构建的。