去年冬天，经验我接手了一个失败的总结项目。团队花了四个月做的和亮智能客服系统，上线两周就被业务方叫停。点提复盘会上没人说话，经验会议室里只有投影仪风扇的总结嗡嗡声。我盯着屏幕上的和亮数据——用户满意度比旧系统还低12个百分点。那一刻我意识到，点提我们犯了一个根本性错误：把"技术先进"当成了目标本身。经验

这个项目用的总结是当时最火的预训练模型，团队里两个算法工程师每天调参到凌晨。和亮但业务方的点提客服主管私下跟我说，他们最头疼的经验其实是退换货流程的自动分流，而我们的总结系统连"我要退那双红色的鞋"这种简单诉求都识别不准。模型在通用语料上跑分很高，和亮可面对真实客服对话里的方言、错别字、情绪化表达，表现一塌糊涂。后来我翻聊天记录才发现，需求评审时业务方提过三次"要能听懂人话"，我们却在技术方案里写"采用多轮对话管理框架"。

失败教会我的第一件事：别急着堆技术。先蹲到业务现场看三天。第二次做类似项目时，我让工程师直接坐在客服工位旁边，听他们怎么跟用户吵架、怎么安抚情绪、怎么在系统里翻找订单。有个细节印象很深——客服经常要同时处理三四个对话窗口，所以回复必须短，最好一行字能说完。这个观察直接改变了我们的交互设计，后来新系统的首次解决率提升了27%。

亮点提炼这事，我吃过亏。以前写周报总爱列"完成了A模块开发、B接口联调"，领导看了没反应。后来学乖了，改成"把订单查询响应时间从3秒压到0.8秒，客服每天少等47分钟"。数字要具体到能让人感知到痛点的程度。上个月给零售客户做库存预警，我没说"运用了时间序列算法"，而是说"能提前两天告诉你哪些货会断，准确率大概八成五，比人工盘点快六小时"。对方当场就签了合同。

还有一点，经验总结别只写成功案例。我现在的文档里专门留一页叫"踩过的坑"，记录那些当时觉得对、后来发现错的决定。比如有次为了赶进度跳过压力测试，结果大促时系统崩了四十分钟。这种教训比任何最佳实践都值钱，因为它是用真实代价换来的。新来的同事看这一页，比看十页架构图都管用。

最后说个反直觉的观察：亮点往往藏在"没做什么"里。有回我们主动砍掉了智能推荐功能，因为发现用户其实更想要简单的筛选按钮。这个"不做"的决定，让项目提前两周上线，还省了服务器成本。所以现在复盘时，我会专门问一句：我们放弃了什么？为什么放弃？答案里经常藏着真正的价值判断。

写这些不是要否定技术。技术很重要，但技术是锤子，得先找到钉子。找钉子的过程，就是蹲现场、听抱怨、算细账。这些事不酷，但管用。