想象这样的场景：深夜，你在 IDE 里敲下公司核心算法逻辑，或是撰写未公开的商业计划书。为了提高效率，你习惯性打开 AI 助手润色代码、补全文档，效率确实提升不止一倍。但你是否曾突然背脊发凉：这一行行敲进去的代码，究竟去了哪里？
2026 年的今天，这不再是杞人忧天。随着 DeepSeek 等开源模型爆发，我们发现一个惊人真相：AI 越来越强，吞噬数据的黑洞也越来越大。今天，我们就来聊聊 AI 无处不在的时代，如何打响主权 AI 保卫战，以及为什么 Codigger 这样的平台会成为这场战役的兵工厂。
一、我们是如何沦为 “数据矿机” 的？
过去几年，我们默认接受了一种交易：科技巨头提供免费或廉价的 AI 服务，作为交换，我们不仅支付订阅费，还无偿贡献了自己的数据。每一次 Tab 键补全，每一次 Prompt 输入，实际上都在喂养那个巨大的中心化模型。
直到 DeepSeek 效应出现，行业风向转变。人们惊讶地发现，原来不必把数据上传给巨头，也能拥有顶级智能。但即便模型开源，若仍使用传统云端工作流，数据依然在裸奔。云厂商的服务器就像巨大的透明玻璃房，你的代码、创意、隐私，在后台管理员眼中可能只是一串串待收割的训练数据。
这时，主权 AI 的概念应运而生。简单来说，就是我的算力我做主，我的数据不出门。

二、拿回钥匙：Codigger 的 “物理隔离” 哲学
这也是最近技术圈频繁讨论 Codigger 的原因。它不像传统云服务商那样想方设法吸走你的数据，反而想帮你把数据锁起来。Codigger 的核心理念是 “Total Sovereignty”，原理类似生活中的保险箱。
给数据穿上 “隐身衣”：在 Codigger 的 SIDE 编辑器写代码时，你不再向云端发送明文请求。其引入的加密分片技术，就像把机密文件放入碎纸机切成无数碎片，再将这些碎片分别锁进全球各地不同的、只有你有钥匙的保险柜。除非你亲自授权，否则没有任何单一节点（包括 Codigger 平台本身）能拼凑出完整数据。这种物理级别隔离，彻底切断了被 AI 巨头偷看的可能。
在 “自家后院” 训练 AI：以前想训练或微调适合自身业务的 AI 模型，需把数据上传到云端 GPU 集群，如同把传家宝送到闹市区展示，风险极大。而 Codigger 的按需计算改变了这一现状。你可以调用强大算力资源，但这股算力是流向你的私有环境的。数据纹丝不动，算力却源源不断，就像在自家后院用租来的挖掘机挖矿，挖出来的金子全归你，挖掘机主无权过问。

三、既要安全，也要变现？
提到主权和隐私，很多人会担心：是不是会变成一座孤岛？还能分享数据赚钱吗？这正是 Web3 时代最迷人的地方。
Codigger 提出了有意思的数据市场玩法。你拥有数据绝对主权，但不代表不能利用它获利。你可以对数据进行脱敏处理，在不泄露核心隐私（比如源代码细节、用户隐私信息）的前提下，将数据的特征或逻辑打包，授权给需要训练 AI 的买家。
这就像你拥有米其林餐厅的秘方，不必直接公开，却能卖给别人基于这个秘方调配好的酱汁。你依然拥有秘方，还能赚到酱汁的钱。

四、做用户，还是做 “领主”？
2026 年，AI 已成为像电力一样的基础设施。但我们必须警惕，不要让这股电力反噬我们。主权 AI 不是为了反技术，而是为了让技术更体面地服务于人。
Codigger 正在构建的，不仅仅是分布式云工作站，更像是一场开发者对自己数字命运的收复运动。在这里，你不再是默默为大模型贡献养料的数据矿机，而是拥有自己算力、掌控自己数据疆域的领主。
下一次，当你敲下一行价值连城的代码时，不妨问问自己：它是安全的吗？它真的属于我吗？如果答案是迟疑的，也许你是时候去 Codigger 看一看了。

行业背景

2026年2月，国产智能编程工具与低代码开发迎来规模化落地期。

织信低代码推出首个AI智能体全领域开发平台，涵盖表格智能体、数据智能体、工作流智能体、仪表盘智能体、脚本智能体、网站智能体、API智能体等10个智能体，可覆盖企业信息化所有功能需求。

同时，摩尔线程推出首个基于国产全功能GPU的AI Coding Plan智能编程服务，集成GLM-4.7代码模型与硅基流动推理加速引擎，支持代码生成、调试全流程优化，标志着国产替代在AI编程领域实现关键突破。

政策层面，《新一代人工智能发展规划》《“十四五”数字经济发展规划》明确支持AI编程工具与实体经济融合，上海、广东等地对低代码开发企业给予最高5000万元补贴，推动技术渗透。

机构预测，2030年全球AI编程工具市场规模将突破2000亿元（Polaris数据），中国低代码开发市场年复合增长率达35%（IDC报告），国产智能编程占比有望超30%。本文基于上市公司公告、行业白皮书，梳理10家A股企业在AI编程平台、低代码框架、国产大模型的核心布局，聚焦技术突破与商业化进展。

一、核心企业深度解析

1、织信Informat

产品定位：全栈国产化AI低代码开发平台

技术架构：基于自研的底层架构、支持微服务，前端Vue、后端Java，支持与众多主流软件硬件集成。AI集成了主流的deepseek、chatgpt、豆包、千问等。可以根据语言描述自动生成应用系统，数据表、仪表盘图表等。

产品亮点：织信AI低代码平台：国产化适配，复杂系统开发，AI自动开发，国内首个全栈式低代码开发平台，独创“组件+数据+流程+权限”组合开发模式，支持70%无代码+20%低代码+10%纯代码。

订单表现：2025年低代码平台收入上亿元（同比+60%），占总收入53%，客户含国家电网、吉利汽车、航天军工单位、招商局等。

2、摩尔线程

产品定位：全栈国产化AI编程服务龙头

技术架构：基于自研MTT S5000全功能GPU（国产替代核心算力），支持全精度计算与软硬件协同优化；集成硅基流动推理加速引擎（响应延迟≤200ms），采用GLM-4.7代码模型（Code Arena盲测国产第一，函数补全准确率92%）。

产品亮点：四档订阅套餐（Free Trial至Max Plan），支持Python/Java/Go等12种语言，代码生成准确率超85%；与阿里云、腾讯云合作适配云计算平台，已服务10万+注册开发者，日均代码生成量500万行。

业绩关联：2025年AI编程服务收入3.2亿元（同比+180%），占总收入12%，研发投入占比25%（重点投向GPU+大模型协同优化）。

3、金现代

产品定位：低代码+DeepSeek大模型领军者

