本周工作思考

本周末系统的学习了东朔老师的课程《发展大模型时代的 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 大模型的辅助设计
职责界定
参数设计
子组件拆分及分层
状态设计
关键组件的算法选择

本周工作思考

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

本周工作思考

复杂前端组件的设计及迭代浅析，简单以 任务分配组件 为例（中(3)）
复杂组件设计的重要准则之三：面向大模型的交互体验
这个准则我一直没有思考清楚，同时实践的和接触的也比较少，另外我觉得这个也是最让人所有期待的一个面向未来的设计准则。 我也一直在思考和观察如何利用AI技术改善现有的交互体验，语音交互，手势或身体交互，眼睛动作交互都有商业上比较成功的案例，也关注到很多新颖的交互方式，比如基于自然语言的业务表单生成和流程流转，基于语义的商业数据分析等等。结合现有技术和业务场景来说，特定的业务场景引入新的基于AI的交互方式会带来变革式的飞跃。最近iPhone16的预告中就透露出了一些端倪。回到企业学习和培训的这个大业务场景上说，学员端的听，说，读，写可能都会发生变化，简单的例子，随着Chrome上大模型类插件的增多，之前只能浏览英文类的文字，现在可以浏览更多的语言类的文字和视频了，这个思路其实也在启发我们思考未来的i18n方案。另一个例子，在考试，问卷等小节中，学员可用利用大模型工具根据相应的目标“针对性”回答这些问题，这也给了我们新的思考和新的挑战。当然，在类似文档，文章，音视频等内容小节上，大模型的会增加学员在这些内容的上多维度理解，这明显会促进学习效果，在学习圈，评论上我们可能会看到越来越多使用AI生成的内容，从更广义上说，我理解这些变化都会影响未来交互体验的设计。在大模型的加持下，未来我们都会面对“立体式的信息大爆炸”，而作为人类如何有效的吸收和判断对自己有价值的信息，换句话说，在大模型时代我们如何设计交互形式和信息展示形式，才能让学员们这些多种多样的信息中有效的吸收到企业需要学员必须学习到的内容，当然这也促使我们建设更深刻的业务模型来完善我们的产品。

本周工作思考

PDF 文件支持超链接
PDF文件目前在Web端上实现思路是解释PDf文件格式，利用Web端渲染方式，目前我们用到了三种渲染方式，Canvas， SVG 和 Image的方式，很多伙伴可能会问什么不是直接用HTML渲染，答案其实比较简单，就是目前常规的HTML标签无法完全描述复杂的PDF格式，特别是PDF中的高级用法，诸如不规则图形，图文混排，以及一些特效。不过，从另一个角度说Canvas 和 Image 也算是 HTML标签。
在以上三种渲染方式中，除了SVG，其他两种的都是单纯的渲染展示，交互需要额外的支持。这次优化的实现上考虑到简单性，采用一种方式适用这种三种方式。PDF.js 支持 annotation 方式，annotation 是一个修改PDF机制，它有不同的语言实现，JavaScript语言中常用的是 PDF.js。也有专门用于PDF修改的，比如 PDF-annotation.js这类小众的类库。配合其他类库，它们都能实现PDF的在线编辑。
超链接的交互动作相对简单，从我们的 标签交付惯例上，我们一般只是使用点击跳转的交互。这次在方案上，没有采用专门的 pdf annotation 库，在PDF.js基础上使用 annotation Layer 层实现了对 标签的定位，渲染和交互动作。
简单来说，就是在 Canvas 外遮罩一个透明的Div，其大小和Canvas中的Pdf的Viewport相同，通过PDF.js的节点遍历方法，找到annotation的Link节点，读取节点的位置信息，转换到外层的Div上坐标系上，然后使用Link的 Rect 信息（Box信息，长宽）在Div上增加一个不带内容 A 标签，设置其Href 和 Display。

本周工作思考

