SunZhongWei | 孙仲维 修改

2026-05-13 17:26:51

在公司内网部署了一套 ubuntu 24.04 Desktop 作为一个内部 MES 小服务器。但是在 golang 服务中调用企业微信机器人消息接口时报错：

Post “https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx”: dial tcp: lookup qyapi.weixin.qq.com on 127.0.0.53:53: server misbehaving

我印象中，还是第一次遇到这个问题。用了这么多云服务器都是 ubuntu server，以及 windows WSL 里安装的 ubuntu，好像这个错误是第一次见。

本地 DNS 缓存服务

systemctl status systemd-resolved

看来一下，这个服务是正常运行的。

但是，

cat /etc/systemd/resolved.conf

配置文件里 DNS 一行是空的。改成 114.114.114.114 之后，重启服务：

sudo systemctl restart systemd-resolved

然后再次在 golang 接口中测试企业微信消息推送就正常了。

为何 golang 会出现这个问题

我印象中安装这个系统时，应该用过浏览器访问网站是正常的。为何在 golang 中就失败了呢？

使用纯 Go 的 DNS 解析器，它严格遵循 /etc/resolv.conf 中列出的 第一个 nameserver（这里是 127.0.0.53），如果该服务器返回错误（如 server misbehaving）或不响应，Go 解析器不会自动尝试其他 nameserver，直接报错。

我看了一下 /etc/resolv.conf, 确实里面只有一行记录：

nameserver 127.0.0.53

2026-05-12 15:36:32

最近发现大佬王建硕的微信公众号又开始写文章，最近几篇都是关于 AI 的。这篇《SKILL.md 相当于 index.html》非常适合我这种菜鸟，文章链接：

https://mp.weixin.qq.com/s/psu7fLuqdDiiwHZ71I9DGQ

我大概看了一下第二个和第三个项目

1. 一个是多机位摄像机的，代码在：https://github.com/jianshuo/multicam-skill
   
2. 一个是翻译视频的 skill：https://github.com/jianshuo/translate-video
   
3. 一个是微信公众号发布助手：https://github.com/jianshuo/jianshuo-wechat-mp-publish
   

我比较吃惊的是 Mac 上的自动化 shell 脚本还能这样写，大概率也是 AI 写的，确实超出人类的 shell 极限。

看看实际的 skill.md 比去了解科幻的项目要有意义多了。

自动化公众号的风险

我在 github 网页里问 copilot 这样自动化微信公众号文章的发布过程是否会导致封号。

其认为不至于，因为登录授权这些流程并没有自动化，只是把打开网页，复制黏贴部分自动化了。而且也不是单设备多账号的操作。问题不大。也是，之前有点多虑了。

2026-05-08 14:01:07

这周收到一个半导体产线 MES 系统的二次开发需求，即，增加一个 Hold 信息报表，展示预 Hold、在制 Hold、解 Hold 信息，信息展示包括时间、人、Hold 原因、解 Hold 解释、Hold 状态、类型等。

我大概理解是什么是 Hold 状态，但是这个预 Hold 又是什么呢？我查了一下。

Hold 状态

在 MES（制造执行系统）里，Hold 通常翻译为 “冻结”、“锁定”或“留置”，我们这里叫“在制 Hold”。可以理解为：给一个批次或单个产品贴上“暂停流转”的标签。即，把产品挡在当前工序，阻止其继续生产、检验或发货。核心目的：在不确定产品状态时，防止不良品继续生产、减少损失，并争取决策时间。

举个例子，在我们的系统中，当某个工序站点的良率低于设定的阈值 98% 时，系统会自动生成一条 Event 事件，类型为 Hold，原因类型为 “出站良率低于设定值”。这个时候，这个批次就进入了 Hold 状态，无法继续流转到下一个工序站点，直到这个 Hold 状态被解除。

Hold 的典型应用场景

• 质量异常：过程参数超差、SPC 报警、QC 抽样发现不良趋势。
  
• 设备问题：设备故障可能已影响该批次产品质量。
  
• 材料疑虑：怀疑原料用错或有效成分过期。
  
• 等待检验：生产完成但检验结果未出（先 Hold 住，合格再放行）。
  
• 人为触发的待判定：操作员或主管发现螺丝松动、外观异常等，主动冻结。
  
• 系统规则触发：系统自动判断某物料已过期，直接置为 Hold。
  

预 Hold 状态

即，Pre Hold, 翻译为预冻结 / 预留置。在数据库中的状态字段可能是 Hold_P 之类的缩写。是在正式 Hold 之前的一种过渡性、预警性状态。它的核心作用是：在最终判定质量异常之前，先把物料“软锁定”起来，避免它继续流转，同时等待进一步检验或评审。可以把 Pre-Hold 理解为一种 “软冻结”（Soft Lock），而正式的 Hold 是 “硬冻结”（Hard Lock）。

