PLM选型对比表设计与避坑指南:从业务痛点推导权重的结构化决策
简介产品生命周期管理PLM项目选型对比表是一份面向企业数字化建设决策者、信息化主管及项目实施团队的选型辅助文档。文档围绕法国达索、德国西门子、美国PTC三大主流服务商从公司综合实力与财务表现、行业客户经验、技术方案完整性、数字化制造能力、系统工程成熟度、平台架构与性能、系统配置维护便利性、二次开发扩展性以及项目管理基础功能等多个维度进行横向对比并结合风能领域典型用户案例补充了量化数据和备注说明。资源压缩包内共包含1个PDF文件整体大小382KB表格化排版结构清晰适合在选型调研、厂商技术评审、内部汇报和招标参数准备等环节直接借鉴。该资料已有1937人学习下载经过众多读者验证。通过这份对比表可以快速摸清三大PLM供应商的差异化优劣势结合自身业务需求做好匹配度分析为后续实施路径规划、投资预算制定和技术选型决策提供切实依据。1. PLM选型对比表做砸一个项目通常只需要一个动作PLM选型对比表做砸一个项目通常只需要一个动作让三家厂商轮流演示一个月然后选型会上研发说A家BOM顺手IT说B家架构干净采购说C家便宜吵三轮没结论。另一家同行四周定了结果一张对比表、两轮筛选、一轮真实产品验证加权得分拍板。差别不在厂商在决策工具。PLM选型对比表这类文档核心是把「哪家PLM适合我们」这个模糊问题拆成结构化问题比哪些维度、每项怎么打分、谁有权评分、证据是什么。它不解决厂商之间的绝对优劣只解决你们内部能不能在同一把尺子下做比较。适合制造企业里负责选型的项目经理、IT负责人、流程负责人和进组的业务骨干要解决的是信息不透明、标准不统一、决策拍脑袋。下面从字段设计、权重分配到打分取证、避坑逐一拆开照着做就能落地。2. 先别列功能清单一张能用的PLM选型对比表从业务流程开始2.1 业务流程是表格的第一列功能清单只是第二列我见过不少选型表表头第一行就是厂商名字第一列从上到下全是功能物料管理、BOM管理、变更管理、文档管理、工艺管理、项目管理……逐项打勾。这种表做出来很整齐但有个根本问题没有业务出处。你解释不了为什么需要物料管理也判断不了厂商的「物料管理」和你说的「物料管理」是不是同一个东西。常见做法是先把业务流程画出来。制造企业的PLM相关流程一般拆成六到七段编码与主数据申请、物料与BOM创建、文档与图纸发布、工程变更、工艺协同、跨部门项目协作。每段流程找业务骨干开一次短会一次半小时记录三件事现在用什么工具、痛点是什么、期望做到什么程度。不用画多正式的泳道图一张A4纸就能承载重点是让每个参与整理的人说出他真实遇到的卡点。举个例子某设备制造企业在梳理「工程变更」流程时发现痛点不是没有变更单而是变更单在OA里走BOM在旧系统里改两边对不上一个月有四五次现场拿着旧BOM生产的事情。这个痛点直接决定了后续对比表里「变更管理」的权重必须远高于「界面美观」这类感受型指标。把流程段放在对比表的第一列功能项放在它后面好处是每次看到厂商功能时都能问一句它对应哪段流程、解决哪个痛点。对应不上的功能标为N/A不参与计分。这一步做完后面所有打分才有锚点不然厂商演示什么你记什么最后表里填的全是别人的强项。2.2 六个对比维度功能、架构、集成、成本、服务、风险流程梳理完再来定维度。PLM选型对比表我一般固定六个维度每个维度回答一个明确的问题避免维度之间互相打架。维度具体考察内容它回答的问题功能层数据模型物料/BOM/变更单/文档的对象结构、业务覆盖研发协同、变更、工艺、项目管理、行业特性如汽车零部件行业的PPAP、电子行业的ECN能不能覆盖我们的核心业务对象和关键流程架构层技术栈、部署方式本地私有化或云、定制与二次开发机制、性能与并发、移动端支持未来五年能不能跟得上我们的IT整体规划集成层与ERP/MES/CAD/OA的接口成熟度、接口配置方式、集成工作量数据能不能在生产系统之间自动流动成本层软件许可、实施服务、年度维护、预期二次开发、服务器或云资源、内部人力投入三年总拥有成本是多少而不只是首年报价服务层实施方法论、本地支持团队、知识转移计划、培训体系上了系统之后我们自己能不能独立用好风险层厂商财务健康度、产品路线图、数据迁移方案、知识产权归属如果选它最大的失败风险在哪里这里要强调一句架构层和风险层最容易在早期被忽略。功能层看得见摸得着成本层数字直接架构层和风险层要靠背景调查和访谈才能拿到信息所以常被跳过。但对于PLM这种要用十年以上的系统架构层的判断失误比功能层更致命功能可以通过二次开发补架构烂了只能推倒重来。2.3 权重从痛点推导不从销售话术来六个维度定了下一步是权重。这一步是玄学高发区常见做法是大家围在一起商量最后各打五十大板每个维度给个15到20分。这样出来的总分必然被「界面好看」「文档功能多」这类容易感知的项带偏业务上最痛的变更管理反而排不上号。我一般用的是痛点频次法三步走。第一步把2.1收集的痛点按「发生频次×影响度」打分发生频次用月均次数影响度用1到5分。第二步对痛点排序找出最痛的三到五个。第三步把这些痛点映射到对应的对比维度上痛得越重、维度权重越高。举一个电子制造企业的实际例子它的痛点排序和权重分配长这样痛点月均频次影响度对应维度权重变更不受控BOM与现场不一致40次5功能层35PLM与ERP靠人工重复录入每周约10小时4集成层20图纸外发版本混乱15次4功能层文档管理计入功能层老系统响应慢用户不愿用日常4架构层15售后支持响应慢月均6次3服务层15———成本层15为什么成本层只给15因为成本在选型阶段容易被过度关注低价厂商一旦先入为主后面所有打分都会往它倾斜。成本层的作用不是第一轮否决而是第二轮用TCO做淘汰。这个权重表只是参考实际使用时按自己企业痛点调整但有一条硬规则所有维度权重之和必须等于100权重分配要在选型组内部评审通过后再开始打分中途不得改动否则后面每个数字都可以被挑战。3. 字段设计与评分规则把对比表做成能打分的结构3.1 一张能用的对比表至少要有十列维度定完落到表结构。很多企业的对比表只有「功能项厂商A厂商B厂商C」四列这不够用。我一般做成下面这个结构列号列名说明必填1维度六大维度之一必填2一级项维度下的子类如「变更管理」「数据模型」必填3二级项可评分的最小对象如「变更单支持自定义字段」必填4权重二级项在一级项内的分值权重必填5评分说明明确什么情况得几分防止评分人各打各的必填6厂商A得分1到5分必填7厂商A证据来自问卷、演示或访谈的具体依据必填8厂商B得分同左必填9厂商B证据同左必填10备注争议记录、待确认项选填关键在第五列「评分说明」和第七列「证据」。没有评分说明两个评分人对同一项可能打出完全不同的分数没有证据列分数就成了印象分。我见过最典型的情况两个厂商在「变更管理」同时得了4分一问理由一个是因为演示里看到了对应界面另一个是因为销售口头承诺支持证据强度完全不对等。所以填表时给评分人立一条规矩每一格分数旁边必须能找到对应证据找不到证据的一律记TBD待确认不参与计分。这一条能原地消灭一大半的拍脑袋分。表格里的TBD多了不丢人它恰恰说明这轮信息没取证完不该急着打分。3.2 五分制评分法从「开箱即用」到「不可实现」评分标尺我推荐五分制并给每个分数配一个可操作的定义。三分和四分的边界是「是否需要二次开发」这是PLM选型里最重要的分界线。分数定义典型情况5分开箱即用无需配置标准功能直接覆盖演示当场可用4分少量配置无需代码后台设置、字段配置、工作流配置即可实现3分需配置加少量二次开发要写少量脚本或扩展工作量在数人天以内2分二次开发工作量大涉及数据模型改动或跨模块扩展工期数周以上1分无法实现或需推翻重来标准产品与需求冲突定制成本接近重建用这个标尺对比表里每个二级项都能被快速归类。注意两个约束第一「少量二次开发」必须在问卷里让厂商写明人天估算不能只写「可以开发、问题不大」第二评分时只按厂商当前版本的实际上线能力打分销售口头承诺的未来版本功能一律打对折并且标注「依赖版本」。提示评分只依据当前版本的实际能力凡是销售说「规划中、下个版本有」的功能得分上限为3分并在备注里写明版本前提。还有一个容易被忽视的细节每个维度的得分不要用简单的平均分要用加权分。二级项得分乘以二级项权重累加得一级项分一级项分乘以一级项权重累加得维度分维度分乘以维度权重累加得总分。这个计算在Excel里用SUMPRODUCT完成公式写清楚方便审计维度分 SUMPRODUCT(二级项得分区域, 二级项权重区域) 总分 SUMPRODUCT(维度分区域, 维度权重区域)SUMPRODUCT的好处是权重和得分分开存放调权重时总分自动重算不需要手改公式也不会因为某一行漏乘权重导致总分算错。3.3 一张可直接抄的模板样例下面是一个简化但完整的模板样例展示「变更管理」维度下三行数据的写法。实际使用时每家企业按自己流程扩充到几十到上百行。维度一级项二级项权重评分说明厂商A厂商A证据厂商B厂商B证据功能层变更管理变更单支持自定义审批流程40%5分标准流程模板直接可建3分需后台配置1分需开发4演示现场通过后台配置实现会签环节3问卷标注需二次开发功能层变更管理变更生效后自动更新BOM30%5分变更发布即触发BOM更新3分需人工触发同步5拿真实BOM现场演示联动更新2问卷标注仅记录变更不联动功能层变更管理变更历史可追溯可对比版本30%5分多版本对比加操作日志3分仅文字记录4演示版本对比但日志导出受限4参考客户访谈确认可用填完这十几行你会发现一个现象总分高的厂商往往不是功能最全的而是你最痛的那几项得分高的。这正是选型该有的效果——选型不是选功能最多的软件而是选最贴合自身业务痛点组合的软件。4. 数据怎么填才不是废表问卷、Demo、访谈三段式取证4.1 厂商问卷让厂商按你的表填而不是按宣传册讲对比表结构定好之后第一件事不是约Demo而是把表发给厂商填。做法是把功能层、架构层、集成层相关的二级项整理成一张Excel问卷每个二级项要求厂商在「支持、需配置、需开发、不支持」四个选项里选一个并且必须在「依据」列填写证据产品手册章节号、演示视频链接、客户案例名称或接口文档截图。给厂商的时限我一般定7到10个工作日。超过时限的在备注里记一笔延误。这里有个经验认真填表的厂商通常实施方法论也认真交回来一份PPT让你自己对比的厂商往往后面Demo也敷衍。问卷本身就是第一道筛选器。问卷回填后第一轮筛选就开始了。规则很简单核心业务对象物料、BOM、变更单的数据模型关键字段不支持的直接淘汰不进Demo轮。这一条能砍掉一半的候选厂商省下后面所有时间。4.2 Demo验证用你自己的三个业务场景不让厂商自由发挥第一轮筛选后剩下的厂商进入Demo环节。这里最大的坑是让厂商自由演示他们一定会展示最漂亮的标准功能恰好绕开你的痛点。我的做法是自己写演示脚本提前发给厂商要求他们用这个脚本走一遍。脚本通常选三个场景第一个是核心业务场景拿企业当前真实的一个产品脱敏后走完「创建物料→搭建BOM→发起工程变更→走完审批流程→发布新版BOM→传递到ERP」这条完整链路。这个场景覆盖了功能层和集成层最关键的几项。第二个是跨部门协同场景设计人员发起任务给工艺工艺回传工时和工艺路线质量在节点上做评审。观看这个场景时注意角色切换是否流畅、权限控制是否到位。第三个是异常场景模拟变更被驳回后重新提交、BOM被引用时禁止删除、文档替换后旧版本自动归档。异常场景最能暴露一个PLM的数据模型是否严谨标准演示里几乎看不到这些。规则再强调三点第一Demo现场至少两个人参加一个人看业务效果另一个人对照对比表逐项打勾记录第二全程录像评分有争议时翻录像第三厂商演示失败先记录失败点再给一次补演示机会第二次仍失败就按实际能力打分。Demo结束后当天把现场记录回填到对比表里不给参会人「隔两天再回忆」的机会。隔夜之后的记忆会美化当天填表是防止印象分污染最有效的手段。4.3 参考客户访谈三个必问和一个变着法问Demo之后进入最后一轮取证参考客户访谈。厂商会给一份客户名单名单上的客户大概率是关系好的但访谈仍然有价值关键在提问方式。三个必问问题。第一问实施周期原计划多长实际上线用了多久延期的主要原因是什么。这个问题直接反映实施团队的真实水平厂商PPT里的「成熟方法论」有没有兑现一问就知道。第二问上线到现在哪些模块用得最好哪些模块基本没人用。没人用的模块问清楚是功能不适用还是操作太复杂这两类问题的处理方式完全不同。第三问如果重新选一次你们会在哪些环节上改变决定。这个问题能挖出名单客户真实的遗憾往往比前两个问题信息量都大。一个不能直接问的问题别问「你们当时买的多少钱」。客户多半不愿说而且商务条件在不同时间点没法直接对比。想了解成本变个方式问不算软件本身实施和三年运维加起来大概占软件费用的几倍。这个比例对估算自己的TCO很有参考价值。访谈记录要归档到对比表的「风险层」和「服务层」证据列。客户抱怨最多的点就是你在合同里要重点谈的保护条款。5. PLM选型对比表避坑指南五个真实翻车现场5.1 现象只比功能清单数据模型成了黑匣子现象对比表里功能项全是整齐的打勾选中厂商在实施阶段暴露出物料主数据字段不可扩展编码规则写死在代码里加一个字段要两周开发。原因功能对比只做到模块级没下沉到字段级。厂商宣传的「BOM管理」可能只有单层BOM而你们需要多视图BOM。解决在对比表的功能层加一组「核心对象字段清单」评分项要求厂商提交物料、BOM、变更单三个核心对象的字段列表并标注哪些字段可扩展、哪些可自定义。字段级一对比产品成熟度高下立判。5.2 现象权重平均分配总分赢在无关紧要的项现象加权总分第一的厂商界面好看、文档功能多但变更管理只能拿2分而变更管理是你们最痛的业务。结果上线三个月后业务部门集体抗议。原因权重在选型组里和稀泥每人分一点最后把权重拉平了。解决权重必须在打分前评审通过用2.3的痛点频次法推导。另外在汇总页同时列出「加权总分」和「核心痛点满足度」两个指标核心痛点满足度取你们前三痛点对应二级项的平均分两个指标一起看防止总分掩盖短板。5.3 现象Demo现场被厂商讲师带节奏对比表对不上账现象厂商讲了一个小时行业最佳实践和成功案例到你们场景时只剩五分钟一句「这块我们很成熟你们回去验证就行」带过。回去对照对比表大部分格子还是空的。原因没有自己的演示脚本和现场记录机制厂商自然选择展示强项。解决提前把演示脚本发给厂商明确每个场景限时30分钟超时即停止现场安排专人按对比表逐项打勾打不了分的当场标「未验证」。当场对不上的格子越多这家厂商的风险信号越强。5.4 现象只比License报价TCO在后半场反超现象某厂商首年报价最低顺利进入候选。实施阶段二次开发费、ERP接口费、服务器采购费层层加码三年总费用反而比另一家高40%。原因成本对比只有一列「软件许可费」实施、接口、运维、开发全部漏掉了。解决成本维度拆成四列软件许可、实施服务、三年运维、预估二次开发。其中预估二次开发一列在Demo之后由选型组和厂商一起按对比表里的「需开发」项逐项估算人天宁可估高不要估低。5.5 现象对比表做完没人认结果出了会议室就翻案现象选型结果公示后被业务部门质疑「选了个不好用的」选型会重新开对比表被推翻。原因打分人没有正式授权业务骨干没有参与评分评审过程没有留痕。解决打分人名单在选型启动时就由负责人确认并公示评分完成后开一场评审会逐条过总分前两名厂商的差异项现场确认无误后与会人员签字。签字版对比表作为选型决策的正式附件存档。6. 让对比表推动决策三张辅助表和一份一页纸汇报对比表是主表但只靠主表还推不动决策。我习惯在主表后面配三张辅助表让选型结果从「数字」变成「可执行的决策依据」。第一张是风险登记表。每条风险写清风险描述、发生概率、影响等级和应对措施。比如「厂商本地实施团队经验不足」这条应对措施是在合同里锁定实施顾问名单并写明更换核心顾问需我方书面同意。第二张是集成工作量估算表。把CAD到PLM、PLM到ERP、PLM到MES、PLM到OA的每一个集成点单独列一行由实施方和你们IT共同估算人天合计数直接回填到主表的成本维度。这张表既能拿来砍价也是后续实施计划的工作量基线。第三张是分阶段实施路线对比表。要求每个候选厂商给出建议的一期二期范围、里程碑、上线周期和所需资源。两个厂商的主表总分相近时这张表往往才是最终决策的关键——都差不多的情况下谁的实施路径更贴合你们的数据现状和人力现状谁就更稳妥。汇报时把主表和辅助表浓缩成一页纸上半部分是六个维度的得分对比左下是核心痛点满足度右中是三年TCO对比右下是风险Top3。口头汇报只讲三句话推荐谁、为什么是它最多两条理由、不选另一家最大的顾虑是什么。多一句都容易把决策会带回吵架模式。选型结束后把签字版的对比表和辅助表一起归档。我个人的习惯是两年后做PLM系统健康度复盘时再把这张表翻出来对照当初打分和实际使用情况看看哪些判断对了、哪些被厂商话术带偏了。这张表最大的价值有两个选型阶段帮你们做结构化决策选完之后留下一个可追溯的决策基线。希望帮到你。本文还有配套的精品资源点击获取

