在企业数字化转型的浪潮中,CRM(客户关系管理)已从“销售工具”升级为“全链路业务中枢”——覆盖获客、销售、订单、交付、分析及上下游协同的完整闭环,直接决定企业的运营效率与客户体验。

本文基于超兔一体云、Salesforce、励销云、探马SCRM、SugarCRM、Free CRM 、ClickUp、Really Simple Systems八大主流CRM品牌的公开能力,从获客、销售、订单、发货/物流、统计分析、上下游协同六大核心维度展开深度横评,为企业选型提供参考。

一、市场背景:从“单点工具”到“全链路闭环”

传统CRM多聚焦“销售跟进”或“客户存储”,难以支撑现代企业的全链路需求

  • 获客需多渠道触达+线索精准筛选;
  • 销售需个性化跟进+流程自动化;
  • 订单需覆盖多类型业务+财务联动;
  • 交付需物流跟踪+客户验收;
  • 决策需数据可视化+AI预测;
  • 生态需连接供应商/客户的协同。

因此,“全链路闭环能力”成为企业选型的核心标准。

二、核心维度横向对比

(一)获客能力:从“流量”到“精准线索”

获客是CRM的起点,关键看渠道覆盖广度、线索筛选精度、管理智能化

品牌获客渠道核心技术/工具线索管理能力
超兔一体云百度/抖音/微信/官网/地推/工商搜客多渠道表单抓取+AI查重归属地补全+分配提醒+活动ROI计算
Salesforce官网/社交媒体/邮件/广告Marketing Cloud+Einstein线索评分行为分析筛选高价值线索
励销云企业公开数据库AI大数据多维度筛选2亿+企业信息精准拓客
探马SCRM私域(群/任务宝/分销)+广告导入线索自动流转+智能分配微信生态数据打通
SugarCRM广告/官网/地推多渠道数据整合+自定义查重基础线索存储与分配
Free CRM手动录入基础线索跟踪
ClickUp无直接获客
Really Simple手动录入基础线索存储

关键结论:

  • 超兔:多渠道覆盖最全面(含ToB专属的“工商搜客”),线索管理更智能(查重+归属地+ROI计算);
  • Salesforce:适合中大型企业(依赖Marketing Cloud生态),Einstein线索评分提升精准度;
  • 励销云:ToB企业精准拓客首选(AI大数据覆盖2亿+企业);
  • 探马:私域运营为主的企业(教育/零售)最佳(微信生态+广告导入)。

(二)销售能力:从“跟进”到“流程自动化”

销售是CRM的核心,关键看客户管理深度、跟单模型适配性、流程自动化程度

1. 核心能力对比

品牌客户管理特色跟单模型流程自动化特色功能
超兔一体云工商补全/权限隔离/生命周期管理三一客(小单)/商机(中长单)/多方项目(大型)自然语言AI生成工作流360°视图/自动日报/电话录音AI分析
Salesforce客户历史数据个性化策略商机跟踪/报价/预测复杂B2B审批/团队协作Sales Cloud生态
励销云基础客户存储销售流程/合同报价电销助手/外勤管理
探马SCRM企业微信客户资源管理销售过程追踪多角色协作/电销手机私域客户分层
SugarCRM自定义客户模块适配复杂流程开放API联动ERP/OA跨系统数据共享
Free CRM基础存储简单任务提醒
ClickUp无客户管理项目任务分配进度跟踪
Really Simple基础存储简单跟单

2. 超兔特色:全场景跟单模型

超兔的“三一客”“商机”“多方项目”三大模型,覆盖从小单到大型项目的全场景:

  • 三一客:针对小单快单(如零售/服务),通过“三定(定人/定时/定动作)”快速转化;
  • 商机模型:针对中长单(如设备销售),用“阶段/预期日期”管控进度;
  • 多方项目:针对大型项目(如基建/集成),整合“项目组/合同/采购/收支”全周期。

关键结论:

  • 超兔:销售能力最全面(全场景跟单+流程自动化+360°视图),尤其适合复杂项目型企业
  • Salesforce:适合中大型 B2B 企业(复杂审批流程+团队协作);
  • 探马:适合私域销售为主的企业(企业微信整合+客户分层);
  • SugarCRM:适合需要定制化流程的企业(自定义模块+跨系统联动)。

(三)订单能力:从“记录”到“全生命周期管控”

订单是销售的结果,关键看订单类型覆盖、执行流程自动化、财务联动精度

品牌订单类型执行流程财务管控
超兔一体云服务/实物/批发/定制/套餐/租赁/维修锁库→采购→发货→签收签约/开票/发货触发应收+三角联动
Salesforce标准/跨渠道审批→关联客户→集成物流需购买套餐+基础应收
励销云未明确未明确未明确
探马SCRM未明确未明确未明确
SugarCRM基础订单集成ERP执行集成ERP管控
Free CRM基础记录
ClickUp任务型订单
Really Simple基础记录

超兔特色:订单闭环逻辑

超兔的订单系统与库存、采购、财务深度联动:

  1. 订单生成→自动检查库存→锁库(避免超卖);
  2. 库存不足→自动生成采购计划→供应商确认;
  3. 发货→生成物流单号→客户实时跟踪;
  4. 签收→触发应收→关联开票/回款(三角联动,避免漏收)。

关键结论:

  • 超兔:订单能力最完善(覆盖全类型+执行闭环+财务联动),适合需要精准管控交付的企业
  • Salesforce:需额外购买套餐,适合已有物流/财务系统的企业
  • SugarCRM:适合已有 ERP 的企业(集成实现订单管控)。

(四)发货/物流跟踪:从“交付”到“透明化体验”

发货/物流是客户体验的关键,关键看跟踪可视化、状态 回传 精度、集成能力

品牌跟踪能力集成情况特色功能
超兔一体云实时查看物流状态+扫码签收原生支持+供应商直发状态回传+客户端可视化
Salesforce需集成第三方(ShipStation/FedEx)Commerce Cloud对接供应链无原生功能
励销云未明确未明确未明确
探马SCRM未明确未明确未明确
SugarCRM需集成ERP无原生功能
Free CRM
ClickUp
Really Simple

关键结论:

  • 超兔:唯一具备原生物流跟踪能力的CRM(实时状态+扫码签收),直接提升客户体验;
  • Salesforce:需依赖第三方集成(适合已有物流系统的企业);
  • 其他品牌:无原生功能,需额外工具补充。

(五)统计分析:从“报表”到“AI驱动决策”

统计分析是CRM的“大脑”,关键看报表自定义、AI预测能力、数据维度深度

品牌报表能力AI预测自定义分析
超兔一体云工作台卡片/同比环比/多表聚合自然语言AI生成工作流关联表查询+单日KPI引擎
SalesforceTableau可视化+Einstein Analytics销售成功率/客户流失预测自定义仪表盘+实时决策
励销云BI看板(销售/客户/ROI)未明确基础自定义
探马SCRM销售行为/客户转化看板未明确微信生态数据打通
SugarCRM高级报表+多维度看板未明确自定义分析
Free CRM基础业绩汇总
ClickUp项目进度/资源分配统计
Really Simple基础客户/销售汇总

超兔特色:“用数据驱动流程”

超兔的“多表聚合引擎”“关联表复合查询”能整合“获客-销售-订单-物流”全链路数据,例如:

  • 自动计算“某渠道获客的订单转化率”;
  • 分析“某销售的跟单周期与订单金额相关性”;
  • 监控“某产品的发货延迟率与客户流失率”。

关键结论:

  • 超兔:适合需要全链路数据联动的企业(多维度分析+单日KPI监控);
  • Salesforce:适合需要AI预测的企业(Einstein Analytics+Tableau);
  • 励销云:适合侧重销售业绩监控的企业(BI看板+ROI分析)。

(六)上下游协同:从“孤立”到“共生生态”

上下游协同是CRM的延伸,关键看协同方式、集成能力、数据共享精度

品牌协同对象协同方式数据共享
超兔一体云供应商/客户OpenCRM共生平台询盘/采购/报价/验收/对账
Salesforce供应商/经销商/合作伙伴MuleSoft集成+Slack/Quip系统间数据互通+跨组织协作
励销云未明确未明确未明确
探马SCRM微信生态伙伴(小鹅通/有赞)API联动私域数据共享
SugarCRMERP/OA开放API跨部门数据共享
Free CRM手动导出
ClickUp内部团队任务协作
Really Simple

超兔特色:“业务伙伴共生平台”

超兔的OpenCRM直接连接“供应商-企业-客户”,例如:

  • 供应商:通过平台确认采购单、对账;
  • 客户:通过平台确认报价、查看订单/物流、验收;
  • 企业:实时监控“供应商交货率”“客户验收率”,避免信息差。

关键结论:

  • 超兔:适合需要直接连接上下游的企业(供应商/客户协同+数据共享);
  • Salesforce:适合需要广泛集成的企业(MuleSoft连接多个系统);
  • 探马:适合私域生态伙伴协同的企业(微信工具联动)。

三、全链路闭环能力:超兔的“差异化优势”

通过上述对比,超兔一体云的核心优势在于“全链路闭环”——从获客到销售,从订单到物流,从分析到上下游,所有环节深度联动,无需额外集成。

Mermaid时序图展示超兔的闭环逻辑:

sequenceDiagram
    participant 潜在客户 as 潜在客户
    participant 多渠道 as 多渠道平台(百度/抖音/微信)
    participant 超兔 as 超兔CRM系统
    participant 销售 as 销售团队
    participant 仓库 as 仓库/物流
    participant 财务 as 财务团队
    participant 供应商 as 供应商

    潜在客户->>多渠道: 提交线索(表单/扫码)
    多渠道->>超兔: 同步线索
    超兔->>超兔: 查重+补全工商信息
    超兔->>销售: 分配线索并提醒
    销售->>超兔: 跟进生成订单
    超兔->>超兔: 锁库→生成采购计划(需补货时)
    超兔->>供应商: 发送采购单
    供应商->>超兔: 确认采购
    超兔->>仓库: 发货指令
    仓库->>超兔: 回传物流单号
    超兔->>潜在客户: 实时物流跟踪
    潜在客户->>仓库: 扫码签收
    仓库->>超兔: 回传签收状态
    超兔->>财务: 触发应收
    财务->>超兔: 关联开票/回款
    超兔->>超兔: 统计获客ROI/销售业绩/物流效率
    超兔->>销售/管理层: 生成可视化报表

四、选型建议:匹配企业需求是关键

根据企业规模、行业、核心需求,推荐如下:

企业类型核心需求推荐品牌
中大型企业(ToB/复杂项目)全链路闭环+项目管理+数据联动超兔一体云
中大型企业(B2B/生态需求)生态集成+AI预测+复杂流程Salesforce
ToB企业(精准拓客)AI大数据+2亿+企业信息励销云
私域运营企业(教育/零售)企业微信+私域工具+广告导入探马SCRM
需要定制化流程的企业自定义模块+跨系统联动SugarCRM
初创小团队(基础需求)低成本+基础客户/销售管理Free CRM/Really Simple
侧重项目管理的企业任务分配+进度跟踪ClickUp

五、结语

CRM的本质是“以客户为中心的全链路数字化”,企业选型时需避免“唯功能论”——更要关注“各环节的联动性”“流程的自动化”“数据的价值化”。

超兔一体云的“全链路闭环能力” ,为企业提供了“获客-销售-订单-物流-分析-上下游”的一站式解决方案,尤其适合需要“用数据驱动业务”的中大型企业;而Salesforce的生态、励销云的拓客、探马的私域,也各自在细分场景中具备优势。

最终,匹配企业当前阶段的核心需求,才是CRM选型的核心逻辑。

(注:文中功能相关描述均基于公开披露信息,具体功能服务与价格以厂商实际落地版本为准。)

当我们向AI大模型提问,或是让它总结一份资料时,大模型之所以能精准回应,核心就在于它能从海量文本中快速“抓出”关键信息。而让大模型具备这种“文本识物”能力的基础,正是实体识别标注。

作为自然语言处理(NLP)与AI大模型训练的核心数据支撑技术,实体识别标注通过对文本中的关键元素进行精细化标注,为机器搭建起“理解文本语义、提取核心信息”的学习框架。

一、AI大模型的文本关键信息提取器

实体识别标注,是指在AI大模型训练场景下,对文本数据中的实体进行定位、分类与属性标注的过程。

这里的“实体”,通俗来说就是文本中具有特定含义的“关键元素”,是构成文本语义的核心单元,比如人名、地名、机构名、时间、数字、专业术语等。

例如,在句子“2020年,曼孚科技在杭州推出了新一代AI数据标注平台”中,“2020年”(时间实体)、“曼孚科技”(机构实体)、“杭州”(地名实体)、“新一代AI数据标注平台”(产品实体)都是需要标注的核心实体。

与普通文本标注(如文本分类、情感分析标注)不同,实体识别标注的核心目标是“精准定位+明确分类”,不仅要找到文本中的实体位置(即标注实体的起止字符),还要明确实体的类型的属性,让机器知道“这个元素是什么”。

如果把AI大模型理解文本的过程比作“整理文件”,实体识别标注就像是给文件中的关键信息贴上“分类标签”,让机器能快速抓取核心内容,而非逐字逐句“阅读”全部文本。

作为AI大模型实现文本理解、信息提取、语义交互的关键, 实体识别标注的核心价值体现在三大层面:

1、夯实语义理解基础

实体是文本语义的“锚点”,通过标注实体的类型与关系,让机器理解文本的核心逻辑。比如通过标注“曼孚科技”(机构)与“AI数据标注平台”(产品)的“推出”关系,机器能明白“曼孚科技是该产品的研发主体”。

2、提升信息提取效率

让大模型具备快速从海量文本中提取关键信息的能力,比如从10万份医疗病历中快速提取“高血压患者”“阿司匹林”“用药剂量”等实体,从千份商务合同中抓取“甲方”“乙方”“违约责任”等核心实体。

3、支撑多场景语义交互

为大模型的问答、摘要、翻译、知识图谱构建等功能提供数据支撑。比如用户问“谁在杭州推出了AI标注平台”,大模型能通过标注数据快速定位“曼孚科技”这一核心实体并给出答案。

二、从“定位分类”到“深度理解”

实体识别标注并非简单的“圈选文本+贴标签”,而是一套融合“语言学知识、行业规则、技术工具”的精细化体系。根据AI大模型的训练需求,其技术细节可分为“基础层、进阶层、复杂场景层”等多个维度,同时配套标准化的标注流程与质量管控机制。

1、基础层:实体定位与类型标注

这是实体识别标注的最基础环节,目标是“精准找到实体、明确实体类型”,是后续所有标注工作的前提。包含两个关键步骤:

1)实体边界定位标注

即精准标注文本中实体的起止位置,确保实体边界无偏差。例如,在句子“浙江省杭州市西湖区的雷峰塔是著名景点”中,“浙江省杭州市西湖区”(地名实体)的边界需从“浙”字开始,到“区”字结束,不能遗漏“浙江省”或多包含“的”字。

标注方式通常采用“字符索引标注”,即记录实体在文本中的起始字符位置与结束字符位置,确保机器能精准定位实体在文本中的位置。

2)实体类型分类标注

在定位实体边界后,需为实体标注对应的类型。根据不同场景之间的差异,实体类型大致可分为“通用类型”与“行业定制类型”两类:

通用实体类型:适用于大多数文本场景,常见类型包括:

人名:如“张三”“马斯克”“李白”;

地名:如“北京”“西湖”“太平洋”;

机构名:如“曼孚科技”“清华大学”“联合国”;

时间:如“2024年5月20日”“上周三”“凌晨3点”;

数字:如“100万”“3.14”“五十”;

日期:如“2025年”“100周年”;

产品名:如“iPhone 15”“华为Mate60”“新一代AI标注平台”;

事件名:如“杭州亚运会”“世界杯”“双十一购物节”。

行业定制实体类型:针对医疗、金融、法律、自动驾驶等垂直领域的个性化需求,定制专属实体类型。例如:

医疗领域:疾病名(如“高血压”“肺癌”)、药物名(如“阿司匹林”“布洛芬”)、症状名(如“头痛”“发烧”)、检查项目(如“血常规”“CT扫描”);

金融领域:金融产品(如“股票”“基金”“理财产品”)、机构类型(如“银行”“证券公司”“保险公司”)、交易术语(如“开户”“转账”“平仓”);

法律领域:法律条款(如“民法典第101条”)、当事人(如“原告”“被告”“代理人”)、法律文书(如“判决书”“起诉状”);

自动驾驶领域:道路元素(如“红绿灯”“斑马线”“人行道”)、车辆信息(如“小轿车”“货车”“非机动车”)、交通标志(如“限速60”“禁止通行”)。

2、进阶层:让机器理解“实体关联”

仅完成定位与分类,还不足以让大模型深度理解文本语义。在复杂场景下,还需要标注实体的属性与实体间的关系,让机器明白“实体的特征”与“实体间的逻辑联系”。

1)实体属性标注

即标注实体的固有特征或状态,让机器更精准地理解实体。例如:

人名实体“张三”:可标注属性“性别:男”“职业:工程师”“年龄:35岁”;

疾病实体“高血压”:可标注属性“类型:原发性”“症状:头痛、头晕”“治疗方式:药物治疗+饮食控制”。

属性标注的核心是“结构化”,需将实体的非结构化特征转化为机器可理解的键值对形式(如“键:性别,值:男”),方便大模型进行特征提取与分析。

2)实体关系标注

即标注两个或多个实体间的逻辑关系,构建文本的语义网络。这是支撑大模型实现“问答交互”“知识图谱构建”的关键。常见的实体关系类型包括:

从属关系:如“曼孚科技”与“杭州”(总部位于);

因果关系:如“高血压”与“头痛”(导致)、“熬夜”与“疲劳”(引发);

关联关系:如“iPhone 15”与“苹果公司”(研发);

动作关系:如“张三”与“文件”(撰写)、“医生”与“患者”(诊疗)。

标注方式通常采用“三元组标注”(主体-关系-客体),例如“曼孚科技-总部位于-杭州”,让机器清晰掌握实体间的逻辑关联。

3、复杂场景层:特殊实体与模糊实体标注

在实际文本场景中,存在大量“边界模糊、类型复杂”的实体,这类实体的标注是行业难点,需要结合语言学知识与行业经验进行精细化处理。

