AI企业落地真相：90%靠工程，10%才是模型？当然不是，分类都是错的...
叶小钗约 12 分钟手里有些AI岗位；想找工作的同学可联系，急缺高级产品经理
关注公众号，回复1，与我交个朋友吧
近来AI训练营1、2班的课程过半，学员们逐渐形成了自己的AI知识框架，并且在某些部分开始逐渐觉醒，比如下午的时候就有同学在群里发表疑惑：
我最近一直在思考，何为AI项目？如ERP这样的，是ERP+AI，还是可以整体重构成AI+ERP，或者换成其它系统名字一样。
而多维表格也不是新东西，我最早在CMS就看见了，给我的感觉好像是历史正在重演，比如下面这句话：
AI是以流程重塑为核心，AI项目开始的标志是梳理了一个典型业务流程并完成demo验证，AI项目初步完成的标志是用AI的逻辑启动了业务飞轮。
把AI二个字换成任何其它字，是否也是成立的？比如：
OA是以流程重塑为核心，OA项目开始的标志是梳理了一个典型业务流程并完成demo验证，OA项目初步完成的标志是用OA的逻辑启动了业务飞轮。 ERP是以流程重塑为核心，ERP项目开始的标志是梳理了一个典型业务流程并完成demo验证，ERP项目初步完成的标志是 用ERP的逻辑启动了业务飞轮。 ...
事实上，该学员的观点是完全正确的，管理类的项目，梳理流程都是第一位的，好像非要说在炒冷饭也可以，新的名词出来，把之前的冷饭再热一遍。
事实上，AI，特别是指多维表格+Coze体系（或者说AI表格+Agent平台体系），确实在一步步蚕食各个公司OA的份额。
OA本来就是公司里面各个系统数据联通而诞生的缝合怪：门户统一、登录统一、审批统一、表单扩展，都是为了在不同视角、权限下的同一张数据表。
企业要的是多人分散录入—集中汇总—统一统计的轻系统，这块肉Excel/OA/低代码/多维表格/AI表格都在抢。
并且所有这类项目，难点不在开发，而在梳理SOP与行业KnowHow，他们的背后体现着一句话数据即流程，并且企业一直追求着成本低、上线快，什么工具体系能满足这一切，那么企业就会选择他。
从暂时来说体系化的能力（IM+文档+AI表格+Agent平台+云服务）会慢慢蚕食所有，对于这些公司以飞书体系来说：
Coze是皮肤，多维表格是内核，解释一下就是核心是流程梳理，整体系统走下来AI占比不重。甚至如此低的AI含量将他们归类到AI项目都不太合适。
以最近的一个AI在HR体系的赋能来说，AI占比真的不足20%（蓝色是必须AI的部分）：
而最近看了一篇文章：《AI智能体企业落地真相：90%靠工程架构设计，10%才是大模型技术》，虽然他篇幅很短，但这确实是我们两年来的经验，AI项目的成败不在AI而在工程，而工程的含义比你想象的多！
接下来，我们以上面图示背后的真实AI+HR体系落地的案例，为大家做系统性的说明。
管理之于AI
在管理上其实有个非常大的矛盾：设计层（管理层）总是想偷懒，他们宁愿公司天天到处救火，都不想把规则设计得很清晰，而发生这种现象的原因有二：
第一，管理能力不足，可能公司核心管理者实践不足缺乏方法论支撑。
比如绩效管理正常是HRBP提供方法论和工具支撑，项目管理PMO提供方法论和工具支撑，但是想做好得综合理解公司业务+细分技术+场景管理，三件事都干的好人也比较缺。
第二，管理工作过于耗精力，公司是以经营为目的的，所以战略重点基本是业务 > 技术 > 管理，从这里看，管理并不重要，并且公司逐利行为会导致短视，所以一些长期的管理工作一旦自己不推基本就停滞了。
一旦停久了，执行标准也会忘了，比如要求项目进度日反馈、工作流程要趋于标准化、故障要记录归档，其实这些都是大家觉得对的、好的经验，但这里面执行者会忘记、会偷懒，监管者也会忘记、偷懒。
最后导致的结果就是，组织一边在管理机制建立过程中优化流程、关联产出、提炼数据，提高结果的确定性和可解释性，一边随着时间的推移又不断遗失管理机制的真正精髓，或完全失去关注（如知识库维护）、或只保留形式（如个人周报），公司被迫走向僵化。
这些问题，在所有公司，其实不管用什么方法、用不用AI，都是要持续解决的，传统的公司解决方案，或是扁平逻辑减少损耗、收拢信息，逼迫管理者业务、技术、管理三手抓，或是用分类逻辑简化问题，不断拆分业务中心、能力中心、职能中心，通过虚线交互来保证监管。
但那是公司战略层面要考虑的事，从技术团队角度，就是不管公司组织结构是什么形式，取两种方法的优势，提效场景的目标：
减少管理层的重复劳动，让技术管理者从繁琐事务中解放，聚焦战略决策与团队成长。 提高决策准确性，决策数据的依据来源系统在持续、稳定的运行；加速流程流转，提高管理工作效率就是提高业务效率，就是提高组织竞争力。
而人员招聘是相对比较容易能马上看到效果的场景，因为他对流程理解、技术沉淀、标准化基础的需求不算高。团队层面能够提效的主要场景包括：
所以，我们这里以AI+招聘的场景继续深入讨论：
招聘+AI
事实上，HR是不需要AI提效的，技术部门做招聘体系多半是为了自己，产研部门是招聘重灾区，而HR多数时候都是爱莫能助（袖手旁观）的：
基础岗位面试太多，自己部门面试、帮其他部门面试，耗精力，耽误事。 一般技术面试缺乏框架思维，结果不稳定、来回入职离职还耽误事。 真马上需要人的时候，也是公司集中招人期，得和其他部门抢HR资源，费劲、也耽误事。 HR太慢，或者想偷摸招人的时候，要自己捞简历，但小伙伴又忙又懒，基本半途放弃。
而常规的招聘流程是：
需求部门提岗位JD（招聘流程），并输出岗位的级别，以及特殊要求（岗位理解） HR根据对岗位的理解，发布招聘需求，并在各个平台捞简历 捞到的简历丢在招聘群里，岗位的需求部门（或委托技术部）安排对接人来进行初筛 HR约时间，创建日程，如果是视频会议提供会议链接 HR面和技术面在一面中合并在一起完成 面试结束后，候选人退出，HR和技术面试官现场确定结果 通过的候选人，看情况是不是要约二面、终面，一般二面是总监、终面是总经理，这个场景的岗位一般有一定重要性，不能减少时间投入。 HR谈薪，这个时候HR会咨询总监建议薪资，只要有个框架参考就可以，剩下的依赖HR的经验和应对能力，什么时候吸引人、什么时候压工资、什么时候想办法争取人
技术部门往往都不喜欢面试，很烦招人，如果没有AI，我们会怎么做这个事呢？答案很简单：
一、制定技术能力框架，业务需要哪些技术能力，我们具备哪些能力，业务需要的技术能力等级，我们具备的技术能力等级，这些能力如何分类：
二、制定技术能力图谱，不同的技术能力等级的具体要求是什么，市场如何定义，是否有一个大家都认可的解释性框架：
三、制定标准岗位的岗位说明书：技术岗位有哪些，分类是否完整、有效，岗位级别的设计和不同级别的要求（经验要求、技术要求、评价标准、薪资范围等）是什么？
四、制定面试手册：根据技术能力图谱、技术能力框架和岗位经验要求设计面试题库，为不同面试题打上技术能力等级，还要设计面试策略，如何进行面试评价。
想搞出这些标准能力的定义，也依赖部门内部的工作流程、工作内容能够抽象出来，完成基本的标准化。
只不过，这里很快遭遇一个问题？
AI的前身：复杂化
这样做下去，非常有一种把简单事情复杂化的感觉，但既然想偷懒，就得花更多精力建立一个让我们能偷懒的机制，不仅要自己内部提炼共性，还要推动公司对一些标准达成共识：
优化招聘岗位设计，不管招聘的岗位实际是做什么的，先按照我们的岗位设计和技能图谱设计匹配套用一下里面的内容，招聘工作、包括后面的绩效设计都必须以这个框架为基础，减少人在里面每次重新DIY的精力花费。 初面交给一线员工，熟悉这套面试手册的用法，轮流通过面试的方式提升他们对修航母基础技术原理的理解，还要同步更新面试手册，这样hr就不会因为我在增加他工作量而反对了。
事实上，从设计层面的策略复杂化，是AI能落地的基础，因为设计上很多公司想偷鸡，所以很多AI项目迟迟不能落地，因为整理这个流程太复杂了！
在上述的整理之下，就可以借助AI完成接下来的工作了，只不过出于对AI工程实践复杂度考虑，最好前期就对功能模块进行分类，大白话就是什么地方需要用AI，什么地方必须用AI，这里可以分为三类：
一类是AI原生的，比如群聊机器人自然语言对话、让大模型通过预设规则来评分； 一类是AI优化的，比如能力框架的梳理和优化、面试手册的编制，AI辅助生成； 一类是和AI没关系的，纯自动化逻辑，比如约会议、建日程、算数据；
这里因为流程里增加了AI助理角色，要让AI能够理解语言并获取到对应的信息，所以得重新设计流程：
框架、说明书、手册不再是可选参考，而是流程中的必需品。 对接招聘软件、日程创建、群聊bot、信息自动更新等自动化工作，可以让流程更顺畅，属于体验侧需求。 简历初筛与匹配、自动化初面，AI需求，完全不需要我们的参与，全部由HR和AI配合完成掉。
由此形成了此图：
至此，框架设计才初步结束，这里可以进行设计层面的总结，这里还涉及各部门的协调，这也是AI工程核心组成部分：
一、技术部门
辅助完成框架、说明书、手册的编写和更新，并制定后续框架、说明书、手册的编写和更新方式。
二、HR部门
HR和候选人需要提供AI开展分析工作所必须的信息 辅助开展各种自动化工作 辅助开展各种数据统计和计算工作
三、部门合作
简历初筛与匹配：自动解析JD与简历关键词，筛选匹配度高的候选人，减少 HR 及技术负责人初筛时简。 自动化初面：通过自然语言交互（或者辅助HR开展面试）完成基础技术问题问答（如编程语言基础、工具熟练度），生成面试评分与能力雷达图，聚焦核心候选人进入复试。
这里开始涉及到了AI应用的难点：行业KnowHow。
行业KnowHow
其实所谓行业KnowHow，就是各种评价，要知道什么是好的，不好的如何优化，这东西也没那么神秘，具体到这个业务场景就是：
简历评价标准
初面评价标准
接下来还有文档编写与更新以及打通各个接口和自动化这里就不赘述了，大家有个感觉就行。
也就是在KnowHow这里AI应用都会遭遇最大危机，以招聘场景为例，这里的问题是：
目前大部分岗位基本讲不清对招聘人员的要求（可能是受限于负责人的能力、可能确实是新岗位认知还没建起来）。
所以这套方法玩不下去，就算强行设流程要求各部门按照这种方式来，他们也给不出有用的文档。反而是自动化工作可能会有点用，但是对他来说也是下面人的活，加加班其实大家都无所谓。
所以HR也好、各部门也好，希望的是有一套工具能够让他们跳过长期的经验沉淀和基础建设工作，直接获得过程中指导和可解释性的确定结果，来提高工作质量和效果。
其实要解决也不难，只要预设一套能覆盖IT、安全、互联网公司所有可能涉及通用岗位的内置岗位和技能规则库就行了，还能找人社部立个国标项目（只不过你懂的...）。
至此，篇幅过2/3，才将AI应用的整体设计说清楚，接下来才是具体实现，而实现方式多种多样，为更好的表达，就直接上Coze吧...
Coze的实现
先上一张工作流全景图：
接着是具体工作流介绍：
然后是智能体设计：
数据设计
如前所述，数据即流程，最重要的依旧是数据设计：
岗位能力框架：
技术能力框架：
简历库：
JD库：
招聘case表：
岗位评分表：
case跟踪表：
PS：其实到了这里已经索然无味了，AI应用的难点永远在前期设计。
结语
前两天有粉丝问我什么是AI项目的工程实践能力，其实本文应该就是一个不错的回答；
然后回到AI含量只占10%的问题，招聘模块确实AI属性也没有超过20%，只不过这并不能说所有的AI应用占比都不超过20%
因为，这仅仅是AI应用的一个大分类：降本增效类AI，这类项目本来AI属性就不多。
但如果是一个复杂的知识库类项目，AI占比会明显高一些，如果将数据的处理与AI的配合也归属到AI的话，占比会超过50%，只不过这里难度也迁移了，从AI工程到了数据工程
最后，给所有这类降本增效AI应用做点总结，也算给大家一点意见吧：
传统的软件工程方式做不好AI项目
传统以功能需求交付为核心，按阶段完成功能开发就结束了，AI项目是以流程重塑为核心，项目完成的标志是用AI的逻辑启动了业务飞轮。
非对称性
该AI招聘模块，工作流从学习Coze开始到demo实现只用了2周，但是业务基础条件的达成做了1年多。
只不过如前所述，只要能让管理提效，不管用不用AI都是要做的，目的还是验证思路和提升认知。
细节悖论
在梳理流程过程中，很容易局部，而一旦陷入细节以后，就很难考虑全局，比如修bug的时候，一抬头一天就过去了，反而迷失了全局方向。
传统软件逻辑很重要
传统软件的逻辑是基础，80%还是传统软件的成本，这部分至少决定了能不能用，虽然甲方们现在希望为好不好用付费。
所以，做AI应用并不意味着传统的那部分基础可以丢了，相反他更重要了。
复合型人才
AI项目需要的人才，还是要不扁平、要不分类的逻辑，目前看起来扁平更容易一点，懂业务+技术+管理的人才转AI会更容易。
一定要分类的话，先要有能快速梳理业务的人才，技术和管理不着急，这个慢点没关系，对应的就是解决方案、产品经理。
什么是AI项目，什么不是AI项目。
AI原生的一定是AI项目，AI辅助提供数据清洗的不是AI项目，自动化的不是AI项目。
Coze、Dify工作流的、OCR识别的、MCP工具是AI项目的一部分，但只有他们就不是AI项目了。总不能用AI+低代码做个demo交付出去就算AI项目了把？
所以AI项目要求高一点，是以流程重塑为核心，AI项目开始的标志是梳理了一个典型业务流程并完成demo验证，AI项目初步完成的标志是用AI的逻辑启动了业务飞轮。
瞧一瞧，这一句话在这里说出来，就很有意思了，不是吗？
点击上方卡片关注叶小钗公众号，查看下方二维码，添加我个人微信：