相关新闻

GongBU模型评估详解:如何用BERTScore、BLEU和Distinct-n指标科学判断微调效果

GongBU模型评估详解:如何用BERTScore、BLEU和Distinct-n指标科学判断微调效果

【免费下载链接】GongBU Paper accepted by CIKM 2024. Codes of GongBU, a LLM fine-tuning platform for domain-specific adaptation. 项目地址: https://gitcode.com/gh_mirrors/go/GongBU 点击查看 免费下载 微调完成之后,最让人头疼的问题往往是&…

2026/10/13 12:49:58 阅读更多 →
Context Hub 多版本 API 文档机制详解:从 versioned-api 目录结构到 chub 版本解析原理

Context Hub 多版本 API 文档机制详解:从 versioned-api 目录结构到 chub 版本解析原理

【免费下载链接】context-hub 项目地址: https://gitcode.com/gh_mirrors/co/context-hub 点击查看 免费下载 本文以 Context Hub 仓库中的多版本文档测试样例 v1/DOC.md 为线索,系统讲解 Context Hub(chub CLI)如何组织、构建、…

2026/10/13 12:49:58 阅读更多 →
WinForm角色权限设计实战:五表RBAC动态菜单与反射窗体实现

WinForm角色权限设计实战:五表RBAC动态菜单与反射窗体实现

