该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://www.yono233.cn/posts/novel/26_3_10_Pandoc

看完了？说点什么呢

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://www.yono233.cn/posts/novel/26_3_5_Carbon

 "headers": {
    "Authorization": "Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImxvZ2luLmlibS5jb20tMjAyNTA4MDgifQ.eyJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiZmVkZXJhdGVkX3VzZXIiOiJyZWd1bGFyIiwiYWRkcmVzcyI6eyJjb3VudHJ5IjoiQ04ifSwicmVhbG1OYW1lIjoid3d3LmlibS5jb20iLCJkaXNwbGF5TmFtZSI6IuW-kCDlhYPpvpkiLCJ1bmlxdWVTZWN1cml0eU5hbWUiOiI2OTUwMDFIM1ZWIiwiYW1yIjpbInVybjppYm06c2VjdXJpdHk6YXV0aGVudGljYXRpb246YXNmOm1lY2hhbmlzbTpiYXNpY2xkYXB1c2VyIl0sInByZWZlcnJlZF91c2VybmFtZSI6Inlvbm8yMzNAb3V0bG9vay5jb20iLCJnaXZlbl9uYW1lIjoi5b6QIiwiaWFtX2F1dGhfcG9saWN5IjoidXJuOmlibTpzZWN1cml0eTphdXRoZW50aWNhdGlvbjphc2Y6YmFzaWNsZGFwdXNlciIsIm5hbWUiOiLlvpAg5YWD6b6ZIiwiZmFtaWx5X25hbWUiOiLlhYPpvpkiLCJlbWFpbCI6Inlvbm8yMzNAb3V0bG9vay5jb20iLCJhY3IiOiJ1cm46aWJtOnNlY3VyaXR5OnBvbGljeTppZDoyNDk2MyIsInJ0X2hhc2giOiJIdEVIeHlxcUtVcmh1d1pzVW5EWVhnIiwidXNlclR5cGUiOiJyZWd1bGFyIiwic19oYXNoIjoiUHYyY241cXk0X0padTNXTkJOS1RZdyIsImF1dGhfdGltZSI6MTc3NDM0MzQ5NiwianRpIjoiaThiM3VnMEZZQmU4MXkzMkV0VG81ZWFtVmx4MjFuIiwiYXRfaGFzaCI6IjVYZDlVTVUzbUE4ZjRuY0EzcWhxaWciLCJleHQiOnsidGVuYW50SWQiOiJsb2dpbi5pYm0uY29tIn0sImlzcyI6Imh0dHBzOi8vbG9naW4uaWJtLmNvbS9vaWRjL2VuZHBvaW50L2RlZmF1bHQiLCJhdWQiOiJOemcwWXpsaVl6QXRPVGhqWlMwMCIsInN1YiI6IjY5NTAwMUgzVlYiLCJpYXQiOjE3NzQzNDM1MDMsImV4cCI6MTc3NDM1MDcwM30.jkdNh6S1gImN7TNGa7cK5qsfWB0QzXK-1HpTN8CzMsA2kQmNtf8tFqt1tGGJpsoJUZcr7PdDsJYBM_Jd3SmbmJgS3LdXX8wMo5BpQpwtDak0zZ6p7MJb2WoE3nRE_gINI9nTAjWS5YA5618W6ZxyWGMUCxeAlzRTYgo4YIqI4RTNA4vWzzlVWcYiOsCc_eKBApg3M2wC2Qlh_CUSI_aC81tDWIgx15In8fcoKRo_31bp93QTLYzQ6ppFuShSzEwSoV69WtnDEdU1qCWepbJnSb1_HcGBOkk7Ca_y2iuFQU3KjBDU-QhHBBj2PMb2ADoDdQz3Lyv-K3p_mV9yl4DJaw",
    "X-MCP-Session": "80762ff3d736424b81cb626a1530a2d8"
  }

看完了？说点什么呢

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://www.yono233.cn/posts/novel/26_3_2_AI

在工程中创建 设计文档.md 以便于记录当前的设计。创建 AI/HANDOFF.md、AI/TODO.md、AI/SESSION_LOG.md 文件以便于后续使用“先读取 AI/HANDOFF.md、AI/TODO.md、AI/SESSION_LOG.md 恢复上下文”这样的提示词在更换环境时同步上下文。

