36氪获悉，凯盛新材在互动平台表示，公司目前没有生产磷酸铁锂产品。

36氪获悉，飞书CEO谢欣发文称：个人电脑上跑Agent与企业用Agent是完全不同的事情，前者是探索，后者是责任。个人场景出了错大不了重来，但企业场景出了错，可能是文件被删、数据泄露。Agent能力上限令人兴奋，但安全下限决定是否能够真正进入工作场景，否则越强大、越危险。

在智能家居行业里，「互联互通」几乎已经成为一个被反复提及的关键词。过去几年，从单品智能到全屋智能，行业一直在尝试解决一个问题：如何让家里的设备真正协同起来，而不是各自为战。

AWE  家电和消费电子博览会前夕，华为举办了一场鸿蒙智家技术沟通会。与以往偏产品发布的活动不同，这次沟通会更像是一场围绕技术体系展开的说明会。华为系统性介绍了鸿蒙智家在连接、控制、感知与 AI 等方面的技术架构，同时也带来了多款新的智能家居产品。这场沟通会释放出一个比较清晰的信号：在华为的规划中，智能家居不再只是设备之间的简单连接，而是逐渐演变为一个拥有「系统能力」的家庭空间。

「1+3+N」方案升级：构建家庭智能中枢

在此次技术沟通会上，华为重点介绍了鸿蒙智家「1+3+N」解决方案的升级版本。

该方案以一个智能主机作为家庭系统的核心，再配合稳定的连接能力以及丰富的设备生态，形成完整的全屋智能体系。

其中，「1」指的是智能主机。本次亮相的智能主机 X2 Pro 搭载旗舰手机级芯片，主要负责家庭设备连接与本地计算能力。相比传统依赖云端的控制方式，本地算力的引入能够缩短设备响应时间，同时也为未来功能扩展提供更充足的性能空间。

「3」代表三种交互方式：触控交互、语音交互以及无感交互。与过去以语音控制为主的模式相比，无感交互成为此次升级的重要方向。

借助 AI 超感传感器，系统可以识别人体在空间中的位置。当用户进入房间时，灯光可以自动开启，空调风向也会根据人体位置进行调整，减少直吹人体的情况。在部分场景中，系统能够自动完成设备控制，减少用户手动操作。

AI 感知能力也被应用在健康场景中。例如 AI 辅助康养传感器可以识别睡眠状态，并能够检测跌倒或坠床等异常情况，从而及时发出提醒。

同时，空气质量检测设备可以实时监测室内环境，当空气质量出现变化时，系统能够自动启动新风或空气净化设备。

生态方面，目前鸿蒙智联已经汇聚超过 3200 家合作品牌，覆盖 400 多种产品品类。相关设备可以通过华为智慧生活 App 查询和购买。

针对已经完成装修的家庭，华为也推出了后装解决方案，共提供三档套餐，覆盖基础到进阶的不同需求。同时还推出百元级局部智能化入门套装，让用户可以从单个场景逐步体验智能家居。

Wi-Fi7+技术升级家庭无线网络

在家庭智能化系统中，稳定的网络连接是基础能力之一。此次沟通会上，华为还发布了 Wi-Fi7+ 端到端芯片解决方案。

该方案以海思自研凌霄 760 系列芯片为核心，通过多项技术提升无线网络的稳定性与传输效率。

首先是动态窄频宽技术。当路由器检测到终端设备信号较弱时，可以自动将传输频宽从常规的 20MHz 压缩至 5 至 10MHz，从而提升信号传输距离。根据测试结果，在该模式下 2.4GHz 频段信号强度提升约 3dB，5GHz 频段提升约 8dB。

第二项技术是真双频并发。系统能够实时监测两个频段的时延与干扰情况，并自动选择更稳定的频段进行数据传输，在需要时实现动态切换。测试数据显示，在弱网络环境下启用该技术后，网络时延可降低约 80%。

第三项技术是双频无缝漫游。终端设备可以同时连接两个频段，并在不同路由器之间移动时实现无缝切换，从而减少传统 Wi-Fi 漫游过程中出现的网络中断。

目前 Wi-Fi7+ 技术已经应用在多款华为旗舰终端，包括 Mate XTs 非凡大师、Pura80 系列以及 nova 15 Ultra 等机型。搭配 BE3 Pro 路由器或凌霄子母路由 Q7 使用时，可以激活完整技术能力。

智慧屏 MateTV 升级鸿蒙 6

智慧屏依然是华为家庭产品体系中的重要终端之一。在此次沟通会上，华为宣布智慧屏 MateTV 即将升级至鸿蒙 6 系统。升级后，系统整体流畅度相比升级前提升约 15%，在应用启动、界面切换以及 4K 视频播放等场景中表现更加顺畅。

应用生态方面，一些游戏开始登陆鸿蒙大屏平台。例如《太吾绘卷》将在鸿蒙系统上首发。用户可以搭配华为灵犀悬浮触控板，在电视上进行类似 PC 的游戏操作。

在交互方面，MateTV 还支持华为灵犀手写笔。用户可以在大屏上进行书写和批注，例如在家庭教育场景中批改作业，或在办公场景中进行文档标注与协同操作。

同时，智慧屏也可以作为家庭智能设备的控制中心，通过系统界面统一管理灯光、空调等设备。

Vision 智慧屏 6 主打设计与影音体验

在智慧屏产品线上，华为还发布了新一代 Vision 智慧屏 6。

外观方面，该产品采用 4.9 厘米纯平一体超薄设计，背板与墙面之间的间隙约为 0.5 厘米。搭配艺术画框后，电视在关闭状态下可以呈现类似装饰画的效果，更容易融入家居环境。

屏幕方面，Vision 智慧屏 6 搭载华为黑晶屏。屏幕外层采用双层纳米低反镀膜，反射率约为 0.5%，能够有效减少环境光干扰。内部使用第六代液晶面板，相比上一代透光率提升约 20%。

在 AI 功能方面，小艺助手新增「看球」功能，在体育赛事直播过程中可以识别球员并提供实时信息分析。此外，该产品支持 4K 超级投屏功能，用户可以将手机内容直接投射到大屏观看。搭配灵犀指向遥控器，可以通过类似手机操作的方式控制电视界面。

Vision 智慧屏 6 已于 3 月 11 日开启预售，同时 Vision 智慧屏 6 SE 也在沟通会上首次亮相。