简介:这份C# WinForm角色权限菜单源码包,面向需要在Windows桌面应用中实现权限控制的开发者,提供了一套基于角色的动态菜单完整解决方案。核心设计思路是让权限与角色绑定,用户通过分配角色自动获得对应操作权限,从而大…

2026/10/13 12:49:58 阅读更多 →

最新新闻

数据结构期末试卷拆解:高频考点与手写算法提分策略

数据结构期末试卷拆解:高频考点与手写算法提分策略

简介:湖北大学《数据结构》2022—2023学年第一学期期末试卷(A卷),面向计算机相关专业本科生,适合期末复习、考研自测及教学参考。试卷为闭卷考试,覆盖判断分析题、简答题与应用分析题,重点涉及带…

2026/10/13 13:34:15 阅读更多 →
LiteLLM:统一LLM API网关的工程实践与生产落地

LiteLLM:统一LLM API网关的工程实践与生产落地

1. 项目概述:LiteLLM 是什么,它解决的到底是什么问题?LiteLLM 这个名字乍一听像是某个轻量级模型,但其实它压根不训练模型、不压缩参数、也不做推理加速——它是个“协议翻译器”,更准确地说,是一个统一 AP…

2026/10/13 13:34:15 阅读更多 →
Win7下部署PaddleOCR-json:离线OCR服务实战指南

