大家好，我是汤师爷~

概念模型设计是促销系统开发的关键环节，我们需要基于之前的功能分析，将复杂的促销业务拆解成清晰的领域概念，这些概念之间的关系界定和边界划分，将直接决定系统的可维护性和扩展性。

促销系统核心概念模型

通过对促销业务的分析，我们可以抽象出促销系统的关键概念模型。

1、促销活动模型

促销活动模型对活动的各个要素和规则进行抽象，包含活动名称、描述、时间、类型和状态等基本属性。

2、优惠券活动模型

优惠券活动是一种特定的促销活动类型，通过发放优惠券吸引消费者购买商品并提升品牌忠诚度。该模型包含活动名称、时间、发放数量限制和券总量等属性。

3、活动叠加互斥规则

该规则定义了促销活动之间的组合关系，某些优惠不能与其他优惠同时使用（互斥），而某些优惠可以与其他活动一起使用（叠加）。

4、优惠模型

优惠模型是对商家提供给消费者的福利的抽象，可以是折扣、固定金额减免等。一般来说，消费者必须满足特定行为才能享受到。

1）为何抽象出一个“优惠”模型

优惠规则通常是促销活动的一部分，为啥不能合并到活动模型中，需要抽象出一个“优惠”模型？主要有以下考量因素：

• 业务关注点不同：虽然优惠规则通常是促销活动的一部分，但促销活动本质上是对客户的一种行动号召，并承诺客户满足特定行为，就能给予优惠。促销活动主要关注如何吸引消费者参与，可能包含推广、营销策划和销售目标制定。而优惠是客户实际享受的具体折扣、返利、积分累积或其他福利。
• 灵活性和扩展性：将优惠作为一个独立模型，可以更灵活地扩展促销系统。例如，新增一个促销活动”会员专享优惠“，只需基于现有的优惠模型，设置会员专享的优惠门槛和优惠内容即可，不影响现有的优惠处理逻辑。此外，优惠不仅可以来源于促销活动，还可以来源于其他场景，例如会员等级成长所带来的优惠。
• 简化会计和财务处理：从会计和财务角度看，不同促销活动的处理方式可能完全不一样，将优惠模型独立出来，也是为了简化会计和财务处理，针对不同的优惠模式、优惠级别，进行标准化的处理。

2）优惠级别

优惠级别分为商品级、订单级、权益级，这些级别定义了优惠价值如何被分配和应用。

• 商品级：优惠价值应用于符合优惠门槛的单个商品或多个商品。例如，买一送一场景，优惠金额减免会直接应用于这些买赠的商品上。
• 订单级：优惠价值应用于整个订单，通常是基于订单总价来计算，同时之前应用的商品级价格也会跟着减少。
• 权益级：优惠价值应用于一个权益账户，通常只适用于延迟赠送的奖励。例如，消费者因为下单支付而获得积分，这些积分累积在账户中，可以在未来用作折扣或兑换商品。

3）优惠模式

优惠模式分为立享、抵扣、返还模式。

• 立享：在交易过程中立即兑换优惠价值，如满减、满折、满赠等。
• 抵扣：之前积累的优惠价值，在后续交易订单的最终支付金额上提供抵扣，如使用优惠券、余额、红包、积分等。
• 返还：基于订单的实付金额或特定策略提供返利，可在未来购买时使用，如满返积分、满返优惠券等。

5、优惠内容

详细说明优惠的具体内容，优惠内容可分为：价格替代、折扣、固定金额减免、运费减免、积分/优惠券返还及其他奖励。

6、优惠门槛

消费者享受优惠需要达到的条件，门槛类型包括商品相关（特定商品、品牌、分类）、购买数量、金额、销售渠道、客户相关（特定客户账户、会员等级）、特定支付方式等。

7、优惠券模板

用于创建具体优惠券的基本属性和规则，模板定义了优惠券的基本属性，如名称、有效期、使用门槛、可用次数限制等。

8、客户优惠券实例

