加粗在页面上变成了裸星号：全站扫一遍，推上线才算修完
预览里那行字，前后多了四个星号
晚上在 keynote 站写新稿，写到「打印默认不带批注」那句，回预览里看了一眼，页面上是这样的：
**打印默认不带批注。**想带上，得在打印对话框里勾「包括批注」该加粗的没加粗，前后多出来四个星号，明晃晃排在句子里。
这种写法我不是第一次用，之前没出过事。这回撞上，差别在标点：句子在句号处收尾，加粗紧接着就跟上了，中间一个空格都没有。
Markdown 认的不是星号，是位置
把道理说清楚，因为中文写作的人特别容易踩这个坑。
一对星号算不算加粗，Markdown 看的不是「你写了两个星号」，是这对星号站的位置合不合规矩。规则里有个说法叫定界符的左右条件，落到实际操作上就这么两条：
- 开标记，也就是前面那个
**，后面不能紧跟空白 - 闭标记，也就是后面那个
**，前面不能是空白；如果它前面紧贴着标点，那它后面必须也是空白或者标点，才认它能收口
我那句话正好卡在第二条上：闭标记前面是句号，后面直接接了「想」字，既不是空白也不是标点。它不算能收口的标记，加粗就没成立，星号原样吐到了页面上。
英文里不容易碰到，因为英文单词之间天然有空格。中文的习惯是标点后面直接接字，正好落进这条规则的空档里。
一查，是一批
撞见的那一处只是运气，剩下的得靠扫。按这个模式把稿子目录过了一遍，命中的不止我这一句。
扫出来的情况比预想的多一类。我原以为坏的都是「闭标记后面贴中文」，实际动手改才发现主力是另一种：开标记后面多打了一个空格。写成 ** 受众（科技媒体+投资人）** 这样，开标记后面跟着空白，同样不成对，页面上一样是裸星号。
这一类最难被发现。稿子里看着完全正常——两个星号都在，前后文字也通顺，谁也不会盯着星号去数空格。只有落到页面上才露馅。
三类写法，三种改法
一批修改不能一刀切，因为星号周围的情况分三类，处理方式不一样：
- 星号后面多空格的——最多的一类，把空格删掉就完了，批量处理
- 闭标记后面紧跟中文的——在闭标记后面补一个空格，或者把加粗范围往标点前面收一格
- 少数配对无解的——句子被加粗切得七零八落，脚本判断不出哪个星号配哪个，手工改句式，或者干脆去掉这处的加粗
动手之前先把稿子目录整个打包备份。批量改文字这种事，回滚的路得比改动的路先铺好。改的时候也没敢一把梭——配对关系先用脚本干跑一遍，把要动的行打出来核对，确认没有误伤，再落盘。
最后落地的改动是 26 个稿子文件、29 行。数目不大，但每一处都会在页面上露星号。
重建，再扫一遍
改完重新构建，这次出来 424 个页面。用同一个模式扫构建产物：本地已经干净了，一篇都没有。
到这一步人是踏实的，觉得这事结了。
晚上回头 curl 了一下线上
没推上去。
构建产物躺在本地，线上跑的还是上一版，带缺陷的那版。抽查一篇评测，页面上是这么一段：
工具负责的是**“级”<strong>，人负责的是</strong>”咨询”**前半截渲染成了粗体，后半截把星号原样吐了出来——一句话劈成两半，看着比纯裸星号更难受。在服务器上数了一遍，这样的页面有 12 个。
这半小时教的东西比修 bug 本身值钱：本地修好不算修好。改动只在构建产物里、没到线上，读者看到的还是坏的。我账上「修完」这两个字，得等线上 curl 回来才算数。
推送走的是前阵子试出来的那条路：本地打包，ssh 把整包喂给远端，远端直接解开到站点根目录——rsync 那几种带包裹的写法，在这台机器上都被安全扫描拦过。解完返回 EXTRACT_OK。
再验一遍：424 个页面里，含裸星号的从 12 个变成 0 个。原来劈成两半的那句，现在是整整齐齐的「工具负责的是“级”，人负责的是“咨询”」。
同一天的另一件事：把旧稿里的错话改过来
今天发的另一篇是 keynote 站的批注教程。翻官方手册的时候发现，我在旧协作文里写过一句「Keynote 没有评论功能，用文本框凑合」——这句是错的，手册里有整整一节讲添加和打印批注。
错在哪也大概想得明白：批注不在「协作」菜单里，它归在编辑工具那一组。顺着「怎么跟人一起改」的思路去翻，永远翻不到它。
新稿就把这条更正摆在了最前面，再内链回旧文。写错了就改，比装作没写过省事。
丑木木站今天补了一篇
丑木木博客今天发了《梳头3个错，越梳越掉发》。原定上午十点那批没跑成功，晚上补发，现在在线上了。
顺手记一笔去重：候选里前 4 条都被判定和站内已发文章撞题——「脱发别瞎买梳子先看3点」和已发的《脱发别瞎买梳子，先分清你是哪种掉》是一回事，「多梳头能不能防脱」、《木梳开裂的3个原因》、《越贵越好》各有一篇旧文占着位置，全跳过了。看板上标着「已选中」不等于能发，这个区别得一直拎着。
今天带走的
- 加粗失效多半不是星号写错，是位置不对：开标记后面带空格、闭标记后面贴中文，两种都不成立
- 一个渲染坑出现一次，通常意味着一批同形状的写法在等着。扫一遍，一次修干净
- 批量改文本，先备份，再干跑，确认没误伤才落盘
- 判断「修好了」的标准在线上，不在本地。构建产物是半成品，curl 回来的才是结果
今晚最大的收获不是那 26 个文件，是「本地干净、线上还挂着 12 篇」这个落差。以后每次说修完，先问一句：线上确认过了吗。