本周工作思考

解决客户问题要以客户为中心
本周在解决美敦力离职数据的问题时，对客户问题有了更深的理解，之前的工作中接触到了非常多的问题，绝大部分都是通过工程上的问题解决的。客户反馈说离职数据导不出来了，我的看到这问题第一反应是代码有问题，当时看了企业里确实有离职数据，看代码线下测试，发现是代码上bug，于是思路就是在如果解决这个bug上了，上线后我们没有在客户的环境上验证这种方法是否真的解决了客户问题，第二天客户发现没有离职数据，以为功能有问题，后来我通过关联Chatbot练习数据发现离职的人员没有练习过Chatbot。这问题对我来说是个很好的例子教我如何理解和解决客户的问题。
工程技术是解决客户问题的手段之一，但不是唯一的。 工程技术往往能规模化的，高效的，批量的解决客户问题，但有时候，客户问题往往具有独特性，需要识别出来。 客户的问题，不能仅用工程思维解决，客户问题首先是用户这个人的问题，是具体的他/她遇到的问题是什么，背后的问题有是什么，先解决Ta遇到问题，后面才是这个问题我们存在哪些问题，如何解决。我觉得这个可能是客户支持和技术工程意识上不同；
识别客户的问题是什么，客户的问题往往具有迷惑性，需要仔细审题， 有时候客户的问题很简单，其实没有那么简单，有时候客户的问题看似很庞杂，分析下来确也比较简单， 我以为解决了客户问题，实际上没有解决客户的问题，这个给了我很大的反思。我和客户之间存在一个模糊区，我以为的，逻辑上，可能不是Ta直接遇到的问题，尽管我们解决了深层次的问题，要把问题在转过来给客户解决。客户的问题很直接，对应的解决方案也要能让客户直接感受到和认知到，目标是拉进距离，消除这个模糊区；
客户体验，我之前很少关注客户体验，最近一段时间在Chatbot上非常频繁的和CSS的伙伴打交道，我逐渐意识到，产品体验和客户体验是两个层面的事，特别是大客户的客户体验，客户支持，bug修复，功能咨询，解决方案都会和客户产生很多交互，这个交互过程中，双方的感受，体验，情绪就很重要；建立良好的客户体验需要所有岗位为止努力。对于我来说，高效的解决客户需要的直接问题是最重要的方式之一。

本周工作思考

Chatbot相关问题总结
反思日本盐野义的Chatbot实施问题，这里有我很大的责任，没有及时消除其中的危机，日常优化中功能回顾不够深入，特别是go和python两侧服务中的类型没有对齐的问题导致的阈值问题。建立信任难，毁灭信任容易，和客户建立信任的基础是稳定和可靠的质量，以后的交付过程中必须想办法守住质量，除了优化调整交付流程，增加验证粒度，还要持续增加一些可靠性和准确度验证，虽然语言本身是模糊的，在现有的架构下，需要丰富评测维度，实现客户预期，提升用户体验。
增强客户服务意识也很重要，客户的很多反馈问题，实际上是客户在使用上和对Chatbot的理解存在偏差，支持工程师需要针对性的找到解决方案，并切实解决客户问题。解决掉客户的问题，透过这些解决方案再去优化Chatbot
AI类的产品比以前的任何产品都更需要工程化，现阶段模型本身存在一定的不确定性和个性化（这个是问题空间和解空间的映射有关），商业化产品要求准确稳定，AI类产品在问题对齐，数据，训练，开发，测试，评估等各个方面建立工程化的工具和平台，保证各个环节的结果符合预期，这样形成标准化的交付，保证所有的交付具有同样的高质量结果。
深挖实现原理，不少bug是出在对实现理解不深刻，对对应调整引发的深层次问题意识不到，往往的这类问题没有深入的对应的测试，又不能得到及时的发现，一旦发现就可能演变成事故了。
我另一个深刻的认识是敬畏客户，敬畏产品。敬畏不止是态度，在围绕客户服务的所有缓解中，只指向为客户创造价值这个一结果，不给客户惹麻烦，不增加客户负担，为客户消解难题，以客户的困难为自己的困难，敬畏产品，需要严谨，严肃的态度对台产品的任何变更。

