嘉立创社区
发动态
图文
列表
置顶
参与嘉立创"硬核手搓挑战"DIY活动，瓜分万元大奖！
置顶
【元器件规范共建召集令】诚邀行业专家，定义行业规范新基准
当你在电子元器件选型时，是否因参数定义模糊反复试错？当你推进研发项目时，是否因标准不统一延误进度？如今，有一个能改变行业现状、为电子产业发展注入新动能的机会 —— 加入立创商城电子元器件规范共建项目，与更多行业专家携手，打造科学、完善、权威的元器件参数规范体系！立创商城深耕电子元器件电商领域多年，深知统一精准的参数规范对行业上下游的重要性。我们正启动一项开创性工程，现面向全国电子元器件行业规范制定人、电子行业从业者、电子专业教育从业者、资深领域电子爱好者等群体招募 20-50 名细分领域专家，涵盖接口芯片、时钟和定时、射频无线、传感器等 9 大核心方向，邀你成为这场 “规范革命” 的 “执笔人”。1、你将参与的核心领域（涵盖9大方向）接口芯片USB、PCIe、CAN芯片等接口芯片的设计关注核心参数范围划定及其参数名词解释时钟和定时晶振、定时器、时钟发生器等震荡器的设计关注核心参数范围划定及其参数名词解释射频无线RF芯片、天线模块、无线收发器等无线射频相关器件的的设计关注核心参数范围划定及其参数名词解释传感器温度、压力、光电等传感器的设计关注核心参数范围划定及其参数名词解释功能模块电源管理、信号调理模块等电子模块的设计关注核心参数范围划定及其参数名词解释物联网/通信模块5G、WiFi、蓝牙模块等无线通讯模块的设计关注核心参数范围划定及其参数名词解释单片机/微控制器ST、TI、STC等单片机器件的设计关注核心参数范围划定及其参数名词解释逻辑器件和数据转换ADC/DAC、逻辑门等与信号转换和数据转换相关的设计关注核心参数范围划定及其参数名词解释显示屏器件OLED、LCD等显示屏的设计关注核心参数范围划定及其参数名词解释 2、你的角色：从技术实践者到标准制定者评审与优化：针对公司内部团队起草的规范初稿（如参数定义、填写规范、案例模板），以专业视角审核逻辑严谨性，提出修改建议（例如隔离电压、CMTI等参数的单位换算、优先级规则）；深度参与：基于实操经验，为芯片引脚定义、数据速率计算、温度范围界定等参数提供行业实践案例，确保规范兼具理论准确性与工程可行性；成果共创：与跨领域专家协作，构建类似“电子元器件维基百科”的公开规范网站，让技术标准真正服务行业生态。3、我们为你提供的四大价值回报「行业署名权」：每一份经你评审修改的规范，均将在最终版本中明确标注你的姓名与单位，成为个人技术生涯的权威背书；「品牌曝光度」：规范公开时，参与评审与编撰的专家名单将同步公示，通过公司官方渠道（行业媒体、技术社区）定向推送，提升行业影响力；「知识共享平台」：加入电子元器件规范维基网站建设，你的技术见解将被全球工程师查阅引用，成为领域内的“隐形标准制定者”；「多样激励体系」：任务制，每次任务均有丰厚报酬奖励，根据审核规范复杂度与贡献度可获取，包括且不限于京东E卡/采购晶/优惠券/实物奖励等，多劳多得激励形式：1、积分制每次任务，每人均可获得积分，根据每人贡献程度获得对应积分贡献程度人数获得积分皇冠125黄金315白银610青铜105 2、积分可兑换礼品积分数兑换礼品价值550E卡或50采购晶50元10100元E卡或100元采购晶100元20200元E卡或200元采购晶200元50500元E卡或500元采购晶500元1001000元E卡或1000元采购晶1000元2002000元E卡或2000元采购晶2000元 4、为什么工程师值得加入？技术价值升华：从“用标准”到“定标准”，让你的经验成为行业参照坐标； 资源链接机遇：与芯片原厂、方案商专家深度交流，拓展技术人脉圈； 职业发展加分：参与行业级规范制定的经历，是技术管理岗晋升的硬核背书。5、报名方式如果您在上述领域拥有多年以上研发/设计经验，或主导过元器件选型与参数验证项目，欢迎将个人简历（附技术专长说明）发送至：，邮件主题注明“【规范专家报名】+领域方向”。我们将在3个工作日内与您联系，共商规范共建蓝图。 电子元器件的每一个参数，都承载着工程师的智慧。现在，你就有机会成为定义行业规范的 “少数派”，让全球工程师使用你参与制定的标准。这不仅是一次技术实践，更是一段能为行业留下深刻印记、为职业增添高光的宝贵经历。立创商城期待与你携手，重塑元器件参数规范行业标杆，让你的技术印记，刻进行业未来！ 注：“本次共建采用灵活协作模式，单次任务预计耗时2~4小时，全程线上进行，不影响日常工作。”
【元器件规范共建召集令】诚邀行业专家，定义行业规范新基准
立创商城
嘉立创FPC
电池包的热管理，是新能源汽车安全与续航的核心命脉。当电芯在大倍率充放电时，瞬间产生的热量若无法及时导出，不仅会导致电池加速衰减，更可能引发热失控风险。而在热管理系统中，一个小小的导热界面材料——导热硅脂，却常常成为决定成败的关键。 今天，我们将目光聚焦于华东某知名新能源汽车制造商的电池包散热改造项目。这是傲琪电子以专业热管理方案解决客户痛点、实现性能跃升的典型案例。   一、 项目背景：被忽视的“界面之困” 该车企在研发一款高能量密度电池包时，遇到了棘手的散热瓶颈。其设计方案采用液冷板贴合模组底部的方式散热，但在测试中发现：即使液冷板温度控制良好，电芯底部的温度依然居高不下，导致电池包整体温差超过8℃，严重影响了电池的一致性与循环寿命。 问题出在哪里？经过热成像分析与拆解，根源锁定在电芯与液冷板之间的导热界面。 电芯铝壳与液冷板表面虽然经过机加工，但微观上仍存在大量凹凸不平的缝隙。为了填充这些缝隙，原方案使用了一种常规导热垫片。然而，垫片硬度偏高，无法完全贴合曲面；且长期受压后，垫片发生应力松弛，接触热阻逐渐增大，导致热量“堵”在了电芯底部。 二、 傲琪方案：不仅仅是“换一种材料” 接到客户诉求后，傲琪电子技术团队立即介入。我们没有简单地推荐一款高导热系数的硅脂，而是从界面传热机理与工程可制造性两个维度展开分析。 1. 材料匹配：低热阻与长期稳定性并重 针对电池包内部空间狭小、长期震动、温度交变的特点，傲琪电子推荐了G500系列高导热硅脂作为核心填充材料，并配合导热灌封胶实现整体密封与散热。 G500系列导热硅脂：导热系数5.0W/(m·K)，远高于常规垫片。其独特的低油离度（<0.05%） 配方确保了在40℃~150℃的极端温度循环中，基础油不会析出污染电芯极柱或连接器，避免了传统硅脂“泵出效应”导致的干涸失效。 导热灌封胶：在电池包底部形成一层兼具绝缘、导热、缓冲的整体密封层，将电芯产生的热量高效传导至液冷板，同时起到防护作用。 2. 工艺适配：实现微米级均匀涂覆 大尺寸电池模组对涂覆均匀性要求极高。傲琪团队协助客户改进了涂覆工艺：采用精密钢网印刷，将G500硅脂以80μm的厚度精准涂布在液冷板表面，确保了每个电芯底部接触面的热阻一致。随后，在模组装配时注入导热灌封胶，利用胶体的流动性二次填充细微间隙，形成“无死角”的导热网络。  三、 落地成果：热阻直降30%，温差缩至3℃ 改造后的电池包经历了严苛的第三方测试，数据令人振奋： 界面热阻降低30%：相比原垫片方案，G500硅脂与灌封胶的组合将接触热阻从0.62℃·in²/W降至0.43℃·in²/W。 最高温度下降8℃：在2C倍率连续充放电测试中，电芯最高温度由72℃降至64℃，有效延缓了电池衰减。 温差控制优于3℃：模组内各电芯间的最大温差从8℃以上缩小至2.8℃，大幅提升了电池一致性与循环寿命。 长期可靠性验证：经过1000小时高温高湿及500次冷热冲击，材料无开裂、无渗油，接触热阻变化小于5%。 客户热管理负责人感慨：“之前我们一直在垫片和硅脂之间犹豫，总以为垫片更可靠。傲琪用实测数据告诉我们，选对材料、做对工艺，硅脂不仅能胜任，还能带来意想不到的性能提升。现在这款电池包已经成功搭载在我们新款车型上。” 四、 技术解析：为什么傲琪能赢？ 这个项目的成功，源于傲琪电子对导热材料底层技术的深耕： 填料复配技术：通过微米与纳米级导热填料的级配填充，G500系列在保证低粘度涂覆性的同时，构建了密集的导热通路，实现高导热与低接触热阻的平衡。 流变学设计：针对印刷工艺需求，精确控制硅脂的触变指数，确保涂覆时易刮平、停顿时不流淌、受压时不外溢。 系统级思维：不孤立看待单一材料，而是提供“硅脂+灌封胶+工艺优化”的组合方案，解决客户从材料到量产的全链条问题。 结语 新能源汽车的热管理是一场“毫米级”的较量，每一个界面的优化都关乎整车的安全与效能。傲琪电子在电池包项目中的实战证明：小小的导热硅脂，经过专业选型与精密工艺的加持，足以成为攻克散热瓶颈的利器。  
让电池包安然度过“火炉”与“极寒”： 傲琪电子高导热硅脂在新能源汽车热管理中的实战记
开源硬件平台
嘉立创纸盒
还在为每个列表页写重复的分页代码而烦恼吗？ 还在复制粘贴 currentPage、pageSize、loading 等状态吗？ 一个 Hook 帮你解决所有分页痛点，减少90%重复代码背景与痛点在后台管理系统开发中，分页列表查询非常常见，我们通常需要处理：当前页、页大小、总数等分页状态加载中、错误处理等请求状态搜索、刷新、翻页等分页操作数据缓存和重复请求处理这些重复逻辑分散在各个组件中，维护起来很麻烦。为了解决这个烦恼，我专门封装了分页数据管理 Hook。现在只需要几行代码，就能轻松实现分页查询，省时又高效，减少了大量重复劳动使用前提 - 接口格式约定查询接口返回的数据格式： { list: [ // 当前页数据数组 { id: 1, name: 'user1' }, { id: 2, name: 'user2' } ], total: 100 // 数据总条数 } 先看效果：分页查询只需几行代码！ import usePageFetch from '@/hooks/usePageFetch' // 引入分页查询 Hook，封装了分页逻辑和状态管理 import { getUserList } from '@/api/user' // 引入请求用户列表的 API 方法 // 使用 usePageFetch Hook 实现分页数据管理 const { currentPage, // 当前页码 pageSize, // 每页条数 total, // 数据总数 data, // 当前页数据列表 isFetching, // 加载状态，用于控制 loading 效果 search, // 搜索方法 onSizeChange, // 页大小改变事件处理方法 onCurrentChange // 页码改变事件处理方法 } = usePageFetch( getUserList, // 查询API { initFetch: false } // 是否自动请求一次（组件挂载时自动拉取第一页数据） ) 这样子每次分页查询只需要引入hook，然后传入查询接口就好了，减少了大量重复劳动【顺便提一嘴】技术大厂，前端-后端-测试，全国均有机=会，感兴趣可以试试。待遇和稳定性都还不错~解决方案我设计了两个相互配合的 Hook：useFetch：基础请求封装，处理请求状态和缓存usePageFetch：分页逻辑封装，专门处理分页相关的状态和操作 usePageFetch (分页业务层) ├── 管理 page / pageSize / total 状态 ├── 处理搜索、刷新、翻页逻辑 ├── 统一错误处理和用户提示 └── 调用 useFetch (请求基础层) ├── 管理 loading / data / error 状态 ├── 可选缓存机制（避免重复请求） └── 成功回调适配不同接口格式 核心实现useFetch - 基础请求封装 // hooks/useFetch.js import { ref } from 'vue' const Cache = new Map() /** * 基础请求 Hook * @param {Function} fn - 请求函数 * @param {Object} options - 配置选项 * @param {*} options.initValue - 初始值 * @param {string|Function} options.cache - 缓存配置 * @param {Function} options.onSuccess - 成功回调 */ function useFetch(fn, options = {}) { const isFetching = ref(false) const data = ref() const error = ref() // 设置初始值 if (options.initValue !== undefined) { data.value = options.initValue } function fetch(...args) { isFetching.value = true let promise if (options.cache) { const cacheKey = typeof options.cache === 'function' ? options.cache(...args) : options.cache || `${fn.name}_${args.join('_')}` promise = Cache.get(cacheKey) || fn(...args) Cache.set(cacheKey, promise) } else { promise = fn(...args) } // 成功回调处理 if (options.onSuccess) { promise = promise.then(options.onSuccess) } return promise .then(res => { data.value = res isFetching.value = false error.value = undefined return res }) .catch(err => { isFetching.value = false error.value = err return Promise.reject(err) }) } return { fetch, isFetching, data, error } } export default useFetch usePageFetch - 分页逻辑封装 // hooks/usePageFetch.js import { ref, onMounted, toRaw, watch } from 'vue' import useFetch from './useFetch' // 即上面的hook ---> useFetch import { ElMessage } from 'element-plus' /** * 分页数据管理 Hook * @param {Function} fn - 请求函数 * @param {Object} options - 配置选项 * @param {Object} options.params - 默认参数 * @param {boolean} options.initFetch - 是否自动初始化请求 * @param {Ref} options.formRef - 表单引用 */ function usePageFetch(fn, options = {}) { // 分页状态 const page = ref(1) const pageSize = ref(10) const total = ref(0) const data = ref([]) const params = ref() const pendingCount = ref(0) // 初始化参数 params.value = options.params // 使用基础请求 Hook const { isFetching, fetch: fetchFn, error, data: originalData } = useFetch(fn) // 核心请求方法 const fetch = async (searchParams, pageNo, size) => { try { // 更新分页状态 page.value = pageNo pageSize.value = size params.value = searchParams // 发起请求 await fetchFn({ page: pageNo, pageSize: size, // 使用 toRaw 避免响应式对象问题 ...(searchParams ? toRaw(searchParams) : {}) }) // 处理响应数据 data.value = originalData.value?.list || [] total.value = originalData.value?.total || 0 pendingCount.value = originalData.value?.pendingCounts || 0 } catch (e) { console.error('usePageFetch error:', e) ElMessage.error(e?.msg || e?.message || '请求出错') // 清空数据，提供更好的用户体验 data.value = [] total.value = 0 } } // 搜索 - 重置到第一页 const search = async (searchParams) => { await fetch(searchParams, 1, pageSize.value) } // 刷新当前页 const refresh = async () => { await fetch(params.value, page.value, pageSize.value) } // 改变页大小 const onSizeChange = async (size) => { await fetch(params.value, 1, size) // 重置到第一页 } // 切换页码 const onCurrentChange = async (pageNo) => { await fetch(params.value, pageNo, pageSize.value) } // 组件挂载时自动请求 onMounted(() => { if (options.initFetch !== false) { search(params.value) } }) // 监听表单引用变化（可选功能） watch( () => options.formRef, (formRef) => { if (formRef) { console.log('Form ref updated:', formRef) } } ) return { // 分页状态 currentPage: page, pageSize, total, pendingCount, // 数据状态 data, originalData, isFetching, error, // 操作方法 search, refresh, onSizeChange, onCurrentChange } } export default usePageFetch 完整使用示例用element ui举例 <template> <el-form :model="searchForm" > <el-form-item label="用户名"> <el-input v-model="searchForm.username" /> </el-form-item> <el-form-item> <el-button type="primary" @click="handleSearch">搜索</el-button> </el-form-item> </el-form> <!-- 表格数据展示，绑定 data 和 loading 状态 --> <el-table :data="data" v-loading="isFetching"> <!-- ...表格列定义... --> </el-table> <!-- 分页组件，绑定当前页、页大小、总数，并响应切换事件 --> <el-pagination v-model:current-page="currentPage" v-model:page-size="pageSize" :total="total" @size-change="onSizeChange" @current-change="onCurrentChange" /> </template> <script setup> import { ref } from 'vue' import usePageFetch from '@/hooks/usePageFetch' // 引入分页查询 Hook，封装了分页逻辑和状态管理 import { getUserList } from '@/api/user' // 引入请求用户列表的 API 方法 // 搜索表单数据，响应式声明 const searchForm = ref({ username: '' }) // 使用 usePageFetch Hook 实现分页数据管理 const { currentPage, // 当前页码 pageSize, // 每页条数 total, // 数据总数 data, // 当前页数据列表 isFetching, // 加载状态，用于控制 loading 效果 search, // 搜索方法 onSizeChange, // 页大小改变事件处理方法 onCurrentChange // 页码改变事件处理方法 } = usePageFetch( getUserList, { initFetch: false } // 是否自动请求一次（组件挂载时自动拉取第一页数据） ) /** * 处理搜索操作 */ const handleSearch = () => { search({ username: searchForm.value.username }) } </script> 高级用法带缓存 const { data, isFetching, search } = usePageFetch(getUserList, { cache: (params) => `user-list-${JSON.stringify(params)}` // 自定义缓存 key }) 设计思路解析职责分离：useFetch 专注请求状态管理，usePageFetch 专注分页逻辑统一错误处理：在 usePageFetch 层统一处理错误智能缓存机制：支持多种缓存策略生命周期集成：自动在组件挂载时请求数据总结这套分页管理 Hook 的优势：开发效率高，减少90%的重复代码，新增列表页从 30 分钟缩短到 5 分钟状态管理完善，自动处理加载、错误、数据状态缓存机制，避免重复请求错误处理统一，用户体验一致易于扩展，支持自定义配置和回调——转载自：不一样的少年_
Vue3 后台分页写腻了？我用 1 个 Hook 删掉 90% 重复代码（附源码）
开源硬件平台
嘉立创FPC
第一次在立创做CNC，也是蛮怀期待。做了一个带耳朵的小铝盒子，3月25日下单，4月7日发货，4月9日收到货，费用三百二十多，价格有点偏贵，因为是打样，只做了一个，所以这个价格也能接受。拿到盒子，整体看起来还像那么回事，不错的，建立不要用哑光，效果暗灰，不如亮银来的好看。整体来来，立创CNC打样用来核一下尺寸还可以，作为产品显然是不合格的。原因有2：其一，产品磨边问题，不知道是什么情况，产品因为带耳朵，棱边也比较多，加工边缘会比较锋利，正常的加工都会对棱进行打磨，确保棱边不太锐利。这次加工的产品有一部分棱做了打磨，但大部分棱没打磨，这个就想不通，为什么会这样，看起来更像是漏加工，说明品控和质查没有发挥作用。其二，产品有一盒一盖，盖采用的沉头螺孔，沉头螺孔尺寸偏小偏浅，将螺钉上到底，螺盖依然会高出盒盖，尝试了几种不同规格的螺钉，都会露出来。相近的图纸在别的小公司也加工过，没有出现上述两种情况，立创CNC还需要加强。
立创CNC，还有较大进步空间
CNC机械制造
嘉立创PCB
SMT贴片加工是将电子元器件焊接到PCB上，那么在进行贴片加工之前都是需要对PCB进行检测，挑选以符合SMT生产要求的PCB，并且把不合格的退回PCB供应商，PCB的具体要求可以参考IPc-a-610c 国际通用电子行业组装标准，下面是一些SMT贴片加工对PCB的基本要求。外观与平整度表面平整光滑：PCB板应无翘曲、高低不平，否则在锡膏印刷和贴片时可能出现裂痕、影响钢网和刮刀寿命等问题。无污垢和氧化层：表面不能有污垢、锈斑、氧化等，以免影响定位、贴装和焊接质量。清洁度良好：能承受清洁剂清洗，在液体中浸渍5分钟表面不产生不良，且有良好的冲载性。尺寸与形状合适的外形尺寸：一般尺寸在50×50~350×250mm，但不同SMT设备要求有差异，设计时需考虑设备的最大和最小贴装尺寸。规则的形状：通常为矩形，最佳长宽比为3：2或4：3，长宽比例较大时容易产生翘曲变形。传送边要求：传送边不能有缺口，拐角要做圆形倒角，元器件最外侧距传送边≥3mm，尽量保证5mm，否则需加工艺边。板材与性能导热性良好：导热系数一般在0.2-0.8W/(K·m)，整个PCB平均导热系数约6.5W/(m·K)，以便在回流焊和波峰焊时受热均匀。耐热性达标：无铅工艺回流焊接温度达217245℃，持续3065s，PCB耐热性要达到260摄氏度持续10s。铜箔粘合强度足够：铜箔的粘合强度要达1.5kg/cm²，防止外力作用导致铜箔脱落。良好的导电性：作为电子元器件的载体，PCB需依靠线路导通实现元器件间连接，线路不能有断路等问题。Mark点设置形状与大小：形状标准有圆形、正方形、三角形等，大小在1.0~2.0mm。表面要求：表面平整、光滑、无氧化、无污物，与周围颜色有明显差异。位置要求：距离板边3mm以上，周围5mm内不能有类似mark点、过孔、测试点等，为避免进板方向错误，左右两边mark点与板缘位置差别应在10mm以上。拼版设计板边宽度与间距：拼版的板边宽度3~5mm，间距在1.6mm以上。弯曲与扭曲度：向上弯曲程度<1.2mm，向下弯曲程度<0.5mm，扭曲度最大变形高度÷对角长度<0.25。分板方式：拼板之间可采用V形槽、邮票孔或冲槽等，建议同一板只用一种分板方式。焊盘设计尺寸与形状：焊盘尺寸要合适，不能过大或过小，形状需符合元器件封装要求，参照数据手册设计。无过线孔与漏锡孔：焊盘上不能有过线孔，元器件焊盘边不能有漏锡孔，避免焊接时出现锡珠、短路等问题。阻焊与丝印阻焊层：阻焊层不能高于焊盘，且平坦，不影响焊盘，以保证锡膏印刷和焊接的准确性。丝印清晰：丝印要清晰可见，方便设备和操作员准确检测元器件位置和焊盘方向。
SMT贴片加工对PCB的基本要求
嘉立创SMT
开源硬件平台
单位：px、em、rem、vw、vh、clamp 怎么选？CSS 单位是响应式布局的核心，也是我刚学响应式时踩坑最多的知识点之一——明明写好的尺寸，换个屏幕、调个字体大小就错乱，排查后才发现是单位选得不对。px 是固定值、em/rem 是相对值、vw/vh 跟着视口走、clamp 能做流体排版，掌握它们的区别和用法，响应式开发、页面可访问性都会轻松很多。今天就把我整理的单位干货、实操经验和避坑技巧，分享给大家。一、绝对单位：px 为主，其他慎用（我的日常用法）绝对单位里，我日常开发只用 px（像素），其他单位（mm、cm、in、pt 等）几乎用不到，大多用于打印场景，新手不用花太多精力记忆。 /* px：像素，固定值，不会随任何因素变化 */ font-size: 16px; width: 200px; /* 打印场景专用，日常开发基本用不上 */ mm, cm, in, pt 分享我的实操心得：px 最适合用来设置固定不变的尺寸，比如边框宽度、小间距、图标大小、圆角等，这些地方不需要随字体、视口缩放，用 px 最精准，也最不容易出错。我早期曾用 em 设边框，结果字体一调，边框也跟着变粗，踩过一次坑后就再也不这么做了。二、相对单位：em 好用但易踩坑，嵌套需谨慎em 是相对单位，核心是“相对于当前元素的 font-size”——如果当前元素没设置 font-size，就继承父级的 font-size，这也是它容易踩坑的地方。 .parent { font-size: 16px; } .child { font-size: 1.5em; /* 相对于父级16px，就是24px */ padding: 1em; /* 重点：相对于自己的font-size（24px），就是24px */ margin: 0.5em; /* 相对于自己的font-size，就是12px */ } /* 嵌套会累积，这是我踩过的大坑！ */ .grandchild { font-size: 1.2em; } /* 相对于子元素24px，就是28.8px，越嵌套越大 */ 避坑提醒：em 最大的问题就是“嵌套累积”，嵌套层级越深，计算出来的尺寸越乱，我早期做导航菜单嵌套时，用 em 设字体，结果二级、三级菜单字体越变越大，排查了很久才找到原因。现在我只用 em 做简单的局部适配，嵌套场景坚决不用。三、相对单位：rem 我的首选，全局缩放超省心后来接触到 rem，直接解决了 em 嵌套累积的痛点！rem 也是相对单位，但它只相对于根元素（html）的 font-size，和父级元素没有关系，不会出现嵌套累积的问题，现在是我做全局布局、字体设置的首选单位。 /* 根元素字体大小，默认通常是16px，我会明确设置，避免浏览器差异 */ html { font-size: 16px; } .box { font-size: 1rem; /* 相对于html的16px，就是16px */ padding: 1.5rem; /* 16px×1.5=24px，计算直观 */ width: 20rem; /* 16px×20=320px，不用复杂换算 */ } /* 响应式神器：只需修改根字号，全站元素就会等比缩放 */ @media (max-width: 768px) { html { font-size: 14px; } /* 小屏缩小根字号，字体、间距、布局同步缩小 */ } 我的实操用法：rem 适合设置字体大小、容器间距、布局宽度等需要全局适配的样式，配合媒体查询修改根元素 font-size，就能轻松实现全站等比缩放，不用逐个修改每个元素的尺寸，效率大幅提升。#嘉立创PCB#<顺便提一嘴>技术大厂，前端-后端-测试，全国均有机=会，感兴趣可以试试。待遇和稳定性都还不错~四、视口单位：vw、vh、vmin、vmax 做全屏/自适应超方便视口单位是相对于“视口（浏览器可见区域）”的尺寸，和元素、根元素都无关，适合做全屏布局、自适应组件，比如首页Banner、全屏弹窗等，是响应式布局的“好帮手”。 /* vw：视口宽度的 1%，视口宽1000px，1vw就是10px */ .full-width { width: 100vw; } /* 占满视口宽度 */ .half-width { width: 50vw; } /* 占视口宽度的一半 */ /* vh：视口高度的 1%，视口高800px，1vh就是8px */ .full-height { height: 100vh; } /* 占满视口高度 */ /* vmin：vw 和 vh 里较小的那个，适合做正方形自适应 */ .square { width: 50vmin; height: 50vmin; } /* 始终是正方形，随视口缩放 */ /* vmax：vw 和 vh 里较大的那个，适合做全屏英雄区 */ .hero { height: 100vmax; } 高频坑点：这几个单位我踩过两个关键的坑，一定要记牢！1. 100vw 会包含浏览器滚动条的宽度，如果页面有纵向滚动条，用 100vw 会导致横向溢出，出现横向滚动条；2. 移动端用 100vh 时，浏览器地址栏显隐会导致高度跳动，体验很差，后来发现用 dvh 就能解决。五、现代视口单位：dvh、svh、lvh 解决移动端高度跳动问题为了解决传统 vh 在移动端的痛点，浏览器新增了 dvh、svh、lvh 三个现代视口单位，我现在做移动端全屏布局，全靠它们，再也不会出现高度跳动的问题。 /* dvh：动态视口高度，地址栏显隐时会自动调整高度，最常用、最推荐 */ .min-height: 100dvh; /* 移动端全屏布局首选，适配所有场景 */ /* svh：小视口高度，仅当浏览器地址栏始终可见时的视口高度 */ .min-height: 100svh; /* lvh：大视口高度，仅当浏览器地址栏始终隐藏时的视口高度 */ .min-height: 100lvh; 我的实操建议：做移动端全屏页面、吸底组件时，优先用 dvh，它能自动适配地址栏的显隐，保证页面高度始终贴合视口，体验更流畅；svh 和 lvh 只用在特殊场景，日常开发很少用到。六、clamp：流体排版神器，不用媒体查询也能自适应clamp 是我近期最常用的“黑科技”，它能实现“流体排版”，语法很简单：clamp(最小值, 首选值, 最大值)，意思是在最小值和最大值之间，根据首选值随视口平滑变化，不用写一堆媒体查询，就能实现自适应，极大减少代码量。 /* 字体：最小1.5rem（24px），最大2.5rem（40px），随视口宽度平滑变化 */ h1 { font-size: clamp(1.5rem, 4vw + 1rem, 2.5rem); } /* 容器：最小320px（小屏不挤），最大1200px（大屏不宽），随视口自适应 */ .container { width: clamp(320px, 90vw, 1200px); margin: 0 auto; /* 水平居中，适配所有屏幕 */ } /* 间距：小屏16px，大屏24px，随视口同步变化，不用单独写媒体查询 */ .section { padding: clamp(16px, 5vw, 24px); } 我的实操技巧：首选值常用 vw + rem 或 calc 做线性变化，比如 4vw + 1rem，既能保证小屏有足够的尺寸，又能让大屏尺寸不夸张；clamp 适合设置字体、容器宽度、间距等需要“平滑自适应”的样式，比媒体查询更简洁、更流畅。七、百分比 %：相对父级，布局常用但易踩坑百分比 % 也是相对单位，核心是“相对于父级元素的 content 区域尺寸”，日常布局用得很多，但新手容易踩坑，尤其是高度设置。 .child { width: 50%; /* 相对于父级content宽度的50%，布局常用 */ height: 100%; /* 相对于父级content高度的100%，容易失效 */ padding: 10%; /* 重点：margin、padding的%，始终相对父级宽度，不是高度！ */ } 避坑提醒：这是我早期踩过的高频坑——子元素设置 height: 100% 时，如果父级元素没有明确设置高度（比如父级 height 为 auto），子元素的 100% 就会失效，显示为内容高度。另外，margin 和 padding 的百分比，不管是水平还是垂直方向，都相对于父级的宽度，不是高度，新手很容易记混。八、我的实际用法建议（直接套用，少踩坑）结合我多年的开发经验，整理了一套单位使用规范，新手可以直接套用，不用再纠结怎么选，高效又避坑： /* 1. 根字号：设置rem基准，避免浏览器差异 */ html { font-size: 16px; } /* 2. 字体：rem（全局统一）或 clamp（流体自适应） */ body { font-size: 1rem; } /* 全局基础字体 */ h1 { font-size: clamp(1.5rem, 2vw + 1rem, 2.5rem); } /* 标题流体排版 */ /* 3. 间距：rem为主，保证全局一致性，配合clamp做自适应间距 */ .gap { gap: 1rem; } .padding { padding: 1.5rem; } .section-padding { padding: clamp(16px, 5vw, 24px); } /* 4. 布局宽度：%（局部适配）、vw、clamp（全局自适应） */ .container { width: min(90vw, 1200px); } /* 结合min更稳妥 */ .child-box { width: 50%; } /* 父级容器内的局部适配 */ /* 5. 小固定值：px（精准不变） */ border: 1px solid #eee; /* 边框固定 */ border-radius: 4px; /* 圆角固定 */ .icon-size { width: 24px; height: 24px; } /* 图标固定尺寸 */ /* 6. 全屏布局：dvh（移动端）、vh（PC端） */ .full-screen { min-height: 100dvh; } /* 移动端全屏首选 */ 九、个人总结：单位选择避坑核心（新手必看）固定尺寸用 px：边框、圆角、小图标、固定间距，精准不混乱；全局适配用 rem：字体、全局间距、布局，配合媒体查询改根字号，全站等比缩放；嵌套场景避 em：em 易累积，只用在简单局部适配，嵌套层级深的场景坚决不用；全屏/视口适配用 vw/vh + dvh：PC端用 vw/vh，移动端全屏用 dvh，避免高度跳动；流体排版用 clamp：字体、容器宽度、自适应间距，不用媒体查询，简洁又流畅；百分比慎用：记住“宽高相对父级、边距相对父级宽度”，父级无明确高度时，height: 100% 会失效。其实单位选择没有绝对的对错，核心是结合场景，保证页面适配流畅、维护便捷。我从一开始分不清各种单位，到现在能熟练搭配使用，核心就是多实操、多踩坑、多总结，新手只要记住上面的规则，就能少走很多弯路。——转载自：VixenAhri
单位：px、em、rem、vw、vh、clamp 怎么选？
开源硬件平台
立创商城
立创BOM配单
 2.4G 翻页笔由一个 RF 射频遥控器与一个无线接收器（USB 接口）组成。RF 射频遥控器内嵌有无线 RF 射频发射器，在使用时只需要将接收器插入电脑主机的 USB 接口，无需安装驱动即可正常工作。使用者只需点击 RF 射频遥控器的相关功能键便可操纵接收器，并且发射器不用对准接收器，真正体现无线自由。本翻页笔无线控制方案基于深圳市芯岭技术有限公司 XL2417D与 XL2417U 两款高性能、低功耗 2.4G 射频系统级芯片（SoC）搭建，采用XL2417D 作为发射端集成于翻页笔手持端，XL2417U 作为接收端适配电脑、平板等终端设备，核心通过 2.4G 无线通信完成翻页、激光指示等控制指令的高速稳定，传输传输距离约 200 米，接收端则依托 XL2417U 原生集成的 USB 2.0 全速协议，直接实现与终端的指令对接及执行。整体方案兼具硬件设计简洁、功耗低、抗干扰性强、适配性广的特点，完全满足办公、教学等场景下翻页笔的无线控制需求.深圳市芯岭技术有限公司是一家专注于短距离无线通讯，芯片应用解决方案商，从事芯片研发、封测，代理、技术服务、销售，为众多企业提供物联网应用芯片，技术支持，解决方案服务。
芯岭技术两颗芯片结合实现2.4G翻页笔，全部资料开源
开源硬件平台
嘉立创PCB
嘉立创PCB
嘉立创PCB
嘉立创PCB
嘉立创PCB
NYFEA徕飞公司推出小尺寸6.8mm*1.4mm的法拉电容,作为高性能国产替代新选择，在市场上引起了广泛关注。 以下是对NYFEA徕飞小尺寸法拉电容的详细介绍： 一、产品特点 小尺寸设计： NYFEA徕飞推出的法拉电容具有极小的尺寸，6.8mm×1.4mm这些尺寸设计使得它能够轻松适应各种紧凑的电子设备中的时钟电路RTC后备电池。 高性能表现： 这些法拉电容具有出色的性能表现，包括高额定电压（如3.3V）、适当的容量（如0.22F）以及稳定的充放电性能。 它们还具备快速充电的特点，充电10秒至10分钟可达到其额定容量的95%以上，非常适合需要快速响应的应用场景。 高兼容性： NYFEA徕飞的法拉电容NB614S224N-TR能够替代多个国际知名品牌的同类产品，如日本的MS614SE-FL28E、　MS621FE-FL11E、FDK及Panasonic型号ML621，以及韩国的korchip，DMS3R3224、DMS3R3304等。 这种高兼容性使得NYFEA徕飞的法拉电容能够轻松融入现有的电子设备中，无需进行复杂的改造或调整。 环保与长寿命： 法拉电容的原材料构成、生产、使用、储存以及拆解过程均没有污染，是理想的绿色环保电源。 二、应用领域 NYFEA徕飞小尺寸法拉电容因其高性能和小尺寸设计，在多个领域都有广泛的应用前景： 智能家居：作为备用电源或智能设备的储能元件，法拉电容能够提供稳定、可靠的电力支持。 智能电表：在电力系统中，法拉电容可以作为储能元件，帮助平衡电网负荷，提高电力系统的稳定性。 便携式电子设备：如手机、平板电脑等，法拉电容可以作为辅助电源或快速充电解决方案，提高设备的续航能力和充电效率。 NYFEA徕飞小尺寸法拉电容作为高性能国产替代新选择，在市场上引起了广泛关注。他们通过持续的研发投入、创新的产品设计和积极的国产替代策略，成功打破了日韩公司的垄断地位，为国内外电子设备制造商提供了更多选择和更好的服务。未来，随着科技的不断进步和市场需求的不断变化，NYFEA徕飞公司将继续致力于法拉电容的研发和创新，为电子行业的发展做出更大的贡献。  
NYFEA徕飞小尺寸法拉电容，高性能国产替代新选择
技术沙龙
大家好，我是双越。前百度 滴滴 资深前端工程师，慕课网金牌讲师，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 智能体，需要掌握哪些知识？
开源硬件平台
ZCC4981：开启高效同步升压新时代在当今电子设备日益复杂、对电源性能要求极高的背景下，ZCC4981凭借其卓越的性能和灵活的配置脱颖而出，成为同步升压控制器领域的佼佼者。无论是在便携式电子设备、电源适配器还是工业电源系统中，ZCC4981都能提供高效、稳定且可靠的电源解决方案,直接替代XR4981。广泛的输入输出电压范围：3V~36VZCC4981支持3V至36V的宽输入电压范围，这意味着它能够适应各种不同的电源场景，无论是单节锂电池（3.3V~4.2V）、多节电池组（12V~24V），还是常见的USB输入（5V）等。同时，其可调节的输出电压范围为5V至36V，能够满足从低电压到高电压的多样化需求，例如为USB设备提供5V供电，或者为高功率设备提供24V甚至更高的电压。这种广泛的输入输出电压兼容性，使得ZCC4981在多种应用场景中都能发挥出色的作用。500kHz固定开关频率：高效与稳定的平衡ZCC4981采用500kHz的固定开关频率，这一频率选择在电源设计中具有重要意义。首先，较高的开关频率可以显著减小电感和电容的体积，从而实现更紧凑的电源设计，这对于空间受限的便携式设备尤为重要。其次，500kHz的开关频率能够有效降低开关损耗，提高电源转换效率，同时保持稳定的输出性能。例如，在12V输入、24V输出的应用中，ZCC4981能够保持超过90%的转换效率，这在同类产品中表现优异。此外，稳定的开关频率还能减少电磁干扰（EMI），确保电源系统的可靠运行。可调节的软启动时间：平稳启动，保护电路ZCC4981的软启动功能是其另一大亮点。通过在SS引脚与AGND之间连接一个10nF至100nF的软启动电容（Css），用户可以灵活设置软启动时间。当电路启动时，内部0.25µA的电流源会对软启动电容进行充电，从而实现平稳的输出电压上升。例如，当Css为100nF时，软启动时间约为320ms。这种可调节的软启动机制能够有效避免启动时的电流冲击，保护电路中的敏感元件，延长设备的使用寿命。对于一些对启动特性要求较高的应用，如音频放大器或精密仪器，ZCC4981的软启动功能提供了可靠的保障。精准的电流限制与保护：安全可靠在电源设计中，电流限制功能至关重要，它能够有效防止过流损坏电路。ZCC4981通过OC引脚和外部电阻（Roc）实现了可调节的输入电流限制。例如，当Roc为100kΩ时，电流限制阈值可达12.5A。这种精准的电流限制设置不仅能够满足不同应用场景下的电流需求，还能在过流情况下提供即时保护，防止电源损坏。此外，ZCC4981还具备热关断功能，当芯片温度超过150°C时，会自动关闭输出，进一步确保电源系统的安全运行。应用场景广泛：满足多样化需求ZCC4981适用于多种应用场景，包括但不限于：便携式电子设备：如蓝牙音箱、移动电源等，其宽输入电压范围和高转换效率能够为这些设备提供稳定的电源支持，同时延长电池寿命。电源适配器：无论是为笔记本电脑、平板电脑还是其他高功率设备供电，ZCC4981都能提供高效、稳定的电压输出。工业电源系统：在一些需要高电压输出的工业设备中，ZCC4981的高性能表现能够确保系统的可靠运行，同时其可调节的输出电压和电流限制功能能够满足复杂的工业需求。ZCC4981以其卓越的性能、灵活的配置和广泛的应用场景，成为了同步升压控制器领域的理想选择。它不仅能够满足现代电子设备对电源性能的高要求，还能为工程师提供便捷的设计体验。选择ZCC4981，开启高效、稳定、可靠的电源新时代。
国产化同步升压控制器芯片ZCC4981C
硬创社
嘉立创PCB
3D打印
嘉立创PCB
【摘要】一款基于表格的研发项目管理工具，覆盖概念、系统设计、开发、测试、验收全流程，帮助研发团队规范过程管理、沉淀项目数据、实现需求追溯。适用于汽车电子 ECU 及其他嵌入式系统研发。在研发项目管理中，你是否遇到过这些问题： 需求、设计、测试数据分散在多个 Excel 文件中，版本难以统一管理。 项目成员各自维护自己的表格，信息不同步。 需要追溯需求时，要在多个文件之间来回查找关联。 项目结项后，经验教训没有系统沉淀，下一个项目继续踩坑。 这些问题的核心在于：缺乏一个统一的数据管理平台。 零绪研发项目管理工具，正是为了解决这些问题而设计。零绪是什么？ 零绪是一款基于表格的研发项目管理工具。 它提供标准化的表格模板，覆盖研发项目的完整生命周期：概念阶段、系统设计阶段、开发阶段、测试阶段、验收阶段。 每个阶段包含若干张专业设计的表格，用户通过填写表格完成项目数据的录入和管理。所有数据集中存储，团队成员访问同一份数据，避免多版本混乱。01_零绪研发项目管理工具零绪 项目管理
01_零绪研发项目管理工具
硬创社
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 为什么开始失宠了
开源硬件平台
3D打印
嘉立创纸盒
立创商城
社区数据
今日帖子
-
今日互动量
-
在线人数
-
帖子总量
-
用户总量
-
功能讨论
（）
主题
打赏记录
激励规则
服务时间：周一至周六 9::00-18:00 · 联系地址：中国·深圳（福田区商报路奥林匹克大厦27楼） · 媒体沟通：pr@jlc.com · 集团介绍
移动社区
联系我们