本周工作思考
复杂前端组件的设计及迭代浅析，简单以 任务分配组件 为例（中(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（图片）-组件（代码）-代码文件这种查询。