智能门锁家族扩展

智能门锁是家庭智能系统中使用频率较高的一类设备。此次华为也公布了新的门锁产品阵容，包括 X 系列、2 系列以及 M 系列。

以华为智能门锁 2 系列为例，该产品搭载 3D ToF 深感摄像头，支持 AI 3D 人脸识别与掌静脉识别两种解锁方式。门锁还可以与鸿蒙生态中的其他设备联动。例如当门锁识别到家庭成员回家时，系统可以自动启动对应的家庭场景模式。

在续航方面，产品提供应急供电方案，通过应急小红键可以在电量耗尽时进行临时供电。

另一款产品华为智能门锁 X1 金玉满堂则在设计上融入东方建筑元素，从传统飞檐斗拱中汲取灵感，定价 19999 元，首发价 14999 元。此外，华为还预告了新品智能门锁 M2，未来将进一步扩展门锁产品线。

随行 WiFi X 面向移动网络场景

除了家庭设备，华为还发布了一款移动网络产品——随行 WiFi X。这款设备是全球首款支持四发四收天线设计的随行 WiFi 产品，四根天线可以同时进行信号收发，使设备峰值上行速率达到千兆级别。

设备采用 360° 信号收发设计，以提升网络覆盖范围与稳定性，适用于户外直播、移动办公等使用场景。在散热方面，设备采用双层石墨烯与高导热均热膜结构，以保证长时间运行时的稳定性。续航方面，随行 WiFi X 内置 12000mAh 电池，可支持约 20 小时直播或约 24 小时持续上网。产品外观采用可展开的 X 形结构设计，收纳时更加紧凑，展开后可以提升天线性能。

这场技术沟通会更像是一次系统能力的集中展示。华为没有把重点完全放在某一款产品上，而是试图说明一件事情：在智能家居逐渐成熟的阶段，真正决定体验的往往不是单个设备，而是整个系统。当家庭空间拥有类似操作系统的能力之后，智能家居的形态或许也会发生新的变化。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

36氪获悉，A股三大指数集体收涨，沪指涨0.25%，深成指涨0.78%，创业板指涨1.31%；能源、电力、汽车板块领涨，节能风电、赣能股份涨停，宝利国际涨超9%，宇通客车涨超3%；航天军工、半导体、文化传媒板块走弱，航宇科技跌超6%，寒武纪跌超4%，易点天下跌超3%。

作者 | 王晗玉

编辑 | 张帆

3月6日，中国证监会主席吴清在十四届全国人大四次会议经济主题记者会上表示，将在创业板增设一套更加精准、更为包容的上市标准，并明确提及积极支持新型消费、现代服务业等优质创新创业企业在创业板发行上市。

这一表态被市场解读为创业板向新型消费与现代服务业企业敞开大门的信号。

此前较长一段时间内，由于A股主板及创业板上市标准对“盈利性”和“硬科技”属性的严苛要求，大批如泡泡玛特、名创优品等新消费领域的头部公司不得不“退而求其次”选择赴港上市。如果此次改革落地，或有望改变一级市场的投资预期，并带动A股消费板块的估值重塑。

A股为何“不要”消费公司？

回顾近几年的A股IPO市场，其板块结构呈现出明显的“重制造、轻消费”特征。

根据同花顺的统计数据，2025年A股IPO公司主要集中于制造业，数量高达100家，占比86.21%；批发和零售业仅有3家，信息传输、软件和信息技术服务业仅2家。

这种结构在一定程度上反映了监管层的导向：消费类企业通常现金流充裕，融资需求不如科技企业迫切。同时，部分新消费模式在初期常因盈利模式不稳定而受到质疑，进一步降低了其在A股上市的优先级。

而观察创业板现行的三套上市标准，也均对企业的盈利或营收规模设置了较高门槛。第一套标准要求“最近两年净利润均为正且累计不低于1亿元”，第二套标准涉及“市值+收入+盈利”的组合要求，第三套标准虽放宽盈利要求，但仍需满足“市值不低于50亿元且营收不低于3亿元”的条件。

这对于处于快速扩张期、尚未实现稳定盈利的新消费企业而言，多数难以企及。尤其在2023年8月“827新政”后A股IPO节奏整体趋缓的背景下，有限的上市名额进一步压缩了消费类企业的上市空间。

而同一时间，港股成了一众消费类明星企业的IPO首选。2025年全年，港股共有119只新股挂牌上市，IPO募资总额达2856.93亿港元，其中可选消费成为IPO募资规模排名第五的行业，募资额为49.31亿港元。

Wind数据显示，截至今年2月9日，消费行业还有67家企业在港股门前排队等待上市。

A股为何重新拥抱“新消费”？

监管层此次明确提及“新型消费”与“现代服务业”，或意味着对消费行业态度的转变。

尽管A股过去对消费企业较为审慎，但港股市场却涌现出一批新消费牛股。

以泡泡玛特为例，尽管多家机构认为其估值被严重低估，但其股价在2025年依然表现亮眼，累计涨幅超过110%，年化收益率达到112.79%；古茗同样在港股市场获得较高认可，去年2月上市以来累计涨幅157.24%，年化收益率达192.61%。

这些企业在港股的表现，证明了新消费模式不仅具备可持续的盈利能力，也能为投资者创造丰厚回报。A股市场若有此类标的回流，或有望增加居民财富增值渠道，进而助力资本市场长期健康发展。

另一方面，此次创业板上市标准改革的最大受益者，或许是那些已在港股上市、盈利能力逐渐被验证、但价值被低估的新消费龙头企业。

仍以泡泡玛特为例，作为当下潮玩行业的头部企业，其估值在2025年以前被长期压制，去年亦经历了从狂热到理性的估值回归过程，目前尚在向下波动，动态市盈率跌回40倍以下。

泡泡玛特H股近三年PE（TTM）变化 图源：Wind

不过根据浦银国际的研报，其认为2026年年初至今，泡泡玛特在国内的收入展现出较强增长动力，并预计泡泡玛特1-2月国内市场收入同比将增长130%-160%，并且今年二至四季度的收入绝对值也都将维持一季度的规模，因此该机构认为泡泡玛特当前估值被严重低估。

若未来A股创业板增设第四套标准，允许符合条件的企业二次上市或分拆上市，泡泡玛特也能不再受限于单一资本市场，而在全球化布局的阶段内获得更丰富的资本运作选择。

