workflow-retrospective

# 工作流问题复盘 把本次工作中已经发生的问题整理成可核验、可交接的原因报告。报告不是道歉、重新承诺、一般任务总结，也不是 EpiAgentKit 完整规范的替代版本。 ## 1. 限定本轮工作 - 本项是一个局部产物，只创建或更新用户指定位置的 `workflow.txt`；未指定时使用当前工作目录。 - 不为复盘重跑整个项目，不修改正式数据、代码、结果、论文、表图或项目状态文件。用户同时要求修复产物时，把修复与复盘列为两个工作项，分别使用适用的内容 skill。 - 不把 `workflow.txt` 写入 `BACKLOG.md`、`DECISIONS.md` 或结果唯一来源。它只负责把现场证据交给后续维护会话。 - 若已有 `workflow.txt`，先完整读取。保留旧报告，在末尾新增本次会话的独立部分；只有用户明确要求替换时才覆盖。 ## 2. 建立可见证据 只使用当前会话中可见或能够定位的材料： 1. 逐项记录用户指出的问题、用户确认的正确结果和必须保留的行为。 2. 定位实际输出、文件、行号、图片、工具结果或完成说明；没有可定位产物时引用简短的会话事实，不大段复制对话。 3. 核对当时明确加载或可见的规则、skill、reference、执行步骤和验收结果。不能确认当时使用了什么时写“待核验”，不得根据现在安装的 skill 反推当时一定已经加载。 4. 把每项材料标为“用户确认”“直接观察”“可复核推断”或“待核验”。会话经过压缩、原文件不可访问或规则版本不明时，在证据边界中明确说明。 5. 不记录凭证、环境变量、隐私数据、未公开研究结果或与问题无关的完整文件内容；优先使用相对路径和最短必要摘录。 不得声称知道模型未公开的思维过程，也不得用“忘了”“没有注意”“Agent 不够认真”作为根因。原因必须落到可观察的任务分流、制作步骤、规则表达、执行检查、工具条件或完成判定。 ### 独立可读要求 假设接收者无法查看当前会话、没有参与原项目，也不知道报告作者省略的主语和指代。每个问题必须明确写出： - 涉及哪个工作项、产物和制作或验收阶段； - 在什么条件下应当触发什么 skill 或规则，哪些情况不适用； - 谁依据什么材料，对什么对象执行什么动作，以什么证据判定完成； - 实际证据位于哪里，文件名、字段名和 skill 名分别指什么； - 哪些是用户已经确认的通用要求，哪些只是当前项目偏好或尚待核验的解释。 不用“这里”“这些”“按规范”“适当处理”“必要时修改”“相关 skill”等无法脱离上下文确定含义的说法。必须保留真实文件名、skill 名和最短必要背景；若边界只能由用户决定，直接写明需要确认的问题，不替用户补全。 ## 3. 找到最早失效环节 对每个问题依次写清：应当发生什么、实际发生什么、两者最早在哪里分开、现有流程为什么没有阻止、造成了什么影响。 优先检查以下环节，但不把它们当成固定结论： - 任务范围或 skill 分流错误； - 适用规则或 reference 没有加载，或者调用条件不清； - 规则缺失、互相冲突、表述无法执行或把适用范围写得过宽； - 规则已经明确，但没有进入实际制作步骤； - 执行或验收只检查了文件可打开、脚本成功等表面条件，没有检查内容规范； - 异常已经出现但未在安全点停止，或者完成状态被夸大； - 工具、权限、运行环境或输入材料使规则无法可靠执行； - 用户提出的是新的项目偏好，原流程并没有声称覆盖该要求。 多个问题若来自同一个更早原因，合并为一个共同原因并保留各自证据，不为每个表象各写一条规则。若存在多个同样合理的解释，分别列出及其缺失证据，不制造虚假的精确结论。 ## 4. 形成候选调整 `workflow.txt` 只提出需要在完整 EpiAgentKit 中核验的候选调整，不直接决定修改文件。每项候选调整写清： - 要改变的可观察行为； - 最小可执行机制及可能的维护位置； - 必须保留的旧行为和合法例外； - 一个过去应继续通过的场景和一个本次问题场景； - 当前证据的置信度及仍需查看的完整规则。 可能的维护位置包括根规则、skill、reference、模板、脚本、hook、同步器、测试和 README。报告所在项目通常看不到完整体系，因此不得以“建议修改某文件”冒充最终方案；也不得把局部项目习惯、单个措辞偏好或一次工具失败直接升级为通用要求。 ## 5. 写入 `workflow.txt` 使用 UTF-8 纯文本，并按以下顺序组织每次会话的独立部分： ```text 工作流问题交接报告 报告时间： 报告范围： 一、结论摘要 二、证据边界 三、问题记录 问题 WF-001 涉及的工作项、产物与阶段： 适用条件、不适用范围与合法例外： 用户确认的正确结果： 实际表现： 证据位置与证据类型： 当时适用的规则或 skill： 最早失效环节： 现有流程未能阻止的原因： 影响： 置信度与待核验内容： 四、共同原因 五、交给 EpiAgentKit 核验的候选调整 目标行为： 执行主体、动作与完成证据： 触发条件与不触发条件： 最小机制与可能位置： 必须保留： 旧场景与新场景： 证据限制： 六、不应升级为通用规则的事项 七、尚缺证据 ``` 没有内容的部分写“无”，不编造补齐。问题编号在同一文件内连续且稳定；本次会话内更新同一问题时修改原条目，不再创建措辞不同的重复条目。旧报告中的问题再次发生时使用新编号并注明关联，不改写原有证据。 ## 6. 完成检查 写入后重新读取并确认： - 每个用户指出的问题都回答了“为什么现有流程没有阻止”，而不只是复述错误； - 不查看原会话也能确定每条记录的对象、条件、动作、证据、完成标准和边界； - 事实、推断、建议和未知信息已经分开； - 候选调整说明了保留行为和代表性验证，没有预先限定只能改或不能改某类组件； - 文件中没有敏感内容、隐藏思维过程、泛泛道歉、助手式承诺或无法核验的断言； - 除 `workflow.txt` 外没有因本项复盘产生正式项目改动。 最后向用户报告文件位置、记录的问题数量、主要共同原因和证据限制。不要声称 EpiAgentKit 已经因此完成修改。