客户优惠券实例是客户领券后，根据优惠券模板生成的具体优惠券实体。

9、客户权益账户

记录和管理客户在商家下的积分、红包等权益的账户，通常用于追踪顾客的购买历史、积分累计和兑换等。

基于上述核心概念模型，下面将讲解促销计价的处理逻辑。

活动叠加互斥规则

活动叠加互斥规则用于控制多个促销活动是否可以同时生效。针对同一商品或订单，系统需要判断是否允许多种优惠叠加。若只允许一种优惠生效，称为互斥；若允许多个优惠同时生效，则为叠加。以下是常见的叠加互斥规则：

1、单品级组内互斥

单品级组内互斥规定同一商品只能享受一种优惠。比如某商品同时参与"一口价"和"限时折扣"两种促销，活动生效时，只能选择其中一种，这样可以防止单个商品优惠力度过大，避免商家利润受损。

2、订单级组内可以共享

订单级组内共享是指允许多个基于订单总额的活动同时生效，如"满减"、"满折"、"满赠"等订单维度的促销活动。

举例来说，消费者下单金额为120元，同时满足"满100减10"和"满100赠5元券"的条件。在订单级允许共享的情况下，这两个优惠可以同时享受。

如果商家希望控制优惠力度，也可以将"满减"和"满赠"设置为互斥，但这会降低促销的灵活性。

3、配送费组内互斥

配送费组内互斥是指限制配送费促销活动只能生效一种，以防止配送费优惠过度。例如"配送费减5元"和"配送费减半"这类优惠只能二选一，不能叠加使用，这样可以避免商家承担过高的运费成本。

活动命中规则

活动命中规则决定当商品或订单同时满足多个活动条件时，应该使用哪个活动。

"叠加互斥规则"解决了"是否可以叠加"的问题，而"命中规则"则解决了"不能叠加时选哪个"的问题，它帮助系统选择最适合且最有利于商家的活动方案。

活动命中规则并无统一标准，需要根据具体业务场景来制定。运营团队通常会从优惠力度、活动优先级和活动有效期等方面来确定活动的优先顺序。

1、按优惠金额优先

当系统以"优惠金额最大化"为导向时，会根据促销活动的实际让利金额来确定优先级。例如，某商品原价10元，可享受7折或限时特价5元两种优惠。因为7折优惠3元，而特价优惠5元，系统会选择限时特价方案。

2、按活动优先级排列

部分商家会通过后台配置活动优先级，系统按优先级从高到低依次判断。例如，新品推广活动的权重高于常规促销，系统会优先采用新品活动。

3、按时间先后

按时间先后的活动命中规则主要考虑两个因素：

• 活动创建时间：系统优先选择较早创建的活动，确保原有活动得到充分利用。
• 活动结束时间：系统优先考虑即将到期的活动，以充分利用活动资源，避免名额或预算浪费。

例如，当商品同时满足两个活动条件时，若其中一个活动将在24小时内结束，另一个还有一周有效期，系统会优先使用即将结束的活动，确保临期活动能被及时使用。

优惠计算顺序

优惠计算顺序决定了多个活动在同一订单中的计算先后顺序。这个顺序直接影响最终订单价格。例如，先计算折扣再计算满减，与先计算满减再计算折扣，最终结果可能会有显著差异。

优惠计算的常见顺序如下：

1. 先计算单品优惠，这会直接改变商品的结算价格。
2. 然后计算订单级优惠，因为需要根据商品的最终单价来判断是否达到优惠门槛。
3. 最后处理返还类优惠，比如"支付后返积分"需要用户完成支付才能触发。

部分商家可能会根据运营需求灵活调整这个顺序以提高转化率。无论采用何种顺序，关键是要确保计算逻辑清晰、避免歧义，并保证结果可以准确复现。

优惠分摊

优惠分摊是指将活动优惠金额按比例分配到各个享受优惠的商品上，从而在数据统计或退款时能准确计算出每件商品获得的实际优惠金额。

