メニュー
纠偏与误判排查方法论——退化信号检测、四行重写模板、止损序列、六类泛化误判排查表、与 BLOCKED 的边界判定。触发场景：(1) 出现退化信号（反复纠偏/目标漂移/证据缺失等），(2) 需要纠偏恢复，(3) 排查误判，(4) 判断是 correction 还是 BLOCKED，(5) 用户说"纠偏"、"偏了"、"不对"、"重写"、"止损"、"误判"
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
归档管理——Task 归档与 Recording 物理归档的双轨机制、触发条件、手动步骤、验证清单。触发场景：(1) 终态任务数超阈值，(2) session 文件数超阈值，(3) 用户说"归档"、"archive"、"清理"
积木式能力验证方法论——判断「直接做 vs 先验证」、将不确定性分层隔离、沉淀可复用能力资产。触发场景：(1) 讨论技术可行性或方案选型，(2) 评估某个实现的不确定性，(3) 决定直接集成 vs 先做 Demo 验证，(4) 分析能力复用或知识沉淀策略，(5) 用户说"积木"、"Demo"、"能力验证"、"不确定性"
产品文档工具——正向（需求→文档）或逆向（代码→文档）两种模式。触发场景：(1) 为已有产品还原/补全文档，(2) 为新功能/模块编写产品文档，(3) 用户说"写文档"、"还原文档"、"doc"、"产品文档"
阶段边界决策锚点——四段式判断（启动/实施/验收/纠偏），含正例/反例/边界例。覆盖：基线失败处理、不确定性决策、入口门控、大幅度判定、执行偏差分级、并行串行选择、超前实施、Done 人工确认、blocked_by 判定、循环依赖、continuous_mode 续跑、recording 写入时机、decisions.md 写入时机。触发场景：(1) 需要做阶段边界决策，(2) 判断幅度大小，(3) 选择并行还是串行，(4) 判断是否需人工确认，(5) 用户说"判断"、"决策"、"幅度"、"并行"、"确认"
产品需求分析方法论——竞品分析、用户画像、需求优先级排序、迭代层次设计、方案对比、非功能性需求分类。触发场景：(1) 讨论产品规划或功能设计，(2) 进行需求分析或竞品调研，(3) 设计迭代路径或优先级排序，(4) 用户说"PRD"、"需求文档"、"竞品分析"、"产品规划"、"需求优先级"、"迭代规划"、"方案对比"
Session 记录写入方法论——文件格式模板、踩坑经验四段式记录、时间戳获取规则、最低合法答案、归档聚合指引、Stop hook 检测正则。触发场景：(1) 写 session 记录，(2) 记录踩坑经验，(3) Session 结束前整理，(4) 用户说"记录"、"recording"、"踩坑"。铁律：必须 date 命令获取时间戳。
| name | dcorr |
| description | 纠偏与误判排查方法论——退化信号检测、四行重写模板、止损序列、六类泛化误判排查表、与 BLOCKED 的边界判定。触发场景：(1) 出现退化信号（反复纠偏/目标漂移/证据缺失等），(2) 需要纠偏恢复，(3) 排查误判，(4) 判断是 correction 还是 BLOCKED，(5) 用户说"纠偏"、"偏了"、"不对"、"重写"、"止损"、"误判" |
| argument-hint | [退化信号类型] |
| context | fork |
| agent | general-purpose |
| allowed-tools | ["Read","Grep","Write","Edit","Bash"] |
| hooks | {"PreToolUse":[{"matcher":"Edit|Write","hooks":[{"type":"command","command":"python3 ${CLAUDE_SKILL_DIR}/../hooks/scripts/drift_detect_pre.py 2>/dev/null || true"}]}]} |
纠偏体系：偏航时的恢复协议。开工前的完整规范见 mindset（三唯一框架、不确定性门控）。
出现以下任一退化信号时，停止扩写，回到本规则：
| # | 退化信号 | 含义 |
|---|---|---|
| 1 | 同一问题已被纠偏两次以上仍沿旧路径推进 | 判断循环 |
| 2 | 同一前提被反复解释 | 上下文污染 |
| 3 | 输出越来越像通用套路，越来越不像当前任务 | 目标漂移 |
| 4 | 讨论越来越长，下一步动作越来越模糊 | 动作衰减 |
| 5 | 已改动却拿不出运行态或输出层证据 | 证据缺失 |
| 6 | 开始同时引用多个目录、多个入口、多个"真相源" | 主线分裂 |
偏航时，先停掉以下六项动作：
| # | 停止项 | 为什么危险 |
|---|---|---|
| 1 | 沿已被否定的路径继续扩写 | 放大误差 |
| 2 | 把副本/旧入口/旧文档当当前主线 | 目标错位 |
| 3 | 把界面表象直接当主链根因 | 归因肤浅 |
| 4 | 把测试红了/提示成功直接当最终结论 | 验证误读 |
| 5 | 把问题归因给模型/提示词/代码其中一层 | 分层未拆清 |
| 6 | 无证据情况下宣称"已完成" | 虚假完成 |
纠偏时先用四行重新锚定当前任务。写不出来 = 还没回到主线。
当前目标：- 这次到底要得到什么结果
当前主线：- 唯一主线目录 / 唯一运行入口 / 唯一 canonical
当前现象：- 已观测到的事实（不是推测）
当前缺口：- 缺什么证据导致还不能推进
轻量任务（纯写作/低运行态）可用简化版：目标 + 主线 + 现象 + 下一步动作 + 验证方式。
纠偏的第一步是排除误判。看到对应现象时，先查左列再下结论。
| 项 | 内容 |
|---|---|
| 现象 | 今天突然不通、502/404/超时、同提交多机表现不一致 |
| 默认先查 | 运行进程、端口占用、代理配置、环境变量、依赖服务状态 |
| 暂不下结论 | "代码回归了"、"上次还好好的" |
| 何时下结论 | 排除所有环境因素后，同一代码在干净环境中仍复现 |
| 项 | 内容 |
|---|---|
| 现象 | 查询没命中、结果为空、候选缺失、显示"证据不足" |
| 默认先查 | 测试样本量、账号权限、数据存量、索引状态 |
| 暂不下结论 | "实现失效了"、"算法有问题" |
| 何时下结论 | 数据充足且权限正确时仍复现 |
| 项 | 内容 |
|---|---|
| 现象 | 页面白屏、布局错位、打不开、时间离谱、幽灵数据 |
| 默认先查 | 前端读层逻辑、渲染管线、开发服务状态、CSS/JS 加载 |
| 暂不下结论 | "后端主链挂了"、"API 返回错了" |
| 何时下结论 | 前端独立验证通过（直接调 API 确认返回正确）后仍有问题 |
| 项 | 内容 |
|---|---|
| 现象 | tool-loop-guard 触发、空查询、选错工具、XML/格式漂移 |
| 默认先查 | 查询参数构造、工具路由规则、接口格式约定、护栏触发条件 |
| 暂不下结论 | "模型能力不行"、"这个模型做不到" |
| 何时下结论 | 参数和路由完全正确时仍复现 |
| 项 | 内容 |
|---|---|
| 现象 | 测试失败/脚本失败/HTTP 200/成功提示/撤回成功文案 |
| 默认先查 | 测试口径和前提、脚本执行时机、表面提示含义、首轮输出完整性 |
| 暂不下结论 | "真实失败了" 或 "真实成功了" |
| 何时下结论 | 用 L1-L3 证据交叉验证后 |
| 项 | 内容 |
|---|---|
| 现象 | 结构化结果差、产出回退、改了没效果 |
| 默认先查 | 输入层 → 提示词层 → 后置判定层 → 回退层，逐层隔离 |
| 暂不下结论 | "提示词的问题" 或 "代码的问题"（单一归因） |
| 何时下结论 | 逐层排查后锁定单一层，且其他层独立验证正常 |
纠偏后不要默认继续原路径。重新判断入口方式：
| 条件 | 路径 | 要求 |
|---|---|---|
| 改动小 + 结果可预期 + 差异一句话说清 | 直接继续 | 三项同时满足 |
| 任一不满足 + 需稳定输出/交接 | 先写最小规格 | 见 mindset 最小规格模板 |
| 外部依赖多 / 落点不清 / 回滚成本高 | 先探索验证 | 隔离验证后再决定 |
重新开始推进时，第一条输出禁止宣称"已经搞定"：
现象：- 我现在看到的事实
判断：- 基于事实我认为更像什么；已排除哪些误判
动作：- 下一步具体做什么；怎样验证
尝试重写任务、确认主线、补事实后仍回不到主线时，按序止损：
| 步骤 | 动作 | 目的 |
|---|---|---|
| 1 | 切掉已污染的历史上下文 | 清除判断噪声 |
| 2 | 把任务缩到最小可执行单元 | 降低复杂度 |
| 3 | 明确写出缺口（边界/证据/外部依赖） | 定位阻塞点 |
| 4 | 请求人工补充主线/验收边界/判别依据 | 外部介入 |
最忌讳："继续解释，希望解释本身把任务救回来"。
交接时不默认转发完整历史。只传五类信息：
| 类别 | 内容 | 外化位置 |
|---|---|---|
| 当前目标 | 这次到底要产出什么 | — |
| 关键边界 | 不能破的约束 | — |
| 已验证结论 | 逐条 PASS/FAIL | — |
| 未解决问题 | 遗留阻塞点 | — |
| 下一步动作 | 接收方只需知道的最小信息 | — |
| 维度 | correction（纠偏） | BLOCKED（阻塞） |
|---|---|---|
| 根因性质 | 内部判断失真（AI 自身推理出错） | 外部条件不满足（环境/凭据/权限/依赖） |
| 解决方 | AI 自身按本协议恢复 | 必须等待人工提供条件 |
| 任务需求 | 不变，只是执行偏了 | 不变，但客观上无法继续 |
| 典型场景 | 反复纠偏无效、目标漂移、证据缺失 | API Key 缺失、容器未启动、第三方宕机 |
判断方法：问自己"给我正确的判断就能继续吗？" → 能 = correction；不能（缺环境/凭据）= BLOCKED。