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