[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-925":3,"consumer-news-interaction-925":40,"consumer-news-related-925":43},{"detail":4,"item":35},{"card":5,"schemaVersion":22,"fields":23,"content":29},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":14,"href":15,"sourceName":12,"meta":16,"metrics":19,"tags":20,"resolved":21},"NEWS_ARTICLE:925","news","NEWS_ARTICLE",925,"资讯","订单的含金量在分化","博客园","复杂的流程，在产品设计阶段就需要综合考虑多方面的建议，前期业务和技术的介入，避免产品层面出现合理但不合适的设计，过繁或者过简都不利于整体的迭代节奏。","","\u002Fnews\u002F925",[17,18],"2026","数据与架构",{},[18],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":24,"categoryName":18,"summary":13,"description":13,"publishTime":25,"updateTime":26,"sourceUrl":27,"language":28},"三范式","2026-08-29T16:37","2026-09-02T20:37:56","https:\u002F\u002Fwww.cnblogs.com\u002Fcicada-smile\u002Fp\u002F22754898","中文",{"format":30,"policy":31,"normalized":21,"html":32,"text":33,"wordCount":34,"hasBody":21},"HTML","NEWS_CONTENT_V1","\u003Cp>\u003Cstrong>订单含金量在下降，订单研发的含金量在上升。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch2>01\u003C\u002Fh2>\n\u003Cp>产品体系中，订单管理作为交易链路上最核心的模块，其流程的难度和复杂度都比较高，尤其是在经典的电商业务中，订单几乎和系统中所有核心的模块都有交互，在订单设计的初期，经常能听到某种指挥的声音：\u003C\u002Fp>\n\u003Cp>\u003Cstrong>复制某App的流程就行。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>话虽然没错，但是只在理论上可行；而当下实际的情况是：受到消费大趋势的影响，多数商品在执行低价竞争策略，导致订单的含金量在下降；然而运营又在千方百计的添加营销策略，争取提升订单量转化，这又会导致订单模块的复杂度增加，提高产品研发的含金量。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>常识来说：花哨的策略不如低价，低价策略不如仅退款。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>从最近的互联网媒体舆论来看，似乎头部电商对低价竞争都有松动，再次将重心转向订单的成交额，价格战终究还是打不动了。\u003C\u002Fp>\n\u003Ch2>02\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>订单几乎是产品中所有业务关系的焦点。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>相应的结构模型自然也就很复杂，在面对类似订单这种复杂的业务场景下，可以先从模型层面做大的结构规划设计，然后在研发的过程中持续迭代细节，先不管最后落地的是桥，或者是一叶扁舟。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>不是废墟，什么山都可以。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>设计订单的结构模型，至少要从三个大方向来考虑：平台属性，业务场景，订单主体。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>1）平台属性\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>平台的特点就是可以服务多种类型的卖家和买家，而不是独立的店铺型产品，只服务于商家的自营品类和业务；比如主流的电商平台和各种品牌的小程序店铺，这两种模式下所产生的订单结构有很大的差异：平台型订单需要将交易拆分到各个商家结算，店铺型产品的订单在拆单结算这块则简单许多。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2）业务场景\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>订单流程中需要兼容的业务交易场景很多，包括普通购买行为，预售和促销活动，团购和分期付款等；交易物品可能涉及实物和虚拟物品以及服务等；支付货币可能包括资金和优惠券以及产品内的积分兑换等，还有当下比较热门的跨境交易。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>3）订单主体\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>以平台型的业务来看，订单的主体结构至少包括三个层级：主订单、子订单、订单项；主订单可以理解为用户下单时的交易记录，子订单是拆分到商家层面的订单，订单项是拆分到商品层面的订单；从场景来说就是把购物车里不同商户的商品一次下单支付，商家收到订单后会分别处理各自的流程，比如仓储管理，发货和退换货，结算等。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>从模型层分析，已经很复杂了。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>再从产品研发层面看，还涉及用户群体中的买卖方和平台方，资金结算对账和支付渠道对接，平台运营活动和营销策略，电商场景中仓储物流和售后等，所以订单管理的难度可想而知。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>复制某App的订单流程简单，粘贴到自己的产品中很难。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch2>03\u003C\u002Fh2>\n\u003Cp>除了框架层面的模型，最核心的就是资金结构，涉及交易类的业务场景对于误差的容忍都非常低，因此在资金结构设计上需要非常的细致，并且制定好相应的计算逻辑和规则，来确保订单金额在全部结算环节都准确无误。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>批量结算单有误差，就不是简单的优化系统能收尾的问题。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>资金结构与订单主体和支付形式有直接的关系，当然也会受到对账和结算逻辑的影响，尤其是电商平台的支付，涉及到的细节繁多且复杂。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>1）资金拆分\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>用户在电商平台支付一笔订单时，假设购买三个店铺的商品，在主订单中有支付的总金额，还需要把金额拆分到三个商家的子订单中，商家的子订单金额还要拆分到订单项的具体商品，如果支付中涉及优惠和运费的不同策略，那么优惠额度也需要执行类似的拆分计算逻辑，这样方便用户针对单个商品操作退换货流程。\u003C\u002Fp>\n\u003Cp>细分下来，无论是主订单子订单还是商品的订单项，每个层级的订单都需要记录总金额、支付金额、优惠金额、运费金额，还要保证各个层级的订单对账没有误差。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2）支付形式\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>支付形式有多复杂，建议参考各大电商平台的双十一活动即可，除了核心的资金支付，还会涉及预付定金、优惠券、积分消耗、现金红包、产品货币等，这种过粪的模式也火过几年，后来和硬低价与仅退款对线失败。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>营销的精髓：优惠多少不确定，但付款额度提高了。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>当这些复杂的支付手段融入订单时，订单资金明细的管理和计算就变得非常复杂，如果出现误差问题，会导致整个订单体系和对账结算都出问题，这并不单纯是技术层面问题，更应该从产品和运营层面思考，是否真的需要这么复杂的支付模式。\u003C\u002Fp>\n\u003Cp>对于交易类业务，记录好资金明细和执行每日对账机制，可以及时发现和解决异常问题，避免造成大范围的误差和损失。\u003C\u002Fp>\n\u003Ch2>04\u003C\u002Fh2>\n\u003Cp>有订单模型的草图之后，还需要规划好订单的流程，设计核心节点的管理逻辑；因为流程连路长且复杂，所以产品和系统功能上要具备订单流程完整周期的驱动，即订单从开始到完成，或者从完成到彻底回滚。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>流程，有正向和逆向以及中断的异常情况。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>1）正向流程\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>从下单支付创建订单开始，到后续在账期内完成订单资金的结算，在流程的中间可能存在部分节点倒退的情况，但是从开始到结束走了一个完整周期；以电商购物场景为例：用户从购物车进行下单，预览订单的支付结算明细，对订单进行支付，商家进行订单确认发货，用户确认收货和评价商品，平台在账期内对订单金额进行分润结算。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2）逆向流程\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>逆向流程通常是从中间环节向前回滚，完成之后整个订单处于作废结束状态，例如用户在收到货后发现和预期不符，或者不符合卖家的商品描述，则可以发起退回流程；商家端同意且收到退货之后确认入库，并且退回用户支付的订单金额，订单逆向流程走完进入作废状态。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>3）异常流程\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>复杂流程中发生异常导致中断，这在产品中是比较常见的现象，订单被中断的原因有很多，例如用户操作层面，系统技术层面，网络或者第三方渠道突然异常等，这时就需要产品层面的人工操作入口，或者系统的定时任务识别，进而驱动订单的流程执行到下个合理的节点。\u003C\u002Fp>\n\u003Cp>以支付这个切入口来说，支付成功前如果异常，需要把订单退回到待支付状态并提醒用户重新支付，支付成功后如果异常，产品或者系统需要自发的完成后续的补偿机制，把订单推到待发货状态。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>任何业务场景中，流程的完整性都非常关键。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>尤其是订单这种复杂的流程，产品设计上预留运营手工操作的入口，系统的主动识别和自动化的补偿机制，都是必不可少的管理策略。\u003C\u002Fp>\n\u003Ch2>05\u003C\u002Fh2>\n\u003Cp>订单的管理流程复杂，相应的状态机也就很复杂，同一个订单在不同的事件驱动下，需要不断的进行状态转换，从而实现整个订单流程的完整周期；比如用户支付，商家发货，取消订单等事件，都会导致订单从一个状态转换到另一个状态。\u003C\u002Fp>\n\u003Cp>从常规的订单结构设计来说，单一的状态很难细致的描述订单的周期，需要多个状态进行组合判断；例如订单的流程状态，买卖双方的支付状态，退货过程的售后状态，围绕平台和商家的结算状态等。\u003C\u002Fp>\n\u003Col>\n \u003Cli>流程状态机：待支付、已支付、待发货、已发货、已收货、售后中、售后完成、待评价、已评价、已完成、待结算、已结算、已关闭。\u003C\u002Fli>\n \u003Cli>售后状态机：无售后、申请中、已同意、已拒绝、已退货、已收货、已入库、已退款、已取消、已完成。\u003C\u002Fli>\n \u003Cli>支付状态机：未支付、已支付、已退款。\u003C\u002Fli>\n \u003Cli>结算状态机：待结算、结算单已创建、平台已核验、商家已核验、结算单已核验、结算单异常、已打款、已确认、已完成。\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>定义状态机之后，还需要明确状态转换的驱动事件；订单状态转换的基本原理：当前状态在指定事件的驱动下转换到下个状态；例如待支付状态在支付事件驱动下转换到已支付状态，已支付未发货状态在取消订单事件下转换到已取消状态，已发货状态在申请售后事件驱动下转换到售后中状态。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>状态机转换是数学模型和逻辑，在产品层面还要明确定义状态机的描述。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>订单状态和转换逻辑复杂，但是很多中间状态和明细并不需要向用户层面暴露，只需要展示用户最关注的流程状态即可；对于大多数网购用户来说，关注自己App内订单状态，可能只涉及到支付发货和售后而已。\u003C\u002Fp>\n\u003Ch2>06\u003C\u002Fh2>\n\u003Cp>复杂的流程，在产品设计阶段就需要综合考虑多方面的建议，前期业务和技术的介入，避免产品层面出现合理但不合适的设计，过繁或者过简都不利于整体的迭代节奏。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>限制业务的天马行空，提醒技术的细节把控，同时要实现业务的核心需求，兼容技术的难点处理。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>于订单模块来说，参考其它App的流程和原理自然可以，但是想直接粘贴到自己的产品中，也显然不现实。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>原理在理论上是通用的。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>但是不同产品不同的业务背景和团队，提需求的人和实现需求的人千差万别，所以同一套理论实践出来的效果也就截然不同。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>有段子嘲讽，产品研发拿着跨江大桥的设计蓝图，最终实现的结果就是个小木筏，如果拿着小木筏的设计图，是不是得教用户游泳？\u003C\u002Fp>","订单含金量在下降，订单研发的含金量在上升。 01 产品体系中，订单管理作为交易链路上最核心的模块，其流程的难度和复杂度都比较高，尤其是在经典的电商业务中，订单几乎和系统中所有核心的模块都有交互，在订单设计的初期，经常能听到某种指挥的声音： 复制某App的流程就行。 话虽然没错，但是只在理论上可行；而当下实际的情况是：受到消费大趋势的影响，多数商品在执行低价竞争策略，导致订单的含金量在下降；然而运营又在千方百计的添加营销策略，争取提升订单量转化，这又会导致订单模块的复杂度增加，提高产品研发的含金量。 常识来说：花哨的策略不如低价，低价策略不如仅退款。 从最近的互联网媒体舆论来看，似乎头部电商对低价竞争都有松动，再次将重心转向订单的成交额，价格战终究还是打不动了。 02 订单几乎是产品中所有业务关系的焦点。 相应的结构模型自然也就很复杂，在面对类似订单这种复杂的业务场景下，可以先从模型层面做大的结构规划设计，然后在研发的过程中持续迭代细节，先不管最后落地的是桥，或者是一叶扁舟。 不是废墟，什么山都可以。 设计订单的结构模型，至少要从三个大方向来考虑：平台属性，业务场景，订单主体。 1）平台属性 平台的特点就是可以服务多种类型的卖家和买家，而不是独立的店铺型产品，只服务于商家的自营品类和业务；比如主流的电商平台和各种品牌的小程序店铺，这两种模式下所产生的订单结构有很大的差异：平台型订单需要将交易拆分到各个商家结算，店铺型产品的订单在拆单结算这块则简单许多。 2）业务场景 订单流程中需要兼容的业务交易场景很多，包括普通购买行为，预售和促销活动，团购和分期付款等；交易物品可能涉及实物和虚拟物品以及服务等；支付货币可能包括资金和优惠券以及产品内的积分兑换等，还有当下比较热门的跨境交易。 3）订单主体 以平台型的业务来看，订单的主体结构至少包括三个层级：主订单、子订单、订单项；主订单可以理解为用户下单时的交易记录，子订单是拆分到商家层面的订单，订单项是拆分到商品层面的订单；从场景来说就是把购物车里不同商户的商品一次下单支付，商家收到订单后会分别处理各自的流程，比如仓储管理，发货和退换货，结算等。 从模型层分析，已经很复杂了。 再从产品研发层面看，还涉及用户群体中的买卖方和平台方，资金结算对账和支付渠道对接，平台运营活动和营销策略，电商场景中仓储物流和售后等，所以订单管理的难度可想而知。 复制某App的订单流程简单，粘贴到自己的产品中很难。 03 除了框架层面的模型，最核心的就是资金结构，涉及交易类的业务场景对于误差的容忍都非常低，因此在资金结构设计上需要非常的细致，并且制定好相应的计算逻辑和规则，来确保订单金额在全部结算环节都准确无误。 批量结算单有误差，就不是简单的优化系统能收尾的问题。 资金结构与订单主体和支付形式有直接的关系，当然也会受到对账和结算逻辑的影响，尤其是电商平台的支付，涉及到的细节繁多且复杂。 1）资金拆分 用户在电商平台支付一笔订单时，假设购买三个店铺的商品，在主订单中有支付的总金额，还需要把金额拆分到三个商家的子订单中，商家的子订单金额还要拆分到订单项的具体商品，如果支付中涉及优惠和运费的不同策略，那么优惠额度也需要执行类似的拆分计算逻辑，这样方便用户针对单个商品操作退换货流程。 细分下来，无论是主订单子订单还是商品的订单项，每个层级的订单都需要记录总金额、支付金额、优惠金额、运费金额，还要保证各个层级的订单对账没有误差。 2）支付形式 支付形式有多复杂，建议参考各大电商平台的双十一活动即可，除了核心的资金支付，还会涉及预付定金、优惠券、积分消耗、现金红包、产品货币等，这种过粪的模式也火过几年，后来和硬低价与仅退款对线失败。 营销的精髓：优惠多少不确定，但付款额度提高了。 当这些复杂的支付手段融入订单时，订单资金明细的管理和计算就变得非常复杂，如果出现误差问题，会导致整个订单体系和对账结算都出问题，这并不单纯是技术层面问题，更应该从产品和运营层面思考，是否真的需要这么复杂的支付模式。 对于交易类业务，记录好资金明细和执行每日对账机制，可以及时发现和解决异常问题，避免造成大范围的误差和损失。 04 有订单模型的草图之后，还需要规划好订单的流程，设计核心节点的管理逻辑；因为流程连路长且复杂，所以产品和系统功能上要具备订单流程完整周期的驱动，即订单从开始到完成，或者从完成到彻底回滚。 流程，有正向和逆向以及中断的异常情况。 1）正向流程 从下单支付创建订单开始，到后续在账期内完成订单资金的结算，在流程的中间可能存在部分节点倒退的情况，但是从开始到结束走了一个完整周期；以电商购物场景为例：用户从购物车进行下单，预览订单的支付结算明细，对订单进行支付，商家进行订单确认发货，用户确认收货和评价商品，平台在账期内对订单金额进行分润结算。 2）逆向流程 逆向流程通常是从中间环节向前回滚，完成之后整个订单处于作废结束状态，例如用户在收到货后发现和预期不符，或者不符合卖家的商品描述，则可以发起退回流程；商家端同意且收到退货之后确认入库，并且退回用户支付的订单金额，订单逆向流程走完进入作废状态。 3）异常流程 复杂流程中发生异常导致中断，这在产品中是比较常见的现象，订单被中断的原因有很多，例如用户操作层面，系统技术层面，网络或者第三方渠道突然异常等，这时就需要产品层面的人工操作入口，或者系统的定时任务识别，进而驱动订单的流程执行到下个合理的节点。 以支付这个切入口来说，支付成功前如果异常，需要把订单退回到待支付状态并提醒用户重新支付，支付成功后如果异常，产品或者系统需要自发的完成后续的补偿机制，把订单推到待发货状态。 任何业务场景中，流程的完整性都非常关键。 尤其是订单这种复杂的流程，产品设计上预留运营手工操作的入口，系统的主动识别和自动化的补偿机制，都是必不可少的管理策略。 05 订单的管理流程复杂，相应的状态机也就很复杂，同一个订单在不同的事件驱动下，需要不断的进行状态转换，从而实现整个订单流程的完整周期；比如用户支付，商家发货，取消订单等事件，都会导致订单从一个状态转换到另一个状态。 从常规的订单结构设计来说，单一的状态很难细致的描述订单的周期，需要多个状态进行组合判断；例如订单的流程状态，买卖双方的支付状态，退货过程的售后状态，围绕平台和商家的结算状态等。 流程状态机：待支付、已支付、待发货、已发货、已收货、售后中、售后完成、待评价、已评价、已完成、待结算、已结算、已关闭。 售后状态机：无售后、申请中、已同意、已拒绝、已退货、已收货、已入库、已退款、已取消、已完成。 支付状态机：未支付、已支付、已退款。 结算状态机：待结算、结算单已创建、平台已核验、商家已核验、结算单已核验、结算单异常、已打款、已确认、已完成。 定义状态机之后，还需要明确状态转换的驱动事件；订单状态转换的基本原理：当前状态在指定事件的驱动下转换到下个状态；例如待支付状态在支付事件驱动下转换到已支付状态，已支付未发货状态在取消订单事件下转换到已取消状态，已发货状态在申请售后事件驱动下转换到售后中状态。 状态机转换是数学模型和逻辑，在产品层面还要明确定义状态机的描述。 订单状态和转换逻辑复杂，但是很多中间状态和明细并不需要向用户层面暴露，只需要展示用户最关注的流程状态即可；对于大多数网购用户来说，关注自己App内订单状态，可能只涉及到支付发货和售后而已。 06 复杂的流程，在产品设计阶段就需要综合考虑多方面的建议，前期业务和技术的介入，避免产品层面出现合理但不合适的设计，过繁或者过简都不利于整体的迭代节奏。 限制业务的天马行空，提醒技术的细节把控，同时要实现业务的核心需求，兼容技术的难点处理。 于订单模块来说，参考其它App的流程和原理自然可以，但是想直接粘贴到自己的产品中，也显然不现实。 原理在理论上是通用的。 但是不同产品不同的业务背景和团队，提需求的人和实现需求的人千差万别，所以同一套理论实践出来的效果也就截然不同。 有段子嘲讽，产品研发拿着跨江大桥的设计蓝图，最终实现的结果就是个小木筏，如果拿着小木筏的设计图，是不是得教用户游泳？",3300,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":15,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":39},"2026 · 数据与架构","#2563eb","16 \u002F 10",[18],{"targetType":8,"targetId":9,"likedByMe":41,"likeCount":42,"commentCount":42,"contentLikeCount":42,"contentCommentCount":42,"sourceLikeCount":42,"sourceCommentCount":42},false,0,[44,51,57,64,70,79,85,92],{"id":45,"kind":7,"title":46,"summary":47,"image":48,"href":49,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":50},"NEWS_ARTICLE:842","几何分布：从“等一个结果”开始","你有没有过这样的经历？ 在游戏里抽卡，抽了多少次才终于出货？ 站在路边等公交车，第几辆来的才是你要坐的那一路？ 给客户打电话，打到第几个才终于接通？ 刷短视频时，刷了多少条才刷到自己想看的内容？ 这些场景背后，都藏着一个共同的概率模型——几何分布（Geometric Distribution）。 几","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F83005\u002F202609\u002F83005-20260902112922617-1277310049.png","\u002Fnews\u002F842",[18],{"id":52,"kind":7,"title":53,"summary":54,"image":14,"href":55,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":56},"NEWS_ARTICLE:884","OSS 文件上传的几个风险点和解决方案","〇、前言 OSS 作为海量数据的承载平台，一旦配置不当，可能引发敏感数据泄露、恶意文件上传、巨额流量盗刷甚至数据被勒索加密等严重后果。 了解这些风险并非杞人忧天，而是帮助开发者和运维人员在使用 OSS 时建立正确的安全思维——从凭证管理、权限控制、访问策略到上传校验，每一个环节都可能在疏忽中成为攻击","\u002Fnews\u002F884",[18],{"id":58,"kind":7,"title":59,"summary":60,"image":61,"href":62,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":63},"NEWS_ARTICLE:892","zg 正式开源：本地检索，不止于关键词","🚀 zg（zvec-grep）正式开源！\n　\n我们打磨了一款面向人与 AI Agent 的「本地检索工具」——  \n默认在本机完成索引与检索，既能理解模糊意图，也保留 rg 的精确与高效。\n　\n🔒 本地优先：文件处理、索引和检索均在设备内完成，代码与文档无需上传，保护隐私与数据安全。\n　\n⚡️","https:\u002F\u002Fintranetproxy.alipay.com\u002Fskylark\u002Flark\u002F0\u002F2026\u002Fpng\u002F24957442\u002F1786498962962-a148a454-6626-4fdc-81ff-e95a9f71c9cd.png","\u002Fnews\u002F892",[18],{"id":65,"kind":7,"title":66,"summary":67,"image":14,"href":68,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":69},"NEWS_ARTICLE:899","C# U9 二次开发","U9 是用友 U9 Cloud，基于BEAS 开发平台，底层 C# + .NET Framework，服务端是 IIS+WCF，数据库 SqlServer；二次开发分：插件扩展、WebService 接口、单据扩展、自定义页面、外部程序调用 U9 接口。 ⚠️ U9 二次开发不建议直接修改 U9 原","\u002Fnews\u002F899",[18],{"id":71,"kind":7,"title":72,"summary":73,"image":74,"href":75,"meta":76,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":77},"NEWS_ARTICLE:827","MHS 三部曲（下）：谁允许 AI 行动？——权力、合规与中国厂商的答卷","我们总在等待一个像 ChatGPT 那样的机器人时刻。但具身智能真正的拐点，也许先发生在更不起眼的地方：一台陌生设备，第一次能把自己的能力、状态和边界完整告诉 AI；一个 Agent，第一次能把试出来的经验固化成可验证、可复用的机器技能。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202608\u002F510-20260830153745229-1536981088.jpg","\u002Fnews\u002F827","2026 · 人工智能",[78],"人工智能",{"id":80,"kind":7,"title":81,"summary":82,"image":14,"href":83,"meta":17,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":84},"NEWS_ARTICLE:829","我不会美工，用 WorkBuddy 1 分钟做出 4 张海报","先说结果：下面这 4 张海报，从我发出指令到拿到图片，大约 1 分钟。 我不会美工，也没有打开 Photoshop。用的工具，是我之前用 WorkBuddy 做的一个海报生成器。这个生成器本身也没花几分钟，具体开发过程我在上一篇文章里写过。 这次我把海报生成器的网址、产品截图和要求一起发给 Work","\u002Fnews\u002F829",[7,8],{"id":86,"kind":7,"title":87,"summary":88,"image":89,"href":90,"meta":17,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":91},"NEWS_ARTICLE:828","一个人抵一个团队的时代，企业级 AI Agent 还需要做什么？","对于企业而言，真正需要的，不是一个“会聊天”的 Agent，而是一套能被多用户、多场景复用，且权限清晰、过程可审计、成本可控制的 Agent 能力体系。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2232255\u002F202609\u002F2232255-20260902173524728-659996478.png","\u002Fnews\u002F828",[7,8],{"id":93,"kind":7,"title":94,"summary":95,"image":14,"href":96,"meta":97,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":98},"NEWS_ARTICLE:832","用 runtime-async 写一个支持 async\u002Fawait 的轻量脚本引擎","起因：一个好奇 事情的开头很简单。 给 .NET 做过动态脚本的人大概都碰到过同一堵墙：表达式树也好、Reflection.Emit 也好，都很难支持 async\u002Fawait。原因不在语法，而在 await 的实现方式——C# 编译器要为每个 async 方法生成一个状态机结构体，把方法体切成若干片","\u002Fnews\u002F832","2026 · 软件开发",[99],"软件开发"]