真实工作结束后，经常会留下很多材料：需求记录、脚本、截图、运行日志、复盘和聊天片段。它们不是天然的案例，也不是可以直接发布的文章。把文件搬进一个“知识库”目录，只解决了存放，没有解决复用。
更有效的做法，是让同一段工作沿着不同用途流动：先形成可核对的项目记录，再提炼为公开案例和方法文章，最后把稳定步骤固化成下一次可以调用的 Skill。
第一层：保留事实，不急着写故事
项目记录首先服务事实核对。它应该回答：谁提出问题，原流程是什么，输入输出有哪些，做了什么，当前运行状态如何，证据来自哪里，还有什么没解决。
这一层可以保留较多内部细节，但必须有清楚边界。原始材料、判断结论和公开表达不能混在同一段里，否则后面很难知道哪句话是记录、哪句话是解释。
我会把确定事实、业务确认和内部估算分开标记。这样几周后回看时，仍能知道一个数字为什么存在，而不是凭记忆把它写成精确结果。
第二层：案例不是项目总结的缩写
公开案例面对的是不了解上下文的人。它需要重组信息，而不是把内部文档删短。
一个可判断的案例至少包括业务问题、真实约束、本人职责、处理方式、运行状态、证据来源、仍未解决的问题和披露边界。客户名称、员工身份、订单、价格、内部路径和原始截图需要移除；不能脱敏的证据宁可不公开。
案例的作用不是证明“我什么都能做”，而是让读者判断：这个人如何面对约束，如何区分证据，方法是否适合自己的场景。
第三层：文章提炼判断，不复述项目
一段工作里最值得写的内容，往往不是功能清单，而是一个可迁移的判断。例如：为什么脚本跑通不等于落地，为什么下载量不能直接代表内容效果，为什么高风险流程应先切一个可回滚的单点。
文章围绕一个判断展开，用项目经验提供依据，同时去掉不必要的内部背景。这样它既能被外部读者理解，也能在下一次类似项目中反过来帮助决策。
第四层：稳定步骤才进入 Skill
不是每次做过的动作都值得变成 Skill。只有当步骤会重复、输入输出相对稳定、错误边界清楚，并且下一次执行可以验证时，才适合固化。
Skill 应该记录触发条件、必读资料、执行顺序、停止条件和验证方式。它承接的是已经被实践验证的方法，不是把一次项目中的临时做法永久化。
让输出反过来改善下一次输入
这条链路最终形成一个循环：项目记录保存事实，案例暴露证据缺口，文章提炼判断，Skill 固化可靠步骤；下一次工作再使用这些判断和步骤，并产生新的运行证据。
知识真正“流动起来”，不是因为目录更完整，而是每一层都有明确用途、进入条件和下一站。沉淀的目标也不是保存所有内容，而是让真实工作更容易被复核、表达和再次使用。