在 ChatGPT 上做一个两周交付，几乎都是同一种结局：30 个零散对话、同一份大纲的 3 个互相矛盾版本、一个晚上花在”我明明在哪写过那段”。问题不在工具，在没结构。这套方法用一个 Project 里的 spec.md + log.md 节奏，把同样精力从碎片变成复利。
这篇主要解决什么问题
在 ChatGPT 上做一个两周的任务通常会变成 30 个零散对话、相互矛盾的草稿、“我在哪写过这段”——这套方法让任务复利累积。
这篇适合谁看
任何一个交付要做 5 次以上对话的任务：论文章节、上线计划、长系列内容、求职 campaign。
什么时候适合用
任务明显一次坐不完，并涉及多个子任务。
什么时候不建议用
一次对话能完成的事、探索性问题、还不知道最终交付长什么样的任务。
具体步骤
- 用一句话和一段话定义最终交付。说不出来，说明任务还不够准备让 AI 介入。
- 拆成 4-8 个子任务。每个子任务大约够一次对话的体量。
- 建一个 Project。里面放两个文件：“spec.md”（在做什么）+ “log.md”（沿路的决定和产出）。
- 每个子任务：在 Project 里开新对话，先说明本次子任务并贴 spec.md 相关章节，结尾把产出和决定复制进 log.md。
- 两个子任务矛盾时，不要当场拍——把矛盾写进 log.md，专门开一个对话来解决。
- 每完成 3 个子任务，重传一次 log.md。不然 ChatGPT 会忘记旧决定、重复建议。
- 最终拼装：一个专门对话读 log.md，把所有产出缝成完整交付。
建议的操作流程
一个 6 周的论文章节：spec.md 写论点。8 个子任务（文献综述节、数据、方法等）。log.md 每周长一点。最终对话读 log.md，产出 30 页初稿。
容易踩的坑
- 跳过 spec.md。你会在每个对话里都从头脑补一遍，且每次都不太对。
- log.md 不分章节、不写日期，堆成一团。
- 最终拼装时没重传最新的 log.md。
- 在同一个 Project 里夹杂无关问题，Project Instructions 漂移。
- 靠 Memory 而不是文件。Memory 没结构、不完整；文件是你的、有结构、能导出。
- 一个 Project 硬塞 12 个子任务。超 10 个文件量太重拖性能——拆两个 Project 共享 spec.md。
进阶技巧
- log.md 用标题（## 2026-05-19 ——方法节）。ChatGPT 能按日期引用。
- 每个子任务 Pin 一个对话——这些是你的里程碑，比翻历史快。
- 卡住时把 spec.md 大声”念”给 ChatGPT，问它”我目前 log.md 还在轨道上吗？“做一次校准。
FAQ
- 为什么不用 Memory？: Memory 没结构，跨周不稳定。你自己控制的文件才稳。
- 子任务多少算太多？: 超过 10 个 Project 文件量太重会拖性能。拆成多个 Project 共享 spec.md。
- 任务中途 scope 变了怎么办？: 在 spec.md 里加一条带日期的明确变更（“2026-05-15：scope 收窄到第 1-3 章”）。不要静默改——矛盾轨迹本身有价值。
- 能跟协作者共享吗？: Team workspace 可以。Project 文件成为其中所有人共享的上下文。