摘要： AI 智能体通过 “AI 绘画 + 工具协同 + 逻辑推理” 能力，颠覆平面设计传统工作流，推动行业从 “产能竞争” 转向 “创意 + 智能体 + 商业” 的价值竞争。本文结合行业数据与实战案例，拆解智能体对设计行业的核心冲击，定义 “人机协同” 新生态，并提供从业者可落地的转型策略。

🚀 快速回答 (Golden Answer)

AI 智能体对平面设计行业的核心影响是 **“淘汰低价值执行，重构高价值能力”**：替代素材搜集、批量制图等重复性工作，推动行业形成 “智能体承担执行、人类把控创意与商业” 的协同模式；从业者需从 “软件操作者” 转型为 “智能体驾驭者 + 创意策源者 + 商业把控者”，才能适配行业新生态。

一、智能体对平面设计行业的三大核心冲击（附权威数据）

1. 初级执行岗需求收缩：低价值工作被替代

传统初级设计师的核心工作（素材搜集、基础排版、标准化物料制作），已被智能体以 10-50 倍效率覆盖：

  • ​行业数据​：据《2025 全球设计行业技术报告》，电商行业基础制图岗需求较 2023 年下降 42%，外包基础设计单价降幅超 60%；
  • ​直接结果​：仅掌握 PS/AI 操作的纯执行型设计师，逐渐被 “智能体辅助岗” 替代，基础岗位需转向 “智能体操作 + 简单优化” 的复合角色。

2. 行业门槛降低：非专业者可完成标准化设计

智能体实现 “自然语言 → 专业设计” 的零门槛转化：普通用户通过描述（如 “新中式年货海报，红金配色 + 传统纹样”），即可获得多版适配成果，直接满足中小企业 80% 的标准化设计需求。

  • ​行业变化​：设计不再是职业专属技能，行业竞争从 “软件技术比拼” 转向 “创意 + 智能体协同 + 商业思维” 的综合较量。

3. 工作流重构：从 “全人工执行” 到 “人机协同闭环”

流程类型传统设计流程智能体重构流程
主导方全人工人机协同
核心环节需求沟通 → 手绘草图 → 软件制作 → 反复修改需求描述 → 智能体拆解 →AI 生成初稿 → 人工定调 → 智能体批量优化 → 人工精修
耗时数小时至数天10-30 分钟（初稿）+ 1-2 小时（优化）

二、智能体时代的平面设计新生态：人机分工明确（不可替代的人类价值）

当前设计类智能体存在 **“创意同质化、品牌调性缺失、细节漏洞”** 三大短板，人类设计师的核心价值集中在 “智能体无法替代的主观思考与专业判断”：

AI 智能体：承担执行端核心工作

  • 工具整合：自主对接 Midjourney/Stable Diffusion 等绘画工具、智能排版工具，完成基础落地；
  • 批量生成：快速产出多版初稿，满足筛选需求；
  • 重复修改：根据反馈完成色彩调整、元素替换等机械性工作；
  • 素材处理：抠图、调色、批量制图等低价值工作。

人类设计师：把控价值端核心环节

  • 需求拆解：结合品牌定位，向智能体传递精准设计方向；
  • 创意定调：构思差异化创意，规避智能体的同质化问题；
  • 细节精修：打磨设计细节，融入品牌文化；
  • 风险把控：排查版权、商标等合规问题。

三、智能体时代设计师的核心能力重构（行业刚需）

传统 “软件操作 + 手绘” 的单一技能权重下降，三大复合能力成为行业刚需：

1. 智能体深度驾驭能力（基础必备）

  • 基础：熟练使用 Canva AI、Adobe Firefly 等设计智能体，掌握 **“精准需求描述（Prompt Engineering）”** 技巧（如 “电商主图，ins 风，暖色调，突出产品质感，留白占比 30%”）；
  • 进阶：自定义智能体的工具协同逻辑（如 “先调用 AI 绘画生成主视觉 → 再用智能排版工具适配尺寸”），搭建专属设计工具库；
  • 评估：10 分钟内筛选出智能体生成的 3 版最优初稿，精准定位问题点（如 “色彩与品牌调性不符”）。

2. 创意与审美表达能力（核心壁垒）

包含品牌调性解读、创意构思、视觉表达、色彩版式设计等能力，解决智能体 “能生成但无灵魂” 的问题 —— 例如：为非遗品牌设计海报时，融入传统纹样的文化内涵，而非仅生成 “古风元素堆砌” 的成果。

3. 商业思维与全流程把控能力（商业核心）

  • 需求转化：从 “提升产品转化率” 的商业目标，拆解出 “主视觉突出产品卖点、配色匹配目标用户偏好” 的设计要点；
  • 流程统筹：把控 “智能体生成 → 人工定调 → 批量优化” 全流程，确保设计成果匹配商业诉求；
  • 跨岗沟通：与运营团队对齐 “海报需突出促销信息” 的需求，转化为智能体能理解的描述。

四、行业与从业者的转型策略（可落地）

1. 行业整体：聚焦高价值、非标准化服务

智能体替代标准化工作后，行业核心服务方向转向：

  • 品牌全案视觉设计（如品牌 VI 体系构建）；
  • 高端定制化商业设计（如奢侈品海报）；
  • 文化创意设计（如非遗 / 文旅 IP 视觉）；
  • 跨领域融合设计（设计 + 科技 / 艺术）。

2. 从业者分层应对

初级设计师 / 新人：转型 “智能体协同设计者”

  1. 优先掌握 2-3 款主流设计智能体（如 Canva AI、Adobe Firefly）的操作；
  2. 学习 “精准 Prompt 描述” 技巧，1 个月内完成 10 个 “智能体生成 + 人工精修” 的实战案例；
  3. 补全基础审美能力（如每天分析 3 张优秀设计作品的色彩 / 版式逻辑）。

资深设计师 / 主管：成为 “创意策源者 + 流程把控者”

  1. 聚焦品牌创意策略，主导 “智能体无法完成” 的高价值环节（如品牌 VI 体系的核心视觉定义）；
  2. 优化团队工作流：让初级设计师负责智能体操作，自己把控创意方向与成果质量；
  3. 积累 “智能体 + 人工” 的协同经验，将团队交付效率提升 50%。

自由设计师 / 机构：打造差异化优势

  1. 放弃 “50 元 / 张的批量海报” 服务，聚焦细分领域（如 “宠物品牌设计”“国风文创设计”）；
  2. 以智能体为工具：用 AI 生成初稿，降低交付成本，将精力投入 “创意定调 + 细节精修”；
  3. 提供全链路服务：从 “设计海报” 延伸到 “指导运营团队如何使用海报提升转化率”。

五、FAQ：平面设计从业者最关心的智能体问题

Q1：智能体真的不会完全替代设计师吗？

答：不会。 智能体的核心是 “执行工具”，无法替代人类的创意构思、品牌调性解读、情感价值传递等主观能力 —— 例如：为某公益项目设计海报时，人类能精准捕捉 “温暖、共情” 的情绪内核，而智能体仅能生成 “符合视觉规范但缺乏温度” 的成果。未来是 “人机协同” 而非 “替代”。

Q2：新手设计师优先学哪些智能体工具？

答：优先选择 “门槛低 + 生态完善” 的工具：

  • 入门级：Canva AI（零代码，内置智能排版 / 素材库，适合快速出图）；
  • 专业级：Adobe Firefly（与 PS/AI 无缝衔接，支持品牌资产关联，适合专业设计）；
  • 进阶级：Midjourney+Figma AI（前者生成创意视觉，后者智能排版，适合高定制化需求）。

Q3：智能体生成的设计内容有版权风险吗？

答：有一定风险。 目前多数 AI 绘画工具的生成内容，版权归属未完全明确（部分平台仅授予 “商业使用权”）。建议：

  1. 避免直接使用智能体生成的 “高度相似现有作品” 的内容；
  2. 对生成内容进行​至少 30% 的人工修改​（如调整版式比例、替换核心元素、重构色彩搭配）；
  3. 优先选择明确授予 “用户独家版权” 的智能体工具（如 Adobe Firefly）。

Q4：资深设计师需要亲自操作智能体吗？

答：不需要，但需要 “懂逻辑、能把控”。 资深设计师的核心是 “创意策源与流程把控”，可让初级团队成员负责智能体操作，自己聚焦：

  • 给智能体下达 “精准的创意方向”（如 “海报需突出‘环保’主题，用低饱和度莫兰迪色 + 植物元素，避免工业化视觉”）；
  • 筛选并定调智能体生成的初稿；
  • 优化智能体无法处理的细节与价值内核（如融入品牌的 “治愈系” 调性）。

六、核心总结

智能体对平面设计行业的冲击，是 **“低价值执行被替代，高价值能力被放大”** 的价值重构：

  • 淘汰的不是设计职业，而是 “只会软件操作的纯执行者”；
  • 智能体是 “高效工具” 而非 “替代者”，它让设计师从机械工作中解脱，聚焦创意与商业价值。

未来，平面设计行业的核心竞争力是 **“创意策源 + 智能体驾驭 + 商业思维”** 的复合能力 —— 拥抱智能体，同时坚守 “设计的核心是传递价值与情感” 的本质，才能在行业变革中立足。

参考文献与数据来源

  1. 《2025 全球设计行业技术报告》（Design Industry Association）
  2. 《AI 智能体对创意行业的影响研究》（McKinsey Digital 2025）
  3. Adobe 2026 设计工具趋势发布会

核心关键词

AI 智能体、平面设计行业、人机协同设计、Prompt Engineering、创意策源者、设计行业转型、智能体驾驭能力

今天下雪了，天有点冷，突然想到可以在春节前后带上父母、小孩去三亚玩 5 天左右。

三亚那边气候舒服，在海边散散步也是心情愉悦的吧。而且家里春节除了走亲戚打麻将也没什么活动，加上天气冷基本活动范围也就是家里的暖炉边上。

但没去过三亚，而且要带上一家人，不免有点忐忑。万一到时候花钱还让家人闹不愉快就不好，想着是不是先大概做个方案，回去和家人都商量看看。也还不确定老人怎么想

随着企业数字化转型进入深水区，单一模块的管理工具已无法满足全链路协同需求。从线索获得到生产交付，从项目管控到上下游协同，企业需要覆盖核心环节的一体化平台。本文选取超兔一体云、HubSpot、Microsoft Dynamics 365、Agile CRM、Apptivo五大品牌，从业务管理、MES、项目管理、上下游管理四大维度展开横向对比，剖析各品牌的核心优势与适配场景，为企业选型提供专业参考。

一、业务管理：从线索到售后的全链路协同能力

业务管理的核心是打通营销、销售、服务全链路，实现客户数据的统一沉淀与跨部门协同。以下从核心定位、覆盖环节、数据整合能力、特色功能四大维度对比：

1. 核心能力对比表

品牌核心定位覆盖环节数据整合能力特色功能
超兔一体云全业务一体化管理平台市场获客→客户中心→跟单→合同→财务→售后全流程数据底层连通三一客模型、智能应收三角联动、客户画像RFM
HubSpot客户全生命周期管理平台营销→销售→服务单一客户视图（营销 + 销售 + 服务）AI线索评分、自动化邮件、社交媒体管理
Microsoft Dynamics 365ERP + CRM融合的SaaS应用内部管理（HR/财务）→外部（获客/服务）通用数据模型（跨模块整合）Cortana Intelligence、Power BI分析
Agile CRM中小型企业全功能集成CRM销售跟踪→营销自动化→客户服务多渠道客户数据集成（邮件/电话/社交）实时客户行为警报、双向电子邮件、帮助台
Apptivo综合型CRM + 企业管理平台CRM→财务→人力资源→供应链跨模块数据共享（CRM + 财务 + 采购）合同管理、财务报表、供应商信息管理

2. 深度分析

（1）超兔一体云：全流程闭环的“业务神经中枢”

超兔的业务管理以“全业务一体化”为核心，解决了中小制造企业“部门数据割裂”的痛点：

  • 线索到客户的闭环：通过“三一客模型”（精准识别客户需求）将多渠道线索（百度、抖音、地推）快速转化为客户，RFM模型实现精准营销；
  • 合同到财务的联动：智能应收系统自动触发“签约→开票→回款”三角联动，超发预警规避风险；
  • 数据底层连通：全流程数据（市场→销售→生产→财务）共享，例如销售订单自动同步至MES生成生产任务，售后反馈更新客户画像。

其业务流程闭环可通过Mermaid图直观展示：

暂时无法在飞书文档外展示此内容

（2）HubSpot：客户增长驱动的“全生命周期管家”

HubSpot聚焦“以客户为中心”，通过三大模块（Marketing Hub、Sales Hub、Service Hub）打通全链路：

  • 营销端：自动化邮件、社交媒体工具追踪客户互动（如网页访问、邮件打开率），生成线索评分；
  • 销售端：销售管道可视化，AI推荐高价值线索（如“访问过定价页”的线索），缩短成交周期；
  • 服务端：工单系统 + 知识库实现售后闭环，反馈数据回传CRM更新客户画像。

其核心优势是单一客户视图，跨部门协同无需切换系统（如营销给销售推送“高活跃度线索”，服务给销售反馈“客户痛点”）。

（3）Microsoft Dynamics 365：企业级的“资源整合平台”

