$ man context-wiki/taxonomy

你组织文件的方式就是上下文工程。如果你的仓库一团糟，你的 AI 输出也会一团糟。不是因为模型被混乱的文件夹搞糊涂了。而是因为混乱的文件夹意味着模型找不到它需要的东西、加载了错误的文件，或者完全跳过了上下文。可预测的结构意味着可预测的结果。当每个合作伙伴文件夹都有相同的子文件夹（research/、prompts/、workflows/、resources/）时，Claude 确切知道去哪里找 ICP 定义、营销文案和资格认证提示。它不搜索。它不猜测。它去可预测的位置读取文件。

模式

content/drafts/ 存放进行中的工作。content/published/ 存放已发布的带日期前缀的文章。partners/{name}/research/ 存放 ICP、角色画像和竞争情报。partners/{name}/prompts/ 存放 Clay 资格认证和研究提示。partners/{name}/workflows/ 存放营销序列和路由逻辑。skills/ 将每个可重用的工作流存为 SKILL.md 文件。data/ 存放生成的资产如仪表板和进度统计。scripts/ 存放 Python 自动化脚本。 每个文件夹都有明确的用途。每个文件都有可预测的名称。当我告诉 Claude "检查合作伙伴研究"时，它确切知道去哪里找，因为每个合作伙伴的结构都一样。这种一致性就是分类法。

专业技巧

日期前缀的草稿：2026-02-16_topic-name.md。这按时间排序并告诉 Claude 写作时间。合作伙伴文件夹使用小写短横线：partners/acme/、partners/contax/。技能文件在命名文件夹内始终为 SKILL.md：skills/deploy/SKILL.md、skills/tracker/SKILL.md。脚本使用下划线命名：daily_scan.py、rpg_sprites.py。 命名约定不是为了美观。而是为了可预测性。当 Claude 需要找到部署技能时，它查找 skills/deploy/SKILL.md。不是 deploy-skill.md。不是 DeploySkill.md。不是 deploy.skill。一种模式。每次都一样。可预测性消除了搜索时间和虚构的文件路径。

反模式

最糟糕的做法是把所有东西都扔在一个文件夹里。我见过根目录有 200 个文件的仓库。没有子文件夹。没有命名约定。文件名像"final_v2_ACTUAL.md"和"notes_old_backup.txt"。Claude 无法理解那些。你也不能。如果你不能在 5 秒内通过浏览文件夹树找到一个文件，你的分类法就是有问题的。在添加更多内容之前先修复结构。一个干净的 20 个文件的仓库会胜过一个混乱的 200 个文件的仓库。