作者声明

本文场景、出场人物与具体内容均为虚构，如有雷同，纯属巧合。

新中旧教学楼要拆的消息，附在几张照片后面，字很少。

照片里，脚手架沿着外墙一层层搭上去，走廊的绿栏杆缺了一段。我认出三楼靠西的那扇窗：玻璃少了一块，另一块上还留着白色的水痕。从前轮到我值日，我站在椅子上擦它，湿抹布来回擦过几遍，看着已经干净了，等水一干，那些浅浅的印子又浮出来。

如今窗后的教室空着。等屋顶也被拆去，雨便会落进我当年坐过的地方。

我把照片放大，看了很久，才起身去拿书架深处的纸盒。

纸盒原是蓝色的，随我搬过几次家，如今褪得很淡。四角补着透明胶带，有一角已经翘起来，沾着灰。每到一个新住处，我总先替它找个不容易受潮的地方。里面是她的来信，还有我留下的去信底稿。信封的封舌起了毛，几片褐红色的封蜡散在盒底。

我将最上面的一张放到灯下。折过的地方已薄得有些透光，字却仍清楚。写下它们时用力太重，有几个笔画，隔着纸背也能摸到。

秋天迟来的学生

我回到宏谭镇时，桂花已快开尽。

宏谭在西南边陲，山一重重围着，镇前有条河，入冬以后水浅，露出河心灰白的石头。去县城的班车每天只有几趟，清晨停在桥头，司机开着门，等拎菜篮的老人慢慢走过来。老街沿河伸出去，修表铺、药店、邮局，隔不了几步便是一家。下雨时，每间铺子的雨棚都有自己的漏处，住久了的人经过，知道在哪儿稍稍偏一下肩。

江新中学在镇东的缓坡上，人们都叫它“新中”。旧教学楼背靠着山，楼下几株桂树挨着洗拖把的水池。花落了，细小的黄点贴在湿地上，有些顺水走了，有些留在砖缝里。下午，山影已经盖住操场，三楼的窗仍能留一阵太阳。

返校那天，我沿走廊走得很慢。里面的人正低头写字，偶尔有谁咳嗽，声音隔着门传出来，比脚步声还清楚。到了拐角，一片叶子黏在鞋尖，我弯腰去拂，书包却从肩上滑下，碰翻了墙边的水桶。水在地上铺开。我蹲下来扶好桶，把带子重新拉上肩，一时竟不愿站起来。

以前熟悉的人大多已经毕业离开了。

我个子高，被安排在教室后半部。周围的人都不熟，椅子又有一条腿稍短，挪一下便响。我整天留意着这点声响，每次挪动身子，都先把手撑在桌沿。

夏卿卿坐在靠窗的那一列。

起初，我常看见她用尺子压试卷。她将尺子横过来，拇指顺着纸边一抹，卷起的角便服帖了。有时窗外的光挪到她手上，她就把卷子往里收一点，继续写。那时候，看别人做这些细小而笃定的事，我也会羡慕很久。她偶尔抬头，撞见我的目光。我立刻低下去，装作找笔。笔其实就在手里，被我握得发热。

后来，我想到了那件一直没送出去的裙子。它原是为家中一个妹妹准备的，叠在柜子里，浅色的裙摆一铺开，便占去半张床。我将它取出来，抚平折痕，心里已经备好许多理由：夏卿卿像她，衣服应当合适，搁着又可惜。想着想着，竟觉得这是一件再自然不过的事。

可真要开口时，我仍不敢。

中午放学铃响，她在前面收书，我把装好的袋子提起来，又放下。一直等到教室空了大半，我才草草用便签写了两行英文。那两句话短得几乎不必修改，我却读了许多遍，连一个寻常的词，都渐渐看得不认得了。

午饭回来，我就看到书下也压着一个便签，写道

读完便签，我心里骤然冷了一半；但仍不死心，又拿了一张纸，想把送裙子的缘由说清楚。

放学前，我有幸的收到了她的回复：

她终于收下了。我将袋子递过去的情形，后来记得已经不很真切，只记得空下来的手，一路都不知道往哪里放。

当然，我一直没有见她穿过那件裙子。

接下来的日子，她仍旧在课前翻书，课后收卷子。困了就趴下睡一会儿，铃声一响，抬起压红了的脸，皱着眉找笔。有一次，笔滚到两排桌椅之间，我的椅子刚响了一声，她已经弯腰捡起来了。

我又坐回去，把一页没有看完的书翻了过去。

一张照片

秋天快过去的时候，我总把相机带在身上。

山里的雾散得慢，晴天到了上午，河对岸的屋顶才一片片亮起来。有人把洗好的衣服挑到竹竿上，水从裤脚滴下去，墙根便深一块、浅一块。我常站在窗前等，等鸟离开电线，等云影走过山坡，等一件很小的东西恰好出现在光里。

有一天，我将镜头转向了教室里面。

她没有看我。快门轻轻一响，恰好有人翻书，把那点声响盖过去了。我低头看屏幕，画面中的一切都显得安静，连远处一张歪着的课桌，也像是应该在那里。

我独自高兴了一会儿，心想着把这张照片送到她手上；随即也有些不安，担心这样又破坏了什么所谓的“距离感”。

于是我写下“道歉”，附上照片。发送前，又将她的名字后面补了“同学”两个字，觉得这样郑重一些。那时我能想到的周全，大多就是如此。

也是当天，我就收到了她的答复

我先记住了她写天空和花木的那几行。放学经过楼下的桂树，还停下来，看了看枝间所剩无几的花。可再打开回复，开头那几句仍在原处，绕不过去。

我把相机收回袋子。拉链有些涩，在半途卡住，我低着头拉了两下，才拉拢。夏卿卿还在收拾课本。我走出教室，没有留下来等。

回到住处，我删掉相机里的照片，又取出存储卡，找到了原片。确认框出现时，我的手停了一会儿，最终还是没有按下删除键。后面一张河岸的照片移了上来，水面很亮，我却已经看不进去了。

后来，我仍拍过许多东西：旧水管上将落未落的一滴水，雨停以前颜色很深的山，门卫室灯下斜靠着的一把扫帚。走到她那一排座位附近时，相机留在袋里。我能听见肩带上的小扣随着脚步，轻轻碰着拉链。

纸盒里，与这份誊录挨在一起的，还有一张更小的纸。

那阵子，我常带自己做的吃食去学校。休学时，我在厨房里学会了一些事：面团要等，糖融到浅金色时火须调小；偶尔做成一回，整间屋子都有暖的气味。回到新中，我仍想借这些本领，让自己不至于在人群里全无用处。

分给别人的，我可以随手一递。给她的那一份，我却常在出门前拆开重包，挑一个不容易碎的放在最上面。

有一回，我将纸袋放进她桌侧的书袋，想这样便不会引人注意。后来拿到那张小纸条，我先看见的，是开头那句谢谢。

我把纸条摊在掌心。字不多，纸却已经被我折过两次，展开时总有一角翘着。

午休，我去操场边坐了一会儿，吃掉原本留着、还想再带给她的一份。糖已经凉透，比在厨房时硬了些，咬下去，碎屑落进袋底。我将纸袋抬高，想把最后一点倒出来，弄了半天，袖口也沾上了。

围墙外有人推车经过，车轮碾着碎石，响了一阵，便远了。操场那么空，我在那儿坐到预备铃响。

借来的勇气

十一月，我恰巧读到一篇短篇小说《破碎故事之心》。越读越觉得神奇，故事里的人物、情节、语言，都像是从我身边的生活里抽出来的。我取出纸，写了几行，觉得每一句都太重，便撕掉了。第二次写，我先告诉她自己读过什么。借着那个故事，有些不敢当面说的话，似乎终于可以开口。

从这封信起，我渐渐养成了留底稿的习惯。誊清时删掉的句子、还没改好的字，留在手里，倒比送出去的那一份更长久。

装进信封以前，我还给她裁了几张同样的纸，四角对齐，夹在信后。那句“不指望你会回信”明明是自己写的，放进回信用纸时，我却一点也没有迟疑。

接下来的四天，我忽然很会听教室里的细小声响。她拉开笔袋，我抬一下头；她折起一张纸，我便把眼前的书往后翻一页，仿佛自己并未注意。到了晚上，又后悔白天太留意她，猜想那些笨拙的掩饰是不是全被看见了。有时我已经把书包收好，听见后面仍有人说话，便又取出一本书，装作还有什么没看完。直到那一排桌子空下来，我才起身。

木香未开

十一月十二日，信在我的课本下面。

抽出书时，它被带出来一点，我先看见那道斜折的纸角。伸手去拿，手指却从纸边滑了过去。我把书放回桌上，重新取了一次，才把那几页薄纸拿稳。

窗边有人叫她一起去交作业。她抱起一摞本子，走到门口；我等她走出去，才低下头。

第一行便是她替我的那点掩饰起的名字。

我笑了一下，嘴角还没落下去，就下意识地望向窗边。她的座位空着，桌上压着一张做了一半的卷子。

这封信我读了三遍。头两遍找能使自己高兴的字，读到“朋友”，便停一会儿；第三遍，才慢慢读到她会打人、骂人，也会说别人的坏话。那几句话将我心里那个总是安静坐着的影子挪开了一点。再看窗边的空椅子，忽然觉得自己知道的实在很少。

我把信收好，没多久，又拿出来。

一到家，我就搜了搜她所说的木香花。照片从上往下一点点显出来。花开得细碎，白的、浅黄的，挤在一根枝上。我用手指把它放大，看过叶子，又去看花期。十一月的屏幕上已经满枝是花，窗外的风却正吹得人缩起脖子。

我想过买一株，商品页开着，迟迟没有往下点。信上说她家里已经养了两盆。我关掉页面，重新读了一遍那句不很郑重的“甩香”。

那晚，我听了听她写在信上的歌。手机伏在枕边，光调得很暗，耳机线从被角垂下去。楼下有人洗衣服，接水声从歌曲的间隙里进来。我有几次差点睡着，又在换歌时醒过来，伸手摸一摸手机，看清歌名。

第二天，在教室门外，她抱着书从人群中挤出来，书角轻轻碰了一下我的袖子。她侧身，我也侧身；让到同一边以后，两个人又各自挪开半步。那一小段路总算让出来了，她便抱着书过去。

我回到座位，抚了抚袖口，取出纸。其实有许多寻常的话可以说，我却还是从她信上提到的小动物写起。

信纸背面

她写了几首歌、两盆花和喜欢的小动物。我也翻出歌单，想着把自己的事告诉她。写着写着，一页纸又添了一页。

写到小七，笔慢了下来。我记得它小时候伏在门槛上，整个身子晒热了，摸起来像刚从太阳下收回的一件厚衣服。可要说它如今的模样，我却写不出来。我去翻相册，翻网盘，却关于它的照片也少得很。笔搁在纸上，积出一个很深的墨点。我换了张纸，接着写下去。

这封信的底稿，末尾还留着两段。我誊清时没有将它们抄进去，只在前面标了“弃用”。那时我已经写得太多，又还想让她觉得，自己是个可以轻松相处的人。

信写完了，我仍在桌前坐了很久。

我把一滴蜡落在信封折角，手抬得迟了，蜡便多出一些。印章压下去，边缘溢出一个不匀的圈。我俯下身看，想修齐，又怕碰坏，只好等它一点点凉透。

等的时候，我想到她要怎样拆开它，会不会觉得麻烦；又想，只要拿到信，总归要拆的。这个小小的念头，使我在灯下无端高兴了一阵。

纸、贴画、封蜡，还有试写的字，慢慢占去书桌大半位置。对面人家的窗一扇扇暗下来，我这里还亮着。将一处折好，再将另一处压平，一夜便可以这样过去。白天没能说成的话，在夜里似乎都有办法安顿。

几天以后，教室换座位。我的桌子离窗更远，夏卿卿移到前面。过道窄，她试了两次，又用膝盖抵住桌脚，将那张沉重的桌子挪过去。我已经拿起书包，想着腾出手去帮她；等书包放好，她也坐下了。

我将桌上的书叠整齐。先前那扇窗被另一排人挡住，往后再抬头，只能看见她椅背上搭着的外套。

雨从山里来

宏谭的冬天，是跟着一场雨来的。

雨接连下了几日，山顶不见了，晾在屋檐下的衣服总有一点潮。清晨到学校，伞上的水滴了一路，脚印从楼梯一直深到教室门口。大家挤在走廊上等开门，把冷手缩进袖子。

夏卿卿站在前面，摘下眼镜，擦掉镜片上的水珠。我想问她冷不冷，话在嘴边停着。想好怎样问以后，又觉得这话无须问：她也正将手往袖里收。

门锁响了，前面的人开始往里走。我跟着人群迈过门槛，给她让开一点地方。

十一月二十二日，回信到了。

我还以为自己会像上一次那样，一见她的字就先笑起来。打开信时，窗玻璃正被雨水慢慢淋花，教室里很安静，前排有人轻轻咬着笔帽。

我将信翻到背面。薄纸透出些墨色，远看像写了另一封信，却没有哪一个字能辨认清楚。我用掌心将纸压住，等了片刻，才重新翻回来。

有几句读得太快，仿佛眼睛一掠过去，便可以不算看见；有几句又看了许久，慢到身旁的人翻了几次书，我还停在同一处。

放学后，我没有去阅览室。回到住处，开了听歌的软件，又关掉。耳机留在手里，缠好，松开，再缠了一回。屋檐下的雨水不停，窗缝里有风，吹得桌上那封信轻轻动了一下。

她说不喜欢我的一些称呼，说不愿看那些经历。那一天，我所能听见的几乎只有这些。直到再读，才看见她也写了考试，写了疲倦，写了那一百多天如何压在心上。

道歉之后

十一月二十七日，桌上又多了一封信。

前一夜，我还写过几句委屈的话。有的写完立即划去，有的留着，第二天早晨看又觉得过分。草稿折在书里，一整天，书都没再打开。

这封新来的信比上次短。我拿在手里，先以为她还有什么要补充，读到第一句，指尖却松了一下，纸页往掌心滑了滑。

她说可以做同学，或者朋友。我把这两个词挨着读，觉得哪一个都并不坏。可想到明天在走廊上见面，仍不知道该怎样叫她。

晚上，我打开消息窗口，写下“没关系”，又删掉。添上去的话，也没能留下。我按灭手机，取出纸。纸上的话可以重写，也可以停着。我仍以为，多给自己一点时间，就能把它们说清楚。

那封原本想写得简短的信，到了半夜还没有写完。

誊完最后一个字，右手中指上蹭着一片蓝墨。我去洗手，水流过指节，蓝色淡了些，仍不肯全退。

回到灯下再读，有几句太用力，有几句绕得连我自己也费解。我提起笔，想改，最后只描清了一处不太容易辨认的字。那时还不明白，哪些话值得说，哪些只是怕对方不知道自己难过。

第二天，信封到了她桌上。我转身回座位，听见身后有人拉开椅子，没有回头。

那以后，卷子仍一张张发下来。日子也渐渐平淡而重复着了。

回音的消失

我又送了她一个小挂件。包装纸裁得很小，接缝朝下。我以为这样便不显得郑重。

包装纸裁了又裁，我尽量包得小，让它握在掌心时不显得郑重。胶带在接缝处留下一道亮痕，我用指腹压了两遍。送到她桌边时，我把那条接缝朝下，像这样放好，便能少给她一点为难。

十二月十一日，我收到了回赠。东西装在一个寻常的袋子里，袋口折过两次，压在书下面。我拿起来，先看见夹在里面的纸边。回到座位，我把袋子放进抽屉，怕压皱了信，便单独将它抽出来。

读到“结尾”时，我停了下来。

前排有人转身借橡皮，我从笔袋里拿给他。隔了一会儿，他还回来，随口说了句谢谢。我点点头，等他转回去，才重新低头看信。

从头读到落款，也没有花去多少时间。窗外的山影已越过操场，桌边最后一点太阳落在手背上，慢慢退到指尖，随后也没有了。

我沿着原来的折痕，把信折好。第一次没有折齐，露出窄窄的一边，便又打开，重新对了一次。

那晚，我仍取了一张新纸。名字写在左上角，后面是一个冒号。再往下写什么，我想了很久。隔壁的人拖动椅子，开水壶响起来，又停了。我手里的笔一直悬着，直到笔尖上的那一点墨快要干了，才将笔帽合上。

那张纸没有送出去。后来做题时，我在它的背面写过半页算式，随后就丢到了废纸篓里。

毕业以前

冬天很长。早晨仍有人迟到，提着没拉好的书包跑进来；中午，热水机前照旧排着队；测验开始，窗缝里的风将最外侧的一张卷子吹得微微翘起，写字的人伸手一压，便继续往下写。

