SRM+AI智能寻源:10分钟完成一轮供应商寻源的实战拆解
干了十几年采购数字化最近一年被问得最多的一个词就是“智能寻源”。过去大家谈SRM聊的是采购订单协同、供应商档案、对账开票这些“管”的层面。现在不同了企业手里都有了些数据上了SRM基础模块开始琢磨怎么把“寻源”这件事也用系统做起来。尤其AI大模型火起来之后很多老板直接问采购部能不能把找供应商这事也交给AI10分钟给我出个候选名单我的答案是能但前提是你要把SRM里的数据底子打牢把寻源流程梳理清楚再把AI恰当地嵌到关键节点上。这篇文章我就用实际跑通过的一套方案完整拆解“SRMAI智能寻源”是怎么做到10分钟完成一轮标准供应商寻源的。适合正在做SRM选型、准备上智能寻源模块的采购数字化负责人也适合想理解AI采购应用逻辑的实施顾问和产品经理。1. 先弄清楚AI智能寻源到底解决了什么1.1 传统寻源的五大痛点我见过很多企业的寻源本质上还停留在“人肉Excel”阶段。需求部门提个采购申请写一句“采购一批某某物料”采购员拿到手之后先去自己的通讯录和聊天记录里翻找之前合作过的供应商逐个打电话问有没有兴趣报价。再不行就去163诚信通或者行业内的人脉群里发个消息看谁自荐过来。这个过程有几个很要命的问题。第一是慢一个稍微复杂点的物料从需求确认到拿到第一批报价一周时间是家常便饭。第二是不全超过三年没有合作的老供应商或者新进入行业但质量很好的供应商很容易被漏掉。第三是不准需求描述经常是口语化的采购员需要靠经验去翻译成技术规格翻译错了后面全是坑。第四是没法追溯为什么选这家不选那家完全凭个人经验出了问题责任说不清。第五是成本不透明同样的物料不同采购员买出来的价格可能差10%以上根本原因是寻源范围不一样竞争不充分。这五个痛点每一个都真金白银地在消耗企业的利润。我之前在一家年采购额20亿的制造企业做过一次摸底他们的可寻源物料里真正走完正式比价流程的不到四成剩下六成都是“老朋友报价”直接续签。这种模式在行情稳定的年份没什么大问题但这两年原材料价格波动大供应风险事件频发再靠老经验就有点玩不转了。1.2 AISRM的组合逻辑所谓SRMAI智能寻源不是把AI当成一个挂在系统旁边的聊天机器人而是把人工智能模型嵌入到寻源的每一个关键环节替代过去靠老师傅经验完成的工作。逻辑分三层。底层是数据层SRM系统里沉淀的供应商主数据、历史交易记录、报价记录、绩效评估结果这些是AI的“燃料”。中间是模型层自然语言处理模型理解采购申请里的需求描述推荐模型根据物料特征和供应商画像做匹配风险评估模型对候选供应商做合规预筛查价格预测模型给出合理价格带。上层是应用层也就是采购员实际看到的界面和操作流程从发起寻源到接收推荐结果再到生成询价单、开出比价报告都在一个流程里完成。这个组合能成立关键在于SRM把采购数据做了结构化沉淀。没有SRMAI就是无米之炊。有了SRM再叠加AI效率提升是几何级别的。我团队的实测数据是标准物料有完整物料编码、有历史供应商数据的从创建寻源单到输出推荐候选供应商纯系统耗时平均在6到8分钟新物料没有历史数据的因为有需求解析和外部供应商库匹配的环节会慢一些一般在15分钟到半小时。所以我们对外宣传的“10分钟”针对的是标准物料寻源场景这是大家最高频的诉求也是最能快速见效的场景。2. 系统核心能力拆解这10分钟是怎么省出来的2.1 需求解析与标准化把“人话”变成结构化字段寻源的第一步永远是从需求开始的。过去这里就要折腾半天需求部门写的东西五花八门有人写得专业有人写得很随意。我见过最离谱的采购申请写的是“买点那种不锈钢的接头要质量好一点的”这种需求给AI也白搭因为信息量不够。做AI寻源之前必须先建一道需求解析关卡。系统用自然语言处理模型把采购申请里的一段描述性文字抽取成结构化字段。比如输入“1.5mm冷轧钢板每月用量80吨要求有ISO9001认证江浙沪优先”系统会识别出物料类别是钢材/板材规格是1.5mm月用量80吨认证要求是ISO9001交付地偏好是江浙沪。这些字段自动填入寻源单后续所有环节都基于这些结构化数据运行。实际落地的时候要注意需求解析模型的效果高度依赖物料分类体系的规范程度。如果企业的主数据里物料编码都是乱的同一个物料有三种叫法模型再强也没用。所以上AI寻源模块之前我强烈建议先花两到四周时间做一轮物料主数据清洗把“螺丝”“螺钉”“螺栓”这类同义词归并掉。这一步省不得后面能少踩一半的坑。2.2 供应商推荐引擎谁在帮你筛候选名单需求标准化之后核心环节是推荐候选供应商。这个环节传统做法是采购员自己回忆、自己问、自己搜。AI寻源的做法是让推荐引擎从三个维度打分。第一个维度是历史合作匹配度。系统调取SRM里该物料的历史采购记录找出过去三年有实际交易、且到货质量稳定的供应商。这里要注意一个细节不是交易过就算匹配要按物料分类编码精确匹配而不是按供应商名称模糊匹配。比如历史买过“伺服电机”现在要买“减速机”虽然可能是同一家供应商能供货但物料编码不同历史数据不能直接复用。第二个维度是供应商能力画像匹配。这需要给每个供应商建立标签体系包括主营品类、供货区域、产能规模、认证资质、即使业绩等。推荐引擎把需求里的结构化字段和供应商标签做相似度计算给出一个能力匹配分。为了实现这个前期要做大量的供应商信息补全工作团队整理过几百个供应商的公开资料填进系统里。第三个维度是绩效与风险分。SRM里本来就有供应商绩效评估模块把交货准时率、来料合格率、配合度这些指标算成分数风险分则来自企业信用数据库。推荐引擎把三个维度加权汇总输出一个Top N推荐清单每个候选供应商都带着一个推荐理由比如“与物料A匹配度高近一年准时交付率98%风险评级低”。2.3 风险预筛查报价前先排雷供应商寻源里最怕的是什么不是报价慢而是选了一家看起来便宜、结果后面暴雷的供应商。交付出问题、质量出问题甚至涉及法律纠纷这些都是采购事故。过去这些信息靠采购员网上搜搜到什么算什么既不系统也不及时。AI寻源的好处是把风险筛查做成了自动化的前置环节。候选供应商清单出来之后系统会逐一调取该供应商在库的工商基础信息、涉诉记录、失信被执行记录、行政处罚记录、异常经营名录等数据源做自动比对。只要命中高风险标签直接打上“高风险”标记并从推荐清单里剔除或者标注“建议人工复核”不再进入询比价环节。这个环节能极大的缩短时间。人工核查一家供应商的合规底细快的话20到30分钟慢的话半天。机器做呢我实测过893家初筛候选供应商风险预筛查跑完全部数据比对耗时大约90秒。你说这个时间省得值不值得。当然要注意机器筛查看的是结构化数据有些隐性风险比如实际控制人在行业里的口碑、客户现场管理混乱机器是看不出来的所以风险预筛查是辅助不是替代人工背调。2.4 智能询比价与谈判辅助把商务动作提效候选清单确定之后接下来是询比价。AI寻源系统会自动生成询价单内容包括物料编码、规格参数、采购数量、交付要求、质量标准、报价截止时间这些结构化信息。询价单通过系统消息、邮件或者短信批量发给候选供应商供应商在供应商门户里在线填报价格。这里要展开讲一下AI在比价环节的价值。传统比价都是“谁报价低谁中标”但真正的采购成本远不止裸价。付款账期影响资金成本交货周期影响库存成本质量水平影响来料检验成本这些综合考虑才是真实成本。AI做的事情是报价截止后自动拉取历史成交价、市场参考价、供应商账期和交期信息算出每家的综合持有成本再给出推荐排序。采购员看到的不只是一个价格列表而是一个带解释的分析报告。在谈判阶段AI还能提供一些支撑比如告诉采购员“这家供应商的报价比他们上轮成交价高8%”“同规格物料另外两家供应商平均报价低5%”这些信息在谈判中都能转化为筹码。当然最终谈成什么样还是看采购员的能力AI只是把信息整合成本降下来了。3. 实操全流程手把手跑通一次智能寻源3.1 前置准备数据和模型要到什么程度讲实操之前先把大实话放在前面AI寻源不是开箱即用前置准备工作决定成败。我见过太多企业一上来就买了个智能寻源模块然后发现系统里要数据没数据要标签没标签推荐出来的供应商还不如自己问的靠谱最后项目烂尾。按照我实操的经验上AI寻源前至少要完成三件事。第一件物料主数据治理至少把采购额占比前80%的物料整理成标准的分类和编码体系。第二件供应商主数据完善每家活跃供应商都打上主营品类、产能区域、年销售额区间、关键资质这几个标签新供应商注册时强制填写并审核。第三件历史交易数据的按时补录特别是近三年的采购记录、报价记录、到货记录和质检记录。这三件事听着简单做起来工作量巨大我建议分品类逐步推进而不是一次性做完。先选一到两个物料品类跑通流程再逐步覆盖更多品类。模型层面用通用的大模型做文本解析就够了但推荐模型一定要基于企业自身的历史数据训练。这也是为什么我坚持SRM先行——如果你的SRM系统里积攒了一两年的高质量历史交易数据推荐模型的准确率会有显著提升。没有这些数据硬上一个AI寻源推荐结果基本就是拍脑袋还不如老师傅凭经验。3.2 发起寻源从需求单到候选清单我以实战中一个真实场景来演示整个操作流程。假设某设备制造企业要采购一批“伺服电机”需求部门提交的采购申请是“伺服电机额定功率750W带刹车本月需要50台下月再要50台希望四月底前全部到货。”这个需求描述不算标准但也没有特别模糊。需求被接收后系统会自动进行解析把关键信息抽取出来。物料类别是伺服电机额定功率750W带刹车是附加特征采购数量100台交期是四月底前。其中“带刹车”这类特征模型需要结合行业知识库来识别这是AI寻源里的一个技术难点。我的解决方案是预置了一个细分行业的物料特征知识库把常见物料的关键技术参数、常用别名、选型常识都整理进去。没有这个知识库模型很难理解“带刹车”是制动器配置的变体。解析完成后系统进入推荐阶段。伺服电机在SRM里有历史采购记录系统调取了五家历史合作供应商同时根据物料类别和能力标签从供应商库里又匹配出31家总共36家进入初筛。随即风险预筛查开始执行剔除了3家涉诉较多的企业和6家资质过期的企业剩余27家进入待询价候选池。这个过程在界面上就是几个进度条闪了一下我从点击“发起寻源”按钮到看到候选清单大概耗时4分钟左右。3.3 比价与推荐算法怎么给结论候选清单确定后采购员在界面上可以手动微调比如剔除某家交期不匹配的或者补充一家自己认可的优质供应商。这个人工兜底环节必须有AI给的是建议最终选择权始终在人。确认询价范围后系统自动生成询价单并批量发出。供应商通过门户在线报价报价截止后AI自动汇总。这次询价的收款结果是27家候选供应商中有12家按时报了价5家回复“暂不报价”10家未响应。未响应的供应商系统会自动打上“响应率低”的标签后续推荐时降低他们的排序权重。报价汇总后AI开始算综合成本。以其中三家的报价为例A家裸价最低1450元一台但账期要求是月结30天B家裸价1520元账期月结60天C家裸价1480元但交货期要45天满足不了四月底的交付要求。系统按照企业预设的资金成本率把账期差异折算成现金成本再把交期风险折算成缺货成本最终给出的推荐排序是B家第一、A家第二、C家第三。采购员看到的是这个结论以及背后完整的计算逻辑说明。整轮询比价从发出到拿到推荐结论大约耗时5分钟。3.4 落地执行把结果同步到采购协同寻源结论确认之后流程并没有结束最后一步是结果落地。系统会自动生成比价报告和定标审批单推送给采购负责人审批。审批通过后拟定的供应商信息直接同步到采购订单管理环节后续的订单协同、收货、对账、开票都在既有的SRM流程里继续。这一步的价值在于形成业务闭环让寻源结果不只是图表上的一个记录而是实实在在促成一笔订单。同时这一轮的报价数据、成交数据、供应商响应情况都沉淀回SRM数据层成为下一次AI推荐的训练依据。我把它称作“数据飞轮”每一次寻源都让系统更聪明一点。4. 我踩过的坑和排查经验4.1 数据治理不到位AI就变“人工智障”这是我在多个项目里踩得最深的一个坑。曾经有一家企业SRM系统已经上线三年但物料主数据一直是业务部门各自为政。同样的一个“液压阀”在系统里有三种编码分别对应进口品牌、国产品牌和通用替换件。AI寻源上线后推荐引擎被这些混乱数据带跑偏了把进口液压阀的需求推荐给了国产件供应商采购员气得想砸电脑。排查下来发现问题并不在算法而是在输入数据。供应商推荐模型再强也架不住物料分类体系是乱的。后来我们花了整整三周把该物料品类的几百条主数据重新清洗统一了分类维度推荐准确率从48%提升到了86%。这个经历让我深刻明白AI寻源项目里最耗时、最关键的工程不是写代码而是做数据治理。建议大家在项目启动先建立数据治理专项组而不是让实施团队边做边改。4.2 供应商分类体系混乱导致推荐不准另外一个高频问题是供应商主数据里的分类标签乱。我们知道匹配的本质是看供应商的“能力标签”和“需求物料”是否对得上。但很多企业的供应商分类是按“供应商注册行业”填的比如一家实际主营连接器的企业公司注册信息写的是“电子元器件制造”标签打得太粗。需求方要买“圆形连接器”的时候推荐引擎把这家公司筛出来了但实际人家主业是排针排母圆形连接器只是顺带做的报价意愿和质量都一般。解决这个问题的办法是建一套“供应商主营品类清单”按照企业自身的物料分类维度让供应商勾选自己真正擅长的品类采购员人工复核。这个动作很费人力但效果立竿见影。另一家客户狠下心来花了两个月的时间把核心供应商的主营品类全部重新认证了一遍AI推荐的精准度上了一个大台阶采购员的抱怨也少了。4.3 什么时候该人工干预AI寻源再智能它也是个工具不是决策主体。我要提醒大家有三个场景必须人工干预。第一个是战略性物料的寻源。成熟物料如标准件适合AI跑但涉及企业核心技术和成本命脉的战略物资比如定制模具、核心芯片这些物料的寻源需要供应商深度协同单纯靠AI推荐候选清单是不够的必须有采购专家和研发团队共同参与。第二个是供应商更换成本高的物料。如果切换供应商需要重新开模、重新验证批次、重新走客户审批即使AI推荐了一家综合评分更高的新供应商也要仔细评估切换风险。第三个是涉及合规审计的场景。有些行业的采购需要保留完整的人工决策痕迹AI推荐可以作为参考但最终决策理由必须由人工写清楚。这既是合规要求也是对业务负责。我的建议是把AI寻源定位为“决策辅助工具”而不是“决策替代者”。当时我在项目上线评审会上反复强调这句话这也帮我们规避了很多责任边界模糊的问题。系统输出的推荐结论在快速流转的低风险品类上可以直接执行但在高价值品类、复杂品类上必须保留人工审批环节。4.4 常见问题速查表梳理几个常见问题按场景给出排查思路方便大家直接对照。问题现象可能原因排查与解决需求解析后字段错误物料特征知识库缺失自然语言描述过于口语化检查识别的物料类别是否准确补充知识库同义词库提示需求部门按模板填写申请推荐的供应商与需求完全不匹配供应商能力标签不准或缺失核查供应商主营品类标签是否经人工认证补全核心供应商的标签信息候选供应商大量被风险筛查剔除风险筛查规则设置过严校验风险数据源是否包含误伤对轻微风险如已结案的诉讼可调整为“提醒”而非“剔除”询价单响应率低询价单模板信息不完整供应商门户体验差检查询价单是否包含完整的参数和交期优化供应商门户在线报价交互流程AI推荐排序与实际期望差距大算法权重设置不合理复核综合成本折算参数资金成本率、缺货成本权重按企业实际业务目标调整权重还有一个问题经常被忽略就是AI推荐结果的可解释性。我遇到过有采购员反馈“系统推荐了一家我没听过名字的供应商我不信任。”这说明推荐引擎不能只给一个结论还要给出详细的推荐理由。后来我们在界面上增加了推荐理由展示区明确标注“该供应商在同类物料上有长期供应经验近12个月交付准时率98%当前风险评级低”采购员的信任度大幅提升。说到底AI要让人用得放心先要把思路讲清楚。写在最后的实践心得做SRMAI智能寻源这一年多我最大的感受是技术本身并不神秘真正难的是组织协同和习惯改变。很多企业花了真金白银上系统最后却用不起来不是因为软件不好而是因为采购员习惯了老一套不愿意信任系统给的结果。破解之法只有一个先让系统在一个品类上跑出肉眼可见的效果再拿着这个案例去说服其他团队。另外一个实用建议是不要把“10分钟”当成一个绝对的性能指标来考核。它更像是一个体验目标意思是采购员不再需要把时间花在搜回忆、翻通讯录、打听哪家供应商靠谱这些低价值的事情上而是可以把省下来的时间投入到供应商现场审核、商务谈判、品类策略这些真正创造价值的工作中去。我团队接手过的客户里上线智能寻源半年之后采购员的寻源效率普遍提升数倍但这部分提升并不是靠压榨人的工作强度实现的而是把机械劳动交给了系统人去做更有判断力的事。如果你正在规划这个方向我建议从小切口开始选一个采购额大、标准化程度高的物料品类先做试点。数据治理不要追求一步到位而是按品类逐层推进。系统上线后给采购员留一个月的并行适应期AI推荐结果和人工寻源结果同时跑让大家自己对比判断。用实际结果说话项目自然就推行得下去了。

