首页 › skills-review › 语言层首拆:描述写哪种语言

语言层首拆:描述写哪种语言——hello-sdd 的术语括号与中文描述件抱团聚居

概述

一、选题逻辑:拆了七遍「怎么写」,没人拆「用哪种语言」

先自证不炒冷饭。与语言层沾过边的存档有三处,但都只领过边注:《起名即路由》在门面五流派里记过一笔「转写裂缝」——中文名人用拼音(liudehua)、国际名人用英文名(jackie-chan)、日漫角色用罗马字(naruto),手动通道在转写层断裂;同文记过「语言后缀 -zh、-sc 是中文生态的刚需发明」,一句话带过。《论述变图》拆 architecture-diagram-zh 时点过「中文语境的架构图有独立的画法惯例」,服务于命名分析。《改牌第二例》拆的是描述去 Claude 化——把品牌词从描述里摘出去。三处都不是把「语言」本身当研究对象。

二、快照普查:45 条里 8 条非英语,且抱团聚居

比例约六分之一。但比比例更重要的是分布:8 条里 7 条成簇——DeepSeek Harness(DSH)生态三件(鲸鱼娘皮肤、余额挂件、桌面版,三件自述全部点名 DSH)、WARP 系两件、录音硬件一件,只有 hello-sdd 独在西语。中文描述不是随机撒在榜单上的盐,是聚居在特定宿主生态周围的村落※(推断依据:三件 DSH 件的中文描述与其自称的生态归属一致——DSH 社区的通用语是中文,其周边工具自然用中文写门面)。

同一天还有一个天然对照实验:微信场景两件同榜,wechat-intelligence-hub(⭐1914)用英文描述「Local-first WeChat intelligence system...」,WeChat-AI(⭐1885)用中文描述。同一个场景、同一天、两种语言赌注。前者赌的是 GitHub 国际流量与英文生态的检索入口,后者赌的是中文用户的原话直接命中——胜负要靠路由日志才能判,纸面只能记下:这不是谁对谁错,是两条都没被验证过的路线※。

flowchart TB
    subgraph ZH["中文描述簇"]
        DSH["DSH 生态三件<br/>鲸鱼娘 挂件 桌面版"]
        WX["WeChat-AI"]
        WARP["WARP 系两件"]
    end
    subgraph EN["英文描述簇"]
        OFF["官方出厂件"]
        WIH["微信情报室<br/>中文场景 英文描述"]
    end
    subgraph ES["西语簇"]
        HS["hello-sdd"]
    end

三、评测对比表

对象是五种语言写法而非单件——单位变了,维度跟着换,不硬套五维权重(沿用《起名即路由》先例):触发命中面(描述原话与用户语言的重合度)、受众半径、过期与腐化风险(星多=风险低)、维护成本(星多=成本低)。全部为纸面估分※,与正文层五维分不可比。

语言写法 快照/在册标本 触发命中面 受众半径 过期风险 维护成本
全英件 官方出厂件、微信情报室 ★★★★(英文生态) ★★★★★ ★★★★ ★★★★★
全中件 WARP 系、录音卡、WeChat-AI ★★★★★(中文原话) ★★★ ★★★★ ★★★
双语件 鲸鱼娘、DSH 桌面版 ★★★★★ ★★★★ ★★★ ★★
后缀方言件 -zh/-sc 在册四件 ★★★★ ★★★ ★★★★ ★★★★
本土语言件 hello-sdd ★★★★(西语原话) ★★ ★★★★ ★★★

评分说明:触发命中面按「描述语言与目标用户原话语言的重合度」估;双语件命中面最高但维护成本最低分——两套原话要人肉同步,改一处漏一处※。后缀方言件指本会话注册表在册的 course-video-maker-zh、course-video-maker-zh-link、architecture-diagram-zh、ericsson-ppt-writer-sc 四件(一手清点),它们把语言写进名字第三段,描述可以继续用英文——语言被显式声明后,描述层就解放了。

四、语言五层决策点:你的第一个 Skill 在哪五处押语言

这一节是给写作者的主菜。一个 Skill 从目录名到交付物,语言决策点有五处,每处都有在册标本。

第一层:名字——转写方案要立法。 注册表四百余条名单(存档口径)里的人设件给出了现成教训:jackie-chan 不叫 chenglong,naruto 不叫 mingzhitouhuo,liudehua 不叫 Andy Lau——三套转写并存,用户心里念的那个词,盘上未必有。转写裂缝的修补成本极低:README 第一屏写明检索词对照表。名字层的语言原则一句话:名字给手滑的通道用,转写服从目标用户的第一反应,而不是作者的审美※。