常见分摊公式：商品优惠金额 = 总优惠金额 ×（商品金额 / 参与优惠的商品价格总和）

1、分摊要点

首先要确定参与分摊的商品范围，未参与优惠的商品不应参与分摊。

将优惠按商品金额从小到大依次分摊，并将最大金额商品作为最后一件，以确保优惠金额能完全分配完毕。

对于舍入和尾差，当分摊金额出现小数时，需要明确四舍五入的规则，并将尾差加到最后一件商品上，确保分摊总额与实际优惠金额相符。

2、分摊示例

假设用户购买A、B、C三件商品，单价分别为20元、30元、40元，总价90元。参加"满80减20"活动，总优惠20元。

A商品分摊金额：20 / 90 × 20 = 4.44元

B商品分摊金额：30 / 90 × 20 = 6.67元

C商品分摊金额：40 / 90 × 20 = 8.89元

为确保数据准确，最终分摊总额必须等于20元。如遇四舍五入误差，可将尾差计入C商品或最大金额商品中。

本文已收录于，我的技术网站：
tangshiye.cn
里面有，AI 编程、算法 Leetcode 详解、面试八股文、BAT面试真题、简历模版、架构设计，等经验分享。

今天给大家推荐一个
双语对照的 PDF 翻译工具
的开源项目：PDFMathTranslate 。

项目介绍：

基于 AI 完整保留排版的 PDF 文档全文双语翻译，支持 Google/DeepL/Ollama/OpenAI 等服务，提供 CLI/GUI/Docker 。

项目亮点：

• 基于 AI 布局分析和 PDF 指令流分析实现对文档排版的完整保留 ；
• 保留行内/行间公式和图表样式，对 Latex 文献进行特殊优化；
• 保留文档可索引目录结构 ；
• 支持 Google、DeepL 和 OpenAI 等多种翻译服务 。

预览效果：

快速开始

1、确保服务器安装的 Python 版本大于 3.8 且小于 3.12 ;

2、安装此程序 ;

pip install pdf2zh

3、打开 GUI 界面 , 访问：
http://localhost:7860/

pdf2zh -i

4、上传文件并翻译

如上图，我们上传一个英文版 PDF ，上传完成后，在预览区域会显示 PDF 的内容。

接下来，选择翻译服务 Google、Bing、zhipu、Tentcent 等和翻译方向（英文转中文），

最后点击翻译按钮即可。

当然，我们也可以使用 命令行直接翻译：

pdf2zh raft.pdf

基本原理

核心流程：

1、上传文件后，通过 AI 模型 DocLayout-YOLO-DocStructBench-onnx 解析文档格式 ；

2、调用翻译服务 Google 、智普、Bing、DeepL、OpenAI 等开放平台的服务 ；

3、将数据流整合在一起并输出到目标 PDF 。

参考资料：

https://huggingface.co/wybxc/DocLayout-YOLO-DocStructBench-onnx