相关新闻

2026年薪酬设计性价比之王,这三家藏不住了

2026年薪酬设计性价比之王,这三家藏不住了

又是一年金三银四,HR圈子里弥漫着一股焦虑——薪酬设计,到底该怎么搞?老板要控成本,员工要涨工资,竞争对手在抢人,数据报告却总让人一头雾水。更扎心的是,市面上那些薪酬产品,要么价…

2026/10/15 8:19:29 阅读更多 →
artcraft 工作台:参数化生成与素材管理的高效创作流程

artcraft 工作台:参数化生成与素材管理的高效创作流程

1. 从“artcraft”这个名字说起:它到底想解决什么问题第一次看到“artcraft”这个项目标题,我的直觉是:这大概率是一个把“艺术(art)”和“手工艺/工程(craft)”揉在一起的工具型项目。事实也确…

2026/10/15 8:19:29 阅读更多 →
Spring Boot实战:高校学生电子履历管理系统设计与实现

Spring Boot实战:高校学生电子履历管理系统设计与实现

折腾完这套高校学生电子履历管理平台,最大的感觉就是:简历系统看着不起眼,实际做起来比想象中复杂得多。这个项目虽然以毕业设计的形式展开,但功能覆盖了学生端、企业端、管理员端的完整闭环,既要把 Java Web 环境下常…