技术突破：基于DeepSeek大模型构建低代码开发框架，支持自然语言生成业务流程，在金融、政务领域落地300+企业级应用，开发效率提升70%（人工修正率＜15%）。

产品亮点：轻骑兵低代码平台：可视化编程+国产化适配（覆盖OA/ERP/CRM），通过华为鲲鹏、统信UOS认证；

智能表单引擎：自动生成数据模型与交互逻辑，适配三表智能化改造（电表/水表/燃气表）。

订单表现：2025年低代码平台收入2.8亿元（同比+90%），占总收入35%，客户含国家电网、工商银行。

4、卓易信息

产品定位：AI编程平台一键部署技术突破

核心能力：艾普阳SnapDevelop平台支持C#/JS语言，通过多智能体协作实现代码生成，解决大模型“非生产级代码”问题，一键部署率超90%（响应速度≤1.5秒）。

商业化进展：2025年签约50+企业客户（覆盖智能制造、能源），平台日均处理代码请求10万次，与中芯国际合作开发芯片设计辅助编程工具。

业绩关联：2025年AI编程平台收入1.5亿元（同比+120%），毛利率45%（技术壁垒驱动）。

5、中科创达

产品定位：智能汽车+AI编程协同

业务布局：旗下低代码和大数据管理平台整合至操作系统+端侧智能平台，赋能智能汽车、物联网场景；与高通合作开发智能座舱AI编程工具（支持语音交互、手势控制代码生成）。

场景落地：在理想汽车、小鹏汽车量产车型中应用，2025年智能汽车业务收入25.6亿元（同比+40%），占总收入35%。

6、东华软件

产品定位：智慧医疗低代码平台

技术优势：推出“智慧医疗低代码平台”，支持HIS系统、电子病历（EMR）快速开发，与协和医院合作优化门诊流程，患者等待时间缩短30%。

订单表现：2025年医疗信息化订单4.8亿元（同比+55%），其中低代码平台占比20%，客户覆盖300+三甲医院。

7、太极股份

产品定位：政务低代码+Qwen Code融合

核心进展：低代码开发平台集成AI助手，接入Qwen Code后企业应用开发周期缩短40%；为北京市政府开发“政务服务低代码平台”，覆盖100+项政务事项，实现“零代码上线”。

政策红利：入选“信创国家队”，获政府补贴8000万元，2025年政务IT收入18.9亿元（同比+25%）。

8、宇信科技

产品定位：金融低代码+AIOps双驱动

产品矩阵：低代码开发平台、智能运维（AIOps）已在国有大行、股份制银行广泛应用；与百度合作优化信贷审批流程，审批效率提升50%。

业绩关联：2025年金融IT收入38.9亿元（同比+30%），低代码平台占比15%，毛利率32%（同比+2pct）。

9、赛意信息

产品定位：制造智能编程平台

技术突破：推出“制造智能编程平台”，支持PLC编程、工业机器人控制代码生成；与美的合作优化生产线流程，产能提升25%。

研发投入：2025年研发费用2.1亿元（同比+35%），重点投向AI编程+工业互联网融合。

10、新晨科技

产品定位：物流低代码+模型驱动架构

核心能力：低代码企业建模平台基于模型驱动架构（MDA），为物流企业提供可视化开发环境；与顺丰合作优化快递分拣流程，分拣效率提升40%。

业绩关联：2025年物流IT收入6.8亿元（同比+45%），低代码平台占比18%。

二、行业数据与政策支撑

技术参数：

GLM-4.7函数补全准确率92%（超越GPT-5.2）

国产GPU推理效率80%（对比进口芯片）

低代码平台开发效率平均提升50%-70%（赛迪顾问）。

政策驱动：

上海对AI编程工具研发给予设备投资额20%补贴（最高5000万元）

工信部要求2025年重点行业代码自动化率≥60%（《人工智能赋能中小企业发展报告》）。

市场预测：

2026年中国低代码开发市场规模800亿元（IDC）

AI编程工具渗透率从2025年25%升至2030年60%（Polaris）

国产智能编程在全球市场份额有望突破30%。

三、数据来源说明

企业动态：各产品官网公告、金现代2025年半年度报告、卓易信息投资者关系记录；

行业研究：Polaris《全球AI编程工具市场预测》、IDC《中国低代码开发市场白皮书》、赛迪顾问《AI编程技术发展趋势报告》；

政策文件：国务院《新一代人工智能发展规划》、工信部《“十四五”软件和信息技术服务业发展规划》、上海市《人工智能产业发展专项资金管理办法》；

数据时效：截至2026年2月，动态更新以企业公告为准。

观测云更新

故障中心

原“异常追踪”功能全面升级为“故障中心”。

故障中心提供一体化的故障处理支持。当监控器发现异常时，会自动生成故障事件，合并重复告警，并按值班规则通知负责人。若超时未处理，将根据升级策略扩大通知范围。在故障详情页中，可一站式查看关联的监控指标、错误日志、调用链路等信息，支持状态流转与团队协作，所有操作均有完整记录。故障中心这一功能将进一步帮助团队规范故障处理流程，提升响应效率与过程透明度。

在故障中心的计费逻辑中：每命中一次升级策略，在发送通知时记录 100 次任务调用。

• 创建监控器时，开启「关联故障」，自动生成故障事件

• 故障事件列表

• 故障事件详情页

• 值班规则配置

错误

“错误中心”功能全新上线！可自动汇总 APM、RUM 和日志中的错误，并通过智能聚合将相同问题收敛为统一 Issue 进行跟踪。使用前需配置投递规则以设定监控范围，即可在列表中查看错误概况、处理状态与发生趋势，也可进入详情页分析完整堆栈、关联链路和用户会话。所有错误支持状态流转与团队协作，实现从发现到解决的全流程管理。

同步增加“错误条数”计费，统计每日新增的 Issue 数据条数，包含错误中心产生的 Issue 数据。

• 错误中心列表，可自定义筛选查看不同来源的错误列表

• 错误详情页，基于错误来源展示对应的详情页，下图为用户访问监测错误详情页

Open API

1、资源目录：新增支持创建、编辑、删除资源分组信息；

2、支持直接编辑账号状态（值班中、休假中）。

指标分析

1、新增 Top N 序列及最大返回点数选项，可以指定在每个查询中，返回排序后最大或最小的若干条（20/50/100/500）数据序列；

2、新增支持点击图表数据点，下拉选择查看相似趋势指标、下钻分析或其他关联查看。

基础设施

1、主机：

• 新增支持通过 df_mute 字段进行列表筛选；
• 对于通过 Open API 或规则创建的主机全局静默，系统将在主机列表新增支持展示“静默”标识。

2、资源目录：新增“服务清单”列表入口。

场景

1、仪表板：新增关联监控器按钮，支持一键查看与该仪表板关联的监控器；

