本周工作思考

最近一直在探索Agent在开发中的使用。最近通过自己搭建和或者在豆包上尝试搭建自己开发助理有一些小小的思考。在前端开端开发中经常回到遇到一些常规性的任务，比如：-
后端API接口转成前端代码，小步骤包括
入参，输出类型化
fetch自动生成
文件名自动生成
前端自动化测试case函数生成
由Figma转PRD文本，转代码文件，小步骤包括
Figma生成PRD
文件名生成
变量名建议生成
组件分层
代码结构生成
PRD文档生成自测Case，多语开发流程等等。
这些常规的和程式化的开发任务借助大模型和Agent都应该可以实现自动化或者提高自动化程度，甚至可以打通内部vscode，gitlab，Jenkins，Chrome环境中的开发工具。但是使用外部的Agent平台是没有办法完全打通我们这些内部环节的。我建议内部搭建一个可以公司全员使用的Agent平台，大家在学习和使用过程中逐渐打造自己的Agent助理，进而提升公司整体的工作效率。
uShow礼来-唯泽的调优
因为客户对训练视频的打分做出了比较明确的说明，所以在这套片子上我和伟华做了比较细致的拟合，在伟华初版的拟合的基础上，我做了二次的拟合调整，主要是将高分和低分明显化，因为目前系统设计和模型的问题问题，目前系统Logic打分偏高，FAB打分偏低Logic，而产品知识点的区分度不明显，针对这些问题，在这次拟合中中，我尝试了使用手动的知识点矩阵分析法，调高高目标视频得分，压低低目标视频得分，目前看效果较好。当然这个和这套片子的训练视频的明确的高中低分档的要求有关，有明确的高分，低分，以及区分度不大的中档得分，这样就可以区分性调整标签，使其明确在高分区还是低分区。

本周工作思考

Prompt的新理解<提示词的道与术>
2024AI创新者大会（文字版 https://juejin.cn/post/7425465495971807266），有李继刚对的Prompt分享中有一个简洁的理解说明，Prompt版乔哈里视窗，为了理解我自己草稿了一个。
我在日常使用Prompt工作时，有不同的任务，有一些是深入的问题，比如如何理解React中fiber设计模式的优劣及日常开发中如何应用，再如请从设计角度深入讲解Saga.js的实现，请举例说明在那些开发场景适合使用Saga.js；还有一些比较浅显的问题，具体使用我不记得了，比如IntersectionObserver是怎么使用的。
从下面的图上我们可以看到很多内容，比如你知道的越多，你的Prompt可能就会越简单，Prompt中的简洁不是对所有人都适应，简洁是建立的精确的基础之上的，比如AI是知道IntersectionObserver的，但是你不知道，就要就要用很多的词，甚至是举例说明的方式来表达用什么方法表达Dom的显示和隐藏，所以知识/经验越多越有利于你和AI高效的沟通，这显然对小白不友好，这从另一个角度说明，在AI时代，知识的掌握对自身发展依然是最有效的。
在专业知识上，我们可能会遇到AI知道的少，而我们知道的多情况，这时候few-shot（喂模式）的Prompt方法可能就会很有效。
用户体验的思考
这周在做页面迁移的时候，把个别页面的性能也做了一个overview，有的页面卡顿严重，线上和线下都有会出现类似的情况，目前前端也在针对性的解决一些这样的问题。
丹尼尔卡内曼认为，人们对体验的记忆有两个因素决定，巅峰时和结束时的感觉，这就是所谓的峰终定律。结合我们的日常的体验，重要的时间节点，事件节点也都会给我们留下深刻的记忆，比如我们Kickoff时考试时看自己得分的时候，当你有满分时，会有一个撒花的效果，我相信很多人不记得当时Kickoff的内容，可能记得你得满分看到的撒花的那个瞬间，这种记忆往往深刻而难忘的，而用户体验有时候是非理性的，往往是由这些或好或坏的感受的记忆瞬间决定的。在很多研究人类的思考和决策机制的书籍中，人们的很多决定很多时候来自“快思考”，体验感觉又是“快思考”重要素材和支撑。从这个角度理解， 用户体验 是“人，产品，利润”中非常重要的思考引线。
我理解良好的用户体验，应该由流畅的使用过程，令人难忘的瞬间和完美的结尾构成。
流畅的使用过程是指在产品使用过程中，交互过程和用户的思考过程保持一致，这有两个关键指标，1是交互逻辑是否符合用户的平均认知水平和预期，2是交互响应是否跟得上用户的敏捷度。在我们的研发工序中，交互逻辑主体由产品经理决定，交互的响应由工程师决定。在用户旅程中，用户刚开始主要是学习交互逻辑，交互逻辑熟悉后，用户的主要体验点在交互响应上。比如A企业的管理员和经理坐在一起就最近两个月的学习任务情况做一些业务分析，如果从点击查询按钮到数据展示是30s，那这个30s可能就是管理员和经理“相顾无言”的比较尴尬的30s，而如果是5s出数据，那么两个人的思路将不会受到任何限制，可以继续“头脑风暴”，所以流畅的使用是必须具备的品质。
令人难忘的瞬间，流畅的使用过程之上，如果适时的制造一些小的惊喜，出人意料的装饰，可能会获得日常紧张工作中的愉悦感和松弛感，这种情绪上的体验最是重要。
完美的结尾的指交互的结果要指向用户的业务结果或者绩效，这一点我觉得我在以前的工作中也思考的比较少，最近一两年我开始深入了解管理的一些理论的时候，我逐渐领悟到现代知识工作者的效率往往来源于他和工具的协作效率，我们的产品的有效性也体验在交互结果的有效，比如很多很多下载列表可以定义下载字段，这其实是提供了一种查询结果有效性的机制。当然其实我们也可以继续深入做下去，比如这次的复杂查询能不能保存有快捷查询，下次我可以直接查询使用。

