ITIL Master 系列分享：不必会写代码，但要知道技术边界在哪

课上经常有管理者私下问我：我不懂代码，是不是就没法真正领导AI转型？我的答案是不会。但这句话后面必须跟一个提醒：不懂代码细节和不懂技术边界，是两件完全不同的事。前者只是分工问题，后者才是战略领导者的专业能力所在——你可以不知道一行代码怎么写，但不能不知道一件事能不能做、值不值得交给AI去做、做的时候需要谁来把关、条件不具备的时候会卡在哪一步。这个提醒不是空话，我在课上就当场做过一次示范。

我当着全班的面，做了一次完全不碰代码的开发

有一次课上，我一边讲课一边现场做了个小系统：一个巡检工单管理工具，让巡检人员打开待办清单，点一下关闭任务，或者在设备异常时填一句描述。整个开发过程我没写过一行代码——它用的是Node.js，我一个字符都不懂，后端逻辑怎么写、数据库怎么建，我全程没插手。但我不是站在旁边看戏：AI打字每问到一个岔路口，就会停下来等我拍板。它问我技术栈选Node.js还是Python，我随口就定了Node.js；又问界面主要给PC浏览器还是手机小程序，我说先做PC浏览器就够。功能范围它拿不准——只做巡检人员这一条主线，还是要额外加一个管理后台方便派单，我想了两秒，还是加了后台，不然任务没法派下去。最后问开发过程是每一步都要我手工批准，还是让它自动往下走，我选了自动，主要是不想被反复打断。中间我们照常讲课，隔一阵回头看一眼进度，任务能派、能关、能记录异常，系统就跑起来了。我从头到尾没碰过代码，却做了不少实打实的技术判断。我特意选在讲课的间隙做这个演示，是想让在座的管理者有个亲身体会——很多做IT服务管理的人，离软件研发已经隔得比较远，总觉得这是一件门槛很高的事，其实这几年门槛已经降得很低了。

软件开发这件事，现在已经简单到不需要管理者亲自懂实现细节。但“不需要懂实现细节”不等于“不需要做判断”——技术栈、平台形态、功能范围、审批方式，这些问题AI答不了，只能由清楚业务诉求的人来定。没人把这几个问题想清楚，系统一样能跑起来，只是跑出来的样子未必是业务真正需要的。

但有些架构，我不会放心让AI自己搭

同一次课上我把话挑明了：巡检系统这类应用层的开发，AI已经能独立扛下大部分工作，可换成网络架构呢？三层交换机怎么划分、VLAN怎么隔离、信息安全策略怎么定、一个分布式计算平台或者云平台的架构怎么搭，这些事我不会让AI自己拍板去做，还是得靠人来设计、靠人来把关。这类决策一旦出错，影响的是整套基础设施的稳定性和安全边界，一次没设计好，回头重建的代价比多花点时间设计要大得多——AI在这类场景里能帮着校验、辅助实现，但最终拍板还得是懂行的人。

巡检系统这类面向单一业务流程的应用，出了问题顶多是这一条流程走不通，返工成本可控，可以放手让AI做，人只在关键节点上签字确认。架构决策不一样，风险不是线性放大，而是会牵连整套基础设施，一旦出错往往牵一发动全身，所以还是要由懂这块专业的人主导设计，AI最多帮着校验。我自己是从网络工程和企业IT部门管理起步的，这些年天天跟机房、交换机、安全策略这类东西打交道，知道这类基础设施一旦出问题有多难收拾，这条边界是这么来的，不是凭空划的。战略领导者要判断的，不是“这件事AI能不能做”，而是“这件事一旦AI做错了，谁来承担后果、多久能补救”。

这次演示我还讲了一个自己感触很深的点：软件研发这道门槛，现在几乎被AI铲平了，可反过来，让做软件研发出身的人接手运维这边的活，门槛一点没降。网络架构、三层交换机和VLAN划分、信息安全、性能和容量规划、分布式计算和云平台的架构构建，这些东西要学很长时间才能真正理解，不是一段自然语言描述就能替代的经验。这个不对称提醒管理者：技术边界不是一条固定不动的线，它会随着AI能力往前推，但推进的速度在不同领域差得很远——判断边界在哪，得盯着具体领域去看，不能拿“AI又变强了”这种笼统印象去套每一个技术决策。

我跟供应商谈方案前，先问自己这几个问题

回到巡检系统那次演示，系统好不好用，靠的是我在每个岔路口给出的答案对不对得上业务实际，跟AI生成代码的快慢关系不大——功能范围定窄了，现场巡检人员会觉得不够用；定宽了，又会拖慢上线速度。这些问题背后，其实都是数据、接口、权限和治理条件在起作用：系统要接哪些设备台账、要不要跟已有的资产管理系统对接、谁有权限新建或关闭任务、异常记录要不要留痕给后续审计用。这些条件想不清楚，交给谁开发都会返工，跟用不用AI没有关系，只是AI把返工的门槛降到了几乎为零，让这类问题第一次不需要经历漫长的立项和排期就能暴露出来。我通常建议管理者把这几条列成一张清单，在跟供应商谈方案之前先问自己：这个场景要不要接入现有系统的数据，接口谁来维护，出了问题谁负责修，权限开给谁、开多大范围，记录要不要留痕备查。清单答不全，方案讲得再漂亮也先别签字——供应商的方案书里不会主动替你把这些缺口填上。接口维护权一旦握在供应商手里，想改一个字段都要走对方的工单流程，等到那时候再想谈判，主动权早就不在自己这边了。

教材里讲数字化领导者的能力要求时，专门提到要同时理解业务和技术，更要理解管理这两者的方法和分寸，这是章节里写明的要求，我在课上常拿它提醒管理者别只盯着技术细节。财务、市场营销、业务运营、信息安全，这些管理语言跟技术判断力同样是硬要求，少了任何一门，技术边界都会判断偏。AI转型把这个要求变得更急迫：以前技术能力不足，顶多是拖慢项目进度；现在技术边界判断错了，可能是几分钟内就把一个不该自动化的决策自动化出去，或者把一个明明可以放手的小事，拖成需要层层审批的大工程。

战略领导者该花时间的地方

所以我在课上从不建议管理者去学编程语法，那不是战略领导者该花时间的地方。真正要练的能力是：看到一个AI应用场景，能分清哪部分是可以放手的软件实现，哪部分是必须由人主导的架构和治理决策；能一眼看出这个场景需要什么样的数据、接口、权限条件才跑得起来，而不是等供应商把方案摆到桌上才发现少了半截。少了这层判断，要么是把明明能立刻推进的事一直搁着，要么是把真正需要专业把关的架构决策，也简化成一句话就想问出结果的侥幸心理。专业性不体现在亲自敲代码，而体现在能不能把一个业务目标，谈成一套真正落得了地、出了事有人负责的技术方案。