2、图表：为所有图表别名配置新增统一序号标识和悬停联动直观化展示多查询行配置时的对应关系。

APM

Profiling：若 Profile 文件体积超过 20MB，系统暂不支持在线解析，同时新增友好提示，您可使用专业分析工具进行查看。

LLM 监测

LLM 查看器【所有 Trace】列表中，“总 Tokens 数” 调整为统计整条 Trace 消耗的 Tokens 数；总 Tokens 列将同步显示输入、输出 Tokens 数量。

日志

查看器：在显示项选择“重置为默认字段”后，message 字段显示逻辑优化。

管理

SSO 管理：优化 SSO 登录流程。用户需先通过邮箱选择身份提供商并完成认证，成功后才能在受保护状态下查看可访问的工作空间，避免权限信息外泄。

部署版

管理后台 > 全局配置：新增平台级系统公告管理配置。

集成更新

• 新增 RedPeaks SAP 集成；
• 更新 AWS rds mysql 仪表盘；
• 新增 kingbase 监控器；
• 更新英文版本dashbord，主要处理中英文转换问题；
• 更新腾讯 PGSQL 仪表板&监控器；
• 更新资源目录 icon 以及分类目录。

DataKit 更新

新加功能

• 新增主机变更检测功能，支持用户、crontab、服务及文件变更监控
• flameshot 支持持续采集模式，增加默认定时采集和阈值触发持续采集功能
• 新增 DataKit 自身日志采集配置功能

问题修复

• 修复 Prometheus export 采集器 tags 优先级错误问题
• 修复全局 host 标签设置 host=__datakit_ip 时无效的问题
• 修复 eBPF 采集器导致 istio-init 容器不退出的问题
• 修复容器日志采集使用默认 stdout 配置时存在无用操作的问题
• 修复 WAL 锁文件使用 PID 导致退出后无法重用的问题
• 修复 profile 采集器初始化时机问题，避免磁盘缓存未初始化导致的 panic
• 修复 Statsd 指标采集，新增 event/service check 采集，这俩类数据目前以日志形式来采集

功能优化

• 为选举模块增加更多日志和指标，便于检测选举频繁切换和采集器暂停失败问题
• 更新 DataKit HTTP 客户端指标，增加 URL 路径标签和请求体传输汇总指标
• SQLServer 采集器新增 sqlserver_host 标签，并将 instance 标签改为 counter_instance
• bug report 新增 Git 配置文件收集功能
• Windows 进程采集器新增 status 字段支持
• DDTrace 采集新增更多 source_type 支持

从金融科技初创公司和SaaS提供商，到人工智能公司和电商平台，各类企业都依赖云对象存储来存储和管理其关键数据。企业使用云存储来存储应用程序源代码、训练好的机器学习模型、客户财务数据、应用程序日志和自动备份等资产。市场上有众多云存储选项，每个都有其独特的功能和定价模式，因此根据公司需求选择合适的解决方案是一个重要的决策。

Amazon Simple Storage Service (Amazon S3) 和 DigitalOcean Spaces 是开发者和企业中两种知名的对象存储解决方案。本文将从关键功能、定价结构、性能指标等多个方面对 Amazon S3 和 DigitalOcean Spaces 进行比较。我们将深入剖析每个平台，为您提供必要信息，以便为您的企业存储需求做出最佳选择。

先说结论：

• 定价： DigitalOcean Spaces 提供透明的定价，每月5美元可获得250 GB存储和1 TB出站流量，且无请求费用；而 Amazon S3 采用复杂的定价模式，对存储、请求、数据传输和各种存储类别单独收费，导致成本难以预测。
• CDN：DigitalOcean Spaces 内置CDN，无需额外费用，且提供S3兼容API，使迁移无缝衔接；而 Amazon S3 需要单独配置CloudFront，产生额外费用，并且CDN功能的设置更为复杂。
• 支持： DigitalOcean 为所有客户提供免费支持，文档直接明了，配置简单，并通过中国区独家战略合作伙伴卓普云（aidroplet.com）提供中文的专业技术支持；而 AWS 的技术支持需付费，起价为每月29美元，并且需要深入了解AWS生态系统才能优化成本和配置，中小型企业很难得到最及时的技术支持。

什么是对象存储？

对象存储是一种将数据作为对象进行管理的数据存储架构，每个对象包含数据本身、元数据和唯一标识符。对象存储在一个扁平的地址空间中，存储系统不强加文件或文件夹的层级结构。对象存储专为处理大量非结构化数据而设计，提供可扩展性、持久性和成本效益。Amazon S3 和 DigitalOcean Spaces 就是对象存储服务的两个知名例子。

块存储与对象存储

块存储和对象存储是两种不同的数据存储方法。块存储将数据组织成固定大小的块，每个块都有自己的地址，通常用于需要低延迟访问的结构化数据。块存储性能高且一致，但对于大规模非结构化数据，可能缺乏可扩展性和成本效益。

相比之下，对象存储将数据组织成可变大小的对象，每个对象都有自己的唯一标识符和元数据，因此更适合需要高可扩展性和持久性的非结构化数据，如图像、视频和备份。对象存储为海量非结构化数据提供了卓越的可扩展性和成本效益，但与块存储相比，延迟可能更高。

选择对象存储解决方案的考量因素

为企业选择对象存储解决方案时，应考虑以下几个因素以确保选择符合组织需求：

• 可扩展性： 考虑对象存储解决方案在容量和性能方面，随着数据增长而扩展的能力。寻找一个能够满足您当前和未来存储需求，且无需对基础设施进行重大更改的解决方案。
• API 兼容性 ： 评估对象存储解决方案与标准API（如Amazon S3 API）的兼容性，这使您能够利用现有工具、库和集成。API兼容性确保了更顺畅的迁移过程，并在需要时更容易切换提供商。
• 性能： 评估吞吐量和延迟方面的性能，尤其是针对您的特定用例。考虑提供商的网络基础设施、数据中心的地理分布以及对多部分上传和范围请求等功能支持等因素。
• 安全性： 评估所提供的云安全功能，例如静态和传输中加密、访问控制机制（如IAM策略、存储桶策略）以及合规性认证（如SOC、HIPAA、GDPR）。确保提供商的安全措施符合您组织的安全要求和行业法规。
• 定价： 比较不同对象存储提供商的定价模式（例如按量付费云计算），同时考虑存储容量、数据传输、API请求和附加功能（如版本控制、跨区域复制）等因素。根据您的使用模式，考虑长期成本和潜在的云成本优化。
• 生态与集成： 评估对象存储提供商的生态系统，以及与您使用的其他服务和工具（如数据分析平台、CDN和备份解决方案）的集成。强大的生态系统和预构建的集成可以简化您的工作流程并减少开发工作。
• 支持与文档： 评估对象存储提供商客户支持的质量和可用性，包括电子邮件、电话和聊天等渠道。同时，查看他们提供的文档、教程和社区资源，以确保您拥有有效实施和排查对象存储解决方案所需的信息。

