发动态
综合 最新发布 最新回复
图文
列表
大家好,我是双越。前百度 滴滴 资深前端工程师,慕课网金牌讲师,PMP。开始AI 刚开始出现的时候就是一个 chatbot 聊天对话框,后来逐步增加功能,可以连网、可以配置 tools 和 MCP ,再到 Agent 自定义工作流。有了 Agent 就可以把 AI 应用到各个真实的业务场景中,这是一个逐步进化和落地的过程。例如我们程序员最熟悉的 AI 编程就是一个 AI Agent 很好的落地,就在这 1 年之间已经广泛应用。Dify 和 Coze 等平台可以直接手动定义工作流,配置出一些个性需求的 AI Agent 并发布使用。8 月底国家颁布了“人工智能+”的行动意见,无论是中国还是世界的 AI 应用将会在未来 10 年内持续发展,遍地开花。我个人也会继续在 AI Agent 领域继续深耕,把我擅长的面试、刷题、简历、教程等领域全部 AI 赋能,使用 AI 增加效率,以更快捷的服务于更多用户。本文站在前端开发人员角度,介绍开发 AI Agent 智能体所需要掌握的知识范围,供大家参考。LLMAI 的基础是 LLM 大语言模型,例如现在大家熟知的 ChatGPT Gemini Claude Deepseek Qwen Grok Llama 等。我们常见的使用方式是在线调用它们的 API (可能要付费购买 token),当然也可以本地部署内网使用。LLM 是什么呢?当前所有 LLM 的核心简单理解就是:预测下一个词。LLM 不是“聪明”,也不能理解人话,而是“被喂了整个互联网数据然后疯狂补全”。你设计得越好,它补全得越准。LLM 参数就是“记忆单元”,像人的神经元,参数越多(训练成本大、运行成本大)也就越“聪明”,补全的越准。例如你的输入是“猴子喜欢吃”,LLM 会在自己海量的训练数据中计算,找到一个列表,其中“香蕉”的概率最大,它就返回“香蕉”。包括写诗、写代码、画图,也是根据 prompt 输入来补全内容,只不过不是一个词,而是海量数据训练出来的一个结构化输出。包括 Agent 和 tool 也是一种“补全”,根据 prompt 去猜测使用哪些 tools (每个 tool 都有描述、参数结构)LLM 的两种交互方式:Completion 模式(纯文本补全)👉 GPT-3 —— 现在基本不用了Chat 模式(对话形式,输入消息列表,输出新内容)👉 GPT-3.5/4MoE 混合专家模式,拆分多个子 LLM (总的太大了参数太多了)每次只激活其中几个,这样运行成本低。 模型微调也是调整其中很少一部分参数,改变它的预测取向。Prompt EngineeringAI 的生成内容和质量是严重依赖于 prompt 提示词的,你给出的提示词模糊,它生成的就一定是模糊的答案。例如,我们在使用 Cursor 时一般要写一个 cursor rule 文件,规范代码标准,这就是提示词的一部分。严格来说,Prompt Engineering 提示词工程 并不是什么技能,它就是一些沟通方式,很容易理解我们可以通过提示词来约束用户的提问,如 github copilot 只专注于编程领域,问其他问题它不回答。还可以通过 CoT 思维链模式,引导大模型按照我们的思路去思考。还可以规范 AI 的输出格式,或让 AI 做出一些判断和选择。在实际开发过程中,每次调用 AI 请求我们都会认真思考提示词该如何写,甚至会使用 AI 写提示词,或者在线生成提示词。并不是用户输入什么,就原本的传给 AI 接口,要做很多包装和转述。LangChian.jsLangChain.js 是前端人员使用 Nodejs 开发 AI 应用的首选,它的 LangGraph 可以自定义 Agent 工作流,它的 LangSmith 跟踪和分析 Agent 运作流程。LangChain 是一个非常好的开发生态。RAGRetrieval-Augmented Generation 检索增强生成,这是 AI 搜索资料辅助生成答案的有效方式。它的核心步骤是:1. 把资料拆分为向量格式,存储在向量数据库;2. 用户提问时去向量数据库检索相关答案;3. 把这些相关答案发送给 AI 配合一起生成最终答案。对于前端开发人员,不太好理解的就是 Vector 向量。Vector 向量,就是坐标。生活中常见的有二维、三维坐标,方便计算距离。而我们可以把一段文本、图片等,转换为多维(几百维度)坐标(float 数组),两个坐标的距离(如欧氏距离、余弦相似度),就是两段文本(或图片)的相似度。Elastic Search 可实现搜索引擎,但它只是关键词匹配,例如“教程”关键词匹配不到“课程”,它是严格的文字匹配。而向量就能匹配到,它是相似度匹配,语义搜索。PS.现在 elastic cloud 也有向量存储。Vector store 向量存储技术选型:开发阶段用 Chroma,部署后切换为 Pinecone 或 Supabase 都有免费试用额度。技术大厂,前端-后端-测试,全国均有机=会,感兴趣可以试试。待遇和稳定性都还不错~AgentAgent 是一个综合体,它主要包含LLM 大模型,负责思考和生成内容,一个 Agent 可以有多个 LLM ,不同节点配置不同的 LLMworkflow 工作流:定义节点、方向、判断,以实现 Re-Act ,让 AI Agent 自行判断逻辑tools 工具:调用外部的服务,例如搜索、查询数据库等memory 记忆和存储:记录当前对话和用户的关键信息下图是 Flowise (类似于 Dify 和 Coze)给出的一个 RAG Agent 工作流配置的示例。MCPModel Context Protocol 模型上下文协议,是规定大模型参数和调用的一种协议,让 AI 可统一调用第三方的服务。当前我们谈 AI MCP 主要是说各个 MCP server 能够提供的能力。还有,我们也要能自己开发 MCP server 以及开发 client 去调用 server ,要有这方面的能力。多模态现在的 AI 应用不仅仅是文字聊天,你可以可以上传图片、PDF、word、甚至音频和视频,都可以传给 AI 大模型进行处理。同时,AI 大模型也可以生成图片、PDF、音频和视频。即,现在的 AI 应用要支持多模态。AI 生成的非文字内容,往往通过 Artifact 形式展示。例如使用 Claude 生成一个 HTML 网页,它在右侧直接展示了网页渲染效果,并且还支持发布上线。不同的 AI 大模型擅长不同的模态形式,也有不同的 API 调用方式和参数的写法。其他AI Agent 还在发展之中,还有更多的技术需要学习和实践,后面我会逐步分享Multi-agent 多智能体架构A2A 协议,Agent 和 Agent 之间的通讯协议Context Engineering 上下文工程AG-UI 协议,Agent 和 UI 的通讯协议最后我个人也会继续在 AI Agent 领域继续深耕,把我擅长的面试、刷题、简历、教程等领域全部 AI 赋能,使用 AI 增加效率,以更快捷的服务于更多用户。关注我,我会继续分享更多 AI Agent 相关内容。——转载自:双越AI_club
前端开发 AI Agent 智能体,需要掌握哪些知识?
开源硬件平台
MCP 出生时,被捧得很高。2024 年 11 月,Anthropic 发布"模型上下文协议",几乎所有 AI 开发者社区都在讨论这件事。它的定位很诱人,要成为大模型和外部工具之间通信的"通用标准",有点像当年 HTTP 对 Web 的意义。一时间,MCP server 满天飞,各种集成教程、开源实现层出不穷。但时间只过了一年多。上周,Perplexity 的联合创始人兼 CTO Denis Yarats 在内部表示,他们正在放弃 MCP,转而改用 API 和 CLI。这个消息扩散出来后,引发了一波讨论,但讨论的内容不是"为什么",而是"早该如此"。Y Combinator 的总裁兼 CEO Garry Tan 甚至直接说了一句话:"MCP sucks。"MCP 的问题从来都不是技术实现不够好很多人对 MCP 的质疑,停留在"不稳定"、"认证烦"这些体感上的抱怨。这些问题确实存在,但它们只是表象。MCP 真正的困境,是一个结构性问题。MCP 的工作方式是,把工具的名称、描述、参数结构(Schema)以及使用示例,全部注入到 Agent 的上下文窗口里。Agent 读完这些信息,再决定要调用哪个工具。这个设计在工具数量少时还可以接受。但你一旦接入 10 个服务,每个服务有 5 个工具,光是工具定义本身就已经烧掉了几千个 token。Agent 还没开始干活,上下文就已经塞满了一半。上下文窗口是 Agent 最宝贵的资源,它决定了 Agent 能看见多少对话历史,能保留多少工作记忆,能有多大的推理空间。MCP 的代价,是把这个资源拿来"列菜单"。面对这个问题,现有的出路只有三条:一次性加载所有工具,接受推理性能下降限制接入工具数量,接受 Agent 能力边界收窄构建动态工具加载机制,接受额外的延迟和复杂度三条路都不好走。这不是"实现质量"的问题,而是协议设计本身的代价。除此之外,日常使用中的痛点也不少。MCP server 启动失败是家常便饭,有时重试能解决,有时必须推倒重来。接入多个服务就要在每个服务上重新认证一遍。权限管理也只有"允许"和"不允许"两档,没有办法把某个工具限制为只读,也没有办法约束它可以传什么参数。技术大厂,前端-后端-测试,全国均有机=会,感兴趣可以试试。待遇和稳定性都还不错~CLI 是更好的答案,不是因为它新,而是因为它够旧工程师 Eric Holmes 写过一篇文章,观点直接:MCP 没有带来任何实际价值,LLM 完全可以自己搞懂怎么用 CLI。这话有点刺,但它说的是实情。大模型在训练时看过海量的 man 手册、Stack Overflow 回答和 GitHub 上的 Shell 脚本。它们对 CLI 的理解,远比对某个 MCP server 的理解深得多。给它一个命令行工具和一份文档,它就能上手,不需要特殊适配。CLI 在几个关键点上,比 MCP 天然占优。第一是可调试性。当 Claude 对 Jira 执行了一个出乎意料的操作,你可以直接跑同一条 jira issue view 命令,看看它看到了什么。输入一致,输出一致,没有谜团。但 MCP 的调用只发生在 LLM 的对话内部,出问题了只能去翻复杂的 JSON 传输日志。第二是可组合性。这是 CLI 的核心竞争力。你可以用 jq 过滤数据,用 grep 串联逻辑,把输出重定向到文件。这不只是方便,很多时候这是唯一可行的路。MCP 没有这个能力,你要么把完整数据塞进上下文,要么在 server 端自己写过滤逻辑,两种方式都在用更多的精力换取更差的结果。第三是认证。CLI 复用的是系统级别的认证体系,这套东西已经经过几十年的打磨。MCP 需要你重新为每个工具搭一遍认证流程。这件事说明了什么Perplexity 放弃 MCP,以及其他工具陆续移除 MCP 支持,这件事背后有一个更值得思考的信号。给 AI 构建工具链,不需要发明一套新的协议。AI 需要的工具,和人类需要的工具,在很多时候是同一套。最好的工具是对人类和机器都好用的工具。CLI 存在了几十年,设计上一直遵循一个哲学,每个工具做好一件事,然后把工具组合起来解决复杂问题。这套哲学放到 Agent 身上,依然成立。MCP 想构建一个更"现代"的抽象层,但它解决的问题,现有工具已经解决得够好了。在不需要额外抽象的地方强行加一层,带来的只有额外的成本和复杂度。当然,MCP 不会完全消失。在某些特定场景,比如需要强类型 Schema、有严格访问控制要求的企业内部系统,它依然有它的位置。但作为"AI 工具集成的通用标准",这个定位恐怕很难站稳了。参考:MCP is Dead, Long Live the CLIDenis Yarats on X——转载自:Moment
从爆红到被嫌弃,MCP 为什么开始失宠了
开源硬件平台
提到 JetBrains,相信程序员和开发者们都再熟悉不过了。作为一家全球领先的软件开发工具提供商,他们打造的多款编程软件曾经都深受全球万千开发者喜爱。但是,伴随 AI Coding 的加速冲击,这家公司的很多产品策略,如今也在被迫作出各种调整。这不就在前几天,JetBrains 在其官博里又官宣了一项重大的软件服务调整,那就是:将正式停服 Code With Me 软件服务。提到 Code With Me 这项服务,不知道有没有同学用过。还记得 JetBrains 刚推出那会,还是他们新版的引以为傲的一个功能服务。Code With Me 是一个实时协同编程工具,主要用于协作开发与结对编程,旨在让开发工作突破空间限制,实现多人高效协同。它能够使身处不同地点的开发人员,同时对同一个项目代码进行编辑和操作,以实现 Host-Guest 模式的手把手结对编程和群体编程。聊到 Code With Me 服务的诞生,其实还得追溯到前几年的口罩时期。彼时,内置配对编程和实时协作工具的需求达到高峰,这也是当时 JetBrains 推出 Code With Me 这项服务的初衷。我记得当时 IntelliJ IDEA 2021 年的首个大版本,就开箱即用地支持了 Code With Me 功能,同时它还具有音频通话和视频通话功能,可以满足随时随地的沟通需求,这操作在当时非常酷炫,也解决了很大的痛点。【顺便提一嘴】技术大厂,前端-后端-测试,全国均有机=会,感兴趣可以试试。待遇和稳定性都还不错~但是随着时间的推移,很多事情发生了变化。这次 JetBrains 决定停止对 Code With Me 的开发,主要基于以下两点原因:**第一点是需求变化。**因为该工具在口罩期间需求达到顶峰,但随着团队协作工作流的改变,如今这方面的需求已逐渐下降。**第二点则是资源配置优化。**为了将工程资源集中在能为开发者带来最大价值的领域,公司决定不再投入资源维护该插件。那针对这次的 Code With Me 服务停服,JetBrains 官方制定了明确的停运时间表,以确保用户有足够的时间过渡。JetBrains 官博表示:自 2026.1 版本发布后,Code With Me 将从所有现有 JetBrains IDE 中分离出来,并通过 JetBrains Marketplace 作为独立插件提供。同时 2026.1 也将会是官方支持 Code With Me 的最后一个 IDE 版本,后续将不再开发任何新功能。过渡期自 2026.1 至 2027 Q1,Code With Me 插件将继续在受支持的 IDE 版本上运行,并由 JetBrains 官方提供安全更新,同时对应配套的公共中继基础设施也会保持运行。最终停用会定在 2027 年第一季度,届时公共中继基础设施将被关闭,Code With Me 服务将完全停止运行。话说最近这一年,JetBrains 可谓是动作频频,在产品策略方面,该放弃的放弃,该调整的调整,目前正在大刀阔斧地对其现有软件和服务进行改造。大家还记得吗,三个月前的时候,JetBrains 才刚刚官宣其下一代 IDE Fleet 的终止开发与更新。想当初 Fleet 刚出来那会,也承载了当年 JetBrains 的厚望,号称要对标 VSC,但是最终的结局大家也看到了,还是难逃停更的结果。究其原因,还是因为如今的开发工具领域正经历根本性变化,AI 大模型等技术的突破彻底改变了 Coding 的方式。去年底 Fleet 官宣落幕的时候,官方曾明确表态,Fleet 虽然倒下,但是其背后的技术和团队并不会消失,JetBrains 将基于该基础,转而押注 Agentic Development 赛道,去开发一个新的产品。这不,也就在前些天,Jetbrains 也在其官博里正式放风了一个新产品,即:发布全新的 AI Agent IDE,名字叫做:Jetbrains Air。JetBrains Air 定位为一款桌面级应用,官方是叫它:Agentic Development Environment,专为 AI Agent 工作流而设计,并将其描述为全新一代的开发工具。Jetbrains Air 支持多智能体并发,提供隔离环境。借助 Air,用户可以将编码任务委派给多个 AI Agent,并同时运行。说白了,这玩意有点类似于之前 OpenAI 发的那个 Codex App,不过不同于 Codex App 的是,这次的 JetBrains Air 走的是开放路线,生态开放,不搞 AI 供应商绑定。Air 支持将市面上多种常见的 Code Agent,比如 OpenAI 的 Codex、Anthropic 的 Claude、Google 的 Gemini,包括 JetBrains 自己的 Junie 等,支持整合到一个连贯的工作流中,以实现精准自定义任务、独立运行任务,并借助全面的代码智能功能来查看结果。当然,Air 目前还仍处于 Public Preview 阶段,下载页面目前也仅提供 macOS 版本安装包,Windows 和 Linux 版本在后续会跟进。写到这里其实挺感慨。JetBrains 作为曾经的开发软件领域的扛把子,如今随着 AI Coding 的加速进化与冲击,这两年遇到了不小的瓶颈。包括这一次 JetBrains Air 的亮相,被不少网友讨论说是 Jetbrains 在 all in AI 路上的最后一搏,显然 JetBrains 也不想在 AI 这个赛道上掉队。但不知道为啥,越是这样,现在越给人的感觉就是,产品策略愈渐被动,产品决策也有点仓促和迷茫,说实话,这可不是什么好事啊。而且该说不说,我觉得这次 JetBrains Air 又有点发晚了,毕竟别家像 Anthropic 或者 OpenAI 这些,人家早就已经推出类似产品来占领市场了。JetBrains 这才刚刚跟进不说,搞个 App 结果目前还只发了一个 macOS 版,Windows 和 Linux 版都还没推出来……说实话,这反应速度太慢了。面对各种先进 AI 工具带来的降维打击,以及开发者编码角色和习惯的逐渐转变,JetBrains 在 AI 时代正面临着前所未有的挑战。但是没办法,在这个技术日新月异的时代,唯一不变的就是变化。而作为开发者,我们唯一能做的,就是保持开放的心态,迎接 AI 时代的新浪潮、新范式、新工具。——转载自:CodeSheep
JetBrains又一知名软件宣布倒下,五味杂陈
开源硬件平台
#技术干货##技术干货##技术干货##技术干货##技术干货# 比较器电路是硬件设计里很常用的一种电路,它的功能是比较两个输入端电压的大小,并且根据比较结果输出高电平或者低电平。在电压检测、过压/欠压保护、波形整形、频率测量等场景下比较器电路使用非常广泛。 在多数场景下,使用比较器需要加入一定的迟滞;如果没有迟滞,当输入信号接近比较阈值时,在噪声的作用下比较器的输出会多次翻转,导致后级电路误判;下图中绿色三角波为输入,红色方波为输出;在三角波越过比较阈值2.5V时,比较器的输出多次连续反转;如果比较器后级为MCU,很可能导致MCU连续多次误动作; 而引入迟滞电压后,输出波形明显改善,不再有连续翻转; 因为有不同的使用需求,比较器的种类也很丰富。有需要外部电阻电路的比较器,也有集成度更高不需要外围电阻的比较器。在绝大多数场景下,专用比较器价格更便宜,而且参数更优秀;只有在特定的场景下,比如系统里有多余运放,同时对速度要求又比较低的情况下,才适合用运放搭一个比较器电路,降低硬件BOM成本。 常见的比较器芯片比如LM393(安森美出品)需要用到一个运放和几个外围电阻;配合电源电压,合理设定电阻的阻值大小就能搭建一个有迟滞效应的比较器。下面介绍一下使用电阻+比较器芯片搭建迟滞比较器的原理和参数计算方法。原理解析 迟滞比较实际上就是基于正反馈做的一个闭环结构,通过在输出端与同相输入端之间引入电阻分压网络,使比较器的输出值不仅与当前输入值有关,而且与当前时刻的输出值有关;典型的反向迟滞比较器电路结构如下。 图中所选的比较器输出极为开漏输出,需要外接上拉电阻R1才能输出高电平。很多比较器都是这种输出,它的好处在于可以灵活控制输出的高电平大小;对于多数MCU可以将输出上拉的电压设定为3.3V,与MCU供电电源保持一致,方便MCU接收;对于特定电路,可以设定上拉电压与比较器供电电压不同,比如设定为5V或者更高,以符合后级电路的输入幅度要求。 图 1 原理图 待比较信号从比较器反向端输入,比较阈值结合上拉电压VCC及外围电阻值进行设定。输出特性曲线如下图所示: 图2 输出特性曲线 对于输入信号而言,电路中存在两个比较电平,VL与VH。当输入信号高于VH时,输出电平肯定会变成0;当输入低于VL时,输出肯定会变成1;(因为信号输入到比较器的反向端,所以输出逻辑和输入信号的变化趋势是相反的)。而当输入信号处于VH与VL中间时,就要依靠当前输出电平状态来判断变化曲线。如果此时输出为1,那么输入必须继续上升,直到超过电平VH时才能使输出为0,否则输出仍然保持为1;如果此时输出为0,那么输入必须继续下降,直到低于VL时才能使输出为1,否则输出仍然保持0; 之所以出现这个曲线的原因在于,不同的输出状态会影响VTH处的电压值;导致输入信号所面对的比较值不同。当比较器输出为1(高电平)时,电阻R1+R3等效于与电阻R2并联的状态,此时VTH节点电压对应于图2中的VH,也就是我们目标设计参数中的2.7V。 图3 输出高电平时等效电路 而当比较器输出为0(低电平)时,电阻R4与电阻R3成并联关系,此时VTH节点电压对应于图2中的VL,也就是我们目标设计参数中的2.4V。 图4 输出低电平时等效电路 能做图3、图4等效的原因在于,比较器的输出是开漏输出。下图是LM393的结构框图,当比较器输出高电平的时候Q16处于关断状态;而比较器输出低时Q16导通,导致输出output直接接地。 参数计算 接下来就需要根据参数需求,来设定外围电阻值。为了计算方便我们可以举一个有具体数值的例子,来看一下如何根据参数计算电阻值。假设供电电源为5V,要求设计VH电平为2.7V,VL电平为2.4V,也就是中间迟滞电平为300mV。 为了保证输出电平的驱动能力,一般选定R1的阻值比较小;我们选定R1的阻值为4.7KΩ;同时为了尽量减少静态电流降低功耗,选择R4电阻为100KΩ。接下来就要根据这两个电阻参数计算剩下的R2、R3阻值。 根据电阻串并联分压的计算方法,两个阈值电压计算公式如下: 因为R1与R4已经选定,Vcc、VH、VL这些参数已经明确,计算R2与R3就是解这个二元一次的方程组。由于电阻之间存在串并联关系,这个方程求解过程比较复杂,在实际计算时并不实用,所以有必要根据实际情况做一点简化。 图3 输出高电平时等效电路 如果我们重新观察图3的结构就会发现,对于开漏输出的比较器而言,R1的阻值相较于R2、R3、R4必须是个很小的值,这样当比较器输出电平为高时才能使输出节点Output的电压尽可能接近Vcc;对于MCU应用来说更容易被MCU管脚检测到高电平。这样在实际应用时可以忽略在VH、VL计算公式中的影响;根据这个实际应用需求,在计算过程中忽略R1的影响,可以得到R2、R3的表达式为: 带入计算公式,就可以得到R2≈95.83KΩ;R3≈766.66KΩ。选取最接近的1%标准电阻值,R2 = 95.3KΩ,R3= 768KΩ,R1取R3的1/100大小,为7.68KΩ;仿真验证 接下来我们使用LTspice进行仿真,验证参数设置是否正确。仿真中使用了MAX9095做比较器,这个比较器也是一个开漏输出;使用5V供电,输入一个5V正弦波进行比较;可以看到标线处,VL≈2.4V,VH≈2.7V; 输入输出电压扫描特性如下 我还设计了一个简易的电阻计算程序,输入供电电压,下拉电阻阻值,VH、VL电压就可以计算出剩余电阻取值,并且推荐最为接近的1%精度标准电阻值,非常简单。把刚才的设计参数VH、VL和电源电压都标注进去,就能够获得标准外围阻值; 需要的朋友可以留言索取。关于这个小程序开发还踩了很多坑,里面的代码都是AI辅助编写的,其中有很多需要注意的事项,之后有时间我再写文章发出来。
告别反复调试:比较器迟滞电阻网络计算,看这篇就够(附计算小工具)
开源硬件平台
反激电源复刻,大佬们纠纠错 第一次正经画板子,即将打样前想看看哪里还有错误
6
严重问题>>高压侧线间绝缘间隙太小了,不安全,容易炸 其他问题>>光耦开槽只挡住一半,跟不开槽没区别 新手建议先不要做元件太紧凑的板子. 研究开关电源先要掌握安全规范相关知识,不然做出东西只会害人害己
开源硬件平台
我们最近刚把一个后台系统从 element-plus 切成了完全自研组件,CSS 层统一用 Tailwind。全员同意设计稿一致性提升了,但代码里怨言开始冒出来。这篇文章不讲原理,直接上代码对比和团队真实使用反馈,看看是谁在享受,谁在撑着。1.组件内样式迁移原先写法(BEM + scoped): <template> <div class="card"> <h2 class="card__title">用户概览</h2> <p class="card__desc">共计 1280 位</p> </div> </template> <style scoped> .card { padding: 16px; background-color: #fff; border-radius: 8px; } .card__title { font-size: 16px; font-weight: bold; } .card__desc { color: #999; font-size: 14px; } </style> Tailwind 重写: <template> <div class="p-4 bg-white rounded-lg"> <h2 class="text-base font-bold">用户概览</h2> <p class="text-sm text-gray-500">共计 1280 位</p> </div> </template> 优点:组件直接可读,不依赖 class 定义样式即结构,调样式时不用来回翻缺点:设计稿变了?全组件搜索 text-sm 改成 text-base?无法抽象:多个地方复用 .text-label 变成复制粘贴【顺便提一嘴】技术大厂,前端-后端-测试,全国均有机=会,感兴趣可以试试。待遇和稳定性都还不错~2.复杂交互样式纯 CSS(原写法) <template> <button class="btn">提交</button> </template> <style scoped> .btn { background-color: #409eff;color:#fff; padding: 8px 16px; border-radius: 4px; } .btn:hover { background-color: #66b1ff; } .btn:active { background-color: #337ecc; } </style> Tailwind 写法 <button class="bg-blue-500 hover:bg-blue-400 active:bg-blue-700 text-white py-2 px-4 rounded"> 提交 </button> 问题来了:✅ 简单 hover/active 很方便❌ 多态样式(如 disabled + dark mode + hover 同时组合)就很难读: <button class="bg-blue-500 text-white disabled:bg-gray-300 dark:bg-slate-600 dark:hover:bg-slate-700 hover:bg-blue-600 transition-all"> > 提交 </button> 调试时需要反复阅读 class 字符串,不能直接 Cmd+Click 查看样式来源。3.统一样式封装,复用方案混乱原写法:统一样式变量 + class $border-color: #eee; .panel { border: 1px solid $border-color; border-radius: 8px; } Tailwind 使用中经常出现的写法: <div class="border border-gray-200 rounded-md" /> 问题来了:设计稿调整了主色调或边框粗细,如何批量更新?BEM 模式下你只需要改一个变量,Tailwind 下必须靠 @apply 或者手动替换所有 .border-gray-200。于是我们项目里又写了一堆“语义类”去封装 Tailwind: /* 自定义 utilities */ @layer components { .app-border { @apply border border-gray-200; } .app-card { @apply p-4 rounded-lg shadow-sm bg-white; } } 最后导致的问题是:我们重新“造了个 BEM”,只不过这次是基于 Tailwind 的 apply 写法。🧪 实测维护成本:100+组件、多人协作时的问题我们项目有 110 个组件,4 人开发,统一用 Tailwind,协作两个月后出现了这些反馈:👨‍💻 A 开发:写得很快,能复制设计稿的 class 直接粘贴🧠 B 维护:改样式全靠人肉找 .text-sm、.p-4,没有结构命名层🤯 C 重构:统一调整圆角半径?所有 .rounded-md 都要搜出来替换所以我们内部的结论是:Tailwind 写得爽,维护靠人背。它适合“一次性强视觉还原”,不适合“结构长期型组件库”。🔧 我们后来的解决方案:Tailwind + token 化抽象我们仍然使用 Tailwind 作为底层 utilities,但同时强制使用语义类抽象,例如: @layer components { .text-label { @apply text-sm text-gray-500; } .btn-primary { @apply bg-blue-500 hover:bg-blue-600 text-white py-2 px-4 rounded; } .card-container { @apply p-4 bg-white rounded-lg shadow; } } 模板中统一使用: <h2 class="text-label">标题</h2> <button class="btn-primary">提交</button> <div class="card-container">内容</div> 这种方式保留了 Tailwind 的构建优势(无 tree-shaking 问题),但代码结构有命名可依,后期批量维护不再靠搜索。📌 最终思考Tailwind 是给设计还原速度而生的,不是给可维护性设计的。 设计师爱是因为它像原子操作; 开发者撑是因为它把样式从结构抽象变成了“字串组合游戏”。如果你的团队更在意开发效率,样式一次性使用,那 Tailwind 非常合适。 如果你的组件系统是要长寿、要维护、要被多人重构的——你最好在 Tailwind 之上再造一层自己的语义层,或者别用。分享完毕,谢谢大家🙂——转载自:ErpanOmer
Tailwind 到底是设计师喜欢,还是开发者在硬撑?
开源硬件平台
此题何解
开源硬件平台
V3.0 – 两板集成方案 版本:V3.0 日期:2026-03-21 用途:厂家评估、出样、量产开发 一、项目目标 开发一套双电机升降控制系统,用于控制: 电机1:桌面升降 电机2:显示器升降 系统需具备: 电容触控控制(4键) 无线遥控控制(433MHz) 记忆位置(站姿/坐姿) 自动行程学习 完整安全保护机制 二、系统架构(强制要求) 2.1 整体架构(两板方案) 主控板(MCB)位于底部金属结构内,负责: 双电机驱动(H桥+PWM) 霍尔信号处理 主逻辑控制与安全保护 电源转换(24~29V → 5V) UART通信接口 ↓ UART通信线(≤2m),信号:5V / TX / RX / GND HMI+无线合并板安装在桌面内部(非金属环境),集成: 电容触控区(4弹簧,中心灯珠) 天线区(433MHz) 本地MCU(处理触控、背光、无线、UART) 集成433无线接收 UART通信接口 2.2 架构设计原则(不可更改) 主控板(MCB)位于底部金属结构内,负责电机驱动与主逻辑。 HMI+无线合并板安装在桌面内部(非金属环境),集成触控与无线功能。 主控与HMI之间采用UART通信,线缆长度 ≤2m。 无线模块必须集成在HMI板上,远离金属,与触控弹簧保持 ≥15mm 间距。 禁止将电容触控原始信号通过长线传输(触控信号在HMI板上本地处理)。 HMI板需独立MCU进行本地处理,不得依赖主控进行触控扫描。 三、硬件系统要求 3.1 主控板(MCB) 功能: 双电机驱动(正反转 + PWM,频率 ≥20kHz) 霍尔信号处理(双路AB相,5V供电) 主逻辑控制 安全保护 与HMI板UART通信 电气要求: 输入电压:24~29V DC 输出:5V(供HMI板使用) 电机驱动:双路独立 H桥 持续电流:≥2A/路 峰值电流:≥3A/路 待机功耗:≤0.5W(休眠状态下) 驱动要求: 必须支持正反转(H桥或等效方案),不接受继电器切换方向 PWM频率 ≥20kHz Hall信号需做RC滤波及施密特触发处理 5V电源方案: 24V→5V 降压建议采用同步降压 DC-DC(如 MP2307 或同类),效率≥85%,输出电流≥500mA(含 HMI 板+霍尔供电余量)。 硬件急停: 硬件急停通过切断 24V 主供电链路实现(串联急停开关或继电器),MCU 软件急停为辅助手段,不可替代硬件断电。 电机接口线序(仅供参考): 电机线序建议按捷昌标准6芯:MOTOR+、MOTOR-、HALL_B、HALL_A、HALL_GND、HALL_5V。若使用其他线序,请提前沟通。 3.2 HMI+无线合并板 功能组成: 电容触控(4键) LED背光(4个,每个弹簧中心一颗) 本地MCU(处理触控、背光、无线、UART通信) 433MHz无线接收模块(集成在板上) 触控要求(不可妥协): 电容弹簧:直径 ≥12mm,高度 8~10mm 面板:木板,感应距离3~5mm(局部薄区约1mm) 触控芯片需具备上电自动基准校准和自适应环境基准跟踪,能稳定穿透木板厚度 触控信号在本地处理,不得通过长线传输 LED要求: 每键1颗LED,支持PWM调光 无线模块要求: 频率:433MHz(学习码) 距离:室内 ≥5米 模块集成在HMI板上,远离金属结构,与触控弹簧保持 ≥15mm 间距 天线区域(后部约53×17mm)正反面禁止铺铜,天线走线做阻抗匹配 无线模块电源需独立滤波(100nF+10µF),不与触控芯片共用 遥控器配套: 配套遥控器由厂家推荐或采购市售 433MHz EV1527 学习码遥控器(4键),需与接收方案兼容,厂家需提供配对测试说明。 布局建议: HMI板尺寸约53×70mm(具体以附图为准),触控区与天线区物理分隔 触控感应走线建议加 Guard Ring(地线包围) 触控IC的模拟地与无线模块的数字地单点汇合,避免大面积混用 UART接口(5V/TX/RX/GND)放置于板侧边,方便与主控连接 3.3 通信接口 主控 ↔ HMI: UART,线长 ≤2m 电平:5V逻辑,建议上拉4.7kΩ 支持校验(建议CRC)和超时机制 HMI ↔ 无线模块: 由模块接口决定(UART/GPIO),直接连接至本地MCU 四、功能逻辑 详细功能逻辑见单独提供的 《功能逻辑表》(含按键映射、唤醒休眠、长按运行、组合键学习、记忆位置、安全保护等)。 请厂家按该表完整实现,本处不再重复。 五、抗干扰要求(必须满足) 系统在电机运行、LED PWM、长线通信等条件下必须稳定运行,不得出现误触发、死机、无线失效。 HMI板布局需分区、单点接地 无线模块电源独立滤波 UART通信线建议使用屏蔽线或双绞线,远离动力线 六、交付要求(量产级) 必须交付以下文件,确保可直接移交生产: 硬件部分: 原理图(源文件+PDF) PCB Layout(源文件+Gerber) BOM(含替代料) 贴片坐标文件 装配图 固件部分: 完整源码(C语言,注释清晰) 烧录文件(hex/bin) 烧录工具及烧录说明 固件版本管理说明 测试部分: 功能测试规范(含测试点说明) 老化测试方案(≥48小时) 不良品判断标准 其他: 线束图纸 接口定义说明 装配说明 物料承认书清单 七、验收标准 功能验收:按《功能逻辑表》逐项验证通过 无线验收:遥控器室内5米稳定控制,配对可靠 稳定性验收:连续运行48小时无异常(含休眠唤醒) 量产文件验收:所有文件齐全,可支持工厂直接生产 八、厂家评估要求 请提供: 方案说明:是否基于现有平台,简要技术路线 样品周期:从合同到提供2套完整样机的时间 报价:NRE(研发费)与BOM成本(按1000套批量)分开列出 重点评估: 53×70mm空间内集成触控、LED、MCU、433模块及天线的布局可行性 3~5mm实木板穿透的触控灵敏度稳定性 天线区净空及抗干扰措施的实现 附:推荐器件参考清单 (厂家可替换,需提前沟通) 主控MCU:STC8H8K64U(LQFP-32,约2元) HMI MCU:STC8G1K08(SOP-16,约0.8元) P-MOS高边:AP40P100K(TO-252,约0.6元) N-MOS低边:HYG180N10LS1P(TO-220FB,约0.6元) 电容触控IC:BS86C04A(合泰,SOP-16,约1.5元) 433接收IC:SYN480R(杰盛微,SOP-8,约0.7元) 5V电源:MP2307/MP1584 类(SOT-23,约0.5元) 说明:以上器件仅为参考,厂家可根据自身供应链选用同等性能、封装兼容的替代料,需提前沟通确认。 附件: 板框示意图(附后) 功能逻辑表(附后)
双电机升降桌控制系统(PRD)
开源硬件平台
优质硬件创作分享平台
打赏记录
服务时间:周一至周六 9::00-18:00 · 联系地址:中国·深圳(福田区商报路奥林匹克大厦27楼) · 媒体沟通:pr@jlc.com · 集团介绍
移动社区