我们与大语言模型交互时，往往给出的提示过于简略，而大语言模型还没有达到能够准确猜测你意图的程度，这个时候大模型并不能立即反馈出令人满意的答复，此时，我们需要做的是对大语言模型进行迭代式提示，这个迭代可以反复推进，直至大语言模型给出了令人满意的答案。
比如，某款智能灯箱产品需要一篇营销文案，而当前我们已经获得了该智能灯箱的产品介绍，下面我们看看如何让大语言模型利用这灯箱的产品介绍生成我们需要营销文案。
提示词：
以下是一个产品的相关技术信息，请根据这些信息生成一份产品的营销文案。
```
IUBIOT灯箱安全监控产品：
采用物联网技术， 针对灯箱（ 如大型招牌、广告灯箱、发光字等设施） 的运行安全进行实时监管， 防止灯箱因电气原因导致的起火等安全事故。
1.采集与监测灯箱的工作状态，实时故障报警。
2.过载、短路自动切断电源，保护灯箱安全。
3.通过手机远程对灯箱的开关时间、亮度进行调节控制。
4.可选配温湿度监测、线温监测、位移监测、烟雾感应报警等功能。
5.通过实时运行参数，对故障进行初步定位。

产品特征：
本方案通过各类传感器采集灯箱环境及工作参数，并通过无线方式将数据传递至智能灯箱管理云平台，灯箱管理维护人员可通过PC浏览器或手机APP实时查阅灯箱的状态及相关统计的可视化数据。灯箱发生异常时，手机APP可以实时收到对应的异常消息或警报，无论灯箱管理维护人员在何地，均可及时获知灯箱状态。灯箱管理维护人员可通过PC上浏览器或者手机上的APP对智能灯箱执行远程操控，随时随地控制灯箱，实现远程维护及管控。

应用场景：
机场：吊装航显、落地航显、侧装标识、壁装标识、综合引导、龙门架。
地铁：12封灯箱、4封灯箱、6封灯箱、通道灯箱、长廊灯箱、月台灯箱。
门店：门头灯箱、发光字、货架灯箱。
商场：户外标识、立体灯箱、悬挂灯箱、贴墙灯箱、展架灯箱、综合引导。
路边：路名牌、引导牌、公交站牌、广告灯箱、墙体灯箱。
产品组成：
产品采用模块化设计， 根据实际需求灵活搭配， 快速组装， 即时实施， 作业时间短， 迅速投入使用。
硬件：智能物联灯箱控制器（必选），调光控制器、温湿度传感器、烟雾传感器、位移传感器、线温传感器（可选）。
软件：web管理端，监控、管理整个平台；手机端，方便实施人员定位、检修设备。

智能物联灯箱控制器 RL-GW-01S：
RL-GW-01S 是一款适用于灯箱的智能物联控制器，可以采集和监测单个灯箱的相关工作参数和状态。
远程对灯箱进行控制，并把相关的数据信息通过4G无线模块上传到云端后台服务器，并接收服务器的控制指令。
220V供电，最大可控负载6kW，配合RL-DIM-01调光控制器可实现调光节能效果。
还可灵活适配温湿度传感器、位移传感器、烟雾传感器、线温传感器来增加监测和报警功能。

调光控制器 RL-DIM-01：
RL-DIM-01 是一款需通过RS485或者Zigbee连接到智能物联灯箱控制器使用的调光控制器，可以实现调光节能效果。
单模块可供功率200W，可控电压12V或者24V。
```
大语言模型对上述提示词的回复一般较长，文新大模型3.5给出的回复如下：
IUBIOT灯箱安全监控产品——点亮安全，智护光明
在现代城市的每个角落，灯箱都是不可或缺的风景线。但灯箱的运行安全问题，却常常被忽视。IUBIOT灯箱安全监控产品，用科技守护光明，为您的灯箱安全保驾护航。
产品特色
1.实时监控：无论是大型招牌、广告灯箱还是发光字，我们的产品都能实时采集其工作状态，确保一切正常运行。
2.智能报警：一旦出现异常，系统会立即进行故障报警，并通过手机APP推送消息，确保您在第一时间得知。
3.智能切断电源：过载或短路时，系统会自动切断电源，防止火灾等安全事故的发生。
4.远程控制：通过手机APP，您可以随时随地调节灯箱的开关时间、亮度，让管理更加便捷。
5.多功能监测：除了基本的工作状态监测，您还可以选配温湿度监测、位移监测等功能，全方位保障灯箱安全。
应用场景广泛
机场：确保航显灯箱的安全与准确运行。
地铁：为各类灯箱提供稳定的运行保障。
商场与门店：守护您的品牌标识，确保安全无虞。
快速部署，智能管理
模块化设计：根据实际需求，选择合适的模块，快速组装、实施。
智能硬件与软件：智能物联灯箱控制器与调光控制器完美配合，实现高效管理。
选择IUBIOT，选择专业与信赖。让科技与安全，点亮每一个美好的夜晚。
上面这段回复作为营销方案显然太长了，估计没有几个人有耐心看完，所以此时，我们可以要求模型压缩文案的长度，通常在对话中直接补充新的要求就可以了。