Win7下部署PaddleOCR-json:离线OCR服务实战指南

简介:面向Windows 7 64位环境的PaddleOCR离线部署压缩包,适合需要在本地快速搭建文字识别能力的开发者和企业用户,可免去自行编译和下载模型的繁琐步骤。包内含PaddleOCR-json主程序、动态链接库运行环境、PP-OCRv3系列文本检测、方向分类与文…

2026/10/13 13:34:15 阅读更多 →
图数据库标签计数实战:从全表扫描到索引直读的避坑指南

图数据库标签计数实战:从全表扫描到索引直读的避坑指南

1. 从一次数据盘点需求说起:为什么“数标签”这件事没那么简单刚接触图数据库那会儿,我接到的第一个真实需求就是“把库里所有标签的数量统计出来”。当时心想,这不就是一句MATCH (n) RETURN labels(n), count(*)的事吗?结果跑出来…

2026/10/13 13:34:15 阅读更多 →
Elasticsearch 7.6.2 + IK分词器Docker部署全避坑指南

Elasticsearch 7.6.2 + IK分词器Docker部署全避坑指南

1. 为什么7.6.2版本的IK分词器在Docker里总“不认中文”?——从一次线上搜索失效说起 上周帮某高校实验室调试一个文献检索Demo,后端用的是Elasticsearch 7.6.2,前端输入“机器学习”“深度神经网络”这类词,返回结果全是空——不…