DigitalOcean Spaces 与 Amazon S3 对比

DigitalOcean Spaces 和 Amazon S3 是两个领先的对象存储解决方案，为云中的非结构化数据提供可扩展、持久且经济高效的存储。虽然两种服务都提供相似的核心功能，但它们在几个关键领域存在差异，例如定价。

Amazon S3

Amazon Simple Storage Service (Amazon S3) 是亚马逊网络服务 (AWS) 提供的知名对象存储解决方案。它提供了一个可扩展、持久且安全的平台，用于从Web任何位置存储和检索数据。

S3 与其他 AWS 服务集成，例如用于内容分发的 Amazon CloudFront、用于长期归档的 Amazon Glacier 以及用于无服务器计算的 AWS Lambda。这种紧密集成使开发人员能够构建强大而高效的应用程序，充分利用 AWS 生态系统的全部潜力。S3 还提供广泛的功能，包括版本控制、跨区域复制、生命周期管理和访问控制，使其适用于各种用例——从简单的文件存储到复杂的大数据分析。

DigitalOcean Spaces

DigitalOcean Spaces 是一个简单、兼容 S3 的对象存储解决方案，旨在成为一个经济实惠且对开发者友好的替代选择。它提供了一个可靠且可扩展的平台，用于存储和提供大量数据，如图像、视频和备份。

DigitalOcean Spaces 的主要优势之一是其简单性和易用性。该服务提供了一个简洁直观的界面来管理存储桶和对象，使得不同技能水平的开发人员都能轻松使用。Spaces 还提供内置的 CDN 功能，允许您在全球范围内分发内容，并通过在边缘位置缓存对象来提高性能。虽然 Spaces 可能没有 Amazon S3 那样广泛的生态系统，但它专注于提供满足大多数开发者和企业需求的基本功能和集成。

如果您是一家采用了多云部署方案的公司，可以利用 DigitalOcean Spaces 的 S3 兼容 API，将其与 Amazon S3 一起集成到您现有的工作流程中。通过利用适用于多种编程语言的 AWS S3 SDK，您可以像管理 Amazon S3 一样以编程方式管理您的 Spaces 存储桶。这种兼容性使您可以将 DigitalOcean Spaces 引入作为互补或替代的对象存储解决方案，同时在您的多云环境中保持一致的开发体验。

Amazon S3 与 DigitalOcean Spaces 特性比较

Amazon S3 和 DigitalOcean Spaces 各自提供针对不同用户需求的独特功能。本节比较两者之间的技术差异，重点介绍定价、存储选项和可扩展性等方面，以帮助用户做出明智决策。

为了快速了解它们的主要区别，以下是总结两种服务的特点、定价与参数：

Amazon S3 与 DigitalOcean Spaces 两者的性价比如何？

Amazon S3 采用按量付费定价模式，成本根据存储、请求和数据传输而变化。标准存储的前 50 TB 每月每 GB 起价为 0.023 美元，使用量越大价格越低。然而，请求成本使此模型变得复杂。例如，每 1,000 次 PUT 请求收费 0.005 美元。S3 的成本可变性主要源于这些请求费用，需要警惕性的财务运营管理，以避免意外开支，这可能显著影响客户的预算。

此外，Amazon S3 提供智能分层功能，可根据数据访问模式优化存储成本。此功能对每个对象收取月度监控和自动化费用，进一步增加了管理费用管理的复杂性。

相比之下，DigitalOcean Spaces 提供了更可预测且经济实惠的定价模式。每月固定费用 5 美元，客户可获得 250 GiB 存储和 1 TB (1,024 GiB) 出站数据传输。额外存储按每 GB 0.02 美元计价，额外出站传输按每 GB 0.01 美元计价。这种固定费率模式包含无限上传和 API 请求，使开发人员更容易管理和预测他们的支出，而无需持续的财务监督。

通过提供简单明了的定价，DigitalOcean Spaces 为需要稳定和可预测预算的用户提供了明显优势，这与 Amazon S3 更可变且可能昂贵的定价结构形成对比。

存储类别选项与对象存储功能

Amazon S3 提供一系列存储类别，旨在满足不同的数据访问需求和成本管理目标。这些类别包括用于频繁访问数据的标准存储、用于访问模式多变数据的智能分层，以及用于检索时间较长的长期归档的 Glacier。每个类别都根据特定使用场景（如不频繁访问或归档需求）进行定制，以优化成本和性能，并提供自动数据生命周期转换选项以进一步降低成本。

DigitalOcean Spaces 则采用更简单的方法，只提供一个存储类别。这种标准存储类别旨在处理广泛的用例，专注于简洁性、易用性和关键功能。虽然这种方法限制了基于数据访问和生命周期需求的定制，但它为寻求简单对象存储服务的开发人员提供了一种直接有效的解决方案。

可扩展性与区域可用性

Amazon S3 提供高可扩展性，支持几乎无限的存储且无需长期承诺，允许根据不断变化的存储需求进行动态调整。它还在广泛的 AWS 区域网络中全球可用，提供了将数据存储在靠近最终用户的位置以降低延迟和提高性能的灵活性。

DigitalOcean Spaces 虽然具有可扩展性，但规模稍小，但仍能有效满足大多数开发人员和企业的需求。与 Amazon S3 相比，它在较少的区域中可用。然而，Spaces 为初创公司和中小型企业提供了足够的可扩展性，专注于在其现有数据中心和接入点 (PoP) 中提供易于使用且性能一致的环境。

安全功能与权限粒度

Amazon S3 提供广泛的安全功能，旨在保护和管理数据访问。它包括访问控制列表 (ACL)、存储桶策略，以及能够在存储桶和单个对象级别配置公共和私有访问权限。S3 支持在传输中和静态时对数据进行加密，使用 AWS 管理的密钥或客户在 AWS 密钥管理服务 (KMS) 下提供的密钥，从而增强了对敏感和受监管数据的安全性。

DigitalOcean Spaces 提供了相当的安全级别，确保数据在静态时使用 AES-256 加密，在传输过程中使用 SSL/TLS 加密。虽然它支持与 S3 类似的基本权限设置，例如将存储桶设置为私有或公共，但其权限粒度与 Amazon S3 相比略显不足。这使得 Spaces 成为满足一般安全需求的强大选择。

API 兼容性与生态系统集成

Amazon S3 具有广泛的 API 兼容性，并能与大量服务和第三方应用程序集成。它支持一整套 API，可实现从基本对象存储操作到高级功能（如多部分上传、生命周期管理和跨区域复制）的一切。AWS 生态系统还包括跨多种编程语言的 SDK 支持，提高了开发人员的工作效率，并促进了与 AWS Lambda、Amazon EC2 和 Amazon CloudFront 等其他 AWS 服务的集成。

