企业官网建设流程全解析

Planning-with-Files 三大规划文件实战教程：task_plan.md、findings.md、progress.md 完整指南与避坑清单

【免费下载链接】planning-with-filesPersistent file-based planning for AI coding agents and long-running tasks. Crash-proof markdown plans, session recovery after /clear and compaction, per-turn re-injection against context rot, deterministic completion gate. Manus-style. Install from npm, the Claude Code plugin marketplace, or npx skills. Codex, Cursor, OpenCode, 60+ agents.项目地址: https://gitcode.com/GitHub_Trending/pl/planning-with-files

一个 50 步的任务做到第 30 步，上下文窗口撑爆，执行者忘了最初的目的是什么，开始对着错误转圈。这就是 Planning-with-Files 要治的病：它让 AI 编码代理把"工作记忆"外置到 task_plan.md、findings.md、progress.md 三个持久化 Markdown 文件里，上下文清空了，任务照样接得上。

为什么长任务总会翻车：三种失效模式

先不急着介绍文件。AI 的上下文窗口容量有限，而且一刷新就归零。长任务最常见的翻车，基本都是这几种：

• 目标漂移：工具调用几十次之后，最初的需求被新信息一点点挤出去，执行者开始"走一步看一步"，越做越偏。
• 研究发现丢失：研究阶段查到的资料只留在窗口里，清屏即焚；截图、PDF、浏览器页面这类视觉内容更留不住，当时觉得"回头再看"，回头就是"找不回来了"。
• 断线无法续作：中途/clear、崩溃、断网，新会话面对一段空荡荡的上下文，不知道之前做过什么、做到哪一步，只能从头再来。

Planning-with-Files 的思路是：这三种病各开一剂药，一个文件治一个，下面按病情的先后顺序来看。

研究发现丢失：findings.md 的更新时机与"2 次动作规则"

治什么病。窗口里的东西会被冲掉，findings.md 就是你的随身笔记本——所有"发现了什么"都先抄进去，抄进文件里的才是你的，留在窗口里的随时会蒸发。

里面放什么。按区块记：研究结果、技术决策、有用资源。每做出一个决策，除了"选了什么"，还要写明"为什么选"。

何时更新。关键规则是2-Action Rule（2 次动作规则）：每进行 2 次查看、浏览或搜索操作后，必须立刻把关键发现写进文本文件，没有商量余地。原因很实际——浏览器返回的页面、截图、PDF 里的图表都是多模态内容，它们不会持久化，窗口一刷新就找不回来，所以必须当场提炼成文字落盘。别攒着"等一会儿一起写"，攒着的那份就是会丢的那份。

目标漂移：task_plan.md 的状态机与决策记录

治什么病。做着做着忘了为什么出发。task_plan.md 是导航图：它始终回答"要去哪、现在在哪、下一步干啥"。

里面放什么。四样东西：一句话目标（最终要交付什么）；3~7 个阶段的划分，每个阶段都小到可以独立完成；每个阶段的状态标记，按 pending → in_progress → complete 的状态机流转；技术决策及其理由，外加一张错误日志表。

何时更新。两个固定动作：做出重大决策之前，先重读一遍计划，把目标重新拉回注意力窗口；一个阶段收尾之后，立刻把状态改成 complete，别让"进行中"的阶段一直挂着。只更新、不回填，状态机永远向前推进。

断线无法续作：progress.md 充当行车记录仪

治什么病。清屏、崩溃、隔天回来，新会话两眼一抹黑。progress.md 是行车记录仪：不解释为什么，只忠实记录"发生过什么"，出事故了直接回看录像。

里面放什么。会话日期（隔多久回来的，一眼可辨）；每个阶段的具体操作，建了哪些文件、改了哪些文件；测试记录——跑的是什么、预期结果、实际结果；以及带时间戳的错误日志，包括第几次尝试、最后怎么解决的。

何时更新。全程都在写：每次执行完操作就补一条，阶段收尾补一段小结。做到哪条，文件就写到哪条——这样任何时刻被打断，新会话读一遍就知道"上次做到哪了、手里有什么、还差什么"。

三文件接力：一个调研任务的完整工作流

拿"调研 WebAssembly 的边界并产出技术选型总结"走一遍：

1. 开工先建三件套。task_plan.md 写一句话目标加 5 个阶段（调研 → 对比 → PoC → 验证 → 交付），状态全部 pending；findings.md、progress.md 建好空框架。此时进度为零，但导航已经就位。
2. 研究循环，2 次浏览一次落盘。浏览 2 个来源，停下，把关键结论提炼写进 findings.md 的"研究结果"区；再浏览 2 个，再落盘一次。材料够了，做出"只支持服务端场景"的决策，连理由一起写进"技术决策"区。
3. 实现与验证。跑通 PoC，把"做了什么、测试预期 vs 实际结果"记进 progress.md；阶段 3 收尾时，task_plan.md 里状态改为 complete，"下一步"指针前移。
4. 交付。阶段全部勾完，progress.md 补上收尾摘要，总结文档落盘。

全程的接力关系是：findings.md 接住"发现了什么"，task_plan.md 接住"要去哪、走到哪"，progress.md 接住"发生过什么"——三者缺一，续作时就缺一条腿。

避坑清单：误区与正解

• 误区 ❌拿到任务直接开工。正解 ✅先花半分钟建 task_plan.md，写清目标和阶段再动手——先有计划，清屏之后才找得回方向。
• 误区 ❌查完资料只在脑子里"记一下"。正解 ✅2 次浏览必须落盘 findings.md，网页和截图不会替你记住任何事。
• 误区 ❌错误随手解决了就不记。正解 ✅每个错误连同"第几次尝试、怎么解决的"写进错误表，记录本身就是防重复的保险。
• 误区 ❌同一个失败动作反复重试。正解 ✅失败了就换方法，换到第三次就该推翻假设，而不是继续撞同一堵墙。

结尾

对话窗口是草稿纸，划走就没了；这三个 Markdown 文件才是账本，白纸黑字，清屏、崩溃、隔天回来都还在。把"会消失的"和"不会消失的"分开管，长任务才跑得完。下一步就可以试：下次让 Agent 跑超过 5 个步骤的任务，先让它建好 task_plan.md 再开工，每做一步就往三个文件里补一笔——被打断时，一句"读规划文件接着干"就能原地复活。

顺带一提，技能目录的 templates/ 下备有 task_plan.md、findings.md、progress.md 的模板，直接抄来开工即可。

【免费下载链接】planning-with-filesPersistent file-based planning for AI coding agents and long-running tasks. Crash-proof markdown plans, session recovery after /clear and compaction, per-turn re-injection against context rot, deterministic completion gate. Manus-style. Install from npm, the Claude Code plugin marketplace, or npx skills. Codex, Cursor, OpenCode, 60+ agents.项目地址: https://gitcode.com/GitHub_Trending/pl/planning-with-files