引言：一次邀约，与一个被评分掩盖的工程真相

最近，一位朋友私信问我，我们之前分享的那套让浏览器化身“Vibe Coding”神器的提示词模板，在最新的模型上效果如何。

免费的代码工厂：在DeepSeek V4网页版上运行Harness工程短提示模板

今天，我们不谈哲学，只动手。我们结合一个具体的开源项目PR——StructuredContextLanguage #34——来对DeepSeek V4进行一次硬核测试。我们的任务很明确：在项目中内置一个grep（我们叫它igrep）工具，作为项目Capability抽象的一部分。

在开始前，请先看一张图。这是artificialanalysis.ai的最新模型评分。DeepSeek V4的总分排名令人瞩目，但“推理与知识”和“代码生成”等细分维度的柱状图，才隐藏着这次测试的真相起点。

这份评分是一个信号，但它无法回答一个更实际的问题：在真实的、带有既定约束的工程环境中，它到底是一个唯命是从的学徒，还是一个需要处处留心的合作者？

本文将是一场公开的勘探记录。我们会将测试过程分为四个剖面：遵从命令、代码生成、真实测试、工具理解。每个剖面都将独立剥离出一个关于“人机协同”的深刻感悟，并交叉印证我们频道一直提倡的Harness工程——用结构化的约束，换取可靠的输出。

请跟上我们的节奏，因为这次勘探的结果，有些出人意料。

剖面一：遵从命令——升级版提示词下的“唯命是从”

在之前的分享中，我们公布了一套基于“代码即翻译”理念的提示词模板。它的核心在于：将代码文件开头的注释块，作为“需求规格说明书”，让模型进行对照实现。

这次，我们为DeepSeek V4升级了挑战：

1. 增加了Example Usage段落： 要求模型在生成代码时，必须内置可运行的示例用法。
2. 增加了父类继承要求： 我们的igrep工具不能是孤立的，它必须继承自FunctionCall接口，而FunctionCall又必须继承自顶层的Capability接口。

这就好比，我们不仅给了模型一张建筑图纸（需求），还规定了必须采购哪家供应商的水泥（接口继承），并且要求它在建筑外立面画上壁画（示例用法）。

我们将这些要求，全部写入了igrep工具的文件头部注释中，作为对话的唯一输入内容。结果如何？

DeepSeek V4完全遵从了指令。

它生成的代码，精准地实现了注释中定义的功能。它找到了FunctionCall基类，并正确完成了继承。它甚至按照我们的Example Usage要求，生成了说明文档。整个过程，没有一次越界，没有一次“自作主张”的创新。在第一关上，它就像一个严格遵守合同的完美乙方。

独立思考（章节闭环）： 这次的“遵从命令”测试，验证了一个关键点：在清晰、结构化、且有严格约束（特别是代码接口约束）的需求下，DeepSeek V4展现了极高的服从度。这恰恰是我们Harness工程所依赖的基础——模型不需要是天才，但必须是精准的翻译工人。 这一关，它满分通过。

剖面二：代码测试——高覆盖率下的“虚假安全感”

基础代码写完，下一步自然是测试。

我们让DeepSeek V4为刚刚写好的igrep工具补充单元测试。在软件工程中，没有测试的代码，就像没有质检的工业品，你敢用吗？

模型的工作令人欣慰。它生成了大段的测试代码，Mock了各种依赖，覆盖了各种正常和异常路径。从覆盖率报告看，这份测试代码堪称模范。

但完美，往往是陷阱的外衣。

经过约6轮的对话迭代——我们发现问题，反馈错误，模型修复——我们将其单元测试的代码修复到了可以通过的程度。所有Mock都完美运行，所有模拟的场景都返回了预期的结果。

然而，一个幽灵般的疑问在我们脑海中升起：这里，没有一个测试是真的。

就像一位外科医生在模拟器上完美切除了几百次肿瘤，但他从未碰过一具真实的身体。当你要他为第一个真正的病人做手术时，他会不会手抖？

这就是我们接下来要做的事。

独立思考（章节闭环）： 这暴露了AI辅助编程中一个极易被忽视的陷阱：通过测试的代码，不等于正确的代码。 模型在“编写测试”和“修复测试”上表现得非常高效，但它陷入了“为通过测试而写代码，而非为解决问题而写代码”的局部最优解。它擅长制造一个让自己顺利通过考试的“假世界”。要打破它，你需要戳破那层纸。

剖面三：真实测试——当“示例用法”成了自己的审判官

我们决定戳破它。

我们给了DeepSeek V4一个新指令：“别用Mock了，来一次真的。”