2026/10/15 8:18:28 阅读更多 →

最新新闻

Java3到底是什么?版本识别、JVM参数与升级避坑指南

Java3到底是什么?版本识别、JVM参数与升级避坑指南

第一次在工单系统里看到Java3这个项目名时,我愣了几秒。需求描述很干净:只有Java3,没有版本号,没有 README,也没有验收标准。我心里闪过两个念头:这该不会是 Java 3D 吧?可 Java 官方好像从来没…

2026/10/15 9:01:17 阅读更多 →
AI内容检测技术革新与2026工具评测

AI内容检测技术革新与2026工具评测

1. 项目背景与核心问题去年夏天我接手了一个内容审核项目时,发现团队每天要处理近3000篇疑似AI生成的文章。最头疼的是,这些内容往往能通过常规的查重检测,但读者反馈"机械感明显"。当时我们就意识到:传统的AI检测方法已…

2026/10/15 9:01:17 阅读更多 →
Python裸奔编码:极简开发的艺术与实践

Python裸奔编码:极简开发的艺术与实践

1. 项目背景与核心理念第一次听说"裸奔编码"这个概念是在2023年的一次技术沙龙上。当时一位资深开发者演示了如何用不到50行Python代码实现了一个完整的Web爬虫,而同样的功能在其他项目中往往需要数百行代码和多个依赖库。这种极简主义的编程方式让我深受…