复杂前端组件的设计及迭代浅析，简单以 任务分配组件 为例（中(2)）
复杂组件设计的重要准则之一：面向多维变化的可持续设计
变化是设计目标的很重要来源，变化来自业务，组织，技术，市场，客户等不同的维度，我们要采取不同的策略来应对这些不同维度上变化，以及为应对这些变化而匹配的优先级，资源投入，收益预期都会不同。在一般设计中，很多人对这些变化等同视之，我认为这是很多设计缺陷的来源之一：过度设计，就是把业务上的功能变化看起了业务发展的上变化，设计缺失往往就是把市场的变化看成了单个客户的变化，为了应对组织上变化，必须要保证设计的可理解程度要接近组织的平均开发能力，让组织内的大部分人可以理解，可以维护这些组件的实现和设计。
在我们拥抱变化的同时，要机智的识别出变化的来源，以及在设计上应对策略。
可持续设计，来自几个维度的描述，1是与业务匹配的代码的大结构和抽象层拆分，2是团队共识的设计原则，3是制定有效的设计目标，在这三个维度中，我认为制定设计目标是最重要的。
在制定设计目标时，我认为有以下几个可以操作的点
细化功能拆解，明确功能细节和交叉功能点
功能在整个业务中的价值，这个需要对业务预见能力，要判断这个功能的在整个业务的价值，要设计的组件在功能中的作用
分析如何实现这个功能
枚举可能的变化及来源，找到尽可能完善的解决方案
枚举现在所有的约束条件，诸如项目交付的实际期望，项目时间，成本，技术能力，团队的接受度，可行性，每个变化的发生的概率
复杂组件设计的重要准则之二：面向AI的设计与实现：与AI的全过程协作
要充分利用大模型的能力，在设计和实现上充分的向大模型提出问题
充分的拆解设计目标，颗粒度要和设计目标中的约束条件对应起来，比如常用的 结构化提示词模式： 你是大模型是组件开发专家，我要做一个xxx功能，我的设计目标是xxx，我的要求是（哪些约束条件），请帮我列举出个所有的设计方案
大家在写设计方案的时候，在设计文档中添加一个大目录，主要用来描述设计中用到的Prompt，这样有多个好处
1 沉淀好的Prompt，因为Prompt的设计也需要时间，被证明有效的Prompt，我们要复用起来
2 方便其他人通过Prompt更好的理解你的设计的思路，因为Prompt完全反应了你对设计目标的理解，通过大模型也是一种知识压缩，大家可以支持复用你的Prompt获得相关的说明
实现中利用大模型做重构和部分单元测试的编写，在现有的开发模式中重构一般是在代码交付到下一个流程中的事，比如你要提交code review，然后有另一位代码审查者审查代码，然后回到你这在做修改，这个循环往复的流程是一个臃肿低效的流程，任何正视效率的公司都不会认同这种做法，但是大多数时间是无可奈何的。我读了一些关于软件工程的书籍，我认为这是老一辈工程师们总结出来的善良的错误。 合理的做法是重构发生在编写代码中，大模型可能会彻底改变这种现状，因为大模型会是很好的代码审查者，你可以随时向他询问你该如何实现，以及目前的实现如何，是不是有更好的实现。
作为组件的开发者，要作为技术架构师和业务专家的身份和大模型交流，能够判断和纠正大模型的回答是否符合我们的设计目标和业务功能要求
能够提出关键问题，资深技术专家的重要的能力体现，就是在评审设计时，能够充分理解设计的约束，目标，可行性，并且能够敏锐的识别其中的设计缺陷可能引起的现有功能的影响和对可持续设计的影响，这类关键性问题往往会引导设计质量更上一个层楼
对AI友好，要有足够的设计意图，组件功能，参数的文字描述，尽可能的注释，不远的将来，这些组件会成为我们组件RAG的数据材料，基于需求的查询不仅让工程师获益，会是让产品经理和UI设计师知道，这个需求我们需要哪些已有的组件，这种基于语义的查询会让整个开发提速。但前提是我们要扎实的建设对AI友好的组件原材料
与AI高效协作发生在复杂组件开发的全过程，包括 设计方案的确定，代码实现， code review + 代码优化，单元测试，良好的注释。业界很多人认为我们应该具备AI领导力，以此来利用AI，我认为要与AI高效协作，我们要深入的理解AI的能力和边界，AI也需要深入的理解我们的意图和诉求，我们要懂得如何让AI有效的理解我们的问题（比如我认为AI力小节），同时要通过完善注释，使用规范性命名，通用设计原则，更深入的反馈来训练和完善AI大模型
复杂组件设计的重要准则之三：面向大模型的交互体验
面向大模型的交互体验，我没有过多的经验，思考也不够成熟和完善，不过我想借此机会，抛砖引玉，请关心这个问题的睿智的伙伴们一起思考。
这里的交互体验包括两个方面，1是开发侧的开发交互体验，2是用户侧的使用交互体验
开发侧的交互体验在与Figma的需求交互，与Figma的UE交互，与Anasa的任务管理和Bug管理的交互，与Slack的沟通交互，与VS code中原有代码的交互，与开发过程中线上线下现有功能的交互
我主要开发者的视角，开发过程很频繁的情况是查询，待开发的组件要用在哪里，它和哪些功能相关依赖，有哪些组件和待开发组件类似，或者可以扩展，这些问题的回答，就是有经验的开发者和无经验的开发者的分水岭，有经验的开发者知道该怎么找，去哪里找，没有经验的开发者要花费很多精力去找这些问题的答案，这在一定程度上能够解答，我明明改了一个地方，为什么其他地方会出错；我们招聘到一个过往表现不错的工程师，为什么没有Landing好，当经验沦落为一种信息差，肯定是哪里出了问题，我觉得大模型可以一定程度上改善这类交互体验，我想多模态大模型能解决的关键问题是 需求点（文本）-UI（图片）-组件（代码）-代码文件这种查询。

