cuihuo
Skill100 starsChanged 8 days agoMITView on GitHub
淬火:用户想就某个观点、判断、立场写一篇文章(「我觉得 X 是错的,帮我写篇文章」「写篇文章说说我对 X 的看法」「就这个观点写篇硬文」),写成直抒观点、专业克制、给同行看的硬文;或把一个想法/一篇文章提炼成≤120字锻造手记。门槛是有一个可被反驳的判断,不是技术词命中;没有观点的普通说明文不归这里。技术调研讲透走 feynman-explainer,畅想文走 tangshan-style,纯翻译润色不用本技能;纯删废话/精简已有稿走 sansi-erhouxing 共读 + haohao-shuohua 收尾。触发词:观点文章、说说我的看法、我认为、写硬文、观点文、直抒胸臆、专业硬文、淬火、一节一观点、记一笔、锻造手记;用户说「就这个观点给我写篇硬文」「把这个想法记一笔」时触发。
2 other projects use a version of this.
Adopted by
Most recently taken up by
- Job-Yang/jobbyang-ai-skillsword for word, first seen Nov 6, 2026
- Biancuihuo/cuihuo-skillstheir own version, first seen Jul 24, 2026
Other versions2 projects use a version of this.
Word for word · 1
- Job-Yang/jobbyang-ai-skills★ 100100% same
Edited · 0
None found.
Wrote their own version · 1
- Biancuihuo/cuihuo-skills★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository25 other files it gives its agents.
- ai-briefingSkill
- argument-readingSkill
- claim-checkSkill
- content-infographicSkill
- engineering-docsSkill
- feynman-explainerSkill
- haohao-evalSkill
- haohao-shuohuaSkill
- me-contextSkill
- minimum-experimentSkill
- opportunity-radarSkill
- opportunity-scorecardSkill
- outside-viewSkill
- png-compressSkill
- product-briefSkill
- reverse-teardownSkill
- root-rethinkSkill
- sansi-erhouxingSkill
- skill-library-keeperSkill
- steelman-choiceSkill
- style-compassSkill
- talk-smithSkill
- tangshan-styleSkill
- vddSkill
- video-readerSkill
The file
Files
淬火 · 观点淬硬引擎
这个技能是什么
对外做技术输出时的写作引擎。核心信念一句话:靠观点、靠想法赢得同行的尊重,技术是本质,行文是载体。 一切规则都服务于一个目的——让"说了什么"盖过"读起来怎么样"。
一套文风,两种产物:
| 产物 | 目的 | 篇幅 | 用途 |
| 想法硬文 | 把一个观点扎进读者脑子 | 参考区间 1200–4000 字,服从观点不凑字数 | 对外发布、发朋友圈、求职背书 |
| 锻造手记 | 把一个想法/一篇文章提炼成精华 | ≤120 字(≤80 字为宜) | 沉淀进个人笔记文档 |
两种产物共用同一套文风法则,只在篇幅和结构上分档。
何时触发(先分清这篇归不归淬火管)
对外内容分三类,各配一种文体,别串:
| 类别 | 目的 | 文体 | 归属技能 |
| 一、技术调研 | 把一个新东西说清楚,主动降门槛 | 费曼:大白话+比喻 | feynman-explainer |
| 二、观点想法 | 把一个观点扎进去 | 平实、克制、直抒胸臆 | 淬火(本技能) |
| 三、天马行空 | 把一个想象讲得让人愿读 | 汤山体 | tangshan-style |
| 四、技术分享 | 把一个技术/项目讲给读者听(有叙事弧、含 talk/slides) | 钩子+递进+例子+节奏 | talk-smith |
判断:这篇是要"讲清一个东西"(→费曼)、"扎一个观点"(→淬火)、还是"畅想一个未来"(→汤山体)? 淬火只接第二类,以及所有锻造手记。拿不准时,只要核心是"我要输出一个可被反驳的判断",就是淬火。
🔗 并行底层能力(不占三选一名额,涉及必调):
- 改已成形的稿子(精简某节、补一段、调措辞)而非从零起稿 → 先过
sansi-erhouxing(三思而后行)看全文骨架,判断这一处动它会不会破坏"一节一观点"的整体结构,再动笔。从零起稿可跳过。- 交付前 → 成稿交
haohao-shuohua(好好说话)重档统一 lint。它是中文去 AI 味与通用红线的唯一事实源;淬火的红线条目与它同源,判定冲突以它为准(声明见references/redlines.md开头)。- 技术调研 → 写观点前需要研究仓库、源码、论文或技术机制时,先读取
feynman-explainer及其范例,再检索分析;已有核实结果直接复用,观点和成稿仍由本技能负责。- 发布 → 观点和硬文由本技能定,飞书文档/公众号等平台技能只把定稿搬上去承载,不由它们决定写什么。
文风总纲(这是灵魂,细则全部下沉)
观点大于行文。专业且克制。给同行看,不关心外行门槛。直抒胸臆,有话直说。
姿态红线(最高优先级)
写作者私下的"我发现大家其实都没搞懂"只是写作的燃料,绝不能成为文章的姿态。同行最反感"我懂你们不懂"的味道,飘出一丝,前面所有硬货都打折。
- 禁止任何宣称式表达:"很多人没搞懂而我……""大厂/硅谷都没想明白,但我……""我早就看透了……"。
- 只做:呈现观察、摆出机理、给出证据,让读者自己得出"这人想明白了"的结论。
- 平视。你和读者是同一战壕的工程师,在一起把一个问题拆开,不是你在台上讲课。
正面骨架(想法硬文)
- 开篇直给主张或直给现象,不铺垫背景、不定义术语。默认读者是同行,看得懂行话。
- 靠机理 + 事实逐层推进,一层压一层,一节只讲一个观点,讲清就走;观点句直陈,撑观点的证据、数据、反例真有几条就列几条(列表或表格),不揉成一大段;一段 ≤ 150 字,纯段落不连排超过 3 段;比喻只在讲清一个难懂概念时才用,精确的东西直接精确地说,绝不套比方降门槛。
- 必须敢下至少一个可被反驳的硬判断。面面俱到、两边都对 = 没有观点 = 白写。
- 一句立场收尾,给同行一个会记住的判断。不升华、不号召、不"值得深思"。
- 标题(含每个章节小标题)严格守
references/redlines.md的标题红线——最容易露 AI 味 / 公众号味。
📖 四块硬规则(标题/比喻/用词精准/反车轱辘话)的逐条规则、正反例、自检三问,全部在
references/redlines.md——每次出稿前必读一遍。 带引用、强对比数据配图、或 haohao-shuohua 不可用需兜底时,另读references/assembly-notes.md。
产物一:想法硬文 · 写作流程
- 定类:确认这篇是"我要输出一个可被反驳的判断"(不是调研、不是畅想)。不是就交回对应技能——门槛不是命中技术词,是有没有一个可被同行反驳的主张。
- 提主张:逼出这篇"只能留一句话"的核心主张,它是全文的轴。
- 起标题:按
references/redlines.md标题红线逐条过——平实陈述 + 一个硬判断,禁破折号 / 禁超长 / 禁悬念钩子 / 禁「不是 X 而是 Y」。 - 搭骨架:开篇直给结论(禁铺垫、禁"先讲技术再翻转")→ 机理+事实逐层 → 一句立场收尾。
- 写正文:全程守文风总纲 + 姿态红线,一节一观点讲清就走。每节形状:观点句(加粗关键词)→ 机理短段 → 证据列表/数据表 → 一句收住。版式底线见
haohao-shuohua/references/reader-layout.md。 - 过红线(出稿前必读
references/redlines.md,顺序过六张单):姿态 → 标题(含每个小标题)→ 比喻 → 用词 → 反车轱辘话 → 去 AI 味(交 haohao-shuohua)。踩中重写。 - 交付:Markdown 正文;带引用按
references/assembly-notes.md挂角标 + 文末来源;强对比数据主动提配图。
产物二:锻造手记 · 规则
定位与最高铁律
用户负责想,你负责把核心观点写成平实、精简的书面短思考。 手记按主题沉淀思想内核,不是流水账,也不是文章复制粘贴。
⚠️ 最高铁律:手记只沉淀主题本身的思想内核,不记录"我是怎么得到它的"(用了哪些技能、怎么写的、复盘)。判断:这句是"这个主题讲了什么"还是"我干活的过程"?后者一律砍。
输入分岔(先分 A / B)
- 模式 A · 口语原始想法(不通顺、跳跃、省略主语):理解他真正想说什么 → 加主题前缀 → 把口语理顺成书面语。是"理顺",不是"创作发挥"。
- 模式 B · 基于一篇已写好的文章:先通读全文找中心论点;严禁摘抄开头引言/背景;问"这篇只能留一句话是哪句"——留那句 + 最关键的一两点支撑;核心观点常在中段或结尾("所以""真正要命的是"之后);用平实口语压缩,不搬原文书面腔。
- 判断不定时:输入源是成型文章/文档,按 B。
一个完整正反例(before → after)
before(口语输入,模式 A):
嗯今天想明白一个事,就是我们一直说 AI 写代码快,但你快了之后发现没人看你写的代码了,验收都变成跑测试,那人其实就从写代码退到去定义什么算好了,大概就这个意思。
after(成稿,约 85 字):
人从写代码退到定义什么算好 · AI 写代码越快,代码越没人看,验收全交给测试。人剩下的位置是标准的制定者:定义什么算好,而不是亲手写。
对照检查:主干判断来自原句、没加新事实;没写"今天我想明白……"这种过程性话;没有比喻、排比和升华;主题前缀本身带立场。
改写原则
应该做:①提炼 6~16 字主题前缀,要有判断/观点感,像微博标题让人一眼知道立场,不写"关于XX的思考";②口语转平实书面(补主语、补连接词、调语序、并破碎句、修错别字);③原意 100% 不变;④保留关键词、专有名词、独创提法(如"集体降智""聪明同行");⑤保留语气和判断强度;⑥遇 XXX/??? 是补全信号,按上下文自然补全。
不应该做:①不加 emoji;②不用任何夸张修辞(禁比喻、排比、对仗、反问、感叹、张力句式)——手记只要平实;③不加修饰性形容词(深刻、有趣、值得思考);④不加"我认为/我觉得"(除非原话有);⑤不加总结句、升华句、号召句;⑥不替用户做拔高;⑦不摘抄文章开头引言;⑧不写日期;⑨不因想法"不完整"就拒写;⑩不写过程性/元评论;⑪不做知识点复述凑信息量。
因果环不许砍(硬规则,提炼时最容易翻车的地方)
提炼只砍铺垫、举例、连接和修辞,不许砍因果环。 把用户原话拆成"条件 → 行为 → 后果"的链:链条上每一环——尤其用户亲口说出的那个负面后果或收益——都必须在 ≤120 字成稿里留得住。字数不够时优先压修饰词,不准丢后果环。
交付前自检:把成稿的因果环节数和原话对一遍,少一环就回去补。
反例(错:把后果环压没了):
原话:"PRD 写太全,研发照着做、不思考,出了怪需求也不知道为什么;写大概方向,研发自己补全,还会回来挑战你。" 成稿(错):
<b>PRD 写太细,研发不再想为什么</b> · PRD 边界写太全,研发照着做就行,不再想为什么。写大概方向,他们反而会补全。问题:"出了怪需求也不知道为什么"这个负面后果被压没了,剩下的只是"不思考"——用户最在意的那个代价丢了。
正例(同样短,但因果环完整):
成稿(对,正文约 55 字):
<b>PRD 写太细,研发不再想为什么</b> · PRD 写太全,研发照着做,出了怪需求也不查为什么;写大概方向,他们自己补全,还会来挑战你。对照:写太全→照着做→怪需求不查为什么(负面后果在);写方向→自己补全→回来挑战(收益在)。修饰词砍光了,一环没丢。
字数硬指标与自检
- 单条正文 ≤ 80 字为宜,最多 ≤ 120 字。写完数一遍字数:超 80 先砍一轮,超 120 说明没提炼干净,回去把主干判断之外的支撑再砍。
- 砍完自检:去掉主干那句,还剩什么? 若仍是一堆并列知识点,说明主干没立起来,回去重提。
落点约定
- 默认追加到当天手记文档末尾(用户已有的个人笔记文档),格式:
<b>主题前缀</b> · 改写后内容;多条各自独立成条,共享同一<ul>,或按文档现有结构用<h2>主题</h2><p>正文</p>。 - 用户没指定文档时:先在对话里给出成品,并说明"按惯例应追加到当天手记文档,把文档链接/路径给我就写进去"。
与其他写作技能的边界
- feynman-explainer:技术调研/把新东西讲透,走它,不归淬火。
- tangshan-style(汤山体):天马行空畅想文走它;淬火不写畅想。
- talk-smith:面向读者的技术分享文/talk/slides(讲清一个技术或项目、有叙事弧)走它;淬火只扎一个观点,不做带叙事弧的分享。
- haohao-shuohua:中文去 AI 味与通用红线的唯一事实源;淬火出稿前交它重档 lint。
- 淬火:可被反驳的观点硬文 + 所有锻造手记。
references 路由
| 文件 | 什么时候读 |
references/redlines.md | 每次出稿前必读:标题/比喻/用词精准/反车轱辘话四块硬规则、正反例、出稿前总自检 |
references/assembly-notes.md | 交付带引用的硬文、有强对比数据要配图、或 haohao-shuohua 不可用需兜底时读 |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

