把本地知识库变成 Codex 工作台：四类任务的整理方法

当资料、项目和对话越来越多，问题通常不是“有没有笔记”，而是下一次让 Codex 工作时，它能不能找到正确的材料，并知道哪些内容可以直接用、哪些只是旧记录。这个方法卡把维护者在 2026-04-08 至 2026-09-19 的本地工作流审计整理成一张可复用的工作台卡片。

1. 先看工作台要解决什么

这套方法适合有一批 Markdown、项目记录或来源资料，想让 Codex 帮忙写稿、做项目执行或维护 Agent 规则的人。目标不是把整座知识库塞给模型，而是让一次任务有清楚的入口、证据和出口。

本案例对维护者的本地工作流审计归纳出四类 Codex 任务：资料采集，内容生产与发布，项目与 SEO 执行，Agent 与日常自动化。这是任务索引与知识库结构的归纳，不是全年任务的完整统计。它们需要的记录不同：来源、草稿、实验台账和执行规则不能混成一篇“万能笔记”。

2. 先把资料分层

准备一个能被人和工具读取的 Markdown 目录。目录名称可以不同，但建议至少有三层：

knowledge/
├── sources/       # 原始链接、会议记录、资料摘录
├── decisions/     # 已经提炼过的判断与规则
└── projects/      # 机会、任务、实验台账和交付记录

先把一条材料放进 sources/，再决定它是否足够稳定，可以提炼成 decisions/。会改变项目方向的内容进入 projects/，并附上下一步和验收条件。不要用文件名或搜索摘要替代事实核对。

3. 让 Codex 先检索再行动

OpenAI 的 Codex 介绍把 Codex 放在真实开发工作流中，而不是只生成一段孤立答案。可以把下面的任务开场白改成自己的目录和主题：

先读取本项目的规则文件，再检索 knowledge/ 中与“{{主题}}”最相关的 5 个文件。
请分开列出：
1. 已有事实和原文位置；
2. 可以复用的判断或代码；
3. 旧资料、推断和需要外部核验的地方；
4. 本次产物要写入的目录和验收条件。
先给检索结果，等我确认后再修改文件。

这一步的重点是限制上下文边界。只给任务相关的文件，不把私人原始归档、无关项目和凭据目录一起交给 Agent。

4. 按任务类型选择产物

任务类型	先读取什么	最后留下什么
资料采集	来源卡、原文链接、日期	带来源和状态的摘录
内容生产	既有判断、读者问题、编辑记录	草稿、发布版本和反馈变化
项目与 SEO	机会卡、关键词核验、风险清单	实验台账、页面差异和数据复盘
Agent 与自动化	触发条件、权限边界、历史失败	可复用任务模板、测试和回滚点

如果同一规则只出现过一次，先留在项目记录里；在同类任务中重复出现并至少一次真实复用后，再升级为 Skill 或长期规则。这样可以避免把一次性的偏好误写成所有项目都必须遵守的约束。

5. 让结果可检查、可回退

要求 Codex 在执行后同时给出改动摘要、测试命令、实际输出和没有覆盖的边界。涉及旧项目时，先保存基线，再让它做最小修改；涉及长任务时，可以参考 OpenAI 的代码现代化案例 中“先理解结构，再分阶段修改”的思路。

一次合格的交付至少能回答四个问题：改了哪些文件？为什么改？怎样证明结果符合要求？如果结果不对，怎样恢复到修改前？只有“看起来完成了”而没有这些证据时，先不要把它写回长期知识库。

6. 把这张卡换成自己的案例

先挑一个范围很小的任务，例如把一篇会议记录整理成选题卡，或把一个站点机会写入实验台账。记录输入文件、Codex 的第一次检索、人工修正、最终产物和下一步。下次遇到同类任务时，比较哪些步骤真的减少了返工，再决定是否把它做成模板。

这套方法不保证任何项目自动获得流量、收入或更高的模型效果。它解决的是工作台的可追溯性：资料从哪里来，判断如何形成，Codex 修改了什么，以及结果怎样被人验收。

相关入口：六课入门 · 案例概览 · 内容标准与反馈