---
title: 小参数量模型实战
description: 小参数量模型能力够用,但缺少约束时稳定性不足。本文从 DeepSeek-V4-Flash 的一次排障误判案例出发,复盘工作流约束、skill 调用、证据验证等最佳实践。
lastModified: 2026-06-11
---

## 背景

这次案例的核心是同一个模型、同一个 Agent,因约束方式不同,走出了两条完全不一样的排障路径。

<Columns cols={2}>
  <Column>
    <Card title="常见误判路径">
      **起点**:发现两条相邻线索--变量名相近、代码位置相邻、日志时间接近

      **推理**:A 看起来影响 B → 把相邻关系直接当作因果关系

      **验证**:不验证,直接沿假设补充叙事

      **终点**:结论方向已经偏了,但写得很顺,难以察觉
    </Card>
  </Column>
  <Column>
    <Card title="hunt 约束路径">
      **起点**:确认复现入口--用户可见现象、可执行的复现步骤

      **推理**:追真实调用链和数据流向,而不是猜测链接

      **验证**:提出可验证假设 → 运行验证命令 → 判断证据是否闭合

      **终点**:先证明"根因是 X,因为有 Y 证据",再进入修复
    </Card>
  </Column>
</Columns>

两种路径的差异可以这样看:

```mermaid
flowchart LR
  subgraph wrong[常见误判路径]
    A1[相邻线索] -->|相关性写成因果| A2[看似合理的解释]
    A2 -->|沿假设补充叙事| A3[方向已偏的结论]
  end

  subgraph right[hunt 约束路径]
    B1[现象/复现入口] --> B2[追根因, 收集证据]
    B2 --> B3{证据闭合?}
    B3 -->|否| B2
    B3 -->|是| B4[根因证明 + 修复]
  end
```

:::tip
两个例子的差别就在这里:模型能力没有变,约束方式变了,输出质量也跟着变了。
:::

## 先说结论

这篇文章想讲的是一个很具体的问题:Coding Agent 做排障时,最容易出错的地方不是写不出代码,而是在证据不足时提前相信一个解释。