2026/10/15 9:01:17 阅读更多 →
基于Spring Boot的智慧外贸平台设计与核心实现

基于Spring Boot的智慧外贸平台设计与核心实现

又到课题选题的高峰期,后台咨询量最大的一个方向就是“基于Spring Boot的智慧外贸平台”。很多同学来问的时候,第一句话都是:这个题目是不是就是做个电商网站?把商品放上去,能下单,能付款,就叫外…

2026/10/15 9:01:17 阅读更多 →
语义驱动的Diagram-as-Code设计方法论

语义驱动的Diagram-as-Code设计方法论

1. 项目概述:这不是画图,是构建可执行的系统逻辑骨架“diagram-design”这个词组乍看像一个普通的设计术语,但在我过去十年带过的几十个跨领域项目里,它从来不是PPT里拖拽几个矩形框、加几条箭头就完事的事。它本质是一种结构化思…

2026/10/15 9:01:17 阅读更多 →
t3code重构实录:用渐进式改造救活80万行遗留系统

t3code重构实录:用渐进式改造救活80万行遗留系统

接手一个代号叫 t3code 的旧项目,是我这几年做过最耗时,也最有收获的一件事。项目名里的 t3,其实是当初团队里一位老前辈随手起的内部代号——取的是 "Third Try" 的意思,也就是第三次推倒重来的版本。可讽刺的是&#…

