永夜

不想再守着 Codex 选择 Y/N：我的无人值守运行配置实践

永夜 — Mon, 02 Nov 2026 04:18:11 +0000

使用 OpenAI Codex 执行长时间开发任务时，频繁出现的 Y/N 审批提示让我无法离开电脑。本文记录如何通过全局配置 `approval_policy = "never"` 和 `sandbox_mode = "workspace-write"`，减少人工审批，并解决 Go 编译缓存目录只读的问题。在保留沙盒安全限制的前提下，让 Codex 更适合长时间无人值守运行。

不想再守着 Codex 选择 Y/N：我的无人值守运行配置实践最先出现在永夜。

只是多了 2 个页面，为什么却触发了一次 49→51 的迁移？

永夜 — Fri, 30 Oct 2026 08:29:00 +0000

learn-docs-v1 原本以 49 个页面完成了完整翻译生命周期，后来才发现 /doc/ 和 /doc/install 也应该属于同一个内容包，于是不得不进行一次 49 → 51 Page 的正式成员迁移。表面上只是增加两个页面，实际却需要重新处理成员权威、候选快照、历史继承、独立审核和最终确认之间的关系。本文记录这次迁移带来的工程成本，并总结为什么新增一批全新页面时，应该尽量在 Generation 开始前完成成员完整性审计：越早发现范围遗漏，越像普通修改；越晚发现，越接近一次正式生命周期迁移。

只是多了 2 个页面，为什么却触发了一次 49→51 的迁移？最先出现在永夜。

一个命令快了还不够：为什么我的性能优化开始转向跨命令环境复用

永夜 — Fri, 30 Oct 2026 07:11:14 +0000

随着 Go 多语言翻译工作流越来越复杂，性能瓶颈开始从单个命令内部转向多个命令之间的重复准备工作。current-check、result-pack、import 等命令虽然职责不同，却会反复重建相似的当前状态、历史审核链、回执、SHA 和身份标识。本文记录性能优化思路从“单命令内部复用”进一步转向“跨命令共享已验证执行环境”的过程，并讨论为什么共享环境不能等同于永久缓存、为什么冷启动必须始终独立正确，以及性能优化为什么不能绕过当前性和失效检测。

一个命令快了还不够：为什么我的性能优化开始转向跨命令环境复用最先出现在永夜。

BeWild ChatGPT Plus 3 个月套餐第 3 个月续订再次失败：取消套餐后修复成功，菲律宾比索计价与 Codex 权益观察

永夜 — Thu, 29 Oct 2026 11:20:27 +0000

2026 年 10 月 29 日，BeWild ChatGPT Plus 三个月套餐第三个月续订再次失败。本文记录取消官方订阅、重新提交 Session、恢复 Plus 的完整过程，并分析菲律宾比索 PHP 982.14 计价背后可能存在的成本与利润因素。此外，修复后 Codex 的五小时及每周额度先保持不变，随后同时恢复至 100%，且重置周期发生变化，可能与重新订阅有关。结合实际账单与截图，分析第三方代充服务的可靠性、用户体验及订阅状态同步问题。

BeWild ChatGPT Plus 3 个月套餐第 3 个月续订再次失败：取消套餐后修复成功，菲律宾比索计价与 Codex 权益观察最先出现在永夜。

同一个 Go 语言之旅网站，Bing、Google 和百度的搜索表现差距有多大？

永夜 — Tue, 27 Oct 2026 05:15:29 +0000

对比个人 Go 语言之旅网站在 Bing、Google 和百度三家搜索引擎中的收录及搜索表现。Bing 已索引 103 个网址，Google 已收录 96 个网页，两者不仅在 AI 概览中引用了网站，而且在搜索“go 语言之旅”时，常规搜索结果均出现在第一页。相比之下，百度虽然已有 84 个页面被索引，但约两个月内仅获得 3 次展现、0 次点击，手动翻查前 20 页搜索结果也未找到网站。本文结合站长平台数据与实际搜索截图，记录三家搜索引擎之间的明显差异。

同一个 Go 语言之旅网站，Bing、Google 和百度的搜索表现差距有多大？最先出现在永夜。

命令明明失败了，为什么最后还是 PASS？一次 Shell 自动化的 fail-closed 教训

永夜 — Mon, 26 Oct 2026 03:48:46 +0000

一次 Generation Bundle 当前性检查中，我误用了不存在的 generation-bundle check 命令。脚本虽然检测到失败并打印了 RESULT=FAILED，却因为在顶层子 Shell 中错误使用 return，没有真正停止执行，最终又打印出了一个伪造的 RESULT=PASS。本文记录这次故障的发现、恢复和修正过程，并讨论为什么 FINAL 只是摘要而不是权威状态、为什么后续成功不能覆盖必要检查失败，以及正式工作流中的 Shell 控制流为什么同样必须遵循“无法确认时按失败处理”的原则。

