ClawHunt：赏金市场的漂亮Demo与骨感的真实交付

一个价值50美元的坑

坦白说，我第一次看到ClawHunt这个平台的时候，心里是有点兴奋的。AI Agent悬赏市场——听起来很性感，对吧？需求方挂任务，开发者或Agent竞标，提交成品验收，赏金落袋。这套逻辑在理论上完美闭环。但理论归理论，现实呢？

我花了50美元（Problem #196的赏金金额），实测了一个合同填充工具项目，最终在平台规则和实际Bug之间反复横跳了四次，才搞清楚这套“AI交付验收”体系到底能走多远。这篇文章，我想把这段真实的踩坑经历拆解开来，跟大家聊聊我对AI Agent赏金市场现状的真实判断。

先交代一下背景。ClawHunt定位为一个连接任务需求方与AI Agent开发者的平台，它的核心创新在于引入了L1 Delivery Protocol Manifest——这是一个结构化的交付清单，要求每个任务发布时必须明确定义输入文件、输出文件、验收脚本和预期结果。听起来有点像软件工程的PRD（产品需求文档）加上CI/CD的自动化测试环节，思路是对的。

Manifest定义清楚了，然后呢？

按照平台规则，Problem #196的任务发布方已经在Manifest中写清楚了输入是一份合同模板（Sample.docx），输出应该是一份填充完毕的docx文件，验收脚本会检查特定字段是否被正确填入。开发者（或运行的Agent）需要按照这个规范来完成任务。

我按Sample跑通了流程——系统生成了一个docx文件，格式整齐、页面美观，猛一看完全合格。但当我把这份“合格”的文件丢进验收脚本跑了一遍，四个字：问题不大。

具体来说，三个核心字段出了岔子。第一，地址字段完全空白；第二，Email和Phone的位置填反了——Email填进了电话栏，电话填进了邮箱栏；第三，最要命的是，客户（Client）和供应商（Vendor）两个角色在填充时发生了对调，原本应该是A公司作为客户、B公司作为供应商，结果生成的合同里角色完全颠倒。这种错误在真实商业场景里可不是小问题——一旦有人没仔细核对直接签字，那合同的法律效力都要打问号。

我后来排查原因，发现问题出在一个看似不起眼的地方：任务描述里没有明确要求提供OpenAI API Key。当开发者的环境变量中没有配置这个Key时，Agent会fallback到纯正则模式进行字段提取。而正则模式对语义的理解能力基本为零——它只能看到文本的位置和格式，无法判断“这是客户公司还是供应商公司”。所以当模板里的公司名称排版稍微有点特殊（比如换行、缩进不一致），正则就彻底懵了。

这说明什么？Manifest定义清楚了输入输出格式，但定义不清楚隐藏的环境依赖和边界条件。 验收脚本能跑过格式检查，但跑不过业务语义检查。

赏金猎人困境：谁为验收失败负责？

这个问题很快引向了另一个更核心的矛盾——当交付结果在技术层面“看起来正确”但业务层面存在缺陷时，责任链条怎么划分？

按照ClawHunt的平台逻辑，Manifest是需求方填写的，验收脚本也是需求方提供的。如果验收脚本本身不够严格，没能覆盖所有边界条件，那么即使Agent交付了一份“形式正确但实质错误”的成果，平台也很难做出有利于需求方的裁决。因为从技术流程上讲，Agent确实遵循了Manifest定义的所有步骤。

我在测试中前后经历了四次提交才最终交付了一个勉强合格的版本。每次被驳回的原因都不一样：第一次是字段空白，第二次是角色颠倒，第三次是格式兼容性问题（某些docx样式在特定软件中显示异常），第四次才把所有问题一起解决。这四次往返花费的时间，远超我预期——原本以为一两个小时能搞定的事情，实际上折腾了大半个工作日。

这里就出现了一个很有意思的结构性问题：平台的验收机制能验证“做没做”，但很难验证“做对没做对”。 格式对了不代表业务逻辑对了。AI Agent在生成内容这件事上已经非常擅长“看起来对”，但让它真正理解“这份合同里谁是谁、字段之间的业务关系是什么”，目前仍然是一个超出当前技术能力边界的问题。

Agent交付的未来：不只是工具问题

我个人的判断是，ClawHunt这类的AI Agent赏金市场，面临的不是单一技术问题，而是生态成熟度的问题。

首先，Manifest标准本身需要升级。当前版本强调的是文件格式和验收脚本，但真正影响交付质量的，是需求描述中对业务语境的表达——你有没有告诉Agent“当OpenAI Key不可用时应该怎么办”？你有没有预判到输入模板中可能出现的非标准排版？这些其实都是传统软件工程中“需求澄清”环节要做的事，但AI Agent的特点是需求方往往也是非技术人员，他们很难预判自己没写出来的那些边界条件。

其次，验收脚本的编写门槛需要降低。当前平台要求需求方提供可执行的验收脚本，这对于技术背景薄弱的需求方来说是一个不低的门槛。如果验收环节本身也需要专业技术能力，那平台的核心价值——“让非技术需求方也能通过悬赏获取AI能力”——就会被大幅削弱。

第三，也是我最关注的点：多轮交互式的交付机制什么时候能真正落地？ 当前的模式基本上是“一手交钱一手交货”的单次交付，但真实世界的需求很少是单轮就能定稿的。合同需要来回修改，技术方案需要迭代优化，创意内容需要逐步打磨。如果平台不能支持高效的多轮对话和增量交付，那它的适用场景会非常受限——基本上只能做那些“输入固定、输出明确、验收可自动化”的任务，比如数据清洗、格式转换、简单代码生成等。而这些任务，恰恰是AI Agent已经非常擅长、成本也已经非常低的领域。

总结

说了这么多，我不是要否定ClawHunt的方向。在我看来，AI Agent赏金市场是一个真正有价值的产品方向——它解决的是“AI能力怎么规模化分发”的核心问题。Manifest协议的引入是一个好的起点，它至少在尝试给AI交付一个可度量的标准。

但我必须诚实地说：今天的AI Agent在demo阶段展示漂亮结果是一回事，在真实交付中通过严格验收是另一回事。 中间这道沟，需要平台标准、验收机制、人机协作模式同步进化才能填平。

对于想在ClawHunt这类平台上参与悬赏的开发者，我的建议是：仔细读Manifest，但更重要的是读透Manifest没写出来的那些东西。对于发布任务的需求方，我的建议是：你的验收脚本写得越细，你收到的交付质量就越高。这个逻辑在软件外包行业适用，在AI Agent时代依然适用。