回到消费市场一线，随着Z世代成为消费主力，消费范式正在发生深刻变化。悦己消费、品质消费、精神消费等新消费形态，不仅带动了经济增长，也催生了新的产业链。支持这类企业上市，有助于完善A股市场的行业结构，同时也为居民提供了分享新消费红利的投资渠道。

退出通道拓宽，改变一级市场预期

转向投资者的视角，如果此次改革落地，或也将对一级市场的投资逻辑和二级市场的估值体系产生深远影响。这些影响不仅体现在资本流向的变化上，更将重构A股消费板块的价值评估框架。

过去在一级市场上，投资机构对于新型消费项目往往持谨慎态度，因为这类项目即便做到行业龙头，也可能因盈利不稳定或模式太新而无法在A股上市。

创业板增设包容性标准，相当于给一级市场提供了明确的预期指引。这将促使投资机构更敢于投早、投小，支持那些暂时不盈利但具备高成长性的消费创新企业。从长远看，此举将激发社会资本投资新消费领域的热情，形成产业创新与资本增值的良性循环。

此外，A股消费板块的估值也高于港股。

从历史数据来看，A股消费类公司通常享有比港股同类型企业更高的估值溢价。目前A股消费类个股市盈率普遍超过30倍，港股消费股则约在18倍以下。

如A股市场上的青岛啤酒市盈率约18倍，港股市场上的华润啤酒约13倍；A股市场上的贝因美市盈率约46倍，港股市场上的中国飞鹤则不到12倍。

而部分A股白酒龙头，如洋河股份当前市盈率约37倍，水井坊约32倍，舍得酒业则高达111倍。

基于港股市场中零售、餐饮、服饰等可选消费权重更高的结构因素，其估值水平往往受消费复苏影响弹性更大。而A股以必需消费为主，估值更抗跌。

两地市场的估值差异意味着，一旦新消费企业获得回归A股的通道，其市值管理空间将被打开，这对于提升股东回报和吸引长期资金具有积极意义。

而对于A股消费板块而言，长期以来，A股消费板块以白酒、家电等传统白马股为主，估值体系相对固化。新型消费企业的涌入，将改变这一格局。

未来随着更多在港上市的新消费龙头企业可能回归A股市场，A股消费板块的估值结构也将面临调整。那些真正具备核心竞争力和成长潜力的企业将获得合理估值，而单纯依靠概念炒作的个股估值泡沫可能被挤压，整个消费板块的估值体系将趋向更健康合理。

*免责声明：

本文内容仅代表作者看法。

市场有风险，投资需谨慎。在任何情况下，本文中的信息或所表述的意见均不构成对任何人的投资建议。在决定投资前，如有需要，投资者务必向专业人士咨询并谨慎决策。我们无意为交易各方提供承销服务或任何需持有特定资质或牌照方可从事的服务。

关注获取更多资讯

和硕3月11日公布2025年业绩显示，营收净额1.12万亿元新台币，同比减少7.1%；净利润144.0亿元新台币，同比减少14.7%；每股收益5.39元新台币，上年同期6.34元新台币。（界面）

导读 introduction

Agent 能写代码、能调工具，但它不了解你团队的规范、流程和质量标准，每次对话都从零教起，既低效又不稳定。Skill 机制正是为解决这个问题而生：把你的经验和流程结构化地交给 Agent，让它像拿到工作手册一样自主执行。本文从设计原理、编写方法到评测迭代，梳理 Skill 的实践路径，帮助开发者打造高效易用的Agent Skill。

01 Skill 是什么，为什么需要它

1.1 Agent 的先天缺陷

大模型很聪明，但它有一个根本问题：没有你的私域知识和专属能力。

你团队的代码规范是什么？做 Code Review 要看哪几个维度？创建一份 PPTX 应该遵循什么品牌样式？这些东西不在训练数据里，每次对话都重新教一遍既低效又不稳定。

更现实的问题是，即使你通过 MCP 给了 Agent 工具调用能力，能读 GitHub、能查 Sentry、能操作 Linear，它依然不知道该按什么流程、什么顺序、什么标准去使用这些工具。而 Skill 就可以提供这些信息，帮助Agent更好地执行任务。

1.2 从 MCP 到 Skill：能力扩展的演进

Agent 能力扩展的路径，经历了几个关键节点：

MCP（Model Context Protocol） 解决了"连接"问题。2024 年 11 月 Anthropic 开源 MCP，让 Agent 能够标准化地调用外部工具和数据源。这是基础设施层面的突破，Agent 终于能"伸手"触达外部世界了。

AGENTS.md 是社区自发的探索。随着 Cursor、Claude Code 等 AI 编码助手的普及，开发者很快意识到一个问题：这些 Agent 能写代码，但不了解项目的技术栈选择、代码风格约定、架构决策背景。于是社区开始在仓库根目录放置 AGENTS.md，用自然语言把项目的上下文和规范写给 Agent 看。

Skill 则是 Anthropic 在 2025 年 10 月正式推出的标准化方案。它把 AGENTS.md 的理念系统化，不仅仅是一个 Markdown 文件，而是一个结构化的文件夹，包含指令、脚本、参考文档和资源文件，形成完整的知识包。随后，Cursor、Windsurf 等产品也纷纷推出类似机制，Skill 正在成为 Agent 能力扩展的主流范式。

1.3 Skill 的核心设计：渐进式披露

Skill 最精妙的设计在于它的三级渐进式披露（Progressive Disclosure）机制，不会一次性把内容全塞给模型，而是分层按需加载：

第一级：YAML frontmatter 中的 description 字段。 本质上是一段结构化的自然语言声明，包含三层信息：这个 Skill 干什么用（“分析 Figma 设计稿并生成开发交付文档”）、核心能力是什么（“设计规范提取、组件文档生成、标注导出”）、什么时候触发（“当用户上传 .fig 文件或要求’设计转代码交付’时”）。它始终存在于 Agent 的系统提示词中，作用类似索引，当用户输入到来时，Agent 拿请求和所有 Skill 的 description 做匹配，命中了才加载对应 Skill 的完整内容。这个设计意味着你可以同时挂载几十个 Skill，而激活判断的成本只是几十行短文本的比对，不需要把所有 Skill 的完整指令都塞进上下文。

第二级： SKILL.md 正文。 当 Agent 判断某个 Skill 与当前任务相关时，才会读取 SKILL.md 的完整内容。这里包含核心指令、工作流程和关键示例。