在工程中创建 设计文档.md 以便于记录当前的设计。创建 AI/HANDOFF.md、AI/TODO.md、AI/SESSION_LOG.md 文件以便于后续使用“先读取 AI/HANDOFF.md、AI/TODO.md、AI/SESSION_LOG.md 恢复上下文”这样的提示词在更换环境时同步上下文。

注意：设计文档是一种软件功能和逻辑的描述，以便于使用不同的编程框架重构。需要完备描述软件设计的功能，包括已完成和未完成的所有功能，但无需备注是否完成。不要描述技术栈，不要关联当前项目。

现在请更新 设计文档.md以及AI文件夹中的内容,以和当前的项目现状对齐

看完了？说点什么呢

背景故事

虽然我有数个网站自用在跑，但是服务器这块与我工作无关，永远是小白。

近几个月，一直会遭遇挖矿程序入侵，但是那时候还有腾讯云的主机防护体验卡，只是会通知我然后手动点下修复就好。

过年回来发现，体验卡到期，天塌了。老破小服务器已经满载挖矿好几天。

年后正式启用私有部署的 git 托管管理项目代码，这个中毒问题得好好找下。其实是不想给🐕企鹅送钱。

总而言之，目前的状况是博客前端的端口直接暴露在公网上，next.js 有某种特点(没有深究)被入侵利用，然后污染了前端容器。暂时重新拉取镜像重部署，docker-compose.yml的image段同级增加read_only: true，避免入侵下载挖矿程序，以此临时解决。

本文主要记录一下指令长啥样，因为我记不住。

排查流程

立即止血

找出最吃 CPU 的进程

top -o %CPU

切到 root

whoami
id
sudo -n true; echo $?

杀他妈的 例如我这个挖矿进程的 PID 是 53075，就使用 sudo kill -STOP 53075

sudo kill -STOP <PID>

再看看进程

top -b -n 1 | head -n 15

谁拉的屎

找到真实的可执行文件，将获得一个路径，如果需要清理可以后续进行

sudo readlink -f /proc/<PID>/exe

查看启动命令行，其实是辅助排查，结果“空”表明不是用户手动命令行启动的

sudo sh -c 'tr “\0“ ” ” < /proc/<PID>/cmdline; echo’

查看进程启动时的环境变量，如果看到比较熟悉的词，在这里已经可以找到是什么应用被入侵了

sudo cat /proc/<PID>/environ | tr “\0“ “\n“ | head -n 60

NOTE

如果以上不足以找到根源应用，那么深入排查，以下指令结果无法明示，可以发给 GPT 让他辅助解析并进一步指导

查看进程控制组，比如我这里回复0::/system.slice/docker-9cffb5dca4c53cf437c1499d7df3725132406b42b3e4873837ec1487a7aa2b46.scope，那么已经明确是CONTAINER ID 为这串数字的容器被入侵了

sudo cat /proc/<PID>/cgroup

查看进程基本信息

sudo ps -o pid,ppid,user,cmd -p <PID>

查看父进程信息

sudo ps -o pid,ppid,user,cmd -p $(ps -o ppid= -p <PID>)

查看进程的网络连接情况

sudo ss -antup | grep -E "pid=<PID>," || true

详细列出进程打开的文件和网络连接

sudo lsof -nP -p <PID> -i 2>/dev/null | head -n 50

[!NOTE]

以上这些查询输出，如果看不懂排查不了，就直接丢给 GPT 让他指示下一步就好

我的处理

经过排查，在我的问题环境下，明确了是某个 docker 容器 9cffb5dca4c53cf437c1499d7df3725132406b42b3e4873837ec1487a7aa2b46 引起的，那我这里就直接查下这是个啥就行了。

sudo docker inspect 9cffb5dca4c53cf437c1499d7df3725132406b42b3e4873837ec1487a7aa2b46 --format 'ID={{.Id}}
Name={{.Name}}
Image={{.Config.Image}}
Created={{.Created}}
Entrypoint={{json .Config.Entrypoint}}
Cmd={{json .Config.Cmd}}
WorkingDir={{.Config.WorkingDir}}
EnvCount={{len .Config.Env}}
Mounts={{json .Mounts}}
Ports={{json .NetworkSettings.Ports}}'