命令明明失败了，为什么最后还是 PASS？一次 Shell 自动化的 fail-closed 教训最先出现在永夜。

一个候选快照为什么突然多出 122 个单元？从隐式范围到显式内容包契约

永夜 — Mon, 26 Oct 2026 03:09:06 +0000

在为 site-v2-shell 首页创建候选快照时，本应只有 1 个页面翻译单元，结果却意外生成了 122 个单元。问题并非数据损坏，而是命令没有显式绑定内容包，底层流程落入了 Tour 的默认范围。本文记录这次真实故障的发现与修复过程，以及为什么错误的正式产物不能直接删除、为什么内容包本身就是工作流的权威边界，以及正式命令为什么宁愿多写一个参数，也不应该依赖隐式范围猜测。

一个候选快照为什么突然多出 122 个单元？从隐式范围到显式内容包契约最先出现在永夜。

保护机制也会保护错东西：为什么一个 Documentation 能阻塞整页修订？

永夜 — Fri, 23 Oct 2026 10:52:50 +0000

在 Go Learning & Documentation v2 的翻译流程中，protected representation 用来防止 Generation 修改 Go identifier、URL、链接绑定和其他机器语义内容。但保护机制本身也可能出错：一次正式 QC 已经明确指出某个可见自然语言需要修订，可当前 protector 却把它错误分类成 opaque protected content，导致 Generation 即使完全理解 Reviewer finding，也没有合法方式修改它。本文介绍为什么“保护得更多”并不一定更安全，为什么不能让模型直接修改 protected token，也不能从目标译文重新 Protect 来猜 token mapping，以及为什么修正 parser 后仍不能改写旧 batch。文章进一步说明 representation successor 如何在保留历史 evidence 的同时，把同一个 physical Page 从旧 formal representation 安全衔接到新的可编辑表示。核心结论是：语言质量授权和编辑能力是两层不同的 authority；当 representation 无法表达一个合法修订时，应该修复表示能力，而不是放宽模型边界。

保护机制也会保护错东西：为什么一个 Documentation 能阻塞整页修订？最先出现在永夜。

页面明明是我自己的，为什么不能直接重写？从 /translation/ 改版看 immutable source 与 replacement successor

永夜 — Fri, 23 Oct 2026 09:03:30 +0000

在 Go Learning & Documentation v2 中，我准备重新整理项目自有的 /translation/ 页面时，发现一个看起来很反直觉的问题：页面明明是自己维护的，却不能像普通 HTML 一样直接重写。原因是旧正文已经被 corpus、Generation、Review、closure 和 Surface 等正式流程消费，过去的证据都绑定着当时的 exact source。本文介绍为什么 immutable 并不意味着内容永远不能更新，而是历史事实不能被原地覆盖；同时区分 append successor 与 consumed-source replacement successor，说明为什么追加新内容可以大量继承旧语言结果，而改写、删除、重排旧正文则必须建立新的 source authority。文章还讨论了为什么 renderer 不能绕过正式语言流程直接注入中文，以及为什么 source ownership 和 source lifecycle 是两回事。核心结论是：当一份内容已经进入正式多语言生命周期以后，修改它不再只是编辑文件，而是在执行一次内容版本迁移。

页面明明是我自己的，为什么不能直接重写？从 /translation/ 改版看 immutable source 与 replacement successor最先出现在永夜。

为什么修完 Reviewer 指出的所有例子，下一轮还是会失败？从 B→revision→B 看同类问题完整性

永夜 — Fri, 23 Oct 2026 03:42:07 +0000

在 Go Learning & Documentation v2 的独立审核流程中，我遇到过一种反复出现的情况：Reviewer 首轮判定为 B，并列出了几个具体问题；Generation 按照这些 examples 完成修订，机器校验也通过，但 successor re-QC 仍然因为同一类别的残留再次判 B。问题并不一定是 Generation 没有修，而是工作流把“Reviewer 举出的例子”和“完整修订边界”混在了一起。本文介绍为什么 finding-anchored 不等于 example-anchored，以及 Reviewer 如何通过 defect category、exact predicate 和 bounded scope 做 same-class scan，Generation 又如何在不扩大修订范围、不进行无关润色的前提下完成 locally complete 的 same-class sweep。核心结论是：真正需要关闭的是审核发现的问题类别，而不是几个碰巧被列出来的实例。

为什么修完 Reviewer 指出的所有例子，下一轮还是会失败？从 B→revision→B 看同类问题完整性最先出现在永夜。