可以看到，模型迅速对我们的要求进行了响应，将原来洋洋洒洒的文案改写到仅有48字（IUBIOT视为一个字）。这段文字简洁地说明了智能灯箱产品的主要功能与特色，最终用户可以通过这段文字快速了解这款产品。但是我们假设在现实世界中，智能灯箱通常需要通过系统整包集成商销售，最终用户很少直接采购，那上面这段文字就不太适宜了。所以我们需要继续迭代提示，我们告诉模型文案面向的真正的读者，以及系统整包集成商关注的重点，再进行一次迭代。

新生成的文案技术的味道多了一些，但是显然还不够，面向系统整包集成商介绍产品时，一定要列出产品的具体信息，以及这些产品本身的介绍，否则集成商无从采购。因此我们需要向模型提出新的要求，为了便于我们使用，甚至可以要求模型直接以特定格式（比如准备在网页上介绍产品，其格式应为HTML）返回结果。
在对话框中继续输入以下提示，再进行一次迭代：
面向系统整包集成商还需要列出具体的产品。请用一个表格，提供具体产品的信息。表格应该有两列。第一列包括产品的名称，第二列包括产品的简要说明。给表格命名为“产品列表”。表格线宽度为1磅。将所有内容格式化为可用于网站的HTML格式。将描述放在

元素中。
模型这次的响应严格遵循提示中的要求，它给出一段整洁漂亮的HTML代码，其截图如下：

将上述代码存为HTML文件，使用浏览器打开后，一个合乎要求的产品列表直接跃入眼帘。

至此，我们已经获得了面向系统整包集成商的营销文案，看起来这个文案似乎不错。当然，一名专业的营销人员或许还会有更多的要求或想法需要模型去完成，那他/她可以继续迭代，直至得到满意的答案为止。

去年我写了一篇也是讲
开源商业化
的文章，
当时是月入 30 万，一年过去了，我们整整涨了 5 倍多
。本文理论结合实践，比较干货，希望对大家有帮助。

我们的现状，谁在给我们付钱

第一，开发者
，我们已经近 20 万用户了，而且随着
Sealos Devbox
的发布，活跃用户和付费用户飙增，广受用户好评，且用户已经形成了自发性的传播。其实云计算不是一个赚快钱的赛道，有那么多巨头在，而且需要长期积累，我们今天的成就是一个非常非常非常小的还不错的开始。

开发者是非常重要的群众基础，虽然开发者的付费能力有限 (特别在当前的中国)，我们从刚开始就没直接去切 B 端用户，因为我们想做一款东西让真正在使用它的人舒服，效率提升而不是通过搞定企业的决策者，自顶向下做 toB 的生意。

我们要做一个大生意，品牌建立起来，同样是离不开开发者这个群体，所以 Sealos 能做成的牢牢的基石就是服务好开发者，做出让开发者认可的产品。另外，由于我自己是个十多年老码农，太理解开发者的痛苦了，而且我还很擅长把复杂的东西简单化，这让我们获得了非常多开发者认可。

所以很多开发者给我们充值十几二十块，这完全符合我的预期，
营收占比很小，但是潜在价值巨大
。

第二，中小 B
，第二个符合我预期的事就是，一旦开发者足够多了，就会逐渐有一些小 B 开始用我们的产品，这几乎是一个顺其自然的事，因为小 B 决策路径很短，开发者图便宜和省事就直接用我们的了，然后费用超过一定值时肯定就不想自己掏腰包了，就去找领导，领导一开始可能也有点担心，觉得稳不稳定会不会跑路什么的，然后一看哦 Sealos 开源做的还不错，那试试吧，一试不要紧，后面就离不开了，发现我们不仅好用而且支持还特别给力，几乎是一对一拉群支持，这也是早期吃螃蟹用户得到的额外好处，我们充当了他们的稳定性保障和运维团队了。我们团队又非常会通过技术手段收敛问题，实际支撑大部分问题都会在产品和技术层面解决掉。

