摘要：制造业与地产业CIO现场“互怼”LLM编程应用，观点差异直击甲方痛点！制造业庞总把“稳定”刻进DNA，核心生产线代码坚决人工编写，还强制考核团队编码能力，怕AI出错导致生产线停机；地产业坚少则全力追效率，除合规红线外都让AI干活，觉得没必要纠结手动编码，人才会用AI、懂业务就够。尽管分歧明显，但两人都认可LLM的提效价值，也都计划2026年针对性制定应用规则——这场范式变革，没有绝对对错，只看是否适配行业特性。对话人：叶总（主持人，甲方数字化转型负责人，兼具业务与技术视角）、庞总（制造业甲方CIO，深耕工业数字化十年）、坚少（地产业甲方CIO，主导过多个智慧社区、数字化管控项目）
场景：甲方数字化转型沙龙现场，叶总引导两位CIO围绕Karpathy随笔，探讨LLM对甲方技术团队的影响与实践心得
叶总：各位同仁，今天咱们不聊虚的，就围绕Karpathy那篇刷屏的随笔，从甲方视角聊聊LLM重构编程工作流这事儿。庞总、坚少，你们俩分别扎根制造、地产两大重资产行业，肯定有不少实操体感，先请庞总聊聊，你们团队现在用LLM编程的比例大概到多少了？
庞总：叶总这个问题很实在。我们团队这三个月变化特别明显，从之前偶尔用AI补全代码，到现在差不多70%-80%的开发工作靠LLM搭框架，尤其是工业场景下的小工具开发、数据报表脚本这些。但我们比Karpathy更谨慎，制造业的代码太特殊了，要对接PLC、MES系统，容不得半点差错。上周让团队用Claude写设备数据采集脚本，AI自作主张简化了异常校验逻辑，还好测试时发现了，不然生产线停机一分钟，损失都是六位数起步。
叶总：没错，甲方最看重“稳定可控”，尤其是重资产行业。坚少，地产业在智慧社区、ERP系统迭代上，应该也在用LLM吧？有没有遇到类似的风险点？
坚少：太有了。我们现在做智慧社区的小程序迭代、业主数据统计工具，基本都靠LLM提速。但地产行业的代码要兼顾合规性，比如业主隐私数据处理、物业收费逻辑，AI经常会忽略行业特殊条款，自顾自写逻辑。上次让它写业主物业费补缴提醒的后台脚本，居然没加“逾期天数分段计算”的地产行业常规规则，还多写了个冗余的批量推送接口，删改优化花了不少时间。但不可否认，它解决了我们技术团队的人手瓶颈，以前要两周才能搞定的临时统计工具，现在三天就够，还能腾出精力对接业务部门需求。
叶总：确实，甲方技术团队大多是“小而精”，LLM的核心价值就是帮我们放大人力杠杆。不过不同行业的诉求肯定有差异，庞总看重生产稳定，坚少聚焦合规与协同，你们对LLM的应用优先级，是不是也有不一样的看法？
庞总：这一点必须夸，但我的核心诉求还是“稳字当头”。我们团队以前没人懂Python的工业视觉处理库，靠Claude一周做出车间瑕疵检测demo，省了招专项开发的时间成本，但这只是辅助性场景。核心生产线的PLC、MES对接代码，我坚决要求100%人工编写调试，哪怕多花三倍时间，也绝不让AI碰——生产线停机一分钟六位数损失，试错成本太高。而且我发现年轻工程师依赖AI后手动能力退化，这是致命隐患，所以现在强制要求核心模块必须手写，每周组织编码考核，就是要守住技术底线。
叶总：庞总这是把“稳定”刻进了骨子里。坚少，你这边是不是有不同想法？毕竟地产业试错成本和制造业不一样。
坚少：我和庞总的思路正好相反，我是“效率优先，合规兜底”。地产业没有生产线停机的即时损失，项目周期和人力成本才是核心痛点，所以除了业主隐私数据处理、收费核心逻辑这些合规红线，其他场景我都鼓励团队大胆用AI，包括智慧社区的核心小程序框架，也是AI搭骨架、人工做合规校验和优化。至于年轻工程师手动能力退化，我觉得没必要过度焦虑——未来甲方技术人才，核心不是会写多少代码，而是能驾驭AI快速落地业务、把控合规风险。真遇到要手写核心代码的场景，找外部专家兜底就行，没必要让团队把精力耗在重复编码上，不如聚焦业务需求对接。
叶总：这就有碰撞了！一个求稳拒让AI碰核心，一个提效放手非红线场景，还在人才培养上有分歧。庞总，你肯定不认同坚少“外部专家兜底”的想法吧？
庞总：完全不认同。制造业的旧系统兼容、核心流程代码，都是带着十几年的生产沉淀，外部专家根本摸不透我们的生产逻辑，临时兜底只会越改越乱。上次我们找外部团队优化老旧MES接口，对方不熟悉我们的生产节拍，改完反而频繁出现数据卡顿，最后还是靠内部团队手动重构才解决。而且核心技术能力必须握在自己手里，过度依赖外部专家，不仅成本高，还会丧失对系统的掌控权。AI再好用，也只是工具，团队的核心编码能力、对行业场景的理解，才是立足根本，这部分绝不能丢。
叶总：庞总顾虑的是核心能力掌控，坚少更看重资源高效配置。那在运维和内容甄别上，你们的分歧会不会也很明显？
坚少：确实有分歧。运维上我是把LLM当主力用，不管是门禁故障还是能耗异常，先丢给AI分析定位，效率提升太明显，就算偶尔给治标不治本的方案，人工再兜底修正就行，整体还是省时间。至于AI生成的垃圾代码，我觉得没必要花精力自建代码库甄别，直接用行业内成熟的开源工具筛选，再让AI辅助优化，性价比更高。地产项目迭代快，没必要在代码沉淀上过度投入，快速落地、满足业务需求才是关键。反观庞总，肯定是要逐行校验、自建库吧？
叶总：一针见血。庞总，你这边肯定是另一种操作逻辑？而且这种分歧，会不会影响你们对人才结构的判断？
庞总：没错，运维上我要求AI只做辅助分析，最终排查方案、修复代码必须人工敲定，还要留存详细记录，避免AI给出的临时方案留下隐患。代码库也必须自建，外部内容哪怕筛选过，也未必适配我们的生产场景，万一引入带隐藏bug的代码，后果不堪设想。人才结构上，我认为未来制造业甲方，还是要以“懂编码、懂生产、能控险”的复合型人才为主，驾驭AI只是加分项，核心编码能力和场景理解才是硬指标。如果一个工程师连基础代码都写不明白，根本没法判断AI生成内容的对错，谈何驾驭？
坚少：这就是我们的核心分歧。地产业人才，我更看重“业务理解力+AI驾驭能力”，编码能力只要达到基础水准就行。毕竟地产数字化项目，核心是对接业主、物业、法务等多方需求，把业务逻辑转化为可行方案，再用AI快速落地。一个能精准拆解业务需求、写出高质量提示词、把控合规风险的人才，比一个只会手写代码的工程师更有价值。而且行业迭代快，人才培养也要轻量化，没必要强求全才，让专业的人做专业的事，AI补编码短板，人聚焦核心决策，效率才最高。过度纠结编码能力，反而会限制团队的业务拓展能力。
叶总：两位的分歧非常鲜明——庞总坚守“核心能力内化、稳定优先”，坚少主张“效率优先、能力轻量化”，本质是两大重资产行业的场景特性决定的。这种冲突反而很有价值，没有绝对对错，只有适配与否。那针对2026年的消化吸收计划，你们的差异应该也会延续吧？
庞总：肯定延续。我们的计划核心还是“控风险、强能力”，除了制定LLM应用场景清单、禁止AI触碰核心生产代码，还会加大基础编码和场景实操考核力度，把技能萎缩的风险降到最低。内部代码库也要加速扩容，所有AI生成的辅助代码，必须人工校验优化后才能入库，确保每一行代码都适配生产需求，绝不将就效率牺牲稳定。
坚少：我们则是“提效率、优协同”。重点搭建地产专属提示词库，让AI更懂合规规则和业务逻辑，进一步释放基础开发、运维的人力。同时优化人机协同流程，明确AI和人工的分工边界，把技术团队从编码、排查等事务性工作中彻底解放出来，聚焦核心系统设计和跨部门业务对接。人才培养也会侧重提示词设计、合规把控和业务拆解，不会在基础编码上过多消耗精力，毕竟适配行业特性的高效模式，才是我们的目标。
叶总：非常精彩的观点碰撞！庞总的坚守，是制造业对生产命脉的敬畏；坚少的放手，是地产业对效率与协同的追求。说到底，LLM带来的范式变革，没有统一答案，核心是适配行业特性、守住业务底线。无论是“能力内化”还是“轻量化赋能”，只要能让技术服务于业务核心，就是适合甲方的好路径。这也正是甲方数字化转型的精髓——不盲从趋势，只贴合自身需求。
