从内部工程材料到公开文章：YunLab.ai 的 public-safe 写作边界

YunLab 写作手记

这篇我想写得老实一点。

我最近把一些 OpenClaw 里的内部工程材料，改成 YunLab.ai 上可以公开看的文章。刚开始时，我自然觉得：内部材料已经写得很细，任务、结论、复盘、边界、验证记录都在里面，只要把敏感信息删掉，换一种说法，就能变成一篇公开文章？

真正改起来才发现，不是这么回事。

内部材料最大的价值，是让下一个人、下一个 AI、下一次会话能接得住。它追求准确、完整、可追溯：哪里有文件，任务做到哪一步，判断有没有证据，能力是不是仅本地候选，都要写清楚。

但公开文章不是这么读的。一个人打开 YunLab.ai，不是来接手我的本地工程，也不是来审核任务目录。他更可能只想知道：我为什么这样搭个人 AI 系统？踩到了什么坑？哪些判断可以迁移到他自己的系统里？

我第一次改的时候，文章很容易变成内部交接

这是第一个坑。

我会顺着原材料往下写：这里有一个状态文件，那里有一份 handoff，某个模块已通过，审计分数是多少，某个目录下面还有输出。写的时候觉得都对，毕竟这些都是真实发生过的东西。

但页面一渲染出来，味道就不对了。不像一篇文章，更像我把工作台拍了张照片贴出来。信息堆得很满，读者却进不来。更麻烦的是，太多后台暴露在公共视野里：路径、流程、能力边界、未完成状态、内部命名，甚至一些只该留给本地的工作方式。

这时我才意识到，公开写作不是把内部材料"压缩一下"。它要先换问题。

内部材料问的是：这件事做到哪里了，后面怎么接。公开文章问的是：这件事背后有什么经验，哪些部分值得留下来。

打码只能解决一小部分问题

第二个坑，是我一开始太相信"打码"。

我以前以为，把 token、账号、路径、内部名字遮掉，内容就安全了。后来才发现，这只是最低层的安全。真正容易出问题的，不一定是某个字符串，而是文章传递出来的状态。

比如，一个系统其实只是本地候选，不能把它写得像已经在线稳定运行。一个流程只跑过一轮，不能写成成熟方法。一个 agent 还在调人格、权限和记忆，不能只挑好看的部分写出来，让外部读者误以为它已经可以交付。

这类问题不靠打码解决。它靠老老实实写边界。

我现在理解的 public-safe，不只是"没有泄露"，还包括"不夸大、不误导、不把后台当成成果"。

我现在会先问：这篇到底能公开留下什么？

现在我再从内部材料改文章，会先停一下，不急着搬。

先问一个很笨的问题：这堆材料里，真正能公开留下来的东西是什么？

有时候答案是一个坑。比如原始聊天记录为什么不能直接变知识库。有时候答案是一个边界。比如 agent 的角色设定不能只写性格，还要写工作契约。有时候答案是一个方法。比如个人 AI 系统不能只追求能跑，还要能被验证、能交接、能延续。

找到公开角度之后，内部材料才有用。它不再是正文的结构，而是我背后的证据和记忆。我可以用它帮自己想清楚，但不需要完整摆出来。

我现在大概会把内容分成三类：

• 可以公开的，是我踩过的坑、修正后的判断、可以复用的方法，以及对个人 AI 系统的真实体会。
• 需要抽象的，是内部任务、角色、审计、记忆、工作流。可以讲原则，但不要把后台细节原样端出来。
• 必须留在本地的，是密钥、账号、完整提示词、真实目录、未复核结论、私人关系上下文，以及可能被误用的操作入口。

这套分法不复杂，但能帮我避免一种常见错觉：以为文章越接近内部原始材料，就越真实。恰恰相反。公开文章的真实，不是把后台全部摊开，而是把经验讲准确。

所以这不是"降敏"，而是重新写一遍

现在我更愿意把这件事看成一次重写。

内部材料是给系统继续工作的，公开文章是给人读的。前者要保留足够多的操作上下文，后者要把上下文提炼成可理解的经验。两者都重要，但不能混在一起。

所以我写完会先本地预览。光看 Markdown，很容易觉得"差不多了"，但页面一打开，问题会明显很多：像不像我自己说的话，标题是不是太用力，卡片是不是太多，字体读起来累不累，某一句有没有把内部状态说过头。

读起来像说明文，改。像内部报告，也改。像 AI 整理的"最佳实践"，更要改。YunLab.ai 不是要包装成公司官网，它是我给自己的公开实验记录。这里的文章可以有结构，但不能失去个人痕迹。