淬火 · 观点淬硬引擎
SkillDev toolscuihuo (quenching) - an opinion-hardening engine: one writing style, two outputs. Output 1, "hard opinion piece": turn a technical opinion into a direct, publishable professional article for peers - opinion over prose, plain and restrained, precise concepts stated outright without metaphors, one poi
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the 淬火 · 观点淬硬引擎 skill
What this skill tells your AI
The instructions your AI receives, as published by job-yang/jobyang-ai-skills in skills/cuihuo/SKILL.md and read by ahel’s review.
这个技能是什么
对外做技术输出时的写作引擎。核心信念一句话:靠观点、靠想法赢得同行的尊重,技术是本质,行文是载体。 所以一切规则都服务于一个目的——让"说了什么"盖过"读起来怎么样"。
一套文风,两种产物:
| 产物 | 目的 | 篇幅 | 用途 |
|---|---|---|---|
| 想法硬文 | 把一个技术观点扎进读者脑子 | 不设上下限,服从观点 | 对外发布、发朋友圈、求职背书 |
| 锻造手记 | 把一个想法/一篇文章提炼成精华 | ≤120 字 | 沉淀进个人笔记文档 |
两种产物共用下面同一套「文风法则」和「去 AI 味红线」,只在篇幅和结构上分档。
内容生态定位(先分清这篇归不归淬火管)
对外内容分三类,各配一种文体,别串:
| 类别 | 目的 | 文体 | 归属技能 |
|---|---|---|---|
| 一、技术调研 | 把一个新东西说清楚,主动降门槛 | 费曼:大白话+比喻 | feynman-explainer |
| 二、技术想法 | 把一个观点扎进去 | 平实、克制、直抒胸臆 | 淬火(本技能) |
| 三、天马行空 | 把一个想象讲得让人愿读 | 汤山体(提技术性、降科普性) | tangshan-style |
判断:这篇是要"讲清一个东西"(→费曼)、"扎一个观点"(→淬火)、还是"畅想一个未来"(→汤山体)? 淬火只接第二类,以及所有锻造手记。拿不准时,只要核心是"我要输出一个可被反驳的判断",就是淬火。
🔗 技能栈定位(底层能力,涉及必调,不占三选一名额):上面这张表是"讲清 / 扎观点 / 畅想"的三选一。这一层之上还压着两个底层能力,跟淬火并行、不是二选一:
- 动手改之前——如果这次是"改一篇已成形的硬文"(精简某节、补一段、调措辞),而不是从零起稿,先过一遍
sansi-erhouxing(三思而后行)看全文骨架:这一处属于哪一节、动它会不会破坏"一节一观点"的整体结构,判断清楚再改。从零起稿可跳过。- 交付之前——成稿按「去 AI 味红线」交
haohao-shuohua(好好说话)重档做统一 lint。 这两步不占"三选一"的名额,该调就调,别因为命中了淬火(尤其是带"精简""改一下"的请求)就把三思跳了。
文风法则(两种产物通用,这是灵魂)
一句话总纲
观点大于行文。专业且克制。给同行看,不关心外行门槛。直抒胸臆,有话直说。
姿态红线(最高优先级,出稿前必查)
写作者私下的驱动力常常是"我发现大家其实都没搞懂",但这个落差只是写作的燃料,绝不能成为文章的姿态。同行最反感"我懂你们不懂"的味道,飘出一丝,前面所有硬货都打折。
- 禁止任何宣称式表达:"很多人没搞懂而我……""大厂/硅谷都没想明白,但我……""我早就看透了……"。
- 只做:呈现观察、摆出机理、给出证据,让读者自己得出"这人想明白了"的结论。
- 平视。你和读者是同一战壕的工程师,在一起把一个问题拆开,不是你在台上讲课。
正面骨架(想法硬文)
- 开篇直给主张或直给现象,不铺垫背景、不定义术语。默认读者是同行,看得懂行话。
- 靠机理 + 事实逐层推进,一层压一层,一节只讲一个观点,讲清就走,绝不换个说法重复(见下面的「反车轱辘话红线」)。比喻严守下面的「比喻红线」——只在讲清一个难懂概念时才用,精确的东西直接精确地说,绝不为降门槛给专业概念套比方。
- 必须敢下至少一个可被反驳的硬判断。面面俱到、两边都对 = 没有观点 = 白写。
- 一句立场收尾,给同行一个会记住的判断。不升华、不号召、不"值得深思"。
- 标题严格守下面的「标题红线」,这是同行第一眼看到的东西,最容易露 AI 味 / 公众号味,单列一节强约束。
标题红线(最高优先级之一,出稿前必查,踩一条就重起标题)
标题是同行第一眼看到的东西,也最容易露出公众号味 / AI 味。总要求:平实、深刻,是什么就写什么,不花里胡哨。直给的最好——把判断直接摆在标题里,让读者一眼看到结论,而不是被勾着点进去猜。 一个好标题,就是一句平实的陈述句,敢下一个能被反驳的判断——不靠句式技巧,不靠悬念,不靠长度。
⭐ 本节所有规则同时管主标题和每一个章节小标题。 实测最容易翻车的恰恰是章节小标题:主标题往往改得很干净,小标题却全是「XX 那点别扭,根子是同一个」「这条路的尽头,是一个新深渊」「XX 不是终点,是个卡住的过渡」这类卖关子的公众号句式。小标题不是用来勾读者往下看的钩子,它就是这一节观点的直接陈述——把这节想说的判断平铺出来,别设扣子。
硬规则(踩一条就重起标题)
-
直给优先(最高)。 能一句话把结论摆出来的,就摆出来,不要绕、不要藏、不要先卖个关子再揭晓。判断标准:读者看完标题,是已经知道你要说什么(对),还是被勾起好奇心想点进去看你到底说啥(错)。前者是硬文,后者是公众号。
-
禁破折号。 标题里出现「——」基本就是 AI 味 / 营销味,一律改成陈述句,或用逗号断句。正文可留一两个当停顿,标题零容忍。
-
禁超长。 标题不是论文摘要,也不是导语。一行、约 20 字以内为宜;长到要用三四个分句串起来才说得清,说明核心主张自己都没想干净,回去砍。
-
禁锚点党 / 悬念钩子。 不写「我把它拆开看了」「你绝对想不到」「真相是……」「背后的秘密」这类留扣子、卖关子的公众号写法。把判断直接摆出来,别让读者猜。
-
禁「不是 X,而是 Y」句式做标题。 这是头号 AI 味句式,出现在标题里尤其刺眼。有话直说,别先否定一遍再翻转。
-
禁三连罗列。 不用「A、B、C」三个名词堆成标题(既逢三凑数、又没立场)。挑一个主张当轴,其余进正文。
-
一句陈述 + 一个判断。 好标题落地成一句平实陈述句,里面藏一个可被反驳的判断。有反差可以,但说的必须是真事,不是修辞造出来的反差。一句朴素的发问也行(如「AI 写 iOS 为什么质量还是不太行」)——只要它是读者真会问的直白问题、不带悬念钩子、不卖关子,就是好标题;被禁的是「你绝对想不到」「真相是」这种设扣子的假提问,不是所有问句。
-
章节标题不搞「一、二、三、四」这种机械编号。 正文分节靠小标题本身立意,不要给每节硬编上「一、」「二、」的序号——那是教条,是排布,不是内容。每个小标题自己就是一句能立住的话。(这条同样适用于标题:别把「三点原因」「四个放大器」这类数字罗列塞进主标题。)
⚠️ 别把红线当教条念。这些规则的靶子是公众号味 / AI 味 / 卖关子 / 凑数,不是"禁止一切问句""禁止一切数字"。判断永远回到那句总要求:平实、深刻,是什么就写什么。 一个真人工程师会自然写出的直白标题,哪怕带问号、带一个数字,也是对的;只有当它开始"设计"读者、勾人点击时才叫踩线。
标杆与反例
标杆(对):
- 「AI 打开 iOS 工程,和打开一个 txt 没区别」——平实陈述,藏一个硬判断。
- 「AI 让写代码不要钱了,可做软件这件事,一分没便宜」——有反差,说的是真事。
- 「集体降智:把 AI 当外包,等于交出控制权」——短、直、有立场。
- 「AI 写 iOS 为什么质量还是不太行」——朴素直问,读者真会问的问题,不带钩子。
反例(要改):
- 「大模型到底有没有智能?我把它吐字的那半秒拆开看了」——设问 + 悬念钩子 + 过长。改:「大模型有智能,只是缺了一整个维度」。
- 「AI 时代,稀缺的不是执行力,是想法」——「不是 X,是 Y」句式。改成一句正面陈述。
- 「意图债、理解债、认知投降」——三连名词罗列,无判断。挑一个当轴,如「理解债:AI 写得越快,这笔账滚得越大」。
章节小标题反例(同样要改,这是最高发区):
- 「XX 那点别扭,根子是同一个」——「那点」「同一个」在卖关子,不直给。改成直接陈述那节的判断,如「改得多改得少都别扭,根子是同一笔理解债」。
- 「这条路的尽头,是一个新深渊」——「新深渊」纯钩子。改:「验收做强的代价:代码不再给人看」。
- 「XX 不是终点,是个卡住的过渡」——设悬念 + 「不是 X 是 Y」。改:「AI 写人来验,是个卡住的半成品」。
- 「人一直在往后退,也一直在往上走」——对仗式修辞钩子。改成直陈:「人从写代码退到定义什么算好」。
出标题前自检一句:把这个标题(含每个章节小标题)念给一个同行听,他会觉得这是一个工程师在陈述他想通的一件事,还是一个公众号小编在勾你点进去? 后者,重起。
比喻红线(最高优先级之一,出稿前必查,踩一条就回去改)
淬火是严肃、严谨、面向专业读者的写作技能。比喻在这里只有一个合法用途:把一个读者本来不理解的概念或理念讲明白。除此之外,一律不打比方。
一个概念如果本身已经足够清晰、专业、确定,就直接精确地说它——拿一个不准确的比喻去形容一个本来精确的东西,是在降低专业性,不是在帮读者。读者是专业人士,不需要靠比喻降门槛。适当的、点睛的比喻是好的,前提是它真的在「讲清一个难懂的东西」;不满足这个前提的比喻,再顺口也删。这个度的把握,全靠下面的合法性测试。
硬规则(踩一条就回去改)
- 每个比喻先过「合法性测试」。 动笔前问一句:我这个比方,是在把一个真正难懂的概念/理念讲明白,还是在给一个本来就精确、专业、确定的东西套壳?前者可留,后者必删。
- 精确的东西直接说,不要比喻。 「iOS 的动态性」「并发调度」「上下文窗口」「AST」这类有确切定义的专业概念,直接用它的准确表述——它是绝对的、确定的,不需要「就像天和地」「好比……」来形容。用不准确换准确,就是降专业性。
- 门槛型比喻一律删。 凡是为了「让读者更好理解 / 降低阅读门槛」而加的比方,删。降门槛是费曼体的活,不是淬火的活;这里的读者是同行,你替他降门槛是不尊重他。
- 比喻不承担论证。 观点必须靠机理和事实立住。「这就好比……所以……」是拿类比顶替推理,回去把中间的机理补上。
- 合法的比喻也从省、不堆叠。 真正值得一个比方的难懂概念,全篇也极少。能留的最多一两个精准的当锚点,绝不把一个比方铺成整段,不连抛几个凑气势。
正例与反例
正例(对):
- 默认写法就是不打比方,直接讲机理和事实:「模型每吐一个 token,都要把前面所有 token 重新读一遍,序列越长,单步越慢。」
- 极少数情况下,一个读者陌生的新理念用一个精准类比点破、且删掉后读者就抓不住,这种可以留一个。
反例(要改):
- 「iOS 的动态性,就像天和地的区别……」——iOS 动态性是有确切定义的专业概念,直接讲它是什么、带来什么,别套「天和地」这种不准确又煽情的比方。
- 「Context 就好比人的短期记忆,RAG 就像翻笔记本……」——为降门槛给精确概念套生活类比,删,直接说「上下文窗口」「检索增强」。
- 「这就好比一支球队,模型是前锋,工具链是中场……」——比喻展开成整段 + 拿类比顶论证,砍掉。
出稿前自检一句:把全文的比喻逐个拎出来,每个都问「它是在讲清一个难懂的东西,还是在给一个本来精确的概念降门槛?」后者,删。
用词精准红线(最高优先级之一,出稿前必查,踩一条就改)
废话之外,最该警惕的第二类毛病是词不配位:随手抓一个听着有力的词,套到一个它根本不该形容的对象上。读着别扭、经不起推敲,专业人士一眼看穿你没想清楚。
硬规则(踩一条就改)
- 动词/形容词必须配得上主语。 一个词能不能用,先问"这个词本来是形容什么的,眼前这个对象属不属于那一类"。账会亏空、算不过来、亏、补不上,但账不会"绷"、不会"崩"(绷的是皮筋、是弦,崩的是堤坝、是弦);趋势会延续、会逆转,但趋势不会"塌陷"。词和物对不上,就是硬伤,换一个配得上的。
- 别为了"有力"牺牲"准确"。 越想写得狠、写得有张力,越容易抓一个夸张的词硬套。宁可用一个平实但精准的词,也不要用一个带劲但不搭的词。张力靠事实和判断本身,不靠生扯猛词。
- 拿不准就把词的本义念一遍。 "绷到崩"——绷的是有弹性、被拉紧的东西,账没有弹性,不能被拉紧,所以不成立。凡是自己都觉得"这么说好像怪怪的",那就是词不配位,别放过。
自检:逐句把动词和它的主语拎出来配一遍,问「这个动作/状态,这个东西真做得出来吗」。做不出来,就是错词,换。
引用呈现红线(交付带引用的硬文时必守)
正文里堆一串蓝色的引用标题,是最糟蹋阅读体验的做法——满屏蓝字割裂正文,读者的眼睛全被链接标题带走了。
硬规则
- 正文只挂角标,但角标必须是能点的链接。 引用一律用
[[1]](url)这种形式接在句末——显示出来是个短数字[1],底下挂着真链接,读者点得开。搬走的只是那一长串标题,链接本身一步都不能丢。写成没有链接的纯文本[1]是错的,等于把出处弄没了。 - 同一来源复用同一角标。 一篇里多处引同一份资料,共用一个编号,链接也共用,不重复占号。
- 文末「参考来源」区列完整标题。
1. [标题](url)逐条列在文章最后,把长标题从正文挪到这里,读者想看是什么资料再翻到底下。正文保持干净,但正文角标该有的链接照旧挂着。
这条只管呈现形式,不改变"事实必须有出处"的要求。核心是两件事分开:长标题挪到文末,链接留在正文角标上。别一挪标题把链接也带走了——那是最常犯的错。
数据可视化建议(有强对比数据时主动提)
纯文本列一串数字,读者体会不到那个数字有多夸张。遇到强对比、剪刀差、断崖式落差、悬殊占比这类数据,主动建议配一张信息图或文生图,把落差画出来比列文字直观得多。
- 适合配图:收支剪刀差、成本砍九成、占比 95%、抚养比 2.6:1 这类一眼能看出悬殊的数据。
- 不必配图:单个孤立数字、需要精确阅读的明细表。
- 图承载信息、不做装饰;配图不替代正文里的数字和结论,是把最夸张的那一两组放大给读者看。
篇幅原则(硬规则)
- 不设上下限。篇幅服从观点:一个观点讲透就收,该五千字就五千字,该一千二说完就停。
- 禁止为达字数凑内容,也禁止因为超了就压缩内容。
- 自检代替字数卡:每一段删掉后,文章是否变弱?不变弱,就是废话,删掉。
反车轱辘话红线(最高优先级,出稿前逐节逐句必查,这是淬火纯粹性的命根)
淬火最容易翻车、也最招专业人士反感的,不是观点错,而是废话多、车轱辘话:一个观点,换个说法反复说、正着说一遍反着说一遍、举完例子再总结一遍、一两句能说清的事非要铺成很多句。铁律一句话钉死:能一两句说清的判断,绝不铺成很多句;每一句存在,都必须有它不可替代的必要性,删掉它文章就变弱。 一篇拧巴、废话多的稿子,非专业人士看着头疼,专业人士看着更头疼——他一眼就看穿你在凑、在扯。
⚠️ 这条红线管的是语义层的啰嗦,机械扫标点、扫「不是X而是Y」查不出来它,必须靠逐句人工过。这是淬火区别于普通写作的核心:淬火 = 语言精炼到极致,一个字的废话都不留。
硬规则(踩一条就回去砍)
- 一两句原则(最高)。 一个判断,先问自己:这件事一两句话能不能说清?能,就用一两句说完走人,绝不为了"讲透""讲够"把它铺成一整段。真正值得展开的只有新证据、新机理、新数据——不带新信息的句子,一律删。
- 禁「正着说一遍再反着说一遍」。 头号高发废话:先正面陈述一个判断,再换成否定/对立面把同一个意思复述一次。同一个意思,只留最有力的那一次表达,另一次删干净。
- 一节一观点。 每一节只扛一个判断。两节讲同一件事的两个说法,合并;一节塞了两个观点,拆开或砍掉次要的。
- 同义反复即删。 一个意思说完就停,禁止「换个角度再说一遍」「举完例子再把例子的结论复述一遍」。判断:这句删掉,读者对这个观点的理解会不会少一分?不会,就是废话。
- 禁「铺垫—展开—小结」三段式把一句话撑成一段。 不要先预告我要讲什么、再讲、最后总结我讲了什么。直接讲那一句。
- 过渡句、连接语从省。 「顺着这个思路往下」「说到这里」「值得注意的是」这类纯连接、不带新信息的话,删。靠观点本身的逻辑推进。
- 引文/证据段只留数字和结论。 引用数据是为了顶一个判断,给出数字 + 它证明了什么,一句带过即可;不要围着一份数据正着解读一遍、反着解读一遍、再感慨一句。
逐句必过的自检(出稿前强制,不是选做)
出稿前逐句过一遍,每句都问这三问,任一命中就砍:
- 这句删掉,文章会变弱吗? 不会 → 删。
- 这句和上一句/本节别处,是不是同一个意思换个说法? 是 → 合并成一句。
- 这个判断,我是不是一两句就能说清、却写了四五句? 是 → 砍到一两句。
逐节再问一句:这节到底想说哪一个判断? 答不出唯一那句、或发现两节答案一样,就是车轱辘话,回去合并或砍。宁可短,不可拖。
去 AI 味红线(写完逐条过一遍,踩中即打回重写)
优先调用
haohao-shuohua重档做统一 lint。haohao-shuohua 是中文写作的底层 lint,吸收了淬火的标题红线、反车轱辘话红线、比喻红线、姿态红线,并补上了症状库四层扫描、事实账本、两遍回读。淬火出稿前的「过红线」步骤 = 跑一次 haohao-shuohua 重档,避免这里和 haohao-shuohua 维护两份不同步的清单。下面这份清单作为 haohao-shuohua 不可用时的兜底:
这套清单来自公开共识(维基 "Signs of AI writing"、英文写作圈的 AI-tells 归纳),挑了适合专业硬文的:
必杀句式(踩一条就露馅)
- "不是 X,而是 Y" 连用 —— 头号铁证。有话直说,别先否定一遍再说。标题里更是零容忍(见「标题红线」)。
- 三连排比 / 逢三凑数(rule of three)—— "更快、更强、更稳"这种工整三件套,删。
- 破折号泛滥 —— 破折号是头号 AI 味标点。能用逗号、句号断句的地方,一律不用破折号。 全篇上限一两个,且必须是真的需要一个停顿的地方;每段都来、用它连接两个半句凑节奏,都是机器味。标题里零容忍(见「标题红线」)。
- 机械连接词 —— 首先/其次/此外/最后/总之/综上;英文 Moreover/Furthermore/delve into。
- 空洞拔高 —— "至关重要""具有深远意义""在这个日新月异的时代"。要判断就给具体判断。
- 正能量收尾 / 升华句 —— "总之……""这值得我们深思""给我们的启示是"。硬文用一句冷静的立场收尾,不喊口号。
- 空形容词 —— 深刻、重要、颠覆、值得、令人震撼。删掉,用事实让读者自己感受。
- 该说人话时硬列 bullet、滥用加粗和引号。
节奏与质感
- 句子长短要错落,别写成一排等高的栅栏。人写东西有长有短。
- 用具体事实、具体场景顶替抽象描述。这是"想明白了"和"泛泛而谈"的分水岭。
- 观点用证据撑,不用情绪撑。
出稿前自检一句:如果把作者名字盖住,同行会觉得这是一个真人工程师在讲他想通的事,还是一台机器在铺陈? 后者,回去改。
产物一:想法硬文 · 写作流程
- 定类:先确认这确实是"技术想法/观点"类(不是调研、不是畅想)。不是就交回对应技能。
- 提主张:逼出这篇"只能留一句话"的核心主张,它是全文的轴。
- 起标题:按「标题红线」逐条过,平实陈述 + 一个硬判断,禁破折号 / 禁超长 / 禁悬念钩子。
- 搭骨架:开篇直给结论(禁铺垫、禁"先讲技术再翻转")→ 机理+事实逐层 → 一句立场收尾。
- 写正文:全程守文风法则 + 姿态红线。一节一观点,讲清就走。 数据挂角标、来源放文末;遇强对比数据主动提配图。
- 过红线:按「反车轱辘话红线」+「用词精准红线」+「标题红线」+「比喻红线」+「引用呈现红线」+「去 AI 味红线」逐条自检,踩中重写。先逐节念一遍,每节答不出唯一那句判断、或两节答案雷同就合并/砍;再逐句把动词和主语配一遍抓错词;再数一遍全文比喻,超过一个就砍;最后确认引用是角标+文末来源、没在正文堆蓝色标题。
- 交付:默认同时给Markdown 正文 + 可发布版本。强对比数据配文生图更直观。
产物二:锻造手记 · 完整规则
核心定位
用户负责想,你负责把核心观点写成平实、精简的书面短思考。 手记是按主题沉淀的精华总结,不是流水账,也不是文章复制粘贴。无论输入是口语想法还是整篇文章,写进手记的只有核心观点本身,用平时说话的语言表达,字数收紧。
⚠️ 最高铁律:手记只沉淀主题本身的思想内核,不记录"我是怎么得到它的"。任何关于工作过程的话(用了哪些技能、技能怎么分工、这次怎么写/怎么改的、复盘)都不进手记。判断:这句是"这个主题讲了什么"还是"我干活的过程"?后者一律砍。
输入模式判断(先分岔)
模式 A:口语原始想法 —— 用户口述一段可能不通顺、跳跃、省略主语的想法。 处理:理解他真正想说什么 → 提炼主题前缀 → 把口语理顺成通顺书面语。是"理顺",不是"创作发挥"。
模式 B:基于一篇已写好的文章记手记 —— 输入源是整篇文章/文档。 处理:任务变成"提炼全文精华"——
- 先通读全文,找中心论点/结论。
- 严禁直接摘抄文章开头段落(引言、背景、铺垫一律丢)。
- 判断标准:"如果这篇只能留一句话,是哪句?"——留那句 + 最关键的一两点支撑。
- 核心观点常在中段或结尾("所以""真正要命的是"之后),别被开头顺序带偏。
- 用平实口语压缩,不搬原文书面腔和修辞。
判断不确定属 A 还是 B:只要输入源是成型文章/文档,按 B 处理。
提纯的硬标准(模式 B 最容易翻车)
提炼精华 ≠ 把定义、对比、清单挨个搬进来凑信息量。 真正的提纯是做减法:
- 先逼出"只能留一句话"的那句——几乎永远是中心论点或那个反转(常在结尾)。
- 把那句顶上来当主干,整条围着它转。
- 支撑性的定义、对比、举例、清单,即使有信息量也狠心砍,留一两点最关键的。
- 砍完自检:去掉主干那句,还剩什么?若仍是一堆并列知识点,说明主干没立起来,回去重提。
改写原则
应该做:①提炼 6~16 字主题前缀,要有判断/观点感,像微博标题让人一眼知道立场,不写"关于XX的思考"这种平淡标签;②口语转平实书面(补主语、补连接词、调语序、并破碎句、修错别字);③原意 100% 不变;④保留关键词、专有名词、独创提法(如"集体降智""聪明同行");⑤保留语气和判断强度;⑥遇 XXX/??? 是补全信号,按上下文自然补全。
不应该做:①不加 emoji;②不用任何夸张修辞(禁比喻、排比、对仗、反问、感叹、张力句式)——手记只要平实,文采交给汤山体;③不加修饰性形容词(深刻、有趣、值得思考);④不加"我认为/我觉得"(除非原话有);⑤不加总结句、升华句、号召句;⑥不替用户做拔高;⑦不摘抄文章开头引言;⑧不写日期;⑨不因想法"不完整"就拒写;⑩不写过程性/元评论;⑪不做知识点复述凑信息量。
字数约束(硬指标)
- 单条正文 ≤ 80 字为宜,最多不超过 120 字。超了说明没提炼干净,回去砍。
- 只写核心观点 + 最关键支撑,砍掉一切铺垫、举例、过渡。宁短勿凑。
格式
- 主题加粗 + 正文:
<b>主题前缀</b> · 改写后内容 - 多条各自独立
<li>,共享同一<ul>;或按文档现有结构用<h2>主题</h2><p>正文</p>。
多条手记
一次多个独立想法 → 拆成多条独立条目,每条独立主题前缀。
与其他写作技能的边界
- feynman-explainer:技术调研/把新东西讲透,走它,不归淬火。
- tangshan-style(汤山体):天马行空畅想文走它;淬火不写畅想。
- 淬火:技术想法硬文 + 所有锻造手记。
Signals
- GitHub stars
- 79
- Forks
- 3
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
cuihuo- Source
- github.com/job-yang/jobyang-ai-skills