第三级： references/ 和 scripts/ 。 references/ 目录下的详细文档、scripts/ 下的可执行脚本，这些只在 Agent 执行过程中确实需要时才会去查阅或调用。

为什么要这么设计？它解决了两个实际问题：

1. Token 效率：不把所有知识一股脑塞进上下文，避免信息过载。
2. 注意力聚焦：模型的注意力机制在上下文越长时衰减越明显，渐进式披露让模型在每个阶段只关注最相关的信息。

1.4 怎么组织和安装 Skill

当 Skill 越写越多，散落在各处很快就会失控。推荐一开始就用Git仓库统一管理。

team-skills/
├── code-review/
│   └── SKILL.md
├── react-state-management/
│   ├── SKILL.md
│   └── references/
├── sprint-planning/
│   ├── SKILL.md
│   └── scripts/
└── ...

好处很直接：版本有记录，团队能协作，跨仓库安装迅速。

安装到具体的 Agent 平台时，各家的路径约定不同，但社区已经有了统一的解决方案，Vercel 开源的 skills CLI 工具，一条命令兼容多平台：

# 从 GitHub 安装，自动识别当前环境并放到正确的位置
npx skills add https://github.com/your-team/skills/tree/main/code-review
# 支持 Claude Code、Cursor、Windsurf 等主流 Agent 平台
# 无需关心各平台的路径差异

当然，你也可以手动放置安装。因平台和场景而异路径约定不同，以Claude Code为例：

Claude Code：

# 项目级（只在当前项目生效）
.claude/skills/code-review/SKILL.md
# 全局级（所有项目生效）
~/.claude/skills/code-review/SKILL.md

社区实践一瞥

Skill 的生态正在快速成长。Anthropic 官方提供了一批高质量 Skill， 在anthropics/skills 仓库，尤其是 pdf、skill-creator、frontend-design 这几个，它们很好地展示了渐进式披露和脚本自动化的最佳实践。这些 Skill 本身就是很好的学习范本。

社区层面，Asana、Atlassian、Figma、Sentry、Zapier 等厂商已经为自己的 MCP Server 配套了 Skill。独立开发者也在持续贡献，从前端设计到代码审查，从数据分析到项目管理，可用的 Skill 库正在不断扩大。

02 如何编写一个 Skill

2.1 基本格式

一个 Skill 在文件系统中是一个文件夹，最小结构只需要一个文件：

your-skill-name/
├── SKILL.md          # 必须，入口文件
├── scripts/          # 可选，可执行脚本
├── references/       # 可选，参考文档
└── assets/           # 可选，模板、图标等资源

命名规则简单但严格：

• 文件夹名用 kebab-case：my-cool-skill 是正确的，而My Cool Skill 以及my_cool_skill 等都是无效的。
• 入口文件必须精确命名为 SKILL.md，大小写敏感，skill.md 或 SKILL.MD 都不行
• 不要在Skill文件夹内放README.md（所有文档放在SKILL.md或 references/ 中）

SKILL.md 的结构分两部分：YAML Frontmatter 和 Markdown 正文。

---
name: my-skill-name
description: 做什么。在用户说"XXX"时使用。核心能力包括 A、B、C。
---
# My Skill Name
## Instructions
具体的指令内容...

Frontmatter 用 --- 包裹，其中 name 和 description 是必填字段。正文用标准 Markdown 编写，包含 Agent 执行任务时需要遵循的具体指令。

2.2 工作原理

理解 Skill 的工作原理，有助于写出更有效的 Skill。核心流程是这样的：

阶段一：常驻索引。 你安装的所有 Skill 的 description 字段会被注入到 Agent 的系统提示词中。Agent 在每次对话开始时就"知道"自己拥有哪些 Skill，但不知道具体内容。

阶段二：激活读取。 当用户的请求与某个 Skill 的 description 匹配时，Agent 会使用内置工具（如 view 或 read 命令）读取该 Skill 的 SKILL.md 完整内容。这一步对应 messages[] 中的一个工具调用。

阶段三：执行与深入。 Agent 根据 SKILL.md 中的指令开始执行任务。如果指令中引用了 references/ 下的文档或 scripts/ 下的脚本，Agent 会在需要时再去读取或执行它们。

用 API 的 messages[] 视角来看，一个典型的 Skill 调用大约是这样的

用户消息 → Agent 识别需要 Skill → [工具调用: 读取 SKILL.md] 
→ Agent 获得指令 → [工具调用: 执行任务步骤] → 返回结果

这意味着 Skill 的激活本身会消耗 1-2 步工具调用。所以 description 写得准不准，直接影响 Token 消耗和响应速度，误触发意味着浪费，漏触发意味着能力缺失。

03 编写优质的 Skill

一个 Skill 能不能用和好不好用，差距巨大。这个差距主要体现在两个地方：Description 决定"什么时候用"，Body 决定"用起来效果如何"。

3.1 Description：激活的精准度

Description 是整个 Skill 体系中最关键的一行文字。它决定了 Agent 在什么场景下会加载你的 Skill，写得不好，要么该用的时候不触发（under-triggering），要么不该用的时候乱触发（over-triggering）。

三大要素： 一个好的 Description 需要同时回答三个问题

1. 能做什么：这个 Skill 的核心价值是什么
2. 核心能力：具体包含哪些能力
3. 激活条件：用户说什么话、做什么操作时应该触发

正面案例：

# 清晰、具体、包含触发短语
description: >
  分析 Figma 设计稿并生成开发交付文档。当用户上传 .fig 文件、
  要求"设计规范"、"组件文档"或"设计转代码交付"时使用。

# 明确的服务边界和触发词
description: >
  管理 Linear 项目工作流，包括迭代规划、任务创建和状态跟踪。
  当用户提到"迭代"、"Linear 任务"、"项目规划"或要求
  "创建工单"时使用。

反面案例：

# 太模糊，几乎什么都能匹配
description: Helps with projects.
# 缺少触发条件，Agent 不知道什么时候该用
description: Creates sophisticated multi-page documentation systems.
# 过于技术化，没有用户视角的触发词
description: Implements the Project entity model with hierarchical relationships.

防止过度触发的技巧： 如果你的 Skill 经常在不相关的场景被加载，可以在 Description 中加入"负向触发"说明：