回复表明

ID=9cffb5dca4c53cf437c1499d7df3725132406b42b3e4873837ec1487a7aa2b46
Name=/shiroi
Image=ghcr.io/stbanana/shiroi:latest
Created=2026-01-26T07:33:07.293181432Z
......

同时此前查找父进程表明

[lighthouse@VM-20-5-opencloudos ~]$ sudo ps -o pid,ppid,user,cmd -p $(ps -o ppid= -p 53075)
    PID    PPID USER     CMD
   2206    1954 root     next-server (v

另一个侧面验证是，前端镜像备份现在膨胀到了2GB，与我保存的稳定版备份400MB相去甚远。

那我这里可以确认是博客前端的 next.js 直接暴露的问题，但是我又不会修，也不想更新前端到最新版本(in神重构了，同步更新后端和迁移好麻烦)。

那就使用 read_only 部署就可以了，docker-compose.yml的image段同级增加read_only: true，下面是当前的。

version: '3'

services:
  shiro:
    container_name: shiroi
    image: shiroi:local
    volumes:
      - ./.env:/app/.env
    read_only: true
    restart: always
    ports:
      - 2323:2323

本地 docker 镜像压缩包的食用

注意到，上面我使用image: shiroi:local是一个本地镜像，而不用拉取，因为这个镜像来自于一个我保存下来的稳定版压缩包。

其实这个操作我做了好多次，但是每次都会忘得查指令，cd 到压缩包所在处->docker 加载镜像压缩包->打个人看得懂的标签。

类似以下。

[root@VM-20-5-opencloudos ~]# cd /root/mx-space/Shiroi
[root@VM-20-5-opencloudos Shiroi]# sudo docker load -i shiroi.tar
b0f89ac7b966: Loading layer  148.4MB/148.4MB
d3b1ea8ff6e6: Loading layer   5.39MB/5.39MB
2497eefc5264: Loading layer  3.584kB/3.584kB
769a089b3661: Loading layer  30.95MB/30.95MB
8a9366fbc004: Loading layer  1.536kB/1.536kB
556c774c2fcc: Loading layer  8.075MB/8.075MB
55405dd49280: Loading layer  4.096kB/4.096kB
66b48a972c24: Loading layer  24.75MB/24.75MB
7f1566c30993: Loading layer  24.29MB/24.29MB
911870b37b57: Loading layer  27.33MB/27.33MB
14c1060772f2: Loading layer  6.655MB/6.655MB
7be455708435: Loading layer  12.18MB/12.18MB
6fdc0a038ef1: Loading layer  5.213MB/5.213MB
ba8c6d828d78: Loading layer   2.56kB/2.56kB
5c557125ffd5: Loading layer  160.3kB/160.3kB
77abd848d7fc: Loading layer  110.1kB/110.1kB
e7f72ced6a18: Loading layer  111.2MB/111.2MB
0d71f84d6130: Loading layer  23.76MB/23.76MB
dade50077aed: Loading layer  22.65MB/22.65MB
Loaded image ID: sha256:8c476da1052b3d1e26bdaae875b0ac026b6c26869224732f2deee58a8349911a
[root@VM-20-5-opencloudos Shiroi]# sudo docker tag sha256:8c476da1052b3d1e26bdaae875b0ac026b6c26869224732f2deee58a8349911a shiroi:local
[root@VM-20-5-opencloudos Shiroi]#

使用不拉取的 compose 指令部署

docker compose up -d

今天才真正清楚 SPI 外设怎么用捏。

用以下三个典型 API 讨论

发送：HAL_SPI_Transmit_DMA(Spi, RBuf, ui32Len)

接收：HAL_SPI_Receive_DMA(Spi, RBuf, ui32Len)

收发：HAL_SPI_TransmitReceive_DMA(Spi, RBuf, ui32Len)

此前遇到过的问题

作为 spi 主机时，调用接收 api却无法真的收到数据，所以在所有接收处都用了收发 api。

因为 spi 用的比较少，功能也很单一，没有真正考虑过为啥，只当是 api 实现有些问题(因为在底层上又套了兼容层)。

今天重写 spi-flash 驱动，才又考虑这个问题。

总而言之

spi 是一种依赖时钟线边沿做移位的硬件通信，没有时钟，那么主机或者从机都不会真正发送数据。除非是自己奇怪的非标实现。

而且通常来说，只有主机允许产生时钟。

那么问题就显而易见了，起码对于 stm32，只有在发送时产生时钟，所以哪怕是仅接收数据，也要使用收发 api。

接收 api仅在作从机时有意义，或者有 GPT 说的由外部硬件产生时钟(这太恐怖了，真有这种用法吗)。

思考

spi 通信的特性似乎适用于无限地双向通信，不适合任何单向的通信。这会在作为主机尝试大批量的读时存在问题，因为发送线路依然需要占据一块相同大小的 buffer 空间。

可能是 stm32 的 hal 实现问题，但是并没有深究，可能真的遇到再说吧。

在浮点兼容定点的应用时，分辨率的转换很让人头疼，所以有如下的宏方法。

对应关系类似 2--0.01--100 ，可以覆盖倍乘、倍除的数值关系。

/* 辅助宏 */
#define LIB_DEC_FACTOR_TOKEN(dp) LIB_DEC_FACTOR_##dp
#define LIB_DEC_FACTOR_0         1
#define LIB_DEC_FACTOR_1         10
#define LIB_DEC_FACTOR_2         100
#define LIB_DEC_FACTOR_3         1000
#define LIB_DEC_FACTOR_4         10000
#define LIB_DEC_FACTOR_5         100000
#define LIB_DEC_FACTOR_6         1000000
#define LIB_DEC_FACTOR_7         10000000
#define LIB_DEC_FACTOR_8         100000000
#define LIB_DEC_FACTOR_9         1000000000
#define LIB_DECIMAL_FACTOR(dp)   LIB_DEC_FACTOR_TOKEN(dp)

#define LIB_DEC_STEP_TOKEN(dp) LIB_DEC_STEP_##dp
#define LIB_DEC_STEP_0         1.0f
#define LIB_DEC_STEP_1         1e-1f
#define LIB_DEC_STEP_2         1e-2f
#define LIB_DEC_STEP_3         1e-3f
#define LIB_DEC_STEP_4         1e-4f
#define LIB_DEC_STEP_5         1e-5f
#define LIB_DEC_STEP_6         1e-6f
#define LIB_DEC_STEP_7         1e-7f
#define LIB_DEC_STEP_8         1e-8f
#define LIB_DEC_STEP_9         1e-9f
#define LIB_DECIMAL_STEP(dp)   LIB_DEC_STEP_TOKEN(dp)

/* 统一管理 */
#define RES_DEC_ACVoltage       2 /* 交流电压 */
#define RES_DEC_LoadACCurrent   2 /* 交流电流 */
#define RES_DEC_OutputACFreq    2 /* 交流频率 */
#define RES_DEC_PowerFactors    3 /* 功率因数 */

#define RES_DEC(name)           (RES_DEC_##name) /* 小数位数 */
#define RES_FACTOR(name)        (LIB_DECIMAL_FACTOR(RES_DEC_##name)) /* 倍数 */
#define RES_STEP(name)          (LIB_DECIMAL_STEP(RES_DEC_##name))   /* 小数 */

使用类似如下

int a = RES_DEC(ACVoltage);    // =2 获得小数位数
int b = RES_FACTOR(ACVoltage); // =100 获得对应倍数系数
int c = RES_STEP(ACVoltage);   // =0.01 获得对应小数系数

辅助函数

哪怕具有倍数系数，在浮点转为定点数时依然面临四舍五入的小问题。可能可以结合以下函数进行。

#include <stdint.h>
#include <limits.h>

/**
    * @brief  浮点值按十进制位缩放并四舍五入后转整型。
    * @param  value:          期望被转化的浮点值
    * @param  decimalPlaces:  缩放的小数位数(10^decimalPlaces)
    * @retval 四舍五入后的缩放结果，超限时按int32范围饱和
*/
int32_t LIB_FloatToScaledInt(float value, uint8_t decimalPlaces)
{
    double scale = 1.0;
    for(uint8_t i = 0; i < decimalPlaces; i++)
    {
        scale *= 10.0;
    }

    double scaled = (double)value * scale;
    if(scaled >= 0.0)
    {
        scaled += 0.5;
    }
    else
    {
        scaled -= 0.5;
    }

    if(scaled > (double)INT32_MAX)
    {
        return INT32_MAX;
    }
    if(scaled < (double)INT32_MIN)
    {
        return INT32_MIN;
    }

    return (int32_t)scaled;
}

一个应用示例

SelfACRunSetting[0].ACVoltage = 123.45678;

int a = LIB_FloatToScaledInt(SelfACRunSetting[0].ACVoltage, RES_DEC(ACVoltage); // = 12347

st hal 库的 HAL_Delay 以毫秒为单位。

HAL_Delay(2); // 实际延迟3ms
HAL_Delay(1); // 实际延迟2ms
HAL_Delay(0); // 实际延迟1ms

没错，他的实际延迟会比传参 +1。

此前 某个Example 有觉察并且处理这个问题。

但是由于平常都没用过 HAL_Delay，今天又忘了。记录一下以防过两天要用到吧。

今年接下来的时间大概率会摆烂，不可能有任何博客产出，值此双十二下班前，来篇总结然后在今年忘掉博客吧。

起始

今年开始于对 HIL 设备的研究，围绕某篇论文及其领域相关的其他论文实现了电路矩阵化仿真，最后实现了一个 py 的原型算法程序，并且用 C 进行了工程化，支持导入 PSpice 、PSIM、 simulink 的 xml 文件。看起来对电力电子的常见拓扑仿真效果还不错。

虽然最后并没有落地成产品，但也算是告一段落。

这并不是我感兴趣的事情，只是领导吩咐我研究一下。

这也是今年唯一拿得出手的技术领域的探索。

其他

也尝试了一些乱七八糟parasoft 测试框架、QEMU MCU外设行为仿真等等道听途说来看起来很厉害的东西，但最终都是因为某些工作上的事情打断了一下，然后就懒得搞了，并没有阶段性成就，也没有总结成经验文章。

另外关于本行业的个人经验积累无法言说，尝试了技术性不强的玩意倒是有一些收获。

PlatformIO+arduino 开发 ESP32——ESP32玩具 - 土星环的基地

MCU-py后端-web前端的方案验证——数据采集卡 DAQ 的探索 - 土星环的基地

去年做的开源库居然真的有使用者给我捐钱钱了，太棒了！！

stbanana/modbusX: modbus protocol support

懒狗的旅行

今年有1周(云南)+1周(游轮)的旅行，日均步数不超过5000，非常愉快轻松。

云南是和刚硕士毕业的同学们一起去的(计划5人实到4人)，正好他们趁上班前 GAP 一下(我跟着混一混)，总体就玩了昆明-香格里拉。

可能由于在非节假日，整个体验非常棒，消费非常低，比老家小县城还低。我们大多数时间都呆在民宿打麻将or网吧上网，去景区逛的时间日均不超过6小时。

整个过程都挂着action5 pro有记录，而且我号称将出一篇博客分享，但是我太懒了，一直没有审查视频截一些片段，所以就算了。

在云南最刺激的应该是我开着租来的车载着同学们，差点在高速上车毁人亡，太棒了，被永久剥夺开车权，

游轮是和老姐一起去的，老姐老早就订好了船票，可以顺便看个展，再顺便带着我玩一下，短航线总体玩了上海-济州岛-福冈。

上海体验很糟糕，各种消费都很高，哪怕我们基本在 citywalk 当街溜子，打车、餐厅、住宿等等费用依然很高。被老姐带着看了一个艺术展，我也算半个艺术院校出身:-D大概算吧，上海的展体验就是很棒，奇妙的气息。

第一次游轮游，这种旅游方式太适合我了，不用考虑住宿、路线、交通等等问题。游轮的话就是晚上都在海上飘着，上午靠岸把人丢下去，晚上自己回到船上来。

韩国的话，打车很困难，我们找了一对车搭子。离开船的时候他们用 Uber 死活打不到车，我用韩国本土的 Kakao T 打到了。回船的时候 Kakao T 又死活打不到，用 Uber 打到了。

日本 Uber 打车很快。

整体还是街溜子策略，我们体力都不怎么样，走一会儿就得蹲十几分钟抽支烟缓一缓。更多时间也是最舒服在阳台上躺着看海，什么都不做是最棒的！我在阳台鬼哭狼嚎一路终于学会了张惠妹的听海。

生活

基本五天八小时了一整年，或许不到八小时，我经常地睡不醒请假半天。

后半段开始，日常都避开人在生活，所以心理比起去年健康了很多。

我仍然喜欢日常一个人呆着，我难以维持长久地与人相处，必须得不时自闭数天或数周才舒服。

基本放弃了所有自律，还是决定躺下自然地流向令自己舒适的生活方式。

关于未来

目前迷茫中，没有明确的目标。或许应该考虑一下AI+量化交易有没有搞头？

被我发送此文章的同事将被我打上 不善沟通且我将避免与其沟通的标签

除非深入学习此文的沟通技巧并付诸实践

示例

一个很坏的沟通方式(精简版)

>> 我这里通信不上，是什么问题
<< 请问是什么机器呢
>> ASXXX    // 一种交流源机型
<< 长什么样子？拍给我看一下    // 有时公司会创建一种新机型，并烧录我的固件，但我并不知情
>> [图片]
<< 通信过程告诉我一下，截图
>> [图片]
<< 也就是说现象上 *idn? 可以通信，但是 **** 这个指令不行？ // 此时我会打开工程审查
>> 是这个现象
<< 代码来看支持的，用的什么通信接口？
>> GPIB
<< 看下版本号呢？
// 此后一整天没有答复，我将无比讨厌这种行为
>> 昨天那个 **** 指令还是不行
<< 看下版本号呢？
>> 1.2.3
<< 串口尝试有没有问题
>> 试过没有问题
<< 偶发还是一直都会通信不上？
>> 偶发的，跑很长时间后会出现
<< 我没有遇到过这样的情况，看起来像是硬件问题，你是要做什么？ // 此时我会再次打开工程审查
>> 是有xx客户要买这个机器，我测试一下他们需要的指令和功能。
<< 你用的什么GPIB接口？
>> 我不知道
<< 嗯我基本确定是接线或者接口有问题，找xxx/*某个FAE*/帮你看一下吧。

一个相对好的沟通方式

>> 有xx客户要买ASXXX型号机器，我测试一下他们需要的指令和功能。 // 你的目的是什么？
    客户需要GPIB通信，我尝试了 *idn?、VOLT? 等常用的指令。    // 你做了什么？
    测试到****指令时发现偶尔没有正常回读。                    // 出现了什么问题？
    我又尝试了串口，这个指令是有回读的。                      // 你又依据经验做了什么排查？
    我在公司一楼测试的，使用的一楼的公用机，机器软件版本1.2.3。 // 一些不算关键的环境信息帮助我分析。
    [图片]                                            // 现场是什么样子
    [图片]                                            // 你在电脑上操作是什么样子
<< 应该是接线或者接口有问题，找xxx/*某个FAE*/帮你看一下吧。

宗旨是不要假设我知道所有的情况，我不是安排你工作的人，你应该主动尽可能详细地描述你的现场是什么情况，你的操作过程是什么，你有没有自行做过一些排查尝试。尽可能不带判断地详细地描述物理世界发生了什么，看到了什么现象。

第一个方式提问者花了两三个小时自己排错自己思考，也进行了很多尝试，并不能说他不努力。 但在沟通过程中他将自己前两三个小时的努力化作了泡影，因为我并不知道他到底做了什么事情，我会让他按我的猜测方向再做一次操作并告诉我现象。 并且在来回提问拉扯的过程中再次浪费双方半~两个小时。

假设提问者仔细考虑过自己到底做了什么操作，并花费20分钟提炼编辑发给我。 采用第二种提问方式，我将很快锁定究竟是什么问题。浪费提问者20分钟，我则几乎不用太多时间。

一些摘录自其他文章的本质技巧

来源自

ryanhanwu/How-To-Ask-Questions-The-Smart-Way: 本文原文由知名 Hacker Eric S. Raymond 所撰寫，教你如何正確的提出技術問題並獲得你滿意的答案。

tvvocold/How-To-Ask-Questions-The-Smart-Way: How To Ask Questions The Smart Way 《提问的智慧》中文版

群友巨著——《如何不像弱智一样提问》

我自己的小巧思

提问应明确但不代表详细无用

对于真正高明的提问者来说，指出核心问题并附加合适的补充描述，是一种没有压力的事情。他们当然也不可能看到这篇文章。

我希望看到这篇文章的读者，尽可能提取出你认为最明确的提问，和最合适的补充描述，放在提问最前面。

但你自认为的明确当然不可能事实上明确，请

同时编辑出完整的操作流程，你到底做了什么，尽可能详细地描述，作为补充之补充信息，附在提问后，这将给回答者了解情况提供极大的便利。请相信回答者的能力，你花费两三个小时编辑的内容，他们依然可以在十分钟内看完。

提问不要分段发送

请在文本编辑器真正编辑好“问题”，并自己阅读一遍后统一发送。

这样将极大节省回答者时间，并且回答者可以像解难题一样专注，而非像刑侦不断发现新的线索、从头梳理打断工作，这通常会使技术从业者非常恼火。

別用低聲下氣取代你真正該做的事

有些人明白他們不該粗魯或傲慢的提問並要求得到答覆，但他們選擇另一個極端 -- 低聲下氣：我知道我只是個可悲的新手，一個失敗者，但...。這既使人困擾，也沒有用，尤其是伴隨著與實際問題含糊不清的描述時更令人反感。

別用原始靈長類動物的把戲來浪費你我的時間。取而代之的是，盡可能清楚地描述背景條件和你的問題情況。這比低聲下氣更好地定位了你的位置。

描述目標而不是過程

如果你想弄清楚如何做某事（而不是報告一個Bug），在開頭就描述你的目標，然後才陳述重現你所卡住的特定步驟。

去掉無意義的提問句

避免用無意義的話結束提問，例如有人能幫我嗎？或者這有答案嗎？。

这不会使你显得很礼貌。

首先：如果你對問題的描述不是很好，這樣問更是畫蛇添足。

其次：由於這樣問是畫蛇添足，駭客們會很厭煩你──而且通常會用邏輯上正確，但毫無意義的回答來表示他們的蔑視， 例如：沒錯，有人能幫你或者不，沒答案。

一般來說，避免用 是或否、對或錯、有或沒有類型的問句，除非你想得到是或否類型的回答。

問題解決後，加個簡短的補充說明

对于我而言，所有的问题都应该最终有定论，否则在我这里永远悬而未决。

别人给我的问题，这个定论依赖于别人给我。

所以无论是否真正解决，还是在项目中将其搁置，或者需要我做修改，或者是其他人的修改可以糊弄过去。

在一周内应当给我有一个答复。

如果问我问题，但不把最终结果告诉我，那么我可以确定你是傻逼，并在后续拒绝与傻逼的一切沟通。

学会圈出重点

截图截一半，父母少一半。

仅截图某个关键信息或其上下两行，这不叫圈重点。需要携带合适的上下文信息，否则根本无法分析。

如果你不擅长分辨什么是上下文，请直接截图整个窗口、整个屏幕，并用截图工具自带的划线功能圈出重点信息。

请有自己的目标感

你的目标是“解决问题”。

请不要一次性抛出很多问题，请找到最棘手最难处理的编辑提问。

我知道你很急，但是先别急，很多的问题占据我的脑子只会使我宕机摆烂，对“解决问题”不可能有帮助。

通常我是一个热心肠且有礼貌的人，我喜欢任何人给我带来问题并解决，仅仅寻求这样的思维健美操。 假如假如，我一旦确认你是傻逼，且不自知，那么你会感受到我全方位的阴阳怪气。

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://www.yono233.cn/posts/shoot/25_11_11_DAQ

看完了？说点什么呢