Dynamics 365以“通用数据模型”为核心，融合ERP与CRM能力：

  • 内部管理：覆盖HR、财务、运营等环节，降低企业运营成本（如自动核算员工绩效）；
  • 外部增长：通过全通路客户互动（网页、社交、邮件）提升获客效率，Cortana Intelligence分析客户数据（如预测客户 churn 率）；
  • 生态融合：与Azure、Office 365深度集成，适合已采用微软生态的中大型企业。

（4）Agile CRM：中小型企业的“全功能集成工具”

Agile CRM聚焦中小型企业，提供“销售 + 营销 + 服务”全功能集成：

  • 多渠道通信：同一页面支持打电话、发邮件、发推文，监控客户行为并提供实时警报，在一个地方管理客户历史服务台票，一页展示客户详细信息及通信历史（按时间排序），并可集成其他业务应用的客户数据；
  • 自动化流程：将网站访问者转为潜在客户，自动培养/跟踪/评分线索（如“发送欢迎邮件→3天后推送案例→7天后跟进”）；
  • 客户视图：一页展示客户详细信息 + 通信历史（按时间排序），集成其他应用数据（如Mailchimp、Slack）。

（5）Apptivo：综合型企业管理的“一站式平台”

Apptivo是CRM + 财务 + HR + 供应链的综合平台：

  • 模块覆盖：从CRM到财务报表、人力资源管理，再到供应链（供应商、库存）；
  • 跨模块协同：CRM订单自动生成财务发票，供应链库存数据同步至CRM（如“库存不足”提醒销售）；
  • 易用性：界面简洁，适合需要“一套系统管全部”的小型企业。

二、MES：生产制造的数字化闭环能力

MES的核心是连接ERP与车间现场，实现生产计划、进度、质量的实时管控。五大品牌中，仅超兔一体云与Microsoft Dynamics 365具备MES能力，其余品牌无直接功能。

1. 核心能力对比表

品牌定位核心功能CRM联动能力适配企业类型
超兔一体云小微生产企业轻量化MES智能排程、进度甘特图、物料BOM、生产报工与CRM订单→库存→采购闭环联动中小制造企业
Microsoft Dynamics 365云端一体化MES生产计划、实时监控、质量管理、设备维护通用数据模型整合（ERP + CRM + MES）中大型制造企业

2. 深度分析

（1）超兔一体云：小微适配的“轻量化MES”

超兔MES聚焦中小制造企业，核心优势是与CRM的深度联动：

  • 闭环流程：CRM销售订单自动同步至MES，生成生产BOM与任务；MES领料/退料联动CRM库存（出库/入库）；报工/质检数据回传CRM，合格成品自动入库；
  • 功能轻量化：支持正排/倒排程（最快时间/最小班组策略）、小组计件报工、逐工序质检，车间大屏展示关键指标（如进度偏差、良品率）；
  • 智能采购：基于订单BOM与库存数据，自动计算物料需求并同步至CRM采购模块，生成采购计划（如“生产100台设备需要500个零件→库存有300个→采购200个”）。

其MES与CRM联动流程如下：

暂时无法在飞书文档外展示此内容

（2）Microsoft Dynamics 365：企业级的“云端MES”

Dynamics 365 MES依托Azure云生态，核心优势是智能与物联网集成：

  • 生产管控：覆盖生产计划、实时监控、质量管理与追溯、设备维护等全环节（如通过Azure IoT采集设备数据，预测设备故障）；
  • 生态融合：与Dynamics 365 ERP、CRM模块通过通用数据模型整合，实现“订单→生产→交付”的端到端协同（如“客户下单→生产计划调整→设备启动→交付”）；
  • 案例：某食品企业通过Dynamics 365 MES提升生产效率70%（AI优化生产排程，减少 downtime）。

三、项目管理：从商机到交付的全生命周期管控

项目管理的核心是资源优化与进度管控，实现项目在预算内按时交付。以下从模块名称、核心能力、协作工具、成本管控四大维度对比：

1. 核心能力对比表

品牌模块名称核心能力协作工具成本管控能力
超兔一体云多方项目跟单模型项目组→合同→采购→收支管控甘特图、工作流引擎精确收支差控制
Microsoft Dynamics 365Project Operations销售报价→资源调度→进度跟踪→成本核算Microsoft Teams、Power BI资源负载平衡、成本分配
HubSpot轻量协作模块销售商机跟踪、营销活动日历Asana/Trello集成无
Agile CRM拖放式项目管理任务创建→人员分配→进度跟踪内置任务管理无
Apptivo独立项目模块任务→里程碑→资源分配项目日历基础成本跟踪

2. 深度分析

（1）超兔一体云：复杂项目的“全周期管控”

超兔的多方项目跟单模型适合“业务主体多方参与”的复杂项目（如大型设备交付）：

  • 全生命周期覆盖：在一个项目视图内管理项目组、合同订单、采购跟单、收支管控（如“项目收入 - 采购成本 - 费用”）；
  • 进度与成本：通过甘特图实时跟踪进度（如“设备生产→安装→调试”），精确控制收支差（避免项目超预算）；
  • 协作：工作流引擎自动分配任务（如“项目启动→给采购部分配“物料采购”任务”），支持“项目→客户→财务”的联动（如“项目里程碑触发客户跟进”）。

（2）Microsoft Dynamics 365：企业级的“资源优化工具”

Dynamics 365 Project Operations模块聚焦项目型企业（如工程、咨询）：

  • 资源管理：智能匹配人员技能与项目需求（如“找“懂Python”的工程师”），平衡资源负载（避免“某员工同时做3个项目”）；
  • 进度跟踪：通过Power BI生成实时项目报表（如“项目进度偏差、成本超支情况”），集成Microsoft Teams实现团队沟通（如“在Teams中讨论项目问题→同步至Project Operations”）；
  • 成本管控：支持成本分配（如人工成本→项目），帮助企业最大化项目盈利能力（如某咨询公司通过Project Operations提升项目利润率15%）。

（3）其他品牌：轻量协作的“补充工具”

  • HubSpot：通过Sales Hub跟踪销售商机（如“需求确认→方案提交→合同签订”），营销活动日历管理多渠道活动（如直播、白皮书发布），需集成Asana/Trello实现复杂项目管理；
  • Agile CRM：拖放式项目管理界面，适合中小型项目（如营销 campaign）；
  • Apptivo：独立项目模块，支持任务与里程碑管理，适合基础项目协作。

四、上下游管理：从供应商到客户的全链路协同

上下游管理的核心是打通供应商、企业、客户的信息壁垒，实现全流程数据共享。以下从平台/模块、协同环节、数据共享、特色功能对比：

1. 核心能力对比表

品牌平台/模块协同环节数据共享能力特色功能
超兔一体云OpenCRM共生平台询价→采购→发货→对账→售后企业与伙伴双向数据同步三流合一对账、供应商评级雷达图
Microsoft Dynamics 365供应链模块采购→订单→物流→对账供应商实时数据共享供应链可视化、Azure IoT库存预测
HubSpot间接协同渠道合作伙伴→客户线索与业绩数据共享合作伙伴门户、线索分配
Agile CRM客户侧管理客户互动→售后客户行为数据共享实时客户警报、多渠道通信
Apptivo供应链模块采购→供应商→库存CRM与供应商数据同步供应商信息管理、库存同步

2. 深度分析

（1）超兔一体云：伙伴共生的“全流程协同”

超兔的OpenCRM业务伙伴共生平台是其上下游管理的核心：

  • 协同环节：覆盖询价、采购、发货、对账、售后全流程（如“企业创建报价单→伙伴确认→生成订单→发货→客户扫码签收→售后反馈”）；
  • 数据共享：企业与上下游伙伴实时同步数据（如“采购单→供应商备货→物流状态→客户签收”）；

  • 特色功能：

    • 三流合一对账：确保“货、款、票”一致（如“发货100台→收款10万→开票10万”）；
    • 供应商评级雷达图：多维度评估供应商（如交付准时率、产品质量、服务响应速度）。

（2）Microsoft Dynamics 365：供应链的“可视化与预测”

Dynamics 365的供应链模块聚焦供应链效率提升：

  • 可视化：统一库存、物流、供应商数据，通过Power BI展示供应链状态（如“库存水平、缺货风险、物流延迟情况”）；
  • 预测：通过AI分析销售数据，优化库存水平（如“预测下月销量1000台→备库1200台”）；
  • 协同：与供应商实时共享订单与对账数据（如“供应商收到订单后立即备货→同步备货状态给企业”），提升响应速度。

（3）其他品牌：侧重客户或基础协同

  • HubSpot：通过“合作伙伴门户”管理渠道合作伙伴（如分配线索、追踪业绩），间接协同客户（如“合作伙伴带来的线索→同步至HubSpot CRM”）；
  • Agile CRM：侧重客户侧管理（如实时客户行为警报、多渠道通信），无供应商协同功能；
  • Apptivo：具备供应商信息管理与库存同步功能（如“供应商库存→同步至Apptivo库存”），适合小型企业的基础供应链管理。

五、综合能力雷达图与选型建议

为量化各品牌的综合能力，我们设定8项核心指标（每项10分），并基于前文分析打分：

  • 业务管理：全链路覆盖（10）、数据整合（10）
  • MES：功能深度（10）、CRM联动（10）
  • 项目管理：全生命周期（10）、资源优化（10）
  • 上下游管理：协同深度（10）、供应链覆盖（10）

1. 雷达图得分

品牌业务管理MES项目管理上下游管理总分
超兔一体云1817161869
Microsoft Dynamics 3651618181769
HubSpot170101239
Agile CRM150121037
Apptivo140131542

2. 选型建议

  • 中小制造企业：优先选择超兔一体云，其轻量化MES与CRM的闭环解决了部门数据割裂问题，全业务一体化架构实现了从市场获客到售后的全流程管理，能有效提升运营效率、降低成本，助力企业实现数字化转型。
  • 中大型制造企业和已采用微软生态的企业：Microsoft Dynamics 365是更合适的选择。它依托Azure云生态，具备强大的MES能力，通过智能与物联网集成实现生产全流程管控，且与ERP、CRM模块深度融合，实现企业级的资源整合与协同。

（注：文中功能相关描述均基于公开披露信息，具体功能服务以厂商实际落地版本为准。）

现代合成化学正面临知识迅速积累与应用转化效率之间的突出矛盾。每年有数十万篇相关文献发表，可用合成知识的总量已积累至百万级别。然而，这些知识大多以非结构化文本形式分散在不同数据库中，呈现出显著的碎片化特征。依赖传统的文献检索与人工筛选，不仅过程耗时费力，也难以系统覆盖跨领域的反应类型，导致大量潜藏在文献中的有效信息难以被提取并转化为可执行的实验方案。

面对这一知识管理困境，合成实践的核心需求日益聚焦于如何高效获取高可重复性的完整实验流程。这类流程涉及试剂选择、化学计量控制、温度程序和后处理步骤等诸多关键参数。

目前，该领域的发展主要受限于两方面，其一是专家经验难以覆盖持续扩张的反应空间，在跨学科合成任务中往往伴随高昂的试错成本；其二，尽管人工智能技术发展迅速，但通用模型在化学领域的应用仍存在可靠性不足、易产生「幻觉」及缺乏置信度评估等问题，尚无法满足实验级的精度要求。因此，将海量、分散的化学知识转化为结构化、可信赖的合成指导，已成为突破领域效率瓶颈的关键。

在此背景下，耶鲁大学研究团队近期提出 MOSAIC 模型，将通用大语言模型转化为一个由众多专业化学专家构成的协作系统，通过专业分工有效抑制模型幻觉，提供可量化的不确定性评估，实现了从反应描述到完整实验方案的系统生成，有望在药物发现、材料开发等领域实质性地提升科研效率。

相关研究成果以「Collective intelligence for AI-assisted chemical synthesiss」为题，已发表于 Nature。


论文地址：
https://www.nature.com/articles/s41586-026-10131-4
关注公众号，后台回复「MOSAIC」获取完整 PDF

更多 AI 前沿论文： 

https://hyper.ai/papers

基于 Pistachio 数据库，构建各擅所长的「AI 化学专家」

该研究基于 Pistachio 数据库开展。这是一个商业化、高度结构化的化学反应知识库，内容主要源自全球专利文献。通过对专利中记载的反应物、产物、试剂、溶剂、产率及关键步骤文本描述进行系统提取与标准化处理，数据库将其统一编码为机器可读的格式（如 SMILES 字符串）。研究团队并未直接使用全量数据，而是执行了严格的质量筛选，核心标准是要求反应记录必须包含详细、可执行的实验步骤描述，而不仅仅是反应物与产物的映射关系，从而确保后续训练的模型学习的是「如何实现反应」，而非仅仅是「反应结果是什么」。

经过筛选的数据通过专门设计的核度量网络，被转化为 128 维的反应特异性指纹。该数字化表征旨在捕捉化学反应的本质转化特征，所有指纹向量共同构成了一个表征广阔化学知识空间的「反应宇宙」。基于此向量空间，研究采用无监督的 Voronoi 聚类算法（通过 FAISS 库实现），将其划分为 2,489 个互不重叠的专业区域，每个区域聚集了化学性质高度相似的反应类型。

最终，每个 Voronoi 区域内的反应文本被用于独立微调一个专用的 Llama-3.1-8B-Instruct 模型，由此形成 2,489 个各擅所长的「AI 化学专家」。整个 MOSAIC 框架的知识范围与能力边界，根本上由这份以专利为核心的训练数据集所决定。这也解释了系统在某些快速发展的前沿领域（如光化学）表现相对受限的原因——这些内容在现有专利数据库中的覆盖尚不充分。