DigitalOcean Spaces 通过提供 S3 兼容 API 保持了高水平的 API 兼容性，这使其能够与许多为 Amazon S3 设计的相同工具和系统集成。这种兼容性简化了从 S3 迁移的用户流程，并使开发人员能够以最少的修改使用现有的脚本和工具。虽然 DigitalOcean 的原生服务集成比 AWS 少，但与 S3 API 的兼容性确保了 Spaces 可以成为寻求更简单、更具成本效益的云存储解决方案的用户的可行替代选择。

分析、监控与管理工具

Amazon S3 提供了一套分析、监控和管理工具，可以对存储的数据进行详细的洞察和操作控制。S3 Analytics 通过分析数据使用情况并建议适当的存储类别，帮助用户了解访问模式并优化存储成本。AWS CloudTrail 集成允许跟踪 API 调用和相关活动以进行审计和安全目的，而 Amazon CloudWatch 提供指标和警报来监控资源的运行状况和性能。此外，S3 Inventory 提供有关存储对象元数据的报告，有助于合规性和管理任务。

另一方面，DigitalOcean Spaces 通过 DigitalOcean 控制面板提供更基本的监控功能。用户可以直接在界面内跟踪带宽使用情况和监控性能指标。这些工具涵盖了基本的监控需求，并且操作简单，对于那些偏爱管理工具简洁性的用户尤其具有吸引力。这种易用性与 DigitalOcean 提供用户友好型云解决方案的总体重点相一致。

Amazon S3 与 DigitalOcean Spaces 常见问题解答

DigitalOcean Spaces 和 Amazon S3 之间的主要成本差异是什么？

DigitalOcean Spaces 每月固定收费 5 美元，提供 250 GB 存储和 1 TB 出站流量，且无每次请求费用，使得成本可预测且易于计算。Amazon S3 采用复杂的定价，对存储层级、GET/PUT 请求、数据传输、存储类别转换和各种附加功能单独收费，如果不仔细监控，很难预测每月成本。

两种服务之间的 CDN **集成有何不同？

DigitalOcean Spaces 包含内置的 CDN 功能，无需额外费用，可自动进行内容分发，设置简单，无需单独配置。Amazon S3 需要单独的 CloudFront 设置，数据传输、请求和配置复杂性都会产生额外费用，从而增加了成本和管理开销。

从 Amazon S3 迁移到 DigitalOcean Spaces 容易吗？

是的，DigitalOcean Spaces 提供 S3 兼容的 API，这意味着使用 AWS SDK 的应用程序只需很少的代码更改（通常只需更新端点 URL）即可切换到 Spaces。这种兼容性使迁移变得简单直接，减少了供应商锁定顾虑，同时提供了更简单的定价和内置的 CDN。

哪个平台更适合不同的用例？

DigitalOcean Spaces 适合具有可预测定价、内置 CDN 需求的直接对象存储需求，希望避免 AWS 复杂性的应用程序，以及优先考虑透明成本而非广泛功能的团队。Amazon S3 适合需要高级功能（如生命周期策略、广泛的存储类别、深入的 AWS 集成）的企业，以及拥有专门 AWS 专业知识来管理复杂性的团队。

总结

DigitalOcean Spaces 提供了一个简单直接且可扩展的对象存储解决方案，适合那些希望有效管理数据，同时又不想应对大型云提供商常有的复杂性的开发人员和企业。像 Adevava 和 Kea 这样的企业都信任 DigitalOcean Spaces 来满足其对象存储需求。无论您是在存储海量数据还是向用户提供媒体文件，Spaces 都能在 DigitalOcean 用户友好的生态系统内提供可靠且经济高效的服务。

以下是使用 DigitalOcean Spaces 及更广泛的 DigitalOcean 平台的一些主要功能和优势：

• 管理简单： 易于使用的控制面板简化了存储和数据的管理。
• 高可扩展性： 无缝扩展以满足您不断增长的存储需求，无需任何手动干预。
• 经济高效的定价： 提供可预测的固定费率定价，出站流量高达 1 TB 无隐藏费用。
• S3 兼容 API ： 确保与您现有的、使用 Amazon S3 API 的工具和工作流兼容。
• 详尽的文档： 全面、易于理解的文档，帮助您充分利用 DigitalOcean 服务。
• 出色的客户支持： 我们专业的支持团队 7x24 小时待命，随时协助解决任何问题或疑问。
• 活跃的社区： 活跃的社区论坛以及由 DigitalOcean 和社区成员贡献的大量教程。

将您的工作负载迁移到 DigitalOcean

如果将您的工作负载从其它云迁移至DigitalOcean，在获得专家全程免费迁移协助的同时，您的云服务成本还可以降低 30-50%。同时，DigitalOcean 中国区独家战略合作伙伴卓普云AI Droplet还会为中国企业提供中文的专业技术支持。目前，Character.ai、fal.ai、Persistent、DataCake和 NoBid 等公司，都在使用 DigitalOcean 云服务，不仅节省了云服务成本，还获得了性能的提升。

作者：vivo 互联网项目团队- Ding Junjie
本文从作者使用AI的实践经验出发，探讨了Chat模式作为AI交互范式的特点和优势。作者提出了"意图信息密度匹配"的核心概念，认为好的AI交互设计本质上都在解决人机意图信息密度匹配问题。通过分析Cursor Tab补全、Granola会议笔记等成功案例，以及对比一键生成模式的局限性，文章总结了不同AI交互模式的适用场景和设计原则。作者认为Chat模式虽然不是唯一的最佳交互范式，但它体现了高密度意图交互的重要原则，关键是要根据用户意图的复杂程度设计合适密度的交互方式。

1分钟看图掌握核心观点👇

图1 VS 图2，您更倾向于哪张图来辅助理解全文呢？欢迎在评论区留言。

我从 GPT-3.5 发布第一个月就开始用 AI，也尝试写过各种demo项目，参与过早期的NextChat开源项目，现在每天都离不开各类AI工具。最近在想一个问题：Chat模式是和AI最好的交互范式吗？

图片来源于 TOP 50 GEN AI WEB PRODUCTS

一、Chat 模式为什么让人感觉舒服？

用ChatGPT的时候，我经常有种感觉：就像在和一个很聪明的朋友聊天。我说一句，它回一句，我们慢慢把问题聊清楚。

这种感觉和用其他AI功能很不一样。比如一些"一键生成"的功能，我点一下，它哗啦啦输出一大堆，我看着就头大。

想了想，发现Chat模式有个特点：你一句，我一句，每次交换的信息都是小块的。

二、从AI的工作原理看Chat模式

大模型本质上是预测下一个token。它需要基于前面的内容来预测后面的内容。