2026/10/15 9:00:16 阅读更多 →

日新闻

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

1. 为什么选择容器化方式部署 LoRa 网络服务LoRa 物联网项目落地时,网络服务器是整个链路的核心枢纽。它负责接收网关上报的数据包、完成去重与解密、再把有效载荷分发给上层应用。早期大家习惯把网络服务器直接装在物理机上,依赖一堆系统库和特定版本的…

2026/10/15 0:00:46 阅读更多 →
共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

1. 共享推理服务里,扩缩容到底难在哪做过大模型推理服务部署的人,大概都经历过这样的场景:一个团队共用一套推理集群,A 业务跑的是 7B 的小模型,B 业务跑的是 72B 的大模型,C 业务白天流量高、晚上几乎归零…

2026/10/15 0:00:46 阅读更多 →
Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

1. 引子:一次内核恐慌引发的追查先从一个真实场景说起。某次我给一台老旧的嵌入式设备折腾系统裁减,为了把启动时间压进两秒以内,我手贱地把一串自认为“没用”的 systemd 服务给 disable 了,其中就包括systemd-remount-fs.servic…

2026/10/15 0:00:46 阅读更多 →

周新闻

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

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

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

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

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

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

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

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

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

2026/10/14 3:29:58 阅读更多 →

月新闻

我发现了一个新思路:用 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/15 0:14:36 阅读更多 →
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/14 22:45:47 阅读更多 →
黑夜航拍船只数据集训练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/14 7:53:34 阅读更多 →