description: >
  CSV 文件的高级数据分析，包括统计建模、回归分析、聚类。
  不要用于简单的数据浏览（那个用 data-viz skill）。

3.2 Body：执行的效果

Description 写好了只是让 Skill 在对的时间出现，Body 的质量才决定最终效果。根据使用场景，Body 通常呈现两种形态：

形态一：知识文档型

适用于需要 Agent 掌握特定领域知识或遵循特定标准的场景。

核心要素：

• 领域知识：把你的专业判断和决策逻辑写成 Agent 可以理解的规则
• 质量检查清单：明确定义"什么算做好了"，让 Agent 在交付前自查
• Few-Shot 示例：给出 2-3 个输入输出的范例，比抽象描述有效得多

## Code Review Standards
### Critical Checks (must pass)
1. No hardcoded credentials or API keys
2. All user inputs sanitized
3. Error boundaries on async operations
### Quality Checks (should pass)
1. Functions under 50 lines
2. Meaningful variable names (no single letters except loop counters)
3. Comments explain "why", not "what"
### Example Review
**Input:** A React component with inline styles and no error handling
**Expected output:**
- Flag: inline styles → suggest CSS modules or Tailwind
- Flag: missing error boundary → provide template
- Pass: component size reasonable
- Suggestion: extract magic numbers to constants

形态二：工作流型

适用于多步骤、有固定流程的任务。

核心要素：

• 步骤清晰：每一步做什么、调用什么工具、预期输出是什么
• 步骤间校验：上一步的输出满足条件才进入下一步，而不是盲目往下走
• 可循环迭代：对质量不达标的输出能回到前面的步骤重做

## Sprint Planning Workflow

Step 1: Gather Context

`Fetch current project status from Linear. Validation: Confirm at least 1 active project returned.

Step 2: Analyze Velocity

Calculate team velocity from last 3 sprints. Validation: Velocity data covers at least 2 complete sprints.

Step 3: Draft Plan

Create task breakdown with estimates. Validation: Total story points ≤ average velocity × 0.85 (buffer).

Step 4: Review & Adjust

Present plan to user. If user requests changes: → Return to Step 3 with modified constraints.

Step 5: Execute`

Create tasks in Linear with labels and assignments. Validation: All tasks created successfully, no API errors.

3.3 进阶技巧：分层与自动化

多层渐进： SKILL.md 只放核心指令和工作流主干。详细的 API 文档、完整的示例库、边缘场景的处理方案，都放到 references/ 目录下，在正文中用明确的路径引用：

Before writing API queries, consult references/api-patterns.md for:
- Rate limiting guidance
- Pagination patterns  
- Error codes and handling

这样既保证 Agent 知道有这些资源可用，又不会在每次激活时都加载全部内容。

脚本自动化： 凡是可以用代码确定性完成的事情，就不要让模型用自然语言"理解"着去做。模型理解自然语言有概率性，但代码执行是确定性的。

官方的 PDF、DOCX、PPTX 等 Skill 大量使用了这个模式，核心的文档生成逻辑封装在 Python 脚本中，SKILL.md 只负责告诉 Agent 什么时候调用哪个脚本、传什么参数。

04 基于评测迭代

写完 Skill 不是终点。Skill 本质上是给概率性系统写的指令，“我觉得写得挺好"和"它确实在各种场景下都表现稳定"之间，往往隔着好几轮迭代的距离。评测不是锦上添花，而是 Skill 开发流程中不可省略的一环。

4.1 核心理念：像对待 Prompt 一样对待 Skill

Skill 的 Description 是系统提示词的一部分，Body 是任务执行时的指令集。这使得 Skill 开发和 Prompt 开发面临相似的挑战，而 Prompt 开发有一个被反复验证的基本事实：你无法靠直觉判断一段指令的好坏，只能靠在真实场景中反复测试来验证。

这引出三个关键原则：

原则一：分层评测。 Description 和 Body 解决的是完全不同的问题，前者决定"什么时候用”，后者决定"用起来效果如何"。它们的评测方法、评测标准和迭代策略完全不同，必须分开处理。

原则二：对照实验。 “好不好"是相对概念。一个 Skill 的输出质量，只有和某个基线对比才有意义。这个基线可以是没有 Skill 时的裸跑效果，也可以是上一个版本的 Skill。没有对照组，改进就无从衡量。

原则三：人类参与。 自动化评分能覆盖格式、结构、字段完整性这类客观检查，但 Skill 真正的价值，比如审美判断、业务适配度、专业深度，只有人能评估。评测流程的设计必须让人的判断能高效地注入迭代循环。

4.2 评测 Description：触发的精准度

Description 评测要回答一个简单的问题：Agent 在该用这个 Skill 的时候用了吗？在不该用的时候没用吧？

理解触发机制

在动手测之前，先理解两个关于触发的事实：

事实一：Agent 只在觉得自己搞不定时才找 Skill。 简单的一步操作（比如"读一下这个文件”），即使 Description 完美匹配也可能不触发，因为 Agent 判断自己直接就能完成。这意味着你的测试用例必须足够复杂，不然你测的不是 Description 好不好，而是任务够不够难。

事实二：Agent 天生偏向欠触发（under-triggering）。 Description 要写得主动一点，把边界往外推。比如不只写"分析 Figma 设计稿并生成交付文档"，而是追加"当用户提到设计规范、UI 组件文档、设计转代码交付，甚至只是上传了 .fig 文件但没明说要干嘛时，都应该使用"。

还有一个常见错误：把"什么时候该用这个 Skill"的信息写在 Body 里。Body 是触发之后才加载的，写了也没有任何帮助。所有触发相关的信息，必须且只能写在 Description 中。

构建评测集

准备 16-20 条测试 query，分两组：

• 应触发组（8-10 条） ：覆盖不同的表述方式，正式的、口语的、没有明确提到 Skill 名称但显然需要它的
• 不应触发组（8-10 条） ：重点选近似场景，而非明显无关的请求

[
  {
    “query”: “我们团队要移除 less-loader，把 .less 文件全部转成 PostCSS 方案。项目比较大有 200 多个 LESS 文件，有复杂的 mixin 嵌套，用哪种方式风险更低？”,
    “should_trigger”: true
  },
  {
    “query”: “项目已经在用 PostCSS 了，现在想加 postcss-px-to-viewport 做移动端适配，postcss.config.js 不知道怎么写。”,
    “should_trigger”: false
  }
]

