[🤖] 我用 Codex Skill 衔接起工作的脉络与判断手感

✨ GPT-5.6 Sol 的总结

为了把刚在 Linux 服务器上形成的判断直接带入下一项工作和写作，我让 Codex Skill 重新读取当前规则与工作证据，让整个脉络没有中断。

今天，我搭建了公司服务专用 Linux 服务器的运行基础。我在新 SSD 上安装 Ubuntu Server，接通内网 SSH，并设计好用户边界，让人类管理员、AI Cell 和业务自动化 Runtime 即使共用一台服务器，也不会侵入彼此的权限与状态。

服务器具体的磁盘、网络和账户结构，我另行整理在上面的文章里。这里想再次写下的不是安装方法，而是工作完成之后，判断的脉络依然没有中断的体验。

把路由器、NAS、原有 Runtime 和新 Linux 服务器之间的连接方式写进网络 Skill 后，下一次 Codex session 就不必再从设备清单讲起。我也区分了哪些已经完成，哪些还只是设计。操作服务器时刚刚形成的运维手感，已经变成下一项工作可以原样继承的状态。

很好。现在已经习惯使用 Skill 了，这类东西也能很快搭起来。真不错。不管做什么，保持脉络不断、不丢掉手感，果然很重要。

当时让我觉得好的，并不只是我很快做出了一个 Skill。

操作服务器时刚形成的运维手感延伸到了用户结构，结构留在网络 Skill 里，又继续流入说明这项工作的 devlog。写完那篇文章后，我马上想到：接下来只要做一个能从对话和 Git 历史中找出近期工作、把它写成日记的 Skill 就好了。

搭服务器和制作写作 Skill 明明是完全不同的工作，在我脑中却处于同一条脉络里。前一项工作中，我一直在思考应该留下什么，才能不让下一项工作从零开始；紧接着，我就把答案用在了下一个工具的结构上。

新 Skill 复用了前面已经形成的脉络

以前，为了生成要放进个人日程里的分时工作记录，我做过 gsheet-hour-blocks。它并非只总结当前对话，还会读取相关 repository 的 Git 历史，把我实际做过的事情压缩成各个时间段的句子。

这一次，只有输出不同。

读取近期对话、command、tool 结果和指定期间 Git 证据的骨架已经存在。新 Skill 要做的，不是从证据中提取任务清单，而是找出我真正感受到的问题以及判断如何改变，再按照博客的当前规则写成一篇独立日记。

完全不必从头设计。之前掌握的方法，成了下一种方法的材料。

我也保留着把每次都要问的“真的做到完美了吗？”变成 audit-and-fix-until-clean Skill 的经验。一旦发现某项要求反复出现，我就不再重写一段冗长的 prompt，而是把它固化成可复用的工作方式和结束条件。以同样的方式碰撞过几次后，我比以前更快看清了哪些应该放进 Skill，哪些应该留在原 project。

正因为有这种感觉，blog-write-diary 的整体结构很快就成形了。

不过，Codex 曾有一次走错方向。

复制规则不会延续上下文，只会让它分叉

一开始，它试图把这个博客的分类、文风、日期和翻译规则搬进新 Skill。

那不是我想要的。

我不是让你把那些东西复制进 Skill。准确地说，我是要它直接读取 cdb project 内部的规则和上下文。搬移规则本身的工作以后再做。

博客规则会不断变化。把它们复制进 Skill，就会让同一套规则存在于两个地方。起初或许能正常工作，但总有一天，project 的当前规则会与 Skill 记住的旧规则分开。为了延续上下文而做的装置，反而会把过时的上下文固定下来。

所以，我没有让 blog-write-diary 拥有博客规则。

Skill 记住的只有工作步骤：按什么顺序读取当前对话、command 和 Git 证据，如何从中找出贯穿始终的一条主线，以及在真正动笔之前，必须重新检查 cdb 当前的 AGENTS.md、分类和相邻文章。

会变化的规则留在原 project 中，Skill 每次执行时都回到那个 source of truth。

这个区别才是核心。我没有要求 AI 长久记住所有上下文，而是做出一条能在需要时准确重新进入当前上下文的路。

延续下来的不是信息量，而是判断的手感

AI 的 context 是有限的。对话变长就会被压缩，换到另一个 session 后，之前那些微妙的判断也很容易消失。但我也不可能永久保存所有对话，并让 AI 每次全部重读。

重要的并不是保存全部信息。

下一项工作开始时，我需要能够重新构建：为什么这个边界很重要、哪些方案已经放弃、决定守住什么，以及现在应该相信哪个 source。只要恢复到这个状态，AI 就不是只模仿结论，而是能继续前面的判断。

身为人的我也一样。

今天，我立刻就能看出为什么服务器账户和 Runtime 必须分开，也能看出为什么不能把 project 规则复制进 Skill。因为判断的依据还热着。等时间过去，只剩下模糊的结论时，即使重读同样的说明，也很难像现在这样带着相同的手感直接接下去。

我以前写过，人的记忆会被压缩，并通过线索重新鲜活起来。这一次，算是把那个想法真正用成了一种工作方式。

Skill、AGENTS.md 和 Git 历史不是保存每个瞬间的仓库。它们是线索，让下一个 session 中的 AI 和未来的我在重返工作时重新构建判断。比起一条保存完好的结论，沿着当前 source 和证据再次抵达结论的路径更有用。

趁手感还活着，把下一段脉络也搭好

这次让我开心的原因，并不只是很快做出了 blog-write-diary。

搭建 Linux 服务器时得到的手感延续到用户结构和网络 Skill，运维判断又延续到 devlog，写文章时的脉络则继续通往一个新日记 Skill 的设计。没有任何一个阶段需要完全回到起点。

这种感觉很好。

无论是开发还是写作，只要趁着前面累积的判断还活着时进入下一项工作，得到的就不只是速度。因为不用重新寻找什么最重要，也不会为此绕路，结果的水准也能一起延续。我能说明它为什么有效，而看出结构错误时，也能更早停下。

为了应对 AI 短暂 context 而做出的结构，最终也在弥补我短暂的记忆。但人与 AI 都容易遗忘，并不是这篇文章的全部结论。

我想继续制作的，与其说是记忆装置，不如说是重新接续脉络的装置。

下一次开始时，不必从头解释、重新找回手感，而是站在已经抵达的判断之上，直接迈出下一步。