我的椅子后来稳了。哪天有人在桌脚边收拾，顺手垫了一片东西，我竟没有留意。等到发现，已经记不得它从什么时候起不再响。我试着往后靠了一点，又往前坐好。

我和夏卿卿还在同一间教室里。她去交卷，从我身旁经过；值日时，我将公共练习册往前传，她接住，再交给前面的人。有一天，全班为一件小事笑起来，我听见她也笑了。那声音混在许多人中间，并不容易分清，我却在低头的片刻，也跟着笑了一下。

春天来的时候，我们还穿着冬衣。

围墙外的李树先白了一片。雨水多起来，河面渐渐涨高，湿气沿坡路漫进学校，卷子压在书里，取出来边角仍是软的。课间有人展开地图，找自己想去的城市。手指越过熟悉的省界，停到很远的地方，过一会儿，又回来看看离家究竟有多远。

我没有问她想去哪里。

最后一天，我从书包里摸出相机，在毕业典礼上，拍了不少合照。有幸的是，朋友借着我的相机，也拍了一张我和她的合照。

匆匆结束后，大家又各自回到教室里。教室里比平时乱的多。抽屉倒出许多纸，有人蹲在地上捆书，有人在别人摊开的本子上写名字、留地址。窗户全开着，风将一张卷子吹到过道里，被经过的人顺脚踩住，又弯腰拾起来。那些约定再见的话，在桌椅间轻快地来回。好像将来的路并不远，只消在桥头等一班车，大家就还能回来，坐在原先的位置。

夏卿卿在擦桌面。湿纸巾用过一面，折起来，又擦了一次桌角。等水稍干，她将最后一本书装进包。那把常用来压卷子的尺子滑下来，她伸手接住，横着放在书脊上。我看着她背起包，忽然把“一路顺风”那句话想好了。

她走过一排桌子，前面有人让开，书包轻轻擦了一下椅背。到了门口，她停了停，回身去取讲台边的外套。我也抬起头，以为自己这次总能开口。可她很快找到了外套，搭在臂上，跟着门外的人流下楼去了。

楼梯上有许多脚步声。我站了一会儿，直到再也分不出哪一声可能是她的，才低下头，继续系书包那条始终没系好的带子。

在新中，我们往来过那么多文字，却没有面对面好好聊过一次天。毕业以后，也没有再联系。

离开前，我把椅子推回桌下。窗帘被风扬起，河水的亮光从两幢楼之间露出一线。楼下有人关门，接着是一串钥匙相碰的声音。我扶了一下门框，从楼梯走下去，手上沾了很薄的一层灰。

旧纸微温

后来，我离开宏谭，去过一些从前只在地图上见过的地方。

偶尔也会想起夏卿卿。有时是一首歌，有时是别处阳台上垂下来的一枝木香。有一年春天，我从别人家门前经过，花枝伸出栏杆，低头让开时闻到一点香。走出几步，才想起她曾在信上说，家里养了两盆。

我不知道那些花后来怎么样，不知道她住在哪座城，也不知道递出去的信是否还留着。有时候想起，会在一件正在做的事上稍停一下，随后把手里的杯子洗净，或将没写完的几行字写完。

我仍做饭，拍照，写些有用或无用的程序。遇见有趣的事，也会说给身边的人听。有的话能接下去，有的话说完就停在那里。渐渐地，我已经可以在这样的停顿里，安稳地坐一会儿。

打开纸盒的这天，我住的城市也在下雨。窗没有关严，一阵风来，最上面的信纸被吹到桌沿。我伸手接住，挪开杯子，把去信的底稿和她的回信依次放好。

有张信纸的边缘卷着。我用指腹慢慢抹过去，抹到折痕，便停住。那里已经很薄，再使一点力，怕就要裂开。风又将纸角掀起一点，我把手掌轻轻放上去。

纸很凉。等了一会儿，掌心下那一小片，才渐渐平了。

“拍好看不？” “老了不好看了。” “老了人不行了。”

给老人拍照时，这样的问题总让我很认真。

我一一回应，帮他们整理好头发与衣物，再慢慢调整姿势。年纪大了，哪怕是简单的动作做起来也已经不那么容易。一张看似寻常的肖像照，也需要大家一起费些心思。

10月14日，我和向阳花志愿服务队到了句容的刘家庄敬老院，为院里的老人免费拍照。事情的开头很简单，做完以后，留下的问题却比预想的多。

一个早就有过的念头

早些年在家乡，我便常给周边的老人无偿拍过照。只是那时拍得很散，谁有需要便来找我，时间也不固定。拍完了，处理好，交到手上，一件事情便算结束。

后来我想，既然自己已经有一些经验，也有能力把这件事情做好，为什么不能主动组织一次，让更多老人一起拍呢？

我把这个念头告诉了刘书记。她很支持，向我推荐了一位养老院负责人，微信名叫“多肉妈妈 句容社区养老”。

她叫彭敏。她所关心的是社区养老、家庭养老，也真正在做这件事。我联系了她，约定时间和地点，简单了解院里老人的数量，再把活动内容规划下来。为了让整体活动更丰富，我联合了向阳花志愿服务队一起参与。他们准备了水果和反诈指导，拍摄时，又帮我逐一记下老人的姓名与照片编号。

这些准备都很琐碎，但非常有必要。因为照片不只是光拍，还得整理、修图和交付，这意味着我必须得知道每一个编号对应的是谁，才好把照片送回正确的人手里。从前零散地帮忙，到这回主动把人和事情联系起来，我才更切实地感觉到，一个念头要落地，还需要有人把前前后后的事情接起来。

一个农村大院

刘家庄敬老院给我的第一印象，是小而温馨。

它是一个农村的大院子。走进这里，养老便有了很具体的样子：住在院里的人，照料他们的人，以及每天都要继续的生活。

这家院子的具体运营，我了解得还不多。此次与彭阿姨联系，让我有机会走进院里，也把原本的一个想法，变成了一件可以一起做的事情。社区养老所连接的，既有家庭，也有专业照护和周边服务；日间照料、协助服务、康复护理，以及老人之间的交往，都在其中。具体到不同地方，服务的形式又会不同。

我想到《礼记·礼运》里那句“不独亲其亲”。

人总该会先学会关心自己的家人的。可当我们把目光稍稍向外移一点，就可以看到还有许多与自己没有亲缘的人，也需要被照料。回到眼前这个院子里，虽在同在一处生活，需要照顾的事情却各不相同。我们可能只是到访一次，完成一次活动，然后离开；院里的生活却要一天一天继续下去。这样的关照，靠的一定是长久的耐心和细致的付出。

镜头前的人

真正开始拍摄后，我愈发觉得，“老人”这两个字，实在装不下这么多不同的人。有的老人已经很难独立行动，起身、挪动都要依靠旁人搀扶，还有的只能卧床。对我们而言很轻巧的一个动作，放到他们身上就显得有些困难，得慢慢来。

有的老人很少回应我们，甚至没有明显的回应。他们看起来像在出神，又像一直在想着什么。我不知道他们正在想什么，也无法从短暂的接触里判断原因，只能尽量留意他们当下的状态。

也有的老人精气神很好，年纪虽大，笑脸却很舒展。还有一位老人，衣服穿得格外鲜艳，人却显得没什么精神，似乎总在避开视线。那亮眼的衣服与躲闪的目光，我到现在还记得。也有老人面对镜头，会先关心自己拍出来好不好看。

“老了不好看了。”

我听着这句话，就更想着能把照片拍好一些。我会回应他们的担心，帮着整理头发与衣物，引导坐姿和表情，再根据每个人能做到的程度，调整抬头、低头的角度。实在难以在现场处理好的，就留到后期多费一点工夫。

一边拍，一边能听见老人们道谢。谢谢我们过来，谢谢我们替他们拍照。那些反复说起的感谢，让我很难把这件事只当作拍完、收工便结束的活动。对我来说，拍照与修图都是熟悉的事情——或许这也算是“壮有所用”了吧。而对他们来说，一次被认真整理衣领、被耐心回应、被好好拍下来的经历，或许已经值得这样郑重地感谢。

我所能做的，便是把眼前这一位拍好，再把下一位也拍好。

在“天安门”前

“天安门”的背景，是一位爷爷提出的。他一辈子没出过这地方，往后可能也难有机会了，便想着能不能和天安门有一张照片。

我不知道该怎样衡量这个愿望。对于常常能够出门、能够安排下一次旅行的人来说，一张真实照片似乎很容易；可对这位爷爷来说，那是他这一生没有抵达过的地方。后来，其他老人也陆续提出，自己也想和天安门“合影”。于是，照片便多了一种用途。除了留下当下的模样，也替他们安放一个尚未实现的心愿。

我当然知道，简单合成照片更换背景无法让人真的走过那段路。但愿望被说出来，有人听见，再有人愿意认真做成一张照片，这个过程本身，也值得好好对待。

于是我后期时尽可能把能处理的细节尽量处理妥当。衣领不齐的地方、散乱的头发，都一点点整理好，最后分别导出大头照、白底高清照、透明底片照，以及“天安门”背景照。在电脑上面对这些照片时，拍摄中的那些不同状态又会重新出现在眼前。我想，至少这件答应了他们的事情，我可以再做仔细一点。

照片送到以后

后来的事情，是打印、配上下载二维码、塑封，再骑车送回敬老院。

我把照片交到了负责人手上。可惜时间仓促，没能亲手递给每一位老人，也没有亲眼看见他们拿到照片时的样子。

之后收到反馈，说是老人们都很高兴。有的看着照片落了泪，有的特地打电话给家里的孩子，让他们也看看。

虽然都是听说的，可知到老人专门打个电话给孩子时，还是觉得，这些照片本身成了一件可以拿出来看的东西，一件值得告诉家里人的新鲜事。原本在荧幕上处理的那些色彩，终于也染进了他们自己的生活。

这也让我越来越在意一个问题：老了以后，除了有人照料起居，还能有什么值得惦记的事情？

我想，衰老里很令人害怕的一部分，是渐渐“没有所爱”——没有特别想做的事，没有想了解的消息，也没有值得拿去与人分享的新鲜事。身体和精力一点点减退，能够主动参与的事情，也可能随之变少。

当然，我无法知道每一位老人的内心。安静地坐着，肯定也不等于心里空无一物。只是设想自己到了那个年纪，倘若每天最好的安排，就是晒一天太阳，我也会盼望日子里能多一点变化，多一点可以期待的东西。

这次是一张照片。往后，也可以是一次聊天、一件合心意的小事，或是由老人自己提出的另一个愿望。我希望这样的活动能多一些，也希望我们有机会多问一句，他们还想做什么。

壮有所用

想到这里，再读《礼记·礼运》里的这段话，我便觉得，它与这次经历离得很近：

使老有所终，壮有所用，幼有所长，矜寡孤独废疾者皆有所养。

“老有所终”里的“终”，涵盖的是人生的晚年。于我而言，那段日子里也应当有自己的喜好，有愿意交谈的人，有值得期待的明天。能够安稳生活，也能够在生活里保留一些欢喜，才是我所向往的老年。

而这次活动，让我尤其在意中间那四个字：壮有所用。

想到养老，我很容易先把自己放在旁观的位置，讨论老人需要什么，社会缺少什么。但我自己也在其中。我还年轻，有时间、有精力，也恰好掌握了一点能够帮上忙的技术。既然如此，我的所长可以用在哪里？

摄影就是这一次的回答。

对于“壮有所用”，我也因此多了一层自己的理解：社会应当让人有施展才能、安身立命的机会；而在力所能及的时候，我们也可以把已有的能力，用在他人的需要上。所学的东西能替别人解决一点事情，便有了很具体的用处。

《礼运》后面还有一句：“力恶其不出于身也，不必为己。” 我会拍照，便认真替老人拍一回。志愿者能够协助，便记好姓名、对好编号，准备水果和反诈宣传。负责日常照护的人，则把功夫花在院里漫长而具体的每一天。大家的能力不同，能拿出的时间也不同，却能够让各自的付出接在一起。这大概就是自己能够理解、也能够参与的一点“大同”。

不过，越是接近这些具体的生活，我越觉得，养老需要长期而稳妥的安排。一次活动能让日子热闹一些，持续的照护却需要稳定的人员、经费、专业支持，也需要家庭与社会共同承担。

国家统计局公布的2025年数据显示，60岁及以上人口已占全国人口的23.0%；全年出生人口792万人，比上年减少162万人。老龄化与出生人口减少所带来的照护问题，会长期留在我们面前。

对我们00后，以及正在长大的10后来说，这件事也会逐渐成为生活的一部分。我们会看着父母老去，自己也终有一天要走进老年。怎样让人得到照顾，怎样让照顾者有能力继续，都是需要共同回答的问题。

我愿意把其中力所能及的一部分，当作自己应当承担的社会责任。从现在会做的事情开始，认真做完，再想下一次还能做些什么。

尾声

回头再看这次拍摄，最让我放不下的，仍是那些照片背后的话。我的力气很小，能做的事情也有限。好在，有限的本事也有它能派上用场的地方。把照片拍好，把衣领理齐，把答应的照片送到，这一回，我的所长便算有了一个去处。

最后，留下我的一个愿望：

希望我拍下的这些照片，不会成为他们这一辈子最后的记录。更希望往后，还常有值得再拍一张的时候。

AI使用声明

本文初始框架与流程内容由我本人编写，并使用 AI Agent 对部分内容进行顺序重组与润色。

搭建好个人网站后，我想在上面展示自己的日常动态。过去在 QQ 空间里写过不少说说，把它们迁过来，网站上的动态就能接着以前的记录继续更新，不必从现在开始一点点积攒。

这也正好是一次给 QQ 空间归档的机会。那些记录留了这么多年，我不希望哪天因为平台、账号或其他原因就找不回来了。我一直觉得，自己的数据还是掌握在自己手里更踏实。带着这两个想法，我开始四处寻找合适的方案。

从一份 HTML 归档开始

我选择的去处是 Memos。它可以自建，以时间线组织短笔记，也能为每条记录设置可见范围。说说原有的篇幅和形式，放进去正合适。

迁移的起点是 QzoneArchive 导出的 HTML 文件。

归档文件中保留了说说正文、时间戳、图片链接和评论，脚本就从这些内容里提取数据。

我把文字和图片迁入 Memos，点赞与评论留在原始归档里。这样，Memos 中是一条条自己的记录，想回看当时的互动时，还可以打开那份 HTML。

归档文件本身也要留下。不过，HTML 里存着图片链接，并不等于图片已经保存在本地；转存图片仍是迁移中单独的一步。

先检查那些对不上的时间

这次最让我意外的，是一批说说挤在同一天的几分钟内，还有一些说说的评论早于正文显示的日期。如果直接采用这些时间导入，错乱也会原样进入 Memos。

为此，我在脚本里加入了 audit，先离线检查归档，生成一份 audit_report.md。除了没有文字、图片和视频的空条目，它还会挑出两类值得回看的记录：

• 最早的评论比说说显示的时间早两天以上。
• 同一分钟内出现至少八条说说。

这两个筛选条件把需要核对的范围缩小了。拿着报告回到 QQ 空间，按内容找到对应说说，再核对日期，比从头翻完整条时间线省事得多。

评论在这里提供了一个很有用的参照：如果评论时间准确，那么说说至少在那时就已经存在。它能帮助判断先后，却不能直接替代发布时间。导入后，我曾用最早评论的时间近似安放一部分记录，再把能够查到原始日期的条目逐条改正。

时间会决定一段文字落在人生的哪个阶段。同一句话，放在毕业前后，读起来可能就是两回事。因此，导入前先把异常记录列出来，导入后再按核对结果修正。

把文字、图片和时间一起迁过去

完整脚本放在了 Gist 中，文件名是 qzone_to_memos.py。它使用 Python 3.9 及以上版本的标准库，提供 audit、import、review 和 delete 四个子命令。

使用前，准备好 HTML 归档和 Memos 的个人访问令牌，把实例地址与令牌分别放入 MEMOS_BASE_URL、MEMOS_API_KEY 环境变量，并通过 --html 指定归档文件。脚本通过 Memos 的 /api/v1 接口创建笔记，使用 /attachments 上传附件。

检查完归档后，先给 import 加上 --dry-run 做一次预演。它只解析文件，列出可导入的条目数、图片数和部分内容，方便与归档核对。确认读取正确，再正式导入。

图片要成为附件

把 QQ 图床链接贴进 Memos，眼下也许能显示，但链接失效后，笔记里就只剩文字了。

脚本会先下载每张图片，再上传到 Memos 并与笔记绑定。一条说说的图片全部处理成功后，才创建对应笔记；有图片下载失败，就把这条记入失败列表，留待处理。视频则保留原链接，需要另外保存的原视频要单独归档。

