（来源：图灵人工智能）
转自AI Native启示录，仅用于学术分享，如有侵权留言删除一、AI都能写代码了，怎么还要找我？
最近，我一直在帮HR的同事，使用飞书妙搭搭建一些企业内部应用。
员工评价、文化共创、活动管理、主管能力测评……这些应用说复杂吧，确实不复杂。无非是填填表、点点按钮、审审批、发发通知。
放在以前，这些需求需要找IT，走流程、排计划、做开发、等上线。业务提需求的时候可能还是春天，等系统上线，活动都已经结束了。
现在不一样了。
飞书妙搭提供了一整套应用开发的基础能力，包括企业组织、员工身份、权限管理、数据存储、页面设计、业务逻辑、消息通知和应用部署。再加上AI辅助生成页面、编写逻辑，业务人员即使没有编程经验，也有机会在很短时间内搭建出一个可以运行的应用。
以前业务人员只能对着IT说：“我想要一个这样的系统。”
现在他们可以直接对AI说：“给我做一个这样的系统。”
AI回答：“好的。”
几分钟后，一个应用的雏形就出来了。
这确实是软件开发的一次巨大进步。
但奇怪的事情发生了。
业务人员已经能够自己搭建应用了，为什么最后还是要找程序员？
而且经常是：第一版自己做，第二版找人帮忙，第三版开始怀疑人生。
AI降低了开发的门槛，却没有同步降低软件设计的认知门槛。
二、业务人员眼里是页面，程序员眼里是数据
在最近的合作中，我发现了一个很有趣的现象。
业务人员讨论一个应用时，通常是这样的：
“这里加个按钮。”
“这里要有个审核。”
“这个页面不够好看，能不能改得活泼一点？”
“最好像小红书一样，能评论、回复、点赞。”
这些要求都很正常。
毕竟业务人员每天接触的是业务操作，他们最熟悉的是页面、功能和用户体验。
但程序员听到这些需求，脑子里出现的往往是另一套东西：
有哪些业务对象？对象之间是什么关系？一对一还是一对多？状态怎么流转？权限怎么控制？历史数据怎么办？
比如最近做的一个文化共创应用。
业务希望员工可以认领文化主题、上传作品、管理员审核，然后展示优秀作品。
听起来很简单。
如果直接从页面出发，完全可以建一张表：员工、主题、作品、审核状态。
然后把页面搭出来。
完美！
直到业务突然提出：
“一个主题能不能让多个人认领？”
“一个人能不能提交多个作品？”
“作品修改以后要不要重新审核？”
“以后能不能增加评论和投票？”
这时候，原本那张简单的数据表，突然就不那么简单了。
你会发现，最开始省下来的设计时间，正在以另一种方式加倍偿还。
软件开发有时候很像装修。
墙还没砌好，业务已经开始讨论窗帘的颜色了。
等窗帘买回来，突然发现这面墙应该拆掉。
真正的问题不是业务人员不会建数据表，而是他们往往缺少把现实业务抽象成数据结构的能力。
而数据结构，恰恰是决定一个应用能否持续演进的基础。
三、AI这么聪明，为什么不让它设计数据结构？
当然可以。
事实上，我现在做数据建模和架构设计，也经常借助AI。
但这里存在一个很容易被忽略的问题：
AI可以给出答案，却不能保证你问对了问题。
例如，业务人员告诉AI：
“我要做一个员工评价主管的系统。”
AI可能很快生成员工表、主管表、评价表，还顺手做出一个漂亮的评分页面。
看起来非常专业。
但它未必知道：
员工可能同时评价直接主管和横向主管；评价关系需要由业务提前确认；主管不能查看下属评价；活动结束后还需要按照组织维度进行统计分析。
当然，你可以要求AI主动澄清这些问题。
问题在于，业务人员自己也未必意识到这些问题的存在。
更麻烦的是，即使AI提供了三种数据结构设计方案，业务人员又该如何判断哪一种更好？
这就有点像让AI帮你设计一座桥。
AI给了你三套方案，每套都有漂亮的效果图，还有详细的结构说明。
你看了半天，最后选择了最漂亮的那套。
至于桥能不能承重？
这个问题可能要等第一辆卡车开上去才知道。
AI能够大幅提高方案生成的效率，但对方案的判断、验证和取舍，仍然需要相应的专业能力。
最危险的不是不知道怎么开发，而是不知道自己开发出来的东西有什么问题。
四、我找到了一种合作方式：我设计结构，AI负责干活，业务自己折腾
经过几次合作，我开始尝试调整工作方式。
既然业务人员不擅长数据建模，却很擅长业务操作和页面调整，那为什么一定要让他们从头到尾独立完成？
反过来，既然AI和妙搭已经能够承担大量基础开发工作，我又为什么要亲自修改每一个按钮、每一段提示文字？
于是，我们逐渐形成了一种共创模式。
第一步：业务负责讲清楚业务，我负责数据结构和架构设计。
我们一起梳理需求、业务对象、数据关系、权限规则和关键流程。
业务人员负责解释现实世界是怎么运转的，我负责把这些现实世界的规则转化为系统能够理解的数据模型。
这里有一个很重要的区别：
业务人员不需要知道什么是数据库范式，但需要说清楚一个员工能不能评价多个主管。
至于这意味着怎样的数据关系，是我需要解决的问题。
第二步：让AI和妙搭完成基础搭建。
当数据结构、核心规则和系统边界明确以后，就可以借助AI和平台完成大量具体工作。
建表、生成页面、配置流程、实现基础交互。
当然，生成结果仍然需要检查和测试。
AI可以干活，但不能因为它干得快，就免除验收。
第三步：把应用交还给业务人员，让他们自己迭代。
这是整个模式中，我认为最重要的一步。
当基础数据结构和核心架构相对稳定后，业务人员就可以自己修改页面布局、提示文字、交互效果，以及部分业务逻辑和管理规则。
这些事情他们往往比程序员更擅长。
毕竟，业务今天想把按钮从左边移到右边，明天又觉得放回左边更好。
这种事情如果每次都找程序员，程序员迟早会怀疑自己是不是转行做了家具搬运工。
但如果涉及新增核心业务对象、改变数据关系、复杂权限或重要流程，则需要重新进行技术评估。
这样，业务获得了自主迭代能力，专业工程师也不必成为每一次小修改的必经关卡。
专业人员负责结构，AI加速实现，业务人员负责持续改进。
至少在当前阶段，我认为这比要求每个人都成为全能开发者更现实。
五、真正的能力边界，不是会不会写代码
过去，我们习惯用会不会编程来区分开发者和业务人员。
但AI正在让这个标准逐渐失效。
我认为，未来企业应用开发的能力至少可以分成三个层次。
第一层：应用搭建能力。
会用AI生成页面，会配置表单、流程、按钮和通知，能够把一个想法变成可运行的应用。
这一层的门槛正在快速降低。
第二层：业务建模能力。
能够识别业务对象、设计数据关系、定义状态流转和权限规则，并为未来变化保留合理的扩展空间。
这一层需要抽象能力和系统设计经验。
第三层：系统演进能力。
能够处理复杂需求变更、历史数据迁移、性能、安全、测试、运维和持续交付。
这一层涉及完整的软件工程能力。
这三个层次并不是职业身份的划分。
业务人员完全可以通过学习掌握数据建模，程序员也可能只会写页面而不懂系统设计。
但我们不能因为一个人会使用AI生成应用，就默认他具备完整的软件工程能力。
就像会用Excel，不等于会做财务管理。
会用PPT，也不等于会制定企业战略。
当然，会用AI写代码，也不等于会设计软件系统。
AI让“做出来”越来越容易，却没有让“做得对、改得动、维护得住”自动发生。
六、程序员会失业吗？也许先失业的是那些只负责搬按钮的人
我越来越觉得，AI时代专业工程师的价值，并不是消失，而是在重新分布。
过去，很多开发时间花在页面、表单、接口和重复性的业务逻辑上。
未来，这些工作会越来越多地交给AI和平台。
而工程师真正重要的能力，将转向理解业务、识别约束、抽象模型、设计架构和控制系统复杂性。
当然，这并不意味着每个简单应用都需要一位资深架构师坐镇。
一个只使用三天的活动报名表，实在没有必要先设计一套能够支撑未来十年业务发展的微服务架构。
否则，活动都结束了，架构师还在讨论数据库应该如何分库分表。
真正合理的做法，是让工程投入与业务复杂度、风险和生命周期相匹配。
简单的应用，业务自己做。
有一定复杂度的应用，专业人员设计基础结构，业务人员自主迭代。
涉及核心业务、高风险数据和复杂集成的系统，则需要完整的软件工程治理。
专业工程师不应该成为所有需求的必经关卡，而应该成为复杂问题的关键解决者。
七、结语：AI让人人都能造房子，但不是人人都要成为建筑师
最近这些与HR共创应用的经历，让我逐渐改变了一个想法。
过去，我们讨论业务自主开发时，总希望业务人员能够掌握更多开发技能，最终完全脱离IT。
但现在我觉得，这可能不是最值得追求的目标。
一个HR同事，真正的专业价值是理解组织、员工和管理问题，而不是精通数据库设计。
让她花几个月学习软件架构，可能还不如让专业工程师花几个小时帮她设计好基础结构。
然后，让AI和平台完成大部分实现，让她能够持续改进自己的业务应用。
这样，每个人都在发挥自己的专业优势。
当然，这种模式也有一个尚未解决的问题：当专业工程师不再负责日常开发，谁来承担应用的长期维护责任？
这仍然需要组织明确资源和责任边界，不能简单地把所有问题都留给那个“最懂技术的人”。
但至少我们已经看到了一个更现实的方向。
AI时代，业务自主开发的终极目标，不是消灭程序员，而是让业务人员不必成为程序员，也能持续创造软件价值。
AI应该消除的是专业能力的使用门槛，而不是专业能力本身。
至于程序员？
也许以后终于不用每天改按钮了。
当然，前提是别让所有人都知道，你其实还会改按钮。