这部分用户贡献了公有云收入的大头，里面不乏一些非常优秀的创业公司，如有
千万玩家的
开心自走棋
，匆匆雪工作室，joyjoy games，
优秀开源项目 Teable
等等，这样的公司我们
服务了一千多家
！未来他们成长我们就成长，而且这些公司也会吸引更多同类公司，他们深知使用我们之后基础设施几乎成本降低了 80% 这非常夸张，效率也不知道提升了多少倍，最重要是总算告别了恶心。

第三，大 B 用户
，令我意外的是大 B 来的如此之快，
我预期云这个东西不干个五年可能大 B 都看不上我们，但是事实是非常多大 B 主动找上我们，这和我们在开源社区的影响力分不开，毕竟
Sealos
和
FastGPT
都是非常出名的开源项目了
，再配合上企业自己的调研基本上很容易促成合作，甚至大部分面都没见就打款了。我大部分拜访的客户，但凡确实有匹配需求的，无一例外全部选了我们。我们服务了像零跑汽车，雪花啤酒，克诺尔，欧派家居，绿联，AO 史密斯，伊利集团，雅迪电动车，高驰等一众大 B 用户。

触客，安全感与信任

我们到目前为止几乎都没有销售人员
，我们的触客成本极低，大部分是客户主动找我们的，这如果不开源，没有品牌效应，没有知名度的影响几乎不可能。今天的影响力几乎都是社区自动产生的，如果不开源各种博主 up 主是不太可能主动免费给我们做宣传的。不是说必须得开源才会这样，而是同等条件下，开源更容易被传播。做好一个开源项目是技术公司品牌传播最快速的方式，难的是怎么做好一个开源项目。

“小公司挂了怎么办？” “至少我们还有源代码”，所以开源是可以给客户更多的安全感的。

信任基础，建立信任其实是非常困难的，但是一个优秀的开源项目，可能客户看到第一眼就倾向于去信任，我们去购买别的产品也一样，对于不熟悉的东西开始时一定是质疑的，如果不开源你需要花很大代价与客户建立信任。

我想打你，打不过你，我先开为敬

比如 Llama 要打 OpenAI，效果虽然差点，但我开源，一样可以分到一些流量。和你的竞争对手竞争时，他如果先发，咱就可以开源，如果能倒逼对手也开源那也不见得是坏事。

开源与免费

做开源大家最为忌讳的就是用户不付钱的矛盾，特别是害怕开源做的越优秀越稳定付钱的越少，这个确实不好解决，核心是得想清楚模式，想清楚谁在付费，想清楚场景。

很多开源产品选择了区分开源版与商业版，在开源版中有所保留。这不算是个高明的做法，因为本身要做出一款优秀开源软件就是需要使出全力的，如果还有所保留，项目本身就挺难成功
。此外对积累口碑也不是很好，大家只会觉得你以开源为幌子，引流而已。立场不同，公司又得生存，有时也是迫不得已。

所以我觉得或许可以整一个对商业化友好的开源协议，因为大部分大公司还是重视合规的，这样开源产品可以尽情开源，开发者长尾用户也能免费，项目会得到良性的发展。

Sealos 就无这个问题，也不去区分开源版和商业版
，原因有几块：

第一，
商业模式是云服务
，也就是大部分想用我们产品的人是懒得自己搭建的，而且自己搭建一定更贵。

第二，有部分学习的人会去搭建，这部分
个人居多，那免费也就免费了，没什么问题
。

第三，私有云偏大客户居多，他们要的是服务，是稳定性，是兜底能力，且 Sealos 能给他们带来的价值，或者节省的成本是付出的很多很多倍。大企业用我们保守估计每年都可以节省千万级的基础设施成本。还有就是采购我们比他们自己维护便宜且专业。决策者最基本的技能就是算 ROI，这些账都是能算过来的。

所以一旦选择了开源，那必然要接受一部分用户和一部分场景免费。靠服务赚回来，云服务和私有化支持服务都属于服务。

