夜雨聆风还记得刚做软件这行的时候，培训讲师说：“做实施，就是跑断腿、磨破嘴，客户不睡你不睡。”
15年，N个项目、N个城市，干的活永远是那几样：装系统、导数据、配参数、写操作手册、给客户做培训、再处理各种“怎么系统跟我想的不一样”的投诉……
直到上个月，有个延期两个月的项目，甲方新来的信息部小伙子说：“你们这活，其实我们找个AI也能干。”当时我嘴上没回，心里挺不舒服，更多的是，慌了。尽管我的老板一直在督促“学AI学AI”，但是高频率的项目穿插，我抽不出脑子真的投入AI学习。
目前AI对项目的帮助刚刚停留在：转译会议纪要、同频调研、喂资料之后的部分蓝图、操作手册、写SQL脚本查数据、编写测试用例，这些纯执行型的工作，做得比我之前还要高效和全面、但是有广度没深度。
后来，跟很多同行朋友了解，他们开始用WorkBuddy介入交付过程，甚至编写了很多可以商业化的小应用，有的还说刚刚汇报了AI助力排产的方案……焦虑了一个多月，我的价值会不会马上就被AI吞噬了？
直到一个项目现场，让我的焦虑稍微转折向好。那个客户是搞化工的，系统上线后，仓库的实际库存和系统账面总是对不上。我用AI查了所有数据差异，AI给出了理论原因清单：可能有未审核单据、可能有手动调拨未记录、可能有系统接口延迟……一共列了15条。
但AI不知道的是：这个客户的库管老王，习惯在每天下午四点半统一补录上午的出库单，而且他用的手写记录本上，产品编码经常写错。系统接口延迟只是表象，真正的原因是 人 的问题。
我问了老王半小时，搞清楚了他的工作习惯，然后让客户在系统里加了一个暂存草稿的功能，让老王随时录、随时存、下班前统一提交。问题解决了。AI给出的15条理论原因，一条都没用上。
那一刻我突然意识到：AI处理的是数据，我处理的是人。数据的问题AI能查，人的问题AI查不了。
后来，我对自己的角色重新做了定义。以前我是个做实施的人，现在我是个帮客户把人和系统对齐的人。两类工作，截然不同：
以前花大量时间的事、现在全交给AI：写文档、写脚本、写测试用例、整理会议记录、查日志、查数据差异、查系统配置、重复回答客户的基础操作问题……
现在花大量时间的事（AI帮不上忙的）：观察客户一线操作员的真实工作习惯，找出系统跟现实脱节的地方；跟不同部门的负责人聊，搞清楚他们嘴上说的需求跟实际要的东西是不是一回事；判断一个需求是该做系统改动，还是该改操作流程，或者干脆不改；在客户拍桌子说“系统不行”的时候，听懂他真正在抱怨的是什么……
AI帮我节省了40%的体力活时间，让我能把100%的精力放在那60%的脑力活上。
以前一个项目4个月，其中至少1.5个月在写文档、写脚本、整理数据、回答重复问题。现在同样4个月的项目，AI帮我压缩了1个月的基础工作，多出来的时间，我去现场蹲仓库、蹲车间、蹲办公室，去观察、去聊天、去发现问题。
今年上半年做的一个项目，光靠现场观察就发现了三个AI绝对发现不了的优化点——一套操作流程可以简化两步、一个输入界面可以合并三个字段、一份日报可以取消因为根本没人看。
这些优化的价值，远远大于我写的任何一份操作手册。
如果你也是做实施的，我的感受可能对你有用：
1、AI替代的是操作手册式的工作——规则明确、重复性高、逻辑清晰的事。它替代不掉的，是诊断式的工作——需要观察人情世故、理解组织惯性、判断真实需求的事；
2、以前这个行业看重的是能不能把系统装好、把数据导对、把手册写全。往后几年，看重的是能不能帮客户想清楚：系统上了，为什么人还是按老习惯干活？
3、系统上线只是项目的起点，让系统被人用起来才是真正的终点。而让人用起来这件事，AI暂时还插不上手。
这就是我们这群人的饭碗所在。