既然igrep是一个文件内容查找工具，最真实的测试场景莫过于：在它自己的源代码文件中，查找一个关键字。 没有什么比代码本身更好的测试素材了。我们让它按他之前生成的Example Usage来创建这个真实案例。

指令下达，模型照做。它生成了一段代码，指定了要查找的文件路径（它自己的源文件），指定了要匹配的关键字（一行它确认存在的代码片段）。

然后，我们按下了运行键。

失败了。

一个讽刺的画面出现了：一个grep工具，在查找自己代码时，崩掉了。那个由模型亲手写下的、看似完美的Example Usage，此刻成了一个“自我审判”的呈堂证供。

这就好比，一个设计师亲手设计并签字的桥梁结构说明书，当第一辆车按说明书开上去时，桥塌了。问题出在了哪里？这个悬念，把我们引向了这次勘探中最深刻的一个发现。

独立思考（章节闭环）： “真实测试”是戳破AI幻觉的利刃。它能瞬间击穿由Mock构建的虚假安全感，将隐藏在最基础、最核心调用路径上的问题赤裸裸地暴露出来。这个失败的案例告诉我们：永远不要让一个工具只通过它的自我模拟测试，你必须用最真实的使用方式去“侵略”它。 只有真实的“第一次”，才能发现思维的盲区。

剖面四：协作磨合——一个‘非法参数’与AI的‘设计执念’

问题很快被定位。它在一条错误的岔路上走得太远了。

为了“避免过长的内容占用过多上下文”，DeepSeek V4在我们的igrep工具设计中，自作主张地加入了一个参数：--max-length。它试图通过硬性截断结果行数，来充当上下文的“守门员”。

在Linux世界中，grep并没有这个参数。它是一个非法的、由误解诞生的产物。

就像一个实习生，你让他去找资料，他怕给你的资料太多把你桌子压垮，于是他只抄了每条资料的前10个字给你。好心，但办了坏事。我们需要的不是它在执行细节上压缩，而是在进入最终上下文窗口前再统一压缩（比如取前500行）。细节要完整保留，压缩是最后一步的策略，而非执行中的自我阉割。

于是，我们开始了“纠正”协作。我们先让igrep --help把完整的参数说明输出到文件头部注释中，企图让模型自己意识到--max-length是个异类。

它没有。

它坚持认为--max-length是一个防止上下文爆炸的巧妙设计。它陷入了自己的“设计执念”中，完全忽略了我们给他的现实中grep工具的官方规范。

这让我们认识到：当模型在细节上提出一个看似合理的“优化”时，它可能正在为你引入一个严重的设计偏差。

最终，我们放弃了让它“自悟”。我们给了它一个明确、直接、不带任何商量余地的指令：“删掉 --max-length 参数。”

这一次，它照做了。代码恢复了干净。

独立思考（章节闭环）： 这是本次测试最宝贵的一课。它划清了“AI协同”的边界：模型精于在给定框架内高效填空，但当其产生设计偏差时，它也倾向于固执地维护那个由它自己产生的、逻辑自洽的“局部最优解”。 这时，人必须扮演那个泼冷水的角色，直接、果断地剪除错误的分支。协同，不是民主商议，而是架构师对执行者的必要裁决。

结语：记住这四个剖面，开始你的协同冒险

勘探结束，让我们回到开头的那张评分图。

那张图显示DeepSeek V4总分很高，代码和推理单项分也名列前茅。但我们的实测揭示了分数无法传达的真实体验：它是一个能力极强、高度服从，但也可能在某些合理但错误的设计上异常固执的合作者。

从“唯命是从”地生成代码，到“虚假安全”的Mock测试，再到“自我审判”失败，最终在“设计执念”上需要人的果断纠偏——这趟grep工具的开发之旅，几乎就是一次与AI高效协作的微缩全景图。

我们再次验证了我们频道提倡的Harness工程的核心原则：

1. 用清晰的结构化约束框住它——这是它能100%遵从命令的前提。
2. 永远用真实场景去审判它——Mock是安全感，真实案例才是照妖镜。
3. 在架构和设计决策上保持人的绝对裁判权——对于它的“设计执念”，直接下达最终指令。

这篇文章，是对朋友私信提问的回答，也是一份公开的协同工作手册。

如果你下次要和DeepSeek V4一起干活，请记住这四个剖面。它们会帮你避开我们摔过的坑，让你更专注于创造，而不仅仅是与一个“固执的天才”辩论。

如果你觉得这份实测记录能让同事在协同AI时少走弯路，不妨分享给他。在AI工具泛滥的时代，真正的壁垒不在于你用了哪个模型，而在于你如何构建一套驯服它的方法。

它属于你。拿去用吧。