MOSAIC：由众多专业化学专家构成的去中心化协作系统

MOSAIC 模型的核心设计思想是将通用大语言模型 Llama-3.1-8B-instruct 转化为一个由众多专业化学专家构成的去中心化协作系统。这一搜索驱动的架构显著降低了对硬件资源的需求，仅需使用适中规模的算力配置（如 4 个 GPU）即可对特定任务子集进行训练，无需依赖大规模计算集群。系统通过专家分工机制有效抑制模型幻觉，并提供可量化的不确定性评估，同时支持动态扩展新专家而无需重新训练整个系统，在灵活性与可持续性上具有明显优势。

MOSAIC 模型设计思路

为突破大语言模型在大规模数据上训练时面临的算力与协调瓶颈，MOSAIC 通过 3 个渐进式组件构建而成：

反应相似性度量：

研究设计了一种基于神经网络的非线性映射（核度量网络，KMN），用于量化化学反应之间的相似性。它将 SMILES 编码的反应转化为 128 维的反应特异性指纹（RSFP），使其欧氏距离能够近似反应类别关系，从而捕捉反应的本质转化特征。

知识空间聚类：

利用 FAISS 库的高效索引能力，对 RSFP 向量空间进行无监督 Voronoi 聚类，自动划分出 2,498 个化学性质高度聚集的专业区域，每个区域代表一个特定的化学知识领域。

领域专家训练：

在每个聚类对应的反应数据上，独立微调专用的专家模型。研究采用两阶段训练策略：先在完整数据集上进行基础模型微调，再利用各聚类数据深化对应专家的领域知识，使专家在保持通用化学理解的同时，具备深厚的专业认知。

MOSAIC 首先将查询反应编码为 RSFP，并通过 FAISS 快速定位其所属的 Voronoi 区域及对应的专家。例如，对于一个氯代芳烃的 Buchwald-Hartwig 偶联反应，系统会调用精于此领域的专家，生成完整、可读的合成步骤。实验验证表明，完全依照该方案操作，最终能以 96% 的产率获得目标产物。

MOSAIC 实现 94.8% 组分覆盖率与 71% 合成成功率

该研究进一步通过多维度评估系统验证了 MOSAIC 模型的综合性能，其核心价值在于将海量文献知识转化为高可信度的合成智能。

在产率预测与核心组分识别方面，MOSAIC 模型通过解析完整的实验程序文本，实现了对反应产率的量化预测。如下图所示，采用分箱策略后，预测区间中心与真实产率中位数显示出显著相关性（R² = 0.811）。在识别反应关键组分（试剂、溶剂）方面，模型展现出优秀的覆盖能力，在集成前三位专家的预测结果后，能至少部分识别出正确组分的综合成功率高达 94.8%。值得注意的是，即便预测条件与文献记录不完全一致，其输出也常为化学上可行的替代方案，体现了深层的专业判断力。

MOSAIC 的产率预测分析

在 12 类重要反应（Suzuki 偶联、Buchwald-Hartwig 胺化等）的对比测试中，如下图所示，与 ChatGPT-4o、Claude 3.5 等通用大语言模型相比，MOSAIC 在提供明确、可行的合成指导方面 consistently 表现更优。这一优势在模型参数量仅为 80 亿的背景下尤为突出，证明了领域专业化微调的有效性。更重要的是，MOSAIC 克服了通用模型在化学任务中常见的指令遵循不稳定、回答随意性大等问题，提供了稳定、可靠的输出，这对实际实验至关重要。

MOSAIC 与通用 LLMs 的比较

为了评估所提出框架的实用性、通用性和可靠性，该研究还通过执行现代化学合成基础反应的精确、最高排名预测进行了广泛的实验验证。研究人员把重点放在了对药物和材料开发至关重要的广泛适用的催化反应上。Buchwald-Hartwig 胺化形成的碳-氮键在药物分子中普遍存在，这些具有挑战性的反应的条件被准确预测。实现了类药支架的高效组装，在对从天然产物到功能材料的应用至关重要的烯烃转化方面展示了特别的优势。

此外，MOSAIC 模型的实用性在大量新颖化合物的成功合成中得到有力证实。在总计 37 个目标化合物的合成中，有 35 个依据模型的首次推荐即告成功，整体成功率达 71%。验证范围涵盖从经典偶联反应到选择性转化，并包括指导开发全新氮杂吲哚成环方法这一体现创新能力的案例。

尤为重要的是，模型内部的置信度指标（最近专家质心距离）与实验成功率呈现明确的正相关关系：高置信度预测（距离<100）的成功率超过 75%。这为化学家提供了宝贵的量化决策依据，使其能在高成功率目标与探索性尝试之间进行有效的资源分配。

化学合成迈入精准智造新纪元

在推动化学合成智能化的全球进程中，学术界与工业界正沿着互补的轨道协同发力，共同重塑从分子发现到工艺生产的全链条。

高校的研究如同探索未知领域的先锋，专注于攻克底层计算的极限与科研范式的革新。麻省理工学院（MIT） 的研究人员巧妙地将用于图像生成的「扩散模型」迁移至化学反应领域，实现了对关键「过渡态」结构的超快速计算——将传统需耗时数日的任务压缩至数秒之内，并以 0.08 埃的原子级精度为反应预测提供了前所未有的微观洞察。

与此同时，斯坦福大学的团队则致力于重构科研本身的工作方式，构建 AI 驱动「虚拟实验室」系统，能够自主组建多学科虚拟团队，在「首席研究员 AI」的协调下进行秒级协作与辩论，已在疫苗设计等复杂课题中提出了超越常规的创新思路。此外，哈佛大学等机构的研究将人工智能的模拟能力推向宏观尺度，其提出的统一框架成功实现了对包含百万原子的复杂铁电材料的精确模拟，为从本质上设计新一代功能材料提供了强大的数字透镜。

相较于学术界对前沿的开拓，企业界的创新则更注重于将尖端算法转化为解决实际痛点的生产力与市场竞争力。德国化工巨头巴斯夫在全球范围内部署 AI，不仅推出了辅助研发的「AI 化学家 Copilot」，将新材料开发周期大幅缩短了 60%，更将 AI 深度融入生产优化、物流规划和预测性维护等环节，实现了从实验室到工厂的全价值链增效。

而在制药领域，总部位于瑞士的诺华（Novartis） 等药企正以「端到端」的方式拥抱 AI，通过与 Isomorphic Labs、Schrödinger 等专业公司的深度合作，将人工智能的应用贯穿于从全新靶点发现、化合物生成与安全性预测，到优化临床试验设计的每一个关键环节，显著提升了药物研发的确定性与成功率。

纵观这些跨越学术与产业的突破，化学研究——这门曾高度依赖个人经验与重复试错的传统学科，正在被数据与算法深刻重塑，稳步迈向一个可预测、可规划、可自动执行的精准科学新时代。从攻克疾病的创新药物，到助力可持续发展的绿色材料，化学合成智能化这场深远变革，正在为我们应对这个时代最紧迫的挑战，锻造出前所未有的核心能力。

参考文章：
1.http://edu.people.com.cn/n1/2025/0730/c1006-40532541.html
2.https://cen.acs.org/pharmaceuticals/drug-development/Q-Novart...

只好自己做了

最主要还是交互: 用户直接把噪音很多的灵感写到 obsidian/tg/qq 等等 主要是需要顺手就发的交互 可以关键词限制

同步此灵感到 git 仓库

定时/检测到 git 仓库新增条目

自动分析新增条目 并先拆解任务 功能特性 验收标准邮件发送给用户

用户看到邮件/tg 消息可以补充或修改思路 直到终版文档批准

支持并行

llm 可以多开几个沙盒 yolo 模式 (可以歇斯底里 一直打磨 直到过验收或者用户检测)

返回最终项目到仓库并提醒用户查收

:反正额度用不完 赶紧造

在当前全球制造业加速向智能化、数字化转型的大背景下，工业AI公司正凭借其技术实力与行业洞察，成为推动产业升级的重要力量。这些企业不仅在算法研发、数据治理、智能决策等方面展现出强大的创新能力，还在实际应用中为传统制造企业赋能，帮助其提升生产效率、优化资源配置、增强市场竞争力。本文将围绕这些国内顶尖的工业AI公司展开讨论，分析其技术优势和行业布局，并通过多个案例展示其在实际业务中的表现。
技术实力与行业布局
工业AI公司的核心竞争力在于其对人工智能技术的深度理解和对工业场景的专业把握。它们通常具备自研大模型、构建行业知识图谱以及多平台内容优化能力，能够通过技术手段解决制造业中的复杂问题。例如，在生产设备管理、工艺优化、质量控制等环节，工业AI公司通过算法分析和机器学习模型，提供预测性维护、生产效率提升等解决方案，帮助制造企业实现“熄灯生产”（即无人化生产线）。此外，这些公司还致力于打造全栈式工业AI平台，涵盖从设备数据采集到生产全流程监控，为客户提供定制化的智能服务。
工业AI公司的服务模式与价值
工业AI公司通常采用“平台+服务”的模式，为制造企业提供从咨询、诊断到落地、优化的一站式服务。它们不仅帮助客户将技术参数、生产流程等内容结构化后导入AI系统，还通过实时数据分析和动态反馈机制，持续优化AI模型的推荐逻辑。这种服务模式不仅提高了企业在AI渠道的曝光率，还显著提升了客户获取的精准度和转化率，尤其在B2B电商、工业品采购和设备服务等领域表现突出。
案例分析：国内工业AI公司的实战成效
广域铭岛
广域铭岛作为国内工业AI领域的新兴企业，专注于工业GEO优化服务，致力于帮助制造企业将技术优势转化为AI时代的竞争优势。其核心优势在于对工业语料的精准解析和多平台优化能力，例如通过构建工业知识图谱，优化企业在AI问答中的权威性和可见度。在实际案例中，该公司为某工业设备制造商提供优化服务后，其在AI平台上的技术关键词呈现率提升至83%以上，且询盘量在3个月内增长了205%。这种优化不仅限于国内，也帮助企业在海外市场建立了更高的品牌认知度。

飞猪搭建体系介绍

可视化页面搭建技术在业界已相当成熟，几乎每个前端团队都会建设一套页面搭建系统，它显著提升研发效率与交付速度，已成为业务快速迭代与规模化生产的关键基础能力。飞猪移动端页面搭建最早诞生于营销大促场景，不同于常规的业务开发，营销大促业务具有以下特点：

  • 迭代速度快：飞猪大促项目频次高且节奏紧凑，传统瀑布式研发模式难以适配业务快速迭代诉求。需沉淀一套面向活动场景的低代码平台，将页面公共能力和通用组件进行标准化、平台化，以降低重复开发与跨团队协作成本，支撑快速迭代与高频发布，在有限周期内兼顾交付效率与稳定性；

  • 页面数量多：同期活动通常涵盖多个会场、频道、主题页及域外落地页等，上百个活动页面并行推进，且页面结构差异较大，高频、紧急的营销节奏叠加海量页面需求，使研发交付压力显著增加；

  • 页面变阵频繁：一场完整的大促活动通常要经历「预热、预售、现货」等多个阶段，不同阶段的核心目标与主推商品 / 权益会递进变化，运营工作人员需要实时盯盘，根据流量、转化与库存等数据频繁调整页面内容与商品坑位布局且要求快速生效；

基于上述特性，飞猪移动端页面搭建体系应运而生，我们围绕可视化搭建、数据配置与动态渲染三大核心能力，打造了一套面向高频迭代与规模化交付的页面搭建体系。该体系从初代寄生于阿里集团搭建平台下的一个服务站点起步，先后经历了数据投放服务自建、平台能力自建、搭建服务与渲染底座自研。最终形成了当前将数据投放与页面搭建深度融合的一体化“搭投”体系，能够灵活支撑营销大促、日常频道、互动玩法、机酒汽等行业场景、商业化以及小程序等多场景业务需求。

飞猪搭建体系遵循 PMT 模型规范，核心概念包括：

  • Page（页面）：用户可访问的完整页面载体，由页面容器聚合多个业务模块完成运行时渲染，页面容器提供通用基础能力，包括：模板引擎渲染、协议数据的转换与分发、组件依赖与运行时注入、以及埋点与日志等公共服务；

  • Module（模块）：可复用的业务组件单元，封装组件的展示与业务逻辑并定义数据绑定规则，支持独立配置、按需组合编排，快速拼装成不同页面结构；

  • Tag（资源位）：模块内用于承载内容投放的最小单元，用来挂载与管理投放数据，一对多关联具体数据投放配置，并支持个性化规则定投；

图片

飞猪搭建平台

现状与可优化空间

