本周工作思考
凯西问题跟进
凯西的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有些不同的表现，所以熟悉特定大模型的使用非常重要。