Ducklab 这个项目最抓人的地方不是“又一个开发工具”的新增功能而是它自带的一组记录416 次运行、总成本 176 美元、全程接入本地模型。翻译成更容易理解的说法就是这是一个用本地模型驱动、在循环中不断修改代码和验证结果的 dev harness而且它在低成本条件下真的跑出了足够多的有效迭代。如果你打算做 AI 编程工具链或者在研究“让工具自己改进自己”的工作流这篇文章值得看完。这里不会吹它能替代人工编码而是把它背后的执行闭环拆开讲清楚这类 dev harness 到底怎么搭、跑起来有哪些边界、遇到问题从哪排查。先给一个总体判断这类“自我构建”工具链的核心不在模型多聪明而在验证循环多便宜。Ducklab 的 416 次运行能控制在 176 美元说明它把单次运行的边际成本压到了很低低到可以不断试错。本地模型在这里不是噱头而是成本控制和数据隐私控制的关键。下面我按实际落地顺序把这个思路拆成可执行的方案。1. 先确认它解决的到底是开发验证问题还是“自动写代码”问题很多人看到“built itself”容易往“模型自动写整个软件”方向理解这个方向其实偏了。把 416 次运行和“自我构建”组合在一起看它更接近一个开发验证问题让模型在每一次运行里承担一部分代码生成、修改、修错的职责然后由测试命令判断结果是否可用。和纯聊天式 AI 编程不同这种 harness 有一个明确的闭环。1.1 dev harness 到底是个什么东西dev harness 可以理解成开发阶段的脚手架。它负责把“开发任务”和“验证环境”捆绑在一起典型组成包括一个任务来源可以是 issue、任务描述、失败测试、TODO 列表。一个工作区实际存放代码的目录通常是 git 仓库。一组验证命令构建脚本、单元测试、lint、集成测试。日志采集每次运行之后把 stdout、stderr、退出码、diff 保存下来。反馈回路把验证结果再次送入模型让它调整下一步动作。日常开发里很多团队其实已经有一个简化版 harness改完代码跑测试测试挂了看日志再改。Ducklab 这类项目的特殊性是把“看日志—改代码—再跑”这个循环自动化并让本地模型充当那个“改代码”的角色。这解释了为什么它强调 416 次运行。手动改 416 次要耗费大量时间机器跑 416 次测试则非常快。只要每次验证的脚本足够聚焦这个循环就可以很廉价。1.2 “built itself”不是玄学而是一个生成—验证—修正循环把“self-built”拆开看本质是从任务列表取一个明确的开发任务。把任务描述、相关代码、当前失败信息拼接成 prompt。本地模型输出代码补丁或完整文件。把补丁应用到工作区。运行测试命令验证。测试通过提交这次变更测试失败回滚并记录失败信息。把失败信息作为新上下文进入下一轮。整个过程中模型只负责“生成候选方案”真正决定能不能合入的是测试脚本。所以这个 harness 的核心是验证能力不是生成能力。没有自动化测试覆盖的代码仓库跑这类循环会非常不稳因为模型改出来的东西可能测试通过了但功能不对甚至测试本身没有覆盖关键逻辑。1.3 416 次运行和 176 美元这两个数字意味着什么这两个数字放在一起信息量很大。按 176 美元除以 416 次计算单次平均成本大约 0.42 美元。具体每次成本不同但这个量级说明它没有用高价的云端大模型作为主力而是靠本地模型把单次推理成本压了下来。更重要的是 416 次这个样本量。“跑一次”不等于“成功一次”真实项目中会有大量失败、回滚、重新生成。如果每次运行要花几美元416 次会是一笔不小的开支如果能压到几十美分那这种试错策略就可持续。本地模型的价值在这里体现得最直接它不按 token 计费主要成本是电费、硬件折旧和运行维护时间。需要提醒的是416 次运行可能包含多种类型生成代码、补丁失败、重试、成功提交、环境检查、回归验证。不要把它理解成“416 次都成功”。这种循环里失败是正常状态成功的标准是最后产生了可合入的变更。2. 本地模型驱动的开发工具链到底适合什么场景不是所有编码任务都适合丢给本地模型。这个方案最适用的场景往往同时具备三个特征任务结果可以被程序判定、代码仓库有测试覆盖、模型需要访问的上下文不会超长。缺了任何一个跑起来都会很别扭。2.1 哪些任务适合交给本地模型按我偏向的经验适合先尝试的任务类型包括单元测试补全已经有了待测函数模型生成边界测试。简单 bug 修复测试报错信息明确比如数组越界、空指针、函数签名对不上。代码格式化或机械重构变量重命名、函数提取、常量替换。配置修复依赖版本冲突、CI 脚本拼写错误。文档与注释生成结合代码结构生成说明再通过 lint 或格式检查验证。这些任务有一个共同点成功与否有相对客观的判断标准。单元测试能过就是能过修复配置后构建成功就是成功。模型不需要理解太多业务背景只需要根据当前文件和错误信息调整。不适合的任务也有明显特征。比如“把这个模块设计得更好”“优化老系统性能”“理解未文档化的业务规则”这类目标很难用一个测试命令表达模型生成结果后你无法自动判断正确性。勉强放进 harness只能靠人工审核每个 diff成本反而更高。2.2 本地模型和云端模型的取舍我在实际项目中的感受是不要做“二选一”而是做“任务分级”。本地模型适合高频、低风险、上下文可控的任务云端大模型适合低频、复杂、需要大量常识或长上下文的任务。本地模型的好处不是质量全场最优而是三个点隐私好代码不用离开本机很多公司对这个有硬性要求。成本稳定跑多少次主要看电费和占用时间没有突发的 token 账单。离线可用网络受限环境里也能持续跑。劣势也很明显推理速度慢、模型参数量有限、对长上下文处理容易丢信息。同样一个任务云端模型可能一次就改对本地模型可能要试五次。但只要测试脚本能拦住错误多试几次的成本仍然可控。更实际的策略是混合模式harness 默认用本地模型跑验证循环复杂任务或连续 N 次失败后人工介入或者把人切换到云端模型完成一次补丁再回到本地模型继续循环。这样既控制成本又保留兜底能力。2.3 运行环境到底要准备什么按照常见配置本地模型跑代码生成至少要有这样几条环境项起步要求推荐配置说明操作系统Linux / macOSLinux 服务器或开发机Windows 也能跑但命令、路径、权限问题更多CPU4 核以上8 核以上加载模型、跑测试、处理日志都会占 CPU内存16 GB32 GB 以上模型推理和测试进程同时跑时会明显吃内存GPU可选NVIDIA 显卡显存 8 GB 以上没有 GPU 也能跑小模型但很慢磁盘20 GB 空闲50 GB 以上模型权重、git 历史、日志都会累积推理运行时任选一种Ollama / llama.cpp / 其他兼容服务要能通过接口或命令行向模型发请求代码仓库git 仓库git 仓库 干净的基线回滚和审计依赖 git验证命令一条可重复运行的测试命令秒级单测 分钟级回归验证越慢试错成本越高比起具体型号我更建议先确认测试命令的“成本”。如果测试命令要跑 10 分钟哪怕模型单次生成只要 1 分钟整个循环也会被拖慢到不可用。所以第一步不是选模型而是把验证命令压缩到足够快至少能接受连续跑几十次。注意这里不要一上来就把并发和参数量拉满先用一个小模型、一条最快测试命令跑通全流程再逐步放大。3. 搭一个可复用的 self-building harness核心循环怎么写这类 harness 的本质是一个循环脚本。下面给出的是通用闭环设计不是 Ducklab 的原始代码但思路完全够用。3.1 最小闭环任务描述、生成代码、跑测试先从一个最简单版本开始。流程是从 tasks 目录读取一个任务描述文件。用模板拼 prompt包括当前代码片段、任务描述、失败的测试输出。调用本地模型接口拿到补丁。把补丁写入代码目录。运行测试命令收集退出码和输出。通过则提交 git不通过则 git 回滚。把结果追加到日志开始下一个任务或进入重试。这个最小闭环看着简单真正能跑起来要解决三件事prompt 怎么拼、补丁怎么应用、失败信息怎么反馈。三者分别对应输入格式、变更应用、上下文管理。3.2 让失败信息变成模型的下一步提示很多自构建工具跑不好不是因为模型弱而是因为失败信息没有有效传回模型。典型错误是把整个终端输出塞进 prompt模型看到几百行无关日志反而找不到关键错误点。更有效的方式是提取关键信号退出码说明是测试失败、超时、还是崩溃。第一处错误定位文件名、行号、函数名。断言信息期望值和实际值。stderr 中包含的异常类型。diff 与最近一次变更的差异。把这些信息按固定结构拼回 prompt模型才知道“刚才你改了哪个文件测试在哪里失败现在需要调整什么方向”。我一般会在日志里保留完整输出但只把关键片段送入上下文避免上下文被无用日志撑爆。3.3 用 git 做回滚和审计没有 git 的 self-building 循环非常危险。模型连续修改代码后如果每一轮都基于上一个失败状态叠加补丁代码会迅速变得不可维护。正确做法是每一轮实验开始前把当前 HEAD 记下来应用补丁后如果验证失败就立刻 reset 回基线。审计也很有价值。每次运行至少应该记录运行编号和开始时间使用的模型和后端任务 IDprompt 的输入摘要模型生成的补丁或代码测试命令、退出码、关键输出是否回滚这些日志既是排查依据也是成本分析的数据来源。没有日志416 次运行结束后你只能看到一个结果无法知道哪些任务反复失败、哪个模型配置更适合哪类问题。3.4 一个最小示意脚本下面给一个 Python 风格的逻辑框架重点不是语法而是循环结构。实际使用时要根据你的推理接口调整。import subprocess import os repo_dir /path/to/repo task_file /path/to/task.txt model_url http://127.0.0.1:11434/api/generate def call_model(prompt_text): # 示例向本地模型服务发请求 # response requests.post(model_url, json{model: local-model, prompt: prompt_text}) # return response.json()[response] return 生成的补丁内容 def apply_patch(patch_text): # 示例将补丁写入文件或执行 git apply pass def run_tests(): result subprocess.run([pytest, -q], cwdrepo_dir, capture_outputTrue, textTrue) return result.returncode, result.stdout[-500:] result.stderr[-500:] max_runs 5 for run in range(max_runs): task open(task_file).read() prompt build_prompt(task, current_code, last_error) # 需要另写 patch call_model(prompt) apply_patch(patch) code, output run_tests() log(run, code, output, patch) if code 0: commit_changes(task finished) break else: rollback_to_head() last_error extract_failure(output)这套逻辑跑通之后再往里面加任务队列、模型切换、人工审批、并发控制都会容易很多。4. 关键参数设置与成本控制416 次、176 美元是怎么做到的只看结果数字很容易忽略中间的过程约束。成本能压到 176 美元通常不是靠某一个技巧而是靠多个参数共同控制。下面拆开讲。4.1 最大运行次数任务粒度和预算的平衡每一个开发任务不要无限重试。我给任务设上限时一般看两类指标任务复杂度简单修变量名3 次内不成功就停止涉及多文件改动可以到 10 次。单次运行成本如果测试很重重试次数应减少如果模型很快、测试秒级可以适当放宽。416 次这个总数如果是多个任务累计出来的那单个任务平均运行次数可能并不高。按经验一个任务反复重试超过 5 次后边际收益会明显下降因为模型往往在同一个错误点打转。与其让它继续耗不如换个模型、换个任务描述或者人工看一眼。4.2 单次成本怎么算本地模型的成本不是零。要准确核算至少要把这几项加进去电力成本GPU 满载和待机功耗差异很大。硬件折旧显卡、内存、硬盘按使用年限分摊。人工维护时间调 prompt、清理日志、处理环境问题都算成本。测试耗时占用测试跑得越久占用开发机器的时间越多。如果按“176 美元 / 416 次”这个平均思路单个任务重试超过一定次数后成本贡献就会放大。控制成本的第一步就是记录每次运行的耗时和资源占用没有数据就谈不上优化。4.3 并发、重试和超时本地模型推理并行处理时速度不一定是线性提升。多个进程同时向同一个模型服务发请求可能因为显存或内存不够而互相等待甚至导致 OOM。我自己习惯先跑单任务稳定后再尝试 2 个并发观察资源占用再决定是否加。超时设置也很关键。模型生成可能卡住测试命令也可能因为资源竞争而挂起。一定要给模型请求和测试命令分别设置超时时间比如模型生成 120 秒无响应就中断重试测试命令按正常耗时的 2 到 3 倍设置上限。重试策略同样要区分。模型调用失败可以重试测试失败不要盲目重试。测试失败带回滚模型调用失败只需要重新调用两者性质完全不同。4.4 控制成本的小技巧从实际运行经验看下面几个点对成本影响很大模型常驻加载不重复加载权重。每启动一次推理服务都要重新读模型文件时间和电费都不少。测试命令优先跑针对性测试不要每次都跑全量。先一条相关用例验证通过后再跑完整回归。只保留最近 N 条日志关键行不要把整个输出写入 prompt。代码变更尽量用 diff 或补丁方式不要让模型输出完整文件完整文件容易把无关内容改坏。定期清理临时文件、模型缓存和旧日志避免磁盘和内存被垃圾占满。同一批任务尽量按类型分组避免频繁切换模型和任务上下文。建议第一轮先跑 20 到 30 次小任务记录平均耗时和单次成本再决定要不要大规模推广。这样比直接放 400 次更稳。5. 结果怎么判断不能只看“测试通过”自构建 harness 里最迷惑人的情况是测试显示绿色但代码实际是错的。比如模型删掉了某个关键分支、改了配置后测试绕过了真实路径、或者补丁本身没生效但测试恰好通过。所以结果判断要从多个维度看。5.1 一条运行算成功的标准是什么我的判断顺序是这样的测试命令退出码为 0。补丁确实被应用到了预期文件不是空操作。diff 中没有意外删除的功能代码。测试的输出里有真实执行了相关用例而不是 skipped 或 no tests ran。变更可以通过 git diff 审查。第五点最容易被忽略。模型生成的补丁即使通过测试也可能包含大量无关改动。harness 可以自动合入“测试通过”的补丁但人工审计仍是必要的。尤其在没有测试覆盖的老代码上这种风险会放大。5.2 看日志不能只看最终结果单次运行的成功和失败只是最粗粒度信息。真正有价值的是过程数据。每次运行都应该能回答这几类问题这一轮改了哪些文件、哪些行测试失败时模型拿到了什么反馈模型是第一次就成功还是尝试了五次失败原因集中在语法错误、逻辑错误、还是超时哪些任务反复回滚消耗了多少成本把这些日志汇总后你会发现自己能针对性地优化 prompt、调整模型、裁剪任务范围。没有过程数据的 harness等于把每一次试错的经验都丢了。5.3 常见失败模式与识别方法第一类是模型输出不完整。常见表现是补丁文件被截断、括号不闭合、或者只输出了说明文字没有代码。这类问题可以在应用补丁前先做基础语法检查比如用 Python 的 compile 检查 .py 文件用 prettier 或 eslint 检查前端代码。尽早拦截避免把坏补丁带入测试。第二类是测试不稳定。测试本身有时序依赖、端口冲突、网络请求超时会导致同样的代码这次过、下次挂。如果发现同一份代码反复出现“一次成功一次失败”优先怀疑测试环境不要反复让模型修代码。第三类是环境不干净。上一轮任务留下的临时文件、数据库状态、缓存会影响下一轮测试结果。每次运行前把工作区清理到基线状态能减少大量假失败。6. 排查链路卡住、乱改、反复失败从哪里查起任何自动化工具跑久了都会出问题。最有效的排查方式不是先看模型而是按“现象—输入—环境—参数—工具”的顺序逐层收紧。6.1 先给现象分类我看到现象时会先分四类完全没有输出可能是模型调用失败、服务没启动、请求格式错误。测试失败这是最常见的说明补丁被应用了但没解决问题。测试通过但 diff 异常说明生成逻辑偏离任务需要检查 prompt 和上下文。进程卡死多半是资源问题或超时没生效。现象不同排查起点完全不同。如果卡死不要反复检查 prompt先看进程资源占用。6.2 按顺序排查输入、环境、参数、工具具体顺序可以参考下这一套看运行日志和退出码确认失败发生在生成阶段、应用阶段、还是测试阶段。看输入任务是否清晰上下文是否包含正确文件模型是否读到了最新代码。看测试环境是否干净依赖版本是否固定是否有残留进程磁盘是否写满。看参数是否合理最大重试次数、超时、并发、temperature、上下文窗口。最后才看模型本身量化等级、后端配置、是否被其他任务抢占。大多数“模型乱改代码”的问题最后查出来都是 prompt 里给的信息不完整。比如只给了函数名没给函数签名和预期输入输出模型只能猜。6.3 几个容易踩的坑现象常见原因排查优先级模型反复修同一个错误失败信息没完整进 prompt或日志被截断高测试有时过有时挂测试存在时序依赖或端口冲突高补丁不能正常 apply模型输出带了 Markdown 代码围栏中git 回滚后代码还是乱没有记录实验前的 HEAD高模型请求超时模型服务负载过高中内存持续上涨日志未清理、模型频繁加载中补丁 apply 失败是很典型的问题。很多本地模型喜欢在回复里写 python 代码块围栏如果脚本没有剥离围栏直接写文件就会混入多余字符。我自己会在应用补丁前先做一个清洗步骤删除代码围栏、删除“这是修改后的代码”一类说明文字再尝试 apply。另一个容易忽略的是路径权限。如果 harness 以服务方式运行工作目录权限不够模型生成的代码写入失败但测试用的又是旧文件就会出现“补丁没有生效但测试通过”的假象。排查时先确认脚本工作的用户和目录权限。7. 实际落地后的一些判断和边界把整个思路整理下来我认为 Ducklab 这类项目最有价值的参考点不是“本地模型能写代码”而是“让机器自己迭代代码的验证循环可以做到多便宜”。这个方向对很多团队是有启发意义的但也要看清边界。7.1 不要对本地模型抱有不切实际的期待我建议把本地模型当成一个“愿意反复试错的初级工程师”而不是“资深架构师”。它能根据错误信息调整代码但容易忽略大范围上下文也缺少长期记忆。你的 harness 设计得越好它犯错的成本就越低反过来如果指望模型一次写好本地模型很容易让人失望。所以真正值得花时间的是完善测试断言、优化失败信息、控制补丁范围。这些工作能让“笨一点的模型”也产出可用的结果。416 次运行之所以能产生可接受的结果大概率不是模型每次都很准而是验证和回滚机制兜住了错误。7.2 这个方案适合谁不适合谁适合的团队通常具备这些条件核心代码有自动化测试覆盖测试命令可以快速执行。大量任务属于重复性修改比如补测试、修告警、做机械重构。数据隐私要求高不希望代码发送到云端。有预算约束或希望成本可预测。不适合的情况也很明确项目几乎没有测试模型改完无法自动验证。业务逻辑高度依赖团队内部知识和历史决策。任务描述无法量化只能靠人工看结果。如果你所在的项目还在积累测试覆盖阶段不要急着搭这种自构建工具。先把几个核心模块的测试补齐再让模型参与否则它只能帮你制造更多待审阅的 diff。7.3 下一步可以怎么扩展跑通最小闭环后有几个方向可以继续做加任务队列从文件清单变成支持动态追加任务。接入多模型本地模型失败后自动切换到更复杂的模型作为兜底。增加人工审批模型生成的 diff 先暂存人工确认后再合入。输出可视化把每次运行的耗时、成本、失败原因汇总成报告。加失败聚类把相同错误信息归为一类避免同一个问题反复消耗预算。更进阶的方向是让 harness 不仅能修 bug还能自己补充测试用例、评估补丁质量、回滚异常提交。这些功能都会让“自我构建”更接近真实开发流程但每加一层复杂度也会上升。我个人更建议先把单任务跑稳再考虑批量和扩展。踩过几次教训后你会发现这类项目真正决定成败的往往不是模型选得多新而是任务描述、验证命令、日志和回滚策略有没有组织好。把这几样做扎实416 次运行和 176 美元这样的结果就不只是运气而是可以被复制的工作方式。