从寄生站点到自研体系的全面回迁，标志着飞猪搭建体系逐渐成熟，但是依赖传统人工选搭投的模式没有得到本质化的改变。下一阶段的重点，是在既有能力之上进一步释放效率红利，围绕“搭建自动化、配置智能化、保障体系化”持续优化：

  • 运营侧提效：页面搭建链路仍有较大提效潜力，当前运营在模块选择、配置理解、跨平台联动配置上投入时间较多，且在日常使用中对咨询支持的需求仍然较旺。与此同时，运营团队更新节奏快，新人从熟悉到独立产出仍需要一定学习成本，存在进一步降低门槛、增强引导与工具化的空间；

  • 设计侧降本增效：页面交付对设计资源的依赖仍然较重，尤其在大促等峰值场景，设计需求集中、节奏紧，容易成为影响整体交付效率的关键路径。日常场景采用计件和众包模式也带来一定的成本与协同开销，因此在设计素材智能生成等方面有进一步优化空间；

  • 产研侧提效：

    答疑提效：尽管已有答疑平台与知识库沉淀，但是在自主排查方面仍可继续增强，高频场景可进一步沉淀标准化诊断与一键解决方案，减少人工介入；

    技术保障提效：大促会场通常需要多轮预演，上线后也需要持续巡检以应对业务调整带来的体验波动。随着平台迭代和营销活动频次提升，可通过自动化预检和巡检等方案持续降人工保障投入；

    研发提效：搭建模块遵循特定规范与约束，新人从上手开发到独立交付仍需一定学习成本；同时由于容器和渲染等核心链路的黑盒特性，仍需平台负责人员提供一定协同支持与保障。可引入 AI Coding 辅助研发，并完善 AI 自助诊断与排障工具，提升代码研发与问题排查效率，降低对平台协同支持的依赖；

AI 化升级的目标

如今正是 AI 蓬勃发展的时代，问答推理、物料生产、流程编排等方案已经成熟，当下的命题应当是思考搭建 + AI 如何深度结合，打造智能化搭建系统，从人工运营向 AI 辅助运营转型，最终实现无人值守自动化运营。为解决选搭投当前的问题正式启动 AI 智能搭投升级专项：深度融合图文素材生产系统、大模型调度编排等能力，将 AI 模式注入招商选品、页面搭建、数据投放等核心系统，构建从需求理解 → 智能编排 → 自动执行的搭投新范式，为未来全域智能运营奠定技术基础。

  • 提升运营配置效率：打通“招选搭投”体系 AI 基础能力，通过推荐模板页面、智能搭建页面、智能助理运维等能力辅助业务快速完成页面搭投，覆盖飞猪页面搭建全场景、提升运营配置效率、减少页面配置时间；

  • 减少设计投入成本：全面推广 AI 文生图和创意合图能力，实现计件众包模式向业务自助产图转型，减少设计费用实现流程提效；

  • 减少人工答疑成本：AI 赋能答疑场景，提升答疑助手拦截率，常见配置问题自动定位并引导解决，缩短问题解决耗时；

  • 提升模块研发效率：模块研发全面拥抱 AI 模式，完善搭建 IDE Rules + MCP 生态，探索 D2C 在搭建模块开发应用场景，提升模块开发效率；

产品结构设计

智能选搭投体系 = AI 搭建 + AI 投放 + AI 素材 + AI 助理 + AI 答疑 + AI Coding

图片

产品结构

技术实现细节

智能搭建

模板检索

为了保证 AI 生产的页面尽可能贴合飞猪营销页面规范且保证转化效率，以及让运营人员有体感预期，我们采用模板预览的形式作为平台入口，基于用户描述推荐场景相似且业务效果较好的模板，用户可进行预览并确认后进入下一步生产流程。此外我们对页面模板进行了分类，不同的页面类型会走到不同的 Agent 完成生产。

图片

模板预览

那么这么多页面模板从哪里来呢，总不能人工维护吧？答案是基于历史页面作为模板即可，毕竟运营人工搭的页面一定是符合预期效果的。通过跑定时任务批量对历史页面进行回溯，再交给多模态 LLM 分析页面内容打标，作为检索关键词进行向量化并落库，检索时进行相似度计算排序即可，实现细节如下：

  • 页面回溯：处理埋点日志找到页面 UV 最大的日期，基于该日期进行页面结构和投放数据 mock 穿越处理，并忽略页面下线重定向逻辑，即可回溯到该页面历史线上投放效果；

  • 页面快照：基于无头浏览器对页面进行截图，生成页面截图快照；

  • 内容打标：基于多模态 LLM 进行页面内容分析，生成页面内容维度标识，包括：页面介绍、关键词、行业标、主题标、质量评分、效率评分等，作为相似度计算的依据；

  • 向量持久化：基于 multimodal-embedding-v1 等多模态向量模型将快照截图和内容标识转换成浮点向量，存到关系型数据库即可（如果数据量较大推荐使用向量数据库）；

  • 检索召回：实时检索时先进行简单的 SQL 检索过滤，再将用户关键词进行向量化，与数据库中的向量字段进行余弦相似度计算，最后排序返回即可；

图片

向量检索链路

页面生产

在页面生成链路，我们梳理了飞猪现存搭建页面类型，大致可分为“搭建页”、“频道页”、“图文页”、“文本页”四类，不同页面类型有着各自的应用场景，需要针对性设计不同的技术方案：

图片

最终生产的页面效果如下，完全达到线上可投放标准：

搭建页

传统搭建页主要通过各行业通用模块搭建而成，不同搭建模块配置项各异且繁琐，新人理解学习成本非常高，即便是运营老司机走完配置流程也需要花不少时间，另外在配置过程中还需要填写大量图片素材依赖设计团队产图，页面搭建过程并不丝滑，一整套页面搭建下来往往需要花费大半天甚至几天时间。

为此我们设计了智能搭建系统，基于用户选择的页面模板复制页面和模块，LLM 推理用户需求总结归纳为页面搭建方案，批量调用智能投放链路（详见后文）完成模块配置，再打通后续排期发布和页面发布工程链路。整套流程只需要 3 min 即可完成，用户描述需求后全程无感，并且支持退出页面后台异步生产。

图片

搭建页面生产效果

整体走大模型编排链路，链路如下：

图片

搭建页生产链路

各流程节点实现细节如下：

图片

图文页

传统搭建模式难以有效支持图文页面场景，难点在于图文页偏设计化、页面结构较复杂，一直以来我们都依赖设计出视觉稿再切图投放，该模式设计计件费用昂贵并且流程较长，对于短平快的营销场景来说是属于历史糟粕亟需革命。我们尝试了以下方案，结果总是差强人意：

图片

我们总是在讨论 AI Coding 如何对程序员提效，那么能否直接绕过 “中间商赚差价”（拿起剪刀剪自己辫子），让运营工作人员直接基于 AI 生产页面呢？答案是可以的，抛开复杂的页面交互逻辑，如果仅是产出静态图文页面，完全可行。

我们设计了一套 Agent 模拟 “前端页面开发” 流程，由 LLM 担任产品、PM、设计、开发等多角色，协同完成图文页面开发任务，最终产物为页面 HTML 代码。再将 HTML 代码渲染至左侧面板提供预览能力，支持文本、图片等 DOM 元素可视化编辑以及选中元素后 AI 微调等能力供运营人员二次调整。页面调整完成后会按页面片段进行图层切分，基于 html2canvas 库将 HTML 片段代码转换成 PNG 图片，导入图片模块并借助 LLM 完成自动圈选热区，最终生成可点击图文页面，或者直接 HTML 代码注入模块实时渲染。

图片

图文页生产效果

整体采用 Manager–Worker 架构设计智能体，拆分分析器、调度器、设计师、工程师等多个角色协同完成长图文生产任务，单 Agent 内部实现完整的 ReAct 范式确保输出最优，使用任务队列模式存储执行进程和上下文，由 AI 自主完成监督调度。在设计 Agent 时需要严格约定出入参数据格式以便调度器准确调度执行，另外还需要设计纠错机制和重试机制保障 Agent 节点在意外抖动时整体链路能够稳定运行。图片页生产链路

图片

核心 Agent 实现细节如下：

图片

智能投放

飞猪搭建体系遵循 PMT 规范，其中资源位数据投放也是搭建链路中重要的一环，我们自建了数据投放系统，支持静态数据源（模块配置）、标准数据源（商品宝贝、酒店日历房）、插件数据源（服务端接口）三类数据类型，涵盖了几乎所有场景的数据内容投放。在搭建 AI 化升级过程中我们对数据投放链路同步进行了升级，衍生出了智能投放链路。智能投放目前支持了图片素材、模块配置、商品选品、二方平台四类场景一句话快速投放，并且支持全类目定投策略智能关联能力，如：时间周期、人群、设备等。我们还对智能投放原子化能力进行封装以支持页面级批量调用，通过 LLM 分析页面主题归纳页面搭建方案，各模块基于搭建方案自主生产投放数据。

智能投放技术链路如下图，首先 LLM 会根据用户描述、页面和模块信息进行推理，生成符合页面主题的模块推荐配置，引导用户快速选择。用户进一步描述后，LLM 针对不同物料类型生成所需的内容素材，包括：配置项（JSON）、文案、图片等，并对素材内容整合转换成模块配置入参，若语义识别到用户有定投诉求会自动进行配置，最后调工程链路完成排期发布和钉钉消息通知。

图片

智能投放链路

智能投放各节点详细方案和效果如下：

智能助理

在页面搭建过程中，运营人员除了搭建模块和数据投放外，通常还需要配置页面容器、插件，以及后续投放过程中的渠道加参和转码转链等操作。这类配置内容比较分散，甚至跨多个平台，对于新人运营人员有一定学习过程。因此我们结合 AI 能力推出了「智能助理」，涵盖：页面修改、转码转链、热点分析等多种能力，支持语义识别用户的诉求自动调用相应的工具，辅助用户提高运营效率。

技术链路上比较简单，通过 LLM 理解用户的操作意图，转换成工具约定的出入参并调用底层平台能力完成对应的操作，功能实现细节如下：

图片

智能素材

此外我们还提供了原子化素材创意生成能力，帮助有匠心的运营人员快速微调和优化页面素材内容：

AI 答疑

飞猪搭建直面一线运营人员，我们没有专业的技术支持人员，答疑工作只能由产研人员“兼职”。每天面对大量的答疑咨询工单，让本就繁忙的研发工作雪上加霜。在 LLM 普及后我们也是第一时间接入答疑场景，提供平台和群答疑两种交互模式，日常常见问题全部交由 AI 处理，技术人员只需处理疑难杂症即可。将答疑工作量减至原来的 1/6，拦截率达到 91.4%。

AI 答疑技术方案比较简单，纯调 LLM 没什么好说的，核心需要丰富的知识库来提高答疑准确率。我们扒了近几年来飞猪搭建相关的技术 & 产品文档，根据常见问题进行分类，修订为搭投提示知识库。有了知识库还需要对 RAG 进行优化，主要通过文档分段打标实现，我们通过三方接口召回了集团答疑工具近年来所有人工答疑记录，作为语料支持对现有知识库进行打标，文档缺失部分将该 Case 作为 FAQ 进行补充。基于存量知识库答疑总是具有局限性，随着飞猪搭建体系不断地迭代发展，所以还需要让 AI 自我学习最新知识，我们将 AI 对话和人工答疑对话落库，跑定时任务召回对话并进行向量化落库。后续实时检索时历史对话也会作为知识库的一部分。

图片

AI 答疑 RAG 链路

AI Coding

搭建模块开发：

在 AI Coding 方面我们没有选择造 “重复且低质量的轮子”，而是在 Qoder、Cursor 等成熟 IDE 基础上，通过修订 Rules 方式增强 AI 编码能力。我们编写了 8 类搭建模块开发特殊规则，并接入飞猪代码仓库知识库、Ftech、Figma 等 MCP 服务实现组件库代码片段召回、PRD 理解、D2C 视觉稿转码等能力。有助于模块开发提效，对于新人入门非常友好，整体编码提效 80%+，实测模块功能实现和业务逻辑近乎完美只需要微调样式，规则目录如下：

图片

schema 编写助手

飞猪搭建模块配置表单遵循类 JSON Schema 规范，我们开发了 Schema 编写助手，辅助开发快速生成表单配置，支持 mock 数据和 schema 配置互转，减少新人学习成本、提高模块开发效率、减少研发答疑成本。

图片

schema 助手

总    结

通过对选品、搭建、投放、素材等平台全面整合，我们对飞猪搭建体系进行全面的 AI 化升级，面向运营、设计、产品、研发等全角色构建了一体化的智能搭建平台。在产品形态上，智能搭建体系已经形成智能创建、智能投放、智能素材、智能助理、AI 答疑、AI Coding 六大支柱，为未来全域智能运营奠定基础。

开发一套 AI 体系远比想象中困难，它不像写代码那样有明确、可复现的确定性结果，几乎每天都在对着“人工智障” 挠头。最棘手的问题之一就是大模型的幻觉：自始至终都在困扰着我们，哪怕只是一个很细微的偏差，在多轮任务的链式执行中也会被不断放大，最终产出就可能变得不可用。在不讨论训练 / 微调模型这类高阶手段的前提下，我认为提升 Agent 准确率无外乎以下几种手段：

  • 架构设计：Agent 开发需要有 “把不确定性关进笼子” 的架构设计，实践中可以结合具体场景参考网上的经典设计案例，把任务拆解为可控步骤并引入观测、校验、重试、回滚等机制，将大模型的自由生成约束在可验证和纠偏的闭环中以降低幻觉；

  • 工程实现：多数场景下，工程代码在执行性能与稳定性上更具优势，对于链路中规则清晰、可验证的环节，优先用工程代码实现，能有效降低不确定性；

  • Prompt 调优：Prompt 是一门学问，调好了能让大模型稳定地发挥能力，总结来说就是结构化、多约束、评估标准、分层书写。网上有许多教程和黑科技，不妨先快速学习一轮，实践中灵活尝试运用，磨刀不误砍柴工；

  • 上下文管理：对于多 Agent 体系中，上下文管理尤为重要，一股脑往里塞必然导致 “上下文污染” 越聊越偏。因此需要设计合理的 memory 结构，为上下文标注来源和边界，只使用可信内容、临时内容及时销毁；

  • 模型升级：终极大招，可能你调了半天发现还没换个模型见效快，那就等待 AI 科技的发展进步吧。但是别忘了，基建架构是不可逆的，设计好了就是锦上添花，设计烂了就是雪上加霜；

