2026国家自然基金ai声明在哪里写?

2026国家自然基金ai声明在哪里写?

下面图中

根据2026年国家自然科学基金(NSFC)最新要求,‌AI使用声明需在申请书中明确撰写并提交‌,具体位置和撰写方式如下:

声明撰写位置建议

  • 推荐位置‌:将AI使用声明作为独立小节,置于“‌研究方案‌”或“‌研究基础‌”部分之后,也可放在“‌伦理合规与科研诚信‌”相关章节中。
  • 标题建议‌:使用如“‌3.X 人工智能工具使用边界与研究诚信保障策略‌”等清晰标题,便于评审查阅‌4。

声明撰写原则(权威指引)

根据基金委最新导向及多位专家解读,声明应遵循以下原则:

  • 诚实透明,宜粗不宜细‌:无需逐段罗列AI在立项依据、技术路线等各部分的具体使用情况‌610。

整体性说明即可‌:例如:

“本项目申请书的撰写过程中,申请人使用[工具名称,

Read more

【2026机器人新产品】稚晖君/智元上纬:启元Q1

继智元机器人收购上纬新材超63.62%股份后,创始人彭志辉也当选了上纬新材董事长。这可能是当下最好的安排,因为“华为天才少年”稚晖君,可能将一直是这家公司,尤其是机器人业务的灵魂。 本次发布的人形机器人“上纬启元Q1”面向个人与家庭场景,第一个亮点就是“小”,身高0.8米,体积1.88立方米,在三维空间中能够将体积和重量均缩小至八分之一,折叠起来能直接塞进背包,成年人单手就能拎着走。 从目标客户定位来看,“小”确实有助于机器人产品走入普通消费者和家庭,从心理上,人会恐惧比自己高大的物体。对于陪伴小孩与老人的场景而言,“小机器人”也更符合人的预期。 从技术实现能力上看,智元上纬将实验室级人形机器人能力压缩至背包大小,这里就涉及到一个重要的技术创新----微型化关节系统‌,通过材料与算法重构,将QDD准直驱关节压缩至“比鸡蛋还小”,保留全尺寸机型的动态响应能力,成为全球最小力控人形机器人。‌‌上纬启元Q1通过体型和重量的工程化压缩,意在降低机器人的使用门槛,为极客玩家、科研人员和家庭用户提供了探索空间。 这项创新绝非简单“缩小尺寸”,而是在多个工程与科学层面的高度整合,难度体现在:

宇树VR遥操与IL——从遥操程序xr_teleoperate到unitree_IL_lerobot:如何基于G1进行manipulation开发

宇树VR遥操与IL——从遥操程序xr_teleoperate到unitree_IL_lerobot:如何基于G1进行manipulation开发

前言 如之前的文章所述,我司「七月在线」正在并行开发多个订单,目前正在全力做好每一个订单,因为保密协议的原因,暂时没法拿出太多细节出来分享 但可以持续解读我们所创新改造或二次开发的对象,即解读paper和开源库「当然 有些paper/库还没开始用,但也可以提前解读,作为关注了解」 而对于我司人形开发的订单,截止到25年4月,背后的机器人多半基于这几家:宇树、智元、傅利叶、乐聚「之所以用的这几家,一半因为我和这些公司熟,一半因为客户已有其中某一家或某几家的本体 需在其基础上做定制开发,如其它厂商看到 有兴趣合作,欢迎私我,比如星动纪元、星海图、众擎等等」 * 通过此文《Fourier-Lerobot——把斯坦福人形动作策略iDP3封装进了Lerobot(含我司七月的idp3落地实践)》可知,傅利叶 把idp3 装进了lerobot * 类似的,宇树 通过此开源库「unitree_IL_lerobot」,也把lerobot 集成了下 该库包含了π0策略 且无论咱们是用傅利叶集成的lerobot—

混合知识库搭建:本地Docker部署Neo4j图数据库与Milvus向量库

混合知识库搭建:本地Docker部署Neo4j图数据库与Milvus向量库

混合知识库搭建:本地Docker部署Neo4j图数据库与Milvus向量库 前言 在多代理混合RAG系统中,知识库是“知识储备核心”,直接决定了代理检索的精准度与响应质量。上一篇我们解析了5个子代理的执行逻辑,而这些代理能高效完成知识检索任务,背后依赖“Neo4j图知识库+Milvus向量库”的混合支撑——图知识库擅长挖掘实体关系,向量库精准匹配语义细节,二者互补形成全场景知识覆盖。 本文作为系列博客的第三篇,将聚焦混合知识库的落地实现:从本地Docker部署、数据建模、索引构建,到双库协同逻辑,手把手带你搭建高可用的混合知识库,让你掌握“关系型知识+语义型知识”的全链路管理技巧。 1 混合知识库的设计逻辑:为什么需要“图+向量”双引擎? 1.1 单一知识库的局限性 * 纯图数据库:擅长实体关系查询(如“小米的合作品牌”),但无法高效处理细粒度文本检索(如“苹果的环保目标细节”); * 纯向量数据库:擅长语义相似性检索(如“查找与5G技术相关的内容”),但难以挖掘实体间的复杂关联(如“华为-开发-鸿蒙-适配-智能设备”

腾讯云智能客服机器人Java集成实战:从接入到生产环境优化

最近在项目中接入了腾讯云的智能客服机器人,把整个集成过程和一些优化经验记录下来,希望能帮到有类似需求的同学。自己动手搭过客服系统的朋友都知道,从零开始搞一套,不仅开发周期长,而且智能语义理解这块的门槛太高了,效果还很难保证。直接集成成熟的SaaS服务,就成了一个快速又靠谱的选择。 1. 为什么选择腾讯云智能客服? 在技术选型阶段,我们对比了几家主流云厂商的方案。阿里云的智能客服功能也很强大,生态完善,但它的API设计风格和我们团队的历史技术栈适配起来有点别扭。AWS Lex的优势在于和海外其他AWS服务无缝集成,但国内访问的延迟和合规性是需要考虑的问题。腾讯云智能客服吸引我们的点主要有几个: * API设计友好:它的RESTful API文档清晰,错误码规范,并且提供了Java、Python等多种语言的SDK,上手速度快。 * 计费透明灵活:支持按调用量、按坐席等多种计费模式,初期可以先用调用量模式试水,成本可控。 * NLP能力本土化强:在中文场景下的意图识别和情感分析准确率不错,特别是针对一些行业术语和网络用语,理解得比较到位。 综合来看,对于国内业务为主、追求快速集