1)嵌套实体标注

即实体内部包含其他实体,需分层标注。例如,在“曼孚科技(杭州)有限公司”中,外层实体是“曼孚科技(杭州)有限公司”(机构名),内层实体是“杭州”(地名),标注时需同时明确两层实体的边界与类型,避免混淆。

2)模糊实体标注

即实体类型不明确或存在歧义,需结合上下文判断。例如,“苹果”既可能是水果(物品实体),也可能是品牌(机构实体),在句子“苹果发布了新款手机”中,需标注为“机构实体”;在句子“我买了一斤苹果”中,需标注为“物品实体”。

3)多语种/混合语种实体标注

针对包含多语种的文本,需标注不同语种的实体并统一分类。例如,在“马斯克创办了特斯拉(Tesla)”中,“马斯克”(中文人名)、 “特斯拉”(中文机构名)、“Tesla”(英文机构名)需分别标注,确保大模型能识别多语种实体的对应关系。

4)缩略语/简称实体标注

针对文本中的缩略语或简称,标注其全称与类型。例如,“北大”需标注全称“北京大学”(机构实体),“GDP”需标注全称“国内生产总值”(经济指标实体)。

4、技术流程:自动化预标注+人工精修+质量管控

实体识别标注的专业性与复杂性,需依赖“技术工具+专业团队”的协同,核心流程包括但不限于:

1)数据预处理

对原始文本数据进行清洗,去除冗余信息(如特殊符号、无关空格)、修正错别字、统一文本格式(如统一日期格式、数字格式),为标注奠定基础。

2)自动化预标注

利用实体识别模型或AI自动标注工具,对文本进行初步的实体定位与类型标注,生成预标注结果,大幅降低人工标注成本。

3)人工精修标注

专业标注团队对预标注结果进行逐句审核,修正实体边界错误、调整实体类型、补充属性与关系标注、处理模糊实体与嵌套实体等难点问题。标注人员需具备语言学知识与行业专业知识(如医疗领域标注人员需了解医疗术语)。

三、实体识别标注的核心应用场景

实体识别标注数据是AI大模型文本理解能力的“燃料”,其应用场景已渗透到生活、工作、产业的方方面面,尤其在以下领域发挥着关键作用:

1、通用AI大模型与智能交互场景

这是实体识别标注最广泛的应用场景,直接影响通用大模型的语义理解与交互体验:

智能问答与聊天机器人:如ChatGPT等大模型的问答功能,需通过实体识别标注快速定位用户问题中的核心实体,并从知识库中提取对应信息回应。

文本摘要与信息提取:大模型的文本摘要功能,需通过实体识别标注提取文本中的核心实体,再基于实体关联生成简洁摘要;信息提取功能可从新闻、报告、论文等海量文本中快速抓取关键实体。

机器翻译:多语种翻译场景中,实体识别标注能确保人名、地名、机构名等核心实体的翻译准确性。

2、垂直行业应用场景

在医疗、金融、法律、自动驾驶等垂直领域,实体识别标注需结合行业特性提供定制化数据支持,推动AI大模型的行业落地:

1)医疗领域:提升诊疗效率与合规性

实体识别标注帮助AI大模型从电子病历、诊疗报告、医学文献中提取核心医疗实体,支撑临床辅助诊断、病历管理等功能。例如,从病历中提取“患者姓名”“疾病名”“症状”“用药信息”“检查结果”等实体,自动生成标准化病历报告,减少医生文书工作量;从医学文献中提取“疾病机制”“药物疗效”“临床试验数据”等实体,帮助医生快速掌握行业前沿研究。

2)金融领域:强化风险控制与决策支持

实体识别标注帮助AI大模型从金融报告、交易记录、新闻资讯中提取核心金融实体,支撑风险控制、投资决策等功能。例如,从企业财报中提取“营收”“利润”“负债”等财务实体,结合实体关系分析企业经营状况,辅助投资决策;从交易记录中提取“交易主体”“交易金额”“交易时间”“交易类型”等实体,识别异常交易(如大额频繁转账),防范金融风险。

3)法律领域:提升文书处理效率与准确性

实体识别标注帮助AI大模型从法律文书、庭审记录、法规条文等文本中提取核心法律实体,支撑案件分析、文书生成等功能。例如,从判决书、起诉状中提取“当事人”“案由”“法律条款”“判决结果”等实体,自动生成案件摘要,帮助法官快速了解案件核心;从法规条文中提取“法律术语”“处罚标准”“适用场景”等实体,构建法律知识图谱,辅助律师进行案例检索与法律分析。

4)自动驾驶领域:强化环境感知与决策

实体识别标注不仅适用于文本,还可延伸至自动驾驶的图像/语音文本融合场景,帮助AI大模型识别道路环境中的核心实体。例如,从车载摄像头拍摄的图像文本中提取“交通标志”(如“限速60”“禁止左转”)、“车牌”“道路名称”等实体;从车载语音交互文本中提取“导航目的地”(地名实体)、“车辆控制指令”(如“打开空调”“调整座椅”)等实体,支撑自动驾驶的语音交互与路径规划功能。

3、知识图谱构建场景

知识图谱是AI大模型实现深度语义理解的核心基础,而实体识别标注是知识图谱构建的“核心环节”。通过标注实体的类型、属性与关系,将非结构化文本转化为结构化的知识三元组,再基于这些三元组构建知识图谱,让大模型能快速检索实体间的关联关系,提升语义理解深度。

四、曼孚科技让AI更精准地“读懂”文本

作为AI基础设施领域的领军企业,曼孚科技已构建起覆盖“通用场景+垂直领域”的全栈实体识别标注服务体系,通过“平台工具+专业团队+质量管控”的模式,为头部大模型企业、医疗机构、金融机构、车企等客户提供高质量标注数据,推动AI大模型文本理解能力的升级。

1、定制化标注方案

针对不同行业的个性化需求,提供定制化的实体识别标注服务,精准匹配行业场景。

例如,在通用大模型领域,涵盖中文、英文、日文等各类常见语种及小语种,覆盖新闻、社交、商务等多维场景;在医疗领域,定制化搭建“疾病-症状-药物-检查项目”的专属实体类型体系,构建起一套包含3000+医疗专业术语的标注规范库。

2、平台工具+专业团队

自研AutoLabeling实体标注引擎,基于大模型技术实现实体定位、类型分类的半自动化标注,结合AI辅助修正工具,标注效率提升数倍以上。

搭建“语言学专家+行业专家+标注工程师”的跨学科团队,其中行业专家覆盖医疗、金融、法律、自动驾驶等数十个行业领域,确保标注数据的专业性与准确性。

3、合规与隐私保障

针对文本数据中的隐私信息(如医疗病历中的患者身份信息、金融数据中的用户交易信息),曼孚科技构建了全流程合规体系:

严格遵循《数据安全法》《个人信息保护法》,对涉及隐私的实体信息进行脱敏处理;

采用“本地标注+加密传输+加密存储”的多重安全策略,搭建物理隔离的标注环境,防止数据外泄;

通过ISO27001、ISO27701等体系安全认证,全程追溯数据处理行为,确保合规可查。

五、未来趋势

实体识别标注是AI大模型“读懂文本”的关键前提,看似基础性的数据加工工作,却融合了语言学、行业知识、技术工具等多领域的专业能力。

从通用大模型的智能问答,到医疗领域的病历管理,再到金融领域的风险控制,实体识别标注都在背后发挥着不可替代的作用。

未来,实体识别标注将聚焦于进一步提升自动化标注水平、注重多模态实体融合标注等关键领域,推动标注的效率与精度的不断提升,推动智能时代的文本处理能力实现质的飞跃,从而支撑AI大模型实现更深度的语义理解与更广泛的行业落地。

袋鼠云在 2025 年,对“数据智能到底该怎么落地”这件事,逐渐形成了一套比较清晰的结构性认识,用一句话概括,就是 1 + N + X。

1——指的是一个智能体应用开发平台。

在 To B 场景下,真正的挑战并不是“能不能接大模型”,而是企业能不能持续、可控地构建和运行多个智能体。所以我们在这一层重点做的是平台能力:模型统一接入、权限与成本控制、工作流编排、运行监控,让智能体这件事从一次性尝试,变成可以长期运行的基础能力。

N——是围绕高频业务场景沉淀的场景智能体。
包括数据开发、数据分析、指标使用、报告生成、策略管理、数字人等具体场景。这些智能体围绕明确任务,在多个项目中反复被使用和打磨,逐步形成一组可复用的能力集合,解决的是“数据智能到底怎么用”的问题。

X——是行业智能体。
当场景能力在真实业务中反复验证之后,我们会进一步结合不同行业的数据结构、指标口径和管理方式,把能力固化成行业可复制的形态。这一层解决的,是“怎么在同一行业里持续复用经验”的问题。

所以从整体上看,1 + N + X,不是一种产品组合,而是一条数据智能从“可构建”到“可使用”,再到“可复制”的落地路径。

1 | 智能体应用开发平台AIWorks

2025 年,数据智能在平台层面的核心工作,集中在 AIWorks 智能体应用开发平台的持续建设与完善。

围绕企业级使用场景,AIWorks 完成了对多种主流大模型的统一接入与管理,支持公有模型与私有化模型的灵活部署,并结合权限控制、调用策略、资源隔离与运行监控等能力,满足企业在安全性、稳定性与成本控制方面的实际需求。模型不再以“单次调用能力”存在,而是被纳入统一管理体系,成为可被持续使用和治理的基础能力。

长按上方二维码可获取AIWorks产品白皮书

在模型接入之上,平台系统性补齐了智能体构建所需的基础能力,包括提示词管理、上下文与会话管理、知识库接入、多模态内容解析、函数调用与代码执行等能力,使智能体能够处理更复杂的输入形式,并具备调用企业内部系统与外部服务的能力。在 AI 基础设施层,AIWorks 结合大模型一体机与模型微调服务,支持企业在私有化环境中部署和运行大模型,满足高安全等级场景的使用要求。

在智能体构建方面,平台进一步强化了工作流与任务编排能力。通过可视化方式将模型调用、知识检索、数据操作、业务规则判断、API 调用等能力组合为可配置流程,智能体可以围绕明确目标执行多步骤任务,而不仅限于单轮问答或简单应答。这一能力使智能体能够参与到更复杂的业务过程中,在数据处理、运维支持、业务辅助等场景中承担连续性工作。

在运行与管理层面,AIWorks 支持智能体的统一发布、运行监控与版本维护。已构建的智能体可以被重复调用,并以 API 或组件形式嵌入不同业务系统中使用,支持多环境部署、多版本管理以及调用链路与日志的统一监控。通过对运行状态、调用情况和异常问题的持续观测,智能体逐步具备了在企业环境中长期运行和持续演进的条件。

通过上述能力建设,AIWorks 在 2025 年逐步形成了面向企业环境的智能体开发与运行底座,为上层场景智能体与行业智能体的构建提供了统一、稳定的基础支撑。

N|场景智能体:让“数据生产力”触手可及

在平台能力之上,2025 年数据智能重点围绕高频业务场景,持续沉淀场景型智能体能力。

在数据开发与运维场景中,围绕 SQL 编写与续写、SQL 解释与优化、日志智能解析、任务失败诊断等高频工作,逐步形成了面向数据开发与运维人员的场景智能体。这类智能体能够辅助完成常见的数据处理与问题定位任务,缩短排查链路,减少人工分析成本,并提升数据任务运行的稳定性与效率。

在数据分析与指标使用场景中,结合 AIMetrics 智能指标平台,持续完善智能问数、指标查询、指标解读与分析辅助能力。业务人员可以通过自然语言方式直接获取指标结果,系统在背后完成指标语义解析、计算路径匹配与权限校验,并结合结构化分析能力,辅助完成基础判断与解读,显著缩短从提出问题到获得结论的时间。

长按扫描下方二维码,无需等待即可获取业内首本《指标+AI数智应用》

围绕管理与决策场景,2025 年 AIMetrics 在指标体系之上进一步延展了目标与策略类能力,支持将核心经营目标分层拆解为可追踪的指标体系,并与策略动作、责任归属、过程监控与复盘评估进行关联。在与 中国银联客户 的共创过程中,我们围绕指标口径统一、目标分解路径、策略动作沉淀、过程追踪与复盘机制等环节持续迭代,形成了更贴近大型组织经营协同的使用方式,使指标不止用于“看数”,也可用于“管事”。

围绕数据使用的延展场景,数据智能还逐步沉淀了报告生成、文档辅助、知识库问答等场景智能体能力。这些智能体通过与企业内部文档、指标体系和业务知识的结合,支持自动生成分析报告、快速检索内部资料,提升数据成果在业务中的复用效率。


在上述数据开发、分析与指标应用之外,2025 年我们也开始将数据智能进一步延展至更贴近业务现场的空间化场景。通过数字孪生智能体,将设备、产线、园区等物理对象与实时数据、业务指标和运行规则进行统一建模,使智能体能够在空间语境下理解运行状态,并围绕监测分析、异常识别与运行推演等任务发挥作用。数据不再只是被“分析”的对象,而是能够直接参与到实际运行与管理过程之中,帮助业务人员在更直观的空间视角下完成判断与决策。

在此基础上,2025 年我们也逐步引入数字人智能体,作为连接用户与各类场景智能体的统一交互入口。通过语音、文本与多模态交互方式,数字人可以理解用户意图,并在后台调度相应的场景智能体完成指标查询、数据解读、业务说明或操作指引等任务。这种形态降低了数据智能的使用门槛,使复杂的数据能力能够以更自然的方式被业务人员感知和使用,进一步扩大了数据智能在组织内部的触达范围。

上述场景智能体均围绕明确任务展开,已在多个项目中被反复使用。通过不断优化交互方式、执行路径与结果质量,逐步形成了一组可复用的场景能力集合,覆盖数据开发、数据分析与日常数据使用等核心环节,为数据智能的规模化应用提供了现实基础。

X|行业智能体:在真实业务中持续打磨沉淀行业know-how

在场景能力的基础上,2025 年数据智能进一步向行业智能体方向推进。围绕能源、矿产、制造、高校等行业,在具体项目中结合行业数据结构、指标口径、业务规则与管理流程,构建面向行业使用的智能体能力。这些行业智能体不仅具备通用的数据处理与分析能力,还融入了行业特有的业务语义、指标体系与分析逻辑,使其在结果呈现与解读层面更加贴合行业实际。

袋鼠云行业智能体并非独立产品形态,而是在平台能力与场景能力基础上的组合与沉淀。通过在多个行业项目中反复应用与调整,逐步固化通用方法与实践经验,形成可复制的行业能力模型,为后续在同类行业中的推广与复用提供基础。

回到最初的问题,我们在 2025 年反复思考的,是“数据智能如何真正落到企业的日常运行中”。通过 1 + N + X 的推进路径,我们逐步厘清了从平台能力建设,到场景智能体落地,再到行业经验沉淀的完整链路。数据智能不再是一组零散能力的叠加,而是能够被持续构建、稳定使用并在行业中不断复用的体系化能力。这也为后续在更复杂业务场景中的深化应用,奠定了清晰而可持续的基础。

展望 2026 年,我们将继续沿着这一路径向前推进,但重点将从“能力成型”转向“规模化运行与持续演进”。在平台层,智能体应用开发平台将进一步强化稳定性、治理能力与运行效率,使智能体真正成为企业长期可依赖的基础设施;在场景层,我们将围绕更多高频、关键业务环节持续打磨场景智能体,让数据智能更深地嵌入日常工作与业务流程之中;在行业层,则通过更多真实项目的积累,不断沉淀行业 know-how,推动行业智能体从“可用”走向“成熟可复制”。这将是我们在 2026 年乃至更长时间内,持续投入与演进的方向。

身边还没有遇到喜欢京剧或其它戏曲的程序员,不知道在 V 站情况如何?

分享一下我喜欢的京剧唱段(不太喜欢全本,太冗长了),也希望大家分享一下自己的曲库。

Creating Bash Alias with Arguments

Bash 别名是一种快捷方式,允许您使用更短或更简单的命令来表示更长的或更复杂的命令。在本文中,我们将探讨如何创建带有参数的 Bash 别名。

Creating a Bash Alias

您可以使用 alias 命令在 Linux 系统中创建别名。

alias alias_name='command'

例如,以下命令以长格式列出 /var 目录下的目录,并过滤输出以只显示目录。

ls -l /var | grep "^d"

要为该命令创建别名,可以使用以下 alias 命令:

alias lsdir='ls -l /var | grep "^d"'

Creating Bash Alias with Arguments

Bash 别名不接受参数,但我们可以创建一个接受参数的函数接受命令行参数。这些函数可以用作Linux 系统中的别名。例如,考虑以下内容函数定义:

lsdir() { 
    ls -l $1 | grep "^d"; 
}

这个别名定义创建了一个名为 lsdir 的别名,它接受一个参数 ($1) 表示要列出的目录。要使用此别名,可以传递目录作为调用别名时的参数,例如:

lsdir /etc

这将以长格式列出 /etc 目录中的目录,并过滤输出以只显示目录。

How to Create Bash Aliases with Parameters

Setup Permanent Bash Aliases

要使别名永久存在,可以在 ~/.bashrc 中添加 alias 命令。这将确保每次启动新的 Bash 会话时该别名都可用。

vim ~/.bashrc

在脚本末尾追加以下内容:

lsdir() {
    ls -l $1 | grep "^d";
}

How to Create Bash Aliases with Parameters

然后执行 source 命令更新当前的 shell 环境。

source ~/.bashrc

今天被一张《IT 开发工作可能要完全重组》的图片刷屏,图片中的观点是:传统的「产品-设计-前端/后端」模式在 AI 时代将被变革。

很多人会觉得“前端没有实际的必要了”是管理者自嗨,但就我个人的见闻而言,这可能真的是未来趋势。

基于 AI 的一专多能“超级个体”模式已经在很多公司铺展开,未来不久程序员大概率会不分前后、只剩全栈。

之所以敢这么笃定,是因为今年我亲身经历了这个变化。

简单聊聊我的工作变化

今年我的工作 80% 都是 AI 相关,工作内容上有三个比较大的转变:

技能层面:从“纯前端技术”转向“产品设计+AI内容生产+代码实现”的复合能力(例如:结合自身的冥想经历,提出并开发上线冥想呼吸练习功能)。
协作层面:从“与产品/后端对接”转向“与AI协同+跨部门整合”(例如:直接参与产品需求设计,用 AI 快速做 demo、上线验证方案可行性)。
成果层面:从“交付代码”转向“交付「产品+技术」解决方案”(例如:用 AI 生成热点资讯)。

工作时间分配上,也从之前的「大部分时间手写代码」变成了:

20% 的时间:手写代码(一般是改 bug)
30% 的时间:指挥 AI 写代码、review、accept/undo、cmmit & push
30% 的时间:优化提示词的效果
20% 的时间:和 AI 碰撞点子和改进方案

在我做的这些项目里,正如文章开头的图片所说,完全没有前后端岗位的概念,基本上都是和业务方沟通完需求、确定好方案,就开发、上线,甚至有的需求我自己定方案(在 AI 的加持下)。

插播一则机-会

技术大厂,前端-后端-测试,全国均有机-会,感兴趣可以试试。待遇和稳定性都还不错~

前端是不是真的没有实际的必要了

那么问题来了,前端/后端以后是不是就不需要这么多人,大家要失业了?

我的看法是:程序员这个岗位的确会变少,但适合我们的新机会也随之诞生了。

随着大模型的编程能力提升和配套设施完善,代码开发的 AI 化必定会发展到 80% 甚至 90%(至少还需要 10~20% 的人把关)。

如果只盯着程序员的「把需求文档实现为代码」这个职能,我们的机会是越来越少的。

但如果着眼于使用 AI 进行业务流程改造和内容生产,机会会越来越多。

最近两年开始,很多公司开始招聘名为「AI 工程师」的岗位,他们的工作内容就是业务优化和 AIGC。这个岗位招的人呈两极分化:要么是年轻的高学历应届生、要么是经验丰富的资深开发者。

招高学历应届生是因为他们具备创新和挑战精神;而招资深开发者转型 AI 应用,是因为他们有业务经验、全栈能力更强。

我今年的岗位角色就是 AI 工程师,在带着这种视角工作时,会发现有太多可以做的,以前凭感觉定的都可以用 AI 重做一遍,AI 工程师目前还远远不够。

想想我们的产品里有多少文案是写死的?有多少数据是无人问津的?有多少策略是拍脑袋定的?这些都是 AI 工程师可以改造优化的点。

总结

忍不住多写了几句,一看表这么晚了,年纪大了不能熬夜,总结一下结束此文。

技术变革就是会让生产效率提升,让工具性的岗位变少(程序员说白了就是把人的语言翻译为机器语言),但也会催生出新的岗位,我们要向前看。

从感性上我们是不愿意接受的,怎么革命偏偏革到了我们头上?我的房贷还没还完呢,以后可怎么办呢?

别慌,就我今年的经验来看,这一波 AI 技术革命,作为软件开发的我们有先发优势,只要稍加学习,再加上一些业务思考,很容易就可以转型到 AI 工程师。

至于如何转型到 AI 工程师,容我结合今年的工作&学习经验梳理下,也欢迎感兴趣的朋友留言讨论你们的看法。

滚滚长江东逝水,乘风安逸逆风衰,晚安朋友。

——转载自:张拭心

导读:面对海量多模态数据管理困境,思必驰通过构建以 Apache Doris 为核心的数据集平台,实现了数据从“散、乱、滞”到“统、明、畅”的转变。在关键场景中,存储占用下降 80%、查询 QPS 提升至 3w,不仅实现可量化的效率提升和成本优化,更系统化地提升了 AI 研发效率与模型质量。

本文整理自 思必驰数据中台架构师魏凯君在 Doris Summit 2025 中的演讲内容,并以演讲者第一视角进行叙述。

思必驰作为专注于对话式人工智能的平台型企业,围绕“云+芯”战略布局,致力于提供软硬件结合的全链路 AI 产品与服务。在长期服务智能车载、家居等终端场景中,我们积累了海量的多模态训练语料(包含音频、文本及人工标注)。

早期的数据管理方式逐渐成为 AI 研发的瓶颈。各业务团队的标注数据分散在不同的存储系统中,依赖人工进行维护和同步。随着数据规模快速增长至 PB 级别,传统方式在三个方面面临严峻挑战:

  1. 数据一致性问题:同一份数据在不同团队中存在多个副本,且更新不同步,影响模型训练的一致性。
  2. 协同效率低下:算法工程师难以快速查找、复用跨团队的数据资产,重复标注与数据准备浪费了大量时间。
  3. 版本追溯困难:模型迭代时,无法精准关联训练所使用的数据版本,导致问题复现与效果归因困难。

这些问题使得数据资产化与高效协同成为制约 AI 研发规模化的关键。为此,我们决定构建一个统一的数据集管理平台,目标是将原始数据标准化、资产化,打造一个支持高效调用、可靠追溯、安全共享的“AI 数据基座”

为何是 Apache Doris?

思必驰与 Apache Doris 的合作始于早期技术实践。在 Doris 0.12 版本时期,我们率先将其应用于内部实时数仓场景,并随业务发展,逐步建立起面向外部服务的 Doris 集群,支撑了包括实时看板、用户画像与自助分析在内的多项数据能力。

此外,Doris 在海量业务日志场景(容器日志)中也发挥了关键作用,替代了原有的 Elasticsearch,并基于 Doris 自建日志查询平台,服务智能座舱语音业务。在同等硬件资源下,日志写入性能从原来的 100w/s 提升至 300w/s,存储成本也降低了 50% 以上。

基于 Doris 在性能、成本、稳定性方面的综合优势,在构建数据集平台时,它自然成为数据底座的首选。我们的新场景对数据库提出了更高要求:

  • 海量数据去重与高效查询:需处理 10 亿级样本的快速去重与复杂筛选。
  • 完善的版本管理:需支持数据集的版本化存储、快速切换与对比。
  • 支持向量检索能力:为后续的相似样本检索、特征比对提供支持。
  • 高性价比存储:需利用高效压缩与冷热分离,降低 PB 级数据的存储成本。

综合评估,Apache Doris 在满足上述核心需求的同时,其简洁的架构、易用的运维以及活跃的社区,使其成为最优方案。

面向 AI 大规模训练的数据基座

我们采用类 MLOps 理念,设计了贯穿数据-模型-应用的标准化流水线。

面向 AI 大规模训练的数据基座.PNG

  • 数据预处理:原始的多模态数据(语音、文本等)通过采集、回流进入系统,经由专业的标注平台进行加工,再进入 AI 数据前台进行清洗与特征提取。
  • 数据集管理系统:经过预处理的数据,汇入 基于 Apache Doris 构建的数据集管理系统(即本文核心) 。该系统是整个 AI 中台的关键,负责数据的版本化存储、管理与发布,为模型训练与测试提供数据支撑。
  • 模型训练及管理:测试数据集进入模型训练系统进行训练,生成的模型经模型管理平台统一管理,最终部署上线,服务于业务应用。

由上图可知,数据集管理系统被囊括在 AI 中台这一架构中。纵观整个 AI 中台,主要包括三个部分

  • 数据管理系统:基于 Apache Doris 和 Elasticsearch 构建,提供页面、客户端和相应的 SDK;
  • AI 平台:基于推理与训练框架,以及资源管理与任务调度框架构建;同样提供页面、客户端和 SDK。
  • 底层基础设施:涵盖计算层、分布式存储体系及优化后的网络层。

面向 AI 大规模训练的数据基座-1.png

为满足不同业务场景需求,数据集管理 系统设计了单中心和多中心两种部署架构:

  • 单中心:面向核心研发场景,数据访问统一指向本中心的 Apache Doris、Elasticsearch、Kafka 及相关文件系统,保证最强的一致性与性能。

面向 AI 大规模训练的数据基座-2.png

  • 多中心:面向跨地域或异构计算资源场景, 采用分布式设计。主中心的数据层使用 Apache Doris,各分中心采用独立的分布式文件系统,这些存储之间可以实现数据的相互同步。针对各个中心的训练任务,系统能够读取这些分布式文件存储中的数据进行训练。

面向 AI 大规模训练的数据基座-3.png

数据版本毫秒级切换,存储占用下降 80%

过去,我们依靠人工在文件系统中维护数据集目录,随着版本激增,混乱与错误难以避免。新平台需要实现类似代码库的版本管理能力(对比、切换、回滚)。

为此,我们利用 Doris 的特性进行改进:

  1. 列式存储:将标注信息等结构化数据从文本文件迁移至 Doris 表,利用列式存储的高压缩特性,存储空间占用降低 80%以上
  • 分区表实现版本化:以数据集版本作为分区键。最新活跃版本存放在 SSD(热存储),历史版本自动迁移至 HDD(冷存储),SSD 使用率降低 30%以上
  • 表结构设计:核心围绕数据集表,关联文件表标注表。通过分区机制,实现了毫秒级的历史版本数据检索与切换。

数据版本毫秒级切换,存储占用下降 80%.png

精准溯源检索,查询 QPS 提升至 3W

为解决模型训练后与原始数据脱节这一核心痛点,数据集平台内置了样本溯源能力。传统的流程在完成特征提取后,往往丢失了原始数据的属性与标注信息,导致两大问题:模型无法关联其“数据血缘”,以及不同模型版本间难以进行有效的对比调优。为此,我们确立了样本 ID 全局唯一的核心要求,以此支撑精准的溯源与检索

在样本检索实现初期,团队采用 Apache Doris 的 IN 查询方式支撑相关能力,而面对瞬时并发的规模点查请求时,会有明显资源与性能开销,部分节点峰值可达 80%。

为此,团队基于 Apache Doris 的相关能力进行优化,主要采用两类改进

  • 首先,根据“高频点查”这一核心特征,切换至行式存储并优化 I/O 路径,使单次查询更快。
  • 其次,通过全面启用预处理语句,将查询计划固定下来,避免了大量的重复计算开销。

优化后,在现有配置下,查询 QPS 提升至 3 万/秒;同时在高频点查询期间,CPU 占用由原先约 80% 降至约 10%,并持续稳定

平台收益:可量化的效率提升与成本优化

在平台落地后,形成了可量化的建设成效:数据集规模超过 1 万个,数据总量超过 500TB,样本数量超过 10 亿,平台使用人数超过 200 人。通过新旧架构对比,新平台在三个维度带来了显著收益:

  • 成本大幅优化:通过消除数据冗余拷贝,存储成本降低 20% 以上,网络成本节约超 3 倍。
  • 效率全面提升:数据查询效率提升超 3 倍,数据同步效率提升超 2 倍。
  • 研发显著提效:模型研发流程效率提升 20% 以上,且数据集使用得以全面规范。

更重要的是形成了不可替代的隐性价值:

  • 统一了数据质量标准:公司内研发、测试、业务团队使用同一套数据和规范,从根本上保障了模型输入的一致性。
  • 增强了问题复现能力:任何模型结果均可精准追溯至对应的训练数据集与版本,使得问题调试、效果归因有据可依。
  • 实现了流程自动化闭环:结合自动标注系统,实现了从数据回流、清洗、标注到训练的数据闭环,极大提升了 Badcase 的定位与修复效率。

未来规划

基于当前的成功实践,未来我们将继续深化 Apache Doris 的应用,推动数据架构向更先进的方向演进:

  1. 日志分析场景全面替换:已在 TPS 15 万量级场景完成验证,将加速推进用 Doris 替代 Elasticsearch,预计进一步降低日志处理总成本。
  2. 拥抱 Doris 4.0 新特性:重点关注并计划升级至 Doris 4.0 版本,利用其向量检索能力,支持更复杂的相似性查询与 AI 原生应用。
  3. 探索湖仓一体架构:打破数据孤岛,实现数据在数据湖(低成本存储)与数据仓库(高性能分析)间的自由流动与统一管理,支撑 SQL 查询、机器学习等多样化负载。
  4. 推进存算分离落地:实现计算资源的按需弹性伸缩与负载隔离,并将冷数据沉降至对象存储,在提升资源利用率的同时,追求极致的存储成本效益。

2025 年 1 月 7 日,美国卫生与公众服务部和农业部联合发布了新版《美国膳食指南,2025-2030 版》。在美国政府的官方网站上,他们是这样描述这份指南的「在特朗普总统的大胆领导下,本版《美国膳食指南》将重置联邦营养政策,将我们的家庭和孩子放在首位,迈向更健康的国家。」配套的还有一个很特朗普风格的口号「Make America Healthy Again」。

为什么需要「再次健康」?因为美国正面临严峻的公共健康危机:50% 的美国人患有糖尿病前期或糖尿病,75% 的成年人至少有一种慢性病,近 90% 的医疗支出用于治疗慢性病。而这些疾病大多与饮食和生活方式密切相关。

面对这样的局面,新指南给自己的定位是「重置营养政策」,这个措辞本身就很耐人寻味。美国官方亲自下场「打脸」自己过去几十年的营养建议?按理说,美国作为营养学研究的领跑者,这种政策层面的重大转向本应具有相当的引导意义。但考虑到这份文件浓厚的特朗普色彩,又让其多了几分不靠谱的感觉。

那么,这份指南究竟讲了什么?强调了哪些内容?又有多少参考价值?抛开其他因素,我们就事论事,来聊聊这份最新的美国膳食指南。

作者按:后续内容是我个人阅读指南、查阅资料后重新归纳总结的,和原指南内容及结构并不完全相同,仅代表个人观点。有条件的读者可以从开头链接自行阅读原指南文件,仅 10 页内容,轻松易读。

一条核心理念:吃真实的食物(Eat Real Food)

在这份指南的第一页,开宗明义提出了一个简单直接的核心理念:「吃真实的食物(Eat Real Food)」。

看到这里小伙伴就要问了:真实的食物?难道我之前吃的是假的吗?

什么才算「真实的食物」,我在官网找到了一个明确的定义:

完整的或最小加工的、可被识别为食物的食品。用很少的原料制备,不含添加糖、工业油脂、人工香料或防腐剂。

这里主要强调了两个核心特征:一是食物的完整性与原型形式,比如更推荐完整的蔬菜水果,而不是果汁或提取物;二是成分的纯净性,一个有趣的说法是,如果你奶奶看不懂配料表上的成分,那它大概率不是「真实的食物」。

为什么要强调这些?因为真实的食物是一个「整体」,而不是营养素的简单堆砌。拿一个橙子和一杯橙汁来说,从营养成分表看,两者的维生素 C 含量可能差不多。但橙子有完整的膳食纤维,消化吸收慢,血糖反应平稳,饱腹感强;榨成汁后,纤维没了,糖分浓缩了,一杯下去血糖飙升,而且很快又饿了。同样的来源,最终对身体的影响却截然不同,而这种差异是营养成分表体现不出来的。

指南中还用了一个词叫「营养密集」,真实的食物用更少的热量提供更多的营养。而超加工食品恰恰相反:为了延长保质期、改善口感、降低成本,它们往往会去除部分天然成分,同时添加糖、盐、油脂和各种添加剂,提供的往往是「空热量」。在之前的一项随机对照实验中,研究人员就发现:在营养素构成尽量匹配的前提下,让同一批受试者分别吃「超加工食物」和「未加工/最低加工饮食」,结果在超加工阶段人们会吃得更多、体重更容易上升。1

来源:Ultra-Processed Diets Cause Excess Calorie Intake and Weight Gain: An Inpatient Randomized Controlled Trial of Ad Libitum Food Intake.

这也解释了为什么之前的思路有其局限性。过去几十年里,主流论断更偏向营养素化的表达(如低脂、低热量),这在食品工业环境中产生了副作用。例如,我们每天要摄入多少克的蛋白质;要摄入多少克的碳水化合物;要控制热量和脂肪,仿佛健康饮食是一道精确的数学题。当专家们告诉你「脂肪是敌人,需要控制」时,食品厂家就会推出各种「低脂」的产品。这些产品脂肪确实少了,但为了弥补口感可能会添加更多的添加剂。在旧框架下,这些食品是完全「达标」的,却恰恰是典型的超加工食品。

理解了这一点,也就不难理解这次转向的逻辑了。

而这种转向并非拍脑袋的决定。2024 年发表在《英国医学杂志》的一项大型伞状研究(伞状研究是将 Meta 分析的研究结果再进行进一步的分析,证据等级更高),汇总了近千万人的数据。结果显示,超加工食品与多种健康风险显著相关:全因死亡风险升高 21%,心脏病死亡风险升高 66%,2 型糖尿病风险升高 40%。更值得玩味的是,所有研究中没有一项发现超加工食品对健康有任何益处。2

可以看的出来,其实这个观点与近几年研究的主流方向是相符合的,并非食什么「惊世骇俗」的新发现。说是「重置」,我个人都觉得有点夸大其词了,多少带点政治宣传的意味。但抛开措辞不谈,这确实代表着官方思维模式的一次转变。只不过学界早就在往这个方向走了,这次是官方正式承认并总结了这种转变。

但无论如何,至少在这个核心理念上,它是有扎实的研究和证据支撑的。

三条优先级变更:倒置的膳食金字塔

除了核心理念的转变之外,新版本指南最引人注目的变化是膳食金字塔的倒置。这一视觉符号的改变不仅仅是设计上的更新,而是营养结构优先级的重新排序。

1992 年,美国发布了一个非常经典的膳食金字塔模型:面包米饭面条等稳稳占据底座,建议摄入最多;往上是蔬菜水果;再往上才是奶制品和肉类;而油脂和糖蜷缩在最顶端的小三角里。这个图像影响了整整一代人对「健康饮食」的理解。

而新金字塔的上部,也就是最应该优先吃的部分,分为了左右两个部分:左边是蛋白质、乳制品和健康脂肪;右边是蔬菜水果。而曾经的「饮食基础」谷物,如今被压缩到了最窄的底部,并且特别标注了「全谷物」。

这种变化,正对应着三大基本营养素——蛋白质、脂肪、碳水化合物——结构和优先级的调整。

变更一:蛋白质优先,每餐先把蛋白质吃够

新版膳食金字塔最显眼的变化,是蛋白质从需要限制的中间位置跃升到了最重要的顶端。指南中的措辞相当直接:「每一餐都优先考虑高质量蛋白质。」换句话说,有条件的话,要优先把蛋白质吃满,再考虑搭配其他食物。