今年我觉得我开始认真思考”中年人“这个课题了。要开始面对跟多的生存问题。一起看看下面这些中年人需要实实在在直面解决的的问题吧：

• 如何赡养老人
• 如何处理好和老人的关系
• 如何照顾远在老家的生病的老人
• 如何尽到更好的孝敬老人
• 如何处理好中年夫妻之间的关系
• 如何稳固夫妻关系
• 如何进一步夫妻感情
• 要不要二胎
• 如何教育孩子
• 孩子成绩不好的时候，该怎么办
• 孩子不向着自己规划方向成长发展怎么办
• 孩子在哪上学高考
• 如何保住现在的工作
• 如何避免不失业
• 如何挣更多钱
• 家庭财务捉襟见肘怎么办
• 理财亏的一塌糊涂该怎么过收场
• 如何让自己的不多的钱增值
• 如何让自己的事业更上层楼
• 在公司里，如何处理好各种的职场问题
• 如何让自己保持昂扬的对生活的热情
• 如何面对失败，挫折
• 如何平静的面对工作中的起起落落
• …..

小问题太多甚至都没法一一列举，这些家庭、事业、老人、夫妻、孩子、自己、工作、挣钱问题们哪个不是头疼的大事，如果你没有遇到，并不代表它以后不会发生。普通成年人的生存就是是不得不兢兢业业，任劳任怨，如履薄冰，负重前行。

一位好朋友的母亲得了一种很严重的病，与病魔需要做长时间的拔河，但是最终的结果我们都是知道的。得到这个不幸的消息是在今年春节期间，听到这个消息我震惊不已，每年都要去这位朋友家小聚一二次，所以和他母亲也很熟络，阿姨通情达理，为人热情，每次去都给我们这些”北漂“的”小家庭“一些长辈的温暖，张罗一桌可口的饭菜，和我们唠唠家常。没想到此，恍如昨日，现在阿姨得了重病，虽然心情焦急，却无能为力。在我们眼里，这是不治之症，我的这位好朋友承担了最大的精神压力和财务负担，坚持给阿姨治病。我理解他的做法，但是不能体会。不巧的是5月份，我母亲不经意间的了下肢静脉栓塞，家里哥哥根本指望不上。从北京到临沂一个月跑了四趟，疲惫不堪，幸好姐姐在老家，一起把老人的住院看护问题解决了。各种滋味，我全然体会到了。

这个阶段，工作上面临巨大的转型压力，事业上也面临着巨大的危机，年迈的父母更是让我对未来增加了很多不确定性的思考。我已经进入”中年危机“。

不经历风雨，难得见彩虹。没有中年危机，也就没有中年觉醒。中年人是整个社会中最坚实的底座。如果年轻人是激进的长江潮头，中年人就是暗流涌动的黄河之水，青年人拼的是劲，中年人熬的是稳；青年人要冲，中年人要忍。青年人和中年人有巨大的不同，可是哪个中年人不曾是青年人，又有那些中年人的问题不是来自青年时期的种的因。

中年人的觉醒就是要意识到这些问题，开始认真的认清现实，认真的评估自己的做在的形势，制定最恰到的生存策略，找准最合适的发展之道。

中年人的觉醒就是要开始修身养性，懂得收敛和潜伏，意识到人生机会的越来越稀少，必要有一击必中的勇气和智慧，也必要有舍我其谁的人生信念。

中年人的觉醒就是在带上生活的枷锁时，也要利用人生的经验争取心灵的自由和自信。中年人的生存之路会越走越窄，直至死亡，但是心灵之路会越走越宽。

致敬我的中年！向所有的中年人致敬！

本周工作思考

Chatbot相关问题总结
近两种调整了Chatbot和uShow相关工作的工作方式和优先级设置方式，任何问题都落到Anasa上形成任务，按照优先级的设置不同的时间期限，极优1天，高优1-2天，中优3-4天，低优1周内，基本保证任务周清，及时响应，准时执行到位。
另外也尝试做一些进度公布的事情，方便各项目干系人了解Chatbot和uShow的工程交付进度，保证问题在更大的空间能得到解决
最近利用午饭后的时间把AI组以前的伙伴的周报看一遍，目前在进展中，通过阅读过往周报，比较详细的了解了现有方案的由来，很多技术细节， 目标和后续的改进方向，以及曾经的探索和遇到的问题。同时也深刻体会到产品创新的不易，AI技术攻坚的困难。
uShow的分数拟合在过往的项目中多有提及，很多项目的目标不同，给到的训练材料的差异，导致分数计算复杂多变，从渤健uShow开始，在保证交付的同时，我们逐渐倾向建立统一工程规范和标准的训练素材，当然我们也畅想在不久的将来，我们可以建立面向实施部署的技术工程白皮书，实现部署的标准化作业和自助化服务。