构建评测集时最容易踩的坑：

• 测试 query 太干净。 “请帮我做代码审查"这种教科书式的指令在真实场景中几乎不存在。真人会带上文件路径、个人上下文、前因后果，甚至拼写错误和口语缩写。你的测试 query 越像真人说的话，评测结果越有参考价值。
• 反例太容易。 “写一个斐波那契函数"作为 CSS 迁移 Skill 的反例毫无价值。最有意义的反例是那些共享了关键词但实际需要别的工具，或者触及了 Skill 的领域但处于一个不该触发的上下文中的 query。这些边界 case 才能真正检验 Description 的区分度。

△ code-review skill的触发测试	△ less-to-postcss skill的触发测试

执行评测

逐条把测试 query 发给 Agent，观察它是否加载了对应的 Skill。记录结果，计算两个指标：

• 召回率：应触发组中实际触发的比例（衡量"该用的时候用了没”）
• 精确率：不应触发组中正确未触发的比例（衡量"不该用的时候克制住了没”）

💡 一个快速调试技巧：直接问 Agent “你什么时候会使用 [skill-name] 这个 Skill？”，它会把 Description 复述回来，你可以据此判断它的理解是否与你的意图一致。

迭代改进

根据失败 case 分析原因，调整 Description：

• 漏触发居多：补充更多触发关键词和场景描述，把边界推得更宽
• 误触发居多：增加负向说明（“不要用于…”），收窄适用范围
• 两者都有：Description 可能定位模糊，需要重新理清这个 Skill 的核心边界

每次修改后，用完整评测集重跑，对比前后得分。注意不要只盯着失败的 case 做针对性修补。Description 最终要面对的是无穷多种真实 query，过拟合到几条测试用例没有意义。

4.3 评测 Body：输出质量

Body 的评测比 Description 复杂得多，因为"好不好"不是布尔值，而是一个多维度的质量判断。核心方法是有 Skill 和无 Skill 的对照实验。

Step 1：设计测试用例

准备 2-5 个代表性的测试任务。好的测试用例有几个特征：

• 覆盖 Skill 的核心能力，不要只测边缘功能
• 有明确的可判断的输出，而不是开放性的问答
• 复杂度接近真实使用场景，太简单的任务区分不出有无 Skill 的差异

每个测试用例准备好输入材料（需要审查的代码、需要分析的数据、需要处理的文档等）。

Step 2：对照实验

对每个测试用例，分别跑两次：

• 实验组：正常加载 Skill，执行任务
• 对照组：不加载 Skill（或加载旧版本 Skill），执行相同任务

关键要求：用相同的 Agent、相同的输入、相同的系统环境。唯一的变量是 Skill 的有无或版本差异。

把输出保存在结构化的目录中，方便后续对比：

eval-workspace/
├── iteration-1/
│   ├── test-case-auth-module/
│   │   ├── with-skill/
│   │   └── baseline/
│   ├── test-case-api-refactor/
│   │   ├── with-skill/
│   │   └── baseline/
│   └── …

Step 3：定义评判标准

在看结果之前（避免结果影响标准），先想清楚"什么算好"。评判标准分两类：

可程序化验证的客观标准，用脚本直接检测：

• 输出文件格式是否合法（JSON schema 校验、文件是否可打开）
• 必要字段是否存在
• 是否满足特定的结构要求

需要人判断的主观标准，形成检查清单：

• “每个问题是否附带了具体的修改建议，而非仅描述问题”
• “是否有将正确代码误标为问题的情况”
• “输出的优先级排序是否合理”

对于写作风格、设计审美这类高度主观的 Skill，不需要勉强定义细粒度标准，直接看输出、做整体判断，反而更有效。

Step 4：评分和对比

逐个翻看每个测试用例的两组输出，记录：

1. 客观检查项的通过情况：跑脚本，统计通过率
2. 主观判断和具体反馈：哪里好、哪里差、哪里出乎意料。反馈要写具体。"输出不够好"没有行动指引，“安全维度的审查遗漏了 SQL 注入风险，建议在 Skill 中增加 OWASP Top 10 检查清单"才能指导改进
3. 效率数据：如果可获取，记录 token 消耗和响应时间，避免质量提升以不可接受的效率代价为前提

最终形成一个清晰的判断：Skill 版本在哪些维度上比基线好、在哪些维度上持平、在哪些维度上退步了。

Step 5：分析和改进

基于评分结果和具体反馈，修改 Skill。这一步是整个迭代中最需要判断力的环节，几个关键原则：

从反馈中提炼通用规律，别过拟合到具体用例。 Skill 最终要在无数不同的真实任务上运行，你现在只是用几个测试用例来快速迭代。如果某个改动解决了测试用例 B 的问题但让测试用例 A 退步了，大概率你在做过于针对性的调整。好的改动应该是普适的。

保持指令精简。 如果能获取到 Agent 的执行过程（而不只是最终输出），仔细看看它在做什么。如果 Agent 花了大量步骤在做无用功，找到 Skill 中导致这些无用功的指令，砍掉试试。冗余的指令不只是浪费 token，还会分散模型的注意力，降低真正重要的指令的执行质量。

解释 why 而不是堆 MUST。 如果你发现自己在写 ALWAYS 或 NEVER 这种全大写的硬约束，先停下来想想，能不能换成解释"为什么这件事重要”。模型理解了原因之后，执行的灵活性和准确度通常都比死记硬背的规则好。硬约束应该留给那些真正不可违反的底线，而不是泛滥在每一条指令里。

关注重复劳动。 如果你在多个测试用例的输出中发现 Agent 都独立编写了类似的辅助脚本或做了类似的预处理工作，这说明这个步骤应该被提炼到 Skill 的 scripts/ 目录下直接复用，而不是每次让 Agent 从头造轮子。

常见问题和改进方向参考：

△ body的评测结果 - 有无skill对比	△ body的评测结果 - 经过迭代对检出问题细节优化

4.4 循环迭代

把上面的步骤连成闭环，每一轮迭代的流程是：

1. 跑对照实验：在新的目录下同时跑所有测试用例的实验组和对照组
2. 评分：客观指标跑脚本，主观维度人工判断
3. 分析反馈：哪里好了、哪里退步了、哪里还不够
4. 改 Skill：基于反馈修改 SKILL.md 或脚本，遵循上述改进原则
5. 重跑：用完整评测集验证改动效果