2026/10/13 13:34:15 阅读更多 →
DRF接口设计实战:十大接口标准化写法与视图家族选型指南

DRF接口设计实战:十大接口标准化写法与视图家族选型指南

1. 从“能跑通”到“敢上线”:DRF接口设计的真实分水岭刚接触Django REST Framework(后面统一叫DRF)的人,几乎都会经历同一个阶段:照着文档把序列化器、视图、路由拼起来,接口能返回JSON,就觉得…

2026/10/13 13:33:14 阅读更多 →

日新闻

物联网系统集成避坑指南:从选型到验收的关键要点

物联网系统集成避坑指南:从选型到验收的关键要点

做了这么多年物联网系统集成的项目,我最大的感受是,大部分坑不是出在技术前沿,而是出在一些看起来很平常的地方。设备选了便宜的、协议没问清楚、现场没摸透、验收标准写得含糊——这些细枝末节,最后都会变成延期、超支和扯皮的大…

2026/10/13 0:00:57 阅读更多 →
ESP32舵机控制全攻略:从PWM原理到高级玩法与常见故障排查

ESP32舵机控制全攻略:从PWM原理到高级玩法与常见故障排查

如果你玩ESP32有一阵子了,很难不碰到舵机控制这道坎。做智能小车要转方向,做机械臂要抬关节,做云台要偏航俯仰,背后都是同一个东西在干活:舵机。而我见过太多人卡在“代码能编译、舵机就是不听话”这个阶段&#xff0c…

2026/10/13 0:00:57 阅读更多 →
CAN总线原理与STM32实战:抗干扰、仲裁、错误处理全解析

CAN总线原理与STM32实战:抗干扰、仲裁、错误处理全解析

1. 为什么CAN总线至今仍是工业现场的“硬通货”?——从汽车底盘到智能温室的真实需求你有没有拆过一辆老款燃油车的中控台?或者调试过某高校实验室里那台跑着Modbus协议却频频丢帧的PLC控制柜?又或者,在某个农业物联网项目里&…

2026/10/13 0:00:57 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/13 2:54:56 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/12 0:16:38 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/13 1:58:08 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/12 21:05:09 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/12 14:48:49 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/12 18:11:17 阅读更多 →