第二层:描述——原话预埋,双语并列。 这是五层里收益最大的一处。存档反复验证过定律:路由匹配字符串不是意图(《从拆到造》原话),描述里少埋一种语言的原话,就永久漏掉那批用户。证据有两头——官方 update-config 的原话枚举全是英文(「from now on when X」「each time X」,注册表一手),它服务英文原话用户毫无问题;而本栏收官轮自己写的周报 Skill 示例草稿,描述第一句就是中文(「帮我写周报。当用户提到周报、weekly report、本周总结……」)——当时是无意识的,现在回头看,那份草稿已经在按「用户原话语言」写作。升格成显式定律就是:中文用户的件,描述里中英触发词并列,一行字双倍命中,成本最低、收益最快的单点改动。

第三层:正文——指令语言与对话语言解耦。 官方十范文正文全英文(触发词批改课口径),官方 skill-creator 专门有一节教「受众检测」:JSON、assertion 这类词要先看到用户懂行的信号再用(拆解官方母文期引文)。把这条行话密度元规则平移到语言层:正文写给模型读,模型指令跟随在英语语料上最强(通行理解※);但正文里所有会出现在产出物中的句式、术语表、排版惯例,必须按产出语言单独立法。 指令用英语、产出用中文,不是精分,是分工。

第四层:脚本与资源——语言中立区,除了报错文本。 scripts/ 里的 bash 与 python 无语言问题,但它们的输出会进入模型上下文——脚本报错用什么语言写,决定模型向用户转述的底稿。本栏闸原语那期拆过运行时拒绝文本的三套语法,Skill 自带脚本的报错文本同理:报错是脚本的描述层,用你预期用户求助的语言写。

第五层:产出物——语言是排版问题,不止是翻译问题。 architecture-diagram-zh 的存在证明了这一层的独立性:中文架构图不是英文架构图翻个译,是标签宽度、菱形判断框排版、自上而下分层惯例全部不同(《论述变图》引文)。-zh 后缀锁的不是「翻译成中文」,是一整套中文产出惯例。写中文产出件的人,该把排版惯例当作正文的一等公民来写,而不是假装翻译就够了。

flowchart TB
    U["用户发出一句话"] --> R{"路由器拿原话<br/>比对 description"}
    R -->|"原话同语言命中"| HIT["加载正文"]
    R -->|"语言错位漏配"| DEAD["这个件等于不存在"]
    HIT --> BODY["正文下指令<br/>指令语言"]
    BODY --> SCR["脚本与资源<br/>语言中立区"]
    SCR --> OUT["产出物<br/>用户语言与排版惯例"]

五、新面孔双标本:术语括号与模型名语言

fable-orchestrator(⭐572)——模型名作为第三种语言。 描述原文:"Fable 5.1 orchestrates. GPT-5.6 Luna and DeepSeek V4 Flash implement." 三个模型名,零功能词。这是描述层品牌词光谱的一个极端——同一张快照上站着相反的极值:sepia 的描述写「any Agent Skills-compatible agent」(去品牌化,《改牌第二例》的路线),fable-orchestrator 把三个模型名焊死进描述(超品牌化)。模型名语言的收益是借信誉:用户认模型不认功能,名字自带性能预期;代价是过期债——官方 claude-api 的描述里带着「(4.5 → 4.6, 4.6 → 4.7, retired-model replacements)」的版本号(注册表一手),触发词批改课早就给它记过「模型版本号入描述」的维护债;官方有发行渠道随版本更新描述,社区件未必有※。fable-orchestrator 把三种模型的版本号同时背上,过期债三倍计息。本栏第 1 轮周报当时留了话「留待其文档完善后单独拆」——本期只取语言层标本,综合分继续挂起,不复议。

六、安装与使用:语言三问

市场端检索(命令可直接复制):

npx skills find spec-driven-development   # 找 SDD 类件
npx skills find 周报                       # 用中文原话测检索入口
git clone https://github.com/mouredev/hello-sdd      # 西语 SDD 课程(课程仓,非单件 Skill※)
git clone https://github.com/codejunkie99/fable-orchestrator   # 多模型编排件(描述=三模型名)

写自己的第一个 Skill 之前,先答语言三问:

  1. 原话卷:目标用户求助时嘴里蹦的是什么语言?描述里有没有把那条原话逐字埋进去?拿不准就中英并列——一行字,双倍命中。
  2. 分工卷:正文指令语言与产出物语言分开了吗?产出语言的排版惯例(标签宽度、术语表、句式)在正文里立法了吗?
  3. 转写卷:名字里的专有名词用哪套转写?README 第一屏写检索词对照了吗?行话是否保留英文原词加括号?

推荐排行榜

语言层的全部设计可以收成一句话:描述埋用户的原话,正文用模型的强语,产出守用户的惯例,行话留给英文,解释交还母语。格式、触发词、结构都已卷过一遍之后,「用哪种语言写」是尚未卷起来的最后一层薄地——也是非英语作者手里最便宜的差异化。

参考来源

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入