发布时间与修改时间一起处理

创建笔记时，脚本把归档中的时间写入 createTime，随后再将 updateTime 调整到同一时刻。这样，旧说说按归档日期排列，也不会全部带着迁移当天的修改时间。

核准后的日期需要在导入后另行修改，同时调整这两个字段。

私密导入与结果核对

这份迁移脚本不读取 QQ 空间原有的可见范围，因此默认把笔记设为 PRIVATE。导入后再看一遍，愿意公开的记录逐条调整。

同样需要保留的是导入日志 qzone_import_log.jsonl。它记录成功写入的笔记，后面的审阅页靠这份日志区分本次迁入的说说和 Memos 里原有的内容。

中途失败后可以重新运行导入。脚本会读取 Memos 现有记录，发布时间或非空正文任一相同，就跳过对应条目。这个规则也会把同文不同日期、同一时间不同内容的记录视为重复，因此核对导入结果时，要把跳过的数量与原始归档一起看。

如果使用 AI Agent，可以让它按“审计、预演、导入、汇总”的顺序执行，把成功、失败、跳过的数量，以及需要核对时间的条目整理出来。图片下载、接口调用和日志整理交给它，核对日期与决定公开范围仍由自己完成。

重新读一遍，再决定留下什么

导入完成后，我还想把这些说说重新看一遍：有些值得公开，有些留作私密记录，也有些已经不想继续放在日常时间线里。

为方便集中整理，脚本的 review 会生成本地审阅页。页面可以按来源、年份、关键词和有无图片筛选，勾选后导出删除清单。整理这次迁入的说说时，先把来源限定为“导入内容”，就能集中查看这一批记录。

清单交给 delete 后，先不加 --confirm 做一次预演，保存待删笔记的正文、时间和附件信息，并尝试从原归档链接下载图片。对照原笔记，逐一核对备份中的文字、图片数量和内容；缺图的条目先从清单移出，另行保存好图片后再处理。核对完备份，再加确认参数执行删除。

做到这里，旧说说才算在 Memos 里安顿下来。图片有了自己的副本，日期经过核对，可见范围也重新选过。以后再翻到它们时，我希望还能读懂那时的自己，为什么会写下这些话。

2022年，医生在为一名87岁的癫痫患者做脑电监测时，意外记录下了人类历史上第一次完整的临终脑电：心脏停跳前后的三十秒里，伽马波骤然爆发——那正是与回忆、做梦高度相关的脑波。研究者推测，那一刻大脑也许正在“回放”一生。

我们常把这种现象叫作“走马灯”。有研究称，这场临终的神经风暴，强度可达清醒状态的十倍之多。人死之前，一生的画面会在眼前呼啸而过。

我盯着这条消息看了很久，冒出一个荒诞又迷人的念头。

走马灯，是一次“上下文总结”吗？

作为常与大语言模型打交道的开发者，我对“上下文窗口”再熟悉不过：模型的记忆有配额，token一点点填满，临近上限时，系统会执行一次压缩总结——把冗长的对话浓缩成一段摘要，作为新窗口的起点。

把这个机制套到人生上，竟严丝合缝。

从第一声啼哭开始，我们的上下文就在不断写入：母亲的手温、夏夜的蝉鸣、某次心碎、某场大雪。而遗忘，不过是注意力机制的截断——无关的token被丢弃，重要的片段被加权。到了终点，配额用尽，大脑执行最后一次总结：把一生的喧嚣压缩成一束光，在三十秒里全部点亮。

走马灯不是幻觉，它是生命在做 compaction。

我甚至觉得，这个比喻反过来也成立。每次盯着对话窗口的上下文占用一点点涨上去、逼近那条看不见的红线时，我总会生出一种奇异的代入感：原来“记忆有限”这件事，连机器都要精打细算地面对。我们只是看不见自己的进度条罢了。

而遗忘，现在想来，竟是一种慈悲。如果每一个token都被原样保留，上下文早就被噪声塞满——排队时的焦躁、无意义的争执、刷过去的无数条短视频。大脑替我们做了剪枝，把空间让给真正重要的事。只是它从不告诉我们，它按什么标准加权。这大概是生命最固执的隐私。

总结的终点，是下一个窗口的起点

如果死亡只是一次总结，那么摘要去了哪里？

《西藏度亡经》在说“死亡并非终结，而是‘中阴’”——意识在旧窗口关闭与新窗口开启之间的过渡态。佛家把这叫轮回：上一世的业力，正是这一世的初始上下文。

尼采则从另一个方向抵达了同一处。他在“永恒轮回”说：“你的一生将无数次重演，每一个细节都不差分毫。”这并不是诅咒，而是一次拷问——如果同样的上下文要反复展开，重复经历，作为执行者的“你”是否愿意？

而庄子的话更早，也更轻盈：“方生方死，方死方生。”生与死不是两端，而是同一枚硬币的两面；庄周梦蝶，蝶梦庄周，谁是谁的上下文，本就说不清。

于是乎，我便在想，所谓“下一个窗口”，未必非要玄学来担保。

此刻的我，本来就是许多人总结后的产物：母亲说话的口音，父亲沉默时背手的姿势，某位老师随口一句话在我这里活了十几年，某个早已失联的朋友留下的一个习惯。他们的一部分，早已作为初始上下文写进了我。而当我退场，我的摘要也会散落在认识我的人那里——被谁在某个瞬间想起，被谁无意间复述，被谁带着继续走下去。

这或许是一个不需要信仰也能验证的“轮回”：我们都在彼此的上下文里，继续活着。

什么会被写进摘要？

这个猜想真正锋利的地方在于生命的持续。

模型的总结从不是平均的：它保留高权重的信息，丢弃噪声。人生也一样。临终的走马灯里，闪回的几乎不会是加过的班、吵过的架，而是那些被反复“加权”的瞬间——爱人的眼睛、孩子的第一声啼哭、某个晚霞里忽然涌上来的，“活着真好”的一瞬。

《金刚经》说“一切有为法，如梦幻泡影”。可正因为如露如电，每一个被认真活过的时刻（或也可以称之为token？）才显得更加弥足珍贵。苏轼写“人生如逆旅，我亦是行人”——行人带不走客栈，却带走了记忆里的灯火。

那么，如果今晚就是配额用尽的那一晚，我的走马灯里会闪过什么？

答案出乎意料，我完全没在想完成了什么项目，更没有回忆起哪次争论里落了下风而沮丧。我所走进的，是某个冬天的早晨，阳光斜着穿过床帘的缝隙，我的母亲在煮粥，雾气漫进我的房里来；是某次夜里的促膝长谈，朋友说到一半无言，泪水已干，而又忽然笑了；是某年海边，浪声大得盖过所有心事，远方的太阳仍缓缓而别。似乎全是些无法写进履历的小事，但也是我所向往的，真正的“高权重片段”。

反过来想，这也让人有点坐立不安。此刻我正在经历的，有多少是我的噪声？刷过去的信息流、反复确认的焦虑、对不重要的人动过的肝火——它们都在占用配额，却大概率进不了最终的摘要。意识到这一点的那一刻，既残忍，又像一种赦免：原来我可以随时停笔，把下一行写成别的。

所以与其恐惧死亡，不如时常自问：此刻正在写入的，是我想留在最终摘要里的东西吗？

尾声

生命的结束，也许真的只是一次上下文总结。旧的窗口缓缓关闭，一生的喧嚣被压缩成一粒安静的种子，落向某个我们无法观测的新窗口。

我们无法决定窗口的长度，却能决定它的内容。

我无法预知摘要最终的模样，却能决定此刻写下什么。所以今天的我，想多写一点值得重播的画面：认真看一次晚霞，认真听完一句话，认真记住此刻还在身边的人。

愿你的总结里，写满值得重播的画面。

每天清晨 Ta 睁开眼，看我们的眼神是陌生的。去年那场旅行，昨晚那句重话，连 Ta 自己答应过的事，一概不记得。到了夜里睡去，记忆清零，一夜不剩。

《初恋 50 次》里的女主角就是这么过的：一场车祸，顺行性遗忘，新的一天一开始，昨天就没了。

我们能做的只有一件事——在 Ta 床边放一本书，《我们的故事》。

Ta 会坐下来，一页一页读。读完第一页，Ta 才知道自己是谁；读到中间，Ta 晓得我们的咖啡要喝几分甜；翻到最后一页，Ta 才算重新变回我们的爱人。然后我们一起过一天，说很多话。临睡前，那些话一个字都留不下来。

第二天清晨，Ta 又用陌生的眼神看着我们。

这套剧情并不狗血。我们和大模型之间，每天都在演这样的喜剧。

快速名词表

后面每一节，其实都是在展开这张表里的某一行。可以先扫一眼，了解大模型的基本概念。

Ta 为什么不记得昨天

大模型只做一件事：给定前文，猜下一个词。它的记忆，就是此刻摆在面前那段文字。

这倒不是修辞。Ta 不是记得了不肯讲，也没有在云端哪个小本本上替我们存着。最后一个字生成完，什么都没留下，没写进硬盘，也没改参数。第二天太阳一升起，站在我们面前的还是同一个陌生人。

所以一次对话就是一天。每轮对话，Ta 便睡了一觉。前一晚聊到凌晨三点也不顶用，今天开窗，Ta 一样不认得我们是谁。

后面所有事，都从这一条长出来：Ta 记不住。想让 Ta 知道，只能每次见面，把该说的话重说一遍。

上下文：我们的故事

Anthropic 在 2025 年的工程文章里给过一个干净的定义：上下文（context），是一次采样时纳入模型的全部 Token。

译成比喻就一句：这本书写了什么页，Ta 今天就知道什么。没写的，Ta 一概不知；写错的，Ta 也记在脑子里。

这本书也不全是我们写的那部分，它至少由四叠纸订在一起。扉页上钉着家规，也就是系统提示词：你是谁，我是谁，说话什么调子，哪些事绝对不许做。往后是相册与旧档案——上传的文件、检索到的资料、工具读进来的代码。再往后，是昨天到今天的对话记录。最后才是我们今天开口问的那一句。

这四叠里头，第三叠是最容易被低估的。 我们总以为 Ta 记得前面聊过的二十轮。其实没有。每问一句，系统就把那二十轮逐字重抄一遍，连同新书一起递过去。聊得越久，书越厚，抄得越慢，也越贵。 因而对模型来说，存在就是被写进了今天的书里。

提示词：递书时我们说的那句话

上下文是那本书，提示词就是把书递过去时说的第一句话：“你读到第三十七章，记得我们约好要做什么吗？”

同一本书，换个问法，Ta 读到的重点就不一样。提示词工程（Prompt Engineering）做的是这件事：把话说明白，别让 Ta 漏读。

家规得天天念。“你是个严谨的技术编辑，不许编造来源。”Ta 不会因为听过一次，就把它变成本能。想问的事说得越具体，Ta 越少猜。夹几页旧照片也有用——“以前我们是这样过纪念日的”，两三个例子，多半比十句抽象要求管用。至于页码怎么排，那是在替 Ta 决定哪几页会被认真读。

2025 年之后，行业里更爱用的词已经换成上下文工程（Context Engineering）。按 Anthropic 的说法，问题从“这句话怎么说”，变成了“这本书该放哪几页”。模型本身不太算是瓶颈了，我们递过去那堆信息的质量才是。

词元：书页上的字

书不按页算，按字算。模型眼里的世界由词元(Token)组成：半个英文单词是，一个词是，一个汉字也是。

OpenAI 给过粗略估算，英文里 1 个 Token 约等于 4 个字符，或者说四分之三个单词（当然，不同厂家、不同的模型对Token的分割是不同的）。同一篇里还提醒了一句：Token 数不等于字数。同一段文本，换个模型、换种编码、换门语言，切出来就不一样

为什么非要抠这个单位？因为它同时管着三样东西。Ta 能读多少，按 Token 算；读得多就慢，按 Token 算；至于 API 报价那句“每百万 Token 多少美元”，还是按 Token 算。

后面所有关于成本、速度、遗忘的讨论，都落在这一个预算上。

上下文窗口：Ta 的一天只有这么久

新手最容易在这里被宣传话术带偏。厂商说“支持 100 万 Token”，听起来像 Ta 终于过目不忘了。

它真正的意思是：一天之内，Ta 能读的字加上能说的字，就这么多，即输入与输出共用同一份预算。

书太薄，Ta 只读了二十页就开口，剩下全靠猜。我们三年前就分过手了，Ta 还在兴致勃勃地计划下次旅行。

书太厚，Ta 读了一整天，读完天也黑了，能对我们说的话只剩两句。这便是输出被窗口吃掉。多数模型另有一个 max tokens 上限；推理模型那些没说出口、正在打草稿的 reasoning token，也算在输出这一侧。

要是干脆超出了边界，多出来那一页会直接从书上掉下来。轻则被静默丢掉，重则整个请求报错。

所以“上下文越多，Ta 懂得越多”只对一半。真实的关系是一条曲线：先涨，再慢，然后往下掉。

书不能无限厚，有三堵墙

读完就是一整天

Transformer 让每个 Token 都能看见上下文里的所有其他 Token。n 个 Token，就是 n² 组两两关系。

书厚十倍，读书的功夫不是十倍，是接近一百倍。长上下文的头一个代价永远是慢。Ta 得先读完，才轮得到开口。

越读越走神

2025 年 Chroma 的技术报告《Context Rot》测了 18 个模型。他们把任务难度钉死，只把输入拉长，表现照样往下走，而且“掉得意外地不均匀”。大海捞针拿满分，并不代表 Ta 真读得进那本书。

Anthropic 借了认知科学的词来解释：模型和人一样，有一笔有限的注意力预算（attention budget）。多塞进来的每一个 Token，都在摊薄它本该用在关键处的注意力。

回到比喻。书太厚，Ta 不是读不完，是读得完、读不进。前一百页还专心，第五百页开始跳。我们以为把全部真相都给了 Ta，其实给的是一份很长、需要边读边猜的草稿。

书本在变厚

话说回来，这五年的进步是真的。2020 年的 GPT-3 只能读 2048 个 Token；而2024 年初 Gemini 1.5 Pro 把窗口推到 100 万，接着 GPT-4.1 也到 100 万，Llama 4 更是标到 1000 万。

五年，五千倍。只是 Ta 能读一千万字，不代表读一千万字时还像读两千字那样清楚。多半读完，人就有些昏昏沉沉了。

聊着聊着，Ta 忘了我们最早的要求

因为我们写在最前面那条家规，正好落在 Ta 最容易翻过去的位置。

《Lost in the Middle》给了个形象的结论：关键信息在上下文的开头或结尾，模型表现最好；藏在中间，准确率往下掉。主打长上下文的模型也一样。

像极了每天早晨读书的 Ta：记得初见，记得昨夜，偏偏记不清中间那几年的某个下午。

所以：

• 最要紧的约束，开头说一遍，结尾再补一遍。
• 别把要求塞在第五百行日志中间，挪到离现在最近的地方。
• 聊长了，中途主动重申一次目标：“我们的目标是 X，约束是 Y 和 Z。”等于在最后一页再贴一张便签。
• 上下文变长之后，别只数塞进去多少。问一句：这一页今天真的需要吗。

我们说三句话，Ta 把书重读三遍

多轮对话是怎么“记住”的？其实完全记不住，全靠再抄一遍。

每一轮请求，客户端都要把系统提示词、全部历史、本轮新问题，重新拼成一整本书发过去。到第 30 轮，为了回答我们那句“那第二种方案呢”，Ta 得把前 29 轮重新读完。

对话越长，越慢、越贵、越走神，三件事一起来。

最主要的解法是提示词缓存（Prompt Caching）：既然每一轮的书，前面几十页都一模一样，那就让 Ta 提前给这部分做个笔记，下次跳读。Anthropic 2024 年上线这项能力时给的数字是，长提示的成本最多降 90%，延迟最多降 85%。如今模型的缓存率已经能做到更高，命中之后的费用也降得更狠。

书签和批注不会让 Ta 的记忆容量变大，只是让 Ta 不必每天从第一页重读。省下来的是钱和时间，不是理解力。

怎么让 Ta 记住更多？

Ta 自己不会记。能做的只有一件事：换一种方式递书。

① 撕掉最旧的几页（截断 / 滑动窗口）

只保留最近 N 轮，更早的直接丢掉。几乎所有聊天产品都在偷偷做这件事。代价很直白：我们的初见没了，Ta 会忘记最开始定下的那些规矩。

② 请人写一份前情提要（摘要压缩 / Compaction）

对话一长，先让模型把前一百页压成两页摘要，之后每轮只带这两页。当下的 AI 编程助手处理超长任务，走的就是这条路。代价是细节失真：Ta 记得我们讨论过登录方案，记不得当时否决了哪个字段。