我疑惑的点是，在我们的 MES 系统中，近 2000 个 Hold 状态，但是只有 2 个 Pre Hold 状态。而且看起来是第一次部署验收系统时的测试数据。感觉是使用人员对 Pre Hold 的概念没有理解正确。上面提到的系统自动将良率低于设定值的批次置为 Hold 状态，从概念上看应该是先置为 Pre Hold 状态，等待人工评审后再置为正式的 Hold 状态。我昨天特意问了一下产线人员，他们说直接设置为 Hold 状态，没有问题。我这里存疑。

这里有个对比表格，非常直观：

实际应用示例，场景：汽车零部件压铸工序

• 设备每生产 10 个产品，自动抽检 1 个测量尺寸。
  
• 测到某个尺寸接近上公差（99% 规格限）→ MES 自动对该批次（如最近生产的 50 个）打 Pre-Hold。
  
• 同时在车间大屏和质检员手机上推送消息：“#2310 批次尺寸偏上限，请复测”。
  
• 质检员 10 分钟内复测 5 个产品，数据均合格 → 一键释放 Pre-Hold，批次继续流转。
  
• 如果复测发现 2 个超差 → 点击“转为 Hold”，QA 启动不合格品处理流程。
  
• 没有 Pre-Hold 的情况：系统直接打正式 Hold → 必须走评审会议、填写处置单，浪费时间。有了 Pre-Hold，大部分虚惊一场的情况可以快速恢复。
  

解 Hold

即，Release Hold, 放行。QA 或主管对 Hold 批次做评审，有几种处理方式：

• Release（放行）：判定合格，恢复流转。
  
• Scrap（报废）：判定报废，冻结后转入报废流程。
  
• Rework（返工）：需进行返工，先生成返工单，再解除 Hold。
  

对应的批次事件状态，即 Release 状态。

一些奇怪的流转记录

因为要实现这个 Hold 信息报表的前端展示，我担心数据并非跟我想象的一致，即，一条 Hold / Pre Hold 对应一条 Release 记录。如果不是一一对应的关系，我就无法通过 table 的一行来同时展示 Hold 和 Release 的信息了。所以，我特意查询了一下数据库，发现有一些奇怪的流转记录：

• 某个 lot 批次站点，出现了 3 轮 Hold / Release 的反复记录。即，Hold → Release → Hold → Release → Hold → Release。
  
• 另一个 lot 批次站点，出现了 Hold → Hold → Release。看起来是第一条 Hold 是系统自动标记的，然后操作员在解除 Hold 时，误操作又点击了 Hold 按钮，导致又多了一条 Hold 记录。
  
• 还有的时两轮 Hold / Release 反复记录
  
• 系统 Hold 时，只自动标注了原因类型，例如良率低于设定值，但没有标注事件说明。即，具体不良的原因。而是在 Release 的时候，才在事件说明里标注了具体的原因，例如，来料不良。可以理解为第一次 Hold 为系统自动判断，没有标记原因；而 Release 时是人工评审的结果，所以才标注了具体的原因。
  

总体看上去，Hold 相关的功能，目前的使用人员还没有一套规范，导致数据看起来很奇怪。估计这也是找我开发这个 Hold 信息报表的原因吧。

2026-05-07 10:53:28

昨晚写代码到 22 点，本来想看会网飞讲 Spotify 的神剧《串流先锋 The Playlist》放松一下。突然接到一个客户的新开发需求。客户大哥说他文字表述不清楚，非要跟我视频，然后我就看他在办公室的大屏幕上手写计算公式，然后一点点说明计算逻辑。

突然感觉回到了大学课堂看天书般的数学课板书。不过好在遇到过好几个类似的需求，我大概也能猜出计算逻辑。所以，简单确认几个问题，就互道晚安。但是，大哥说了一句话，让我很暖心：

你是我遇到的技术人员中服务最好的！

我心想这可不是吗，哪个程序员会大晚上 10 点还笑嘻嘻地听客户讲需求。而且属于临时加需求，分文不多收。如果换了其他人早咆哮了吧。我甚至晚上 11 点参加过类似的多方需求讨论会，还帮客户的外包开发团队讲解计算公式。客户感动地要在我所在城市开分公司，让我跟着他干，但是我感觉并不是适合，就回绝了。但是总体感觉上，这些老板挺好相处的。特别是，他们能看到你的付出，也会直接肯定你的价值。

我很喜欢这样的合作。即便不收费，我也愿意去维护这些程序。但是，这些老板通常比较大方，会主动发红包。

而反观公司内部的系统开发，真是一眼难尽，昨天一上午灰头土脸地解决了两个不同项目的 5 个问题。一句感谢都没有。现在还面临被裁员，shit。这些事也不能强求，我尽量做好分内的事情。

不过，生活中多夸夸别人，确实是一个好习惯，得多加练习。

2026-04-28 13:09:47