本周工作思考

Com环境部署及问题联调解决
uShow的COM的部署主要解决了几问题：
Go uShow 服务，Pyhon服务等服务代码版本对齐
EN语言使用的功能上版本，CN，CO上目前使用的是V2版本，EN上使用的是V1版本，V1和V2的差异是在评分维度上差异，V2版除了代码架构的不同，在评分维度上增加了逻辑的承上启下关系的识别，开场白中关于号召类语句的识别，正文中关于打比方，FAB特征的识别，总体而言V2中的评分维度比V1多，所以评分也更客观，更有说服性。
帮助Devos的伙伴们解决了推理服务的部署的问题。
甄别了EN语言中实际需要的各类小模型和缺失小模型的具体情况。这个在之前的交付中没有遇到过此类问题，研究的也不够清楚,这次摸透高清了。
关于Prompt和Agent的思考
上周整体阅读了东朔老师的ATD文字稿，仅仅阅读不认为是学习，对于我认为重要的资料我一般采用多次阅读和思考的精读方式，直到我想不出别的问题了或者我认为理解了其内核思想或者找到行动的点才算学习的结束。学习完整个文档，里面关于Prompt的论述启发了我对AI原生的应用的很多思考，我想也很能是未来应用开发的迭代方向之一。
1 基于AI的应用在架构上增加了一层Agent及Agent控制决策层，这一层负责控制工作流及完成功能调度，比如Dify，AgentGPT都是这一类的框架，但是未来的迭代中，类似的框架中的能力会和业务框架深度融合，形成垂直业务架构的一部分，也可能会和DDD这样的领域思想和框架整合起来
2 在应用层上面向Agent的Funcion Tools会替代现有的功能开发，与现在功能模块比较起来，这类功能是垂直业务的，更容易被Agent调用，同时，很多较大的模块本身被一个Agent包裹，提供特定的能力，供Agent调度层调用。
3 Prompt在开发中的使用用途上会分成三类：
1 系统层面的Prommpt，比如系统能力的角色，调度计划，分拆任务，评估类的Prompt。
2 应用层面的Prompt，解决具体的业务问题和业务流程的Prompt
3 用户层的Prompt， 1，2类Prompt很好理解，我们现在也在使用， 用户层的Prompt是指和用户可以输出的Prompt，因为用户解决的问题不同，使用Prompt的方式不同，结果也就不同。比如A讲师和B讲师负责的培训业务不同，在生成一个文档时，他所使用的Prompt就是不同的，在未来的迭代中我们可以在系统中把讲师的Prompt管理起来，在不同的小节，讲师们可以直接调用或者可以通过AI力，调整其中的参数，这一层，我们构建了基于UMU 所有Tools的可以自定义Prompt的Agent系统，它不同于Dify，AgentGPT类Agent框架，他是基于UMU现有功能集合之上的Agent，并且用户可以自定义Prompt及其参数，这可以成就每个个体对Prompt的大模型的应用能力。

