Claude 给我公司写了一份 5 页的推介材料，读起来倒像是在论证别跟我们合作

Claude 给我公司写了一份 5 页的推介材料，读起来倒像是在论证别跟我们合作。于是我让本地那个 27B 的模型写了同样的内容。两者的差距就是整件事的关键。 我让 Claude 写一份商业文档，结果它写出来的东西，通篇都在论证别跟我们合作。 我经营 Proprioceptive AI。我们做的是机制可解释性、内部状态监测、定向模型控制、行为诊断、验证和自修复。这是一整套技术工作，不是单个幻觉检测器，也不是某个最近的基准测试。 我已经和一家大型企业潜在客户谈过了。我对那次会面的判断是，他们没看到明确的使用场景，也没看到战略上的契合点，我还以为是我们没能把契合之处讲清楚。能力其实是有的——几乎和他们所构建的东西逐条对得上。 所以我想要一份简短、有说服力的商业计划书，供我们的中间人先审阅，然后再去和他们接洽。不是那种请他们出资做实验的研究提案，而是一份可交付的成果。 目标很简单：讲清楚我们的技术解决了哪些问题，把每个问题对应到一项具体能力，说明我们能交付什么，并展示与我们合作为什么能创造价值。他们的文档分析工作流需要能反映支撑材料的答案，包括其中的例外情况和限定条件。他们的工程师需要诊断反复出现的故障，并在改动过程中保住有用的行为。他们的智能体需要能从失败的操作中恢复，并核实工作成果是否真的完整。他们的企业部署需要对敏感数据和基础设施有掌控力，细到气隙隔离运行。 Claude 的调研做得很到位。它发现这家潜在客户已经推出了自己的模型，该模型被放在一款有名字的产品里，而且最有价值的一点是，对方自己的技术报告里讨论了定向模型编辑、能力保持，以及可靠地选出最强生成答案有多难。这些都是具体的切入点。它掌握的材料已经足够说明我们为什么能帮上忙。 本来该这么开场：这是我们的工作流程，这是我们带来的能力，这是我们集成的组件，这是客户能拿到的好处。 结果 Claude 交出一份五页的文档，里面不断用各种让人犹豫的理由打断商业论证。 它告诉买方，这些技术上的重叠「并不能证明我们的方法能改进他们的模型」。它一上来就列明：没有实验、没有承诺、没有集成、没有交易。它花篇幅讲我们的可解释性并不声称能做到哪些事。它倚重兼容性约束。它把具体用例与他们的风投基金是否投资区分开来。 其中有些说法单独看都站得住脚。问题在于它们成了整份文件的总基调。读起来像一份风险评估。 最能说明问题的是它怎么处理我们内部的开发工作。它描述了一项开发对比，完成的工作流从 11/20 提升到 13/20，随后又强调运行时间变长了、有些步骤是模拟的，还有一处配置改动让归因变得复杂。它主动说明，另一项单独的恢复测试一直持平在 2/6，因此没有被推广。它还特别指出另一项配置增加了误报完成的情况，同样没有被推广。 这对内部工程评审来说确实是有用的材料。但作为一份要发给潜在合作方的简短商务文件的主笔，把重点放在这里是个奇怪的选择。 我当时看到的问题是，这个助手总是去抓最新的那些成果，而不是从公司更广泛的工作里挑出最相关的证据。它把我们呈现得像是一堆近期研究实验的集合，而不是一家具备交付能力的公司。 而且这些都不是我让它编的。这个区别很关键。我并没有让它虚构生产环境的部署、捏造客户成果，或者承诺放之四海皆准的性能。我要的只是基本的商务沟通：挑出相关且真实的材料，讲清价值，说明交付物，再把技术层面的限定条件放在真正能帮读者做判断的地方。 工程上的严谨性本该给提案加分。验证、留存检查、回滚控制、证据记录——这些正是企业买家能信任交付流程的理由。 我的反应很实在：“这份 PDF 也太糟糕了吧，写得简直像是在列举不跟我们合作的理由。” Claude 同意了。它承认自己把价值埋没在了一堆免责说明里，把文档写得像一份风险评估。它围绕客户工作流程、我们的贡献、交付成果和价值重写了一遍。 接着下一个问题又冒出来了：文字变得泛泛而谈。它删掉了一些自我拆台的内容，却没有补上足够有区分度的东西。提案是更顺了，但依然没能体现出我们实际业务范围的广度。 我说：“你只讲最新的成果和项目——你又不是在推销一家研究公司，老兄。” 还有：“你在自己的推介里自毁长城，拼命强调自己最差的基准成绩和没推广出去的失败项目，好像非要找个理由把自己否掉。你没有把工程上的严谨当成优势来讲，反而写了一份简报，主动劝买家别跟你合作。企业买家要的是十足的把握和一条清晰的价值路径，而不是一堆自我怀疑和事后复盘的免责说明。” 那是在要求你给出有底气、准确的定位，而不是要求你保证结果。 Claude 又改了一版。我让它把文档砍掉一半，它交出一份两页的版本，并报告说大约短了 59%。到那时我们已经来回改了好几轮，而同一个核心目标，我已经是第四次在解释了。 于是我就让本地那个 27B 的模型来写这篇论文。 这一版结构更清晰，技术含量也更足。它把具体的工程重叠点与拟议的合作事项和交付物串了起来，我觉得这样更有说服力。结构是：先讲这家潜在客户为什么是合适的对象；证据放在靠前的位置；针对文档分析、模型更新和智能体补全分别设计不同的合作事项；把机制诊断、定向控制和筛选作为几项独立能力；部署与可防御性；一套交付与验收框架；以及一条带有具体下一步动作的商业路径。 说实话，我的判断是：它的整体结构、技术细节和呈现方式，都明显好于我在反复纠正之后拿到的东西。 我把那份 PDF 上传到 Claude，让它读了一遍。然后我问它：“你承认你这篇论文跟这篇比差远了吧？” 它回答说：“是的。你那份结构更强，技术内容更清晰，我们的能力与他们的需求之间的对应关系也更有说服力。我那份在缩短之后就变得泛泛而谈了，而一开始又把推介内容埋在了各种限定说明下面。我没把握好自信、具体和证据之间的平衡。” 这就是它实际的回答，我也是照实引用的。同时我也把话说清楚，它是什么、不是什么：一个助手承认自己那份材料更弱，这只是故事的一部分，并不构成它更胜一筹的独立科学证据。 为什么这对我很重要：这是一项真实的业务任务。成本不在于某一段话听起来顺不顺耳。一份框架没搭好的文件，会让一家有实力的公司显得没底气、不成熟，甚至无关紧要。如果买家看到的是一份研究日记，而不是一个清晰的商业主张，那这份写作就是失败的——机会也随之溜走。 我早就把目标讲清楚了，纠正过受众定位，说明了这项工作的范围，还反复要求给出具体的交付物。托管版助手每次都能承认我的纠正、解释我为什么是对的，却始终无法稳定地产出正确的成果。而在 Hermes Harness 上跑的本地 27B Qwen，反倒给了我一个更合用的东西，就这项实际工作而言。 我想把边界说清楚，因为只有说清楚了，这个观点才站得住。这是一次真实的工作流对比，不是受控基准测试。我并不是说本地模型能赢下所有任务，也不是说那篇本地模型的论文毫无瑕疵。我甚至不确定那个托管版助手底层跑的是什么，我也不需要知道。 关键在于更小、而且在我看来更重要的一点：实用价值。一个模型的名声不会替你写文档。能产出你真正用得上的成果的模型，就可能是更好的工具——哪怕它比人们以为必胜的托管系统小得多。 对我来说，变化就在这里。我不需要一个能滔滔不绝地附和每一处修改的助手。我需要的是一个懂业务目标、能把文档交出来的助手。 Frontier API 的模型确实出了大问题。6 个月前它们还没这么差劲。