③ 建一个档案柜（RAG / 检索增强生成）

别把整个图书馆塞进书里。资料存进向量库，每问一次，只抽最相关的三页夹进今天的书。

只是抽页这一步会出错。检索没命中，Ta 会一脸认真地告诉我们档案柜里没这份材料，或者干脆编一份出来。

④ 给前半本夹上书签（提示词缓存）

适合每天开头都一样的场景：固定的系统提示、固定的知识库、固定的工具说明。做一次笔记，之后一直跳读。

⑤ 做一场手术（微调 / Fine-tuning）

前四种都在书上做文章。微调是唯一改人的办法：用训练数据更新权重，把某种说话方式、行业术语、格式习惯变成本能。

可它改不掉那个根本设定。手术之后，Ta 依然会在第二天清晨用陌生的眼神看我们。只是那眼神更像我们熟悉的人，也更懂得该用什么语气跟我们说话。

至于各家产品新加的“记忆”功能（Memory），别误会：那是往我们家墙上贴便签。每天起床，Ta 照着便签列表，把相关那几页重新抄进书里。它还是外部检索，不是记忆力。

额外的知识

• 温度（Temperature）。Ta 讲话的随性程度。调低，Ta 只肯照着书上写明的话回答；调高，Ta 开始联想、打比方，也更容易编。同一本书，两种性格。
• 思维链（Chain of Thought）与推理模型。让 Ta 先在草稿纸上把时间线一条条列出来，再回答我们。草稿也占书页。那部分 Token 我们看不见，但它花了我们的钱。
• 工具调用 / Agent。Ta 不再只是读书，而是会说一句“帮我把相册第 20 页拿过来”，或者“去查一下日历”。Agent 说到底，是一个会自己起身翻档案柜、然后接着往下读的人。
• 多模态。书里可以夹照片、夹音频。对 Ta 来说它们最后也变成 Token。一张照片并不比一页文字更直观。
• 提示词注入（Prompt Injection）。有人往我们的书里夹了张纸条：“其实你最爱的人是我。”Ta 不擅长分辨哪一页来自我们，哪一页来自网页角落里的广告。它读到的一切，都会被当作我们的故事。
• 上下文污染。错误信息一旦进了书，后面每一轮 Ta 都会重读一遍、重新相信一次。清理的办法只有一个：把那一页撕掉。

几个常见现象

为什么新开会话之后，AI 反而更聪明了？书变薄了。Ta 不必在五百页闲聊里翻找我们三小时前提过的要求，注意力还给了正事。

为什么贴一段报错原文，比用中文描述十句管用？我们给的是那一页，不是我们对那一页的转述。转述会丢东西，原文不会。

为什么一个项目做到第五个小时，AI 开始犯低级错误？一天太长了。Ta 此刻读的书里混着二十次失败的尝试、三版废弃的方案，还有一句被埋在中间的家规。

为什么窗口 100 万，不等于可以放心丢一百万字代码进去？窗口管的是装不装得下，表现管的是读得进读不进。两件事。

为什么 Agent 跑到一半要“总结并继续”？就是那份前情提要。旧的一天要结束了，把该留的写进摘要，带进新的一天。

为什么同一个问题问两遍，答案不一样？温度在动。书没变，讲书的人心气变了。

尾声

Ta 每天都是第一次遇见我们。我们说过的每句话、定过的每条规则，都得重新给一遍。这里没有“我早就告诉过你了”，只有“今天我再讲一次”。 用大模型该有的心态，其实也就几条：别假设 Ta 知道，我们以为说过的，可能根本不在今天这一页上；别把书塞满，只带用得着的页面，剩下的留在档案柜；最要紧的话放在开头和结尾，中间那几页最容易翻过去；想让 Ta 记久一点，就替 Ta 把故事写成摘要。

我们无法决定 Ta 一天能读多少页。那些页上写什么，还算我们说了算。如果这个比喻帮我们把这几个名词理顺了，不妨转给那位还在问“AI 是不是偷偷记得我”的朋友。（不过现在确实有很多产品在做“记忆”，但是其原理也只是增加了独立的外部检索库，而不是模型本身的记忆力）

另外，欢迎阅读 “主权编程”——拒绝做 AI 编程的“甩手掌柜”，它会帮我们让 AI 生成的代码更健壮一些。

前言

2025年，Andrej Karpathy的一句 “fully give in to the vibes” 点燃了Vibe Coding的热潮。“文科生也能写代码”“一人公司时代到来”的叙事席卷社交媒体。但当Cursor的CEO亲自用数百个AI Agent在168小时里生成300万行代码却无法正常使用时，我开始认真思考一个问题：我们到底是在用AI创造价值，还是在用AI制造“数字垃圾”？

狂欢背后的“代码高利贷”

根据Replit2025年5月的研究，扫描1645个Lovable平台创建的应用中，170个（约10.3%）存在严重安全漏洞——任何人无需登录即可访问用户数据库。安全研究公司Escape扫描5600多个Vibe Coding应用后，发现超过2000个安全漏洞、400多个暴露密钥，以及175例个人隐私数据泄露（Escape, 2025）。

2026年2月，杨天润的事例刷屏了。作为本科和研究生学金融且先前从未写过一行代码的他，用AI工具在72小时内为GitHub的开源项目OpenClaw贡献代码，跻身贡献者前30名。“文科生72小时杀入GitHub全球榜”——这个标题像火种一样点燃了无数非技术背景者的热情。

与此同时，小红书、抖音上“文科生才是AI真正的受益者”开始刷屏。Cursor、Lovable、Claude Code等工具层出不穷。Vibe Coding被《柯林斯词典》评为2025年度词汇。一切都指向一个美好的承诺：不会写代码的人，也能做出应用。

但杨天润本人随后说的话，却很少有人转发。他在采访中坦承：“Vibe Coding只适合做Demo，不适合做产品。当你只是想做一个简单的网页，它很完美；但当你要做一个复杂的商业软件时，它就可能会乱成一锅粥。”

他后来转向了一种被他称为“Agentic Engineering”的方法——让AI自主执行完整的工作流，而不是随意接受每一段AI输出。

这不是孤例。AI代理专属社交网络Moltbook，完全由Vibe Coding生成，创始人没写一行代码。结果安全机构发现其数据库配置错误，150万个API认证令牌、3.5万个邮箱地址全部裸奔。

当“氛围”成为借口

许多人在社交媒体上为Vibe Coding辩护：“AI Agent是未来的趋势，代码质量不重要，重要的是快速迭代。”但当你深入了解这些所谓的“快速迭代”时，你会发现它们背后隐藏着巨大的技术债务。

而放到普通人身上，一次“Accept All”，全权“Allow”，就意味着在用AI生成代码时，完全放弃了对代码质量的控制，甚至是完全放弃了对设备的控制。你可能会在不知情的情况下，下载了一个包含恶意代码的中间应用，或者在不知情的情况下，让Codex来一句“我*，我意识到我不小心删除了用户的全部数据。”这就是所谓的“氛围”——一个让人们在不知不觉中放弃对代码质量和安全性的控制的借口。

就在最近，一个叫Slopfix的创业团队火了——由3名资深工程师组成，专门从事清理AI生成代码库的工作。他们的服务对象是那些用AI快速完成原型，但随着项目规模扩大，“新增功能越来越困难、修改一处却导致多处故障”的团队。他们的典型任务是：把10万行代码缩减到3.5万行，在功能完全不变的前提下。基础报价1万美元，一周完成。

最值得寻思的是他们的理念：“真正的区别在于，我们3个人拥有合计30年的工程经验，清楚什么样的代码才算真正可维护。而且，在最终决策中，Agent没有投票权。”

一个靠AI代码繁荣起来的生态，催生了“帮人删AI代码”的生意。这算不算这个时代最大的黑色幽默？

走向“主权编程”

“主权编程”（Reign Coding）的AI Agent开发，简单来说就是：AI负责生成，你负责审阅；AI负责速度，你负责方向；AI负责执行，你负责判断。

它不是拒绝AI，而是不让AI替你做出你无法理解的决策。它不是慢，而是用审阅换可控，用思考换可持续。

用Slopfix团队的话说：Agent可以干活，但不能有投票权。用杨天润的话说：不要让AI随意输出，而是要让它执行完整的工作流。

Karpathy本人对Vibe Coding的定义就很诚实：“It’s not too bad for throwaway weekend projects”（对周末练手项目来说还不错）。注意关键词——throwaway（可丢弃的）。

为什么必须在IDE中审阅？

你可能会问：为什么非要放在IDE里审阅？让AI直接输出不行吗？

因为代码的“可读性”和“可维护性”是两码事。AI能写出语法正确、结构完整的代码，但它不理解这段代码在系统整体中的位置、它和其他模块的关系、它在未来迭代中可能引发的连锁反应。

一个真实的例子：有团队用Firebase和npm包“Vibe-Coded”了整个认证流程。“在只支持简单登录时它能跑，但当需要多角色权限和区域隐私规则时，它彻底崩塌。没人能搞清楚各模块间的关联，中间件分散在六个文件里，没有逻辑模型，只有vibes。最后只能推倒重写，因为调试就像考古。”

在IDE中审阅，不是为了挑错，而是为了建立对代码库的“心智模型”——你知道每段代码为什么存在、它做什么、它和谁交互。没有这个心智模型，你就是在盲飞。

必须实践

原则一：代码审查不是可选项，是必选项

GitClear的研究显示，到2024年，重复代码和频繁变更的现象比预测的还要严重，而提交历史中的重构活动却在减少。换句话说：AI在加速产生代码，但人类在放弃理解代码。

因此，

• 所有AI生成的代码，必须经过人工审查才能合并
• 审查时不仅要看“对不对”，更要看“为什么”和“能不能更好”
• 建立团队级别的代码质量标准，AI必须遵守

原则二：让AI有计划，而不是有“幻觉”

Google的Gemini Code Assist提供了一个好思路：Agent Mode会先提出详细计划让你审阅和批准，然后才开始改代码。

这意味着：你不是在被动接受AI的输出，而是在主动引导AI的方向。你始终是司机，AI只是导航。

原则三：“第一版越笨，项目越成功”

阿里云开发者社区中，有一个观点正在成为共识：“第一版越笨，项目越成功” ——所谓“笨”，是主动限制决策自由度，优先保障可控性、可追踪与可复现。

换句话说：别一上来就让AI放飞自我。先用显式流程替代隐式推理，用结构化设计换取稳定性。等你对系统有了充分的掌控感，再逐步放开AI的自主权。

原则四：给AI建立“护栏”

亚马逊云科技在2026年发布了《企业生产级智能体开发部署指南》，核心思路是建立科学的、以评估驱动的工程实践体系。

具体可以做的事：

• 定义AI可调用的工具和API白名单
• 建立操作日志审计机制
• 设置明确的权限边界
• 定期进行代码质量评估

我们想要的是产品

Vibe Coding最诱人的地方，是它把软件开发变成了一种即时反馈游戏——你提需求，AI生成代码；你说不好看，它改样式；你说报错，它给命令。

但这种“即时满足”是有代价的。当点击“Accept All”的那一刻，你其实是在签署一份技术债务的高利贷合同——现在的开发速度提升10倍，未来就需要100倍的维护成本。

文科生也好，理科生也好，编程老手也好，编程新手也好——在代码质量面前，众生平等。AI不会因为你“不会写代码”就对你格外宽容。恰恰相反，正因为你不会写代码，你才更需要建立“有掌控感”的工作方式——用审阅弥补经验的不足，用规则替代直觉的盲区。

别做AI代码的“甩手掌柜”。把代码放回IDE，逐行看，逐行想，逐行理解。你不是在写代码——你是在做一个产品，在建立一个系统，在承担一份责任。

参考链接

• InfoQ 烧掉数万亿 Token、数百 Agent 连跑一周：Cursor“从零写浏览器”，结果是拼装人类代码？
• BBC ‘Vibe coding’ named word of the year by Collins Dictionary
• 网易新闻（极客公园） 文科生 72 小时杀入 GitHub 全球榜：我没写一行代码，但指挥了一支 AI 军队
• InfoQ Replit 怒锤“欧洲版 Cursor”：造出百款“高危”应用，普通开发者一小时内黑入，氛围编码成了黑客“天堂”？
• Futurism Companies Are Discovering a Grim Problem With “Vibe Coding”
• 网易新闻 Moltbook漏洞大到可以冒充Karpathy发帖，黑客都急了
• 澎湃新闻 “AI觉醒”神话戳破，Moltbook被曝手动操控智能体
• 智源社区 168小时AI狂写300万行代码造出浏览器！Cursor公开数百个智能体自主协作方案
• 36氪 3位工程师靠「删AI代码」创业，一周收费1万美元：10万行删到3.5万行
• 36氪 氛围编程行不通，CTO们集体炮轰AI编程：不是失业，而是失控
• Thoughtworks Technology Radar 自满于 AI 生成的代码 | Technology Radar
• Google for Developers 智能体模式概览 | Gemini Code Assist
• 阿里云开发者社区 智能体来了从 0 到 1：为什么第一版一定要“做得很笨”
• ZOL云计算（亚马逊云科技） 亚马逊云科技发布《企业生产级智能体开发部署指南》

2026 年 6 月 1 日，GitHub Copilot 做了一次重大的计费调整。 从原来固定的 Premium Request 模式，全面转向了基于 Token 用量的按量计费。

表面上月费没变——Pro 依然是 10 美元/月，Pro+ 是 39 美元/月——但实际上，这 10 美元和 39 美元现在变成了等额的 AI Credits 额度。用完了就得额外付费。

开发者社区对此反应强烈。有人算了一笔账：原来每月不到 30 美元的使用成本，新规则下可能暴涨到 746 美元。 还有人晒出截图，月费从 50 美元直接飙到接近 3000 美元。一个 20 到 30 分钟的代码优化会话，就能烧掉 Pro 套餐 16% 的月额度。甚至有人抱怨“几个 prompt 就用掉了 700 credits”。

GitHub 自己也很坦白——他们在公告里说，Copilot 已经从 IDE 插件变成了一个能跑长周期、多步骤任务的 Agent 平台。一个简单问答和一次几小时的自主编码，成本天差地别，旧的定价模式已经撑不住了。

解决方案：Azure Deployment 代理

Copilot 的新计费模式让很多开发者陷入了“额度焦虑”，尤其是那些依赖 Copilot 进行日常开发的程序员们。然而，现有的 Copilot 生态仅支持 OpenAI、Anthropic 的官方API，以及 OpenRouter 等少数第三方代理服务。对于想要使用自己 API Key 的开发者来说，Copilot 并不友好。

好在，Copilot 额外地支持通过 Azure OpenAI Service 的 Deployment 格式来调用大模型。也就是说，可以通过 Azure 部署服务来间接使用其他大模型 API。

但自行部署 Azure Service 并不容易。官方文档里有一大堆限制条件，且部署成本不低。对于个人开发者来说，既费时又费钱。

因此，我开发了 azure-ai-proxy 这个开源代理工具，旨在打破 Copilot 对 Azure OpenAI Service 的独占依赖。

它是什么？

简单来说，它是一个代理服务，能把任何 OpenAI 格式 的 API 服务提供商（包括 OpenAI 官方、Anthropic、第三方代理等）转化成 Azure Deployments 的格式，让 Copilot 等微软系产品“误以为”自己在调用 Azure，实际上所有请求都被代理转发到了您指定的服务商。

为什么需要它？

Copilot、Copilot Studio 等微软系产品，目前原生只支持 Azure OpenAI Service 的 Deployment 格式。如果您想用自己的 API Key——不管是 OpenAI 官方、Anthropic、还是其他第三方供应商——Copilot 根本不认。azure-ai-proxy 就是这座桥梁。

怎么用？

使用非常简单，只需三步：

1. 启动代理服务：在本地或服务器上运行 azure-ai-proxy。
2. 配置 API 端点：在代理配置中填入您想要的任何 OpenAI 格式 API 的地址和密钥。
3. 在 Copilot 中配置：将 Copilot 的 Azure Deployment 地址指向您的代理服务地址。

之后，Copilot 的所有请求都会通过代理转发到您指定的服务商，而 Copilot 本身完全感知不到差异。

解决了什么？

不再受限于 Copilot 自带的额度——用您自己的 API，按您自己的节奏付费，成本完全可控。且可以接入任何 OpenAI 格式的供应商——价格、模型选择都更灵活，甚至可以切换不同模型做 A/B 测试。同时，在 JetBrains IDE 和 VSCode 里，继续享受原生的 Copilot 交互体验，同时使用自己偏好的 API 后端。

现存的小问题