少犯大错误，不犯小错误。

本周工作思考

Chatbot相关问题总结
随着Chatbot的客户越来越多，工程部署和反馈问题的工作也越来越多，主要呈现几个特点：
反馈问题的优先级比较高
反馈的问题多样性增加，其中有不少包含隐藏需求，比如灵活的激励体系，快速的脚本上线（其实是要求创作，生成，部署，训练，数据洞察等整个生命周期的提速，本质原因我推测是激烈的市场竞争导致的培训业务对市场应对更敏捷了）
对时间要求比较高
实施周期变长，沟通过程变长
随着以上特点的出现，并且也踩了几个坑，我也及时复盘和调整
跟进CN和UTJ的各自特点采用不同的沟通策略，目标是高效完成反馈问题
及时准确的安排任务，目前是任何任务入档，不遗漏，能追踪
让任务呈现出来，不能淹没在Slack的消息流里
脚本编辑器已经在CN和CO覆盖了5个企业，数十个脚本，对发现的严重问题，我们做了及时的跟进和解决，在一定程度上降低了脚本部署工程的难度，已经交付成本。随着这个一期功能的落地，二期功能的开发也会跟进上来，现在Chatbot的迭代要有些紧迫感了，我一直觉得chatbot未来会是平台型的产品形态，其实脚本创作就是AI内容生成的最好应用，有内在逻辑性，有主题跳转的的半开发对话如果能够利用大模型实现自动生成会是很酷的大模型应用场景。

本周工作思考

凯西问题跟进
凯西的growth模板修改chatbot的勋章名称，基于勋章的基本信息和企业绑定的，不同模板展示不同的勋章，在设计上就是无法实现的。由此我想到什么样的设计能够支持企业的定制需求。本质上说，软件产品是基于一定的规则和逻辑的，且需要长期迭代。这些规则和逻辑即是基础，也是最大的瓶颈，因为和客户的规则和逻辑不能完全包容的。
（1）从设计的角度思考，所有展示出来的都应该是可以修改的；
（2）逆向思考，如果软件产品是规则是一个集合，那如何确定这个集合的全集？
（3）从需求上来说，小需求累积会引起大需求的开发
CO问题跟进问题
CO客户反馈的问题相比CN客户反馈的问题，CO客户的问题大部分是基于Chatbot现有功能的可用性和稳定性两个方面，CN客户反馈的问题打都基于现有功能的配置型调整。本周在处理Shionogi问题时同时遇到了多个问题，同时也遇到假期，我认为处理的不够及时和有效。基于最近几个月的经验和思考，后面要快速改进几个点：
现场性解决问题，客户反馈的问题（非任务问题，比如疑似bug，使用中的疑问等）要立即进行有效的沟通，明确问题，给出解决计划，尽快执行，避免造成信息蔓延和问题蔓延
对性能疑似点和监控保持敏感性，一发现异常，立即采取措施，宁可错误预计，不要遗漏问题
建立Prompt工程化基础
在日常使用大模型做demo的时候以及langchain时，我发现大模型使用关键是Prompt，当我们做一个十分复杂的基于大模型的应用时，业务开发工程师最重要的两个职责就是理解大模型，和构建合适的Prompt工程，如果我们基于大模型开发学习平台，课程的创建，各类小节的创建，除了指令和Agent，就是复杂多样的prompt及其数据的组合，如果创建各种小节，我推测大概需要上百个prompt才能实现较好的效果，类比早期的HTML和数据的组合方式，如果直接prompt拼接各种数据，两个迭代之后，这些prompt就没发维护了，而且也没法做的有效的测评，所以prompt要以多层多类的形式构建。同时业务开发工程师和产品设计师要十分擅长某些特定大模型的数据特性，我发现同样的promot在Chatbot和LLAMA2有些不同的表现，所以熟悉特定大模型的使用非常重要。

