个人记录和公开表达有不同的责任。前者需要容纳尚未整理的想法，后者则要对读者、他人隐私和事实准确性负责。把二者放进同一个仓库、再期待每次提交前都靠记忆排除风险，并不可靠。
我最终把发布过程收敛成一条简单的原则：长期保存不等于允许公开，公开必须是一次额外且明确的选择。
两个空间，两种责任
- 活跃记录仓用于当月的计划、日记和工作思路，默认不公开；
- 长期资料库负责归档和整理，也仍然可以保存私密内容；
- 网站只读取资料库中经过明确标记的文章，不读取整个记录仓。
文件移动到长期资料库，并不会自然获得公开资格。这让“我想长期记住它”和“我愿意让任何人看到它”成为两个独立决定。
发布开关必须是确定性的
网站只接受 YAML front matter 中精确的布尔值：
published: true
字段缺失、拼写错误、写成字符串或任何无法判断的情况，都按不公开处理。这是一种 fail-closed 设计：系统宁可少发布，也不替人猜测隐私边界。
从日记到公开文章，不是复制粘贴
原始记录即使包含值得分享的部分，也可能同时混有私人路径、第三方姓名、内部项目、凭据配置、即时情绪或未经核实的 AI 输出。因此更合适的做法是派生一篇新文章：
- 先提取可独立成立的经验或方法；
- 删除身份、组织、设备和本地环境信息；
- 将即时判断改写为有边界的个人经验；
- 对事实、链接和示例重新验证；
- 保留来源文件与哈希，但只放在本地审阅报告中。
这样公开的是经过思考的表达，而不是私人生活的镜像。
让工具只做它能确定的部分
发布脚本可以稳定完成三件事：验证元数据、只暂存明确公开的文件、在构建后检查是否泄露未发布内容。至于一段经历是否适合被所有人看到，仍然需要人工确认。
我喜欢这种分工。自动化负责重复、可验证的边界，人负责语境、关系和后果。它没有消除风险，但让每次发布都更容易解释和复核。
来源说明：本文由 2026 年 8 月的本地网站整理记录脱敏提炼。原始 AI 协作日志未公开；精确来源文件和校验哈希保留在本地迁移报告中。