开源小模型一个周末写完二进制协议，Claude复查仅少量遗漏

用模型写代码时，先把需求清单和文档/测试（Cucumber 或 EARS 风格）列出来，是提升代码质量的好办法。作者刚用一个周末，用 Qwen3.8-27B（6K unsloth 量化版）完成了一个二进制协议的实现；随后让 Claude 复查，发现基础架构的工程化做得不错，只漏掉了几项安全检查，以及 Python 基准脚本里的两个错误——该脚本用于对比新旧协议。

差别主要来自下面五条做法。

先设计：目标、需求、问题

动手之前，先明确这个功能要解决什么问题、会被谁以什么方式使用。把目标、需求和已知问题写成清单，模型后续的每次生成都有可对照的依据，而不是凭感觉一路写下去。

用可验证的观察、模拟和测试取代假设

假设无法被检查，观察、模拟和测试可以。测试与流程本身也要能被审查，看它是不是只在走形式（ritual）——一条永远通过的测试，等于没有测试。

遇到分叉点时，让模型发起对话（Dialectic）

当模型走到设计上的岔路口，要求它把可选方案列出来，而不是直接选一个继续往下写。让它和你讨论设计取舍（dialectic，辩证式对话），你才能在每个关键决策上介入；否则，一个悄悄做出的选择会一路影响到最终代码。

频繁运行可重复的测试，并审查测试是否满足需求的本意

测试要能反复执行，每次改动都跑一遍。同时定期回看测试本身：它验证的是需求的字面，还是需求的精神（spirit of the requirement）。

把每个风险都写成一条需求

风险不能只停留在“注意一下”的讨论里。每识别出一个风险，就把它转成一条可验证的需求或测试，否则它不会真正被执行。

现成的提示集与工具

作者把这套提示词（也可以理解为“skills”）整理在此，同时还提供了一个可安装到各种本地 harness（本地运行框架）的工具：

https://github.com/bigattichouse/BluePrint

这套提示集覆盖了用 Cucumber（行为驱动开发所用的 Gherkin 语法）或 EARS（Easy Approach to Requirements Syntax，需求语法）风格编写需求与文档/测试的做法。