本周工作思考

复杂前端组件的设计及迭代浅析，简单以 任务分配组件 为例（中(1)）
在深入叙述这个话题之前，我想说明一下为什么会以比较“务虚”（就是没啥实际代码）或理想化的方式来深入的探讨复杂组件的设计这个话题。
一：随着大模型的编程能力不断提升，作为程序员，编码能力已经变的不那么重要了，甚至在未来几年里不会写代码的程序员会陆续上岗。
二：未来（可能也就几年后）程序员的核心能力是业务的把控力和深厚的设计能力，也就是你如何让代码让大模型编写出优秀的代码，是来自开发者优秀的设计思想。设计的深度和业务的广度将会成为程序员的核心能力要求。
三：复杂的前端组件设计，对于设计的深度和业务的广度都有较高的要求。另外，大部分开发者都有一种惯性思维，会根据已有的解决方案来定义问题（这个很隐蔽，想辩驳的伙伴，可以先就这个问题仔细的观察一段时间），而大模型会打破这种“经验主义”；
四：基于大模型的复杂业务组件会是新的形态，新的思想，但是必须根植于用户体验和价值创造，可能需要从根本上思考复杂业务组件的产生及实现，以及其存在的价值；
五：我还有一个判断是基于复杂组件的创造性特点和预见性特点，按照目前大模型的架构是无法独立完成复杂前端组件的开发的。
下面继续复杂组件设计的话题
复杂组件设计的重要准则之一：面向变化的可持续设计
这个重要准则是基于上周我们所叙述的前端复杂组件设计的一般特点。这个准则是两种思想的融合，面向变化的设计，可持续的设计，我们分别阐述这种思想以及其背后的思考，最后关于实践的举证
敏捷开发思想里面很重要的一个是方面的是拥抱变化，但是作为开发者我们具体要拥抱哪些变化，为什么要拥抱变化，如何处理变化和稳定之间的关系，开发中哪些变化因素需要通过编程转为为稳定的，哪些稳定的因素要设计成变化的？这些问题，需要前端开发者认真的思考，并要得出自己的答案。我这里分享我的思考，做为 参考答案。
我们公司的“人，产品，利润”的思维模型出发来梳理和思考这些问题。
和我们有直接关系和间接关系的“人”都有哪些呢？直接的用户，用户的老板们，用户的学员们，我们研发组的伙伴们，我们产品组的伙伴，我们的客户界面的伙伴们等等，这些“人们”每一个人都有不同的个性，但是他们是 变化 的起因，也是他们，而不仅仅是组件的开发者，在共同塑造着组件的形态，组件的功能，组件的价值，没有用户的使用，不可能有组件的需求，没有后端的伙伴，不可能满足组件的数据特性，没有客户界面的伙伴，组件就不太可能真正的服务到用户。啰嗦这么多，我是想明确一件事情，组件开发中的变化来源于所有干系人相互影响的结果，但是我想强调的是，从汇总的结果往上追溯的话，不同的干系人的动因对整体结果的影响的系数不同。这是我们需要在设计中需要考虑的。
大家都知道从实现角度上看，产品会被拆分成很多子系统，子系统被拆分成很多模块，模块又被拆分成各种复杂的复合组件。假设我们把这些复合组件打个包，卖给客户，客户会愿意为此付款吗？肯定不会，因为这些组件不会解决用户的问题，也就是说，不能自主的产生服务。产品的定义是基于产品要解决的系统性的共性问题而产生的一个被部分市场认可的可以有效解决这些问题的系统性方案，也就是通过解决一系列问题而产生的整体效果，这里即包含了软件的部分 ，也包含了“人的思想”（效果学习的思想，客户服务的思想（形成一揽子的客服服务流程，客户服务标准等等））的部分，从这个角度思考，组件是“人”的思想的产物，是 产品 服务 客户 的工具，这就是组件设计时要考虑产品，考虑客户，考虑市场（同行们做了什么，待开发市场可能需要的是什么），这里面是不是也包含了很多变化的动因？
坦白说，虽然大模型可以很清楚的描述这个概念，但作为普通开发者，我很难讲清楚 利润 这个复杂而深刻的概念，不过我想试着从开发者的角度厘清与之相关的几个关系：
有效的复杂的业务组件会直接创造企业利润
优秀的复杂的业务组件是产品最好的代言
高质量的复杂业务组件是企业中最有生产力的工具
如何有效的创造企业利润是组件设计中最大的变化动因