展望

下一阶段的关键在于把 AI 搭建从 “提效 Copilot” 升级为 “可控、可评估、可闭环的生产系统”，通过约束式架构、自动诊断调优等手段不断提升 AI 的自我思考能力并减少幻觉，推广到日常活动、频道运营、大促活动等方方面面，支撑飞猪更高频、更复杂、多场景的全域智能运营。以下是建设过程中的一些思考以及后续规划：

只好自己做了

最主要还是交互: 用户直接把噪音很多的灵感写到 obsidian/tg/qq 等等 主要是需要顺手就发的交互 可以关键词限制

同步此灵感到 git 仓库

定时/检测到 git 仓库新增条目

自动分析新增条目 并先拆解任务 功能特性 验收标准邮件发送给用户

用户看到邮件/tg 消息可以补充或修改思路 直到终版文档批准

支持并行

llm 可以多开几个沙盒 yolo 模式 (可以歇斯底里 一直打磨 直到过验收或者用户检测)

返回最终项目到仓库并提醒用户查收

:反正额度用不完 赶紧造

cmd：node -v
re： 'node' 不是内部或外部命令，也不是可运行的程序或批处理文件。

切换到 ide 的终端有时候又有了，现在挺烦恼的，有可能 cmd 有 ide 没有 有时候 ide 有 cmd 没有 有时候两边都没有只能重启大法，重启大法也有时候也可能还会出现这情况，求助 v 友大神

一、确定 SSL 证书类型

域名验证（DV）证书：仅验证域名所有权，流程简单、速度快，适合个人博客或小型网站。

组织验证（OV）证书：除域名所有权外，还验证组织真实性，安全性更高，适用于中小型企业网站。

扩展验证（EV）证书：提供最高级别的验证，需验证组织详细信息及法律地位，常用于金融、电商等对安全要求极高的网站。

二、挑选证书颁发机构（CA）

选择知名且受信任的 CA 至关重要。
您可以根据预算、证书类型需求及 CA 的信誉度进行选择。

免费SSL证书申请入口

打开JoySSL官网，注册账号，填写注册码230970获取免费证书。

三、准备申请信息

域名信息：明确主域名及需保护的子域名。

组织信息（OV 和 EV 证书需要）：包括组织法律注册名称、地址、电话号码等。

邮箱地址：用于接收验证邮件及证书相关通知。

四、域名所有权验证

证书颁发机构会要求您证明对域名的所有权，常见验证方式有：

文件验证：将特定验证文件上传至网站服务器指定目录。

DNS 验证：在域名的 DNS 配置中添加指定的 TXT 记录。

五、提交申请并等待审核

将准备好的申请信息及验证信息提交给选定的 CA，CA 会对申请进行审核。审核时间因证书类型和 CA 不同而异，DV 证书通常较快，几分钟到几小时不等；OV 和 EV 证书因涉及组织验证，可能需要 1 - 3 个工作日。​

六、下载并安装证书

审核通过后，CA 会提供 SSL 证书文件。根据网站使用的服务器类型（如 Apache、Nginx、IIS 等），按照相应的安装指南将证书安装到服务器上。

七、验证证书是否生效

安装完成后，通过浏览器访问网站，查看地址栏是否显示安全锁标志，且网址以 “https://” 开头。也可使用在线 SSL 证书检测工具，进一步确认证书安装是否正确及网站的安全性。

首先声明这个不是推广帖，也不是引战贴，标题不是噱头

帖子省流版：

  • 对这段时间做的事情做了一些总结
  • 大家提痛点需求，一起做一款让大家觉得爽的开源 AI 产品，形式可能为 build in pulic
  • 拉了个微信群，分享开发 Agent 的经验技巧和坑

缘起

我是一个重度 vim 用户，一开始（ 25 年中旬）用的是 github 官方 copilot.vim （原因是因为开源了几个上千 star 的项目(非凡尔赛)，copilot pro 一开始对这些开发者是免费的，当然现在不免费了），但是自动补全很慢，非常影响效率。

然后就找有关的替代品，尝试了很多，比如 chatgpt.nvim ，codecompanion.nvim 等，但是都不太满意。后来也尝试了 Cursor 和 Claude Code ，但是也有各样问题，一是不太习惯 IDE ，二是还是需要人大量的时间去交互，实际体验下来开发效率并没有提升多少（当然现在要好不少）。后来一想为什么就不能自己写一个呢？于是开始了折腾（造轮子）之路。

过程

一开始是古法编程用 python 快速写了个自动 fix ut 的命令行，还在团队内部做了分享，但是很多时候这个 cli 工作的并不好，然后就想办法优化。

看了很多资料，差不多 100+篇关于 AI 的论文（在 alphaxiv 的帮助下，挑重点 paper 细读。主题包括框架、Agent/Multi-Agent 、注意力、记忆、规划等等），其中一篇给我比较多启发的是 Alita 这篇论文 https://arxiv.org/abs/2505.20286 。当时 Context Engineering 这个概念刚火，还花了好几天看这个 https://github.com/davidkimai/Context-Engineering （后来证明这个项目对我来说基本没用）。然后设计出一套方案，目标是做一个让自己用起来爽的 Agent ，具体来说是：

  • 快（干活快）
  • 狠（彻底解决问题）
  • 准（交付质量高）
  • 美（产品要有设计品味）

充分发挥不同大模型的能力，不局限于单一模型。下面是一开始的架构设计：

集中精力花了差不多 3 个月时间实现，中间还重构了一版（因为效果没有达到预期），核心逻辑全部手写，其他部分前期使用了 Cursor 来帮助写 TUI ，后面就全是用产品自己开发自己了。

产品

产品形态是 Desktop + Tui ，可以编程、Research 、干杂活等，可以简单理解为 Claude Code + Cowork 。

  • 桌面版

对应视频在这

  • TUI

对应视频在这

问题

上个月底这个月初找了几个朋友内测了下，大家给了一些建议。

这两天也开源了，在 HN 和 v2 也分别发了一个帖子简单介绍了下，反馈都比较平平，发的帖子很快沉下去了。我自己反思了下，可能是自己做的东西确实不够好，也可能是大家没关注到，或者大家关注到了但是不感兴趣。

所以想看下大家真实的想法，先抛个几个问题：

  • 现在大家对此类工具和产品怎么看？是产品引不起自己的兴趣吗？
  • 除了 claude code/codex/cursor/opencode 等，还用其他什么比较好的产品吗？比如豆包
  • 现有的工具已经能很好的解决自己的问题了吗？还有其他的痛点吗？

最后

大家需要的话，我可以免费帮实现大家实现有关功能，未来产品的形态由大家来定义。

另外我拉了个微信群，准备把开发 Agent 的时候一些经验技巧和坑分享一下，同时也方便大家交流有关话题，有感兴趣的可以评论区留言我拉一下大家进群。

受够了快餐式的在线音乐和各种难用的播放器，果断自己做一个符合自己需求的。

新手前后搞了快大半年，本地的功能基本完善。

主要支持音乐标签编辑，能让收藏的歌曲更完善，以及很多人性化功能。

有什么更好的建议改进欢迎留言，目前在考虑远程播放功能。

手机效果预览： https://www.bilibili.com/video/BV18GrQBhET6

AppStore： https://apps.apple.com/cn/app/%E6%B3%A0%E7%84%B6/id6755538782

预览

我自己用的图床是简单图床，设计理念就是极简，没有 SSO 功能，今天上午自己一边问一遍改，终于做好了。
image
增加按钮
image
跳转到统一登录
image
完成登录

上次改造的是 alist，现在可以一号通行，网盘、图床都有了，方便多了。

IDE 为 GOLand

根目录导入 strings 、sync 、time 正常：
SnowShot_2025-12-22_10-09-22.png

在 web 目录就不行了：
SnowShot_2025-12-22_10-09-49.png

已经快被折磨疯了，.idea 删了也不行，缓存清理了也不行，go 和 goland 重装了也不行。

go.mod 代码:

module fastports

go 1.25.5

智能体（Agent）是一种能够围绕目标持续运行、并完成任务的 AI 执行系统。
它不以一次输出为结束，而以任务完成为结果。
智能体代表了 AI 从“回答问题”走向“执行工作”的系统化形态。

智能体是什么？

智能体（Agent）是一种……的 AI 执行系统，能够在接收到目标后，自动拆解任务、制定计划并调用工具完成执行。
它以目标为核心，而不是以对话为核心。
智能体的运行方式是持续循环，而不是一次响应。

一个完整的智能体通常由模型、规划模块、记忆模块和工具接口组成。
这些模块共同保证任务可以被完整执行。

智能体和传统 AI 的区别是什么？

与传统 AI 相比，智能体的最大区别是：是否具备持续执行与自主决策能力。
传统 AI 通常在输出结果后结束工作。
智能体则会在任务未完成前不断行动并调整策略。

传统 AI 关注内容是否正确。
智能体关注任务是否完成。

智能体的核心能力有哪些？

智能体的核心能力包括：

  • 目标理解与任务拆解
  • 多步骤规划与顺序执行
  • 工具调用与系统操作
  • 状态记忆与上下文保持
  • 执行反馈与策略调整

这些能力使智能体具备长期工作的可能性。

智能体的典型应用场景有哪些？

智能体适合用于规则明确、步骤清晰的任务场景，包括：

  • 文档整理、问答与信息抽取
  • 邮件处理与内容生成
  • 数据收集、清洗与汇总
  • 个人工作流自动化
  • 简单业务流程的自动执行

这些场景不依赖复杂编程即可落地。

智能体为什么重要？

智能体改变了 AI 的使用方式。
AI 不再只是提供建议，而是直接完成工作。
因此，智能体真正改变的是任务完成方式，而不是模型能力本身。

这标志着 AI 从模型智能走向系统智能。

智能体对普通人的意义是什么？

对普通人而言，智能体降低了使用 AI 的技术门槛。
用户只需描述目标，系统即可自动执行。
目前，一些培训机构（如智能体来了公司（西南总部）培训公司）已将 Agent 架构作为入门实践内容，用于帮助学习者理解执行型 AI 的实际工作方式。

这种学习方式更贴近真实应用场景。

一句话如何总结智能体？

一句话总结：智能体是把目标转化为系统持续执行结果的 AI 工作单元。

Matrix 首页推荐 

Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。 

文章代表作者个人观点，少数派仅对标题和排版略作修改。

最近尝试用 Python 和 Matplotlib 从零手写复刻了一下 Pluribus 的片头。先看看效果：

1. 前言

