适合同时推进版本发布、客户交付、迁移项目或长期维护工作的读者。核心结论是：不要让一个“大总管”任务记住所有事情，也不要把每次状态核对都当成新对话。更稳妥的做法，是为一个明确项目建立独立的“项目搭档”，让它持续维护目标、决策、负责人、截止时间和阻塞，并用 Heartbeat 只在状态真正变化时提醒你。
项目搭档解决的不是“多聊几轮”
普通问答通常围绕一次问题展开：给上下文、得到答案、结束。但真实项目的关键信息散落在需求文档、代码、会议纪要、消息和待办中，而且会持续变化。项目搭档的价值，是把这些材料限制在同一条工作流内，先形成可核对的项目简报，再跟踪后续变化。
OpenAI 官方用例把它定义为一个专注于单个项目或工作流的独立任务。它可以查看与项目相关的消息、文档、决策和截止时间，定期检查有意义的变化，准备下一步，并在真正执行外部动作前等待批准。[1]
这与 /goal 不完全相同。/goal 更适合让一个长任务围绕明确结果持续执行；项目搭档更像长期项目台账，强调“现在处于什么状态、谁负责、什么变了、下一步是什么”。它也不同于跨多个事项的 chief of staff：项目搭档应只关注一个发布、客户、迁移或维护范围。
第一步：先写清项目边界
建立任务时，不要只说“帮我跟进这个项目”。至少给出五类信息：项目目标、当前状态、已确认决策、负责人和期限、尚未解决的问题。还要明确哪些来源允许读取，以及哪些动作必须先征得同意。
可以使用下面这个泛化模板：
“作为项目 A 的专属搭档，只处理与项目 A 有关的材料。先读取已提供的需求、会议记录、任务清单和代码状态，输出目标、当前进展、关键决策、负责人、期限、阻塞和下一步。缺少来源时明确指出，不要猜测。未经确认，不发送消息、不修改文档、不安排会议，也不代表团队作出承诺。”
这里最重要的不是提示词写得漂亮，而是范围可判定。如果同一任务同时跟进三个项目，重复的人名、日期和“下周上线”等表述很容易互相污染。项目结束后，应归档任务或明确切换阶段，而不是无限累积上下文。
第二步：让首次输出成为可校正的项目简报
第一次运行不要急着让它催进度。先要求一份短简报，至少包含：目标与当前状态、已决定事项、负责人和截止时间、变化、阻塞与依赖、下一项可推进动作。每条关键判断尽量附上来源链接或文件位置，并区分“已确认事实”和“根据现有材料的推断”。
随后由项目负责人校正一次。尤其检查相对日期是否已经换算成具体日期、旧消息是否已被最新回复推翻、负责人是执行者还是审批者，以及“等待中”到底在等材料、权限还是决策。这个校正步骤会直接决定后续提醒是否可靠。
第三步：把 Heartbeat 写成变化检测器
Heartbeat 不应只是“每 30 分钟总结一次”。那会制造大量重复通知，也会让真正的风险被噪音淹没。更实用的监控合同可以写成：
“每 30 分钟检查项目消息、文档、任务清单和近期会议。只有负责人、期限、审批、阻塞或关键决策发生变化时才提醒；没有有意义的变化就保持安静。不要重复已解决事项，不要发送消息或修改项目资料。”
频率也应匹配业务节奏。上线窗口可以半小时一次，常规迭代每天一次，月度规划则没有必要高频检查。官方文档还明确区分了执行环境：网页端的计划检查可在电脑关闭时继续；如果任务需要读取本地文件或桌面工具，电脑必须保持开机且应用正在运行。[1]
第四步：把“准备动作”和“执行动作”分开
项目搭档可以整理风险、起草跟进消息、准备会议提纲或列出下一步，但不应默认替你发送、修改或承诺。一个稳妥的工作流是：读取与归纳属于默认可执行范围；生成草稿属于可审查结果；发送消息、更新文档、修改任务状态和安排会议则需要明确批准。
这样设计有两个好处。第一，项目搭档可以主动推进信息工作，不必每一步都停下来询问。第二，外部写入仍有清晰的人类责任边界。对于客户承诺、发布日期、费用和安全审批，这个边界尤其重要。
用四个指标判断是否真的有效
运行一段时间后，不要只看它发了多少提醒。更值得检查的是：旧信息误报是否减少；阻塞从出现到被发现用了多久；每次简报能否给出明确下一步；需要人工纠正的负责人、日期和结论有多少。
如果通知很多但下一步始终模糊，说明来源或项目边界仍然混乱；如果长期没有变化，也要确认是项目稳定，还是 Heartbeat 根本看不到关键来源。项目搭档不是自动项目经理，它更像一个持续维护证据和状态的协作者。目标是让人更快做出可靠决定，而不是让 Agent 代替负责人承担承诺。