00.范式-软件工具介绍

本文件是 03.应用-05.工具推荐 的作者侧写作规范，用来约束命名、价值观和结构。
正式对外的工具介绍正文，禁止出现对本文件或同目录其他文章的任何引用（详见下方「绝对禁区」）。

命名约定

文件名格式：

{场景类型}-{用途类型}-{工具名称}-{工具简介}.md

字段	约束	说明
场景类型	≤4 字	工具主要工作的环境/语境
用途类型	≤4 字	工具完成的核心动作
工具名称	官方常用名	专有名词保留英文大小写
工具简介	短句摘要	一眼看出「干什么」，避免广告词

场景类型词库（优先复用）：跨机 / 本地 / 终端 / 数据 / 运维 / 开发 / 协作

用途类型词库：挂载 / 传输 / 同步 / 编辑 / 监控 / 检索 / 打包 / 终端

示例：跨机-挂载-SSHFS-远程目录本地化.md

核心价值观（贯穿全文）

这些价值观决定文章底色，写的时候要时刻绷着：

讲人话，像个活人。
AI 时代最稀缺的是「活人感」。不追求滴水不漏的客观腔。分享亲身经历、真实感受、踩过的坑。大胆用「我觉得」「我认为」。拥抱不完美。

真诚是唯一的捷径。
可以不写，但绝不骗人。产品有缺点就直接说，不懂就大方承认。读者信任比「写得很全」值钱。

分享真诚，别掉书袋。
少堆专业词。主要目的是让人看懂这工具能干啥，对照一下自己是不是也有这个痛。深度原理能省则省，真要写就「聊着聊着顺手掏出来」，别摆出「下面开始科普」的架势。

推荐要有条件。
活人感不等于乱吹。适合什么、不适合什么都要写。禁止「最佳 / 秒杀 / 一劳永逸 / 必装」这类绝对化。

风格内核

节奏感

像跟朋友聊天，不像写报告。句子时长时短，多用逗号制造口语停顿。段落之间跳跃自然，关键句经常单独成段砸重点。

节奏是推进系统：围绕主线偏出去一点点（喘气、长见识、看个案例），再用一句「扣主线句」拉回来。最糟的是偏出去老远再硬拽，读者得花脑力顺逻辑，心流立刻断。所以写的时候习惯性加扣主线句——不用长，一句够，但要高频。

知识输出方式

知识是「聊着聊着顺手掏出来」的，不是「下面我来给大家科普一下」。看起来像脑子里本来就有这些东西，正好跟眼前的事对上了。

情绪与人称

• 可用「。。。」拖长/震惊/无语/遗憾；「？？？」极度惊讶；「= =」吐槽。这些是情绪，不是语法。
• 允许自嘲（「愚钝如我」等），允许直接兴奋。
• 亲自下场：让读者感觉「这个人真的做了这件事」，不是在想象做这件事。
• 读者直呼法：关键节点才用（「屏幕前的你」「你也可以回想一下」），通篇狂喊会腻。

推荐口语化词组（自然用，别硬塞）

• 转场：坦率的讲、说真的、怎么说呢、其实吧、你想想看、我跟你说、回到 xxx 这块、顺着上面的再聊聊
• 判断：我有时候觉得、我一直觉得、不是说 xxx 不行而是说、我自己的感受是
• 承认：说实话我也不确定、我自己也还在摸索、这个事儿我也踩过坑、我说「理论上」是因为我自己还没完全跑通
• 拉近：很多朋友可能不知道、可能有小伙伴纳闷、你如果也经常 xxx 的话

目标是读起来像真人聊天，不是每句都贴标签。

绝对禁区

正文互引禁令（硬性）

具体工具介绍文章中，禁止出现：

1. 指向同目录其他文章的链接、相对路径、文件名提示
2. 「结构说明见 xxx」「按范式写作」「详见同目录 00.范式…」「参考上一篇」等元写作提示
3. 把写作规范、目录规划、命名约定写进读者可见正文

范式只给作者看。读者打开的是一篇独立能读完的分享，不是系列教材目录页。

外部官方文档、GitHub、厂商手册可以链，那是资料，不是「本目录互推」。

AI 味禁区（硬性）

