小参数量模型实战

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

背景

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

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

先说结论

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

这类问题不只会出现在小模型上。Claude Code、OpenCode、Codex、Pi 这类 Coding Agent 都会受任务约束、上下文质量和验证反馈影响。模型越强,能降低出错概率,但不能替代排障纪律。

真正需要修的不是某个回答,而是工作流 排查时,Agent 必须先证明根因,再提出修复。这个约束可以用 tw93/Waza 里的 hunt skill 来表达。

这个案例错在哪里

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

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

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

为什么 Coding Agent 容易犯这个错

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

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

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

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

hunt skill 提供的约束

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

hunt skill 的核心规则很直接。它要求 Agent 能用一句话说明“我认为根因是 X,因为有 Y 证据”,并且这个 X 必须具体到文件、函数、行号或条件,而不是“状态管理问题”这种不可验证的说法。

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

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

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

怎么让 Agent 少犯这种错

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

最简用法就是这样:

/hunt

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

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

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

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

/hunt

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

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

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

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

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

什么时候该切到 hunt

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

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

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

DeepSeek-V4-Flash 适合指哪打哪

我个人很推荐 DeepSeek-V4-Flash。官方文档里它是 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 以后,它不一定每次都更快,但更不容易沿着一个漂亮的错误解释一路走到底。