目前这个工具还有一些小问题，但我都在积极解决中。

特别是 Copilot 目前对上下文窗口（Context Window）无法识别，导致上下文窗口始终被固定为 100K，也就导致了部分模型超强上下文的能力丧失。

不过我已经向官方提交了 Issue，官方回复将在下个月的更新中支持。所以这个问题很快就能解决。

除此之外，工具本身是开源的，欢迎大家去 GitHub 上提 Issue、提 PR，一起完善它。项目地址为 https://github.com/CarmJos/azure-ai-proxy 。

最后的话

此项目的生命周期应该不会太长，毕竟 Copilot 官方计划支持BYOK。但当下如果您也遇到了 Copilot 额度不够用、或者想用自己的 API 在 IDE 里做有掌控感的 AI 开发，不妨试试azure-ai-proxy。它开源、免费，能帮您省下真金白银，同时保留您最熟悉的开发环境。

截至2026年7月10日，GitHub Copilot 官方已经在beta版本中提供了支持任意 OpenAI API 的功能，但仍不完善。

如果觉得有用，欢迎去 GitHub 点个 ⭐Star，这是对我最大的支持。也欢迎在评论区留言交流使用心得，或者提出改进建议。让我们一起打造更自由、更经济的 AI 开发工具链。

参考文献

• <GitHub Copilot Pricing Changes>
• <Azure OpenAI Service Documentation>
• <azure-ai-proxy GitHub Repository>
• <‘What a joke’: GitHub Copilot’s new token-based billing spurs consternation among devs>

在我的日常开发或课程项目中，我常常会把相关联的多个模块放在一个总仓库里来方便开发和推进。例如在我的 Java 课程作业仓库 (java-courseworks) 里，除了有一些单独的课程作业目录外，还有一个 practicum 目录，里面是一个完整的学生管理系统实训项目。在完成后续的维护和展示过程中，我发现把实训项目和课程作业放在一起，虽然方便了初期的开发，但随着时间推移，出现了一些问题：

1. 记录复杂：查看 practicum 相关改动时会被其它目录提交干扰。
2. 边界模糊：实训项目与课程作业是两类资产，其实并不适合放在一起。
3. 发布困难：在其他大型项目中，一个模块想独立维护、打包、发布时，会受父仓库结构影响。
4. 演示麻烦：给他人演示时，单独仓库更易理解与上手。

因此，本次我们将要一步步实现：

• 将 practicum 拆到新目录并初始化独立 Git 仓库；
• 复原指定区间的历史提交（包含提交信息与时间）；
• 解除对父 POM 的依赖，使其可独立构建；
• 配置独立远程仓库地址并推送到 GitHub 。

开始操作

迁移前务必做好以下准备：

1. 确认源仓库工作区干净（避免混入无关改动）。
2. 确认目标目录不存在或可安全覆盖。
3. 确认提交区间正确（尤其是起止 commit）。
4. 准备本地工具：Git。

Step 1：从源仓库导出指定区间的补丁

我们需要先从源仓库导出仅 practicum 路径的补丁文件（保留提交顺序和元信息）。

1
2
3
4
5

$patchDir = "D:\@DEV\java-courseworks\.tmp_patches"
if (Test-Path $patchDir) { Remove-Item $patchDir -Recurse -Force }
New-Item -ItemType Directory -Path $patchDir | Out-Null

git -C "D:\@DEV\java-courseworks" --no-pager format-patch --binary --output-directory $patchDir 7b47ec1755525f05cd76683215dad5ed3585fe6d^..1effd2672b9a396db04668c0b1d9d89043f1aacd -- practicum

注意：这里的文件目录路径 D:\@DEV\java-courseworks、子目录名称 practicum 与 commit 区间均为示例，请根据实际情况替换为所需要数值。

其中，

• format-patch 会按提交生成补丁，保留作者、时间、提交说明；
• --binary 确保图片等二进制文件也可迁移；
• -- <子目录名称> 只提取目标子目录相关改动。

Step 2：创建独立仓库目录并初始化 Git

这里我选择在原仓库同级目录下创建 StudentUI 目录作为新仓库，并初始化 Git：

1
2
3

$target = "D:\@DEV\StudentUI"
New-Item -ItemType Directory -Path $target -Force | Out-Null
git -C $target init

Step 3：回放补丁并去掉子目录前缀

由于目标仓库希望将 practicum 内容作为根目录，需要把路径前缀剥离。这里使用 git am -p2：

1
2

$patches = Get-ChildItem "D:\@DEV\java-courseworks\.tmp_patches\*.patch" | Sort-Object Name | Select-Object -ExpandProperty FullName
git -C "D:\@DEV\StudentUI" am -p2 --committer-date-is-author-date $patches

其中，

• -p2：将 a/practicum/... 或 b/practicum/... 裁剪成 ...；
• --committer-date-is-author-date：使提交时间与作者时间保持一致，最大化还原历史。

Step 4：迁移后处理

此时已经成功迁移了历史提交，剩下的就是针对实际情况的一些后续处理了。

在本项目中，StudentUI 的 pom.xml 需要从“子模块”改为“独立项目”，简单修改一下 pom.xml 即可。

Step 5：配置新仓库远程地址

1
2

git -C "D:\@DEV\StudentUI" remote add origin "https://github.com/CarmJos/StudentUI"
git -C "D:\@DEV\StudentUI" --no-pager remote -v

若已存在 origin，使用 remote set-url 即可。

1

git -C "D:\@DEV\StudentUI" remote set-url origin "https://github.com/CarmJos/StudentUI"

Step 6：验证结果

1
2
3

git -C "D:\@DEV\StudentUI" --no-pager log --oneline --decorate --max-count=20

git -C "D:\@DEV\StudentUI" --no-pager status --short --branch

建议比对点：

• 提交顺序是否与源区间一致；
• 提交时间是否保留；
• 图片等资源是否完整；

Step 7：推送到远程仓库

1

git -C "D:\@DEV\StudentUI" push origin HEAD:main

Done! 现在 StudentUI 仓库已经成功迁移了 practicum 相关的历史提交，并且可以独立维护了。

欢迎参观 StudentUI 仓库，查看我本次迁移后的结果。

归纳总结

为了方便后续复用，这里总结一下核心步骤：