这让我想到一个角度：Chat模式中，每次用户的一句话，其实都是对AI预测下一段token的调整。

或者用更技术的语言说：每次人的输入都在减少AI理解用户意图的熵。

Chat交互模式：

用户: "我想写个用户管理功能"
AI: "好的，你需要哪些具体功能？增删改查？还是..."
用户: "主要是查询和编辑，要支持分页"
AI: "明白了，你用的是什么技术栈？数据库是..."
用户: "React + Node.js，MongoDB"
AI: "好的，我来帮你写一个基于这个技术栈的用户管理..."

每一轮对话，AI对用户意图的理解都更精确一些

三、意图信息密度匹配的概念

从这个观察中，我想到一个概念：意图信息密度匹配。

用户的意图信息密度：

┌─────────────────────┐

│ 具体目标 + 使用场景 │

│ + 个人偏好 + 约束条件 │

└─────────────────────┘

AI理解的意图信息密度：

┌─────────────────────┐

│ 从对话中提取的 │

│ 用户真实意图程度 │

└─────────────────────┘

当两者匹配度高时，AI输出就符合期望；当差距过大时，AI输出就会偏离预期。

无论是AI理解不了人，还是人不再能够理解AI输出的内容，都不是一个好的体验。

Chat模式的本质就是：它能和AI进行高密度的意图交互。

四、其他成功的交互模式也有类似特征

想到这里，我开始观察其他好用的AI功能，发现它们虽然不是Chat模式，但本质上也在做类似的事情。

4.1 Cursor Tab补全：另一种"你一句我一句"