这类问题不只会出现在小模型上。[Claude Code](https://code.claude.com/docs/en/overview)、[OpenCode](https://opencode.ai/docs/)、[Codex](https://developers.openai.com/codex/cloud)、[Pi](https://pi.dev/docs/latest) 这类 Coding Agent 都会受任务约束、上下文质量和验证反馈影响。模型越强,能降低出错概率,但不能替代排障纪律。

真正需要修的不是某个回答,而是工作流:bug 排查时,Agent 必须先证明根因,再提出修复。这个约束可以用 [tw93/Waza](https://github.com/tw93/Waza) 里的 [hunt skill](https://github.com/tw93/Waza/blob/main/skills/hunt/SKILL.md) 来表达。

## 这个案例错在哪里

错误点不是"模型不知道答案",而是"模型过早相信了一个答案"。

它看到两条线索相邻,变量名、代码位置或日志现象看起来能连上,于是把相关性写成了因果。后续分析就沿着这个假设展开,越写越顺,但方向已经偏了。

排障里最危险的不是没有假设,而是假设出现得太早。一旦 Agent 先有了一个解释,它会自然地继续寻找支持材料,而不是主动找反证。读起来会很像分析,实际是在给未证明的结论补叙事。

## 为什么 Coding Agent 容易犯这个错

Coding Agent 做 bug 排查时,通常要从现象倒推原因。这件事对人也不简单,对模型更容易出现三种偏差。

一是把相邻当关联。两个文件一起出现、两个日志时间接近、两个变量名相似,都可能只是巧合。如果没有调用链或数据流连接,它们就还不是证据。

二是用静态阅读替代运行验证。只读代码很容易得出"应该会这样"的判断,但真实系统还受配置、缓存、构建产物、运行环境和用户路径影响。没有跑测试、打请求、复现 UI 或读取日志,结论只能算假设。

三是把解释写得太完整。模型擅长生成连贯文本,连贯会给人一种"已经查清楚了"的错觉。排障文档越顺,不代表证据越足。

## hunt skill 提供的约束

[Waza](https://github.com/tw93/Waza) 是 tw93 维护的一组 Agent skills,目标是把常见工程习惯变成 Agent 可执行的工作流。它包含 think、design、check、hunt、write、learn、read、health 等技能。仓库文档也说明了它可以安装到 Claude Code、Codex、OpenCode 和 Pi 等不同 agent harness 中。

[hunt skill](https://github.com/tw93/Waza/blob/main/skills/hunt/SKILL.md) 的核心规则很直接:在应用修复前先找到根因。它要求 Agent 能用一句话说明"我认为根因是 X,因为有 Y 证据",并且这个 X 必须具体到文件、函数、行号或条件,而不是"状态管理问题"这种不可验证的说法。

所以调用 hunt 时,不需要再额外强调"不要改代码"。这个规则已经写在 skill 里了。用户更应该补充的是 skill 需要的排障输入:原始症状、复现路径、所有可观察现象、相关日志或状态、环境差异、最近变更,以及你希望它用什么命令或 UI 路径做验证。

把这个规则放进排障流程后,Agent 的动作会从"解释现象"变成"证明链路":

```mermaid
flowchart TD
  A[用户报告问题] --> B[确认复现入口]
  B --> C[追真实调用链]
  C --> D[核对数据来源]
  D --> E[提出可验证假设]
  E --> F[运行验证命令]
  F --> G{证据是否闭合}
  G -->|否| C
  G -->|是| H[给出修复或结论]
```

这张流程图里最重要的是循环。如果验证不能支撑假设,就回到调用链和数据来源继续查,而不是换一种说法继续解释。

## 怎么让 Agent 少犯这种错

排障时,不要只问"这是什么问题"。这种问法会鼓励 Agent 直接给解释。更好的方式是明确调用 hunt skill。

最简用法就是这样:

```bash 快速启动
/hunt
```

把症状和复现路径直接贴在同一行:

```bash 一行式
/hunt 页面列表返回空白,没有报错。复现:打开 /users 页面,只有管理员账号出现。
```

能写一行就一行,写多了反而稀释重点。Agent 会自己根据你描述的现象启动排查流程。

如果你有更多上下文,也可以用结构化字段补齐--适合需要多线索分析的复杂问题:

```bash 结构化
/hunt

现象:
[一句话描述用户可见的问题。]

复现方式:
[命令、页面路径、接口请求或测试用例。]

已观察到的症状:
- [症状 1]
- [症状 2]
- [看起来相关但还不能确认有关的线索]

已有证据:
- [日志、报错、运行状态、最近 diff、环境信息]

验证目标:
[用哪个命令、测试、请求或 UI 路径证明诊断成立。]
```


## 什么时候该切到 hunt

只要任务是"为什么坏了",就应该优先用 hunt。比如报错、崩溃、回归、测试失败、页面表现不对、接口返回异常、线上日志和本地行为不一致。

下面这些信号说明 Agent 已经开始走偏:还没定位入口就解释原因;没有看调用方就修改被调用函数;连续使用"可能、应该、大概"但不补验证;没有运行任何检查就说修好了;修改范围明显大于问题表面需要。

遇到这些情况,不要继续追问"那怎么改"。先让它停下,要求它把根因、证据和验证命令分开写。

## DeepSeek-V4-Flash 适合指哪打哪

我个人很推荐 [DeepSeek-V4-Flash](https://api-docs.deepseek.com/quick_start/pricing)。官方文档里它是 DeepSeek-V4 系列的轻量版本，284B 总参数、13B 激活参数，支持 1M 上下文，定位就是快速、经济的选择。

我的感受是，国产模型更像高学历实习生，能力够，但需要你把任务边界写得很具体：要做什么、该怎么做、不能做什么、输出长什么样。国外顶流闭源模型更像经验丰富的老手，你说一句，它往往能猜到你真正想要的工作流。

用过几个国产模型之后，发现共性问题很一致：性能容易波动、改错改漏时有发生。但耐不住费用低、性价比高，prefill 和 decode 速度都在不错的水平。既然都有这些短板，那我为什么不选一个指哪打哪、能及时反馈的？——最后换到了 DeepSeek-V4-Flash。

DeepSeek-V4-Flash 的优势正好在"指哪打哪"。给它清楚的 skill、输入字段和验收标准,它很适合做快速探索、粗筛、收集线索和执行明确任务。不给具体约束,让它自由发挥,它就更容易提前补因果、写出一条看似顺滑但没有闭合证据的解释。

这里也能看到 Harness Engineering 的重要性。小模型不是只差在"脑子小一点",更差在缺少约束时的稳定性:上下文从哪里拿、哪些材料相关、哪些线索要排除、输出要满足什么证据标准,如果 harness 没有替它管住这些环节,最后拿到的上下文准确性、相关性和生成质量都会更容易波动。

所以这类模型不是不能做 Coding Agent,而是需要更工程化的使用方式。用 hunt 处理 bug,用 check 做 review,用 write 改文章,用明确字段喂上下文,而不是把一句"帮我看看"丢过去。

## 最后

Coding Agent 排障的关键不是让模型"多想一点",而是让它少跳一步。

先复现,再追链路;先证明,再修复。没有这层约束,模型很容易把相邻线索写成因果关系。加上 hunt 以后,它不一定每次都更快,但更不容易沿着一个漂亮的错误解释一路走到底。