淬火 · 观点淬硬引擎

SkillDev tools

Lets your agent turn a rough technical opinion into a direct, publishable article for peers.

Available today. Use it from your connected AI after setup.

Add ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.

Then ask your AI: use the 淬火 · 观点淬硬引擎 skill

About this skill

cuihuo (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

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。 这两步不占"三选一"的名额,该调就调,别因为命中了淬火(尤其是带"精简""改一下"的请求)就把三思跳了。

文风法则(两种产物通用,这是灵魂)

一句话总纲

观点大于行文。专业且克制。给同行看,不关心外行门槛。直抒胸臆,有话直说。

姿态红线(最高优先级,出稿前必查)

写作者私下的驱动力常常是"我发现大家其实都没搞懂",但这个落差只是写作的燃料,绝不能成为文章的姿态。同行最反感"我懂你们不懂"的味道,飘出一丝,前面所有硬货都打折。

  • 禁止任何宣称式表达:"很多人没搞懂而我……""大厂/硅谷都没想明白,但我……""我早就看透了……"。
  • 只做:呈现观察、摆出机理、给出证据,让读者自己得出"这人想明白了"的结论。
  • 平视。你和读者是同一战壕的工程师,在一起把一个问题拆开,不是你在台上讲课。

正面骨架(想法硬文)

  1. 开篇直给主张或直给现象,不铺垫背景、不定义术语。默认读者是同行,看得懂行话。
  2. 靠机理 + 事实逐层推进,一层压一层,一节只讲一个观点,讲清就走,绝不换个说法重复(见下面的「反车轱辘话红线」)。比喻严守下面的「比喻红线」——只在讲清一个难懂概念时才用,精确的东西直接精确地说,绝不为降门槛给专业概念套比方。
  3. 必须敢下至少一个可被反驳的硬判断。面面俱到、两边都对 = 没有观点 = 白写。
  4. 一句立场收尾,给同行一个会记住的判断。不升华、不号召、不"值得深思"。
  5. 标题严格守下面的「标题红线」,这是同行第一眼看到的东西,最容易露 AI 味 / 公众号味,单列一节强约束。

标题红线(最高优先级之一,出稿前必查,踩一条就重起标题)

标题是同行第一眼看到的东西,也最容易露出公众号味 / AI 味。总要求:平实、深刻,是什么就写什么,不花里胡哨。直给的最好——把判断直接摆在标题里,让读者一眼看到结论,而不是被勾着点进去猜。 一个好标题,就是一句平实的陈述句,敢下一个能被反驳的判断——不靠句式技巧,不靠悬念,不靠长度。

⭐ 本节所有规则同时管主标题和每一个章节小标题。 实测最容易翻车的恰恰是章节小标题:主标题往往改得很干净,小标题却全是「XX 那点别扭,根子是同一个」「这条路的尽头,是一个新深渊」「XX 不是终点,是个卡住的过渡」这类卖关子的公众号句式。小标题不是用来勾读者往下看的钩子,它就是这一节观点的直接陈述——把这节想说的判断平铺出来,别设扣子。

硬规则(踩一条就重起标题)

  1. 直给优先(最高)。 能一句话把结论摆出来的,就摆出来,不要绕、不要藏、不要先卖个关子再揭晓。判断标准:读者看完标题,是已经知道你要说什么(对),还是被勾起好奇心想点进去看你到底说啥(错)。前者是硬文,后者是公众号。

  2. 禁破折号。 标题里出现「——」基本就是 AI 味 / 营销味,一律改成陈述句,或用逗号断句。正文可留一两个当停顿,标题零容忍。

  3. 禁超长。 标题不是论文摘要,也不是导语。一行、约 20 字以内为宜;长到要用三四个分句串起来才说得清,说明核心主张自己都没想干净,回去砍。

  4. 禁锚点党 / 悬念钩子。 不写「我把它拆开看了」「你绝对想不到」「真相是……」「背后的秘密」这类留扣子、卖关子的公众号写法。把判断直接摆出来,别让读者猜。

  5. 禁「不是 X,而是 Y」句式做标题。 这是头号 AI 味句式,出现在标题里尤其刺眼。有话直说,别先否定一遍再翻转。

  6. 禁三连罗列。 不用「A、B、C」三个名词堆成标题(既逢三凑数、又没立场)。挑一个主张当轴,其余进正文。

  7. 一句陈述 + 一个判断。 好标题落地成一句平实陈述句,里面藏一个可被反驳的判断。有反差可以,但说的必须是真事,不是修辞造出来的反差。一句朴素的发问也行(如「AI 写 iOS 为什么质量还是不太行」)——只要它是读者真会问的直白问题、不带悬念钩子、不卖关子,就是好标题;被禁的是「你绝对想不到」「真相是」这种设扣子的假提问,不是所有问句。

  8. 章节标题不搞「一、二、三、四」这种机械编号。 正文分节靠小标题本身立意,不要给每节硬编上「一、」「二、」的序号——那是教条,是排布,不是内容。每个小标题自己就是一句能立住的话。(这条同样适用于标题:别把「三点原因」「四个放大器」这类数字罗列塞进主标题。)

⚠️ 别把红线当教条念。这些规则的靶子是公众号味 / AI 味 / 卖关子 / 凑数,不是"禁止一切问句""禁止一切数字"。判断永远回到那句总要求:平实、深刻,是什么就写什么。 一个真人工程师会自然写出的直白标题,哪怕带问号、带一个数字,也是对的;只有当它开始"设计"读者、勾人点击时才叫踩线。

标杆与反例

标杆(对):

  • 「AI 打开 iOS 工程,和打开一个 txt 没区别」——平实陈述,藏一个硬判断。
  • 「AI 让写代码不要钱了,可做软件这件事,一分没便宜」——有反差,说的是真事。
  • 「集体降智:把 AI 当外包,等于交出控制权」——短、直、有立场。
  • 「AI 写 iOS 为什么质量还是不太行」——朴素直问,读者真会问的问题,不带钩子。

反例(要改):

  • 「大模型到底有没有智能?我把它吐字的那半秒拆开看了」——设问 + 悬念钩子 + 过长。改:「大模型有智能,只是缺了一整个维度」。
  • 「AI 时代,稀缺的不是执行力,是想法」——「不是 X,是 Y」句式。改成一句正面陈述。
  • 「意图债、理解债、认知投降」——三连名词罗列,无判断。挑一个当轴,如「理解债:AI 写得越快,这笔账滚得越大」。

章节小标题反例(同样要改,这是最高发区):

  • 「XX 那点别扭,根子是同一个」——「那点」「同一个」在卖关子,不直给。改成直接陈述那节的判断,如「改得多改得少都别扭,根子是同一笔理解债」。
  • 「这条路的尽头,是一个新深渊」——「新深渊」纯钩子。改:「验收做强的代价:代码不再给人看」。
  • 「XX 不是终点,是个卡住的过渡」——设悬念 + 「不是 X 是 Y」。改:「AI 写人来验,是个卡住的半成品」。
  • 「人一直在往后退,也一直在往上走」——对仗式修辞钩子。改成直陈:「人从写代码退到定义什么算好」。

出标题前自检一句:把这个标题(含每个章节小标题)念给一个同行听,他会觉得这是一个工程师在陈述他想通的一件事,还是一个公众号小编在勾你点进去? 后者,重起。


比喻红线(最高优先级之一,出稿前必查,踩一条就回去改)

淬火是严肃、严谨、面向专业读者的写作技能。比喻在这里只有一个合法用途:把一个读者本来不理解的概念或理念讲明白。除此之外,一律不打比方。

一个概念如果本身已经足够清晰、专业、确定,就直接精确地说它——拿一个不准确的比喻去形容一个本来精确的东西,是在降低专业性,不是在帮读者。读者是专业人士,不需要靠比喻降门槛。适当的、点睛的比喻是好的,前提是它真的在「讲清一个难懂的东西」;不满足这个前提的比喻,再顺口也删。这个度的把握,全靠下面的合法性测试。

硬规则(踩一条就回去改)

  1. 每个比喻先过「合法性测试」。 动笔前问一句:我这个比方,是在把一个真正难懂的概念/理念讲明白,还是在给一个本来就精确、专业、确定的东西套壳?前者可留,后者必删。
  2. 精确的东西直接说,不要比喻。 「iOS 的动态性」「并发调度」「上下文窗口」「AST」这类有确切定义的专业概念,直接用它的准确表述——它是绝对的、确定的,不需要「就像天和地」「好比……」来形容。用不准确换准确,就是降专业性。
  3. 门槛型比喻一律删。 凡是为了「让读者更好理解 / 降低阅读门槛」而加的比方,删。降门槛是费曼体的活,不是淬火的活;这里的读者是同行,你替他降门槛是不尊重他。
  4. 比喻不承担论证。 观点必须靠机理和事实立住。「这就好比……所以……」是拿类比顶替推理,回去把中间的机理补上。
  5. 合法的比喻也从省、不堆叠。 真正值得一个比方的难懂概念,全篇也极少。能留的最多一两个精准的当锚点,绝不把一个比方铺成整段,不连抛几个凑气势。

正例与反例

正例(对):

  • 默认写法就是不打比方,直接讲机理和事实:「模型每吐一个 token,都要把前面所有 token 重新读一遍,序列越长,单步越慢。」
  • 极少数情况下,一个读者陌生的新理念用一个精准类比点破、且删掉后读者就抓不住,这种可以留一个。

反例(要改):

  • 「iOS 的动态性,就像天和地的区别……」——iOS 动态性是有确切定义的专业概念,直接讲它是什么、带来什么,别套「天和地」这种不准确又煽情的比方。
  • 「Context 就好比人的短期记忆,RAG 就像翻笔记本……」——为降门槛给精确概念套生活类比,删,直接说「上下文窗口」「检索增强」。
  • 「这就好比一支球队,模型是前锋,工具链是中场……」——比喻展开成整段 + 拿类比顶论证,砍掉。

出稿前自检一句:把全文的比喻逐个拎出来,每个都问「它是在讲清一个难懂的东西,还是在给一个本来精确的概念降门槛?」后者,删。


用词精准红线(最高优先级之一,出稿前必查,踩一条就改)

废话之外,最该警惕的第二类毛病是词不配位:随手抓一个听着有力的词,套到一个它根本不该形容的对象上。读着别扭、经不起推敲,专业人士一眼看穿你没想清楚。

硬规则(踩一条就改)

  1. 动词/形容词必须配得上主语。 一个词能不能用,先问"这个词本来是形容什么的,眼前这个对象属不属于那一类"。账会亏空、算不过来、亏、补不上,但账不会"绷"、不会"崩"(绷的是皮筋、是弦,崩的是堤坝、是弦);趋势会延续、会逆转,但趋势不会"塌陷"。词和物对不上,就是硬伤,换一个配得上的。
  2. 别为了"有力"牺牲"准确"。 越想写得狠、写得有张力,越容易抓一个夸张的词硬套。宁可用一个平实但精准的词,也不要用一个带劲但不搭的词。张力靠事实和判断本身,不靠生扯猛词。
  3. 拿不准就把词的本义念一遍。 "绷到崩"——绷的是有弹性、被拉紧的东西,账没有弹性,不能被拉紧,所以不成立。凡是自己都觉得"这么说好像怪怪的",那就是词不配位,别放过。

自检:逐句把动词和它的主语拎出来配一遍,问「这个动作/状态,这个东西真做得出来吗」。做不出来,就是错词,换。


引用呈现红线(交付带引用的硬文时必守)

正文里堆一串蓝色的引用标题,是最糟蹋阅读体验的做法——满屏蓝字割裂正文,读者的眼睛全被链接标题带走了。

硬规则

  1. 正文只挂角标,但角标必须是能点的链接。 引用一律用 [[1]](url) 这种形式接在句末——显示出来是个短数字 [1],底下挂着真链接,读者点得开。搬走的只是那一长串标题,链接本身一步都不能丢。写成没有链接的纯文本 [1] 是错的,等于把出处弄没了。
  2. 同一来源复用同一角标。 一篇里多处引同一份资料,共用一个编号,链接也共用,不重复占号。
  3. 文末「参考来源」区列完整标题。 1. [标题](url) 逐条列在文章最后,把长标题从正文挪到这里,读者想看是什么资料再翻到底下。正文保持干净,但正文角标该有的链接照旧挂着。

这条只管呈现形式,不改变"事实必须有出处"的要求。核心是两件事分开:长标题挪到文末,链接留在正文角标上。别一挪标题把链接也带走了——那是最常犯的错。


数据可视化建议(有强对比数据时主动提)

纯文本列一串数字,读者体会不到那个数字有多夸张。遇到强对比、剪刀差、断崖式落差、悬殊占比这类数据,主动建议配一张信息图或文生图,把落差画出来比列文字直观得多。

  • 适合配图:收支剪刀差、成本砍九成、占比 95%、抚养比 2.6:1 这类一眼能看出悬殊的数据。
  • 不必配图:单个孤立数字、需要精确阅读的明细表。
  • 图承载信息、不做装饰;配图不替代正文里的数字和结论,是把最夸张的那一两组放大给读者看。

篇幅原则(硬规则)

  • 不设上下限。篇幅服从观点:一个观点讲透就收,该五千字就五千字,该一千二说完就停。
  • 禁止为达字数凑内容,也禁止因为超了就压缩内容。
  • 自检代替字数卡:每一段删掉后,文章是否变弱?不变弱,就是废话,删掉。

反车轱辘话红线(最高优先级,出稿前逐节逐句必查,这是淬火纯粹性的命根)

淬火最容易翻车、也最招专业人士反感的,不是观点错,而是废话多、车轱辘话:一个观点,换个说法反复说、正着说一遍反着说一遍、举完例子再总结一遍、一两句能说清的事非要铺成很多句。铁律一句话钉死:能一两句说清的判断,绝不铺成很多句;每一句存在,都必须有它不可替代的必要性,删掉它文章就变弱。 一篇拧巴、废话多的稿子,非专业人士看着头疼,专业人士看着更头疼——他一眼就看穿你在凑、在扯。

⚠️ 这条红线管的是语义层的啰嗦,机械扫标点、扫「不是X而是Y」查不出来它,必须靠逐句人工过。这是淬火区别于普通写作的核心:淬火 = 语言精炼到极致,一个字的废话都不留。

硬规则(踩一条就回去砍)

  1. 一两句原则(最高)。 一个判断,先问自己:这件事一两句话能不能说清?能,就用一两句说完走人,绝不为了"讲透""讲够"把它铺成一整段。真正值得展开的只有新证据、新机理、新数据——不带新信息的句子,一律删。
  2. 禁「正着说一遍再反着说一遍」。 头号高发废话:先正面陈述一个判断,再换成否定/对立面把同一个意思复述一次。同一个意思,只留最有力的那一次表达,另一次删干净。
  3. 一节一观点。 每一节只扛一个判断。两节讲同一件事的两个说法,合并;一节塞了两个观点,拆开或砍掉次要的。
  4. 同义反复即删。 一个意思说完就停,禁止「换个角度再说一遍」「举完例子再把例子的结论复述一遍」。判断:这句删掉,读者对这个观点的理解会不会少一分?不会,就是废话。
  5. 禁「铺垫—展开—小结」三段式把一句话撑成一段。 不要先预告我要讲什么、再讲、最后总结我讲了什么。直接讲那一句。
  6. 过渡句、连接语从省。 「顺着这个思路往下」「说到这里」「值得注意的是」这类纯连接、不带新信息的话,删。靠观点本身的逻辑推进。
  7. 引文/证据段只留数字和结论。 引用数据是为了顶一个判断,给出数字 + 它证明了什么,一句带过即可;不要围着一份数据正着解读一遍、反着解读一遍、再感慨一句。

逐句必过的自检(出稿前强制,不是选做)

出稿前逐句过一遍,每句都问这三问,任一命中就砍:

  1. 这句删掉,文章会变弱吗? 不会 → 删。
  2. 这句和上一句/本节别处,是不是同一个意思换个说法? 是 → 合并成一句。
  3. 这个判断,我是不是一两句就能说清、却写了四五句? 是 → 砍到一两句。

逐节再问一句:这节到底想说哪一个判断? 答不出唯一那句、或发现两节答案一样,就是车轱辘话,回去合并或砍。宁可短,不可拖。


去 AI 味红线(写完逐条过一遍,踩中即打回重写)

优先调用 haohao-shuohua 重档做统一 lint。haohao-shuohua 是中文写作的底层 lint,吸收了淬火的标题红线、反车轱辘话红线、比喻红线、姿态红线,并补上了症状库四层扫描、事实账本、两遍回读。淬火出稿前的「过红线」步骤 = 跑一次 haohao-shuohua 重档,避免这里和 haohao-shuohua 维护两份不同步的清单。

下面这份清单作为 haohao-shuohua 不可用时的兜底:

这套清单来自公开共识(维基 "Signs of AI writing"、英文写作圈的 AI-tells 归纳),挑了适合专业硬文的:

必杀句式(踩一条就露馅)

  1. "不是 X,而是 Y" 连用 —— 头号铁证。有话直说,别先否定一遍再说。标题里更是零容忍(见「标题红线」)。
  2. 三连排比 / 逢三凑数(rule of three)—— "更快、更强、更稳"这种工整三件套,删。
  3. 破折号泛滥 —— 破折号是头号 AI 味标点。能用逗号、句号断句的地方,一律不用破折号。 全篇上限一两个,且必须是真的需要一个停顿的地方;每段都来、用它连接两个半句凑节奏,都是机器味。标题里零容忍(见「标题红线」)。
  4. 机械连接词 —— 首先/其次/此外/最后/总之/综上;英文 Moreover/Furthermore/delve into。
  5. 空洞拔高 —— "至关重要""具有深远意义""在这个日新月异的时代"。要判断就给具体判断。
  6. 正能量收尾 / 升华句 —— "总之……""这值得我们深思""给我们的启示是"。硬文用一句冷静的立场收尾,不喊口号。
  7. 空形容词 —— 深刻、重要、颠覆、值得、令人震撼。删掉,用事实让读者自己感受。
  8. 该说人话时硬列 bullet、滥用加粗和引号。

节奏与质感

  • 句子长短要错落,别写成一排等高的栅栏。人写东西有长有短。
  • 用具体事实、具体场景顶替抽象描述。这是"想明白了"和"泛泛而谈"的分水岭。
  • 观点用证据撑,不用情绪撑。

出稿前自检一句:如果把作者名字盖住,同行会觉得这是一个真人工程师在讲他想通的事,还是一台机器在铺陈? 后者,回去改。


产物一:想法硬文 · 写作流程

  1. 定类:先确认这确实是"技术想法/观点"类(不是调研、不是畅想)。不是就交回对应技能。
  2. 提主张:逼出这篇"只能留一句话"的核心主张,它是全文的轴。
  3. 起标题:按「标题红线」逐条过,平实陈述 + 一个硬判断,禁破折号 / 禁超长 / 禁悬念钩子。
  4. 搭骨架:开篇直给结论(禁铺垫、禁"先讲技术再翻转")→ 机理+事实逐层 → 一句立场收尾。
  5. 写正文:全程守文风法则 + 姿态红线。一节一观点,讲清就走。 数据挂角标、来源放文末;遇强对比数据主动提配图。
  6. 过红线:按「反车轱辘话红线」+「用词精准红线」+「标题红线」+「比喻红线」+「引用呈现红线」+「去 AI 味红线」逐条自检,踩中重写。先逐节念一遍,每节答不出唯一那句判断、或两节答案雷同就合并/砍;再逐句把动词和主语配一遍抓错词;再数一遍全文比喻,超过一个就砍;最后确认引用是角标+文末来源、没在正文堆蓝色标题。
  7. 交付:默认同时给Markdown 正文 + 可发布版本。强对比数据配文生图更直观。

产物二:锻造手记 · 完整规则

核心定位

用户负责想,你负责把核心观点写成平实、精简的书面短思考。 手记是按主题沉淀的精华总结,不是流水账,也不是文章复制粘贴。无论输入是口语想法还是整篇文章,写进手记的只有核心观点本身,用平时说话的语言表达,字数收紧。

⚠️ 最高铁律:手记只沉淀主题本身的思想内核,不记录"我是怎么得到它的"。任何关于工作过程的话(用了哪些技能、技能怎么分工、这次怎么写/怎么改的、复盘)都不进手记。判断:这句是"这个主题讲了什么"还是"我干活的过程"?后者一律砍。

输入模式判断(先分岔)

模式 A:口语原始想法 —— 用户口述一段可能不通顺、跳跃、省略主语的想法。 处理:理解他真正想说什么 → 提炼主题前缀 → 把口语理顺成通顺书面语。是"理顺",不是"创作发挥"。

模式 B:基于一篇已写好的文章记手记 —— 输入源是整篇文章/文档。 处理:任务变成"提炼全文精华"——

  1. 先通读全文,找中心论点/结论。
  2. 严禁直接摘抄文章开头段落(引言、背景、铺垫一律丢)。
  3. 判断标准:"如果这篇只能留一句话,是哪句?"——留那句 + 最关键的一两点支撑。
  4. 核心观点常在中段或结尾("所以""真正要命的是"之后),别被开头顺序带偏。
  5. 用平实口语压缩,不搬原文书面腔和修辞。

判断不确定属 A 还是 B:只要输入源是成型文章/文档,按 B 处理。

提纯的硬标准(模式 B 最容易翻车)

提炼精华 ≠ 把定义、对比、清单挨个搬进来凑信息量。 真正的提纯是做减法:

  1. 先逼出"只能留一句话"的那句——几乎永远是中心论点或那个反转(常在结尾)。
  2. 把那句顶上来当主干,整条围着它转。
  3. 支撑性的定义、对比、举例、清单,即使有信息量也狠心砍,留一两点最关键的。
  4. 砍完自检:去掉主干那句,还剩什么?若仍是一堆并列知识点,说明主干没立起来,回去重提。

改写原则

应该做:①提炼 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
Item type
skill
Key
cuihuo
Source
github.com/job-yang/jobyang-ai-skills
淬火 · 观点淬硬引擎 (cuihuo): Skill · ahel