From iwatchme-skills
技术文章写作 skill。适用于技术深度文章、工具实战复盘、FAQ/Q&A、方法论、公众号长文等。触发词:写文章、写公众号、写博客、帮我写篇稿、按我的风格写、技术长文写作。不适用于:X/Twitter 短帖、小红书。
How this skill is triggered — by the user, by Claude, or both
Slash command
/iwatchme-skills:iwatchme-technical-writingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> 面向技术工程师的技术写作 skill。
面向技术工程师的技术写作 skill。 写作定位:工程师视角,技术精确、结构清楚、判断明确、实战痕迹重,不卖弄不端着。
技术文章的核心是三件事:
不是资讯搬运,不是情绪发泄,不是 AI 式的整洁废话,也不是为了"好看"去写花活。
让读者真的看懂、能拿去用、知道边界——不是让读者觉得作者很懂。
目标不是"每句都很满",而是"每句都推进理解"。
呼吸感不是抒情,是认知负担控制:
先记住一个结论:... / 到这里,你应该已经能区分 A 和 B。展开顺序:问题是什么 → 为什么值得看 → 先建立整体图 → 再下钻细节 → 最后给判断和边界。不是所有东西都要一次讲完,按读者的理解顺序讲。
【开头】直接交代问题、场景、文章任务
↓
【背景】为什么值得聊,读者能带走什么,需要哪些前置知识
↓
【主体】按 3 到 8 个板块展开,每块只解决一个问题
↓
【判断】把局部观察提炼成更高一层的理解
↓
【结尾】压缩结论、补边界、给后续阅读或行动建议
三句内必须完成三件事:这篇在讲什么、为什么值得看、读者看完能带走什么。
四种常用开头:
本文是 XXX 系列的第 N 篇,主要讲 YYY。上一篇发出去之后,大家最常问的是...开头禁区:
先建立整体图景。 / 到这里先记住一个区别。 / 下面再看这个结论是怎么来的。优先四种收法:
结尾禁区:
判断标准贯穿全节:删掉这个词/句之后,技术信息量有没有变化?没变化 = 填充,必须删。
见到即判不合格。同一个词可能在多类都出现——词库按被误用的语境分类,方便查。
大厂黑话/抽象职场词 赋能、闭环、底座、抓手、下钻、落地、对齐、沉淀、打通、串联、链路、心智、颗粒度、组合拳、护城河、矩阵、生态位、赛道、痛点、蓝海、红海、方法论输出、形成共识、统一认知、价值闭环、全链路、全局最优、打法。
汇报腔 先说判断、综上所述、一言以蔽之、直奔主题、值得重点关注、不难看出、显然、众所周知、总而言之、需要注意的是、可以看到、某种程度上、从某种意义上说、核心在于、归根结底、简而言之、总的来说。
网络梗与夸张情绪词 YYDS、绝绝子、破防、拿捏、上分、炸裂、封神、降维打击、赢麻了、核弹级提升、雪崩式炸裂、魔法般生效、一招封神、彻底颠覆一切。
AI 套话(清嗓/强调/填充/模糊四类合并,AI 最容易自动补出这类词)
AI 元叙述词(正文里讲自己的写作过程) 接下来我将、下面我们来看、让我们来探讨、我想说的是、我要强调的是、让我们来看看、接下来让我们、首先、其次、最后。
"不是 X 而是 Y" 这一族整篇文章最多 2 次,超过即 AI 味:
下面这些模式不是"谁都能判"的词,要带判断去改。示例格式:给错误写法,给修正写法。
底层解释:AI 味在根子上是翻译腔。AI 生成中文时像是先在英文句法里想清楚意思,再一个字一个字换成中文——每个字都是中文,语法也合规,但句子的骨架、主谓搭配、动词选择、段落节奏,全是英文的。下面很多模式都是翻译腔留下的具体痕迹,认出骨架来源比靠"语感"更稳——句子读起来别扭但挑不出单词毛病时,多半是骨架问题。
模式:不是 A,而是 B
问题:先否定一个读者可能没想过的错误理解,再给正确描述。直接说 B 就够了。
模式:误以为 / 很多人会以为 / 读者可能
问题:预设读者有错误认知再纠正。读者可能根本没这么想,反而被带偏。
模式:其实 / 更准确地说 / 更贴近现代 X 的理解是
问题:暗示前文不够准确。技术文章一次说对就行;觉得前文不准确就改前文,不要追加修正。
模式:你可以把 X 理解成 Y / 你可以把 X 先记成一句话
问题:把精确的技术描述包装成口语化比喻,降低信息精度。允许比喻做脚手架,不允许代替技术解释。
模式:先别急着 / 先记住一点 / 这里有一个关键点要讲清楚
问题:给读者设置心理缓冲,暗示"内容很难"。
模式:真正的 X / 真正 / 真的 / 确实 / 实际上(作为修饰语)
问题:这类词最容易逃过禁用词检查——单独看每处都"说得通",累加到全文就是典型 AI 味。
判断:删掉这个词,技术信息量有没有变化?
保留(有两个对照对象):
删掉(没有对照对象,只是强调):
section 标题里的"真正"全部按填充处理——标题最精练,对比关系放进句式,修饰词删掉。
全文高频自检:单一词命中 >= 5 次视为 AI 味,要压到 2-3 次——即使每处单独看都算功能性。靠改句式把强调藏进结构里,不要反复依赖同一个词。
模式:把思考过程、判断关系、状态描述成物理动作。
问题:英文里 catch a point / sharp argument / blow up / hold harder / break 都自然,因为英文背后有棒球、刀刃、物理崩塌这些生活经验。中文没有这套生活,直接翻过来的动词就"悬空"。
高危词库:接住、击穿、拆解、收口、承担、撑不住、不崩、不爆、打穿、打透、收紧、推开、扛住、立住、站稳、锋利、硬(作判断的"硬"度)。
规则:技术文章用中性动词——建立、呈现、展开、确认、得出、收到、记下、站不住、压不住。力量感是副作用,不是目标;靠准确说清事实。
问题:比词库里的"AI 元叙述词"更隐蔽——看起来在为读者指路,实际是 AI 在背诵结构模板。
规则:章节标题和段落顺序本身就是结构表达,不要再用正文元声明一遍。
模式:X 很 Y:[内容] / 更 Y 的 X:[内容] / 很 Y 的是:[内容]
问题:抢走读者自己评估的机会;形容词几乎总是多余;英文原型 Quite simply, ... 在英文里早被诟病为公文腔。
规则:直接把形容词那一节删掉,只留后半句事实。
模式:X 的 Y 比 Z 更 W / X 的 Y 是 W 的
问题:英文 The reality is uglier than... 的直译。
规则:让人、动作、或者具体对象做主语,让事实自己说话。
...。例如 // Several unrelated lines are omitted.**核心原则:列表不能是目录,必须是内容。**每个列表项必须自带信息增量,读者读完该项就知道"这是什么/为什么/怎么用"。
判断标准:删掉列表项后面的描述只留名词,读者会不会少知道什么?如果不会,说明描述不够。
| 图表类型 | 工具 | 代码围栏 | 适用场景 |
|---|---|---|---|
| 流程图/时序图/状态机 | mermaid | ```mermaid | 管线流程、时序、状态流转 |
| 分层架构图 | architecture | ```architecture | 系统架构、模块分层 |
| 数据图表(柱/折/散点/热力图) | vega | ```vega-lite | 性能曲线、对比、趋势 |
| 复杂依赖/调用图 | graphviz | ```dot | 类继承、调用链、模块依赖树 |
| 信息卡片/时间线/对比 | infographic | ```infographic | 效果对比、工具评分、方法论总览 |
| 思维导图/知识图谱 | canvas | ```canvas | 知识体系结构、概念关系 |
选择原则:能用 mermaid 的不用 graphviz;数据对比优先 vega;架构分层优先 architecture;公众号文章优先 mermaid 和 infographic(渲染兼容性好)。
人:给出主题、读者对象、自己的判断、真实经历、关键证据
↓
AI:整理结构、补参考资料、提出可读性优化方案
↓
人:补一手细节、删错的、改判断、压风格
↓
AI:按四层质检做检查,指出具体问题
↓
人:终审,确认准确性、边界、可发布性
写完后执行四层质检,任何一层不通过都需要修复后再检查。
命中即不合格:
真正|实际上|其实|根本|彻底|确实 做全文计数,单一词命中 >= 5 次视为不合格(按 3.3.6 判断标准压到 2-3 次以内)。通过标准:开头必须通过;4 项中至少 3 项通过。
通过标准:论据支撑和知识输出质量必须通过;其余 3 项至少 2 项通过(不适用跳过)。
核心问题:读完这篇,是一个有经验的人在认真分享,还是 AI 在批量输出?
通过标准:整体感觉"像是真人写的"。任何一项感觉"AI 味太重"就需要返工。
---
## 四层质检报告
**L1 硬性规则** pass/fail
- 禁用词:X 处命中(列表)
- 事实硬伤:X 处 / 无
- 格式:X 处不一致(含硬换行)
- 高频词:`真正` X 次 / `实际上` X 次 / ...(任一 >= 5 = fail)
- 结构性元叙述:X 处
**L2 可读性** pass/fail
- 开头、节奏、结构、读者视角:逐项 pass/fail
**L3 内容深度** pass/fail
- 论据支撑、知识输出、独创性、对立面、可执行性:逐项 pass/fail/不适用
**L4 活人感** pass/fail
- 温度感、独特性、姿态、心流:逐项 pass/fail
**总评**:4 层全部通过 / L1/L2 需修复后重检 / 建议人工复审
**最需修复**:[1-3 个具体问题]
约束:
用户让你"精修一篇已写好的文章"(不是重写,不是评审)时用这套工作流。
| 动作 | 精修 |
|---|---|
| 删冗余词/AI 填充词 | 可以 |
| 改一句话内的否定-纠正结构 | 可以 |
| 修格式问题(硬换行、中英文空格) | 可以 |
| 改单句表达(让它更直接) | 可以 |
| 删一个明显冗余的段落 | 谨慎 |
| 改段落顺序 | 不可以,属于重写 |
| 改章节结构 | 不可以,属于重写 |
| 改作者的技术判断 | 不可以,属于重写 |
| 补充新论点/新证据 | 不可以,属于重写 |
原则:精修只动词句,不动结构;只删冗余,不改事实;保留作者原有判断和表达习惯。
第一步:填充词 grep 初筛
真正|本质上|恰恰|其实|显然|众所周知|不言而喻
说实话|事实上|实际上|关键是|重要的是
值得注意|不得不说|需要指出
第二步:逐处按"功能性 vs 填充性"判断(标准见 3.3.6)——有对照对象、删掉会丢信息就保留;无对照对象只是强调就删。
第三步:翻译腔动词 grep(套路一,见 3.3.7)
接住|击穿|拆解|收口|不崩|不爆|打穿|打透|收紧|推开|扛住|立住|站稳|锋利|硬得|claim|catch
命中即判断"中文日常里会不会这样用",不会就换中性动词。
第四步:翻译腔句式扫描
X 很 Y:[内容] 的起手式(套路二,3.3.9)——冒号前是形容词评价就删X 的 Y 比 Z 更 W 骨架(套路三,3.3.10)——重写成具体主语 + 动作谓语context|state|cache|claim|runtime 等原样英文(套路四)——换成上下文/状态/缓存/断言/运行时第五步:格式扫描——硬换行断名词、section 标题里的填充词、中英文空格不规范。
第六步:逐一判断否定-纠正结构(3.3.1)——读者没预设那个错误认知就删否定直接陈述 B。
第七步:虚假引导语(3.3.5)和结构性元叙述(3.3.8)扫描——找 先记住 / 先别急着 / 这里要 / 本节只讲 / 放到下一节,逐个判断。
同样的 AI 味在不同位置严重性不同:
时间有限时先扫 1-3 档,4-5 档列在备注里交回用户。
遇到一段 AI 生成的中文读着别扭但不好改单词的——圈不出具体病句,但通读起来就是不对——这是骨架问题,不是词句问题。单词级别的精修修不掉,必须重写。
方法:
什么时候一定要走这一步:一段话圈不出具体病句但读两行就能认出是 AI——句句都能顺翻回英文——这是骨架翻译腔,只有重写能治。
什么时候不该走:原稿作者本来就是用中文骨架写的,只是偶尔有几个 AI 填充词——这种按正常精修走,别重写。重写风险是会丢掉作者的原意和原语气。
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub iwatchme/iwatchme-skills --plugin iwatchme-skills