本周工作思考

复杂前端组件的设计及迭代浅析，简单以 任务分配组件 为例（上）
这两周清理历史Bug，分析阅读了很多代码，这些代码有些是多年年的，有些是新近写。和大家分享有一些关于复杂组件迭代的思考，有一些还没来的及想清楚，很抱歉要分多次写了。
目前我们Web前端的编程范式大致是基于React的组件化编程，甚至路由也是一个组件，我们在UI上一切皆是组件（text特殊，在React中，text是唯一不具有fiber node的组件）。如果构成页面的是一个组件树，那在设计和实现页面时，我们如何界定组件层次，如何判别可单独迭代组件呢？这里面涉及到三个重要问题：
第一，组件的设计交付；第二，组件的功能交付；第三，组件的迭代交付；
这里有一个很容易让很多开发伙伴疑惑的地方，设计交付和功能交付不是一回事吗？或者说功能的实现肯定包含了设计了呀？在日常开发中，大部分组件的设计和实现确实表现的是一体两面，行业里的做法也通常是交付了功能，即是交付了设计，包括很多资深开发者也持此观点。
组件从专业分类有很多种分类方式，我们这里讨论的分类是简单组件和复杂复合组件。这个分类的标准是业务职责的大小和组件本身的复杂性；业务职责大小，只要熟悉业务就很好辨别，比如 任务分配组件；组件复杂性可以从以下两个现象来判定：
组件的嵌套关系，即子组件的复合程度
组件内部的状态数量和逻辑关系
复杂前端组件就是指在完成一个单元类业务职责时，其内部子组件嵌套层次深，且组件内部状态的逻辑关系多，这类组件内，你往往能看到大量三个以上状态的逻辑组合判断，类似，if a == xxx or b == yyy and c != zzz
前端组件千千万，但都有一个最根本的共同目标，创造客户价值，从本质上来说，Web前端工程师价值是通过组件呈现的。同时作为企业，追求利润是第一责任，作为企业中的一个团队，其目标是是追求利润的子目标或者子任务，即效率和效果，我认可德鲁克对效率和效果的阐释：所谓“效率”，就是把事情做对；所谓“效果”，则是做对的事情。公司和上级会指导我们把事情做对，但我们每一个人必须弄清楚哪些是对的事情。基于此逻辑，我认为开发者需要弄清楚在开发组件是对的事情，不做，或者意识不到，并不意味着对的事情不存在。复杂组件的设计交付就是这类对的事情，但是往往被忽视。
组件的设计交付，我们常听到UI设计师，产品设计师有设计交付，很少听到前端工程师有设计交付。这是因为绝大部分前端团队都不会为一个组件的设计召开技术评审会，也不会编写一份组件的设计文档，但是设计确实是组件本身的固有属性，复杂组件的设计一般有如下特点：
滞后性
隐藏性
多样性
脆弱性
难评估
创造性
预见性
分别解释下各个特点
滞后性 是指设计的最大效果往往是产生的在后续的迭代中；
组件设计的隐藏性包括两层意思，一是，组件本身的发展就有隐藏性，在敏捷开发中，有时候我呢很难预判一个业务组件后续的发展形态，另一层意思是设计本身隐藏在实现中，组件作者的设计意图不易明显化，有大量代码阅读经验开发者应该能够也体会这种隐藏点，代码阅读的乐趣之一，就是你能悟透作者的设计意图。
多样性是指同样的功能，具有多种设计和实现思路，好比爬山，山顶（功能）只有一个，但是上山的路却有很多条；
脆弱性和隐藏性相关，在一个复杂组件的迭代中，一个设计思路往往不能得到长期发展，这里有大概三个原因：1是业务迭代突破设计的界限，2是设计本身存在缺陷，不支持后续的迭代，3是后续迭代者不理解设计思路，强行终结了该设计的发展潜力。
难评估，很多开发者认为开发中的技术评审会是走过场，这里面很重要的原因是 设计评估 真的很难，如果评审委员中没有能力高强的人，很难对设计方案做出有效评估，这里面的原因很多，最重要的一个原因我认为是，设计始终是是面向未来的，面向客户价值的。
创造性，任何复杂业务组件的设计都有其独特的一面，这种独特性必然是会有独创的设计才能实现；
预见性是指组件一定要能够适应未来的迭代，也就意味着组件的设计必需要有一定的可预见性；

