一个人的 AI 工作流，别把全部资料都塞进上下文
AI 工作流缺上下文会反复追问，上下文过多又会挤掉真正重要的信息。用目标、真值来源、当前状态和验收条件组成最小上下文包，让重复任务少解释、可更新、能交接。
一个人用 AI 做重复工作，很容易在两个方向上同时浪费时间：材料给少了，它每轮都要重新问背景；材料给多了，几十页聊天记录、旧文档和临时想法一起塞进去，真正影响这次结果的几条事实反而被埋住。
我更倾向于把上下文当成一笔有限预算。目标不是把你知道的一切交给 AI，而是让它能找到当前任务需要的真值，并且知道什么时候应该停下来问你。
上下文越多，不等于工作流越懂你
OpenAI 在介绍 Codex harness 的实践时，专门提到一份巨大的说明文件会挤占任务、代码和相关文档的位置；他们最后采用的是一张短地图，指向结构化、可验证的真值来源。Anthropic 对长时间 Agent 的实验也发现，单靠上下文压缩并不足以跨会话稳定工作，后续任务还需要看得见的进度文件和清楚的当前状态。
这些是软件工程场景的一手实践，不能直接证明每个内容、销售或客户跟进工作流都要用同样的文件结构。但它说明了一个可以迁移的判断：上下文的价值不在体积，而在它能不能把 AI 带到正确的事实、当前进度和下一步。
社区里也有人把提示词、记忆、临时笔记和规则单独做成版本化文件，起因正是这些材料长期堆在一起以后变得混乱。这只是一个实践信号，不是通用结论。不过对一个人经营业务来说，维护成本已经足够值得警惕：每多放一份材料，就多一份过期、冲突和误用的可能。
最小上下文包只需要四部分
- 这次要完成什么：写成一个可以检查的结果，不要只写“帮我处理一下”。例如“把本周产品进展整理成三份渠道草稿，发布前交回确认”。
- 真值去哪里找：给来源和优先级，不把全文重复粘贴。产品状态看哪份记录，用户原话看哪个入口，冲突时以谁为准，都要能定位。
- 现在已经到哪一步：保留最新完成项、待处理项和已知缺口。跨会话继续时，AI 先读状态，不用从历史聊天里猜。
- 什么结果才算通过：写清输出格式、必须保留的事实、不能做的动作，以及哪一步必须交回人工。
OpenAI 的 Agent 指南建议从已有 SOP 和政策文档建立指令，把密集材料拆成更清楚的步骤，并让每一步对应具体动作或输出。放到个人工作流里，最实用的不是再写一篇万能提示词，而是把上面四部分做成一张会更新的任务卡。
先整理一次，再让不同任务按需取用
这张 MotiClaw 示例工作台里，一位独自经营产品的人先把客户反馈、产品进展和下一步计划整理成一份核心素材，再交给即刻、X 和 Threads 分别改写。三个渠道不需要各听一遍完整背景，最终发布也没有自动越过人工确认。
这更接近一个可维护的上下文包：稳定事实只整理一次，渠道语气按任务变化，发布权仍留在人手里。MotiClaw 在这个案例里提供的是整理、分发草稿和人工确认的产品路径；外部项目关于上下文管理的做法只是设计参考，不能反过来证明 MotiClaw 已经提供它们的全部底层能力。
什么时候该补，什么时候该删
- AI 连续追问同一个背景，而且答案确实会在后续任务复用时，把它补进真值来源或当前状态。
- 材料只解释一次性的讨论过程，最终决定已经写进正式记录时，删掉过程，只保留决定与理由。
- 两份资料互相冲突时，不继续加第三份摘要；先标出 owner、更新时间和优先级。
- 任务结束后，只沉淀下次会复用的事实、规则和验收项，临时推理留在本轮记录里。
你可以从下一件每周重复的工作开始：新建一张任务卡，只写目标、真值来源、当前状态和验收条件，然后跑三轮。每次 AI 追问，先判断这是长期缺口还是本轮例外；只有长期缺口才写回上下文包。工作数据默认留在本机；仅你主动接入的渠道与模型调用按任务所需出网。上下文能被持续删减和校正，才真正开始为你节省解释成本。