我: function calculatePrice(
AI: items: Product[], discount: number): number {
我: ↵ (采纳) const basePrice =
AI: items.reduce((sum, item) => sum + item.price, 0);
我: ↵ (采纳) return basePrice *
AI: (1 - discount);

这也是人一下，AI一下的模式。我写前几个单词，AI预测后面的，我选择是否采纳。整个过程协同密度足够高，每一步都在对齐认知。

4.2 Granola会议笔记：并行理解，AI往人靠

会议进行中：

（1）我手动记录：

[重要决定] 下周发布新功能

[风险点] 数据库性能

[行动项] 张三负责测试

（2）AI同时记录：

完整的会议转录内容

（3）结合阶段：

AI基于我的重点标记来组织它记录的详细内容

这个设计很有意思：它没有采取"你一句我一句"，而是采取并行理解相同的内容，然后AI往人的理解上靠。

本质也是在减少熵增，拉齐认知，并且以人为主导。

图片来源于granola（www.granola.ai/）

五、为什么一键生成常常让人失望？

对比一下一键生成的模式：

一键生成模式：

用户: "帮我写个电商网站"
AI: [生成大量代码和文档]
用户: [需要花很多时间理解和修改，最后发现根本用不了！！！]

问题在于：

• 用户一次性描述很难传达完整意图
• AI大量输出让用户认知负荷爆炸
• 缺乏中间的意图校准过程

六、成功的AI产品/功能都在不断拉齐人和AI的共同认知

观察一些真正好用的AI产品：

• GitHub Copilot：在代码编写过程中实时预测，保持高频意图同步
• Notion AI：基于已有文档内容进行续写，上下文丰富
• Figma AI：在现有设计基础上调整，意图边界清晰

它们的共同点：都在用户提供丰富意图上下文的基础上进行AI增强，同时保持人和AI一致性理解。

七、什么场景适合"一键生成"？

当然，也有一些场景适合大颗粒度生成：

7.1 意图简单明确的场景

• 翻译：意图就是转换语言
• 格式转换：规则清晰，没有歧义
• 模板生成：标准化程度高

7.2 容错度高的场景

• 头脑风暴：随便生成想法，错了也无所谓
• 快速原型：只要能跑起来就行

这些场景的特点是：用户意图相对简单，或者对结果要求不高。

比如飞书的会议总结就是好的应用场景

图片来源于飞书app（feishu.cn）

八、一些思考

基于这些观察，我觉得设计AI功能时可以考虑：

8.1 评估意图复杂度

• 用户意图是否容易一次性描述清楚？
• 个性化需求有多强？
• 对结果的精确度要求如何？

8.2 选择合适的交互密度

• 复杂意图：高频交互，保持同步（像Chat、Tab补全、Granola这种后置拉齐ai和人协同的认知）
• 简单意图：可以支持一键生成

8.3 设计意图校准机制

• 如何让用户轻松提供上下文？
• 如何及时发现意图理解偏差？
• 如何保持以人为主导？

九、未来的方向

从技术发展看，可能的优化方向：

• 更长的上下文窗口：能处理更丰富的意图信息
• 更好的意图推断：从少量输入中理解更多意图
• 多模态意图捕获：结合语音、手势、视觉等
• 个性化记忆：记住用户的习惯和偏好

但核心还是：人机意图信息密度匹配。

十、回到最初的问题

Chat模式是和AI最好的交互范式吗？

我觉得不是唯一的，但它确实体现了一个重要原则：高密度的意图交互。

好的AI交互设计，本质上都在解决人机意图信息密度匹配问题。Chat模式是一种很好的实现方式，但不是唯一的方式。

关键是要理解你的用户意图有多复杂，然后设计合适密度的交互方式。

这是作者作为重度AI用户的一些观察和思考。

你在用AI时有什么感受？有没有发现其他有趣的交互模式？欢迎交流~！

本文仅分享作者基于个人技术实践的思考和主观观点，不构成决策依据。

摘要：
本文介绍如何为开源个人AI助手 Moltbot（原 ClawdBot）集成基于 OceanBase 技术栈的长期记忆插件 PowerMem。通过 HTTP API 对接，PowerMem 为 Moltbot 提供智能信息抽取、艾宾浩斯遗忘曲线调度及多智能体隔离的记忆能力，显著增强其上下文持久化与自主决策水平，实现更类人的“数字员工”体验。 

Moltbot 是什么？

Clawdbot（后更名为 Moltbot，又更名为 OpenClaw）是一款开源、以通讯为核心的AI智能体项目，运行在你自己的设备上，通过你已有的渠道（WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage、Teams、WebChat 等）和你对话，支持语音、Canvas、多代理路由等。 简单点说：Moltbot 最大的特点是不仅能回答问题，更能真正“动手”操作你的电脑系统，执行命令、控制浏览器、管理文件，就像一个 7 x 24 小时在线的 “数字员工”。 

官网 ：https://www.molt.bot/
github 地址：https://github.com/moltbot/moltbot
 

Moltbot 部署

方式一：NPM 全局安装

方式二：源代码安装

上面两种安装方式二选一，因为我是走的源代码安装：
1.     pnpm moltbot onboard --install-daemon 初始化

2.     同意风险
提示这里会让你确认风险。Moltbot 功能强大，能执行系统命令、读写文件、控制浏览器，但这也意味着如果配置不当或被滥用，可能会带来安全风险，请谨慎使用。

3.     选择快速开始
4.     配置 AI 模型授权，我手里头有qwen的

5.     启动web问个小问题：“查一下我的电脑型号”，很快 moltbot 回复了我机器的具体型号，虽然任务非常简单，但是还是挺惊喜的，距离“贾维斯”又进了一步了。

Moltbot 的原生记忆解读

Moltbot 的持久记忆可以概括为：「Markdown 文件为单一事实来源 + 可选向量/混合检索」。 

存储形态：纯 Markdown 文件 事实来源：模型「记得」的内容 = 写入磁盘的 Markdown；不依赖模型内部状态。默认布局（在 workspace 下，如 ~/clawd）：memory/YYYY-MM-DD.md：按日期的日志，仅追加；会话开始时读「今天 + 昨天」。MEMORY.md（可选）：长期、人工可维护的记忆；只在 main 私聊 session 加载，群聊不加载。 也就是说：短期、按天的记录 → memory/YYYY-MM-DD.md长期、精选事实 → MEMORY.md持久化完全靠「写进这些文件」，而不是靠对话历史本身。 

写入时机与「记忆冲刷」（Memory Flush） 平时：模型通过 工具（如 write、edit）或技能，把要记住的内容写到 MEMORY.md 或 memory/YYYY-MM-DD.md。自动冲刷：当 session 快触发自动 compaction 前，Moltbot 会跑一轮 静默的 agent 回合，专门提醒模型「把该持久化的东西写进记忆文件」，并鼓励用 NO_REPLY 不回复用户，避免用户看到这次内部回合。触发条件由 agents.defaults.compaction.memoryFlush 控制，例如在「剩余 token ≈ softThresholdTokens」时触发；每轮 compaction 只做一次 flush，并在 sessions.json 里记 memoryFlushCompactionCount 等，避免重复。 

相关代码在 src/auto-reply/reply/memory-flush.ts：shouldRunMemoryFlush()：根据当前 token、context 上限、reserve、softThreshold 判断是否该 flush。

若 workspace 只读（如 sandbox workspaceAccess: "ro"），则不做 flush。 

检索层：向量 + 可选 BM25 混合检索 
数据流

实现方式 

插件控制：默认使用 memory-core 插件（可设 plugins.slots.memory = "none" 关掉）。工具：memory_search：对 MEMORY.md 和 memory/.md 做语义检索（按 ~400 token 分块、80 token 重叠），返回片段 + 文件路径 + 行号；可选开启 BM25 + 向量 的混合检索。memory_get：按路径（及可选 from/lines）读取 MEMORY 或 memory 下的文件片段，供在检索后精确拉取，控制上下文长度。向量索引：对MEMORY.md 和 memory/.md 建索引；索引按 agent 存于 ~/.clawdbot/memory/.sqlite（路径可配）。支持远程 embedding（OpenAI、Gemini 等）或本地模型（如 GGUF）；可选 sqlite-vec 做向量加速。文件变更有 watcher（debounce），索引异步更新；若 embedding 模型/端点等变化，会整库重建索引。 

混搜权重分配

最终分数的计算公式非常简单（src/memory/hybrid.ts）：

这意味着：向量搜索和文本三七开：最终得分 = 0.7×向量分 + 0.3×文本分（归一化后），偏重语义。候选池放大 4 倍：先取 maxResults × 4 的候选再合并、排序、截到 maxResults，提高最终 Top‑N 质量。 

Moltbot + powermem 方案

有 PowerMem VS 没有 PowerMem

集成 powermem 方案集成方式：已插件的方式进行集成

集成方式：新增插件 extensions/memory-powermem，通过 HTTP 调用 PowerMem 已启动的 API 服务；不把 PowerMem 作为库嵌入 Moltbot 进程。部署：用户需单独启动 PowerMem（如 powermem-server --host 0.0.0.0 --port 8000 或 Docker），并在 Moltbot 配置中填写 baseUrl（及可选 apiKey）。 代码结构代码地址：https://github.com/ob-labs/moltbot-extension-powermem

在 Moltbot Agent 里会暴露这些能力：memory_recall — 按查询搜索长期记忆memory_store — 写入一条记忆（可选是否智能抽取）memory_forget — 按记忆 ID 或按搜索条件删除 使用 powermem 插件 Step1: 前置条件 已安装 Moltbot（CLI + gateway 能正常用）PowerMem 服务：需要单独安装并启动（见下文两种方式，任选其一）若用 PowerMem 的「智能抽取」：需在 PowerMem 的 .env 里配置好 LLM + Embedding 的 API Key（如通义千问 / OpenAI） Step2：把本插件装进 Moltbot 在你本机执行（路径改成你实际克隆的目录）：

安装成功后，可用 moltbot plugins list 确认能看到 memory-powermem。 Step3：配置 Moltbot 使用本插件 编辑 Moltbot 的配置文件（常见位置：~/.clawdbot/config.json 或项目里的 moltbot.json），在 根级 增加或合并 plugins 段，并把记忆槽指向本插件，并写上 PowerMem 的地址。 示例（JSON）：

说明：baseUrl：PowerMem 的 HTTP 地址，不要加 /api/v1，就写 http://localhost:8000 或你的实际主机/端口。若 PowerMem 开了 API Key 鉴权，在 config 里增加 "apiKey": "你的key"。改完配置后重启 Moltbot gateway（或重启 Mac 菜单栏应用），配置才会生效。 Step4：验证插件与 PowerMem 连通 在终端执行：

若输出里没有报错、能看到健康状态，说明插件已连上 PowerMem。 Step5: 测试手动写入 + 搜索 我们来简单测试一下,用手动写入验证数据库是否有数据

 若搜索能返回刚写的那条（或类似内容），说明「安装 PowerMem → 安装插件 → 配置 Moltbot」全流程已打通。 下面是执行结果：

看一眼数据库,妥妥的已经写入了

 欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/  

本文将介绍如何使用 boto 和 SES 发送电子邮件。boto 库是 Python 的一个非常不错的封装，帮助你与 AWS API 互动。

设置

首先你需要一个 AWS 账户（当然），以及你的账户的访问密钥和秘密密钥，这些将用于与 SES 服务器进行身份验证。有几种不同的方法可以使用密钥进行身份验证，但本文我们将只是将它们传递给 boto 提供的connect_to_region方法。

通过 SES 验证一个电子邮件地址（Gmail 地址完全没问题）或您拥有的域。如果您只是测试这个功能，我建议只验证一个电子邮件地址，因为这样会稍微快一点。您只需点击他们发送给您的验证电子邮件中的链接，而不是为验证域而在区域文件中添加 TXT 记录。

如果是第一次使用 SES，且你的应用程序需要发送大量电子邮件，可能需要提交请求来增加发送配额。你的 SES 账户最初会被放在一个沙盒中，在 24 小时内只能发送 200 封电子邮件。

实例代码

完成上面提到的初始设置，你应该能够使用下面的代码发送电子邮件。

AWS_ACCESS_KEY = 'YOUR-ACCESS-KEY-HERE'
AWS_SECRET_KEY = 'YOUR-SECRET-KEY-HERE'

class Email(object):
    def __init__(self, to, subject):
        self.to = to
        self.subject = subject
        self._html = None
        self._text = None
        self._format = 'html'

    def html(self, html):
        self._html = html

    def text(self, text):
        self._text = text

    def send(self, from_addr=None):
        body = self._html

        if isinstance(self.to, basestring):
            self.to = [self.to]
        if not from_addr:
            from_addr = 'me@example.com'
        if not self._html and not self._text:
            raise Exception('You must provide a text or html body.')
        if not self._html:
            self._format = 'text'
            body = self._text

        connection = boto.ses.connect_to_region(
            'us-east-1',
            aws_access_key_id=AWS_ACCESS_KEY, 
            aws_secret_access_key=AWS_SECRET_KEY
        )

        return connection.send_email(
            from_addr,
            self.subject,
            None,
            self.to,
            format=self._format,
            text_body=self._text,
            html_body=self._html
        )

要使上面代码，您只需要做这件事：

email.text('This is a text body. Foo bar.')
email.html('<html><body>This is a text body. <strong>Foo bar.</strong></body></html>')  # Optional
email.send()

该email.html()调用是可选的。如果在电子邮件中同时包含文本和 HTML，则两者都会包含在结果 MIME 中，电子邮件客户端将显示用户支持或偏好的格式。

使用电子邮件模板

当然上面的自定义模板比较朴素，如果你想要更加好看，可以尝试使用模板引擎。这样我们不必直接传递电子邮件正文字符串，而是可以从模板中加载它，就像在 Django 这样的 Web 框架中渲染 HTML 页面一样。

在这里我们使用 Jinja2 模板引擎来处理模板的加载和渲染：

from jinja2 import Environment, PackageLoader

# 
env = Environment(loader=PackageLoader('yourapp', 'templates'))

AWS_ACCESS_KEY = 'YOUR-ACCESS-KEY-HERE'
AWS_SECRET_KEY = 'YOUR-SECRET-KEY-HERE'

class Email(object):
    def __init__(self, to, subject):
        self.to = to
        self.subject = subject
        self._html = None
        self._text = None

    def _render(self, filename, context):
        template = env.get_template(filename)
        return template.render(context)

    def html(self, filename, context):
        self._html = self._render(filename, context)

    def text(self, filename, context):
        self._text = self._render(filename, context)

    def send(self, from_addr=None):
        # Same as before...

注意：在生产代码中，不要直接将 AWS 安全密钥放入代码中。而是使用环境变量之类的东西。

使用这个代码和之前类似，但是我们会直接传递模板文件名和模板填充的上下文：

ctx = {'username': user.username}
email.text('email.txt', ctx)
email.html('email.html', ctx)  # Optional
email.send()

通过上面的代码让你可以像创建和渲染网页一样轻松地创建和渲染 HTML 邮件。

结语

看到这儿相信大家对如何使用 boto 和 SES 发送电子邮件有了清楚地了解，希望这个简短的教程对你有所帮助。这里的代码应该适用于大多数用例，尽管你还可以通过添加抄送、密送、回复地址、返回路径，甚至文件附件来获得更高级的功能。

我刚刚提到的所有这些额外功能，除了附件，都可以通过send_email函数来处理。要发送附件，你必须使用较低级别的send_raw_email函数，这需要你自己构造 MIME 消息。https://mybj123.com/29061.html

社区小伙伴们：

KWDB 社区第二季征文大赛火热进行中，还没上车的趁着放假期间抓紧走一波啦~！

安装部署、实战经验、技术思考、踩坑复盘、优化记录......请将你的真知灼见，化为代码与文字。

我们精心为大家准备了丰厚的奖励，诚邀每一位热爱技术、乐于分享的你，与我们一同书写分布式多模数据库的未来篇章🌟！

赛程重点已经帮大家划好了~快来看吧！👉

关键时间点

📅 投稿截止日期：

2026 年 3 月 9 日（周一）

（Tips: 投稿数量不限哟！）

🏆奖项设置：

奖池丰厚，多重好礼等你来赢👇！

🌟彩蛋🌟

✅ 优秀文章还将被推荐至 KaiwuDB 官方社区各个平台!

✅ 持续投稿高质量内容，还有机会成为社区定期评选的明星贡献者，获得额外的奖励哦\~

两大主题，你的舞台你做主！

1️⃣ 实操主题：从体验到精通，记录每次实践

• KWDB 3.1.0 /3.0.0 安装部署过程中经验与踩过的坑

• 核心特性深度体验与解读

• 读写性能/稳定性实测

• Bug 修复与实践调优

• 与 ThingsBoard、Superset 等生态工具的集成实践心得

• KAT 智能体工具 花式玩法（记得申请免费试用哦！）

• 玩转KWDB Playground

• KaiwuDB Lite 轻量版实操（记得申请免费试用哦！）

------真实体验，就是最好的技术语言！

2️⃣ 场景应用主题：聚焦场景，分享应用落地

• 能源/电力/车联网等任何行业落地案例

• 开源生态中的实战经验分享

• 开源技术方案的落地与优化

------任何能让技术"活起来"的实践，我们都欢迎！

投稿必看！！！

➡️ 内容：不少于 1000 字，推荐"图文并茂"，聚焦干货，阅读体验更佳\~

➡️ 审核：需通过查重检测 + AI 生成文本检测，原创至上！

➡️ 重要提醒：严禁任何形式抄袭！一经发现并核实，账号永久拉黑，取消所有参赛资格！

最重要的：如何投稿？

👇 扫下方二维码登记作品链接或上传作品文件即可：

写稿指南：

👇 参赛指南、试用申请及备赛 tips 合集：

https://www.kaiwudb.com/blog/841.html

👇 往届开发者精彩分享：

https://www.kaiwudb.com/chuangzuozhejihua/

👇 获取指导：

添加征文小助手K小二（微信号：KaiwuDB Assistant2）或扫码加入大赛交流群：

👇 了解我们：

KaiwuDB 官网: https://www.kaiwudb.com/

Gitee 社区: https://gitee.com/kwdb/kwdb

转发给身边的技术伙伴，一起参赛赢好礼吧💡！

用代码连接彼此，用思考照亮前路，用共创定义未来。

码上行动，等你来写！

本活动最终解释权归 KWDB 社区所有

如有疑问，欢迎联系小助手咨询