如何通过开源实现商业化

开源商业化是个门槛挺高的事，我们做过挺多还不错的开源项目，这里有一些思考希望对大家有帮助。

1. 挖掘需求

比较简单的一种发现需求的方式是发现自己的需求
，或者身边人，或者自己公司的需求，其实挺多的，让我们觉得挺麻烦的事都是需求，我随手都可以列出好多，比如：我现在处理发票挺麻烦，简历的分析挺麻烦等等。

第二件事去
搜这个需求有没有比较好的方案
，如果别人的方案还不错了，甚至有很多好方案了，那就不太需要你去做，比如笔记的需求，Notion 和 AFFINE 做的都很好，你没有信心做的比他们更好，那就不做这个。你发现竞品一些明显缺陷，那可以考虑做。或者发现一些好产品没开源，你做开源替代也可以。

第三件事是
评估这个需求的价值
，基本是
价值 = 体量 * 单价
，单价就是对每个使用者或者公司的价值，比如做个笔记软件大概评估一下用户可能平均原因付 5 刀/月。然后是分析受众，有些人确实发现了一些需求，但是太小众，而且这个小众群体原因为之付费也很低，这就不利于开源商业化。所以可以用这个去为需求评分，看值不值得做。这其实和创业一样，就是评估天花板在哪。这不需要太准，但是得有个大概判断：雷总说太阳打西边出来你能做多大。

2. 把项目做出来

项目早期特别是你还没啥影响力时基本就是靠自己，或者若干志同道合朋友，这确实是需要强执行力，大部分能成的项目都是能进入一种状态，就是你发现
有时间就想去写代码，不写浑身难受，我在写 Sealos 时就是这样，基本晚上 8 点到 12 点都在写，进入一种入定状态，也会感觉非常充实
。如果你没有这种感觉，那比较危险。也就是做这件事的时候不会感觉压力大，而是充实，快乐，且自豪就对了。

3. 运营，让别人知道你的项目

早期你是没有任何资源的，非常简单粗暴的运营方式：
写博客，然后各种群里 “恬不知耻” 的推广发消息
，大部分群对开源项目的推广不会那么反感，即便做的不好被人鄙视也不要害怕，虚心请教然后改进，Sealos 早期也不少被骂，即使到现在也还有零星的差评。

积累到 500～1000 star 左右基本会有一些自传播效应了，核心还是项目做的不错确实解决了一些需求。当然如果你视频做的不错的话效果会更好，做视频写博客写代码都一样要注重质量，一个精品顶 1000 个普通内容。

4. 商业模式

第四件事是想清楚模式，当然这个不是特别着急，等项目做到一定程度再去想商业模式也可以，比如 Sealos 早期就在卖安装包，后面才提供云服务。

当项目能赚到一点点钱的时候可以考虑全投出去，比如在开发方面去激励开源社区的开发者，在运营方面去投广告等。这样不断形成良性循环，我一直是觉得
商业化是有益开源项目发展的，如果没有商业化 Sealos 不可能发展这么快
。

开源项目创业

项目还可以，还能赚到钱，起点就挺不错的，可以考虑去好好写好商业计划去融资，这里又要推荐一下奇绩创坛了，是个非常理想主义的孵化器，陆奇博士确实是在为孵化科技企业努力做贡献的，而且创业者优先，谁都可以申请。这不是广告，而是真心强烈推荐。

聊融资有几个建议点：

1. 一开始不用追求大机构或者高级别的人聊，因为在开始时很多基本问题其实你自己肯定都没全想清楚，多被挑战是好事，等自己聊明白了再去找你认为重要的机构和投资人聊。怎么接触他们很简单，所有的官网都可以投 BP，人家对你感兴趣自然会联系你。
2. 所以一个好的 BP 也非常重要，我觉得
   不需要长篇大论，也不需要精美，而是需要把事情讲清楚
   ，一针见血，投资人看到你的 BP 瞬间感觉有了新的认知那大概率会对你感兴趣。