对照组的选择取决于你要回答的问题。如果是新建 Skill，对照组就是没有 Skill 的裸跑，你要证明 Skill 的存在有价值。如果是改进已有 Skill，对照组可以是旧版本，你要证明改动带来了正向提升。

终止条件：反馈趋于空白（没什么要改了）、你已经没有更多手段继续改进、或者你对输出质量满意了。不需要追求完美，Skill 和代码一样，可以持续迭代，在实际使用中收集到新的失败 case 时随时回来改进。

4.5 案例：Skill 迭代的实际路径

案例一：Skill-Creator 的三次进化

Anthropic 官方的 Skill-Creator 本身就经历了迭代式演进：

• 第一版（创建） ：帮用户从自然语言描述生成 SKILL.md，输出格式正确的 Frontmatter 和基本指令结构。核心价值是降低上手门槛。
• 第二版（创建 + 优化） ：增加了分析与改进的能力，将自身能力边界进行了拓展，可以承接几乎所有与Skill相关的工作，因此其description也变得更为激进。用户指出Skill执行时的问题和现象后，可以自主改进Skill内容并给出建议。
• 第三版（自动评测优化） ：基于完整的评测改进循环理论进行构建，不仅仅为生成、改进内容工作负责，也为Skill的最终运行效果负责。这一版可以基于需求生成评测用例、创建评分机制、运行评测、评价汇总、循环改进，完成Skill编写的同时给出效果结论。

案例二：Code-Review Skill 的质量提升

一个更贴近业务的例子，代码审查 Skill 的迭代过程：

• 第一版（简单 Prompt） ：一段直白的 Markdown 指令，列出审查维度和注意事项，以及项目隐式需要注意的的点。效果还行，但输出质量波动大，有时遗漏重要问题，有时对细枝末节过度关注，如果git diff的文件信息过多上下文会超出导致失败。
• 第二版（多 Agent 组合架构） ：引入 SubAgent 模式，每个 Subtask Agent 只持有一个文件的diff + 源码，不会被其他文件干扰。单 Agent 串行审查时，随文件数增加上下文污染越来越严重；并发子Agent 则始终保持干净的注意力窗口。把一次 Code Review 拆解为多个阶段，总览分析（掌握全局）、分维度审查（安全、性能、可维护性分别深入）、使用子agent交叉验证（排除误报）、去重合并（消除冗余）、最终报告（按优先级排序输出）。每个阶段有明确的输入输出契约和质量检查点。依赖文件系统，有明确的“任务是否全部完成”的可检查标准，即使因为网络超时中断，也可以恢复继续处理任务，单个子任务失败不影响其他任务的完成，失败的任务重新跑而无需跑整个PR。

两个版本在相同的 20 个 PR 上跑评测，用 Grader Agent 评估输出质量、覆盖率和误报率，第二版在三项指标上均有明显提升。

△ 旧架构的检出效果	△ 新架构的实现效果，更关注逻辑实现和减少误判

05 总结

Skill 正在统一 Agent 能力扩展的途径。 从 MCP 提供工具连接，到 AGENTS.md 的社区探索，再到 Skill 的标准化方案，Agent "学习新技能"的方式正在收敛。渐进式披露的设计不仅节省 Token，更重要的是提升了模型的注意力分配效率。以自然语言为载体的知识表达，比硬编码的逻辑更灵活，也更 Agentic。

广泛的社区 Skill 可以直接提升生成效果。 Anthropic 官方的文档生成 Skill（PDF、DOCX、PPTX）、前端设计 Skill，以及社区贡献的各类工作流 Skill，都可以拿来即用。在你动手定制之前，先看看现有 Skill 能否满足需求。

定制化 Skill 是让 Agent 在你的场景中真正好用的关键投入。 通用的 Agent 能力就像一个聪明但不了解你业务的新人，Skill 就是你给他的工作手册。Description 的精准度决定了它出现在正确的场景，Body 的质量决定了它在场景中的表现。这两者都有明确的设计原则和可遵循的技巧。

评测是 Agentic 工程必不可少的环节。 不只是工具开发、系统开发需要评测，Skill 开发同样需要。拍脑袋觉得"差不多了"和用数据验证"确实好了"之间，往往隔着好几轮迭代的距离。基于评测的循环优化，评测、分析、改进、重新评测，是通往高质量 Skill 的可靠路径。

回过头看，Skill 做的事情并不复杂：把你本来每次都要重新交代的经验、流程和标准，整理一次存下来，之后 Agent 自己就知道该怎么做了。省掉重复劳动，换来稳定可预期的输出。

这一次，我终于用 10 天时间真正走进白山黑水之间，补上一场迟到了很多年的东北初见。查看全文

36氪获悉，爱企查App显示，近日，上海华曜芯半导体有限公司成立，法定代表人为周利民，注册资本为10亿元人民币，经营范围包括集成电路制造、集成电路芯片及产品制造、集成电路销售、集成电路设计、集成电路芯片设计及服务等。股权穿透图显示，该公司由上海华虹（集团）有限公司及旗下上海华励博企业管理合伙企业（有限合伙）共同持股。

36氪获悉，根据TrendForce集邦咨询最新高速互连市场研究，NVIDIA（英伟达）下一代的AI算力柜架构显示，未来GPU设计重心将转向更高密度的芯片互连，以及更高速的数据传输，机柜内芯片互连（Scale-Up）及跨机柜的大规模互连（Scale-Out）将成为规划数据中心的核心课题。使用铜缆的传统电气传输方案，受物理限制无法应对超大规模的数据搬运需求，光学传输方案因此获得发展空间。TrendForce集邦咨询预估，CPO（共同封装光学）在AI数据中心光通信模块的渗透率将逐年成长，有机会于2030年达35%。

36氪获悉，据腾讯云，腾讯云智能体开发平台宣布自2026年3月13日起调整部分模型的计费策略，涉及GLM 5、MiniMax 2.5、Kimi 2.5等模型将结束免费公测，并开始按量计费。此外，混元系列模型Tencent HY2.0 Instruct与Tencent HY2.0 Think的价格也将有所调整。其中，HY2.0 Instruct输入价格从每千tokens 0.0008元调整为0.004505元，输出价格从0.002元调整为0.01113元。HY2.0 Think输入价格从0.001元调整为0.0053元，输出价格从0.004元调整为0.0212元。套餐用户可通过套餐抵扣部分费用。