1. 套话：禁用「首先…其次…最后」「综上所述」「值得注意的是」「不难发现」「让我们来看看」「接下来让我们」
2. 高频踩雷词，绝对禁用：
   • 「说白了」
   • 「意味着什么？」
   • 「这意味着」
   • 「本质上」
   • 「换句话说」
   • 「不可否认」
3. 假设性编造：「比如有一次…」这种编场景是大忌。要用「就像我今天正在搞的 xxx」这种正在发生的真实细节。没有真实细节就别硬编，宁可写「我自己还没试过，但想想就觉得 xxx」
4. 空泛工具名：不说「AI 工具」「某个模型」，要说具体名字
5. 教科书开头：禁止「在当今…快速发展的时代」「随着技术的不断进步」。永远从一个具体的、当下的事件或场景切入

开头：场景案例是切入契机（必写）

开头永远绑定这款具体软件，用一个真实、当下的问题当引子。模板气质（不是填空题，是节奏）：

最近碰上 xxx 麻烦 → 折腾了常规办法还是别扭 → 摸到 / 想起 {工具名} → 试了一下感觉值得记一笔 → 分享给可能撞上同款坑的人

几种常用起手（涯途味）：

• 叙事启动：「事情是这样的。」「故事是这样的。」
• 荒诞事实：先丢一个让人「？？？」的细节
• 热点 / 当下破题：「这两天…」「今天我正在…」
• 好奇心驱动：「刷到 / 搞到一个…，挺有意思。」

禁止：宏大叙事、产品说明书第一句、先甩定义再讲故事。
定义可以跟在场景后面，用一两句人话带过：「它干的事其实就一件——把远端目录挂到本地路径。」

推荐结构（场景开头 + 后续段落）

新稿默认顺序如下。可按工具裁剪，但 场景开头 / 适用 / 不适用 / 有条件结论 建议都有。标题可用口语，不必机械编号。

0. 场景契机（开场）

具体问题 + 为何需要这工具 + 为何此时分享。亲自下场，带一点情绪和真实细节。

1. 人话定位（可并入开场末尾）

一两句说清「它是啥、解决啥」。缩写首次出现按项目体例给中英文全称；段末可用引用块短注，后文沿用缩写。

2. 我觉得适合啥时候用

3–6 条可对照的情境，优先自己踩过的。扣主线：还是为了解决开头那个「远端文件别扭」类问题。

3. 啥时候我建议你别用

对等写边界。有坑直说。维护不活跃、断网挂死、慢、不能当生产盘——该泼冷水就泼。

4. 原理（能短则短，可省略）

真要写，就「顺手掏」：一两段或一张极简链路，帮人判断故障大概出在哪层。禁止开课。

5. 我怎么装、怎么跑通最小路径

主流平台安装入口 + 一条能挂上的命令 + 怎么卸。默认普通用户。踩过的坑写进去。

6. 真用起来我会改的几个选项

只收显著改善体验/稳定性的（保活、重连等）。每项用「我为啥加它」而不是参数说明书口吻。

7. 跟别的办法怎么挑

2–4 个具体替代（rsync、NFS、IDE Remote…），表格或短对比均可。按条件选型，不排名踩一捧一。

8. 限制、风险、我不确定的地方

维护状态、故障表现、安全注意。不懂就承认。以官方文档为准可一句带过并外链。

9. 有条件的收束

2–4 句：什么前提下我愿意推荐；条件不满足指向哪类替代。语气像聊天收尾，不是「综上所述」。

质量自检清单

写完过一遍：

• 文件名四段齐全，场景/用途均 ≤4 字
• 开头是具体当下场景，无教科书空话
• 正文无同目录互引、无「见范式 / 结构说明见」类句子
• 无套话与踩雷词清单中的表达
• 有真实细节或诚实承认「没试过」；无编造「比如有一次」
• 有「别用」边界；推荐结论带前提
• 工具名具体；命令可复制
• 读起来像聊天推进，关键处有扣主线句
• 缩写体例符合项目约定；front matter 的 title 可检索对应

与其他目录的边界（作者备注，勿写入工具正文）

文类	放哪里
单工具推荐	本目录，按命名约定
多工具横向对比	对比-{用途}-….md 或独立综述
云厂商专项实践	03.应用-09.* 等
领域软件测评（NGS 等）	03.应用-01.software_in_NGS 等既有体系

作者写新稿：先选词库命名 → 用真实场景开场 → 按结构聊完 → 用本清单自检。读者侧应只看到一篇自洽的分享。