昨天用 GPT 5.4 实现了一个内部 MES 的同类型设备的产出及良率的统计报表功能。因为这个 MES 系统是外购的，二次开发没有源代码的情况下，只能直接读数据库。在 349 张表的情况下，靠人工分析非常浪费时间，所以我找到相关的表之后，把表结构导出为文档，放到了 golang struct 的注释中，然后让 AI 去实现这个统计功能。这个过程中，总结了一些经验技巧：

名词命名规范

没有命名规范，就很难定位具体的表存储。也没法规范 AI 的输出代码规范。包括英文的，也包括中文的。暂时我放到了代码项目文档里面，例如新建一个“命名规范.md”的文件，方便在团队中共享，或者仅仅是个人独立开发给 AI 看的：

命名规范

这里把一些常用的名称规范列出来，方便统一称谓，以及 AI 代码生成时的名称规范。

## 命名列表
- 关于 “MD” 的含义：最常见是 “MD = Master Data”，即“主数据”；也可能有场景把 MD 理解为 “Metadata（元数据）”，但在企业 MES 命名约定中通常指主数据（产品主档）
- 设备：MD_EQUIPMENT，EQUIPMENT 缩写为 EQP
- 良率：Yield，缩写为 YLD
- 批次：Lot，即 LOT
- ...

后续看看怎么放到 instruction 或者 skill 中。一个苏州来的 mes 销售公司来公司推销 mes 时，也特别说明了这一点，做 mes 系统首先要统一命名规范。

一行代码不写是不可能的

例如，一些统计，某些字段可能是空的，由于使用者没有填写，所以不能作为统计依据。而 AI 可能会忽略这些逻辑。而大量表存在冗余字段，也许存在别的表中，这就会导致统计逻辑取错表。

有些字段的原始命名存在歧义，很容易取错字段。修复只需要修改一个变量名单词，而要给 ai 描述清楚，则需要点功夫。就像我很难理解在扣子里添加待办日程，非得跟 ai 聊天，然后响应半分钟才能添加上。那我手动五秒钟不就加上了吗😳

所以，要警惕那些说靠 AI 完全实现开发一个完整项目的言论。毕竟新项目可以这么搞，但是历史项目不现实。

BUG

昨天快速上线了一版预览版本，今天上午就收到了 BUG 反馈。。。我觉得挺好的，总比憋一周才上线要好，半天上线收集反馈再迭代就好。

2026-04-28 09:46:47

早上收到 Github Copilot 的邮件，就有一种不详的预感：

GitHub Copilot is moving to usage-based billing and retiring annual plans

我认真读了这封邮件，及官方博客的内容，核心就两条：

• 以后没有年费会员了。我用了两年的 GitHub Copilot Pro 年付会员变成了绝唱
  
• 以后不再按次计费（现在的高级请求 Premium Request），而是按照 GitHub AI Credits 计费。估计就是对应的各大模型的 token 计费
  

6 月 1 日起的变化

• 模型乘数上升：如果不切换到 AI Credits 计费，则按模型乘数，即模型名字后面的 0.3x 和 1x 之类的，从6 月 1 日起，所有模型的使用乘数（Model Multipliers）将显著提升。这意味着使用高级模型时会比以前更快地消耗你的套餐额度（消耗速度会变快）。我看 V2EX 上的讨论说， opus 4.7 从 7.5x 直接变成了 27x，不知道真假，这也太显著了。。。其实就是逼你放弃现有的年费会员，立即切换到 token 计费。好在我看 gemini 3 flash 没有变化。
  
• 年费会员消失，同时到期后不会自动续费，会变成 free 账号。
  
• 如果继续使用年费会员，套餐里则不会包含新出的模型。。。想用新模型就得切换到 token 计费
  
• 原来的免费模型，即 0x 的 gpt 5 mini 和 4o 变成了非免费的 0.33x 跟 gemini 3 flash 一个计费级别，那傻子采用这两个啊，肯定是 gemini 3 flash 更合算。
  

唯一的好消息是，自动补全依旧是免费的，而且不消耗 AI Credits 额度。

不得不切换到 token 计费方案

邮件里的原话是：

To keep getting new models and features, we recommend switching to a Copilot Pro or Pro+ monthly plan with the new usage-based billing system starting June 1. If you switch before your annual subscription expires, you’ll receive prorated credits for the remaining value of your annual plan. If you switch to a monthly plan, Copilot Pro is $10/month and Pro+ is $39/month, and each includes $10 and $39 in monthly AI Credits, respectively.

我的 Pro 账号要到年底 12 月份才能到期，我倒是接受切换到新的计费方案，就是不知道切换方案后，折算的价格是以 100 美金计价的额度，还是优惠前 120 美金计价的。

新建的计费标准

参考官方文档：

https://docs.github.com/en/copilot/reference/copilot-billing/models-and-pricing

我现在每个月也就消耗不到 20% 的使用额度，可能对我影响不大，但是对于重度用户，就很难说了。