本周工作思考

在技术设计上，完全可以应用这个思想：
拆分：拆分是分层思想的通俗表达，同时也包括了业务分解的需求思想。化到业务上，新的升级首先要分解需求目标，不同的需求目标考虑用何种AI技术解决和使用哪类大模型；
路由，路由是组合思想的高维表达，路由不仅包括组合，也包含了智能决策思想在里面，数据如何流转，业务如何进行，服务如何调度，都是路由；拆分后任务，需求，不是以现在组合的方式交付给客户，而是路由的方式，也就是说流转中的状态，路由中的下一路由是有关联的。uShow中，知识点 的整体表达会影响到 逻辑的呈现，在最后的评价体系中，知识点稀疏不同，表达不同，会通过大模型的任务决策路由到不不同的逻辑点和总体评价服务，这种不是组合。这个是和实际中的场景十分贴合。简单的例子，开场白不好，很容易影响观众的第一印象，后面整体的评价和信息接受度都会受此影响。
生成，生成不是大模型时代特有的技术思想，但是在大模型时代必定是大放光彩的工程技术思想，生成不仅包括大模型中的语言生成，同时也包括，规划计划，目标，推理过程等目前只有人类能输出的结果，uShow 中应该不会用到规划和推理类的生成，主要用多模型做多维任务评价生成。
综合，其实是我理解东朔老师可能没有找不到更合适的词来表达他的思想，我还不是很理解，我现在的理解是综合 包括了融合，整合，组合，分析梳理，监控监管，总体管理的意思，经过以上是三个工程思想的处理，已经基本处于可用的状态，uShow的整体流程的路由，可以完成了整体的任务目标，但是我们都知道 1 + 1 > 2的思想，在传统软件思想中，这个作用是通过 结构 表达和体现这个思想。所以软件架构本质上是结构，工作流的基础是组织结构和信息结构。但是在大模型应用上，大模型对每个模块都增加了极大的助力，不仅改变了程序的代码结构，也改变的决策结构，if-else的组合升级为决策性的路由，这是我们所有的组件都带有了一定程度的智能，那么智能 + 智能可能就是接近人类中的专家了。