메뉴
纠偏与误判排查方法论——退化信号检测、四行重写模板、止损序列、六类泛化误判排查表、与 BLOCKED 的边界判定。触发场景：(1) 出现退化信号（反复纠偏/目标漂移/证据缺失等），(2) 需要纠偏恢复，(3) 排查误判，(4) 判断是 correction 还是 BLOCKED，(5) 用户说"纠偏"、"偏了"、"不对"、"重写"、"止损"、"误判"
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
归档管理——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 命令获取时间戳。
SOC 직업 분류 기준
| 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。