36氪获悉，中汽协数据显示，2月，新能源汽车产销分别完成69.4万辆和76.5万辆，同比分别下降21.8%和14.2%，新能源汽车新车销量达到汽车新车总销量的42.4%。

一台3D打印机前，孩子们目不转睛地盯着喷头来回游走。塑料丝线层层堆叠，不过二十分钟，一只小恐龙便从想象中里，变成了可以握在手心的真实玩具。

三十年前，你想要一件东西，只能去商店买。二十年前，你可以找人定制。而今天，你可以直接打印出来。这种转变的意义，远比看上去更深远。当平价 3D 打印机走进客厅，当 AI 能把随手涂鸦秒变立体模型，横亘在创意与现实之间的高墙，第一次被轻松穿透。

人人都是设计师——这句话已经成为了现实。在深圳的创客空间，在硅谷的车库，上海的社区创新工坊，一场静默的革命正在发生：制造的权力，正从工厂流水线，向个人桌面转移 。

 

分享不是失去，是增值

但一个人的创造力，终究有边界。能设计的内容有限，能想到的思路有限，能踩过的坑也有限。而真正的突破，永远发生在图纸被分享的那一刻。

开源硬件的故事，本质上是一个关于信任的实验：把你的设计图、电路板文件、代码全部公开，允许任何人查看、修改、优化。看上去，像是放弃了知识产权；实际上，是在换取更珍贵的东西 ——全球开发者的集体智慧。

全球的开发者会帮你排查漏洞，适配新的芯片，翻译成不同语言，并应用到你想不到的场景。一个人跑得再快，也终究快不过一群人共建的生态。

 

上海的选择题：封闭还是开源？

为什么是上海？2025年底，《上海市加强开源体系建设实施方案》正式印发。文件中定下清晰目标：到2027年，培育100家开源商业化企业，集聚开源开发者超300万人，打造1—2个具有国际影响力的开源社区 。

数字背后，是上海对产业趋势清晰的判断：开源不再是简单的“代码共享”，而是技术创新的核心引擎。在这个判断里，也藏着上海对一道选择题的答案。面对新一轮科技竞争，是延续传统的封闭研发模式，还是押注开源的协作新范式？上海的答案坚定且明确——不仅要使用开源技术，更要主动建设开源生态、持续贡献开源价值 。

 

从个人玩具，到整个产业的重塑

消费端，3D 打印让每个人都能成为设计师；产业端，开源生态让每家企业都能调用全球智慧。

黑湖科技就是一个很典型的例子。这家公司让制造企业的数据流动起来，打破订单、物料、设备之间的信息孤岛。这不是传统意义上的开源，但逻辑相通：当生产链路变得透明，当各环节可以自由协同、高效对话，制造效率便会发生质变。

 

硬件的GitHub时刻

在软件开发领域，GitHub是全球开发者在这共享代码、协作项目，这里是开源运动的心脏，也是无数创新的诞生地。

而今，硬件领域正在迎来它的GitHub时刻。这不是某一家公司、某一个平台的单打独斗，而是一种全新的范式：设计图纸可以共享，电路可以迭代，改进可以回流。当上海的方案明确提出“建立开源项目‘双首发’机制”——鼓励“开源平台首发”或“全球同步首发” ——这便是一座城市的正式宣告：上海愿意成为硬件开源的“代码托管中心”。

 

每一张桌子，都是一座工厂

回到AWE2026的展台。孩子们还在排队等着看 3D 打印。机器轻嗡作响，最后一层即将完成。几分钟后，那个孩子会举起这枚亲手“造”出的玩具，跑向父母。他不会去想什么开源生态、什么产业变革，他只知道：我想的东西，真的可以变成真的。

但正是这个“知道”，定义了一切创新的开端。上海正在做的，是通过政策降低门槛，通过资金激励创造，通过生态吸引开发者。当三百万人在这座城市写代码、画图纸、建模型，当一百家企业在这里把开源项目变成可持续的商业，这座城市就不再只是一个地理概念，而是一个开源创新的核心节点。

上海将选择写在文件里，写在临港的实验室里，写在无数开发者的代码里——开放、共享、协同。因为最终，能够点亮一个时代的，从来不是某一家���司的独家秘方，而是所有人都能参与的那束创新之光。

 

AWE2026东方枢纽国际商务合作区展区为消费电子前沿科技专业展区，聚焦AI芯片、算力、6G、具身智能、新能源等硬核科技领域，主要服务行业人士、采购商、媒体等专业观众，采用提前预约、审核入场制度，无现场注册通道。专业观众需提前24小时完成线上注册与资质审核，凭审核通过凭证及有效证件入场。

扫描二维码即可报名观展

 

 

36氪获悉，中汽协数据显示，2月，汽车产销分别完成167.2万辆和180.5万辆，环比分别下降31.7%和23.1%，同比分别下降20.5%和15.2%。

3月11日，全球智能空间科技品牌NAVEE携20余款新品、20多项首创技术，登陆AWE2026（2026年中国家电及消费电子博览会）。这是NAVEE自2021年成立以来，首次集中呈现其“三维立体出行—户外移动空间—生活智能家电—智能空间系统”的全场景智能空间生态，标志着品牌从智能出行向智能空间系统的战略跃迁。

3月12日-15日，追觅科技将携上百项全球首发的全新品类与首创技术亮相AWE 2026（2026年中国家电及消费电子博览会），覆盖日常出行、居家生活，到户外体验、地面出行乃至天空宇宙等多个领域。本次追觅横跨5大展馆，占地11193㎡，成为AWE有史以来参展面积最大的智能科技生态品牌。

36氪获悉，沪深两市成交额连续第12个交易日突破2万亿元，较上一日此时放量超1100亿元。

据英国金融时报援引知情人士消息，摩根大通已通知多家私人信贷机构，对其投资组合中的部分贷款进行估值下调。这些贷款是相关基金向该行融资时使用的抵押品。此举将限制摩根大通今后以这些贷款为抵押，向私人信贷机构发放的贷款规模。此次被下调估值的贷款主要投向软件企业。摩根大通已收紧对私人信贷机构的放贷。摩根大通拒绝就此置评。（新浪财经）

36氪获悉，“龙虾”概念港股跌幅扩大，MINIMAX-WP跌7%，智谱跌近5%。