Hypo-Workflow / 写作档案
Hypo-Workflow：面向研究生和个人开发者的 AI Harness 工作流
Hypo-Workflow 不是给工程团队用的项目管理平台。它更适合那些需要和 AI Agent 长期协作完成复杂任务的个人——研究生、开发者、研究者。你手头可能是一个要复现的祖传仓库，一个要反复迁移验证的数据集，或者一个需要持续迭代的 Demo 项目，Agent 的动作很快，但几天之后你发现它的决策依据早就散落在几十轮对话里找不回来了。Hypo-Workflow 解决的就是这个：让你能追踪每一步决策、在中断后恢复进度、在需要时审查产出
Hypo-Workflow 是什么？
Hypo-Workflow 是一套面向 AI Agent 长任务的本地工作流协议。它在你的项目目录里安放一层结构，让规划、状态、规则、报告和恢复入口变成可检查的文件，而不是只存在于聊天窗口里随时可能被压缩掉的上下文。
Hypo-Workflow 不是给工程团队用的项目管理平台。它更适合那些需要和 AI Agent 长期协作完成复杂任务的个人——研究生、开发者、研究者。你手头可能是一个要复现的祖传仓库，一个要反复迁移验证的数据集，或者一个需要持续迭代的 Demo 项目，Agent 的动作很快，但几天之后你发现它的决策依据早就散落在几十轮对话里找不回来了。Hypo-Workflow 解决的就是这个：让你能追踪每一步决策、在中断后恢复进度、在需要时审查产出质量。
Why Hypo-Workflow？
没有这些外部约束，长周期协作的实际情况经常是这样的——看起来确实跑通了，但是为什么呢？
有一次我在复现一份祖传代码，原版依赖已经老到完全跑不动。把仓库交给 Agent 之后，它效率很高地把依赖换了一圈，项目居然能跑起来了。但拿输出和原论文一比对，结果根本对不上。一些计算逻辑被改过，我不确定这是为了适配新版本库做的必要调整，还是它顺手“修了个 bug”。回头问它当初为什么改，它很礼貌地告诉我上下文已经被压缩，不记得当时的推理过程了。产出留下了，但决策链断了。
验证跑了两天，目标却被上下文压缩冲散
数据集的迁移验证是另一个场景。一开始 Agent 理解得很清楚，前几轮还在认真和我讨论验证策略。任务跑了两天，中间经历了几次上下文压缩，它开始在一些无关细节上自我辩论。等到我让它总结当前的验证结论，它只能复述最后那几轮对话中的调试片段，完全忘了最初我们要验证什么。长任务的另一端，上下文里只剩最近的碎片。
Demo 还在迭代，要求却要反复复制
早期，在搭我的 LaTeX 库 Hypo-LaTeX 的时候，问题更简单但同样折磨人。每次让 Agent 帮我写或更新技术文档，都要把文档结构、内容要求、这次改哪里重新喂一遍。复制、粘贴、复制、粘贴。它不记得，因为“记忆”只存在于那一个会话窗口里，切走就清零。
这三件事指向同一个事实：AI 比人更快地产出更多东西，但如果在长任务里缺少一层标准化的约束来维持可追溯性和工作稳定性，这个“快”会以更快的速度会被返工和猜测消化掉。Hypo-Workflow 做的事，就是把这层约束从模型外面搭起来。
它把工作流放到模型外面
先明确 Hypo-Workflow 不是什么——它不是替代 Claude Code、Codex、OpenCode 或 Cursor 的独立执行器。写代码、跑测试、做审查，这些动作仍然由你当前使用的 AI Agent 来完成。Hypo-Workflow 负责的是执行之前的讨论、执行中的边界约束检查，以及执行之后你能把头绪捡回来的入口。
你可以把它理解成放在 Agent 外面的一层项目轨道，轨道直接印在文件系统上。物理形态就是项目根目录下的 .pipeline/ 文件夹。里面有当前计划的状态记录 state.yaml，有每次工作周期的边界定义 cycle.yaml，有给人和 Agent 一起看的进度说明 PROGRESS.md，有每一步产出的报告 reports/，还有记录中断后如何接续的 continuation.yaml 和行为日志 log.yaml。这些东西不绑定任何特定 Agent 平台。只要你的编程工具能读写项目文件，并愿意遵从同一套 .pipeline/ 约定，就能在这套文件协议上接回同一个项目的长期状态。Claude Code 的用户和 Codex 的用户，可以围绕同一套本地事实源协作，状态不会因为换工具而断裂。
换句话说，没有试图让模型的“脑子”变大，只是把应该记住的东西写到了本地文件夹里。
一套让你能暂停、能审查、能接回去的概念
在展开具体工作方式之前，先把几个基础概念对上。假设你是一个研究生，下周要汇报阶段进展，给自己定的任务是“把师兄仓库里那套分割模型的代码跑通，替换成自己的数据集，产出可用指标”。
整个这件事在 Hypo-Workflow 里就是一个 Project。具体到“本周内跑通并产出指标”，这是一次 Cycle——有明确边界的工作周期。在工具真正动手之前，会先进入 Plan 阶段，把目标、验收方式、风险都讨论清楚。Plan 的结果会被拆成若干个 Milestone，比如“环境跑通”“数据加载验证”“单卡训练验证”“指标产出”。每一个 Milestone 结束都会有一个 Gate，也就是一个明确的停点：停下来让你看一眼结果，决定要不要继续，还是需要调整方向。
每一轮工作结束，不论顺利还是中断，都要产出一份简明的 Report，说清楚做了什么、依据是什么、当前状态是什么。中间碰到的修文件名、改导入路径、解释一个报错，这些小修小补扔到 Patch 或轻量讨论里处理，不挤进主线的 Milestone 打乱节奏。这些概念不是设计文档里拍脑袋想出来的，是被 AI 的产出淹没过几次之后逐渐确认的必需品。
先提问，再拆分，然后才动手
Plan Mode 容易被误读成“让 AI 先列个步骤再干活”。但如果只是让它自己列步骤，那跟它自己干活中途踩坑再返工没有本质区别。
Hypo-Workflow 的 Plan 阶段有一道关键步骤：它会先问你问题。在你说“我要跑通师兄那套分割模型”之后，Plan Discover 会反抛一串问题——这是复现任务还是目标明确的工程任务？硬约束是什么，不能换框架还是必须在单卡上跑通？验证到什么程度算通过？哪些步骤可以自动跑，哪些必须让你看过结果再继续？有没有哪部分代码绝对不能改？你把这些问题回答清楚，它才会基于你的回答去拆 Cycle 和 Milestone，生成接下来的提示词，把规划落到文件里。这时候计划才真正变成你的计划，而不是模型自作主张的想象。
这种做法不是凭空来的。在用 AI 做项目的圈子里，很多人已经在实践类似的事情。Superpowers 这类 Harness 体系强调的“先 brainstorm，再 writingplans”，先把需求边界和方案讨论清楚再动手。还有 deep grill me、deep discover 这类习惯，本质上都是在计划阶段强制追问你到底要什么、不要什么，然后才让模型进入执行。Hypo-Workflow 的思路是把“问清楚再动手”这整套节奏固化到 .pipeline/ 里，让它变成每次任务都能复用的步骤，而不是靠你每次手动去追问。
开发主线之外，顺便做的事也该留档
主线任务用 Plan、Start、Resume、Report 这一套管下来，已经能应对完整的工作周期。但真实日常里有一大堆动作并不是完整的开发任务。看到一个有趣的新仓库想先跑起来试试；被导师突然问“上次那个实验为什么把学习率调那么低”，你翻半天项目文件夹也不太确定；或者你只是需要阅读一个架构，判断这套方法能不能用到自己的场景里。这些没有记录的话过了就过了，回头要写报告或被追问，就只有聊天记录可翻，甚至聊天记录都没有。
Hypo-Workflow 里放了几个轻量的补充能力。explore 让探索过程和当前 Cycle 隔开，不污染主线状态，结束后能留下一份探索报告，随手试跑别人的代码不会把主项目环境搞乱。explain 偏向解释，当你问“这个文件当初为什么这样改”，它会先扫本地报告、规则和历史记录，尽量让解释有据可查，而不是上下文里猜出来的“可能是这样”。analysis 服务于还没到写代码阶段的阅读和判断——复现策略怎么定、实验方案怎么评估、某个架构适不适合改，这些讨论也可以结构化留下来，不只躺在对话框里。
这三个点不需要贴“研究生专属功能”的标签。但确实，不是每次打开终端都是为了写代码，更多时候是为了搞清楚一个问题，把这些搞清楚的过程也保护下来，才不至于反复从零开始。
降低失忆和返工的成本
长任务里中断和遗忘一旦变得常态化，质量控制就不能靠喊口号。
Hypo-Workflow 用更朴素的办法：把你的要求提前写成文件，把中间状态存下来，把每次重要的判断和结果记下来。报告让输出结果有明确的出处，而不是聊天窗口里一段可能被压缩掉的文字。持续积累的本地规则文件，让你不必每次新会话都重新告诉 Agent“入口脚本不能改”“配置文件只能在最后一步加参数”。continuation.yaml 明确记下中断前做到哪个 Milestone、下一步从哪开始，不用靠猜。
当某个 Milestone 的安全感要求比较高，还可以让另一个 Agent 角色来做 Subagent 审查。它会基于本地的报告和规则检查逻辑是否自洽，约束是否被遵守，重要改动有没有依据。审查记录也留在 .pipeline/ 里，没有额外黑箱。这些设计的共同目标不是承诺全自动不出错，而是降低这样一类成本：你明明已经把要求说过很多次了，但每次重新开始任务，Agent 就像被格式化了一部分记忆，你只好再把要求复述一遍。
让文件接管记忆和重复要求
说到底，Hypo-Workflow 不是为了帮 AI 更会写代码。是让 .pipeline/ 里那些 rules、prompts、reports、continuation 文件，替你去记住需要反复提醒 Agent 的事情。上次做到了哪里，哪些规则不能破，哪个实验结论是基于哪一次运行的日志得出，中断之后下一步从哪开始。这些信息没必要每次都靠你重新注入提示词，更不应该随着上下文压缩消失。
你做完一个阶段，可以在这些记录的基础上整理汇报、写博客，但这只是延伸。真正稳定的价值在于，你不再需要每次都在聊天框里从头解释一遍项目的位置和约束。
如果你也是一个需要频繁写代码、跑别人项目、搭 Demo、做实验验证的研究生，或者任何一个正在被 AI Agent 长任务协作里的“产出快、追溯累”困扰的开发者，可以试试把这层工作流接到你的项目里。它不承诺自动完成一切，但它让每一步都有据可查，让断掉的进度能接回来，让那些你反复说过很多次的要求，不再需要从头再说一次。