AI时代，vibecoding的兴起正重塑企业内部的技术分工格局——业务部门开始自行利用AI工具开发系统，再交由IT部门部署的情况已屡见不鲜。这一现象引发了CIO群体的广泛讨论：面对业务部门的“自主开发”热潮，IT部门应建立怎样的机制来应对？与此同时，一个更深层的问题浮现：AI对IT部门的影响，似乎与其他职能部门截然不同，这种差异究竟是错觉，还是行业特性使然？
人们普遍观察到一个有趣的现象：当患者拿着通过DeepSeek查询的治疗方案咨询医生时，很少有人会认为医生将失业；当职能部门同事借助大模型处理法务问题时，法务岗位也并未面临被替代的焦虑。然而，在IT领域，一旦业务部门利用vibecoding搭建出一套简单系统，便容易产生“IT部门可以下岗”的认知。这种反差背后，既反映了业务侧对IT工作的理解偏差，也揭示了AI技术在不同职能领域应用场景的本质差异——IT工作中那些“可视化、可快速落地”的表层开发任务，确实容易被vibecoding快速替代；而医生、法务等岗位的核心价值，在于其专业经验、风险判断和复杂场景的综合决策能力，这些恰恰是当前AI技术难以超越的。
针对业务部门自行开发并寻求IT部署，CIO如何应对面对业务部门自行开发系统、转而要求IT协助部署的情况，群内的CIO们提出了以下应对策略：
策略一：实施“隔离管控与登记追溯”。 将业务部门开发的系统部署至独立的服务器与数据库，并对每次修改进行详细记录。通过实际运行，让业务部门亲身体验其局限性。这类非专业开发的系统，往往在一两个月后便会因稳定性差、维护困难而被淘汰，从而使业务方认识到专业IT支持不可或缺。
策略二：主动“拥抱融合”，聚焦核心价值。 与其纠缠于“业务越界”的边界之争，不如积极推广vibecoding，并为业务部门提供相关培训，使其在自主实践中认清自身的能力边界；与此同时，IT部门则应抽身而出，专注于业务部门无法解决的核心问题，如底层架构支持、系统集成、安全管控等。以“打不过就加入”的心态，将精力投入更能彰显企业价值的领域，实现IT与业务的协同互补。
在讨论应对策略时，“Harness方法论”成为焦点，其核心价值在于解决AI开发过程中的“目标偏离”问题，为IT部门应对vibecoding提供了重要思路。行业中，Harness原指一款CI/CD软件交付平台，并非专为AI设计的方法论体系。群聊中借用“开发管控工具”这一术语，将其定义为一套覆盖AI开发全流程的管控方法论。该方法论将关注点从单次提示的准确性，转向整个项目全自动化开发的目标一致性，核心是通过预先设定约束条件、验收标准和运行环境，防止AI Agent在长期工作中偏离既定目标。
Harness的本义是马具，用于驾驭马匹。在AI领域，它如同为AI这个“聪明大脑”套上的缰绳与马鞍，使其在自由发挥的同时不偏离方向、不出安全纰漏，并能可靠完成复杂任务。具体而言，Harness通过为AI设立规则，使其能够安全、自主地执行复杂工作。例如，我们可以：
- 环境设计：为AI提供充足的运行环境支持，避免其因环境缺失而耗费大量精力处理基础问题，导致任务偏离正轨。环境设计涵盖多方面内容，如AI执行框架设计、约束条件设定、权限边界划分、状态流转与恢复机制搭建等；
- 目标纠偏：通过预设验收条件、集成日志、指标跟踪等工具，在AI开发过程中及时识别并纠正偏离目标的行为；
- 多Agent监督：借助多个Agent的相互审核，防止AI为快速完成单个任务而忽视整体目标。需注意的是，Harness的效果在自动化长时间编程场景中更为显著，若仅为简单的一问一答式开发，其价值难以充分体现。
群内还有观点进一步指出，Harness的本质是“以管控人类的逻辑管控AI”——如同驯服野马，需通过“马鞍、马鞭”般的约束机制，使AI始终在既定框架内工作，在发挥其高效优势的同时规避风险。但Harness仅提供了方法论框架，具体落地仍需企业根据自身项目特点灵活调整，不存在“放之四海而皆准”的通用方案；同时，AI工程化的成熟离不开大量试错，正如神枪手需靠子弹喂出来，企业需通过多方向尝试，总结出适合自身的AI开发管控经验，他人的经验仅能作为参考，无法直接照搬。
破除AI编程神话，重估IT核心价值深入探讨AI对IT部门的影响，业内已形成共识：AI不会彻底取代IT部门，未来IT的核心竞争力将聚焦于“工程化能力”与“业务深度融合能力”。业务部门借助vibecoding开发的系统，本质上仅能应对“单点、单场景”的简单需求——例如从A系统提取数据、进行基础分析或生成展示页面，这类需求常因IT部门响应速度不足而被业务方自行解决；然而一旦涉及批量分发、安全管控、账号权限、复杂业务逻辑联动等场景，业务部门的自主开发便举步维艰。
这一差异的核心在于：vibecoding生成的系统虽“多快好省”，却难以承受复杂业务的长周期考验，最终可能沦为“难以维护的遗留系统”；而IT部门开发的系统虽投入成本更高、周期更长，却能承载复杂业务需求，具备可集成、可迭代、可智能化的优势，这正是IT部门不可替代的价值所在。此外，当前AI的编程能力仍有明显局限——完成概念验证（POC）游刃有余，但若作为正式业务系统长期运维，连资深程序员也难免担忧；AI缺乏对业务场景的深层认知，在处理复杂关联场景（如人力资源的入离调转多环节联动）时，往往仅聚焦代码层的接口适配，而忽视业务逻辑的关联性，极易埋下项目隐患。
IT的未来方向：重构系统，聚焦工程化与数据整合展望未来，AI与人类程序员仍将保持“互补关系”——人类的核心优势在于对业务的深度理解与复杂场景的决策能力，而AI的优势在于高效的代码生成能力；除非AI能形成独立于人类代码数据的编程范式（例如通过减少复用、隔离业务场景等方式降低逻辑复杂度），否则难以真正超越人类。
关于IT部门的未来定位，业内观点指出明确路径：甲方IT部门需实现双重转型，一方面推动产品经理、项目经理向全栈工程师（FDE）角色进化，提升综合能力；另一方面从基础设施与工程开发层面感知变革，逐步构建适合自身的Harness类管控体系，强化工程化能力。同时，企业未来的核心战略应聚焦两点：一是按岗位角色分级构建的数据集市，二是分级分类的API市场（含通用MCP服务）。
这一方向背后的逻辑值得深思：首先，人脑处理单线程任务的效率远高于多线程切换，未来每位员工应仅面对一个集成化界面，而非频繁切换多个应用；其次，在信息处理的“输入、加工、输出、传输”四环节中，唯有“加工环节的决策工作”需人类介入，其余环节均可由AI替代。依此逻辑，未来3-5年内，功能单一的软件厂商或面临淘汰，行业核心竞争力将转向数据整合、API集成与AI自动化能力。
思考与小结尽管大家对IT部门的未来方向已有清晰认知，但在实际推进中仍面临一个现实困境：企业管理者容易产生认知偏差，一旦发现业务部门能够自主开发系统，便可能质疑“IT部门的存在价值”。这也提醒IT部门，在应对全民开发挑战的同时，必须主动传递自身的核心价值——IT部门的使命从来不是“简单开发系统”，而是“以系统化、工程化、安全可控的方式支撑业务持续发展”，这正是业务侧自主开发难以替代的关键能力。
综上所述，AI时代全民开发的兴起，不应被视为IT部门的“生存危机”，而应把握为“战略转型的契机”。IT部门无需畏惧业务侧的自主开发能力，也不必纠结于职责边界之争，而是要积极拥抱变革：通过推广全民开发让业务部门认识到自身的技术局限，借助Harness等工程方法实现对AI开发的规范化管控，通过强化工程能力与业务融合能力，重新确立自身在组织中的核心定位。毕竟，AI只是提升效率的工具，而IT部门的真正价值，在于让这些工具更好地赋能业务，实现可持续的价值创造。
随时随地看视频