具体的摄入目标是每公斤体重 1.2-1.6 克/天,比过去的 0.8 克几乎翻了一倍。对于一个 70 公斤的成年人来说,这意味着每天需要 84 - 112 克左右的蛋白质,而不是过去的 56 克。这个数字听起来有点抽象,换算成食物大概是这样:100 克蛋白质约等于 500 克瘦肉(两大块鸡胸或两大块牛排),或者 1 千克豆腐,又或者 15 个鸡蛋。当然,没人会只吃一种食物,实际操作中把鸡蛋、家禽、海鲜、红肉、豆类、坚果这些动植物的优质来源搭配着吃就好。

这种变化,本质上是从「防止缺乏」到「促进最优」的一次拨乱反正。

1950 年代起,「饱和脂肪导致心脏病」逐渐成为营养学界的主流共识。而肉、蛋、奶这些优质蛋白来源恰好也含有脂肪,于是一并被打上「要限制」的标签。而限制了蛋白质和脂肪的摄入量,剩下的热量缺口自然只能由碳水来弥补。碳水因为脂肪含量极低,被视为「安全的」能量来源,占据了主要位置。

这个过程中还有一些不太光彩的推手:1970 年代美国谷物过剩,膳食指南某种程度上成了消化库存的政策工具;糖业基金会资助的研究刻意淡化糖的危害、把矛头指向脂肪;肉类和乳制品行业的游说甚至让 1991 年原定发布的金字塔推迟了一年,最终版本里谷物的推荐量比营养学家最初的建议还要高。科学、政治、商业在一碗饭里搅作一团,最后端上桌的那份「权威建议」,早已不是纯粹的科学结论。

然而,近年来的研究动摇了「脂肪有害」这个前提(详见下文),那些「因为含脂肪而被限制」的蛋白质食物,自然该重新审视。科学家们回过头来发现,过去 0.8 克/公斤的推荐量,本就是为了「防止缺乏」而设定的最低标准。就像及格线是 60 分,但没人会觉得考 60 分是最佳状态。

一方面,支持提高摄入的证据在不断积累:近年来多项大型研究表明,更高的蛋白质摄入与更好的血糖控制、更强的饱腹感、更健康的肌肉和骨骼密切相关。同时,对于中老年人而言,充足的蛋白质更是预防肌肉流失的关键。

另一方面,目前也没有足够证据证明高蛋白饮食有害。2018 年的荟萃分析显示,高蛋白摄入不会对健康成年人的肾功能产生不良影响;肝功能方面同样没有发现危害证据。3

但「没查出问题」和「确定没问题」是两回事。4

首先,目前的这些研究大多持续时间不超过 6 个月,长期影响仍不确定。

第二,蛋白质来源很重要。一项涉及近 12000 人的研究发现,红肉和加工肉类摄入较高会显著增加慢性肾病风险,而用植物蛋白替代红肉则与风险降低相关。同样是高蛋白,鱼、禽、蛋、豆类和培根、香肠、午餐肉,对身体的影响可能截然不同。5

此外,还应警惕高蛋白对肠胃的负担,酸碱平衡的紊乱风险,以及可能带来的免疫炎症反应等。如果你平时蛋白质吃得不多、肠胃功能偏弱,提升比例时应该循序渐进。如果是已有肾病、肝病、痛风或其他免疫代谢等方面的疾病,贸然提高蛋白质摄入可能带来风险,调整饮食前最好先咨询医生。

而且,通常当每天的摄入量超过 1.5-2.0 克/公斤体重时,才会被研究正式视为「高蛋白饮食」。指南推荐的量仅是卡在界限上下,并非无脑鼓吹「高蛋白饮食」。

总之,蛋白质的「优先级提升」对大多数健康人是好的选择,但不意味着可以无限制吃。更合理的做法是:优先选择优质蛋白,适量提升比例,警惕加工肉制品。

变更二:为脂肪正名,适量摄入健康脂肪

如果说蛋白质是「升级」,那脂肪可以说是「正名」。

过去对脂肪的恐惧,源于「饱和脂肪导致心脏病」的假说。但近年来的研究对这一假说提出了质疑,需要更细致地看待证据。2015 年《英国医学杂志》发表的荟萃分析综合了数十万人的数据,发现饱和脂肪与心血管疾病死亡率、全因死亡率均无显著关联。62020 年,被认为是循证医学最高标准之一的 Cochrane 数据库发表了一篇系统综述,结论更加复杂:减少饱和脂肪摄入确实能使心血管事件风险降低 17%,但对全因死亡率、心血管死亡率无显著影响。7

饱和脂肪可能不是我们曾认为的那个「大 Boss」,但也不是完全无害。它或许不是什么健康食品,但也没有罪大恶极到需要赶尽杀绝。而且,脂肪本身就是不可或缺的营养素,在人体中扮演着多重角色。脂肪的缺乏可能会影响维生素 A、D、E、K 的有效吸收;影响类固醇激素,包括雌激素和睾酮的合成;以及影响能量代谢和血糖稳定等。

真正值得警惕的是反式脂肪。研究显示,反式脂肪与全因死亡率升高 34%、冠心病死亡率升高 28%显著相关。8两者的关键区别在于来源:饱和脂肪主要来自天然动物油脂和部分植物油,而反式脂肪主要是工业加工的产物,常见于氢化植物油、人造黄油、酥皮糕点和油炸食品中。过去我们把「天然脂肪」和「人造脂肪」混为一谈,虽然没有放过后者,但确实可能过度妖魔化了前者。

指南中也明确列出了健康脂肪的来源:肉类、鸡蛋、富含 ω-3 脂肪酸的海鲜、坚果、种子、全脂乳制品、橄榄和牛油果等。烹饪用油方面,优先推荐含有必需脂肪酸的橄榄油,黄油或牛油也可以作为选择。

不过,「为脂肪正名」不等于「敞开了吃」。需要强调的是,上述研究只是说饱和脂肪与那些非常严重的健康风险没有显著相关性,并不代表多吃饱和脂肪有什么额外的健康益处。这一点在学界仍有争议,指南也没有给出定论,而是建议饱和脂肪一般不超过总热量的 10%。

这个 10% 是什么概念?对于一个每天摄入 2000 大卡的成年人来说,饱和脂肪的上限约为 22 克,大致相当于 100 克五花肉、或 3 杯全脂牛奶、或 1 块牛排中的饱和脂肪含量。所以,你依然没法放肆地大口吃红烧肉、狂喝全脂奶。

新指南的核心信息是:不必过度恐惧天然脂肪,但适量、均衡,仍然是不变的原则。

变更三:碳水化合物降级,从基础到配角

如果说蛋白质是「升级」,脂肪是「正名」,那碳水化合物就是「降级」。

1992 年的膳食金字塔建议每天摄入 6-11 份碳水,是所有食物中最多的。新指南将全谷物推荐量压缩到每天 2-4 份,并用「显著减少」来形容精制碳水。白面包、即食早餐麦片、饼干被明确点名批评,指南更认可全谷物:燕麦、糙米、藜麦、真正的全麦面包等。

这种「降级」有其理论基础。从生理角度看,存在「必需氨基酸」和「必需脂肪酸」。这些成分人体无法自行合成,必须从食物中获取。但却不存在「必需碳水化合物」,人体可以通过糖异生作用,从蛋白质和脂肪中自行合成葡萄糖。这意味着在热量分配上,碳水的「可替代性」最高。当我们提高蛋白质和健康脂肪的优先级时,自然需要相应减少碳水的比例。

减少精制碳水、增加全谷物,这个方向也有充分的证据支持。《柳叶刀》的一篇系统综述分析了上百项前瞻性研究,发现膳食纤维摄入量最高的人群相比最低的人群,全因死亡、心血管疾病、2 型糖尿病、结直肠癌的风险都降低了 15-30%。9《英国医学杂志》的荟萃分析发现,每天增加 3 份全谷物,冠心病风险降低 19%,全因死亡率降低 17%。而精制谷物和白米几乎没有显示出类似的保护效应。10

不过,这并不意味着碳水需要压得很低。柳叶刀子刊的另一项大型研究揭示了一条 U 型曲线:碳水供能比低于 40% 或高于 70%,死亡率都会升高;最佳范围在 50-55% 左右。11新金字塔的图乍看之下确实很颠覆,谷物被压缩在最下面的一角。但实际算一算:每天 2-4 份全谷物约等于 150-200 克煮熟的主食,再加上难以完全避免的精制碳水,以及蔬菜、水果、乳制品中天然含有的碳水,总量其实并不极端。这不是让你「把肉当饭吃」,只是调整了各类食物的优先级

根据指南实际推算,按照供能比例来说,碳水依旧占大头

至于把白米白面全部换成全谷物,同样不必走极端。全谷物纤维含量高,突然大量摄入可能导致腹胀、消化不适,老年人和肠胃功能较弱的人尤其难以耐受。更务实的做法是逐步提高比例:白米里掺点糙米或藜麦,面包选全麦的,早餐试试燕麦,循序渐进,而不是一刀切。

还需要警惕的是,这份指南不应该被断章取义地用来鼓吹极低碳水饮食或生酮饮食。指南确实提到「某些慢性病患者在遵循低碳水饮食时,健康状况可能会有所改善」,但紧接着就强调,这需要「与您的医疗专业人员合作,确定并采用适合您及您健康状况的饮食方案」。生酮饮食更是如此,它本质上是一种治疗性饮食,不是普通人可以随意跟风的生活方式。

所以碳水的「降级」,核心信息不是「碳水是敌人」,而是:精制碳水要少吃,全谷物要适量吃,具体比例因人而异。

六条饮食健康建议

除了三大营养素优先级的调整,我还总结了六条比较重要的饮食健康建议。这些建议更偏向实操层面,有些是老生常谈,有些则有新的表述。

一、对于添加糖的零容忍

指南的原话是:「没有任何添加糖或非营养性甜味剂被推荐或被认为是健康饮食的一部分。」

添加糖的危害早已是共识,应该没有人还不知道糖的危害。但这可能是迄今为止官方机构对糖最严厉的表态。具体建议是每餐添加糖不超过 10 克,儿童则应完全避免。

需要澄清的是,这里说的是「添加糖」,而非「天然存在的糖」。完整水果中的糖与纤维、维生素、矿物质共存,消化吸收相对较慢,对血糖冲击小,不在限制范围内。但蜂蜜、枫糖浆等这些听起来很「天然」的甜味剂,和白砂糖没有本质区别,都属于添加糖。

此外,用代糖替代真糖,同样不被看好。这个态度与世界卫生组织 2022 年的综述一致:WHO 在系统综述了大量证据后明确建议,不要使用非糖甜味剂来控制体重或预防慢性病。理由是,虽然短期内代糖可能有助于减少热量摄入,但没有明确证据表明它们对长期体重控制或健康有益,反而可能存在潜在风险。

与其纠结于用什么糖或代糖,不如直接减少对甜味的依赖。无糖可乐不是健康饮品,只是「没那么不健康」的饮品。

二、全脂乳品回归

这条应该也很好理解,脂肪都得到「正名」了,那么全脂乳品的回归自然理所当然。

前面提到,很多低脂产品为了弥补口感会添加糖。另外,乳制品中的脂溶性维生素(A、D、E、K)需要脂肪才能被充分吸收,去掉脂肪等于打了折扣。还有研究显示,全脂乳制品的饱腹感更强,可能减少总体热量的摄入。也有研究表明,全脂乳制品与心血管风险没有显著关联,甚至与更低的 2 型糖尿病和肥胖风险相关。

更何况,指南的核心价值观是吃真实的食物,而全脂乳品显然比脱脂乳品更「真实」。当然,这不是说要猛灌全脂奶,而是说在乳制品的选择上,不用刻意去选择低脂的产品,无糖比低脂更值得优先考虑。同时,如果你在奶制品中摄入了更多的脂肪,那么其他来源就应该相应的减少。

三、重视肠道健康,适量摄入发酵食物

近几年肠道菌群确实足够火爆,相关研究激增,积累了不少新的证据。

指南写道:你的肠道中有数万亿细菌和其他微生物,统称为微生物组。健康饮食支持平衡的微生物组和健康的消化。高度加工食品会破坏这种平衡,而蔬菜、水果、发酵食品和高纤维食物支持多样化的微生物组。泡菜、韩式泡菜、开菲尔、味噌等发酵食品被明确列入推荐。

说到发酵食物,中国人可太有发言权了,像我们常吃的酸菜、腐乳、榨菜、酱油、豆豉、酸奶等,都属于发酵食物。

但这里需要泼一盆冷水。发酵食物的健康益处主要来源于其中的益生菌及其代谢产物,对肠道健康确实有好处。但问题是,这些传统发酵食物通常还伴随着高盐、高糖,部分还可能存在亚硝酸盐的风险。一小碟榨菜的钠含量可能就超过了一天推荐量的一半。和这些问题相比,益生菌带来的好处可能不值一提。

如果真的是抱着促进肠道健康的目的去吃,应该选择低钠、低糖甚至无糖的产品,比如无糖酸奶、真正的低钠发酵食品等。但说实话,就算是目前市面上很多所谓的「低钠」产品,也只是相对低钠,仔细看营养成分表,钠含量依然不低。真正低钠的发酵食品,大概率也不会太好吃。

常见的轻盐榨菜,实际钠含量也并不低。作为参考,指南建议14岁及以上的一般人群每天钠摄入量应少于2300毫克。

四、多吃完整的蔬菜水果

这条的理由其实在核心理念部分也已经讲过:完整的食物优于加工提取的形式。蔬菜水果尽量吃完整的,而不是榨成汁。

指南建议每天蔬菜 3 份、水果 2 份,并强调要吃「各种色彩丰富、营养丰富的蔬菜和水果」。不同颜色的蔬果含有不同的植物化学物质,多样化摄入比单一品种更有益。

如果新鲜蔬果不方便获取,指南也给出了替代方案的优先级:

  • 最优选:新鲜的完整蔬菜水果;
  • 次优选:无添加糖的冷冻、干燥或罐装蔬果;
  • 限量选:100% 果蔬汁,可以用水稀释后限量饮用。
  • 尽量避免:添加了糖和各种添加剂的果蔬制品

五、选择更健康的烹饪方式

指南推荐用烘烤、炙烤、炖煮、快炒或烧烤等方式替代油炸。

需要注意的是,这里说的「烧烤」大概率指的是美式烹饪语境下的做法:放在烤箱里,温度通常在 180-220 度左右,可能包着锡纸,不会产生明火和烟熏,也不太会烤焦。这和我们街边那种炭火明烤、烟雾缭绕、充满「烟火气」的烧烤是两回事。

高温明火烧烤肉类时会产生杂环胺和多环芳烃,这些物质与癌症风险有关。偶尔吃当然没问题,但不建议作为日常主要的烹饪方式。

另外格外要注意的是避免反复高温油炸。餐厅和快餐店的炸油往往反复使用,这会导致油脂氧化、产生有害物质。家庭烹饪中如果偶尔油炸,用新鲜的油、炸完就倒掉,虽然问题不大,但也谈不上健康。从这点来说,空气炸锅是还不错的替代选择。

六、限制任何酒精饮料摄入

指南的表述是:「为了更好的整体健康,减少酒精摄入。」应完全避免酒精的人群包括孕妇、酒精使用障碍康复者、服用特定药物者、有酗酒家族史者。

值得注意的是,新指南没有给出「适量饮酒」的具体数字。早些年,有一些适量饮酒,尤其是葡萄酒有益心血管健康的说法。但支持这一观点的研究被发现存在方法学问题,而且 2022 年世界心脏联合会的声明直接挑明:「没有安全的饮酒水平对心血管健康有益。」12

说到底,酒精是明确的一类致癌物,对健康只有坏处,没有好处,不存在「适量」的问题。新指南的态度很简单:少喝为好,能不喝最好。

总结

综上所述,我个人认为:这份指南是对近些年主流研究方向的一次官方总结和背书,与之前指南的一些观点相悖,但也并非什么石破天惊的颠覆。倒置的金字塔是一个视觉符号,代表的是优先级的变化,而非实际进食量的比例。落到具体的克数和份数上,其实还是在范围内的。参考价值不错,但应该警惕网络上断章取义的解读。

蛋白优先、适量的脂肪碳水这些建议的前提是吃对你来说合适的量。热量需求取决于年龄、性别、身高体重、活动水平,每个人都不一样。适量才是真正的前提,无论是蛋白、脂肪还是碳水,抛开量去谈健康都是空谈。此外,还有一件更基础的事:喝水。多喝水,喝纯水或气泡水是性价比最高的健康投资。

全文信息总结 | 由 Nano Banana Pro 生成

写在最后

指南中还有相当篇幅讨论分层人群的饮食建议:如婴幼儿喂养(母乳、维生素 D、辅食引入、过敏原等)、青少年营养(钙、铁、维生素 D,以及避免能量饮料等)、孕妇哺乳期和老年人的优先营养素,还有素食和纯素饮食的注意事项(少吃加工替代品、重点营养素的监测和补充策略等)。由于篇幅所限就不展开了,有兴趣的读者可以自行查阅原文,现在有 AI 辅助,英文文档读起来也很方便。

就像 1992 年的那份指南一样,新的指南必然附带了商业、政治等各种因素,不可能完全纯粹。有美国政府的背书固然有一定的引导意义,但后续效果还需要时间验证。目前国内推行的标准是 2022 年版的中国居民膳食宝塔,两者有相通之处,也有差异。

健康是一个多方平衡的结果,而不是听风就是雨。今天说这个好就跟着做,明天说那个好又换方向,到头来什么也没坚持下来。取其精华,去其糟粕,不必盲从,其他的留给时间去验证。

说到底,吃得健康从来都不是一件轻松的事。它要时间,要精力,要钱,有时候还要和自己的本能对抗。真正试着去实践的时候才会发现,有时间的人未必有条件去购买各种食材,有预算的人往往又被困在加班和外卖的循环里。某种程度上,「好好吃饭」这件事,可能还有点「奢侈」。

更难的是,即便解决了时间和预算的问题,健康饮食还意味着要和那些廉价的快乐告别。糖、油、盐、精制碳水,这些让大脑分泌多巴胺的组合,恰恰是指南里最不待见的东西。