3. 不要害怕被拒绝，不被拒绝个 100 次都不叫融资
   ，我们在天使轮的时候我一周聊了 50 多投资人，一天 8 个的强度，没一个愿意投的，此时一点都不用灰心，认真听他们的反馈并改进你的 BP，在这个过程中项目不能停，要不断完善，做出新的成绩。
4. 做好最坏的打算，拿不到钱也得继续，办法总比困难多，
   项目唯一可能失败的原因就是创始人自己丧失信心
   ，我们永远都在资源匮乏时把事做成。

以上一步一步做完，那么恭喜你，游戏的第一关新手营你通关了，后面任重而道远，但这才有趣不是嘛。
踏上取经路比到达西天更重要
，我也刚出新手营，其他东西等以后积累更多经验再给大家分享，最后祝大家 2025 元旦快乐。

推荐一个轻量级的任务调度开源项目。

01 项目简介

Coravel是一个.NET开源任务调度库，只需简单代码、几乎零配置就可以实现多种功能柜，如任务调度、队列、缓存、事件广播和邮件发送等。该项目特点就是让这些通常复杂的功能变得易于访问和使用，同时提供简洁、直观的语法。

02 核心功能

1、任务/作业调度：
通过其流畅的代码内语法，让你能够轻松地在应用程序中设置和管理这些任务。

2、队列：
提供了一个开箱即用的队列系统，它使用内存作为后端来异步处理任务，从而不会阻塞用户的 HTTP 请求，改善了应用的性能和用户体验。

3、缓存：
为了提高应用程序的响应速度，Coravel 提供了一个简单易用的缓存 API。默认情况下，它使用内存缓存，但也支持数据库驱动（SQL Server、PostgreSQL），也可以自定义扩展缓存接口，以适应更复杂的缓存需求。

4、事件广播：
可以构建松耦合的应用程序组件，这有助于提高应用程序的可维护性和灵活性。

5、邮件发送：
简化了邮件发送过程，提供了内置的电子邮件友好的 Razor 模板、简单灵活的邮件 API，并且支持渲染电子邮件以进行视觉测试。此外，它还支持 SMTP、本地日志文件或自定义邮件器驱动程序。

03 使用示例

1、安装依赖库

dotnet tool install --global coravel-cli

2、任务调度

//启用
services.AddScheduler();

var provider = app.ApplicationServices;
provider.UseScheduler(scheduler =>
{
    scheduler.Schedule(
        () => Console.WriteLine("工作日每一分钟执行一次。")
    )
    .EveryMinute()
    .Weekday();
});

3、队列

IQueue _queue;

public HomeController(IQueue queue) {
    this._queue = queue;
}

//使用队列
this._queue.QueueAsyncTask(async() => {
    await Task.Delay(1000);
    Console.WriteLine("这是队列!");
 });

4、广播

var provider = app.ApplicationServices;
IEventRegistration registration = provider.ConfigureEvents();

//注册和监听
registration
  .Register<BlogPostCreated>()
  .Subscribe<TweetNewPost>()
    .Subscribe<NotifyEmailSubscribersOfNewPost>();

5、发送邮件

using Coravel.Mailer.Mail;
using App.Models;

namespace App.Mailables
{
    public class NewUserViewMailable : Mailable<UserModel>
    {
        private UserModel _user;

        public NewUserViewMailable(UserModel user) => this._user = user;

        public override void Build()
{
            this.To(this._user)
                .From("from@test.com")
                .View("~/Views/Mail/NewUser.cshtml", this._user);
        }
    }
}

04 项目地址

https://github.com/jamesmh/coravel

更多开源项目：
https://github.com/bianchenglequ/NetCodeTop

- End -

推荐阅读

推荐一个C#轻量级矢量图形库

.NET日志库：Serilog、NLog、Log4Net等十大开源日志库大盘点！

推荐5个.Net版本 Redis 客户端开源库

ImageSharp：高性能跨平台.NET开源图形库

盘点3个.Net热门HTTP开源库