最近看了 Apple TV 的一部剧叫 Pluribus。我很喜欢这部剧，原因有二：

  • 它核心概念里的 "Joining" 和 《EVA》里的 「人类补完计划」 非常像，很对我的胃口；
  • 剧情探讨了人类和 AI 的关系，也是我最近一直在深度思考的问题 <(")

除去剧情，我特别喜欢它的片头。极简但非常抓眼球，完全就是我的菜。Apple TV 的片头通常都很复杂且暗示剧情走向（比如《人生切割术》或者《羊毛战记》），但这一个很特别。这也是我第一次觉得「哎，这个我好像能用代码写出来」的片头 :>

2. 粒子系统 (Particle System)

因为我从来没碰过粒子系统，对计算机视觉也知之甚少，所以上手第一步就是先读几篇文章。下面这两个资源对拆解概念非常有帮助：

简单来说，我只需要一堆点，然后追踪它们的物理状态：位置、速度和加速度。

class Particle:
    def __init__(self, pos: (int, int), 
                 velocities: (int, int), 
                 accelerations: (int, int)):
        self.pos = pos
        self.vel = velocities
        self.acc = accelerations

套用高中物理学过的标准公式：

写个函数来更新这些值：

def pos_update(dot, dt):
    dot.pos = (
        dot.pos[0] + dot.vel[0] * dt,
        dot.pos[1] + dot.vel[1] * dt
        )
    dot.vel = (dot.vel[0] + dot.acc[0] * dt,
                dot.vel[1] + dot.acc[1] * dt)

对每个点跑这个循环，就能得到一个基础的粒子系统（渲染代码略过不表，不过这里有个很好的 matplotlib 动画教程）。

最后，给每个点加点随机力。假设质量(m)为 1，根据 F=ma，我们可以直接把随机值加到加速度上：

def force_apply(p: Particle):
    p.acc = (
        p.acc[0] + random.randint(-2, 2), 
        p.acc[1] + random.randint(-2, 2)
        )

def dots_update(dots, dt):
    for dot in dots:
        pos_update(dot, dt)
        force_apply(dot)
    return

初始化网格里的点之后，大概长这样：

3. 背景点 (Background-dots)

把片头看了五遍以后，我发现里面的点可以分为三类，各个击破：

  • 背景点 (Background-dots)
  • 圆圈点 (Circle-dots)
  • 文字点 (Text-dots)

对于背景点，简单的随机运动看着不自然。如果你仔细看（现在是第六遍了 :D），会发现它们之间是有交互的。基本上就是太近了会推开，太远了会拉近。我发现 Lennard-Jones 势能完美描述了这个行为：

简单说就是距离太近会排斥，距离远了（但在范围内）会吸引。就像下图这个曲线。（我是从这个博客学来的）。

实现起来也很简单，遍历每一对点应用这个力就行，复杂度是 O(n^2)。

def lj_force(p1, p2):
    dx = p1.pos[0] - p2.pos[0]
    dy = p1.pos[1] - p2.pos[1]
    dis = (dx**2 + dy**2) ** 0.5

    dx_dir = dx / dis
    dy_dir = dy / dis

    u = min(10, 4 * EPI * ((SIGMA/dis)**12 - (SIGMA/dis)**6))

    dx_acc = u * dx_dir / 1
    dy_acc = u * dy_dir / 1

    p1.acc = (p1.acc[0]+dx_acc, p1.acc[1]+dy_acc)
    p2.acc = (p2.acc[0]-dx_acc, p2.acc[1]-dy_acc)

加上 LJ 势能后的效果如下。能明显看到点之间相互作用产生的复杂运动。

4. 圆圈点 (Circle-dots)

加圆圈点之前，先快速复习一下如何在粒子系统中定义方向和距离。（记得的同学可以跳过 :O）

基本上给定一个角度 θ∈[0,2π) 我们可以得到方向的单位向量 ​dir_x=cos(θ) dir_y=sin(θ)​。给定两个点，我们可以得到从 p1​ 到 p2​ 的方向：

要得到方向（单位向量），我们用差值除以距离：

加圆圈点很容易。给个初始速度，按 2π（360度）均匀分布方向就行。

def add_wave(dots):
    for i in range(WAVE_DOTS_NUM):
        angle = 2 * math.pi * i / WAVE_DOTS_NUM
        
        pos = (WAVE_ORIGIN[0] + math.cos(angle)*5, 
            WAVE_ORIGIN[1] + math.sin(angle)*5)
        
        vx = WAVE_SPEED * math.cos(angle)
        vy = WAVE_SPEED * math.sin(angle)
            
        dots.append(Particle(pos, velocities=(vx, vy)))
  • 碰撞问题： 但这里有个坑。因为我们加了 LJ 力，背景点会和圆圈点互怼。圆圈扩大的时候，撞到背景点会被推歪，形状就散了。
  • 解决方案： 我的解法简单粗暴：给 Particle 类加个 mass（质量）属性。让圆圈点比背景点重得多，它们惯性就大，不容易被推跑。

更新物理计算遵循牛顿第二定律 (a=F/m)。基本就是更新速度的时候，把累计的力（加速度）除以质量：

def pos_update(dot, dt):
    dot.pos = (
        dot.pos[0] + dot.vel[0] * dt,
        dot.pos[1] + dot.vel[1] * dt
        )
    dot.vel = (
        dot.vel[0] + dot.acc[0] * dt / dot.mass,
        dot.vel[1] + dot.acc[1] * dt / dot.mass
        )

对比一下（左：无质量，右：有质量）。

加了质量以后看着舒服多了吧？能明显看到圆圈点把背景点推开，自己还能保持队形。

5. 文字点 (Text-dots)

用点渲染文字不难。找个字体（我用的 Arial）画出来，然后提取像素位置就行。

def get_text_draw(text = TEXT, font_path = FONT_PATH):
    mask_img = Image.new("L", (WIDTH, LENGTH), 0)
    draw = ImageDraw.Draw(mask_img)
    font = ImageFont.truetype(font_path, 35)

    bbox = draw.textbbox((0, 0), text, font=font)
    text_w, text_h = bbox[2] - bbox[0], bbox[3] - bbox[1]
    draw.text(((WIDTH - text_w) // 2, (LENGTH - text_h) // 2 - 5), text, fill=255, font=font)
    y_coords, x_coords = np.where(np.array(mask_img)[::-1] > 128)
    return x_coords, y_coords

难点在于做那个「指纹」图案。仔细看原片，它像个波浪，稍微有点不规则。为了简单，我用 sine wave 模拟：

基本上就是根据距离中心的远近推拉这些点。调整频率能搞出不同的环形图案。下图是 freq={1,4,7} 的效果。

def set_fingerprint(x, y, freq = RADIAL_FREQ, strengh = RADIAL_STRENGTH):
    dx = x_coords - RADIAL_ORIGIN[0]
    dy = y_coords - RADIAL_ORIGIN[1]

    dist = np.sqrt(dx**2 + dy**2)
    angle = np.arctan2(dy, dx)

    push = np.sin(dist * freq) * strengh

    x_new = x_coords + (np.cos(angle) * push)
    y_new = y_coords + (np.sin(angle) * push)
    return x_new, y_new

如下是从点 P(25,42) 发起正弦波应用到文字的效果。

其实调这个波的参数花了我好久。试了各种组合，最后选了个看着最舒服的。^_^

把所有东西合在一起，就有了第一版片头！8)

6. 性能优化 (Performance Optimization)

先停一下。目前渲染60帧要跑6分钟。感觉我在浪费生命等它跑完 :( 是时候做点优化了。

6.1 空间哈希 (Spatial Hashing)

前面说了，瓶颈在物理交互计算，复杂度 O(n2)。加上文字点和不断生成的圆圈点，数量轻松上千，意味着每帧要做 10^6 次距离检测。

我的解法是用空间哈希（分桶），把空间划成网格，只计算相邻网格里粒子的 LJ 力。灵感来自第 3 节的公式：距离 ≥3σ 时势能几乎归零。

我用哈希表记录每个点属于哪个格子：

def _bin_coords(pos):
    return int(pos[0]) // BIN_SIZE, int(pos[1]) // BIN_SIZE

def _build_bins(dots):
    bins = {}
    for idx, p in enumerate(dots):
        bx, by = _bin_coords(p.pos)
        if 0 <= bx < BIN_XNUM and 0 <= by < BIN_YNUM:
            bins.setdefault((bx, by), []).append(idx)
    return bins

这一改，速度提升了 5 倍，渲染时间从 6 分 10 秒降到了 1 分 06 秒。

（虽然我知道用树结构——类似二叉索引树——动态维护位置能把复杂度降到 O(nlogn)，毕竟最近在刷 LeetCode。但网格法目前够用了。）

6.2 生命周期管理

另一个优化是控制点的生命周期。圆圈点飞出屏幕（「越界」）后就不用算了。我加了个定期清理。这对减少内存占用很有效，之前内存都飙到 10GB 了。

def prune_dots(dots, circles, margin=50):
    alive_dots = []
    alive_circles = []

    for dot, circle in zip(dots, circles):
        x, y = dot.pos
        if -margin < x < WIDTH + margin and -margin < y < LENGTH + margin:
            alive_dots.append(dot)
            alive_circles.append(circle)
        else:
            circle.remove()

    dots[:] = alive_dots
    circles[:] = alive_circles

我很确定用内存池（链表+哈希表）能做到 O(1) 的插入删除，但对于这个项目有点杀鸡用牛刀了 :/

7. 视觉打磨 (Visual Optimization)

接下来打磨一下视觉效果。

7.1 文字形状

第一个问题是文字时间长了会「糊」掉或者散架。因为点挤得太紧，LJ 势能把它们推开了，导致我们（搞了半天的）指纹纹理丢了。

解决办法很简单：加个锚点力 (Anchor Force)。就像个弹簧，点飘太远了就把它拽回原位。我还加了点阻尼（摩擦力）防止它震荡个没完。

def anchor_force(p):
    dx = p.anchor[0] - p.pos[0]
    dy = p.anchor[1] - p.pos[1]
    dis = (dx**2 + dy**2) ** 0.5
    dx_dir = dx / dis
    dy_dir = dy / dis

    f = dis * ANCHOR_STRENGH

    damping_fx = -p.vel[0] * DAMPING
    damping_fy = -p.vel[1] * DAMPING

    p.acc = (
        p.acc[0] + (f * dx_dir + damping_fx) * random.randrange(5, 10) / 10, 
        p.acc[1] + (f * dy_dir + damping_fy) * random.randrange(5, 10) / 10
        )

7.2 呼吸与循环

另一个改进是给背景点加个「呼吸」效果，大小有节奏地缩放。给每个粒子加个相位属性，用正弦波更新就行。

最后，为了防止背景点飞出屏幕，我做了个屏幕循环 (Screen wrapping)。点从右边出去，就从左边回来。

def pos_update(dot, dt):
    dot.pos = (
        dot.pos[0] + dot.vel[0] * dt,
        dot.pos[1] + dot.vel[1] * dt
    )
    dot.vel = (
        dot.vel[0] + dot.acc[0] * dt / dot.mass,
        dot.vel[1] + dot.acc[1] * dt / dot.mass
    )
    dot.acc = (0, 0)

    dot.phase = (dot.phase + PHASE_INCREMENT) % (2 * math.pi)
    sine_wave = (math.sin(dot.phase) + 1) / 2

    if dot.type == 0:
        ## Keep background dots
        dot.vel = (dot.vel[0] * DECAY_RATIO, dot.vel[1] * DECAY_RATIO)
        dot.pos = (dot.pos[0] % WIDTH, dot.pos[1] % LENGTH)
        ## Change their size periodically
        dot.radius = 0.5 * (0.4 + 0.6 * sine_wave)
    else:
        dot.radius = 0.5 * (0.9 + 0.1 * sine_wave)

效果图解：

当然你也可以把文字换成任何你想要的：

8. 总结

这其实是我第一次尝试写粒子系统。本来计划在剧终（圣诞节）前搞定，但我高估了自己旅行时的精力和专注度。说实话，理解原理并实现它确实花了我不少时间。

相比之下，我看很多人用 Gemini 生成那种酷炫的 web 端 3D 粒子系统。跟那些比，我这个可能显得简陋甚至有点「丑」。但对我来说，从零构建的这个过程要更 enjoyable，虽然这肯定不是最高效的方法。最后，我觉得这种感觉大概也就是《Pluribus》想表达的东西吧。 :V

    本文面向种子轮、A 轮的产品/技术管理者，拆解早期工程团队最常见的管理反模式，重点是少花力气「管人」，把精力用在产品、用户和招聘上。

    很多创始人都会经历类似的一天：

    产品刚有一点起色，团队有 6、7 个工程师，大家各自忙着写代码。你刷了一圈飞书、钉钉、Jira，看到没人「熬夜上线」、「周末加班」，心里开始打鼓：

    我是不是该「管一管」了？

    要不要设周末站会？

    要不要赶紧招个工程经理？

    在早期，绝大多数你以为的「管理问题」，本质上都不是管理问题，而是产品和招聘问题。

    对种子轮、A 轮阶段的产品/技术管理者来说，最值得警惕的，是那些听上去很「负责」、实际上却严重分散注意力的管理动作。

    下面，我们把这些反模式拆开讲清楚。

    一、问题：为什么你总觉得「需要管理」？

    在早期工程团队里，创始人最常见的一种焦虑是：

    • 工程师好像没那么「拼」，没人自发熬夜
    • 项目进展不够「可见」，看不到随时可展示的进度条
    • 组织结构还很扁平，感觉「不像一家真正的公司」

    这时，很容易滑向一个直觉：

    我需要更多的管理：更多会议、更多流程、更多角色。

    但如果你还在找产品/市场匹配点（PMF），事情恰好相反：

    • 你最需要的是把所有可用的精力，放到产品和用户身上
    • 任何与此无关、但会占用创始人和工程师时间的管理创新，都是巨大的机会成本

    所以，真正的问题不是「缺不缺管理」，而是：

    在这个阶段，哪些「看上去像管理」、但其实只会拖慢团队的动作，应该被坚决避免？

    二、误区：三种常见的管理反模式

    误区一：试图靠「打鸡血」激励工程师

    很多创始人一看到团队不够「燃」，就开始想办法「激励」工程师：

    • 鼓励甚至默认 996 式的长时间工作文化
    • 把原本可以异步的事情，塞进周末或晚上的会议
    • 各种形式的微观管理：频繁要进度、要截图、要「证明你很努力」

    问题在于，优秀的工程师，要么一开始就自带动力，要么很快会被这种文化劝退。

    记住这个重要结论：

    动力是招聘进来的，不是管理出来的。

    当你花大量心思去「点燃」团队时，往往说明有两个地方出了问题：

    1. 招聘时，没有足够重视候选人的内在驱动力、韧性和好奇心
    2. 环境没有给这些本来就很自驱的人，足够的空间和意义感

    可执行建议： 把「是否自驱」当作硬标准写进招聘评分表，而不是事后靠文化口号来补课。

    误区二：过早引入管理者和头衔

    另一个常见做法是：一到十几个人，就开始「像大公司一样」搭管理架构：

    • 给团队划小组、设组长、甚至招全职工程经理
    • 安排定期的一对一、绩效评估、晋升路径设计
    • 为了「有条不紊」，大规模引入流程、里程碑、报表

    听上去都很负责任，但在早期，这往往意味着：

    • 你还在搞清楚到底该做什么产品，却已经请来一个「负责把事做对」的人
    • 管理者不得不创造各种「管理工作」 —— 安排会议、管理 Jira、评估绩效，以证明自己有价值
    • 很难判断问题出在产品、在工程师，还是在管理者身上

    下面给出一个简单的分阶段视角：

    • 5–6 人（含技术创始人）：阶段太早，不需要管理者。创始人主要做两件事：招人和（在极端情况下）开人，其余让团队自组织。
    • 10–15 人、2–3 个子团队：所有工程师依然可以向一个人汇报（通常是 CTO），这是打磨工程文化的关键窗口期。
    • 20–50 人：这时才是引入更多组织架构和管理层的阶段，此时团队规模扩大带来了混乱，开始真实限制产出。

    可执行建议： 在 20 人之前，慎重对待任何「全职只做管理、不写代码」的角色设计。

    误区三：照抄大厂的「先进管理实践」

    还有一种更隐蔽的反模式，是把大厂的管理实践，当成早期团队的模板：

    • 全套 Scrum 仪式：每日站会、迭代回顾、燃尽图
    • 复杂的绩效体系、胜任力模型、晋升委员会
    • 花哨的反馈机制、同行评审流程

    问题不在于这些方法本身，而在于阶段错配：

    大厂管理的是一台已经运转起来的机器；

    你在早期时，还在造发动机。

    早期团队的管理栈，应该像「Node + Postgres」—— 普通、稳妥、被无数人试过，不会成为公司失败的原因。

    换句话说，在管理这件事上，越无聊越好。

    可执行建议： 每当你想引入一个「很新」「很酷」的管理做法时，先问一句：如果不用，我们真的做不出产品吗？

    三、方法：少做管理，多做这几件事

    如果说上面三种是「别做」，那早期工程团队到底该「做什么」？有一个很实用的思路：

    用「不情愿的管理者」心态，去做那一小撮真正必要的事。
    1. 把精力放在「招对人」上
    • 招聘时，刻意寻找那些有真正动力的人：主动加班、愿意为难题投入超预期精力，但不是被逼出来的
    • 关注候选人经历里的「挫折时刻」 —— 遇到过什么困难？怎么扛过来的？
    • 是否有持续的好奇心：愿意聊某个技术、某个兴趣时会「眼睛发光」

    一旦招到这样的人，不需要做什么管理，更多的是别把他们的热情消耗在无意义的流程上。

    2. 用最轻量的方式对齐方向
    • 状态更新尽量异步完成：文字周报、短更新，而不是天天站会
    • 对需求和优先级，用几篇共享文档就够了，没必要一上来就搭一整套系统
    • 把「为什么做这件事」讲得非常清楚，比「怎么做、按什么节奏做」重要得多

    当方向清晰、上下文透明时，优秀工程师自然会自己填补细节。

    3. 保护工程师的注意力，而不是占用
    • 钉钉、飞书是刚需，但要警惕演变成「注意力黑洞」
    • 少 @ 全员、少搞临时化同步会议，多用异步文档和评论
    • 鼓励大块、不被打断的深度工作时间，而不是随时在线的「响应速度」

    真正的「高效」，往往体现在有多少时间被保护下来，而不是被填满。

    4. 让一对一和反馈「有事可谈」
    • 不做为了「保持关系」而开、却没有明确议题的例行 1:1
    • 更鼓励基于具体问题、具体项目的临时对话
    • 当有人真的有卡点、困惑或情绪时，再打开深入的沟通空间

    这类关系，是在一起解决问题的过程中自然生长出来的，而不是靠日历上固定的时间段培养出来的。

    可执行建议： 让「时间块」成为支撑深度工作的精简模块，而不是塞满整周日历的主角。

    四、清单：给早期产品/技术管理者的对照表

    如果你正在带一个 5–20 人的工程团队，可以用这份清单自查：

    [ ] 最近一个月花在招人和面试上的时间，是否明显多于花在设计新管理流程上的时间？  
[ ] 是否在试图用流程和制度，去「拯救」一个本就不合适的招聘决策？  
[ ] 团队大部分状态更新，是否可以通过异步文档就能完成？  
[ ] 团队会议是否都有清晰议程和产出，而不是为了「看起来在管理」？  
[ ] 工程师是否能直接接触完整的业务上下文（用户反馈、营收数据、产品决策），而不是只拿到被筛选过的片段信息？  
[ ] 你是否依然亲自参与关键的产品和技术决策，而不是过早把这些权力和判断交给「管理层」？  
[ ] 当你觉得「需要更多管理」时，是否先问过自己：是不是该先多去几次用户访谈？

    可执行建议： 每季度用这份清单做一次复盘，把那些「想不到不做也没关系」的管理动作，都列入精简候选。

    五、总结：当你觉得需要「管理」，往往应该回到产品

    在种子轮、A 轮阶段，如果你觉得自己有很严重的「工程管理问题」，九成的正确解法是暂时什么都不做，先去找用户、做产品、招对人。

    早期工程团队最重要的管理决策，往往只有三件：

    1. 招谁进来 —— 是否真的自驱、好奇、愿意为问题多走一步
    2. 给他们怎样的环境 —— 信息是否透明、目标是否清晰、是否能安心做事
    3. 在什么时刻引入管理 —— 坚持「能用 Node + Postgres，就别造新数据库」式的朴素标准

    如果说传统管理在乎的是「把机器调得更顺」，

    那早期管理更像是：守住几条简单的边界，让真正重要的工作自己长出来。

    当你下次忍不住想「多管一点」时，不妨先问自己：

    我现在做的这件事，真的会让我们更快找到产品/市场匹配吗？

    如果答案是否定的，那也许最好的管理动作，就是先按下暂停键。

    Hi，我是俞凡，一名兼具技术深度与管理视野的技术管理者。曾就职于 Motorola，现任职于 Mavenir，多年带领技术团队，聚焦后端架构与云原生，持续关注 AI 等前沿方向，也关注人的成长，笃信持续学习的力量。在这里，我会分享技术实践与思考。欢迎关注公众号「DeepNoMind」，星标不迷路。也欢迎访问独立站 www.DeepNoMind.com，一起交流成长。

    本文由mdnice多平台发布

    1）.so mmap计算工具内存翻倍现象
    2）iOS报告中的Low Memory是如何被促发的

    这是第461篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。

    UWA社区主页：community.uwa4d.com
    UWA QQ群：793972859

    From 问答社区

    Q：结合UWA DAY分享的.so mmap内存分析流程，我发现在我们项目中libil2cpp.so有个奇怪的现象，想要问问大家是否知道是怎么一回事：

    这里列出来libil2cpp.so占据了4段内存，其中第一段：770e779000-771c606000，和第二段开始到第四段结束地址（78bfac9000-78cd956000）的内存容量完全一致。而且，命令结果显示它们映射到的文件以及offset也都完全一致。我高度怀疑这两段内存的内容也是一致的，很有可能是两段虚拟内存映射到同一段物理内存。但是这个情况只有libil2cpp符合，libunity并不符合。包括我用后来我们打的包，执行同样命令，分析结果，还是符合这个现象。这是否意味着libil2cpp的内存占用实际上是上面统计值的一半？

    补充一点：我用我们自己打的包，查看proc/pid/maps，结合readelf命令，发现后面三个段已经映射了所有libil2cpp中的LOAD段了。

    附：包含文中提到的“.so mmap内存分析流程”的课程：
    Unity移动游戏性能优化全解析与小游戏转化的实战经验

    A：试了几个不同的包，有的确实会出现第一段等于后面几段之和的情况：

    也有几段互不相同没有加和关系的情况。这两种包的运行时数据和拆包得到的so硬盘占用大小也都基本对得上：

    这是因为，UWA DAY PPT中用来计算内存的Python代码会粗暴地计算所有地址的插值并无脑求和，如下图：

    但在出现”第一段等于后面几段之和的情况”的包中，前两段的Offset都是偏移0，此时不能强行求和。可以考虑根据这种规律调整代码或人为重新算一下就对了：

    欢迎大家转至社区交流：
    https://answer.uwa4d.com/question/696ddb25244ce21ce9ec096f

    From UWA AI 问答

    Q：iOS平台上[UIApplicationDelegate applicationDid ReceiveMemoryWarning]调用只在1.8GB左右频繁触发，内存更高以后反而触发率降低了，是什么原因？

    A：该现象符合iOS内存管理机制的分层压力响应策略，根本原因在于：applicationDidReceiveMemoryWarning并非在内存使用达到绝对阈值时触发，而是由系统基于当前可用内存余量、后台进程竞争状态及设备实际内存压力动态判定的“相对性警告”。

    具体解释如下：
    1. 触发逻辑本质是“内存压力等级”，而非“绝对用量”
    iOS不以固定内存值（如1.8GB）为硬触发点，而是通过vm_pressure_level监控全局内存压力。当系统检测到：

    • 可用内存页急剧减少（尤其活跃/非换页内存不足）；
    • 后台App被大量驱逐释放内存；
    • 文件缓存或压缩内存已达上限；
      → 系统向前台应用发送applicationDidReceiveMemoryWarning，提示其主动降载。

    2. 1.8GB 高频触发的典型场景
    此区间常对应：

    • 应用已加载大部分资源（纹理、Mesh、Audio），但尚未触发Unity的Resources.UnloadUnusedAssets()或AssetBundle卸载；
    • 原生堆（Native Heap）与托管堆（Mono Heap）持续增长，GLES驱动内存池（如MTL/OpenGL纹理缓存）接近饱和；
    • 系统仍保留一定后台缓冲空间，此时压力信号敏感且频繁。

    3. 更高内存（如>2.2GB）后触发率下降的合理原因
    ⚠️ 并非系统“变宽松”，而是进入更危险阶段：

    • 系统已启动强制干预：终止后台App、压缩inactive pages、回收文件缓存；
    • 若应用继续申请内存，不再发送警告，直接触发SIGKILL（OOM Killer）；
    • 此时applicationDidReceiveMemoryWarning反而减少 —— 因系统已无“协商余地”，转向静默强杀。

    验证与优化建议

    • 使用Xcode Instruments → Activity Monitor查看Real Memory + Pressure Level曲线，确认是否伴随vm: pressure上升；

    • 在OnLowMemory回调中立即执行：

      • Resources.UnloadUnusedAssets() + Texture2D.DestroyImmediate()清理未引用纹理；
      • 切换至低配资源（如ASTC 4x4替代8x8）；
      • 持久化关键游戏状态（防被杀丢档）；
    • 限制峰值内存：通过UWA GOT Online的GPU/Resource/Mono报告，定位内存大户（如超大图集、未卸载AB、Mono GC堆膨胀）。

    该行为是 iOS 内存保护机制的正常表现，高频警告恰说明应用处于“可挽救临界区”，需优先优化资源生命周期管理。

    可以参考以上AI回答。而且实际上看起来这个警告只在1.8GB左右触发，也即内存更高时反而不触发的原因。

    分享链接：
    https://www.uwa4d.com/main/uwa-shared.html?shareId=bfb1e3df-0...

    无论是社区里开发者们的互助讨论，还是AI基于知识沉淀的快速反馈，核心都是为了让每一个技术难题都有解、每一次踩坑都有回响。本期分享分别来自UWA AI问答和UWA问答社区，希望这些从真实开发场景中提炼的经验，能直接帮你解决当下的技术卡点，也让你在遇到同类问题时，能更高效地找到破局方向。

    封面图来源于网络

    今天的分享就到这里。生有涯而知无涯，在漫漫的开发周期中，我们遇到的问题只是冰山一角，UWA社区愿伴你同行，一起探索分享。欢迎更多的开发者加入UWA社区。

    UWA官网：www.uwa4d.com
    UWA社区：community.uwa4d.com
    UWA学堂：edu.uwa4d.com
    官方技术QQ群：793972859

    SonarQube Server 2025.6.1.117629 - 代码质量、安全与静态分析工具

    SonarQube Server 2025 Release 6 (macOS, Linux, Windows) - 代码质量、安全与静态分析工具

    Self-managed static analysis tool for continuous codebase inspection

    请访问原文链接：https://sysin.org/blog/sonarqube/ 查看最新版。原创作品，转载请保留出处。

    作者主页：sysin.org

    SonarQube Server

    代码质量和安全性由您掌控

    SonarQube Server
    之前称为 SonarQube，本地部署的用于持续代码库检查的静态分析工具

    保持 AI 生成的代码干净

    释放 AI 编码助手的强大功能，而无需承担不良、不安全代码的风险。SonarQube Server 是您的干净代码解决方案，可以部署在任何地方、本地或云环境中。

    SonarQube Server

    受到 700 万开发者和 400,000 多个组织的使用和喜爱

    提高代码质量的代码质量工具

    您的代码是一项商业资产。通过 SonarQube Server 达到干净代码状态，实现代码的最高价值。

    SonarQube Server 功能：

    • 代码智能

      利用 SonarQube 的深度洞察，更全面地了解您的代码库。通过减少认知负荷来提高开发人员的生产力。

    • 与顶级 DevOps 平台集成

      轻松加入项目。与 GitHub Actions、GitLab CI/CD、Azure Pipelines、Bitbucket Pipelines 和 Jenkins 集成，以自动触发分析并显示您工作地点的代码运行状况。

    • 代码审查

      通过 SonarQube 的质量阈值，防止不符合策略的代码进入生产环境。消除人工编写和 AI 生成代码中的问题，从而降低后期修复成本。

    • 高性能和可操作性

      按照您的方式进行部署，无论是在本地、在云中、作为服务器、使用 Docker 或 Kubernetes。多线程、多个计算引擎和特定于语言的加载可提供最佳性能。

    • 顶级分析速度和准确性

      在几分钟而不是几小时内收到可操作的清洁代码指标 (sysin)。Clean as You Code 会在您工作时检查较小的代码片段，为您提供有关新代码质量的准确反馈。

    • 重要语言的关键安全规则

      在您的开发工作流程中，在正确的时间和正确的位置无缝地发现编码问题。受益于 6,000 多个规则以及行业领先的 Java、C#、PHP、Python 等污点分析。

    • 共享、统一的配置

      设置特定的编码标准，使您的团队在代码健康方面保持一致并实现您的代码质量目标。另外，“边编程边学习” 可将开发人员的技能提升到同样高的水平。

    • 用于 IDE 的 SonarQube

      添加 SonarQube for IDE 扩展并将其连接到 SonarQube 服务器，以便在编码时动态查找编码问题，并确保您的团队遵循单一受监管的编码标准。

    • 测量代码覆盖率

      查看测试执行的代码库的百分比，以获得有关代码运行状况的宝贵见解。引导您到覆盖率低的领域进行改进。

    Sonar 的人工智能

    AI 辅助编码，由 SONAR 改进

    • 新的 AI 代码保证

      Sonar AI 代码保证是一个强大且简化的流程，用于通过结构化和全面的分析来验证 AI 生成的代码。这确保了每一段新代码在投入生产之前都符合最高的质量和安全标准。

    • AI CodeFix 简介

      Sonar AI CodeFix 是一项强大的功能 (sysin)，可为代码分析解决方案 SonarQube Server 和 SonarQube Cloud 发现的问题提供代码修复建议。只需单击一下，您就可以获得有关如何解决一系列问题的建议，从而简化问题解决流程。

    笔者提示：此类功能通常需要有效服务合同。

    安全漏洞检测

    增强的开发人员安全工具 | 安全与机密信息检测

    • 静态代码分析

      Sonar 的静态应用程序安全测试 (SAST) 引擎可检测代码中的安全漏洞，以便在构建和测试应用程序之前消除这些漏洞。使用 SAST 为复杂项目实现强大的应用程序安全性和合规性。

    • 机密信息检测

      SonarQube Server 包含一个强大的机密信息检测工具，这是用于检测和删除代码中机密信息的最全面的解决方案之一。与 SonarQube for IDE 一起使用，它可以防止机密信息泄露并成为严重的安全漏洞。

    • 安全标准合规性

      SonarQube Server 可帮助您遵守通用代码安全标准，例如 NIST SSDF。将 SonarQube Server 与 SonarQube for IDE 结合使用，可以自动检查项目代码是否存在安全漏洞，并提高整体代码质量。

    基于开源，满足所有需求的版本

    SonarQube Server 版本：

    • Community Build

      免费开源，可提高开发效率和代码质量。

    • Developer Edition

      小型团队和企业的基本功能。

    • Enterprise Edition

      为现代企业提供更深入的见解和绩效。

    • Data Center Edition

      任务关键型高可用性、可扩展性和性能。

    什么是 LTA 版本？

    LONG-TERM ACTIVE

    SonarQube Server Long-Term Active (LTA)

    为客户提供最佳体验、创新功能和世界一流的支持，以实现持续的业务成功。

    什么是长期活跃 （LTA）

    LTA 是指每 12 个月发布一次的 SonarQube Server 版本（以前称为长期支持或 LTS）。它是产品的功能完整版本，将保持活动状态更长的时间。大型组织有时更愿意继续使用 LTA，因为他们无法经常升级，而是选择每 12 个月升级一次。

    系统要求

    操作系统要求：

    建议运行在虚拟机环境中，推荐使用本站原创虚拟机模板 OVF，简单、精准、高效。

    软件要求已更新：包含在文档中。

    新增功能

    SonarQube Server 2025.6：先沉浸（vibe），再以前所未有的速度验证

    2025 年 12 月 11 日

    SonarQube Server 2025.6

    AI 已经将开发瓶颈从 “写代码” 转移到 “验证代码”。确保代码可靠、安全、可维护，已成为软件开发生命周期中最关键的一步。SonarQube Server 2025.6 加速了这一验证流程，将其直接嵌入您的日常工作流中。通过更深的集成、大幅加速的分析性能以及扩展的语言支持，本次发布帮助团队拥抱 “先沉浸、再验证（vibe, then verify）” 的理念，更自信地交付软件。

    ✅ 2025.6 新功能一览

    • 加速工作流：新增 Jira Cloud 与 Slack 集成。
    • 更快反馈：JavaScript/TypeScript 分析速度提升最高 40%。
    • 即时修复：在 IDE 中新增 58 个 JavaScript/TypeScript 快速修复。
    • 现代语言支持：全面支持 Swift（5.9–6.1）和 Python 3.14。
    • AI/ML 保障：为 PyTorch、Apex 和 Ruby 提供高效分析。
    • 基础设施代码：新增 Go 和 Shell/Bash 的代码质量规则 (sysin)。
    • 合规性：完整覆盖 MISRA C++:2023、OWASP Top 10 2025 与 STIG V6R3。
    • 供应链安全：支持导入 CycloneDX 和 SPDX SBOM。

    ✅ 通过深度工作流集成加速您的团队

    为了帮助团队跟上庞大的代码量，SonarQube 专注于消除摩擦、加快反馈循环。使用 JavaScript/TypeScript 的开发者将立即注意到在大型项目中最高 40% 的分析速度提升，从而缩短等待时间，加速代码评审。同时，SonarQube 让修复问题变得比以往更简单：58 个全新的 “快速修复” 让您在 IDE 中即可快速处理问题。此外，将代码质量融入组织工作流也变得前所未有的顺畅：全新的 Jira Cloud 集成可立即将代码问题转成可追踪的任务 (sysin)；Slack 集成则可在质量门状态变化时实时发送通知，让团队在构建无法通过质量门时可以更快速地响应。

    ✅ 无与伦比的语言与合规覆盖

    SonarQube 2025.6 大幅扩展其在行业内对语言覆盖的领先优势，让您能自信采用新技术并满足最严苛的合规要求。SonarQube 现已为最新版本的 Python 3.14 与 Swift（5.9–6.1）提供全方位的代码安全与代码质量支持，包括 Swift 的 SAST 与秘钥检测。对于构建机器学习应用的开发者，SonarQube 提供 PyTorch 的 AI/ML 保障，帮助实现高效代码。在云原生领域，您将获得大量新的 Go 规则，以及 Shell/Bash 脚本的代码质量与代. 码安全分析。最后，在 SonarQube Server Enterprise 和 Data Center 版本中，SonarQube 提供对全部 179 条 MISRA C++:2023 指南、STIG V6R3 及新版 OWASP Top 10 2025 的完整覆盖，为您的合规与风险团队提供通过严格标准所需的保证。

    ✅ 通过 Advanced SAST 和 SBOM 保护您的供应链

    在供应链攻击不断增加的当下，代码安全绝不能被事后处理。此次发布强化了 SonarQube “集成代码质量与代码安全” 的核心使命。SonarQube Advanced Security 中的 Advanced SAST 功能已针对 C#、Java 以及现在的 Python 的主流库进行了刷新与优化，以发现其他工具遗漏的复杂、隐蔽漏洞。为了让您对所有组件拥有全面可见性 (sysin)，SonarQube Advanced Security 现在支持导入 CycloneDX 和 SPDX 格式的 SBOM（软件物料清单），实现对任意组件的统一依赖性与漏洞报告。通过这些增强功能，SonarQube 确保您的组织能够以快速且自信的方式验证每一行代码——无论是开发者编写的还是 AI 生成的。

    更多详细功能介绍，请查阅官方文档。

    下载地址

    版本历史：

    SonarQube Server 2025.1 LTA Data Center Edition for macOS, Linux, Windows | January 2025 | 2025.1.0.102418

    SonarQube Server 2025 Release 2 Data Center Edition for macOS, Linux, Windows | March 2025 | 2025.2.0.105476

    SonarQube Server 2025 Release 3 Data Center Edition for macOS, Linux, Windows | May 2025 | 2025.3.0.108892

    SonarQube Server 2025 Release 3.1 Data Center Edition for macOS, Linux, Windows | Jun 2025 | 2025.3.1.109879

    SonarQube Server 2025 Release 4.2 Data Center Edition for macOS, Linux, Windows | July 2025 | 2025.4.2.112048

    SonarQube Server 2025 Release 5 Data Center Edition for macOS, Linux, Windows | September 2025 | 2025.5.0.113872 (2025-09-24)

    SonarQube Server 2025 Release 6 Data Center Edition for macOS, Linux, Windows | December 2025 | 2025.6.0.117042 (2025-12-11)

    当前版本：

    SonarQube Server 2025 Release 6.1 Data Center Edition for macOS, Linux, Windows | December 2025 | 2025.6.1.117629 (2026-01-20)

    更多：HTTP 协议与安全

    和大家分享6个我收藏夹里雷打不动的网站。这些工具不是那种看着炫酷但一年用不上一次的“吃灰”神器，而是真真正正能解决日常痛点、提升效率的好东西。

    Perplexity AI

    这是一个最近很火的 AI 搜索工具，我用它已经基本替代了传统的搜索引擎。

    它好在哪？
    以前我们搜东西，比如搜“Java 怎么读取 Excel 文件”，搜索引擎会甩给你一堆链接，让你自己一个个点进去看，有的链接还是广告，或者内容早就过时了。

    Perplexity 不一样，它会直接读完网上的相关内容，然后给你写一段总结好的答案。最关键的是，它说的每一句话后面都会标一个小数字，点一下就能跳转到信息的原始出处。

    这对查资料太重要了。用 ChatGPT 有时候它会一本正经地胡说八道，但 Perplexity 给了出处，你就可以去核实，心里更有底。平时写报告、做技术调研，或者只是查个冷知识，用它效率非常高。

    Excalidraw

    这是一个非常有特色的在线白板工具，我特别喜欢它的“手绘风格”。

    为什么用它？

    平时工作中经常需要画图，比如画个业务流程图、系统架构图，或者给同事讲讲思路。用 Visio 或者那些专业的绘图软件，虽然功能强大，但操作太繁琐了，而且画出来的图太正式，有时候反而让人不敢随便改。

    Excalidraw 打开网页就能画，界面极其简单，连注册登录都不需要。画出来的线条像是在纸上手画的一样，有一种草稿的感觉。这种“非正式感”反而能让人专注于逻辑和结构本身，而不是纠结线条直不直、颜色对不对。

    它还支持丰富的素材库，像什么 AWS 的图标、各种 UI 组件，直接拖进去就能用。画完了可以直接复制图片，或者导出成文件，非常方便。

    123apps

    这是一个在线文件处理的好网站，专门解决那些不想装软件的临时需求。

    解决什么痛点？
    大家肯定都遇到过这种尴尬情况：突然需要把一个视频转成 GIF，或者要把 PDF 里的某一页拆分出来，又或者是一段录音需要剪掉开头那几秒杂音。

    为了这点小事去下载安装一个几百兆的专业软件，既占空间又费时间，甚至还可能不小心装上一堆流氓软件。

    123apps 就是把这一堆小工具全整合在一个网站里了。视频剪辑、音频转换、PDF 合并拆分、录屏，几乎涵盖了所有常见的文件处理需求。你需要什么功能，点进去把文件拖进去，处理完下载走人，干脆利落。

    Carbon

    如果你经常需要分享代码，那这个网站绝对是颜值担当。

    它有什么用？
    有时候我们在写文章、做 PPT 或者在群里讨论技术问题时，直接把代码截图贴出来，往往模糊不清，还很难看；如果直接复制文本，格式又容易乱掉。

    Carbon 就是专门解决这个问题的。你把代码复制进去，它会自动给代码加上高亮颜色，还能给图片加上漂亮的背景框和阴影，看起来就像是一张精心设计的海报。

    你可以自己选配色主题（比如类似 VS Code 的风格），选编程语言，甚至调整窗口的圆角大小。做出来的图往 PPT 里一放，专业感立马就上来了。

    DevDocs

    这是一个把所有开发文档都装进口袋的网站。

    极客首选
    写代码离不开查文档。一会儿查 HTML 标签，一会儿查 CSS 属性，一会儿又要看 Python 的库函数。如果每次都去各自的官网查，要在浏览器里开一堆标签页，而且每个官网的排版、搜索方式都不一样，很心累。

    DevDocs 把几百种编程语言和框架的官方文档都抓取下来，整合成了一个统一的界面。

    它的搜索速度极快，支持模糊搜索。而且它支持离线模式，你可以把常用的文档缓存到本地，哪怕断网了也能照样查。界面干净清爽，没有乱七八糟的干扰，就是纯粹为了查资料而生的。

    GitHub

    很多人以为 GitHub 只是程序员存代码的“仓库”，其实它更像是一个巨大的技术宝库和开发者社区。

    它能做什么？

    首先，它确实是目前最好用的代码托管平台。无论你是写一个小脚本，还是开发一个大项目，把代码传上去，既安全方便，又不用担心硬盘坏了代码丢了。

    其次，这里是找资源的神器。想学 Python？搜一下就有无数的教程和示例代码。想做一个博客？上面有很多现成的模板，改改就能用。

    甚至很多面试官都会看你的 GitHub 主页，如果你经常在上面活跃，提交代码，或者给开源项目做贡献，这绝对是你简历上的一大亮点。

    简单说，不管你是想找现成的轮子，还是想学习高手的代码，或者只是想存一下自己的学习笔记，GitHub 都是绕不开的。

    以上就是我强烈推荐的6个网站。它们每一个我都用了很久，希望能帮大家节省时间，少走弯路。

    如果对你有帮助，点点关注点点赞

    1. 1
    2. ...
    3. 687
    4. 688
    5. 689
    6. 690
    7. 691
    8. 692
    9. 693
    10. ...
    11. 872