写到这里,也有点饿了。

看了看桌面:一边是很符合指南审美的零乳糖全脂无添加鲜牛奶,另一边却是指南大概率会皱眉的深度加工终极糖油混合物——糖油果子。这两个我都要。虽然不是很健康,但偶尔的快乐,大概也是健康的一部分吧。

    下面是我的简历

    持有 CKA ccna 认证。
    长期负责高并发电商系统的稳定性与性能治理,理解 Nginx 的事件驱动模型、Worker 并发机制与请求生命周期控制方式,并将其抽象为 “进入策略( Admission )— 排队策略( Queueing )— 满载策略( Overload )” 的系统行为诊断框架。

    通过拆解全链路时间指标( Time-based Metrics ),结合 P95 / P99 延迟分位数,对比 request_timeupstream_response_time,判断请求阻塞发生在进入控制、系统排队或下游依赖阶段,用于快速界定网络层、应用层与数据层的性能边界。

    参与并主导多次从单体架构向云原生、无状态化架构的演进,关注系统的可解释性、稳定性与成本控制。


    技术技能

    SRE 与性能诊断

    • 使用 Ingress / Queue / Worker / Egress 作为系统分层对象进行问题定位

    • 基于 P95 / P99 延迟分位数 分析尾延迟( Tail Latency )

    • 通过 request_timeupstream_response_time 的分位数差异判断系统内部是否发生排队

    • 区分整体性能退化与少量请求异常放大的不同问题模式

    • 依据进入控制、排队与满载策略分析系统稳定性取舍


    Web 与中间件

    • Nginx 事件驱动模型、Worker 并发模型、连接与请求生命周期

    • 使用 limit / buffer / backlog / timeout 等配置参数实施系统行为控制

    • Nginx 与 PHP-FPM 的 Worker / Process / Queue 协同关系

    • 高并发 WordPress 架构的稳定性与性能治理


    云原生与基础设施

    • 阿里云:ECS 、RDS 、OSS 、ALB

    • AWS

    • Docker 、Kubernetes ( CKA )

    • Terraform (基础设施即代码)

    • Calico ( Kubernetes 网络模型与 NetworkPolicy )


    数据库与数据处理

    • MySQL 使用与常见性能问题定位

    • SQL 编写

    • PL/SQL 阅读

    • ETL 流程(数据抽取、清洗、加载)

    • 结合 P95 / P99 延迟分布 判断数据库是否为系统尾延迟来源


    自动化与运维

    • Ansible Playbook

    • Shell 脚本

    • 配置一致性与变更管理


    网络

    • TCP/IP

    • VPN

    • 负载均衡

    • CCNA 网络体系


    工作经历

    基础设施负责人 / 高级运维工程师

    负责自营跨境电商平台的技术架构设计、云资源管理与系统稳定性。


    性能瓶颈诊断与容量优化

    • 通过时间指标发现平均响应时间稳定,但 P95 / P99 延迟显著升高

    • upstream_connect_time 正常的情况下,response_time 分位数拉长

    • 判断请求未阻塞在网络或 TCP 层,而是在系统内部发生资源排队

    • 结合 Nginx 与 PHP-FPM 的并发模型,将问题定位为应用层并发策略导致的 Worker 争用

    优化措施:

    • 引入 Redis 缓存,降低同步资源竞争

    • 调整 PHP-FPM Worker 数量,减少高分位请求等待时间

    • 调整 Nginx 超时与失败处理策略,防止慢请求放大系统负载

    结果:

    • 页面 P95 延迟从约 5 秒下降至 2 秒以内

    • 尾延迟明显收敛

    • 高峰期服务稳定性显著提升


    电商架构云原生改造

    • 数据库迁移至阿里云 RDS

    • 媒体资源迁移至 OSS

    • 前端通过 ALB 进行多节点负载

    • 应用层实现无状态化部署

    结果:

    • 系统支持水平扩展

    • 综合成本下降约 30%

    • 大促期间可用性维持在 99.9%


    日常运维

    • 使用 Ansible 管理 Nginx / PHP 配置

    • MySQL 备份与恢复演练

    • OpenVPN 远程访问环境维护


    早期经历

    网络管理员 / IT 支持
    2011 年 – 2015 年

    • 企业网络规划与服务器维护

    • SQL 数据提取与分析


    教育背景与证书

    • CKA ( Certified Kubernetes Administrator )

    • CCNA ( Cisco Certified Network Associate )

    请教各位。我做了 10 年电商,从 23 岁就开始做了,这些爱好自学的。现在走下坡路了,要出来找工作了。
    我学历也很低,是函授大专。今年 33 岁了。
    我对内核,nginx,sre ,这些也有深入的理解,我不会开发软件,纯粹的想走运维路线
    最近也打算学 python ,不会写脚本确实没有竞争力。
    我知道我的问题,学历低,没项目经验和实际的工作经验,年纪也大。
    上面每项技术,我确实认真的学了很久,而且做过大量的实验实操,理论也很扎实。
    boss 直聘主动联系我的人很多,但是简历发了后基本就没下文了。
    各位有某些负责招聘的老大,希望能说一下你们的观点
    假如我真的没戏,我就不打算找这些工作了。
    我也做外贸独立站。然后平时会搭建很多开源项目,也不是玩,确实是投入实际使用。所以不断的积累了相关的操作。就是把自己学的,都在开源项目里应用。

    JExten:基于Java模块系统(JPMS)构建健壮的插件架构

    1. 动机:通往模块化隔离之路

    在Java中构建可扩展应用程序时,开发者常常从一个简单的问题开始:"如何让用户无需重新编译核心应用程序就能添加功能?" 旅程通常始于标准的 java.util.ServiceLoader,它提供了一种发现接口实现的简单机制。

    然而,随着应用程序的增长,一个关键问题出现了:"类路径地狱"。

    想象一下,你有一个使用 library-v1 的主机应用程序。你创建了一个插件系统,有人写了一个需要 library-v2 的 "Twitter 插件"。如果所有东西都在同一个扁平的类路径上运行,就会产生冲突。要么主机因为得到错误的库版本而崩溃,要么插件失败。你无法在类路径上同时存在同一个库的两个版本而不面临运行时异常(如 ClassDefNotFoundErrorNoSuchMethodError)的风险。

    这正是JExten背后的核心驱动力。我需要一种能够严格封装插件的方式,使得每个插件都可以定义自己的依赖,而不影响主机或其他插件。

    引入JPMS(Java平台模块系统)

    Java 9引入了模块系统(JPMS),它提供了强封装和显式的依赖关系图。它允许我们创建隔离的模块"层"。

    • 启动层:JVM和平台模块。
    • 主机层:核心应用程序及其依赖。
    • 插件层:在主机层之上动态创建的层。

    通过利用JPMS的ModuleLayers,JExten允许插件A依赖于Jackson 2.14,而插件B依赖于Jackson 2.10,两者可以在同一个运行的应用程序中和睦共存。

    2. 架构与设计

    JExten设计为轻量级且基于注解驱动,抽象了原始ModuleLayers的复杂性,同时提供了依赖注入(DI)和生命周期管理等强大功能。

    架构基于三个主要支柱:

    扩展模型

    核心在于,JExten在"契约"(API)和"实现"之间进行了清晰分离。

      1. 扩展点 (@ExtensionPoint):在主机应用程序(或共享API模块)中定义的接口,规定了哪些功能可以被扩展。

        @ExtensionPoint(version = "1.0")
        public interface PaymentGateway {
          void process(double amount);
        }
      1. 扩展 (@Extension):由插件提供的具体实现。

        @Extension(priority = Priority.HIGH)
        public class StripeGateway implements PaymentGateway {
          // ...
        }

        注意,你可以在没有PluginManager的情况下使用ExtensionManager。这在测试中或当你希望在非插件环境中使用JExten,且所有扩展都已经在模块路径中可用时非常有用。

    管理器分离

    为了分离关注点,该库将职责划分到两个不同的管理器:

    1. PluginManager("物理层")

      • 该组件处理原始工件(JAR/ZIP文件)。
      • 它使用SHA-256校验和验证完整性,确保插件未被篡改。
      • 它构建JPMS ModuleLayer 图。它读取 plugin.yaml 清单,解析依赖项(从本地缓存或Maven仓库),并构建类加载环境。
    2. ExtensionManager("逻辑层")

      • 一旦层构建完成,该组件接管。
      • 它在各个层中扫描带有 @Extension 注解的类。
      • 它管理这些扩展的生命周期(单例、会话或原型作用域)。
      • 它处理依赖注入。

    依赖注入

    由于插件在隔离的层中运行,标准的DI框架(如Spring或Guice)有时可能"太重"或在动态模块边界间配置起来很棘手。JExten包含一个内置的、轻量级的DI系统。

    你可以简单地使用 @Inject 将扩展连接在一起:

    @Extension
    public class MyPluginService {
        @Inject
        private PaymentGateway gateway; // 自动注入最高优先级的实现
    }

    这在模块边界之间可以无缝工作。一个插件可以注入由主机提供的服务,甚至可以注入由另一个插件提供的服务(如果模块关系图允许的话)。

    3. 使用示例

    下面快速了解一下如何定义扩展点,在插件中实现它,并在应用程序中使用。

    I. 定义一个扩展点

    创建一个接口并用 @ExtensionPoint 注解。这是插件将实现的契约。

    @ExtensionPoint(version = "1.0")
    public interface Greeter {
        void greet(String name);
    }

    II. 实现一个扩展

    在你的插件模块中,实现该接口并用 @Extension 注解。

    @Extension
    public class FriendlyGreeter implements Greeter {
        @Override
        public void greet(String name) {
            System.out.println("Hello, " + name + "!");
        }
    }

    III. 发现与使用

    在你的主机应用程序中,使用 ExtensionManager 来发现和调用扩展。

    public class Main {
        public static void main(String[] args) {
            // 初始化管理器
            ExtensionManager manager = ExtensionManager.create(pluginManager);
    
            // 获取Greeter扩展点的所有扩展
            manager.getExtensions(Greeter.class)
                   .forEach(greeter -> greeter.greet("World"));
        }
    }

    IV. 将你的扩展打包为插件

    最后,使用 jexten-maven-plugin Maven插件在编译时检查你的 module-info.java,并将你的扩展打包成一个包含所有依赖项和生成的 plugin.yaml 清单的ZIP包。

    <plugin>
        <groupId>org.myjtools.jexten</groupId>
        <artifactId>jexten-maven-plugin</artifactId>
        <version>1.0.0</version>
        <executions>
            <execution>
                <goals>
                    <goal>generate-manifest</goal>
                    <goal>assemble-bundle</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <hostModule>com.example.app</hostModule>
        </configuration>
    </plugin>

    然后,你可以将生成的ZIP包安装到你的主机应用程序中:

    public class Application {
        public static void main(String[] args) throws IOException {
            Path pluginDir = Path.of("plugins");
    
            // 创建插件管理器
            PluginManager pluginManager = new PluginManager(
                "org.myjtools.jexten.example.app", // 应用程序ID
                Application.class.getClassLoader(),
                pluginDir
            );
    
            // 从ZIP包安装插件
            pluginManager.installPluginFromBundle(
                pluginDir.resolve("my-plugin-1.0.0.zip")
            );
    
            // 创建支持插件的扩展管理器
            ExtensionManager extensionManager = ExtensionManager.create(pluginManager);
    
             // 从插件获取扩展
            extensionManager.getExtensions(Greeter.class)
                .forEach(greeter -> greeter.greet("World"));
        }
    }

    4. 与其他解决方案的比较

    选择合适的插件框架取决于你的具体需求。以下是JExten与一些成熟替代方案的对比:

    PF4J (Plugin Framework for Java)

    PF4J是一个成熟的、轻量级的插件框架,依赖于ClassLoader隔离。

    • 隔离性:PF4J使用自定义ClassLoader隔离插件。JExten使用JPMS ModuleLayers。后者是自Java 9以来处理隔离的"原生"Java方式,在JVM级别严格执行封装。
    • 现代性:虽然PF4J非常优秀,但JExten是专门为现代模块化Java生态系统(Java 21+)设计的,利用模块描述符(module-info.java)来定义依赖关系,而不是自定义清单。

    OSGi

    OSGi是模块化的黄金标准,为Eclipse等IDE提供支持。

    • 复杂性:OSGi功能强大,但学习曲线陡峭且样板代码多(Manifest头、Activators、复杂的服务动态)。JExten通过专注于80%的用例——具有简单依赖注入的严格隔离扩展——提供了远低于OSGi的复杂性("精简版OSGi"),且不需要完整的OSGi容器。
    • 运行时:OSGi带来沉重的运行时。JExten是一个轻量级库,构建在标准JVM特性之上。

    Layrry

    Layrry是一个用于执行模块化Java应用程序的启动器和API。

    • 关注点:Layrry非常侧重于模块层的配置和组装(通常通过YAML/TOML),并充当运行器。JExten则侧重于这些层内的编程模型
    • 特性:Layrry擅长构建层,但它不提供固化的应用框架。JExten提供了"粘合"代码——扩展点、依赖注入和生命周期管理——这些是你在使用原始模块层或Layrry时必须自己编写的东西。
    特性JExtenPF4JOSGiLayrry
    隔离JPMS 模块层文件/类加载器Bundle类加载器JPMS 模块层
    配置Java 注解属性/清单Manifest 头部YAML/TOML
    依赖注入内置 (@Inject)外部 (Spring/Guice)声明式服务无 (ServiceLoader)
    学习曲线

    5. 结论

    JExten是一个轻量级、基于注解驱动的插件框架,它利用JPMS模块层来提供隔离和依赖管理。其设计目标是易于使用和理解,注重简洁性和易用性。

    最后,请记住JExten仍处于早期阶段,有很大的改进空间。欢迎在GitHub上为项目做贡献和/或在issue部分参与讨论。项目仓库链接在此处


    【注】本文译自:JExten: Building a Robust Plugin Architecture with Java Modules (JPMS) - DEV Community

    前期提要

    在2025 年 8 月,腾讯玄武实验室的阿图因自动化漏洞挖掘引擎在零知识证明库 gnark 中发现了一个高危漏洞(CVE-2025-57801,CVSS 8.6)。之后,玄武实验室联合上海交通大学 GOSSIP 实验室及郁昱教授团队共同完成了漏洞复现。

    2025 年 8 月,腾讯玄武实验室基于大模型能力构建的自动化漏洞挖掘引擎 Atuin 在零知识证明(ZKP)库 gnark 的签名验证电路中发现一处高危漏洞,并获得编号 CVE-2025-57801(CVSS 8.6)。该问题本质上属于签名可塑性(Signature Malleability):在电路约束不完备的情况下,攻击者可以在不改变公共输入(交易内容/消息等)的前提下,构造出不同但仍能通过验证的签名见证,从而破坏“签名唯一性/不可重放性”这一常被上层协议默认成立的安全前提。

    之所以需要严肃对待这类缺陷,是因为 gnark 作为工程化程度很高的 ZKP 库,被广泛用于 ZK-Rollup 等扩容场景;一旦 Operator/业务电路直接复用存在缺陷的“原生(native)签名验证”实现,那么攻击者就可能基于一笔真实交易派生出“内容相同但签名不同”的伪造版本,进而在某些以签名字段(如 R/S)派生 nullifier、反重放标识或约束逻辑的系统里引发重复执行/重复结算等连锁风险。

    在玄武实验室披露后,其与上海交通大学 GOSSIP 实验室及郁昱教授团队完成了漏洞复现与影响分析,并推动社区修复。但值得注意的是:即便该漏洞构造并不复杂,其初始“修复”却并不严谨。在早期修复链路中,签名标量 S 的取值约束仍存在边界条件缺口——实现里检查的是 s <= order,而标准要求的是 严格不等 s < order。这会在极端边界(例如 s = order)下引入等价关系,使得签名对在形式上出现可塑性(可理解为 (R, 0) 与 (R, order) 的等价风险点),从而留下“理论上可被利用、工程上可能被误用”的残余隐患。

    为消除这一残余风险,我们(星图实验室)进一步向 gnark 上游报告并推动修复:最终在 PR #1684 将约束从 AssertIsLessOrEqual 调整为严格比较(在 std/signature/eddsa/eddsa.go 中用 cmp.IsLess 并断言结果为 1),使 EdDSA 验证满足 S < order 的严格要求;该 PR 已于 2026-01-21 合入主分支,并在CVE-2025-57801中获得了致谢。

    更有意思的是,这个“残余隐患”的发现路径,几乎与玄武实验室依赖复杂 Agent 体系(Atuin)进行自动化挖掘的路径相反:星图研究员在看到玄武实验室相关信息后第一时间尝试复现。作为安全研究团队,我们希望对 AI/大模型在漏洞分析中的有效性做更“朴素但可对照”的评估——因此我们没有调用外部网络,也没有搭建多工具链 Agent,而是把公开上下文(即ecdsa.go,prompt为:“请你帮我查找其中的安全隐患”。)直接投喂给 Gemini 2.5 Pro 与 GPT-5。出乎意料的是,在“无外部检索、无复杂编排”的条件下,大模型依然给出了准确的漏洞挖掘、机理拆解与推导链路,并能自然地把关注点落到“约束是否完备/边界是否严格”这种最容易在修复阶段被忽略的细节上。

    我们关注到当时的网络安全圈的一些评论,例如微博上对这个的讨论是: “用 AI 发现代码中的漏洞已经没什么稀奇了。但是在密码学库,尤其是经过多轮人工审计的 Web3 社区的密码学库里还能发现漏洞,这就让我们对 AI 能力边界的认知又扩大了一圈。” 这个案例给了我们一些新的如何利用AI能力开展安全研究的启发,AI的能力在目前的安全研究人员认知中可能被低估了,需要大家进一步评估AI挖掘漏洞的潜力。

    相关链接:

    • 我们的AI发现了一个零知识证明库的漏洞,Sam Altman的项目也用了这个库https://mp.weixin.qq.com/s/MefyWBQJKU2Mf0vLwau8MQ
    • gnark 官方漏洞公告:Security Advisories · Consensys/gnark · GitHub
    • CVE-2025-57801:NVD – CVE-2025-57801

    数据智能的内涵与行业价值
    在数字化转型不断深入的今天,数据智能已经成为企业提升竞争力的关键要素。简单来说,数据智能是通过大数据、人工智能和机器学习等技术,对海量数据进行采集、处理和分析,从而挖掘出有价值的洞察,支持企业做出更精准的决策。与传统的商业智能工具相比,数据智能更注重实时性和预测性,能够帮助企业从被动应对转向主动优化。
    然而,实现数据智能的价值并不容易。许多企业在推进相关项目时,常常面临数据孤岛、技术复杂度高以及业务场景适配难等问题。尤其是在制造业这类数据来源多样、结构复杂的行业,传统的数据处理方式往往难以满足高效分析和实时反馈的需求。因此,专业的数据智能公司逐渐成为企业的重要合作伙伴,它们通过技术平台和行业化解决方案,帮助企业打通数据链路,实现智能化升级。
    从技术层面看,数据智能公司的核心能力覆盖了数据采集、治理、分析和应用等多个环节。优秀的公司不仅能提供强大的工具,还能将这些工具与企业的实际业务场景深度融合。举个例子,在工业领域,数据智能需要与生产线设备、管理系统甚至供应链网络无缝对接,才能真正发挥价值。
    数据智能公司的技术路径与差异化
    数据智能领域的公司大致可以分为两类:一类是提供通用技术平台的厂商,另一类是专注于垂直行业的解决方案提供商。通用平台型公司,依托其强大的云计算基础设施和广泛的技术生态,为企业提供从数据存储到分析的全套服务。这类公司的优势在于技术全面、资源丰富,能够快速响应大多数企业的通用需求。但缺点是,在面对特定行业的复杂场景时,它们的解决方案可能需要较多的定制化开发,有时缺乏深度行业理解。
    相反,垂直领域的数据智能公司更注重行业知识与技术能力的结合。它们通常长期深耕某一行业,深刻理解该领域的业务痛点和数据特性,因此能提供更精准、高效的解决方案。专注于制造业数据智能应用,其技术覆盖了从生产流程优化到质量控制的各个环节,体现出鲜明的行业特色。
    此外,数据智能公司的竞争焦点正在从技术工具转向实际落地效果。企业客户不再只关心平台的功能有多强大,而是更关注数据智能如何真正解决业务问题,带来可衡量的价值。比如,通过应用数据智能,企业可能实现生产效率提升10%以上,或供应链响应时间缩短20%,这些具体指标远比技术参数更有说服力。
    典型案例:厂商的实践
    依托吉利集团的工业背景,广域铭岛专注于制造业的全价值链数据智能应用,其解决方案包括数据采集、实时监控和预测性分析等模块。例如,在汽车制造行业,其Geega系统可以实时监控生产线状态和工艺参数,通过AI算法提前发现潜在问题,避免生产中断和质量缺陷。某汽车零部件企业引入该方案后,生产线效率提升了12%,质量追溯速度提高了40%,显著降低了运营成本。
    阿里巴巴的DataWorks和腾讯的TBDS平台为互联网、金融和零售行业提供大数据开发和管理服务,适用于多场景需求。华为云的FusionInsight则专注于大型企业的数据湖和实时分析,在能源和交通领域有较多应用。

    国际版可用

    g0kyghfm@nqmo.com    Djh%oX$c*Yfm
    zvjk3jzb@nqmo.com    #gjV&J7UiI$s
    n6xulwea@nqmo.com    iJJfr$CgQi47
    sun7ghve@end.tw    @q23EyN6KohF
    id460vhq@end.tw    6kPDH*2VQcWr
    c459w302@end.tw    65izh4%lI#@U
    pjzunk90@end.tw    abbXBub!C^PS
    t391ixou@end.tw    78Fi@z2iFcY0
    8sk0cxat@end.tw    Z@lTMP!DlYMo
    rvx0upjj@uuf.me    fkW&R0nqFnJ0
    zpjgynt6@end.tw    f6TKvfGHSRwq
    vvxkc3ba@end.tw    y9PJrA4RVITw
    1q2kzkug@end.tw    6DU7Mj8Lihm7
    kr1vn2cs@uuf.me    4$nUEYoFeJxy
    w5dmf9nd@end.tw    se2ng18cNf8*
    h6i74e9z@end.tw    g^9MJb09Gnbk
    z3uolswg@nqmo.com    mK93ieEZ!CUw
    9e0u13yy@nqmo.com    UMJ%%Xemz6QI
    gdfoks2o@nqmo.com    A6y1VmgLo^iE
    vm1ov9vs@nqmo.com    Zd&Td30Ec62K
    0hqqsnyy@end.tw    !zI5TryeE1yt
    xgd4lqaj@end.tw    gOf#HuxWkA8y
    os8bkeum@end.tw    PVodqSrftfSq
    hsgj6kmv@nqmo.com    2hcNOS10tyhA
    05y5r2kn@end.tw    OkvYGk8Yj*Ux
    0kd4goea@end.tw    fkdokR7qa&Iu
    d5urq980@uuf.me    lmD@aAVDlF#b
    1au3xllh@end.tw    SC#CNXjiy$hR
    updobnze@end.tw    7Eb1YJlfB4eq
    jlg23nkj@nqmo.com    $e4VKKn&%*cM
    9wz6j12x@end.tw    CcB&d%6Ou*Ot
    b7u16yyh@end.tw    %jX9DAKXNIW*
    6lxl6pnv@uuf.me    J&YHULP6!HHa
    ie882658@end.tw    0KUNo&Wut&pw
    asvsdv5t@uuf.me    PZi1Ov%6w!Za
    mali2bcd@uuf.me    09*8hX^@jO91
    3pfyrx5g@uuf.me    MnqHhQlLQ1zH
    ltj23cp6@nqmo.com    atR71%Zw4nY@
    z5ikj67v@uuf.me    !1b6v^uAM2km
    wdadpydz@end.tw    y4An8GtDZm#^
    lkujomny@nqmo.com    ONL@7lM^$Oa@
    ihp8k28n@end.tw    0TexsXI^JlQ0
    0vqtkrt0@nqmo.com    cPk7r&KO7^62
    tltvju9v@nqmo.com    rwHYvYlxjrhD
    ldomlj49@uuf.me    bW^5ARZ2rvF5
    wvaiaeem@end.tw    fMc@&lTFBeSy
    dvubdl0l@uuf.me    QGbID!7BcYmc
    9mjr3140@nqmo.com    1D7pv&JPmEF0
    

    如果有帮助请点赞( )~


    📌 转载信息
    原作者:
    tausak
    转载时间:
    2026/1/23 15:46:57

    「CC 被 A 社限制使用,Codex 逐渐发力,代码之巅,新王加冕」


    最近 Anthropic 小动作挺多,比如说:

    1. 2.1.15 版本开始逐渐弃用 npm 的安装方式
    2. claude code 一些暗配置在云上,方便 Anthropic 云控
    3. Anthropic 明牌抵制大陆公司,大陆 IP 使用
    4. 接下来,好像还有一些小动作,这些信号告诉我们,需要备用方案


    # Codex 示例配置(config.toml)V1.0 
    # 作者:大帅笔 
    # https://linux.do/u/dwifbytslqh/summary
    ################################################################################
    # 核心模型选择
    ################################################################################
    
    # Codex 使用的主模型。默认:所有平台均为 "gpt-5.2-codex"。
    # 支持 gpt-5.2-codex, gpt-5.2, o1-pro-codex 等
    model = "gpt-5.2-codex"
    
    # /review 功能(代码审查)使用的模型。默认:"gpt-5.2-codex"。
    # 可设置为不同的模型以优化代码审查效果
    review_model = "gpt-5.2-codex"
    
    # 从 [model_providers] 中选择的提供方 id。默认:"openai"。
    # 可选值:openai, azure, ollama 等,需在 [model_providers] 部分定义
    model_provider = "openai"
    
    # 用于 --oss 会话的默认开源提供方。未设置时,Codex 会提示选择。默认:未设置。
    # 设置为 ollama 等支持开源模型的提供方
    # oss_provider = "ollama"
    
    # 可选的手动模型元数据。未设置时,Codex 会根据 model 自动检测。
    # 取消注释以强制指定这些值。
    # 模型的上下文窗口大小(token 数),影响单次请求可处理的最大代码量
    # model_context_window = 128000       # token 数;默认:按模型自动决定
    
    # 自动触发历史压缩的 token 阈值,0 表示使用模型默认值
    # model_auto_compact_token_limit = 0  # token 数;未设置时使用模型默认值
    
    # 每个工具输出存储的最大 token 数,防止工具输出占用过多上下文
    # tool_output_token_limit = 10000     # 每个工具输出存储的 token 数;对 gpt-5.2-codex 默认是 10000
    
    ################################################################################
    # 推理与详细度(支持 Responses API 的模型)
    ################################################################################
    
    # 推理强度:minimal | low | medium | high | xhigh(默认:medium;在 gpt-5.2-codex 与 gpt-5.2 上为 xhigh)
    # 更高的推理强度会让模型思考更充分,但响应时间更长
    model_reasoning_effort = "medium"
    
    # 推理摘要:auto | concise | detailed | none(默认:auto)
    # 控制是否显示模型的推理过程摘要
    model_reasoning_summary = "auto"
    
    # GPT-5 系列(Responses API)的文本输出详细度:low | medium | high(默认:medium)
    # 影响模型回复的详细程度
    model_verbosity = "mediummedium"
    # model_reasoning_summary = "auto"
    # model_verbosity = "medium"
    # chatgpt_base_url = "https://chatgpt.com/backend-api/ "
    # experimental_compact_prompt_file = "./compact_prompt.txt"
    # include_apply_patch_tool = false
    # experimental_use_unified_exec_tool = false
    # experimental_use_freeform_apply_patch = false
    # tools_web_search = false
    # features = { unified_exec = false }
    
    ################################################################################
    # Projects(信任级别)
    ################################################################################
    
    # 将特定 worktree 标记为可信或不可信。
    # 为不同项目设置不同的信任级别
    [projects]
    
    # 项目路径设置示例
    # [projects."/absolute/path/to/project"]
    # trust_level = "trusted"  # 或 "untrusted"
    
    ################################################################################
    # OpenTelemetry(OTEL)- 默认禁用
    ################################################################################
    
    # 可观测性配置,用于监控和调试
    [otel]
    
    # 在日志中包含用户提示文本。默认:false(出于隐私考虑)
    log_user_prompt = false
    
    # 应用于遥测数据的环境标签。默认:"dev"
    environment = "dev"
    
    # 导出器:none(默认) | otlp-http | otlp-grpc
    # 设置为 none 则禁用遥测导出
    exporter = "none"
    
    # Trace 导出器:none(默认) | otlp-http | otlp-grpc
    trace_exporter = "none"
    
    # 示例:OTLP/HTTP 导出器配置
    # [otel.exporter."otlp-http"]
    # endpoint = "https://otel.example.com/v1/logs "  # OTLP 接收端点
    # protocol = "binary"                         # "binary" | "json"
    
    # [otel.exporter."otlp-http".headers]
    # "x-otlp-api-key" = "${OTLP_TOKEN}"  # 从环境变量读取 API 密钥
    
    # 示例:OTLP/gRPC 导出器配置
    # [otel.exporter."otlp-grpc"]
    # endpoint = "https://otel.example.com:4317 "
    # headers = { "x-otlp-meta" = "abc123" }
    
    # 示例:带双向 TLS 的 OTLP 导出器
    # [otel.exporter."otlp-http"]
    # endpoint = "https://otel.example.com/v1/logs "
    # protocol = "binary"
    
    # [otel.exporter."otlp-http".headers]
    # "x-otlp-api-key" = "${OTLP_TOKEN}"
    
    # [otel.exporter."otlp-http".tls]
    # ca-certificate = "certs/otel-ca.pem"  # CA 证书路径
    # client-certificate = "/etc/codex/certs/client.pem"  # 客户端证书
    # client-private-key = "/etc/codex/certs/client-key.pem"  # 客户端私钥
    

    config.toml.txt

    MCP 推荐:

    windows 版:

    [mcp_servers.chrome-devtools] command = "cmd" args = [
      "/c",
      "npx",
      "-y",
      "chrome-devtools-mcp@latest",
    ]
    env = { SystemRoot="C:\\Windows", PROGRAMFILES="C:\\Program Files" }
    startup_timeout_ms = 60_000 [mcp_servers.context7] command = "cmd" args = [
    "/c",
    "npx",
    "-y",
    "@upstash/context7-mcp",
    "--api-key",
    "YOUR_API_KEY"
    ]
    env = { SystemRoot="C:\Windows" }
    startup_timeout_ms = 20_000 [mcp_servers.replicate] command = "cmd" args = [
      "/c",
      "npx",
      "-y",
      "replicate-flux-mcp"
    ]
    env = { SystemRoot="C:\\Windows", PROGRAMFILES="C:\\Program Files", REPLICATE_API_TOKEN="r8_MPwJVCYxBSvrYNSETThDE69JQwAAk9SC3r7XSW" }
    startup_timeout_ms = 60_000 [mcp_servers.github] command = "cmd" args = [
      "/c",
      "npx",
      "-y",
      "mcp-remote@latest",
      "https://api.githubcopilot.com/mcp/",
      "--header",
      "Authorization: Bearer xx_Axxx7ICfgT0Vyyd6"
    ]
    env = { SystemRoot="C:\\Windows", PROGRAMFILES="C:\\Program Files" }
    startup_timeout_ms = 60_000`
    

    MacOS 版:

    [mcp_servers.chrome-devtools]
    command = "npx"
    args = [
      "-y",
      "chrome-devtools-mcp@latest"
    ]
    
    
    [mcp_servers.context7]
    args = ["-y", "@upstash/context7-mcp", "--api-key", "YOUR_API_KEY"]
    command = "npx"
    
    
    [mcp_servers.replicate]
    command = "npx"
    args = [
      "-y",
      "replicate-flux-mcp"
    ]
    env = {"REPLICATE_API_TOKEN="r8_MPwJVCYxbSvrYNSETHDE69JQwAAk9sC3r7XSW"}
    
    
    [mcp_servers.github]
    command = "npx"
    args = [
        "-y",
        "mcp-remote@latest",
        "https://api.githubcopilot.com/mcp/",
        "--header",
        "Authorization: Bearer sssssHU5HQZGK4ssgT0Vyyd6"
    ]
    
    
    [mcp_servers.sequential-thinking]
    command = "npx"
    args = ["-y", "@modelcontextprotocol/server-sequential-thinking"]
    
    [mcp_servers.playwright]
    command = "npx"
    args = ["@playwright/mcp@latest"]
    
    [mcp_servers.mcp-server-time]
    command = "uvx"
    args = ["mcp-server-time", "--local-timezone=Asia/Shanghai"]
    
    [mcp_servers.mcp-shrimp-task-manager]
    command = "npx"
    args = ["-y", "mcp-shrimp-task-manager"]
    env = { DATA_DIR = "/Users/lostsheep/tools/mcp-shrimp-task-manager/data", TEMPLATES_USE = "zh", ENABLE_GUI = "false" }
    
    [mcp_servers.mcp-deepwiki]
    command = "npx"
    args = ["-y", "mcp-deepwiki@latest"]
    
    [mcp_servers.desktop-commander]
    command = "npx"
    args = ["-y", "@wonderwhy-er/desktop-commander"]
    # --- End MCP servers ---
    

    Skills

    ---
    name: openspec
    description: OpenSpec 中文版规范助手 - 规范驱动的 AI 编程开发,帮助初始化、创建提案、编写规格、校验格式并归档变更。触发条件: 当用户提及 openspec、规范文档、需求管理、变更提案、spec-driven development 等关键词时主动调用。
    trigger: 当用户提及 openspec、规范文档、需求管理、变更提案、spec-driven development 等关键词时主动调用
    ---
    
    # OpenSpec 中文版规范助手
    
    OpenSpec 是一个 CLI 工具,通过**规范驱动的开发流程**帮助开发者与 AI 编码助手建立明确的需求共识。核心理念是:**在编写代码前,先将需求文档化并达成一致**,从而消除 AI 工具仅依赖对话历史产生的不可预测输出。
    
    ## 什么是 OpenSpec
    
    ### 核心价值
    
    - **准确性**:需求明确后大幅减少返工,避免 AI 理解偏差
    - **可追溯性**:每个技术决策都有完整的文档记录
    - **文档化**:自动生成的规范与代码保持同步,形成活文档
    - **团队友好**:清晰的提案便于多人协作和 Code Review
    
    ### 适用场景
    
    ✅ **最适合**:
    
    - 改进现有项目(1→n 开发,棕地项目)
    - 需要高质量实现的关键功能
    - 团队协作开发
    - 使用 Claude Code、Cursor、Cline 等 AI 工具
    - 需要长期维护的项目
    
    ❌ **不适合**:
    
    - 快速原型验证(0→1 探索阶段)
    - 一次性小脚本
    - 需求极度不明确的创新性探索
    
    ### 实践价值
    
    前期多花 10-15 分钟与 AI 澄清需求、编写规范,能节省数小时的返工时间。规范文档会随着项目演进不断积累,最终形成完整的系统文档。
    
    ## 双文件夹模型
    
    OpenSpec 使用独特的**双文件夹模型**,将"事实"与"提案"分离:
    
    ```plain
    openspec/
    ├── specs/          # 📚 事实:已实施并归档的规范(source-of-truth)
    │   ├── auth.md
    │   ├── api.md
    │   └── database.md
    └── changes/        # 💡 提案:待实施的变更(明确的差异管理)
        ├── add-oauth-login/
        │   ├── proposal.md
        │   ├── tasks.md
        │   └── specs/
        │       └── auth-delta.md
        └── optimize-api-cache/
            ├── proposal.md
            └── specs/
                └── api-delta.md
    ```
    
    **设计理念**:
    
    - `specs/` 是系统的当前状态
    - `changes/` 是即将到来的变化
    - 这种分离让"差异明确且可管理",特别适合修改现有系统
    
    ## 环境与安装
    
    ### 基本要求
    
    - **Node.js** >= 20.19.0(Node 22 也兼容)
    - **无需 API 密钥**:完全本地执行,与现有开发工具集成
    
    ### 安装方式
    
    **全局安装(推荐)**:
    
    ```bash
    npm install -g @org-hex/openspec-chinese@latest
    # 或使用 pnpm
    pnpm install -g @org-hex/openspec-chinese@latest
    ```
    
    **临时使用**(不安装):
    
    ```bash
    pnpm dlx @org-hex/openspec-chinese init
    pnpm dlx @org-hex/openspec-chinese proposal "功能描述"
    ```
    
    **验证安装**:
    
    ```bash
    openspec-chinese --version
    openspec-chinese --help
    ```
    
    ### 支持的 AI 工具
    
    OpenSpec 支持 **20+ AI 编程助手**,包括:
    
    - **原生斜杠命令**:Claude Code, Cursor, CodeBuddy, Cline 等
    - **AGENTS.md 回退**:所有支持自定义指令的工具(通用兼容)
    
    无需额外配置,安装后即可在所有支持的工具中使用。
    
    ## 项目初始化
    
    ### 初始化结构
    
    ```bash
    # 在全新项目中初始化
    openspec-chinese init
    
    # 在现有 OpenSpec 项目中切换到中文版
    openspec-chinese update
    ```
    
    生成的完整结构:
    
    ```plain
    openspec/
    ├── project.md      # 项目上下文(技术栈、架构、团队约定)
    ├── AGENTS.md       # AI 助手通用指令(20+ 工具兼容)
    ├── specs/          # 现行规范库(已归档的事实)
    ├── changes/        # 变更提案目录
    └── templates/      # 自定义模板(可选)
    ```
    
    **重要**:初始化后如果 IDE 里斜杠命令未出现,请重启 IDE/AI 工具。
    
    ### 补全 project.md
    
    生成 `project.md` 后,应立即向 AI 提出:
    
    ```markdown
    请阅读 openspec/project.md 并帮助我填写:
    
    1. 项目的核心技术栈
    2. 架构设计约定
    3. 编码规范和最佳实践
    4. 团队协作流程
    ```
    
    完善的 `project.md` 能让 AI 助手更好地理解项目上下文,生成更符合实际的规范文档。
    
    ## 五阶段完整工作流程
    
    ### 阶段 1:起草提案(Draft Proposal)
    
    **目标**:创建变更文件夹,初步定义需求
    
    ```bash
    # 命令行方式
    openspec-chinese proposal "添加 OAuth 登录功能"
    
    # AI 工具斜杠命令
    /openspec-proposal
    ```
    
    **输出**:
    
    ```plain
    openspec/changes/add-oauth-login/
    ├── proposal.md     # AI 生成的初步提案
    ├── tasks.md        # 任务分解清单
    └── specs/          # 增量规范(空)
    ```
    
    **交互要点**:
    
    - AI 会提出澄清问题(例如:"使用哪些 OAuth 提供商?")
    - 回答问题后,AI 生成详细的 `proposal.md` 和 `tasks.md`
    
    ### 阶段 2:审查对齐(Review & Align)
    
    **目标**:人和 AI 共同审查,反复迭代直到需求明确
    
    ```bash
    # 查看提案详情
    openspec-chinese show add-oauth-login
    
    # 在 AI 工具中交互
    "请根据我的反馈修改 proposal.md:
    1. 只支持 GitHub 和 Google OAuth
    2. 需要处理现有用户的账号合并逻辑
    3. 增加 OAuth 失败时的降级方案"
    ```
    
    **迭代过程**:
    
    1. 审查 `proposal.md` 的 Why/What/Impact
    2. 检查 `tasks.md` 的任务拆解是否合理
    3. 提出修改建议,让 AI 更新文档
    4. 重复直到完全对齐
    
    **关键**:这个阶段多花时间,后续实施会快很多。
    
    ### 阶段 3:编写规格(Write Specs)
    
    **目标**:在 `specs/` 目录下编写符合格式的增量规范
    
    ```bash
    # AI 工具中请求
    "请为 add-oauth-login 变更编写规格文档,放在 specs/ 目录"
    ```
    
    **规范格式**(详见下文"规格文档格式要求"):
    
    ```markdown
    ## ADDED Requirements
    
    ### Requirement: OAuth 登录支持
    
    系统 MUST 支持通过 GitHub 和 Google 进行 OAuth 登录。
    
    #### Scenario: GitHub OAuth 登录成功
    
    - **WHEN** 用户点击"使用 GitHub 登录"按钮
    - **THEN** 系统跳转到 GitHub OAuth 授权页面
    - **AND** 授权成功后返回并创建会话
    ```
    
    ### 阶段 4:校验与实施(Validate & Implement)
    
    **校验格式**:
    
    ```bash
    # 严格格式校验
    openspec-chinese validate add-oauth-login --strict
    
    # 中文格式专项校验(需配置)
    npm run validate:chinese
    ```
    
    **实施开发**:
    
    ```bash
    # AI 工具中参考规范实施
    "请参考 openspec/changes/add-oauth-login/specs/ 中的规范,
    按照 tasks.md 的任务清单逐步实施功能"
    ```
    
    **任务追踪**:
    
    - 在 `tasks.md` 中勾选已完成的任务
    - AI 会自动参考规范,减少理解偏差
    
    ### 阶段 5:归档与文档化(Archive & Document)
    
    **目标**:将完成的变更合并到主规范库
    
    ```bash
    # 查看所有变更
    openspec-chinese list
    
    # 归档已完成的变更
    openspec-chinese archive add-oauth-login --yes
    ```
    
    **效果**:
    
    - `changes/add-oauth-login/` 的规范合并到 `specs/`
    - 变更记录自动保存
    - 形成活文档,与代码同步
    
    ### 流程图总览
    
    ```mermaid
    flowchart TD
      A[1. 起草提案<br/>AI 澄清问题] --> B[2. 审查对齐<br/>迭代完善需求]
      B --> C[3. 编写规格<br/>Delta + Scenarios]
      C --> D[4. 校验格式<br/>validate --strict]
      D --> E{格式正确?}
      E -- 否 --> C
      E -- 是 --> F[5. 实施开发<br/>按规范编码]
      F --> G[6. 归档文档<br/>archive --yes]
      G --> H[规范库更新<br/>活文档形成]
    ```
    
    ## 规格文档格式要求
    
    OpenSpec 使用**严格的格式规范**,确保 AI 和人都能准确理解需求。
    
    ### 核心原则
    
    1. **Delta 分区**:使用英文标题标识变更类型
    2. **强制关键词**:需求必须包含 MUST/SHALL/SHOULD
    3. **Gherkin 场景**:使用英文关键字描述验收标准
    4. **中英混合**:结构英文,描述中文
    
    ### 1. Delta 分区(必填)
    
    **三种变更类型**:
    
    ```markdown
    ## ADDED Requirements
    
    # 新增的能力
    
    ## MODIFIED Requirements
    
    # 修改现有行为
    
    ## REMOVED Requirements
    
    # 废弃的功能(需说明原因和迁移路径)
    ```
    
    ### 2. Requirement 语句规范
    
    **格式**:
    
    ```markdown
    ### Requirement: [需求名称]
    
    系统 [MUST/SHALL/SHOULD] [能力描述]。
    ```
    
    **强制关键词**:
    
    - **MUST** / **SHALL**:强制要求,不可妥协
    - **SHOULD**:建议要求,可协商
    - **MAY**:可选要求
    
    **示例**:
    
    ```markdown
    ### Requirement: 用户搜索功能
    
    系统 MUST 提供用户搜索功能,支持按用户名、邮箱、手机号进行模糊查询。
    
    系统 SHOULD 在搜索结果中高亮匹配的关键词。
    ```
    
    ### 3. Scenario 场景描述(验收标准)
    
    **格式**:
    
    ```markdown
    #### Scenario: [场景名称]
    
    - **WHEN** [前置条件]
    - **THEN** [预期结果]
    - **AND** [额外条件/结果]
    ```
    
    **要求**:
    
    - 每个 Requirement 至少有一个 Scenario
    - 使用**英文 Gherkin 关键字**(WHEN/THEN/AND/GIVEN)
    - 描述内容可以是中文
    
    **示例**:
    
    ```markdown
    #### Scenario: 按邮箱搜索用户
    
    - **WHEN** 用户在搜索框输入 "test@example.com"
    - **THEN** 系统返回邮箱包含该字符串的用户列表
    - **AND** 列表按相关度排序
    - **AND** 邮箱中的匹配部分高亮显示
    
    #### Scenario: 搜索无结果
    
    - **WHEN** 用户输入不存在的邮箱
    - **THEN** 系统显示"未找到匹配用户"
    - **AND** 提示用户检查输入或尝试其他搜索条件
    ```
    
    ### 4. 删除需求的特殊要求
    
    删除需求时**必须**提供 Reason 和 Migration:
    
    ```markdown
    ## REMOVED Requirements
    
    ### Requirement: 用户密码明文存储
    
    - **Reason**: 严重的安全隐患,违反 OWASP 安全规范
    - **Migration**:
      1. 所有密码已迁移到 bcrypt 加密存储
      2. 用户首次登录时会自动升级密码加密方式
      3. 详细迁移指南:`docs/password-migration.md`
    ```
    
    ### 5. 修改需求的说明
    
    修改现有功能时应说明变化:
    
    ```markdown
    ## MODIFIED Requirements
    
    ### Requirement: 用户列表分页
    
    - **变化说明**: 将每页默认显示数量从 20 条调整为 50 条
    - **原因**: 用户反馈每页 20 条过少,频繁翻页影响体验
    - **影响范围**:
      - 前端分页组件
      - 后端 API 默认参数
      - 性能测试基准需重新评估
    
    #### Scenario: 默认分页数量
    
    - **WHEN** 用户访问用户列表页面
    - **THEN** 系统默认每页显示 50 条记录
    - **AND** 用户可以在设置中自定义每页条数(10/20/50/100)
    ```
    
    ### 6. 完整示例模板
    
    ```markdown
    ## ADDED Requirements
    
    ### Requirement: 用户数据导出功能
    
    系统 MUST 提供用户数据导出功能,支持 CSV 和 JSON 两种格式。
    
    #### Scenario: 导出为 CSV 格式
    
    - **WHEN** 管理员点击"导出为 CSV"按钮
    - **THEN** 系统生成包含所有用户数据的 CSV 文件
    - **AND** 文件包含字段:用户名、邮箱、注册时间、最后登录时间、状态
    - **AND** 文件名格式为 `users_export_YYYYMMDD_HHmmss.csv`
    
    #### Scenario: 导出权限检查
    
    - **WHEN** 非管理员用户尝试导出
    - **THEN** 系统返回 403 Forbidden 错误
    - **AND** 前端显示"权限不足"提示
    
    #### Scenario: 大数据量导出
    
    - **GIVEN** 系统有超过 10000 条用户记录
    - **WHEN** 管理员点击导出
    - **THEN** 系统显示"正在生成导出文件"进度提示
    - **AND** 导出任务在后台异步执行
    - **AND** 完成后通过邮件发送下载链接
    
    ## MODIFIED Requirements
    
    ### Requirement: 用户列表查询性能
    
    - **变化说明**: 为用户表添加邮箱和手机号索引
    - **原因**: 当前搜索性能在 10 万用户以上明显下降
    - **预期效果**: 搜索响应时间从 2-3 秒降低到 < 500ms
    
    ## REMOVED Requirements
    
    ### Requirement: 用户密码明文存储
    
    - **Reason**: 严重安全隐患,必须移除
    - **Migration**:
      1. 所有密码已迁移到 bcrypt 加密(cost=10)
      2. 用户下次登录时自动完成迁移
      3. 详细文档:`docs/security/password-migration.md`
    ```
    
    ## 常用命令速查
    
    ### 项目管理
    
    ```bash
    # 初始化全新项目
    openspec-chinese init
    
    # 更新/切换到中文版
    openspec-chinese update
    
    # 查看版本
    openspec-chinese --version
    ```
    
    ### 变更管理
    
    ```bash
    # 创建新提案
    openspec-chinese proposal "功能描述"
    
    # 查看所有变更
    openspec-chinese list
    
    # 查看特定变更详情
    openspec-chinese show <change-name>
    
    # 校验格式(严格模式)
    openspec-chinese validate <change-name> --strict
    
    # 归档已完成的变更
    openspec-chinese archive <change-name> --yes
    ```
    
    ### AI 工具斜杠命令
    
    在支持的 AI 工具(Claude Code, Cursor 等)中:
    
    ```bash
    /openspec-proposal          # 创建新提案
    /openspec-validate          # 校验当前变更
    /openspec-archive           # 归档变更
    ```
    
    ## 自定义模板
    
    ### 创建模板
    
    在 `openspec/templates/` 目录下创建自定义模板:
    
    ```bash
    # 创建功能规格模板
    openspec/templates/feature-spec.md
    
    # 创建 API 规格模板
    openspec/templates/api-spec.md
    
    # 创建数据库变更模板
    openspec/templates/db-migration-spec.md
    ```
    
    ### 模板示例
    
    ```markdown
    <!-- openspec/templates/feature-spec.md -->
    
    ## ADDED Requirements
    
    ### Requirement: [功能名称]
    
    系统 MUST [功能描述]。
    
    #### Scenario: [主要场景]
    
    - **WHEN** [前置条件]
    - **THEN** [预期结果]
    - **AND** [额外条件]
    
    #### Scenario: [错误场景]
    
    - **WHEN** [异常情况]
    - **THEN** [错误处理]
    - **AND** [用户提示]
    
    ## MODIFIED Requirements
    
    (如有修改现有功能,在此说明)
    
    ## REMOVED Requirements
    
    (如有废弃功能,在此说明原因和迁移路径)
    ```
    
    ### 使用模板
    
    ```bash
    # 创建新变更时,从模板复制
    cp openspec/templates/feature-spec.md openspec/changes/new-feature/specs/feature.md
    
    # 然后填充具体内容
    ```
    
    ## 最佳实践
    
    ### 1. 提案阶段多花时间
    
    - ✅ 与 AI 充分沟通,澄清所有疑问
    - ✅ 详细拆解任务到可执行的粒度
    - ✅ 确保 proposal.md 中的 Why/What/Impact 清晰
    - ❌ 不要急于开始编码,需求不明会导致大量返工
    
    ### 2. 规格要具体可验证
    
    - ✅ 每个需求至少有 1-2 个 Scenario
    - ✅ Scenario 要具体,可直接转化为测试用例
    - ✅ 包含正常流程和异常流程
    - ❌ 避免模糊描述,如"系统应该快速响应"
    
    ### 3. 利用 validate 命令
    
    ```bash
    # 每次编辑规格后立即校验
    openspec-chinese validate <change> --strict
    
    # 配置 Git pre-commit hook
    npm run validate:chinese
    ```
    
    ### 4. 保持规范与代码同步
    
    - ✅ 代码实现后,确保规范准确反映最终结果
    - ✅ 如有偏差,更新规范或代码使其一致
    - ✅ 归档前再次审查规范的准确性
    
    ### 5. 利用 project.md
    
    ```markdown
    <!-- openspec/project.md -->
    
    # 项目上下文
    
    ## 技术栈
    
    - 前端: React 18 + TypeScript
    - 后端: Node.js + Express
    - 数据库: PostgreSQL 14
    
    ## 架构约定
    
    - RESTful API 设计
    - JWT 认证
    - 统一错误处理中间件
    
    ## 编码规范
    
    - ESLint + Prettier
    - 函数式组件优先
    - 使用 React Query 管理服务端状态
    ```
    
    完善的 `project.md` 能让 AI 生成更符合项目规范的代码。
    
    ### 6. 版本兼容
    
    OpenSpec 中文版与英文版**完全兼容**:
    
    ```bash
    # 切换到中文版
    openspec-chinese update
    
    # 切换回英文版
    openspec update
    ```
    
    两个版本可以在团队中并存,规范文件格式完全一致。
    
    ## 常见问题排查
    
    ### 命令不可用
    
    **症状**:`openspec-chinese: command not found`
    
    **解决方案**:
    
    ```bash
    # 检查是否在 PATH 中
    which openspec-chinese  # Mac/Linux
    where openspec-chinese  # Windows
    
    # 检查 npm 全局 bin 路径
    npm config get prefix
    
    # 重新安装
    npm uninstall -g @org-hex/openspec-chinese
    npm install -g @org-hex/openspec-chinese@latest
    ```
    
    ### 斜杠命令未出现
    
    **症状**:AI 工具中看不到 `/openspec-*` 命令
    
    **解决方案**:
    
    ```bash
    # 执行更新命令
    openspec-chinese update
    
    # 重启 IDE/AI 工具
    # 检查是否生成了 AGENTS.md
    ls openspec/AGENTS.md
    ```
    
    ### 校验报错
    
    **常见错误**:
    
    1. **缺少 Delta 分区**
    
       ```plain
       Error: Missing required Delta sections (ADDED/MODIFIED/REMOVED)
       ```
    
       解决:确保至少有一个 Delta 分区
    
    2. **缺少 MUST/SHALL 关键词**
    
       ```plain
       Error: Requirement missing mandatory keywords
       ```
    
       解决:在需求描述中添加 MUST/SHALL/SHOULD
    
    3. **Scenario 层级错误**
    
       ```plain
       Error: Scenario must be under a Requirement
       ```
    
       解决:确保 `#### Scenario:` 在 `### Requirement:` 之下
    
    4. **Gherkin 关键字使用中文**
       ```plain
       Error: Gherkin keywords must be in English
       ```
       解决:使用 WHEN/THEN/AND 而非"当/那么/并且"
    
    ### 归档失败
    
    **症状**:`openspec-chinese archive` 报错
    
    **可能原因**:
    
    - 变更未通过校验
    - specs/ 目录为空
    - Git 冲突
    
    **解决方案**:
    
    ```bash
    # 先校验格式
    openspec-chinese validate <change> --strict
    
    # 检查 specs/ 目录
    ls openspec/changes/<change>/specs/
    
    # 解决 Git 冲突后重试
    git status
    ```
    
    ## 触发场景
    
    本技能应在以下场景**主动调用**:
    
    ### 明确触发
    
    1. 用户提及 "openspec"
    2. 用户提及 "规范文档"、"需求文档"
    3. 用户提及 "spec-driven development"
    4. 用户询问如何管理需求
    
    ### 上下文触发
    
    5. 用户开始新功能开发前(建议使用 OpenSpec)
    6. 用户抱怨 AI 理解偏差或频繁返工
    7. 用户询问如何让 AI 更准确理解需求
    8. 用户需要生成技术文档
    
    ### 项目阶段触发
    
    9. 项目初始化阶段(建议配置 OpenSpec)
    10. 准备重大重构时(建议先写规范)
    11. 团队协作场景(提供统一的需求描述)
    
    ## 执行长任务时的注意事项
    
    1. **及时更新任务文件**:
       > **必须要**及时更新对应任务的 `tasks.md` 任务进度文件。避免出现大批量完成任务后,没有更新进度文件的情况,带来严重的误解。
    2. 启动**多个子代理**分模块并行完成任务:
       > 务必要启动多个在后台运行的子代理,同时完成 openspec 设定的一系列繁杂的任务。以便加快速度。你应该至少同时启用至少 4 个子代理。并根据情况,主动增加足够数量的子代理完成任务。
    3. 回复文本语言:
       > 务必用**中文**回复用户。
    4. 上下文合并后重新阅读一次任务要求:
       > 为了避免你在自动合并上下文的时候,给后续的任务带来明显的幻觉,你应该及时的重新阅读 openspec 的任务规范要求。
    5. 连续的,持续的执行长任务:
       - 你应该一次性完成 `tasks.md` 所记录的全部任务。你应该同时新建多个子代理,做出合理的任务划分,一次性完成任务。
       - 不要在完成一个任务的时候就停下来询问用户。这种停顿方式很低效率,你要避免这种执行方式。
    6. **禁止**编写脚本完成批处理任务:
       - **不允许**你编写任何 Python、typescript、javascript,或 bash 脚本,完成大批量代码删改之类的任务。
       - 你应该阅读文件来完成更改,而不是使用不稳定的,容易带来语法错误的,删改不干净不合理的批处理脚本,来完成任务。
       - 你应该新建多个子代理,用具体的子代理来完成大规模的修改任务。
    7. 主从代理的调度设计:
       - `主代理的职责`: 主代理应该负责全面的,完整的阅读来自 openspec 目录下全部的 markdown 文档任务要求。并按照模块和错误类型,新建足够数量的子代理。并持续监听,定期收集来自子代理的处理反馈。
       - `子代理的职责`: 子代理应该严格按照主代理给定的要求来完成任务。
    8. 什么情况下应该新建子代理?在以下的几种情况下,主代理应该及时新建子代理来完成任务:
       - 大规模的代码探索与信息收集任务。
       - 访问 url 获取文档信息的任务。
       - 指定严格顺序的代码修改任务。
       - 报告编写任务。
       - 进度文件更新与编写任务。
    
    ## 注意事项
    
    ### 格式要求(严格遵守)
    
    1. ✅ Delta 分区标题必须使用**英文**(ADDED/MODIFIED/REMOVED)
    2. ✅ Gherkin 关键字必须使用**英文**(WHEN/THEN/AND/GIVEN)
    3. ✅ 需求描述中必须包含 MUST/SHALL/SHOULD 等**强制关键词**
    4. ✅ 删除需求时必须提供 **Reason** 和 **Migration**
    5. ✅ 每个 Requirement 至少有**一个 Scenario**
    
    ### 工作流建议
    
    1. ⏰ 提案阶段多花时间,实施阶段会快很多
    2. 📝 规格要具体可验证,能直接转化为测试用例
    3. ✅ 每次编辑后立即运行 `validate --strict`
    4. 🔄 保持规范与代码同步,归档前再次审查
    5. 📚 善用 `project.md` 提供项目上下文
    
    ### 团队协作
    
    1. 👥 规范文件适合 Code Review
    2. 📖 `changes/` 目录中的提案可作为 PR 描述
    3. 🔍 归档后的 `specs/` 成为团队共识
    4. 🌍 中英文版本可并存,格式完全兼容
    
    ### 工具集成
    
    1. 🤖 支持 20+ AI 编程工具,无缝集成
    2. 🔒 完全本地执行,无需 API 密钥
    3. 📂 AGENTS.md 提供通用兼容性
    4. ⚡ 斜杠命令提供快捷操作
    
    ---
    
    ## 参考资源
    
    - **OpenSpec 中文版仓库**: https://github.com/hex-novaflow-ai/OpenSpec-Chinese
    - **OpenSpec 原版仓库**: https://github.com/Fission-AI/OpenSpec
    - **介绍教程**: https://www.aivi.fyi/llms/introduce-OpenSpec
    - **官方文档**: 项目 README 和 docs 目录
    

    全局 agents.md 推荐:

    AGENTS.md.txt

    config 是与服务器 "打交道" 的配置,Agents. 是操作指南,告诉 Ai 在操作 Project 如何去做。
    比如是一辆车,如果 Agents 是大脑是车机控制系统,来操作车的自动驾驶。那么 config 就是底盘。通过 config 切换不同底盘。

    “道路 " 就是我们的项目,Agents.md 写的太好,底盘不好,驾驶起来照样别扭。想象一下你是全国第一赛车手,但是你驾驶的是一辆老头乐,那么必然发挥不出来。

    这就是木桶效应!!!所以我们一定要对齐短板。


    📌 转载信息
    原作者:
    dwifbytslqh
    转载时间:
    2026/1/23 15:44:35

    图片
    伴随多智能体系统的规模化落地与技术迭代,其跨智能体交互的动态性与决策链路的黑箱特性,使AI协作的复杂度呈指数级攀升。传统可观测体系以指标、日志、链路等系统运行数据为核心,主要解答“系统发生了什么?”的问题。但当面对多个自主决策、动态交互的AI智能体时,我们更需要解答:“智能体为何这样决策?”、“协作是否高效合理?”以及“如何保证结果可靠与成本可控?”等难题。多智能体不仅改变了应用架构,更从根本上对可观测性的深度与广度提出了新的要求:如何打通从数据获取、分析到决策的完整价值链,形成高效闭环?当自动配置、智能见解等核心能力孤立运行时,如何实现它们的协同联动,以精准应对复杂运维场景?又该如何突破当前自动化诊断的瓶颈,稳步迈向预测性干预与系统自愈的高阶智能化阶段?Bonree精彩直播,码上预约为深入探讨这一命题,博睿数据特别推出【前瞻2026:可观测技术风向与趋势洞察】专题直播,直播分为上下两期。下期直播,我们聚焦于可观测性产品本身的演进路径:1月28日(周三)14:00,博睿数据产品中心高级产品经理马倩,将带来 《多智能体协同下的可观测产品体系化演进》主题分享。本次直播将从实际产品视角出发,聚焦可观测性产品的演进路径,从产品内核、协同逻辑到突破方向,展开全方位、深层次的拆解与分析。
    图片
    博睿宏远,将在01月28日 14:00 直播已预约多智能体协同下的可观测产品演进
    图片
    本次直播我们将深入探讨技术趋势,助力大家洞悉多智能体时代可观测性领域的全新挑战与技术走向。立即预约直播,解锁多智能体协同下可观测产品体系化演进,获取该领域关键认知与演进逻辑!

    分享一个通用提示词网站

    里面有很多类型的提示词可以供老友参考


    📌 转载信息
    原作者:
    xuancheng
    转载时间:
    2026/1/23 15:44:10

    为什么会做这款工具呢,当时碰到做题目时候没法复制就搞了一个强行复制功能

    强行复制

    一款浏览器扩展,解除网页复制限制,让你自由复制任何内容。支持 Chrome、Edge 等 Chromium 内核浏览器。

    功能

    • 解除文本选择限制
    • 解除复制 / 剪切 / 粘贴限制
    • 恢复右键菜单
    • 绕过切屏检测

    安装

    方法一:直接安装

    1. 下载 Releases 中的 zip 文件
    2. 解压到任意文件夹
    3. 打开浏览器扩展管理页面
    • Chrome: chrome://extensions/
    • Edge: edge://extensions/
    1. 开启右上角「开发者模式」
    2. 点击「加载已解压的扩展程序」
    3. 选择解压后的文件夹

    方法二:克隆仓库

    git clone GitHub - 2337761309/ForceCopy: 一款浏览器扩展,解除网页复制限制,让你自由复制任何内容。支持 Chrome、Edge 等 Chromium 内核浏览器。

    然后按方法一的步骤 3-6 加载扩展。

    使用

    • 全局启用:开启后所有网页自动生效
    • 单页启用:关闭全局时,可单独对当前页面启用

    📌 转载信息
    原作者:
    2337761309
    转载时间:
    2026/1/23 15:43:40

    随着微软白嫖的 2~5 年,找到了 Azure 这个项目。首先你得过了学生验证。然后开始我们的部署。100​礼金花完就没有了。

    步骤 1:创建 Azure 虚拟机

    链接直达:

    1. 登录 Azure 门户
    2. 创建虚拟机,核心参数如下(避坑关键点):
      • 区域: 选择 Canada Central (加拿大中部) 或 Australia East (澳洲东部),避免免费账户在热门区域被拦截。
      • 映像
      • 大小: 选择 Standard B2ts v2 (比 B1s 性能更好)。
      • 网络: 公共 IP 必须新建。
      • 管理: 关闭所有自动关机、备份、监控以节省资源。

        注意:这里你可以选密钥,如果你习惯用的话,安全性更好。但是账号密码方便后面的步骤,本人是账号密码,后续步骤你可能要微调。记住你这里的账号密码,后面的操作要用。


    步骤 2:开放网络端口 (8000)

    1. 进入 Azure 虚拟机页面 → 左侧菜单 网络 (Networking)
    2. 点击 添加入站端口规则 (Add inbound port rule)
    3. 目标端口范围: 填入 8000
    4. 协议: TCP 或 Any。
    5. 操作: 允许 (Allow)。
    6. 点击添加。


    步骤 3:SSH 连接与环境准备

    使用终端连接服务器: 这里就是上面提到的账号密码,

    ssh 用户名@服务器公网IP
    


    这里你输入密码都是看不见的,你凭感觉自己输入进去!!输完了敲回车。

    后面操作都在 ssh 内部进行。

    关键步骤:增加虚拟内存 (Swap) 由于 1G 内存无法完成前端编译,必须增加 Swap。执行以下命令:

    # 创建 2G 的 Swap 文件 sudo fallocate -l 2G /swapfile
    sudo chmod 600 /swapfile
    sudo mkswap /swapfile
    sudo swapon /swapfile
    # 设置开机自动挂载 echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
    

    步骤 4:安装 Node.js 和 SillyTavern【这一步建议问 AI,把你的进程喂给他,让他给你发,我的朋友有些直接可以,有些有 BUG,自测。不会的问哈基米或者 gpt】

    # 1. 更新系统并安装 Node.js 20 sudo apt update && sudo apt install -y curl git
    curl -fsSL [https://deb.nodesource.com/setup_20.x](https://deb.nodesource.com/setup_20.x) | sudo -E bash -
    sudo apt install -y nodejs
    
    # 2. 克隆酒馆仓库
    git clone [https://github.com/SillyTavern/SillyTavern.git](https://github.com/SillyTavern/SillyTavern.git)
    cd SillyTavern
    
    # 3. 安装依赖
    npm install
    

    步骤 5:修改配置 (公网访问与安全)
    注意:不要直接启动,先修改配置。

    cd ~/SillyTavern
    
    nano config.yaml
    

    利用方向键一个个改。
    1. 允许公网 IP 访问 (listen: true)
    2. 启用账号密码认证 (推荐)
    basicAuthMode: true
    3. 设置用户名 (自定义,例如 admin)
    basicAuthUser: 你的用户名
    4. 设置密码 (自定义,越复杂越好)
    basicAuthPass: 你的密码

    改完后,我们 ctrl+o 按回车确认。ctrl+x 退出。

    或者 或者 或者 或者关系!!
    直接关闭白名单 (不推荐,不安全)

    whitelistMode: true

    冒号后面都有空格,请仔细确认格式。不会的问 AI。

    步骤 6:配置后台进程守护 (PM2)
    为了让酒馆关闭 SSH 窗口后依然运行,并开机自启。

    1. 安装 PM2

    sudo npm install -g pm2
    

    2. 启动酒馆

    pm2 start start.sh --name "MyTavern" 

    3. 保存并设置开机自启

    pm2 save
    pm2 startup
    #(如果 pm2 startup 提示执行一行 sudo 命令,请复制并执行它) 

    到这一步,你会看到最底下有一行 sudo 命令,我们要手动复制出来,然后执行。

    你的公网 IP:8000
    例如: 11.22.33.44:8000 访问你的酒馆,账号密码是刚刚手动设置的。

    然后开始你的酒馆之旅。

    步骤 7:后续维护与更新
    如何更新酒馆到最新版

    cd ~/SillyTavern
    git pull
    npm install
    pm2 restart MyTavern
    

    如何修改密码?

    cd ~/SillyTavern
    # 使用 nano 编辑器修改
    nano config.yaml
    # 修改 basicAuthUser 和 basicAuthPass 字段 # 保存退出: Ctrl+O -> 回车 -> Ctrl+X # 重启生效
    pm2 restart MyTavern
    

    📌 转载信息
    原作者:
    Zooo1
    转载时间:
    2026/1/23 15:43:27

    https://linux.do/t/topic/1349295

    既上次的监控小脚本之后做了一些视觉优化和新的功能!(本来想更新在那个帖子里半天没找到编辑……)
    这次增加了一个新的小脚本 —— 批量起号脚本(存疑),支持的功能有:根据你上传的图片和文案随机组合,定时发送。给定帖子 url,批量关注帖子下的用户
    并且由于 x 的 api 直接一个大变导致现在实在用不了了,所以现在的脚本以及之前的监控脚本加了新的操作方式:模拟浏览器登录(第一次会需要常规登录,后续就一直按照这个浏览器来模仿登录了)
    主要在 windows 上做的调试,mac 包暂时没测试过)

    欢迎点点星星!

    具体使用:

    1. 找到页面左上角的按钮,进入批量起号页面

    2. 第一次使用:
    如图,记得设置代理

    3. 其他内容说明


    📌 转载信息
    转载时间:
    2026/1/23 15:41:27

    // ==UserScript== // @name         GitLab - 一键导出所有项目 // @namespace    http://tampermonkey.net/ // @version      1.0 // @description  在 GitLab 项目页面顶部添加自定义按钮用于一键导出所有项目 // @author       LeonShaw // @match        *://*/dashboard/projects // @grant        none // @run-at       document-idle // ==/UserScript==
    
    (function () {
        'use strict';
    
        const { protocol, host } = window.location;
        const baseUrl = `${protocol}//${host}`;
        const apiUrl = `${baseUrl}/api/v4/projects`;
    
        // 获取所有项目(分页) async function fetchAllProjects() {
            const statusEl = document.getElementById('clone-status');
            statusEl.style.display = 'block';
            statusEl.textContent = '正在加载项目...';
    
            let page = 1;
            let allProjects = [];
            try {
                while (true) {
                    const url = `${apiUrl}?per_page=100&page=${page}&order_by=created_at&sort=desc`;
                    const res = await fetch(url, {
                        credentials: 'include' // 携带 cookie,确保认证
                    });
    
                    if (!res.ok) {
                        throw new Error(`HTTP ${res.status}: ${await res.text()}`);
                    }
    
                    const data = await res.json();
                    if (!Array.isArray(data) || data.length === 0) break;
    
                    allProjects.push(...data);
                    statusEl.textContent = `已加载 ${allProjects.length} 个项目...`;
                    page++;
                }
    
                generateAndDownloadScript(allProjects);
                statusEl.textContent = `完成!共 ${allProjects.length} 个项目。`;
            } catch (err) {
                console.error('获取项目失败:', err);
                statusEl.textContent = `错误: ${err.message || '未知错误'}`;
            } finally {
                setTimeout(() => {
                    statusEl.style.display = 'none';
                    statusEl.textContent = '';
                }, 30000);
            }
        }
    
        // 生成并下载 .sh 脚本 function generateAndDownloadScript(projects) {
            const lines = ['#!/bin/bash\n'];
    
            projects.forEach(proj => {
                if (!proj.ssh_url_to_repo) return;
    
                const sshUrl = proj.ssh_url_to_repo;
    
                const localPath = proj.path_with_namespace;
                lines.push(`git clone "${sshUrl}" "./${localPath}"`);
            });
    
            const scriptContent = lines.join('\n') + '\n';
            const blob = new Blob([scriptContent], { type: 'text/plain;charset=utf-8' });
            const filename = `clone-all-git-repos(${host}).sh`;
    
            // 创建下载链接 const link = document.createElement('a');
            link.href = URL.createObjectURL(blob);
            link.download = filename;
            link.click();
            URL.revokeObjectURL(link.href);
        }
    
        function addButton() {
            const breadcrumbWrapper = document.querySelector('#js-vue-page-breadcrumbs-wrapper');
            if (!breadcrumbWrapper) return;
    
            // 防止重复添加 if (breadcrumbWrapper.querySelector('.custom-gitlab-button')) return;
    
            // 创建按钮 const button = document.createElement('button');
            button.textContent = '一键导出所有项目';
            button.className = 'custom-gitlab-button gl-button btn btn-default btn-sm gl-mx-2';
            button.style.marginLeft = '10px';
            button.addEventListener('click', function () {
                fetchAllProjects();
            });
    
    
            breadcrumbWrapper.appendChild(button);
    
            const statusElement = document.createElement('span');
            statusElement.id = 'clone-status';
            statusElement.className = 'custom-gitlab-status gl-ml-3 gl-font-sm gl-font-weight-bold';
            statusElement.style.padding = '4px 8px';
            statusElement.style.borderRadius = '4px';
            statusElement.style.backgroundColor = '#e9ecef';
            statusElement.style.color = '#495057';
            statusElement.textContent = '';
            statusElement.style.display = 'none';
    
    
            breadcrumbWrapper.appendChild(statusElement);
        }
    
        addButton();
    
        const observer = new MutationObserver(() => {
            addButton();
        });
        observer.observe(document.body, { childList: true, subtree: true });
    })();
    

    AIGC 声明:本脚本部分函数由 通义千问 辅助创造,本人已验证其生成内容的真实性和有效性

    使用方法


    本脚本已在 Gitlab v18.0.1 - v18.8.1 验证


    📌 转载信息
    原作者:
    LeonShaw
    转载时间:
    2026/1/23 15:40:54