长期AI任务从聊天记录中独立管理的方法

make-goal：把长期 AI 任务从聊天记录里解放出来

摘要

在短任务场景中，AI agent 的表现确实令人印象深刻；但一旦项目周期拉长，输出质量便开始下滑——计划零散地分布在聊天记录中，环境依赖未能清晰记录，验证方式仅凭临时记忆，下一轮 agent 接手时又不得不重新理解上下文。这种工作方式，效率低下且容易出错。

make-goal 的目标并非“让 AI 写出更漂亮的计划”，而是将复杂目标整理成一份可执行、可恢复、可验证的 goal.md 文件。目标、约束、运行环境、里程碑、验收标准、进度记录——全部整合到同一个文件中，使 Codex、Claude Code 或其他 agent 能够直接进入长期执行模式。你需要先投入精力把目标梳理清楚，后续 agent 的运行才能顺畅高效。

长任务真正缺的不是计划，而是可执行上下文

我们通常这样使用 AI agent：在聊天中描述目标 → 让 agent 给出计划 → 让它修改代码或整理资料 → 中途不断补充上下文 → 下次会话重新解释一遍。这个流程在十分钟内有效，但对于持续几小时、几天甚至更长的任务，就显得不太可靠。问题不在于 agent 不会拆分任务，而在于“任务状态”并未转化为稳定的资产。

聊天记录的缺陷很明显：上下文过长，后续 agent 可能无法完整读取；用户随口提及的约束容易被遗漏；环境依赖仅存在于某一轮对话中；验证方式不明确，完成标准越来越模糊；进度缺乏结构化记录，恢复成本极高。因此 make-goal 的核心判断是：长期任务需要的不是一次性计划，而是一份能被 agent 反复读取和执行的目标合约。

goal.md 应该包含什么

一份合格的 goal.md 至少要回答以下问题：

• 最终要交付什么？
• 哪些文件、仓库、链接或参考资料必须先阅读？
• 哪些约束不能破坏？
• 哪些事情明确不做？
• 当前运行环境需要什么？
• 缺少依赖时 agent 应该如何处理？
• 如何分阶段推进？
• 每个阶段怎样验收？
• 每次循环之后如何记录进度？
• 什么条件下可以认为任务完成？

make-goal 会引导 agent 先提问，再生成文档。它不会急于编写任务清单，而是先补齐缺失信息——尤其是执行环境这一层。

Harness：长期任务最容易被低估的一层

许多任务目标本身很清晰，但 agent 仍然会卡住，常见原因是 harness 设计不当。这里的 harness 指的是 agent 执行任务所需依赖的一切：runtime（Node、Python、Godot、LayaAir、浏览器）、package manager（npm、pnpm、uv、pip）、CLI 工具（gh、git、ffmpeg、Playwright）、MCP server 或外部连接器、环境变量和密钥名称、本地服务、数据库、第三方 API、文件系统权限和网络权限、基线检查命令、依赖缺失时的降级方案。

如果这些没有写入 goal.md，后续 agent 就只能靠猜测。它可能猜对，也可能在环境缺失时直接停止，或者使用错误的替代方案继续推进。因此 make-goal 在目标整理阶段会明确要求写出 harness：

## Execution Harness
- Runtime:
- Package manager:
- Required CLI tools:
- Required services:
- Environment variables:
- Permissions:
- Readiness checks:
- Fallbacks:

这部分看起来不如“功能列表”让人兴奋，但它决定了任务能否长期自动运行下去。

Agent 工作循环

make-goal 生成的 goal.md 不只是给人阅读的文档，它还会定义 agent 的工作循环：

Read goal.md
Read progress log
Inspect current repo state
Pick the next smallest useful increment
Implement
Validate
Record progress
Continue

这个循环有两个好处。第一，减少漂移——agent 每一轮都回到同一个目标文件，而不是依赖当前聊天上下文。第二，方便恢复——如果任务中断，下一个 agent 可以先读取 goal.md 和 progress log，再继续从当前状态推进。

为什么做成通用 skill

make-goal 并非为某个特定项目编写的 prompt，而是一个通用 skill。它适用于软件重构、开源项目初始化、产品 MVP、研究报告、文档迁移、游戏开发、知识库清理、长期运营任务等多种场景。它也不绑定单一 agent，当前仓库提供了三类入口：Codex skill package、Claude Code slash command、Generic agent prompt。

更重要的是，用户不需要先下载仓库再手动运行安装脚本。更自然的入口是一段给 agent 的提示词：

Open https://github.com/talkcozy/make-goal. Read the repo, install make-goal for this Codex environment, verify the skill is available, then use $make-goal to create a goal.md for this project.

也就是说，安装这件事本身也可以交给 agent 去完成。用户只需表达意图，agent 负责读取仓库、安装、验证和使用。

一个 goal.md 的质量标准

从实践来看，一个合格的 goal.md 至少要满足以下标准：

• 自包含：脱离原始聊天记录也能理解
• 可执行：下一步做什么足够明确
• 可验证：每个阶段有检查方式
• 可恢复：中断后能继续
• 有边界：写清楚不做什么
• 有 harness：环境依赖和缺失处理写清楚
• 有进度记录：每轮工作能留下状态
• 有完成定义：知道什么时候该停

如果只有任务清单，它只是计划。如果包含了上下文、harness、循环和验收标准，它才更接近长期任务合约。

适合在什么时候使用

当你的需求可以在一次对话中完成时，不一定需要 make-goal。但如果出现以下情况，就很适合先生成 goal.md：

• 任务会持续很久
• 涉及多个目录或多个仓库
• 需要反复验证
• 中途可能换 agent 或换会话
• 环境依赖比较复杂
• 用户希望 agent 尽量自主推进
• 完成标准不止一个截图或一个函数

换句话说，make-goal 适合那些“开始写代码之前值得认真想清楚”的任务。

结语

AI agent 越强大，越需要清晰的执行边界。优秀的 goal.md 不是在束缚 agent，而是在为其提供长期稳定工作的地基。目标越复杂，前置整理的重要性就越高。

make-goal 的核心理念可以浓缩成一句话：

项目地址：https://github.com/talkcozy/make-goal

官网：https://talkcozy.github.io/make-goal/