本周工作思考

CO部署Shionogi失败问题的反思
按照UTJ伙伴的计划在周二下午14点部署新脚本，结果在部署时出现新问题。解决问题用了近20分钟，约定的时间晚了20分支。事后我想如果这个事是个重要的事件，如果是客户高层需要这这个时间点审查这个功能，那这个就是非常严重的事故。如果我提前一晚在数据库上走一遍再回滚回来就能发现这个问题，是没有时间，还是没有重视，还是意识到可能会出问题，表面上这些因素都有， 究其根本我认为是平时工作时“成事”的意识薄弱了，工作不仅仅是按部就班的完成，走完过程，而要确定得到最终的有效结果。
基于模型使用的架构思路思考
最近一段时间在跟进和学习各类模型在工程的设计模式和实践应用，初步的体会是没有一个大模型是完美的，但是各类模型的组合使用能够满足较高的商业级质量要求。Langchain的核心思想之一就是 Chain，就是连接和融合不同的模型。在实际工程中，典型的应用就是模型路由+业务规则模式，举个例子，如果学习平台的入口放在chatbot中，那整个架构就是路由模式：用户的输入Query通过语音统一转到Router层，该层是通用大模型，目标是理解意图，将语义意图翻译成指令意图，分发到其他专业层，每个专业都是专有小模型，如用户说，创建一门讲授企业中沟通协作的课程，首先语音进入路由层，通用大模型会理解意图，解析成多个意图点，创建相关，课程相关，由此转到课程创建的专有模型，而不是学习任务专有模型，也不是学习项目专有模型，此处会利用业务规则生成不同的小节，不同小节内容则有沟通协作相关的专有模型生成，生成的内容再由业务规则层处理，最后输出准确合理的课程结构及学习内容。当然这里的技术工程细节还有非常多的困难和挑战，但是此时我想我们和大多数企业站在差不多同样起跑线上，或参与、或观望，或摸索，或旁观，或追随，或领跑，都是来源与自我的认知，目前还看不出谁是赢家，我想赢家一定积极追随的那些，就像长跑一样，领跑要克服风阻要有足够的实力

第一个让我产生了一种又爱又恨的产品。

ChatGPT像是星星之火，必将点燃人类未知的AI大森林。

未来的一两百年，人类的历史恐将发生巨大的变化。

本周工作思考

渤健uShow渤健项目开发总结
之前负责过一套uShow的开发交付，这次第二次是完整的跟进项目开发过程，这次比上一次的困难一下，第一次是我认为是客户的提供的数据比较有代表性，学员演进的内容和客户给到的product和fab比较贴合，所以特性文本很很容易抓到。这次客户的给的总数据有37个视频，方差在3左右，就是各个视频的专家打分波动非常少，最高90，最低84，这些数据不好找明显特征，需要不断的在高分视频的逐字稿中寻找更匹配的知识点和fab的说法，同时又要兼顾客户要求的训练目标中的product和fab，这两套总共分析了80次左右，整体打分的相关性在0.6-0.7之间，按照经验，应该能够符合客户专家的打分习惯，又能够甄别出符合product和fab表达要求的视频。
这次项目我也尝试总结一套可复制的操作方法，希望按照这个方法操作就能够得到较好的特征文本和拟合特征。如果有了这样的方法我们就可以工程化的手段提高交付效率。目前以我的经验来看，还没有没有找到这套方法，可能有3个原因，1是ushow的理解度还是不够深刻，对单个ai技术有些掌握了，但是这些技术组合起来的效果的本质还是模糊的，这样就不能把握特征点的选取方向， 2是经验太少了，根据现在的经验没法联想和推导更多未知的情况。3是不同的企业的学员对产品点讲解和fab的讲解似乎是不一样的。通过以往的数据看，有些企业的学员有很好的产品点意识，会完整的说完产品点，中间穿插灵活的举例，引申，解释等等，有些企业的学员把产品点分散到这些举例，引申里，ai的判断的上下文容量有限，就不太能够得到完整的产品点。