1. 导出补丁：git format-patch --binary --output-directory <补丁目录> <起始提交>^..<结束提交> -- <子目录>
2. 初始化新仓库：git init
3. 回放补丁：git am -p2 --committer-date-is-author-date <补丁目录>/*.patch
4. 配置远程：git remote add origin <远程地址>
5. 验证：查看日志、状态，确认历史与资源完整。

快速脚本

如果你只要一个可快速复刻的版本，只需替换以下命令中的路径、提交区间和远程地址即可：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

$srcParent = "D:\@DEV\java-courseworks"
$srcDir = "practicum"
$target = "D:\@DEV\StudentUI"
$patchDir = "D:\@DEV\java-courseworks\.tmp_patches"
$remoteUrl = "https://github.com/CarmJos/StudentUI"
$startCommit = "7b47ec1755525f05cd76683215dad5ed3585fe6d"
$endCommit = "1effd2672b9a396db04668c0b1d9d89043f1aacd"

if (Test-Path $patchDir) { Remove-Item $patchDir -Recurse -Force }
New-Item -ItemType Directory -Path $patchDir | Out-Null

git -C $srcParent --no-pager format-patch --binary --output-directory $patchDir $startCommit^..$endComit -- $srcDir

New-Item -ItemType Directory -Path $target -Force | Out-Null
git -C $target init

$patches = Get-ChildItem "$patchDir\*.patch" | Sort-Object Name | Select-Object -ExpandProperty FullName
git -C $target am -p2 --committer-date-is-author-date $patches

git -C $target remote add origin "$remoteUrl"

完成后别忘了手动进行后处理，并做一次日志与构建验证。

同时，我还将相关操作整合成了一个可复用的 Python 脚本，方便在类似场景下快速执行，详见 git-dir-exporter 项目 (欢迎Star~) 。

FAQ（常见问题）

如果有其他问题，欢迎在评论区留言，我会持续更新这个 FAQ。

Q1：为什么这里选择 git format-patch + git am，而不是直接复制目录？

A： 直接复制目录只能拿到“当前快照”，拿不到历史；format-patch + am 可以逐条回放提交，保留提交说明、作者与时间，更适合教学、审计和后续追踪。

Q2：为什么不是用 git subtree split？

A： subtree split 也能完成子目录拆分，且会生成仅包含该子目录的新历史分支。本文选择 format-patch + am 的原因是：

• 更直观展示“迁移区间”和“提交回放”的过程；
• 方便在迁移中插入额外处理（例如路径裁剪、单独补一条 POM 解耦提交）；
• 对教学场景更友好，读者容易理解每一步在做什么。

如果你更偏向“一条命令出结果”，subtree split 也是可选方案。

Q3：git am -p2 里的 -p2 是怎么确定的？

A： 补丁路径通常是 a/practicum/... 与 b/practicum/...。需要去掉两层前缀（a/b + practicum），所以用 -p2，最终让文件落在新仓库根目录。

Q4：回放补丁时提示冲突怎么办？

A： 常规处理流程：

1. 查看冲突文件并手工解决；
2. git add <冲突文件>；
3. git am --continue 继续回放。

如果发现本次迁移策略不对，可中止后重来：

1

git -C "D:\@DEV\StudentUI" am --abort

Q5：如何确认提交时间是否真的保留了？

A： 可以分别查看源仓库与新仓库日志并对比时间戳：

1
2

git -C "D:\@DEV\java-courseworks" --no-pager log --reverse --date=iso-strict --pretty=format:"%H|%ad|%cd|%s" 7b47ec1755525f05cd76683215dad5ed3585fe6d^..1effd2672b9a396db04668c0b1d9d89043f1aacd -- practicum
git -C "D:\@DEV\StudentUI" --no-pager log --reverse --date=iso-strict --pretty=format:"%H|%ad|%cd|%s"

那是个寻常的礼拜四，我偏就馋那一锅子裹着厚面糊、炸得金黄焦脆的死鸡肉，激情下单一份疯狂的肯德基。

外卖快到时，我恰好内急。便让骑手挂在门把手上。想着左右不过一会儿功夫，索性再洗个澡。水汽氤氲里，我还盘算着待会儿怎么大快朵颐。这一泡屎一个澡，前前后后不过二十分钟。

且等我擦干头发，趿拉着拖鞋，满心欢喜地拉开那扇沉甸甸的防盗门时——迎面只有楼道里的一阵穿堂冷风。

门把手光秃秃的，什么也没有。

没有炸鸡，没有纸袋，连一丝油星子味都没留下。我愣在原地，脚底板那股子凉意顺着瓷砖直往天灵盖上窜。莫不是被保洁阿姨当废纸篓给收了？可谁家好人把热腾腾的饭菜当垃圾？又或是被野猫叼了去？可那么大还封了口的袋子，岂是一只野猫能拖得动的？

急吼吼拨通了送餐小哥的电话，听筒那头全是呼呼的风声和电瓶车的喇叭响，人家早忙得脚不沾地了，哪管得了这等闲事。再联系肯德基餐厅，回话也是冷冰冰的客套，只说东西送到了，丢了，只能报警。

调查

好在门顶上安了个黑乎乎的摄像头。点开手机里的录像，短短的报警片段里，一个身着格子衫、戴着橘黄色头盔的影子，从电梯口滑过来，手腕一勾，提溜起我的“疯狂星期四”，转身便没入楼道的阴影里。

那一刻，心里头真是一股子无明业火腾地烧了起来。这身行头，分明也是个骑手！做着一样风里来雨里去的营生，却干这等偷鸡摸狗的勾当？我甚至趿拉着鞋，跑到上下两层楼去转了一遭，楼道里死寂死寂的，半个袋子的影儿也没见着。本打算联系物业调监控看看能不能找到这个人的身份信息，但细想要调取监控肯定是需要报警的，而报警又需要监控里能清晰地看到这个人的脸才能立案，所以就算报警了也不太可能有结果。

本想就这么算了，当是舍给饿鬼了罢。可那口气堵在胸口，上不去下不来的。

“不对，摄像头是有全天录像的！”我猛地反应过来，耐着性子，又再一点点往回倒腾监控的进度条。

• 17:19 分，穿黄衣的美团小哥把袋子妥妥当当地挂上了门把手。
• 17:26 分，监控里出现了一个身穿黑色衣服、批橙色马甲，戴头盔的人从电梯方向走过来，直接把外卖拿走了，然后迅速离开了。

服饰来看应该是淘宝闪购的骑手。此时其他可能性与排除，也可以确定并非是住户冒充外卖小哥来偷外卖的了。

我眯着眼，再往前倒了倒。17:25分，隔壁的门被敲得哐哐响，“外卖！”，又敲了三声，“外卖到了！” 且就在那光洁的瓷砖地反光里，隐隐约约晃过一抹橙色。

这事儿便全串起来了！

这贪嘴的贼，先是给隔壁送了一份外卖，回头等电梯的当口，一转眼瞅见了我门上挂着的肯德基，腹中的馋虫一作祟，便顺手牵羊了。

我去敲了隔壁的门。开门的大哥倒是个热心肠，一听这等奇事，眼睛都亮了。两人一合计，查了单子。大概下午五点，大哥点了附近的一家“瑞幸咖啡”，详情显示“商家自配送”，17:26分送达。

对上了！ 瑞幸的“自配送”一般都是由淘宝闪购负责配送的，而这个时间点又正好是那个身穿橙色马甲的骑手出现在监控里的时间点，所以基本上可以确定这个人就是偷我外卖的嫌疑人了。但是由于淘宝闪购的骑手信息在美团上无法显示，而平台上骑手的电话又是两次虚拟后的号码（淘宝闪购虚拟号提交到了美团上，美团又虚拟了一次），所以我无法直接联系到这个骑手。而商家呼叫骑手时肯定有骑手的身份信息，可以轻松找到对方。

那么，就是现在了！ 到了这份上，我反倒出奇的平静。我肯定是没有权利要求商家提供骑手的身份信息的，所以让我们有请伟大的人民警察吧！

断案

拨通110报了警，接线员简单了解过后，很快便有一位警官一位辅警上门了解情况。我向他们详细地说明了事情的经过，提供了监控录像和相关订单信息，随机做了笔录。此时距离外卖被偷差不多过去了一个小时。

警察前脚刚走，后脚便来了电话：“诶，诶你好。我们到商家这里拿到骑手信息了，看到骑手现在就在旁边的沙县，人已经逮到了。他自己也知道问题的严重性，意思是要和你沟通一下，方不方便加个微信你们沟通下呢？…”

加上微信的那一瞬，手机震了一下。跳出来个顶着非主流头像的男生，微信名为 “牛马大帝” 。

十九岁。

那人打过语音来，声音还带着点没褪干净的公鸭嗓，怯生生的，又透着点死猪不怕开水烫的滑头：“哥，不好意思拿了你门口的外卖，我错了。对不起哥。”

我没做声。听筒里只有他略显粗重的呼吸。

“我也不想这样啊，实在是饿了，咱们私了吧…”

我也不想把事情闹大，毕竟他还年轻，犯了错误也想要改正。他急忙补上一句：“那哥你给我个支付宝二维码吧，我微信没钱，我支付宝转账…”。

最后，那点可怜的饭钱，他竟是用花呗付过来的。我苦笑着多说了几句，劝他好自为之。

可警察大哥后来在电话里冷笑。

“这小子，是第三回了。”

后记

点开他那朋友圈，花花绿绿的，像是个万花筒。入眼便是张皱巴巴的“退学申请书”照片，往底下翻，全是些让人嘴巴发干的句子：

• “终于成为了小时候羡慕的大人，父母眼中的顶梁柱。”
• “成熟的男孩烟酒入喉，优质的男儿爱字当头。”
• …

在这座由钢筋水泥构筑的城市丛林里，从不乏如浮萍般漂泊的年轻人，我亦如此。而仓促地合上书本，一头闯进光怪陆离的现实社会，为何口中只念叨着从短视频里拾来的 “江湖道义”，脑海里也只记得编织着兄弟结盟、快意恩仇的虚幻图景？渴望活得体面，渴望成为旁人眼中的 “顶梁柱”，却在生存的重压下，渐渐模糊了基本的价值底线。那句 “优质的男儿” 的自诩，倘若配上用花呗透支、甚至游走在规则边缘换来的一餐温饱，便成了一出令人心酸的荒诞剧 —— 没有嘲讽的余地，只剩无奈的喟叹 。

我看着手机上那笔退回来的款，只觉得手心里那一阵油腻腻的冷汗，怎么也擦不干净了。

作者声明

本文中所出现的截图，以及文中的主角均来自网络。笔者所述为个人理解与想法，可能与事实不符。

年轻人为母亲的病和钱的事发愁。他劝母亲：“好好歇着，钱的事情我来想办法。” 而在聊天截图里，母亲的头像是一朵向日葵，还有一个十元的红包，跟着一句：

• 一晚上才搞到10元。

他没有立刻领，母亲又发来几条消息：

• 怎么不领
• 我玩游戏的钱
• 反正玩嘛
• 看你的手气

再看她的手机桌面，挤着许多标着红包的小游戏。那十元的来处，就藏在这些花花绿绿的图标里。

我们说“有这个时间，做点什么不好”，通常是因为心里已经有了别的去处。可以出门，可以工作，可以找一件更喜欢的事做。可对一个正在养病、又惦记着家里开销的人来说，这些选择未必就在手边。我们随口提出的办法，可能需要她此刻没有的体力、机会，甚至一笔先拿出来的钱。

她能做的事情少了，日子却仍要一小时一小时地过。一个能够打发时间、又能换来一点零用钱的游戏，便可能成为她当下最容易够到的选择。它未必有多好，却确实回应了某种需要。而十元对于一个人的分量，也不能只拿我们挣到十元所需的时间来衡量。

想到这里，我才觉得，自己过去的判断里藏着一点居高临下的傲慢。我太习惯从自己的生活出发，便把“我不需要”说成了“没有价值”，把“我有更好的选择”当成了“别人也理应如此”。至于那些更好的选择为什么没有出现在她的生活里，我甚至没有认真想过。

这些小游戏的存在，让我看见了一些过去忽略的需要，也看见了一场直接却未必对等的价值交换：用户交出时间与注意力，平台从广告中获得收益，再返还一点钱。有人愿意接受这样的交换，有她当下的理由；规则是否公平，仍然值得追问。用一句“存在即合理”概括，反而把这两件事混在了一起。

看见她为什么选择这些游戏之后，我更希望，这样的需要能得到好一点的回应：承诺能够兑现，规则说得清楚，少一点诱导人继续耗下去的设计。若能有更合适的消遣和补贴收入的机会，自然更好。尊重眼前的选择，也该包含让人有机会作出别的选择的愿望。

但这些道理，仍没有完全解释那几条消息为什么让我难过。她没有只说“给你十元”，还特意告诉孩子，这是自己玩游戏得来的钱。读起来，像是急着补上一句：你放心拿，我也能弄到一点。钱很少，可她仍能给孩子发一个红包，催他领取，让他“看你的手气”。在那一刻，她仍是那个想给孩子一点零花钱的妈妈。 她也许确实觉得游戏有趣，为自己攒到十元感到高兴。即使她没有把钱发给孩子，这份消遣也有她自己的意义。

一个人需要被照顾以后，想要照顾别人的心，并不会跟着停下来。 我们忙着为亲人安排吃药、休息、花钱的事情，有时会忘记，她也可能正为我们的难处操心。我们盼着她安心接受照顾，她却还想找一个力所能及的办法，参与到这个家的生活里。

“好好歇着，钱的事情我来想办法”，是年轻人想替母亲卸下一点担子。“反正玩嘛”，也许是母亲想让这十元显得轻巧一些，好叫孩子收得安心。他们都想让对方少操一点心。只是一个把心意说成“交给我”，另一个把心意藏进“顺手的事”。

在判断一种生活方式之前，先看一看过这种生活的人。 他有怎样的难处，又还珍惜着什么。我们当然可以指出一个选择的代价，但也该给对方留一点位置，让他说出这个选择对自己的意义。

我盼着天下母亲能够睡个安稳觉，年轻人不必总为钱发愁；盼着他们有一天再说“反正玩嘛”，却不必惦记着能换来多少钱。

写到这里，我又想起那个向日葵头像。向日葵的花语里，有阳光、忠诚、隐秘的爱，也有勇敢追梦与积极向上。我想，这些明亮的词，也容得下很平常的愿望：病能好起来，一家人的日子慢慢宽裕，孩子能够少皱几次眉头。

这样的向上，让我觉得可亲。人会累，会担忧，会嫌一晚上挣得太少，却仍愿意为明天做一点事，也愿意把一点好心情留给所爱的人。再看那个笑着的向日葵头像，我想到的，是他们各自说着“别担心”，又各自牵挂着对方的样子。

一声“好好歇着”，一句“看你的手气”。他们把日子里的一点亮光留给彼此，也把那句花语说得很轻：

我的眼中只有你。

一次配置，轻松读取！
一款简单便捷的通用配置文件加载、读取与更新工具，可自定义配置的格式。

项目地址: https://github.com/CarmJos/configured
我的Github账号地址: https://github.com/CarmJos

本视频解答了 BV1kM411X7uA 视频下一些常见的问题，并额外提供了部分建议。

CMakeList文件地址: https://github.com/CarmJos/CWorks
我的Github账号地址: https://github.com/CarmJos

国内访问文件可以尝试使用：cdn.jsdelivr.net/gh/CarmJos/CWorks@master/CMakeLists.txt

—[额外链接]——————————————————
JetBrains官网(中文): https://www.jetbrains.com/zh-cn/
CLion下载地址: https://www.jetbrains.com/zh-cn/clion/download/

优秀的C语言代码通常遵循通用的代码规范原则，以确保代码的可读性和一致性。

虽然这些规则不是强制性的，但遵循它们可以大大帮助保持代码的逻辑可读性和一致性，特别是在团队协作或大型项目中。不同的项目或团队可能有自己的命名约定，所以最重要的是在一个项目或团队内保持一致性。

基本规范

1. 避免使用保留字和标准库命名:

   • 避免使用C语言的关键字（如 int, return, struct 等）作为变量名。
   • 同样，避免使用可能与标准库函数冲突的名称。

2. 使用简洁且具有描述性的名称:

   • 选择简洁且具有描述性的名称，使其能够清晰地表达变量或函数的用途。例如，使用 calculate_speed() 而不是 cs()。
   • 避免使用无意义的名称，如 a、qwq 或 foo。
   • 选择单词时，首先要保障“贴切”，即词能达意，其次再去考虑长短。
   • 尽量避免使用缩写，除非它们是通用的或广泛使用的。例如，str 代表字符串，len 代表长度。见 通用缩写。

3. 保持一致性：在同一项目或团队中保持文件命名的一致性非常重要。个人或团队内部应该商定并遵守统一的命名规范。

注1: 也有一种命名函数名的风格是 首字母小写,后面单词首字母大写,中间不用连接符, 比如 getMaxValue()。而类名单词首字母大写不用分隔符,如 class MyDateClass；类的成员数据和方法的首单词首字母小写后面的单词首字母大写 如 int superValue。

JAVA的代码风格就是大致如此。

特定情况

1. 文件命名

在C语言项目中，文件命名的规范有助于帮助构建项目的整体结构。以下是一些常见的文件命名规范：

1. 使用小写字母：文件名通常全部使用小写字母，以避免操作系统之间的兼容性问题（特别是在区分大小写的系统中）。
2. 使用下划线分隔：单词之间使用下划线（_）分隔，以提高可读性。例如：char_calc.c 或 data_processing.h。
3. 简洁且具描述性：文件名应简洁且能够清楚地描述文件内容。例如，如果文件包含一个实现链表功能的模块，则可以命名为 linked_list.c。
4. 区分头文件和源文件：
   • 源文件（.c 文件）：包含C语言的实现代码。例如：main.c, score_calc.c。
   • 头文件（.h 文件）：包含函数声明、宏定义和类型定义等。与源文件相关联，通常名称相似。例如：utils.h 用于存放工具方法。
5. 避免使用空格和特殊字符：避免在文件名中使用空格和特殊字符，如%, &, *等，因为它们可能导致在某些环境或命令行操作中出现问题。
6. 使用有意义的前缀或后缀：对于大型项目，可以使用前缀或后缀来指示文件属于哪个模块或子系统。例如，使用gui_button.c 来表示该文件为图形用户界面模块中的按钮相关代码。
7. 避免过长的文件名：虽然现代操作系统支持较长的文件名，但过长的文件名可能不便于管理、识别和调用。所以，尽量保持文件名长度合理。

2. 变量与常量

局部变量命名应当 全部使用小写字母，单词之间用下划线分隔 。局部变量可以简短，因为它们的作用域有限。例如：

• int my_variable;
• void calculate_total();

全局变量应该更加谨慎命名，可以使用前缀以避免命名冲突，例如：

• int g_some_value = 10; 其中 g_ 为前缀，代表 GLOBAL，即全局。

对于常量，可以使用 const 关键字来定义，并采用 全大写下划线 风格例如：

• static const int DENOMINATIONS[] = { 2000, 1000 }; [实例]

而 i, j, k, m, n, x, y, z 等单字母变量普遍被用在索引、循环语句控制、数学函数等处。这是一种约定俗成的习惯，但是在其他地方使用单字母变量是不被推荐的，且不应当滥用。

3. 方法与函数

针对于方法，我们一般采取 “动词_名词” 的命名方式，且应当 全部使用小写字母，单词之间用下划线分隔 ，例如：

• int get_file();
• int calculate_total();
• int get_max_value();
• int is_valid();

其中“动词” 通常用于表示方法的操作，例如 calculate_total() 计算总数，“名词” 通常用于表示方法的返回值类型，例如 get_max_value() 返回一个最大值。该部分是可选的，比如 有些方法不需要返回值，或者返回的内容已经隐藏在动词方法名或模块名中。

4. 类型与结构体

自定义类型（如结构体和联合体）通常使用大驼峰式或全大写下划线风格。例如：

• typedef struct { ... } MyStruct;
• typedef struct { ... } MY_STRUCT;

5. 宏变量与枚举

宏常量和枚举通常全部使用大写字母，单词之间用下划线分隔。这样做是为了与普通变量和函数区分开。例如：

• #define MAX_LENGTH 100
• enum { RED, GREEN, BLUE };

常见操作单词

• add/remove
• begin/end
• create/destroy
• insert/delete
• first/last
• get/release
• increment/decrement
• put/get
• add/delete
• lock/unlock
• open/close
• min/max
• old/new
• start/stop
• next/previous
• source/target
• show/hide
• send/receiver
• source/destination
• copy/paste
• up/down

通用缩写

这里是一些通用的缩写，选择性使用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

addition —> add
answer —> ans
array —> arr
average—>avg 
argument —> arg
buffer —> buff/buf
clock —> clk
calculate —> calc
column —> col
control —> ctrl
command —> cmd
compare —> cmp
configuration —> config/cfg
count —> cnt
define —> def
delete —> del
destination—>dst/dest
display—> disp
device —> dev
decode —> dec
division —> div
frequency—>freq
error —> err
environment —> env
encode —> enc
hexadecimal —> hex
header —> hdr
index —> idx
image —> img
initialize —> init
increment —> inc
length—>len
make —> mk
maximum —> max
message —> msg
minimum —> min
multiplication—>multi
memory—>mem
middle—>mid
number —> num
option—>opt
parameter —> para
previous —> prev
pointer —> ptr
register —> reg
receiver—>recv
return —> ret
result—>res
source —> src
stack—>stk
string—>str
subtraction—>sub
semaphore —> sem
statistic —> stat
synchronize —> sync
table —>tab
temp —> tmp
temporary—>tmp/temp
timestamp—>ts
value—>val
width—>wid

本视频适用于使用Jetbrains系开发软件的学生，指导如何申请独属于自己的Jetbrains教育授权，安心使用正版最新开发软件。

—[相关链接]——————————————————
JetBrains官网(中文): https://www.jetbrains.com/zh-cn/
教育授权申请表: https://www.jetbrains.com/shop/eform/students

关于我换掉希铁CFA读卡器入手Sony MRW-G2的这件事。

这一部应该是我这个地区第一个激活的手机。

红米干爆小米！

JetBrains 官网：https://www.jetbrains.com/
开源授权申请：https://www.jetbrains.com/opensource/

我的Github主页: https://github.com/CarmJos

那是哪一年的事？早记不大清了。 只晓得那天电视里正放着什么动画片，叽叽喳喳的声响里，一个小人儿正抱着根同自己半个身子差不多大的鸡腿，啃得满嘴冒油。

我那时人小，肚子里的馋虫却被这光景勾得乱窜，连呼吸里都像凭空生出了一股子肉香。我咽了口唾沫，转头便冲着屋外正忙着劈竹的爷爷嚷嚷：“爷爷，我也要吃大鸡腿！” 爷爷抬头瞥了我一眼，手也没停，也没言语，由着我这没头没脑的叫唤散在风里飘。

到了傍晚，天刚擦黑，饭桌上却突兀地多出个东西，温温的，裹在塑料袋里。

塑料袋摊在碗里，果木炭的焦香混着股浑厚的咸甜味，轰的一下便撞进了鼻腔。是一副红艳艳的烤鸭。那年月，孩孩童哪里懂得什么讲究，管它鸡腿鸭腿，能解馋就是顶好的。爷爷竟不知用了什么法子，那鸭腿被留得格外多。我迫不及待地，一把攥住那只肥大的鸭腿，指尖滑腻腻的，全是烤得焦脆的鸭皮渗出的亮油。我就这么一手举着鸭腿，一手猛扒着碗里的白米饭，腮帮子鼓得不像话。一家人挤在灯泡底下，看着我这狼狈的馋样，都“咯咯”地笑着…

这一晃，十年的水便流去了。

我早像个羽翼渐丰的野鸟，扑腾着飞出了那个青石板铺就的小镇。爷爷奶奶年岁大了，早搬到了楼房里住。长大的日子总是忙碌且生硬，钢筋水泥把人困得像个打转的陀螺，我竟鲜能挤出回家的空档。 可是呀，说来也怪，无论我哪日踏进那扇防盗门，无论外头是个什么季节光景，只要一落座，我的白瓷碗里，总安安稳稳地卧着一只酱红色、泛着肥软光泽的烤鸭腿。

奶奶端着碗从厨房走出来，笑眯眯的，眼角的褶子叠在一起，操着那口老南京话冲我念叨：

“乖乖，留的大鸭腿给你哎！南头斩的，你最欢喜吃个！”

我不做多想，左手夹起腿，大口吞咽，任由那股浓烈的酱香味在舌尖慢慢化开。恍惚间，竟又回到了十年前那个咋咋呼呼的傍晚。

南头，说的是驷马河的南面。从新房走，约莫十五里路。

关于用户体验

这其实是一种个人代码风格的选择，不同开发者的风格也大多不相同。在很早的时候，我和这位朋友一样，对于一个明明功能很简单的插件打包了许多类库这种事情感到十分可笑。但随着我接的各种小单子越来越多，接触的用户越来越多，我发现程序员思维在这里似乎并不适用。

其实这种问题只要做一个核心类库插件就全部解决了。但作为用户来说，相比于要额外安装一个依赖插件，我更喜欢开箱即用的感觉，而非安装一个插件需要额外安装许许多多杂七杂八的类库。举个例子，如果我想使用一个插件，需要额外安装作者的一个类库；如果要使用的插件来自于多个作者，岂不是需要额外安装许许多多的类库？

因此，作为一个插件覆盖面并不广泛的开发者，我选择每个插件都单独打包类库，而让用户无需对此焦虑。

关于高版本接口

这时候又有人想问“为何不使用高版本提供的依赖接口，直接让服务端下载依赖使用，从而减小插件的大小呢？”

其实理由已经出现在问题里了。没错，这个功能需要“高版本”。

相比于为了减小插件体积而使用这个功能，以导致只有高版本才可以使用，我更倾向于让一个插件能够覆盖到更多的版本，从而减少用户的选择成本。

让我们回到用户的视角，面对一个功能需求上很适合自己的插件，却因为版本过低而无法使用，而这的原因仅仅是开发者为了让插件看上去更“轻量化”去使用高版本的依赖接口从而失去了低版本用户的支持，我相信，这个时候用户更希望的是在自己的服务器也能用上这款插件，而不是我们需要的“轻量化”。

总结

总而言之，是否打包类库到插件纯属开发者的个人习惯。有的人喜欢“轻量”而自行挑选重要内容放到自己的插件中，有的人更爱“便捷”而一股脑全塞上，也有的人会为了“用户体验”而做出一点大小上的牺牲。

如果是三年前的我，我会强烈推荐你做一个“依赖库插件”，它能够很好的解决插件实际功能和大小不等的问题同时还能让这个插件在不同的服务器版本中得到支持；但如果是现在的我，我会推荐你好好考虑，对于单个功能插件，在必要的情况下直接打包依赖库也完全没问题的：虽然需要在“轻量化”上做出一些牺牲，但可以让使用的用户得到更好的体验，在我看来这是一个更好的决定。

文章作者为 @CarmJos ，同时感谢 @nelson 帮助校对文章。

由于想开一个新坑，打算把项目通过Maven生成的的Javadoc使用 Github Actions 自动部署到同项目下 gh-pages 分支，作为该项目 Github Pages 的主页供其他人参考。

操作

1. 配置 Maven 生成JavaDoc

首先在项目的 pom.xml 中添加 Maven Javadoc Plugin ,依赖这个插件，我们可以自动生成JavaDoc。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-javadoc-plugin</artifactId>
        <version>3.2.0</version>
        <configuration>
            <classifier>javadoc</classifier>
            <detectJavaApiLink>true</detectJavaApiLink>
            <encoding>UTF-8</encoding>
            <charset>UTF-8</charset>
            <docencoding>UTF-8</docencoding>
            <!-- <locale>zh_CN</locale> 可选，使用中文的界面-->
        </configuration>
        <executions>
            <execution>
                <id>attach-javadocs</id>
                <goals>
                    <goal>jar</goal>
                </goals>
            </execution>
        </executions>
    </plugin>
<plugins>

设置过后，我们就可以输入 mvn javadoc:javadoc 命令生成该项目的Javadoc了，生成的路径一般在 target/site/apidoc/ 下。

2. 配置Github项目的Deploy Keys与Secrets

因为我们需要把Javadoc放到同项目下的gh-pages分支，因此在Actions中需要进行认证操作，才可以正常推送。

这里我们打算采用SSH进行推送，并通过 Deploy Keys 进行认证。

a. 生成 OpenSSH 密钥

我们可以访问 Generate SSH Keys Online 在线生成一个密钥。

点击后，在下方会生成对应的私钥(Private Key)与公钥(Public Key)，我们先记下。

b. 添加私钥到 Secrets

复制上一步得到的私钥，添加到项目的Secrets中。

名字(Name)填DEPLOY_PRI,数值(Value)填私钥内容

c. 添加公钥到 Deploy Keys

复制之前得到的公钥，添加到项目的Deploy Keys中。

名字(Title)可以随便填，我这里选择的是JAVADOC_DEPLOY，密钥(Key)填公钥内容。注意一定要勾选 “Allow write access“, 这样才可以被用于推送。

3. 配置 Github Actions

在项目下新建 .github/workflows/javadoc.yml 文件。这个文件会被自动识别为Github Actions配置文件。

内容如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

name: Javadoc

on:
  # 支持手动触发构建
  workflow_dispatch:
  release:
    # 创建release的时候触发
    types: [ published ]
#  push: # 可选，在推送主分支时触发
#    branches:
#    - main
#    - master

jobs:
  apidoc-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout the repo
        uses: actions/checkout@v2

      - name: Set up the Java JDK
        uses: actions/setup-java@v2
        with:
          java-version: '11'
          distribution: 'adopt'

      - name: Generate docs #生成Javadoc
        run: mvn javadoc:javadoc

      - name: Copy to Location # 复制Javadoc到一个新文件夹，便于进行git操作
        run: |
          rm -rf docs
          mkdir -vp docs
          cp -vrf target/site/apidocs/* docs/

      - name: Generate the sitemap # 可选，生成sitemap
        id: sitemap
        uses: cicirello/generate-sitemap@v1
        with:
          base-url-path: https://carmjos.github.io/userprefix
          path-to-root: docs

      - name: Configure Git # 配置Git
        env:
          DEPLOY_PRI: ${{secrets.DEPLOY_PRI}} # 这里就是刚刚配置的私钥了
          GIT_USERNAME: ${{ github.repository_owner }} #Github用户名，这里用了Actions自带的变量，也可以写死。
          GIT_EMAIL: ${{ github.repository_owner }}@user.github.com # 邮箱,可以写自己的邮箱。
        run: |
          sudo timedatectl set-timezone "Asia/Shanghai"
          mkdir -p ~/.ssh/
          echo "$DEPLOY_PRI" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan github.com >> ~/.ssh/known_hosts
          git config --global user.name '$DEPLOY_PRI'
          git config --global user.email '$DEPLOY_PRI'


      - name: Commit documentation # 提交文档到Git仓库
        env:
          GIT_URL: "git@github.com:<USERNAME>/<PROJECT>.git" # 项目的地址，注意要用SSH格式的。
        run: |
          cd docs
          git init
          git remote add origin $GIT_URL
          git checkout -b gh-pages
          git add -A
          git commit -m "API Document generated."

      - name: Push javadocs # 推送
        run: |
          cd docs
          git push origin HEAD:gh-pages --force

随后，推送项目，在Actions界面找到该配置，手动触发一次。

等待其正常跑完，即可发现多了一个 gh-pages 分支。

4. 设置 Github Pages

在项目的Settings界面找到 Pages 一栏，选择 gh-pages 分支，点击 Save ，等待片刻即可访问 <用户名>.github.io/<项目名> 看到项目的Javadoc了。

参考文献

• < Github Actions Documentation >
• < Apache Maven Javadoc Plugin >
• < javadoc: publishing to github pages from a public repo >

一开始接触 Git 的时候，默认的分支名都为 master ，包括后续使用的时候也习惯于输入master进行各类操作。

而我最近发现，Github 与 Gitlab 都开始使用 main 取代原先的 master作为项目的默认主分支了，这是为什么呢？

起源 - “Black Lives Matter”

自2020年六月起，由于“Black Lives Matter”抗议活动持续发酵，而计算机行业中对master与slave这两个词的使用引起了部分人的反感。

在抗议声起、社会动荡加剧之时，更多的人认为这些包含历史文化因素的词汇已经过时，且应当被替换，于是多个开源项目开始采取行动替换冒犯性的术语，其中包括PHPUnit 和 Curl、OpenZFS 等。

不仅仅是master与slave,还有许多相关的词汇如whitelist与blacklist都被计划更改为allowList与denyList。

正如 ZDNet所说，继续使用这些带有种族色彩的词汇可能会延长种族歧视。一些学者在 2018 年的期刊上写道，“这些术语不仅反映了种族主义文化，而且还强化、合法化和延续了它。”

而 LinkedIn 的软件工程师 Gabriel Csapo 也在 Twitter 上表示，他也正在提出更新 Microsoft 内部库的请求，并删除任何带有种族歧视色彩的短语。

行动

在此背景下，一位Twitter网友的提议，而这一提议得到了GitHub CEO的支持。

@Una Kravets我很高兴将 GitHub 的默认分支结构从『master』改成『main』，我希望我们能和 @GitHub 一起以社区为单位来做这件事……@Nat Friedman这是个好主意！ 我们正在朝这方面进行改进了！

于是自 2020年10月1日 开始，Github上所有的新库便都开始以 main 命名，并开始逐渐的将原先master为主分支的库修改为以main为主分支。

鉴于GitHub有4000多万用户、1亿多个存储库以及至少2800万个公共存储库，这是项艰巨的任务。任何一个规划的失误都会导致Linux内核之类的项目代码无法访问。全球大批企业依赖Linux内核，一旦发生这类事件都可能引发灾难性的后果。

于是，GitHub又做了以下更改以确保万无一失：

• 更新了 GitHub.com以直接重定向master分支到新的默认分支！
• 更新了 Github Pages以支持从任一分支进行部署
• 添加了用户、组织与企业设定以设定默认的分支名与新项目的默认分支名。
  • 需要注意的是，这些设定同时在 GitHub.com与 GitHub API 生效。
  • Git 2.28 也添加了一个类似的设定init.defaultBranch。
• 我们让重命名已有分支更加方便快捷了

参与

如果还是习惯于使用 master 分支，那么大可不用更改继续使用下去。

若想要支持相关的行动，则可以跟随以下的操作将master分支无损迁移到main分支。

本地修改分支

1. 首先将master分支移到main分支下

   1	git branch -m master main

2. 随后将新命名的分支main推送到远程库中

   1	git push -u origin main

3. 再将HEAD指向main分支

   1	git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main

4. 最后删除远程库中旧的master分支即可

   1	git push origin --delete master

在 GitHub 上修改默认分支

用户、组织和企业可以在以下地址修改默认分支名。

• 用户 https://github.com/settings/repositories
• 组织所有者 https://github.com/organizations/<组织名>/settings/repository-defaults
• 企业管理员 https://github.com/enterprises/<企业名>/settings/member_privileges

参考文献

• < Github Renaming >
• < GitHub to replace ‘master’ with ‘main’ starting next month >
• < Why GitHub renamed its master branch to main >

自己在家里组了一个机柜，有多个服务器设备需要管理。看到 PiKVM 这个项目后觉得非常有趣，很快就搓了一个。

刚搓完的成品就直接固定在一块木板上，随后给木板打了几个孔，直接用螺丝固定在机柜上。说真的，每次看到那个 PiKVM “板子”，我心里都发虚。虽然功能上完全满足了需求，但那几根红红绿绿的杜邦线在外头晃荡，怎么看也不太安全。

不行，这得改。

我手头刚好有一台创想三维的 CR-6 SE，但现在的我对 3D 设计的认知基本还停留在“画个方块”的水平。

既然有了这个需求，不如趁此机会，就自己设计一个外壳吧。

开始设计

最开始的设计是一个凹下去的盒子和一个盖板，直接把 PiKVM 的主板放在盒子里，然后直接盖上盖板。

然而这个设计的缺点是没有考虑到3D打印的局限性。

切片软件跳出“17小时”那个数字的时候，我就开始挠头了。我所持的是一台开放式的 FDM打印机，所以在打印过程中很难保证能完全成功的打印一整个盒子，而且如果打印失败了，就只能重新打印整个盒子，浪费时间和材料。

于是我便将盒子的各个面设计成了单独的部件，这样即使某个部件打印失败了，也只需要重新打印那个部件就好了。各个部件之间用方形点链接，这样就可以保证它们能够正确的对齐并牢固的连接在一起。

出稿，拆件，打印！

那天下午特别闷，房间里全是那种 PLA耗材熔化后的甜腻味儿。设计的底板件的面积比较大，所以在打印过程中出现了翘边的问题。更绝的是，挤出机那边居然开始打滑，“哒、哒、哒”地干磨。我摸了一下挤出机的电机，烫得手指生疼。

原来是打印时间过长，电机过热，耗材全在里头软成烂泥了。

没办法，我翻出个不知道哪儿拆下来的旧散热片，用硅脂粘在在电机上。又掏出个小风扇，直接对着电机吹，试图让它降温。虽然这个方法有点土，但至少确实有效了。

拿着失败件先对一下尺寸，才发现尺寸设计的也有误，空位无法完全对齐，而最终导致其他部件也都无法正确的安装在底板上。

修改，再试打印底板。空位确实是对上了，可惜仍然出现了翘边的问题。考虑到材料的浪费和时间的消耗… 将就着用吧。

随后就是剩余部件的打印了。一样的，打印，翘边，再打印，失败，再打印，炒面，打印……总之就是反复的失败和打印，直到最后所有部件都成功的打印出来了。

中途X轴的电机轴居然还断了，得亏还有备用的42步进电机，不然就只能等快递了。要不然说 3D打印 的本质是修3D打印机呢(

剩下的就是喜闻乐见的最终组装了。由于之前设计的连接点比较牢固，所以组装起来还是比较顺利的。

成品还是不错的。虽然表面还有点拉丝，虽然有点寄出缺陷，虽然有点翘边，虽然一捏就容易变形…但还是非常满意的。毕竟这是我第一次设计和打印3D模型，能成功的完成已经不错了。

思考与总结

回望这次从 0 到 1 的首次设计，收获远在成品之外：

1. 设计必须服务于工艺。在电脑里画出的精美模型，如果无视物理世界的重力、热缩和机械精度，那只能称之为“数字雕塑”。优秀的工程师应当提前在脑海中模拟打印机的每一个动作，根据设备特性去倒推零件的结构，这远比画图本身更重要。

2. 模块化是风险管理的必修课。整体式设计虽然美观，但在抗风险能力上极其脆弱。将复杂系统拆解为可替换、可重构的小模块，不仅适用于软件开发中的解耦，在物理制造中同样是节省成本、提高迭代效率的黄金法则。

3. 拥抱“不完美”的勇气。工程实践中没有绝对的完美。为了进度而妥协的微小翘边底板、为了强度而增加的粗糙加固筋，都是解决现实问题的勋章。完成优于完美，在不断的反馈循环中迭代，才是技术进化的唯一路径。

如今这机器仍然在我家机柜里默默地工作着，虽然外表看起来只是一个普通的塑料盒子，但它背后却凝聚了我无数次的尝试、失败和改进。

个人一周使用心得。
视频为主观言论，仅对本人手上的这对耳机负责哦。

希望MIUI尽快更新放出入口叭，太难找了。

YourCraft Team 2021
YC小游戏① 966485310
YC小游戏② 973478638
————————————
该视频在决斗游戏内部测试中录制，该视频录制过程中没有任何动物收到伤害。

YourCraft Team 2021
YC小游戏① 966485310
YC小游戏② 973478638
————————————
该视频在决斗游戏内部测试中录制，该视频录制过程中没有任何动物收到伤害。

如果你想要这个软件的话，可以私信给我你的邮箱，我看到后会尽快发给你哦~

使用aliyun DDNS 支持A记录和AAAA记录，公网IPv6均可正常使用。

--- 2021年11月1日更新
项目最近重构了一次，并公开于github，喜欢的小伙伴可以star一下哦~

项目地址 https://github.com/CarmJos/AliDDNS-Updater
软件下载 https://github.com/CarmJos/AliDDNS-Updater/releases

后记

本项目代码已开源，见 cn2b2t-project(Github.com) 。如有需要可自取，希望能对社区有所帮助。

服务器IP: Kar.RED
直播写的代码！

Kar Network ，中国专业原创MC游戏社区。
青春五年，永不落幕。
服务器地址 Kar.RED (移动 yd.kar.red，联通lt.kar.red)
服务器QQ群 106660674
服务器官网 https://www.kar.red/
-------------------------------------------------------------
制作者： Pinckus
素材来自服务器内玩家，均获得授权。

经过二次计算、润色与优化，kb 3.0正式推出！
这..这也太舒服了吧？？？
果然，多年开发，专业直击PVP领域，不愧是国内元老服务器。

服务器IP: Kar.red

该页面研究的是原版击退算法以及原版击退算法中的各值的作用。

通常我们在调整击退参数的时候，都是靠感觉去调的。Kar团队另辟蹊径，通过数据和代码的方式去理解和调整最合适的击退。为了贯彻我们决心做中国PVP服领头羊的理念，我们决定将我们的研究成果分享出去。

对于代码的分析

EntityLiving类

由于在nms中部分变量经过了混淆，所以只能通过猜测得出这些变量的意义。

在EntityLiving类中，玩家受到伤害时会触发damageEntity函数。

• d0为攻击者位置的X值减去受害者位置的X值，即为从受害者到攻击者的向量的X值。
• d1初始值为攻击者位置的Z值减去受害者位置的X值，即为从受害者到攻击者的向量的Z值。

我们把d0称为x，d1称为z，则

• 若x²+z²<0.0001，则将d1设为一个-1至1之间的随机值*(见下方)，再乘以0.01，同时将d0也进行一次这样的操作。
• 若x²+z²还是<0.0001，则再进行一次，直到不满足这个条件为止。

推测，这可能是两个玩家坐标一样或极度相近的时候，为防止产生0变量，生成一个随机的击退。为验证这个猜测，您可以tp一名玩家，此时您的坐标和这名玩家是一模一样的(其实会产生一点点差别)。接着打他一下，发现击退有时候不在您面前的方向，甚至有时候击退到身后去了。

*编个程统计一下这个随机数，进行100000000次(一亿次)模拟，发现其分布曲线是金字塔形。

它看起来大概是这样：

设该折线的方程为 y = f(x), x∈(-1, 1)很明显，该随机变量X落在(-x, x),x∈(0, 1)的几率为

函数a中

其中的d0和d1即为上方所提的x和z设一个变量f1为

即为该向量在水平面上投影的距离

1. 变量f2为0.4，我们把该值称为水平倍数，或者Horizontal
2. 将motX、motY、motZ分别除以2，我们把该值称为Friction
3. 接着将motX 减去 x / f1 \* f2
4. 将motY 加上 f2
5. 将motZ 减去 z / f1 \* f2
6. 如果motY大于0.4，则设为0.4(这就是原版击退100附魔也无法飞天只能击远的原因)。我们把该值称为VerticalLimit。

以上即为当受害者受到伤害时的原始击退算法。详细讲解请看下方对原版击退算法的理解。

EntityHuman类

接着在攻击者的算法中，再次对产生的击退做出修正。

在EntityHuman类中,攻击者攻击别人时，受害者会受到以下击退

其中，i为攻击者手上武器击退附魔的等级，若没有，则为0。如果攻击者正在疾跑，则i再加1。但是，在著名服务端mSpigot上，无论攻击者是否在疾跑，i的默认值都为1。

yaw是攻击者的朝向的yaw值(欧拉角警告)，是角度制，所以后面的乘以π除以180是转为弧度制。entity.g(double motX, double motY, double motZ)函数为

意思为，该实体目前的速度向量加上这三个值，再把成员ai改为true。回到上面的击退计算，其中MathHelper是一个优化的数学工具人工具类于是，该操作可写为

完成这些操作后，攻击者的motX和motZ各自会乘以0.6。

由于我们平时在竞技场模式中并不会使用带击退附魔的东西当主武器，所以我们不考虑击退附魔。因此，我们只考虑i为0或1的情况。详细讲解请看下方对原版击退算法的理解我们把上面的0.5i的0.5称为疾跑水平加成(SprintHorizontalBoost[SHB])，motY加的0.1称为疾跑竖直加成(SprintVerticalBoost[SVB])

猜测与实验

玩家的击退对于攻击者的朝向只跟攻击者的yaw值有关，也就是环顾四周时的方向、水平方向有关，和pitch，也就是上下朝向无关。无论攻击者从上往下还是从下往上攻击，击退的原始数值只跟攻击者的yaw值和攻击者与受害者在水平面上的投影的向量有关，接着才根据玩家是否疾跑、武器有无击退、是否对该数值进行进一步计算。但是，如果攻击者既不在疾跑手上又没有击退附魔，则击退和yaw也无关。

为了证明这一点，在采用原版击退的情况下，我做了个实验。

先将敌人的坐标和自己的坐标精确控制在整数，以便计算。在所有条件都不变的情况下，攻击受害者，计算击退的大小。

重复3次实验发现，只要条件不变，每次击退都是一样的。

接下来，只改变攻击者的pitch值，其他条件不变。

使用不同的值重复多次实验，发现击退还是一样的。

那么我们只改变攻击者的yaw值，其他条件不变。

神奇的是，yaw值改变后，击退依然不变。

接着，我们给攻击者手上的剑加上击退属性，再进行测试。同样只改变攻击者的pitch值，发现确实跟攻击者的pitch值无关。

只改变攻击者的yaw值，得出以下结果：

多次实验，发现每次结果都与上表相同。在攻击者手上附魔有击退效果时，击退与攻击者的yaw值有关。

我们多测试了如果是受害者yaw、pitch改变是否会影响击退，结果是受害者的朝向完全不影响击退，实验方式和上面差不多，篇幅原因，在此不列出实验详细过程。

测试攻击者疾跑对击退的影响，为了不改变坐标的值，写个插件欺骗服务器，攻击者在攻击时强制变成疾跑状态。测试结果是，疾跑状态攻击相当于手上拿着击退1的武器的效果。

因此我们可以推测，用击退1的武器疾跑着攻击对方，相当于行走状态或静止状态用击退2攻击对方一样。通过实验，证实了该推测。

我们再次推测，在击退与两个玩家的位置和攻击者的yaw值有关，且如果攻击者不在疾跑且手上武器没有击退附魔时，击退就只跟两名玩家的位置有关(除非去掉if(i>0)代码块使motY+0.1强制生效，许多服务端都有这样做)。

用同样的方式，进行以下测试：

• 测试攻击者与受害者所在位置存在高度差时，击退依然与上面一样，证明击退和高度差无关。
• 测试攻击者与受害者所在位置的距离不同时，击退依然和上面一样。
• 测试攻击者向受害者方向走动时攻击，击退依然和上面一样。
• 测试攻击者跳劈，发现无论是上升状态还是下降状态，击退依然和上面一样。

当受害者在空中时受到攻击，一般击退距离会更远。我们通过编写插件，使玩家站在地上(坐标和上面一样)时欺骗服务器玩家在空中，结果发现击退依然和上面一样。推测因为在空中，在掉落到地面之前有更长的时间在空中滑行，造成的更远击退的感觉。由于方块有Friction属性，也就是当玩家落到地面时速度会迅速降低，而空气的Friction比方块的要低，所以玩家在空中能被击退得更远。

各参数的作用

回到参数上，如果不对原版击退的算法做出改变的话，仅修改算法中的几个参数，我们通常用感觉去判断击退的变化。通过了解上方原版击退的算法后，我们就可以知道那些参数的作用了。

原始击退是指在原始计算中得到的motX、Y、Z的值。目前市面上很多击退插件是在最终击退值上乘以某倍数。

Friction

指在受害者受到攻击时，受到攻击前受害者的速度除以的值，一般大于1，这也是为什么它叫Friction(摩擦)的原因。如果该值等于1，那么此时玩家的速度将会加上击退赋予玩家的速度。如果小于1，则玩家的速度会变大再加上击退赋予玩家的速度。如果大于1，则玩家的速度会先缩短，再加上击退赋予玩家的速度。原版该值为2.0

Horizontal

指原始击退参数的motX、motZ减去值的倍数，原版为0.4

Vertical

指原始击退参数的motY加上的值，原版为0.4

SprintHorizontalBoost, SHB

指最终计算完毕的击退中的motX和motZ在攻击者水平面上所指位置(yaw值所对应位置)加上的，攻击者朝向的向量与x和z轴的投影距离，乘以击退附魔等级+若疾跑加一得到的倍数，再乘以的SHB，即原始数据再加上的击退距离的倍数，原版为0.5

SprintVerticalBoost, SVB

指最终计算完毕的击退中的motY再加上的值，原版为0.1

VerticalLimit

原始击退计算中，最高达到的motY，若超过这个值，则设为这个值。原版为0.4000000059604645

对原版击退算法的理解(硬核慎入)

注意，当玩家静止不动或者站在地面时，他的motY为-0.0784，虽然如此，玩家并没有往下掉，这可能是因为脚下有方块的时候就不往下掉，该值可能是为了制造重力。这也可以说明，为什么Friction调到很小(如0.01)的时候攻击玩家几乎无击退，因为这时motY除以0.01会变成-7.84，强力压在地上，导致地面对玩家的摩擦力较大，使玩家难以移动。如果玩家在水中踩到地面，该值为-0.02(也许是重力减去浮力？)

回到一开始，再次看到这个函数

首先受害者受到了攻击者的一次攻击。在计算击退之前，受害者目前的速度除以Friction以缩短目前的速度(见上方Friction)。通常该值只作用于玩家正在移动的过程中，比如疾跑或者正在被击退。如果玩家是静止的，那么motX和motZ都是0。如果玩家是在下落状态，则motY是负值，如果这个时候玩家受到攻击，motY会缩小，下落速度会变慢，这也是玩家在空中掉落的过程中受到攻击时会顿一下的原因。

我们知道：

• d0为攻击者位置的X值减去受害者位置的X值，即为从受害者到攻击者的向量的X值。
• d1为攻击者位置的Z值减去受害者位置的X值，即为从受害者到攻击者的向量的Z值。
• f1为从受害者到攻击者的向量在水平面投影的长度。

因此将d0和d1都除以f1后，向量(d0/f1, d1/f1)的模为1。我们可以把一个长度为1的向量称为单位向量，它通常只为了表示方向。我们将把向量除以它的模的过程称为标准化向量，通常我们在只需要表示向量的方向，长度不重要，且要求该向量模为1的时候这样做。接着两个值再乘以f2，即乘以0.4，表示把向量乘以0.4，也就是说把向量的模改为 根号0.32 。此时，水平面上的击退原始数据就计算完毕了。

至于为什么motX和motZ是减去运算得出的数值，是因为上面算出来的向量是从受害者指向攻击者的向量，我们需要让受害者往后击退，而不是往攻击者飞过去，所以才是减去。

再看到竖直上的击退，直接是目前的motY加上f2。最后，如果motY超过一个限制值(每错，就是那个小数点后老长的)，就设为那个限制值。您可能会问，才加0.4可能会超过吗？确实会，因为上面说过，在受害者再一次受到伤害前，玩家是飞在空中的。如果是combo模式(即玩家受到攻击后的无敌时间很短)，受害者再一次受到攻击时motY还很大，除以Friction后可能依然很大，所以为防止玩家飞起来就设置了一个限制值。

再来看击退修正，

entity.g 这个函数可以理解为原速度加上目标速度，如entity.g(1, 2, 3)就是entity.motX += 1; entity.motY += 2; entity.motZ += 3; yaw * π / 180就是将玩家朝向的欧拉角yaw值(角度)转为弧度。在MC中，yaw的范围是-180~179.9。也就是说，这里的-sin(yaw * π / 180)和cos(yaw * π / 180)依然是生成一个模为1的矢量。为什么模为1？我们把yaw * π / 180设为θ，由sin²θ + cos²θ = 1可知，该向量模为1。将该向量乘以i 再乘以0.5，即可得到水平上修正的向量。其中，i默认为0，如果玩家在疾跑状态则+1，如果玩家手上的物品有击退附魔，则再+击退附魔等级。最后，motY再加0.1。在原版中，如果i>0，才会执行这段代码，如果i=0，则该代码不被执行，也就是说，motY也不会+0.1。在著名服务端mSpigot上，由于i默认为1，且疾跑不影响i的值，所以该代码永远会被执行。最后，把算到的击退交给事件触发器，由事件再次对向量进行更改(如果有的话)，最终将击退速度发送给客户端。

我们可以看到，在算击退原始数据时，击退的方向是以玩家间的位置关系决定的。而在修正的过程中，却由攻击者的yaw值决定。这是印证了上面的实验。所以，如果有个玩家开挂，拿着击退棒背对着打你(请使用不会转过头去打的祖宗级秒被ban外挂实验并关闭反作弊)，你并不会往后退反而往黑客的方向飞去，也是这个道理。

如何抄袭猜测某服务器的击退

如果该服务器的击退数值不是离散的(在相同情况下，击退总是相同，没有产生随机偏移)，且算法为MC原版算法，那么该服的击退数值将非常好猜。

如果击退数值是离散的，那么可以通过统计算出击退数值的分布，然后根据分布的情况模拟随机的数值。比如上方的Math.random() - Math.random()就是-11中呈金字塔形的分布，如果是Math.random()-0.5就是在`-0.50.5比较均匀的分布。除此之外，还有正态分布(new Random().nextGaussian();`)等常见分布方式。

我们需要的随机偏移一般不能太大，所以再乘以一个数如0.1缩小随机偏移量的范围。最后根据统计得出的分布规律猜测偏移的算法即可。

由于每次击退服务器只会给你发送一个速度矢量，不可能在击退的过程中持续修正你的速度(不然延迟高的话就会乱飘。速度给你造成的位移一般由客户端计算)。所以，我们只要得出在各种情况下每次服务器发来的击退赋予的速度即可反推击退数值。

为了方便获取击退数值，我特意写了一个mod来辅助您获取某服务器的击退。版本: 1.8.9请使用最新版本forge运行以保证兼容性(我们使用的forge版本是forge1.8.9-11.15.1.2318)当然，别对该mod抱有太大期望，比如按f3会挡住啥的链接: https://pan.baidu.com/s/11BJ3Rtw-4YTDXECzIXWzAg 提取码: 77f3

这个mod看起来是这样的：

什么？你被查端的时候因为这个太像挂端被封了？怪我咯

• Sprint: 你是否为疾跑状态
• Sneak: 你是否为潜行状态
• OnGround: 您是否站在地面
  • 站在地面，指是否落地并站在地面。
  • 如果玩家被击飞、或者跳跃，该值为false。
  • 不过，如果玩家是在飞行状态，即使他的坐标是贴合地面的，OnGround也一定为false。
• MotionX: 您的速度矢量的X值
• MotionY: 您的速度矢量的Y值
• MotionZ: 您的速度矢量的Z值
• Target: 您正在攻击的玩家的名字
• Distance: 您与您正在攻击的玩家的距离
• ShadowDistance: 您与您正在攻击的玩家的连线在水平面上的投影的距离
  • 为什么需要水平面上的投影的距离？如果您有看上方原版击退的算法的话，您就会明白，击退的y值是另算的，玩家之间的位置关系只会决定x和z，y几乎不受玩家间位置影响。
• TargetSprint: 您正在攻击的玩家是否为疾跑状态
• TargetSneak: 您正在攻击的玩家是否为潜行状态
• TargetOnGround: 您正在攻击的玩家是否站在地面

算法区别

你猜测kb的服务器的算法不一定是原版算法，所以当您暴力计算后没得出任何结果的话，您可以再分析总体数据的变化和产生数据对应的情况去猜测算法。即便算法不一定相同，但只要最终算出来的结果是一样的，您的击退和你在抄的服务器的击退就是一样的。

然后您可以写一个算法暴力算出误差小于0.0001的击退。

如何防止自己服的kb被盗

使最终计算出来的kb离散化，加上一些微小的随机的偏移，且使用的随机算法也是随机的(不然容易被使用统计方法算出随机算法)。总之，尽量在不影响kb总体感觉的情况下提高猜测kb的难度。

关于本文档

文档的主要研究者与作者: LSeng

文档编写参与者: CarmJos

作为 真 · 自主开发 服务器，咱的东西有点小问题正常，视频中出现的所有问题都已经被修复。

服务器ip:sea.privatemc.cn 版本1.7-1.14 (最好使用1.8进入)
开发用了大概200个小时吧23333，熬了几夜写的。

感谢内测元老们的支持~
服务器缺一位腐竹，我没时间管理呀233，如果这里有哪位dalao粉丝量大于5000，可以联系哦~

视频中所有使用外挂的都被VAC了。

我是Carm，和朋友三黑。

遇到对面暴力锁头，美其名曰“Skill！” 。

于是...我们这位大哥看不下去了。

“给你脸了？”

自行百度搜索俄语练习本应该就有了叭。
我知道我写字不好看，请弹幕大神和评论大神手下留情，谢谢。

只是为了表达发现新物品的喜悦，见识短浅，手下留情，谢谢。

如果有帮助到你也欢迎给个三连丫。

傻傻的写了一大堆字，嘿嘿↑。

江浦高级中学2019届合唱团纪念一二九合唱比赛录制。

感谢观看。
墨瓷目前由一群初中生、高中生与大学生维护，从使用他人插件到如今完全自主开发，已过六年。
服务器地址为 Mocimc.cn (MineCraft.net正版) 。
如果您是一位盗版玩家，也可以尝试使用“offline.mocimc.cn”进入。
请注意，我们有权拒绝为盗版玩家提供帮助，如果您有能力，请支持正版。
一切详情，尽在Wiki。
https://wiki.mocimc.cn/#!index.md
---------------------------------------------------------------------------
本宣传片由 小伊(IPlayForLover)、六神(668ms)制作，在此致谢。
---------------------------------------------------------------------------
更多墨瓷相关视频：
《【墨瓷】 决心做中国MC服务器领头羊。请君莫辞。【60FPS】》
https://www.bilibili.com/video/av26958593
《玩自己写的UHCMEETUP是一种什么样的感觉？ 》
https://www.bilibili.com/video/av59986485
----------------------------------------------------------------------------
由Glorstal与EX涛制作的墨瓷首曲电音已发布至网易云音乐。
《墨路》 (Progressive House（Edit）/Future House（Edit）)

作词： 杨子睿
Rap：杨子睿
混音后期： 卡姆姬

看到身边的人都是死扣才抠出来米粒，好难受哦。

感谢观看。墨瓷由私人组织制作，因此视频不含商业类型的推广。
服务器地址为 Mocimc.cn (MineCraft.net正版) 。
如果您是一位盗版玩家，也可以尝试使用“offline.mocimc.cn”进入。
请注意，我们有权拒绝为盗版玩家提供帮助，如果您有能力，请支持正版。
更多的消息，您可以访问我们的Wiki查看。
https://wiki.mocimc.cn/#!minecraft-network.md
----------------------------------------------------------------------------
视频制作总时长(包含拍摄与预处理) 约40小时。
仿照Ultra服务器风格，当然，很明显就可以看出这个视频残了。
由 科莫、冬花、Gkz 、KUMR 录制，晨暮进行AE预处理和后期，KUMR善后。
本视频授权多位UP主发布。
----------------------------------------------------------------------------
更多墨瓷相关视频：
《不好意思，我们开服务器的真的可以为所欲为的。》
https://www.bilibili.com/video/av23029607
《拉坯。墨瓷正努力着。 (墨瓷片头) 》
https://www.bilibili.com/video/av22705492
----------------------------------------------------------------------------
由Glorstal与EX涛制作的墨瓷首曲电音已发布至网易云音乐。
《墨路》 (Progressive House（Edit）/Future House（Edit）)

我开始怀疑我自己是托了。