本周工作思考

Prompt的使用
本周自己的Prompt库又多了几个专家：celery技术专家，chatbot对话专家，Angularjs的Typescript类型提取专家，Angularjs性能优化专家，随着专家类型的积累，日常工作的专家团队已经逐渐建立起来了
周末再看一篇关于Chatbot DST 论文时，学到一个反幻觉的技巧，我试了下还可以，非常简单，分享给大家：If the value does not exist, return the value as NONE.
@yuanyuan强烈种草的的copolit新功能也非常好用，比直接ChatbotGPT和cursor好用，前端工程师可以把更多的精力放在需求的理解和功能的精良设计。不过也要注意数据安全，我们不想让外界知道的数据一定尽量不能让外界知道。
最近我也在思考在AI时代，前端工作需要怎么升级迭代，面对的用户的使用习惯发生了怎样的变化，用户喜欢什么样的交互和产品，未来的前端应该是什么样子，需要创造什么样的价值，我现在还没有想清楚。
东朔老师的ATD文字稿看了一半，太精彩了，我觉得从AI应用的层次把思想，策略，技法，迭代方式都讲到了，AI已经逐渐渗透到研发的方方面面了，AI不是替代人，AI是增强人，人类已经存在数万年了，人类的能力就是可以适应环境不断进化，在AI时代，我想大部分人都可以不断地适应，成长出和AI并存的能力，我想我们的产品已经做这个工作了。
PC端多维度评价样式问题，这个问题让我思考了很多，对我而言这不是什么技术难题，不是我不能解决的，也不是想不到，为什么会出现这个错误，这个看起来是态度问题，或者是能力问题，在我看来就是缺乏追求卓越的表现。日常工作把自己困在开发任务里，追求卓越，就一定要站在高，看的远，做的细，踏的稳。

阳历2024年9月29日下午，我接到了父亲给我的电话，内容很简单：恁姑父没了，十一早些回来！

谨此沉痛悼念我的姑和姑父！

本周工作思考

研发中Prompt的组织方式的思考
正如我之前周报中分享的那样，前端中很重要的工作是写组件，由此而衍生出很多相关的工作及生态的发展，模块，构建，组件，框架构建了前端日常开发中的常见主题，AI类应用大概也会遵循这样的模式，从研发成熟度上说，AI目前处于类似JavaScript发展的早期，也就是还处在讨论如何模块化的阶段。
在阅读一些AI类产品的源代码时，很多源码中的Prompt是分散到代码里的，这给Prompt迭代带来很多问题，也就是Prompt如何工程化，比如
谁来写Prompt，Prompt是产品设计吗，Prompt是代码范畴吗，还是Prompt工程师
Prompt导致的线上问题，由哪个角色负责跟进调整
Prompt的对应的模型基座升级了，Prompt如何调整
如何保证Prompt的质量以及迭代后的质量
正如我之前周报中分享的，一个AI应用中，解决方案被分解成了50个Prompt，这些Prompt的关系是需要怎么显性的表达，如何保证调整了其中的一个Prompt而不影响其他的
用很重方式组织成有序的Prompt
不同语言下的Prompt，如何高效的管理其中的细微差异
Prompt的调试
Prompt和对其预期的管理
当然我们面对的问题远不止这些，但是这不影响我们的积极探索，正是因为这些问题的有待探索，也才使得我们的工作更有价值

本周工作思考

本周末系统的学习了东朔老师的课程《发展大模型时代的 AI 力》，对RSTCC 框架和很多高级技巧很了更多的理解，同时也是一专题的形式学习了整个课程，特别是高级技巧部分，特意拿出字幕仔细学习理解，也查了一些相关资料，收获非常大。
这门课有很多前沿性的知识，课程结构设计的也非常合理，在学习过程中也看到了几个小问题
视频中文字资料展示部分非常的快，没来的及看，就转回到主画面了，只能暂停看。我觉得可以时长稍微多一些。
Prompt高级技巧的部分，时间有点短，看的不不够过瘾。
万字见闻｜SaaStr Annual 归来，AI 已来，SaaS 未死，效率成新常态
这一部分是利用kimi断断续续的看的，信息量太大了。看下来有几点思考：
积极把AI技术用现在产品的创新上，在“效率”上做到以前想做不敢做的事情，作业加上AI之后，有了非常好的市场，我们还有很多小节依然有很多用户在用，也应该加上AI的引擎，让它们也跑在AI上。
AI的终局应该是元宇宙，这个“宇宙”的建设需要方方面面，产品设计，工程基建，市场，用户都需要接受这次AI的洗礼。
AI慢慢变得不会那么热，但是会变成关键基础设施。
AI的发展会让小型公司越来越多，追求效率至上，这类小公司成本方面除了智力成本就是AI算力成本，但是可以创造巨大的价值。

本周工作思考

最近在使用ChatGPT中有意识的使用结构化的Prompt，类似https://www.waytoagi.com/prompts 这类有大量这类的使用，我发现对于开放性或者半开放性的问题，这类Prompt写法的效果比较好，我想这里面的原因是很可能是没有标准答案，或者不需要可解释性非常多。另外的一个问题就是稳定性不太好，同样的问题，回答每次都不一样，给的理由又似乎很充分，我分析是两个可能的因素，1是任务没有拆分好，AI也只能给出概率类的结果，没有应用到大模型推理能力，2是对问题本身的理解有问题，也就是Prompt的思路不对。解决问题关键似乎转换成，什么样的Prompt能解决这类问题，我急切想想学习其他公司或组织如何使用大模型在具体的场景中取得良好的效果，经过对一些Coze上案例的了解和学习，我认为开发者一定具备产品思维和系统思维的意识，这两点我似乎都比较欠缺，这就容易导致Prompt的思路不容易取得预想的结果。
我发现调试Prompt还是很费时间的，思路不对，似乎怎么调，都无法取预想的结果。 我尝试autoPrompt，但是这里面遇到结果自动评估难的问题，要真正成为大模型的使用高手，也得需要不断的实践和思考总结才行。

本周工作思考

复杂前端组件的设计及迭代浅析，简单以 任务分配组件 为例（下（1））

关于组件实现，目前我们很难制定出非常详细的开发细则，只能大概定出开发规范和工程基础，比如我们定出输入输出，UI规范，定出组件的使用，打包方式这些工程上基础，组件功能就是每个开发人员根据组件的具体功能去实现了。
前端也一直在推动组件化这件事，这个事很难但是非常有价值，所以值得的持续迭代，因为组件化这个事根本上是产研工作流的标准化过程，涉及到产品设计，UI设计，功能设计，测试，甚至是终端的用户体验和品牌影响力，这需要一致的共识和执行，也就是说是要整个产研的一起努力做下去的事。
组件实现需要考虑的点，每一个点都可以让ChatGPT展开讲很多，不过以下很多的点在实践中还需要结合场景，具体问题具体解决，不能一概而论，但我认为了解公司的愿景，产品战略，研发原则，会对以下各方面的技术决策有好的影响。
渲染与性能
设计扩展与迭代
何时拆分以及组件升级的处理
重构背后的成本和工程考虑
CSS复用性权衡
兼容性设计
可测试组件的设计
利用 AI 大模型的辅助设计
职责界定
参数设计
子组件拆分及分层
状态设计
关键组件的算法选择

本周工作思考

首页推荐多模块开发
该功能原来的功能是非常内聚的一种实现思路，当前的迭代功能和原来的实现思路完全不能兼容，除了基本的样式类组件，卡片类组件外，基本上要重新实现，另外涉及到原来功能的兼容，所以当前的实现比较新增一种功能更加复杂一些
基本思路是增加一种多模块的思路，和目前模块的思路完全兼容。现有实现还有一个问题是没有实现组件化，就是一个大组件实现了整体功能。所以在开发新功能前，需要使用组件化现有的实现，才能在此基础上迭代新的功能。
这块代码有六年左右没有彻底的迭代，从现有的开发思想和经验来复盘当时的设计和实现：
组件化的粒度要保证功能拆分一致
功能的拆分要遵守职责单一原则
设计一定要有可扩展性，在产品开发中，设计扩展性可能是最重要的和关键的开发能力