企业官网建设流程全解析

先别被标题里那串黑话劝退。OpenClaw、Moltbot、规格驱动开发，拆开看就是一套很朴素的东西：让AI自己给自己记笔记，自己检查自己干的活，干错了自己改，改完还把教训存下来，下次不再犯，最终在无人盯守的情况下按规格把开发任务跑完。我自己在模拟项目X上把这套流程完整搭了一遍，这篇文章就讲清楚它到底在自动什么、怎么搭、怎么调、坑在哪里。

这套玩法适合两类人。第一类：手上有一批重复性高、边界清晰的开发任务，想用Claude Code这类编码智能体批量完成，但没时间守着每一次运行；第二类：想尝试规格驱动开发（SDD），希望需求不是靠嘴交代给AI一封邮件，而是变成一份机器能读、能验收的施工图。不管你是哪个，这篇文章都不讲虚的，全是能落地到项目里的配置和流程。

1. 先弄明白这套系统到底在“自动”什么

我第一次看到“OpenClaw自动操控Claude Code”这个说法时，第一反应是：这不就是写个脚本调一下命令行吗？真上手之后才发现，真正的难点根本不在“调用”这一步，而在于怎么让AI在无人盯着的情况下，仍然不会跑偏、不会重复犯错、不会把项目折腾得一团糟。要理解这套系统，先得把标题里的几个角色认清楚。

1.1 一句话拆掉标题里的黑话

你可以把这套系统想象成一个迷你开发团队，每个组件都有自己的工种。我习惯用这个表格来给人解释：

分工是这样的：OpenClaw拿到一份规格文件，先拆出任务清单，然后启动Claude Code去执行；执行完之后，OpenClaw负责跑验证；如果验证挂了，它把报错信息回传给Claude Code，让它自己修；修完再验证，直到通过或者触达重试上限。Moltbot干的是另一件事：每轮任务结束后，它会把过程中踩过的坑、修正过的问题、总结出的规律，整理成结构化条目，存进记忆库。下一次启动任务时，它再把最相关的历史经验翻出来，塞进Claude Code的上下文里。

这正好呼应了标题里那句“自动学习避坑”——不是模型自己偷偷进化了，而是旁边的记忆系统在替它“长记性”。Claude Code还是那个Claude Code，但它每次干活之前，都会先收到一份“同类任务曾经踩过的坑清单”。

1.2 为什么说它会“越用越聪明”

很多人对“越用越聪明”有误解，以为模型参数会被自动训练。实际不是这样。自动进化机制本质上是三层东西在起作用：

• 经验复用：把过去任务中的成功方案、失败原因、修复步骤保存下来，在相似场景下主动命中。
• 规则约束：把团队约定、平台限制、项目红线写进规则库，每次执行都强制生效。
• 流程固化：把同类任务的最佳执行顺序沉淀成模板，避免每次重新摸索。

这三层合起来，就是“记忆系统 + 检索增强 + 策略调整”。模型本身没变，但喂给模型的上下文变了，所以它在具体项目上的表现会肉眼可见地变稳。我第二次跑相似任务时，Claude Code主动补了一个规格里没写的前置校验，那一刻我才反应过来：不是它变聪明了，是Moltbot把我第一次手动修过的坑记下来了。

理解了这套机制，下面的大方向就清楚了：我们的目标不是让AI一次写对所有代码，而是搭一个能把“错一次”快速转化成“永不二错”的闭环。这个闭环，是整个自动进化系统的骨架。

2. 核心思路：把开发流程变成一条可进化的流水线

自动进化不能只靠“跑一次看一次”，它需要把开发这件事拆成阶段，并且让每个阶段之间产生反馈。我用的思路是：规格驱动开发作为输入侧，三库体系作为记忆侧，自动修复循环作为执行侧。这三者咬合在一起，才形成了零干预的流水线。

2.1 规格驱动开发（SDD）为什么是自动化的地基

大多数人让AI写代码时，是直接甩一段需求描述：“帮我写个用户注册模块”。这种对话式的任务适合一次性问答，但完全不适合无人值守的连续生产。原因很简单：模糊需求会让Agent自由发挥，而自由发挥在无人监督时就是灾难。

举个例子。你跟AI说“实现一个注册接口”，它可能默认用户名是手机号，也可能默认密码长度是6位，还可能在注册成功时多发一个欢迎邮件。这些“默认行为”里，只要有一项和你的业务预期不符，后面就得人工去翻代码、改逻辑。零干预的前提条件是：需求描述本身没有任何二义性。

规格驱动开发（SDD，Specification-Driven Development）就是干这个的。它要求你在开工之前，把需求翻译成一张结构化的“施工图”。这张图里必须包含四类东西：

• 输入定义：接口接收哪些参数，各自的类型和约束。
• 业务约束：哪些规则是强制必须遵守的。
• 验收标准：哪些行为可以被自动化脚本断言。
• 范围之外：明确告诉AI哪些事情不要做。

SDD和TDD（测试驱动开发）不是替代关系，而是上下游关系。TDD管的是“代码写完之后怎么验证”，SDD管的是“开工之前需求怎么描述”。规格文件里的验收标准，最后会变成测试用例。有了这个地基，后面的任务拆解、执行、验证才能逐步自动化。如果没有规格文件，所谓“零干预”就是一个伪命题。

2.2 三个库：经验库、规则库、流程模板库

自动进化听上去很玄，落到工程上其实就是三个存储结构。我搭建的时候把记忆系统拆成了三个库，每个库的功能完全不同，混在一起一定会出问题。

第一个是经验库。它面向的是“这个场景曾经出过什么问题，怎么解决的”，作用是避坑。典型条目是这样的：

scene: 在目标平台打包时
symptom: 启动时闪退，日志显示动态库缺失
cause: 打包脚本没有把依赖目录一起拷进产物
solution: 打包前执行依赖收集，并把依赖目录加入产物路径

下次再遇到“目标平台打包”类任务时，如果Moltbot检索到这条经验，Claude Code就会在执行打包步骤前主动检查依赖收集环节。这就是避坑。

第二个是规则库。规则库不解决“怎么做更好”，只解决“什么绝对不能做”。它的粒度更硬，更像强约束。典型条目包括“所有对外接口必须设置超时”“禁止直接删除数据库记录，改用软删除”“生产环境配置变更必须走人工审批”。规则和经验最大的区别是：经验是“建议”，规则是“红线”。OpenClaw在组装任务上下文时，会把规则库的内容原封不动放进系统提示词里，没有商量余地。

第三个是流程模板库。同类任务的执行顺序其实高度相似，比如“后端接口开发”的标准顺序是：先明确出入参，再写实现，再补测试，最后跑回归。如果没有模板，AI每次都会从头摸索，可能先写测试又删掉重来。流程模板库把这类经验固化成步骤列表，让Agent沿着既定路径走。

三个库分别管三件事：经验库管避坑，规则库管底线，流程模板库管顺序。我见过很多人只搭了一个“记忆库”，把经验、规则、模板全塞在里面，结果Agent经常抓到一条“规则”时发现它描述的是“某次失败”，完全不知道该当强制要求还是当背景参考。分库存储看着多一步，实际省下的是无穷无尽的歧义。

2.3 任务循环的完整链路

整套零干预自动化的核心，是把任务循环固化成一条可重复的链路。我自己用的流程是这样的：

1. 目标解析：OpenClaw读取规格文件，提取任务名、模块范围、验收标准、涉及的技术栈。
2. 任务拆解：大任务按规格切成可执行的子任务，每个子任务尽量只改一个方向，便于定位问题。
3. 经验注入：Moltbot根据子任务的标签检索经验库和流程模板库，把最相关的内容插入上下文。
4. 执行与验证：Claude Code按任务卡片执行，OpenClaw在关键节点跑测试、编译和静态检查。
5. 自动修复：验证失败时，把失败日志回传，让Claude Code根据日志定位问题并修改，然后重新验证。
6. 经验沉淀：一轮结束后，Moltbot把这次执行的差异点、修复过程、结果评分固化成新经验。

这里面最关键的一环是第5步。很多人理解“零干预”就是完全不看，其实不是。零干预的本质是：把“看”这件事，从人工盯着屏幕，变成了预先写好的自动验证加自动修复规则。OpenClaw每一轮验证都像一个工头在检查实习生干的活，检查发现不合格，不是马上打电话给老板，而是把问题清单扔回给实习生，让他自己重做。只有当重试次数耗尽或者遇到规则库禁用的操作时，系统才停下来等人工介入。

有了这条完整链路，再来看具体的搭建和配置，就会清楚很多。下面这部分我按自己实际跑通的过程写，字段名在不同版本可能不完全一致，但控制的核心参数和思路是一样的。

3. 实操：从零搭一套零干预的自动进化助手

说句实话，搭环境本身并不难，真正花时间的是理解每个参数在控制什么。我第一次搭的时候照着网上的配置直接抄，跑起来之后发现自动修复循环像疯了一样反复修同一个bug，烧了一大堆调用额度才反应过来：重试上限根本没配。所以这部分我会重点解释参数背后的权衡，而不只是给一份配置。

3.1 环境准备与目录规划

先说明一下：这套系统对机器性能要求不高，真正的计算发生在模型侧，所以不用配高规格服务器。重点反而是权限隔离和目录结构。

我的建议是单独创建一个系统用户，或者直接用容器跑，把这个用户的工作目录锁在项目目录里。不要给AI用户全局读写权限。原因后面讲权限失控时你会体会更深。安装层面需要准备两样东西：OpenClaw运行时与CLI，以及可用的Claude Code环境。Claude Code的环境要提前确认能正常启动、能执行读写操作，避免在自动循环里卡在环境检测上。

然后是目录规划。我用的结构是这样的：

projects/ simulation-x/ specs/ user-register.yaml workspace/ src/ tests/ logs/ run-2025-01-01/ memory/ experience.db

specs目录放规格文件，workspace是AI的作业区，logs按日期存每次运行日志，memory放经验数据库。之所以要单独开logs和memory目录，是因为AI在执行过程中会产生大量中间文件，如果不做隔离，很容易把项目仓库弄乱。日志也不只是事后排查用的，自动修复循环回传失败信息时，会直接引用日志里的报错片段，所以它必须是一个稳定路径。

3.2 核心配置：先理解参数再抄代码

我的配置文件核心部分长这样：

openclaw: runtime: claude-code working_dir: /home/aiuser/projects/simulation-x max_concurrency: 1 evolution: backend: local top_k: 5 similarity_threshold: 0.72 pipeline: stages: [spec_parse, task_split, execute, verify, retro] auto_fix: max_retries: 3 escalation: report_only

这里每个参数都值得展开说说。

max_concurrency（并发任务数）我一开始设成1。很多人一上来就开高并发，觉得并行效率高，但自动进化系统在早期最需要的是稳定反馈，而不是速度。并发一高，日志混乱、经验关联不清，出了错都不知道是哪条链路带偏的。等同一类任务跑稳了，再慢慢往上加。

top_k（检索经验条数）我设置为5。这个值控制的是每次任务注入多少条历史经验。直觉上会觉得越多越好，实际不是。经验注入过多会挤占上下文窗口，而且会让Claude Code分不清哪些经验是当前任务真的相关的。5条起步，后续根据无效命中率调整。

similarity_threshold（相似度阈值）我设置为0.72。这个参数决定一条历史经验会不会被检索出来。阈值低了会召回一堆“看起来像但其实无关”的经验，阈值高了则什么都匹配不到。0.72是一个相对保守的起步值，先跑几天看看命中质量再微调。

auto_fix.max_retries（自动修复重试上限）必须设置。没有这个上限，系统可能在一个bug上反复重试几十次，烧钱不说，还有可能把对的地方改坏。3次是一个安全起步值。超过上限之后的行为用escalation控制，我设置的是report_only，也就是停止自动修复，生成一份问题报告，等人工来看。注意：在早期磨合阶段，建议把max_retries设成0或者直接关闭auto_fix，先人工盯完几轮，把该沉淀的经验沉淀下来，再逐步放开。

注意：这类开源工具的迭代速度非常快，字段名在不同版本可能有差异。重点不是抄我的配置，而是理解每个参数在控制什么。拿到一个新的版本时，优先跑一个最小示例，确认参数行为符合预期，再上正式任务。

3.3 写一份能被机器看懂的需求规格

配置好了之后，第一件事不是直接写代码，而是写规格文件。我用一个注册模块的例子来说明。下面是一份我实际用过的简化版规格：

spec: name: user-register target: backend-api description: 实现邮箱注册接口 inputs: email: type: string rule: email_format password: type: string rule: min_length_8 constraints: - 密码与确认密码必须一致 - 新用户默认状态为active acceptance: - "POST /api/register 成功时返回 HTTP 200 和 token 字段" - "重复注册同一邮箱时返回 HTTP 400 和 error_code=EMAIL_EXISTS" - "密码长度少于 8 位时返回 HTTP 422 和 error_code=PASSWORD_TOO_SHORT" out_of_scope: - 短信验证码 - 第三方登录

这份文件里有几个点，是摸过坑之后才写出来的。

description不要写得太长、太文学。“实现邮箱注册接口”就够了。AI要的是范围，不是激励。把业务背景写太长，Claude Code容易把无关信息也当成需求，执行时反而跑偏。

acceptance是整个文件最重要的部分。它必须全部是可自动断言的、脚本能判断的行为，绝不能出现“体验流畅”“交互友好”这类人类主观词。每一条验收标准都应该能在测试里写成一个assert。这里的“返回200和token字段”“返回400和error_code”，都是可以直接落成测试断言的描述。

out_of_scope是我特别想强调的。早期我写规格文件从来不写“范围之外”，结果AI经常自己加戏，比如顺手实现了密码找回、第三方登录。单次运行倒无所谓，全自动运行时这种行为会直接污染项目。明确声明“短信验证码不做”“第三方登录不做”，等于给Agent画了一条高压线。

3.4 跑通第一轮：从手动纠错到自动避坑

第一次跑这套流程时，我强烈建议你不要开全自动。把auto_fix.max_retries设成0，或者直接关闭auto_fix，让验证失败后系统停在等待人工的状态。这个时候你的角色是“第一次经验注入员”——AI踩了坑，你去填坑，然后把这个坑变成经验库里的条目。

我的实际过程是这样的。第一轮任务跑完，测试发现了一个问题：密码校验只判断了长度，没判断空字符串。一个空字符串password长度为0，直接绕过了min_length_8的校验。Claude Code写的代码单看长度是过得了关的，但边界条件漏了。我手动在代码里补上了“输入统一trim后检查非空”这一层，然后把这条教训写成了经验卡片。

第二轮换了一个类似接口的任务，规格文件里依然没有写“非空”二字。但执行过程中，Claude Code在干活的步骤里主动停下了，备注了一句“根据历史经验，所有输入字段需要先行判断空字符串”。看到那条备注的时候，我确定这套东西是真的转起来了。那不是模型凭空聪明了，而是Moltbot在第一轮之后，在同类任务启动时检索到了那条经验，把它注入了执行上下文。

之后第三轮、第四轮任务越来越顺，Claude Code甚至开始区分不同错误码的返回场景。我基本从“盯屏幕改bug”变成了“早晚看一轮日志”。整套系统的效果就是标题里那句话：自动学习避坑。

4. 自动进化的加速技巧：让记忆库越长越准

前面是把系统跑起来，这一部分是怎么让它“进化”得又快又稳。很多人搭完记忆库就不管了，结果跑了一个月后经验库变成一锅粥：重复条目、过时条目、自相矛盾条目全混在一起，检索出来的东西越来越不靠谱。我有几个加速技巧，能让记忆库的质量随着运行次数增长，而不是跟着膨胀。

4.1 经验卡片的写法：给AI看的迷你病历

经验沉淀的质量，直接决定了系统能不能“越用越聪明”。我管经验条目叫“经验卡片”，因为它的结构更像病历：有症状、有诊断、有处方。一份合格的经验卡片长这样：

experience: scene: 开发新注册接口 symptom: 密码校验只判断了长度，空字符串被放过 cause: 初始规格里没有明确非空约束 solution: 所有输入统一trim后检查非空，再走长度校验 tags: [api, validation] confidence: 0.9

这里有三个容易写错的点。

**scene（场景）**要足够泛化，不能写成只对应一个任务的名字。如果场景写的是“用户注册接口”，那下次来个“登录接口”就匹配不上了；写成“开发新注册接口”或者更宽泛的“开发接口类任务”，才可能被召回。

**symptom（症状）**写的是现象，不要写情绪，也不要写猜测。例如“密码校验只判断了长度，空字符串被放过”是合格描述，“用户输入异常导致报错”这种就没法让AI落地下手。

**solution（解决方案）**必须是可以直接执行的改法。“注意校验”这种话，AI看完还是不知道怎么做。要像写处方一样，给具体的操作步骤，比如“统一trim后检查非空，再走长度校验”。

另外，**confidence（置信度）**字段很有用。它不参与检索，但参与排序和冲突消解。高分值经验在自动修复时会被优先采用。

4.2 检索质量怎么调：别让经验库变成噪音池

经验库建得越来越大的时候，检索质量会下降。我调检索参数只盯一个指标：无效命中率，也就是最近10次任务中，注入的经验真正被Claude Code参考并产生正向效果的比例。如果连续跑下来发现无效命中率低于三成，大概率是相似度阈值太低了，召回了一堆“看起来像但根本不适用”的经验。

参数调节的基本思路是：

• 相似度阈值低于0.6，开始出现明显噪音，建议提高。
• top_k超过10，上下文质量下降，建议降低。
• 同一标签下经验条数超过20条，考虑做去重合并，把高度相似的条目聚成一条“通用经验”。

还有一个容易被忽略的技巧：按阶段检索，而不是一次性全注入。规划阶段只注入流程模板，执行阶段再按动作类型注入经验卡片。规划阶段就丢一堆细节经验进去，Claude Code容易在设计方案时被带偏，把精力耗费在那些无关痛痒的细枝末节上。

4.3 用失败自动生成新经验：把坑自动变成教训

跑得足够多之后，会有一个很常见的场景：某个任务连续失败两三次，而且是同一个测试在挂。这时候最佳做法不是每次都先去修，而是先用失败日志让Moltbot自动生成一条经验草稿。等人工确认之后，这条草稿才会转入正式经验库。这个确认动作很关键。

为什么不能全自动入库？因为Agent自己总结的教训不一定对。我遇到过AI把一个偶尔出现的网络超时总结成“该接口永远需要重试”，这种错误经验一旦进库，后面所有调用都会受影响。所以我的做法是三层状态机：pending（草稿）→ reviewed（已审核）→ active（生效）。只有active状态的经验才会被检索，reviewed是人工确认过可以入库的，pending是待核实的草稿。

当同一个场景出现两条冲突经验时，我用的取舍原则很简单：

• 时间近的优先。
• 有验证记录、跑过测试的优先。
• 量化收益大的优先，比如修复某类问题的耗时可度量的那条，权重更高。

如果你也想给冲突经验打综合分，可以按这个公式来估算：score = 0.4 * confidence + 0.3 * recency + 0.3 * verification。recent代表更新程度，verification代表是否被验证过程背书过，confidence来自经验卡片里的置信度。谁分高用谁。

5. 常见问题与排查实录：那些自动循环里的暗坑

把自动进化系统搭起来并不难，难的是它长期稳定地跑下去不出幺蛾子。跑了一段时间之后，我遇到了一堆“单看代码完全合理，跑到第N轮就出事”的坑。挑几个有代表性的，给你做份排查速查表。

5.1 死循环：AI一直在修同一个bug

最典型的问题就是自动修复死循环。现象是：同一个测试反复失败，Claude Code每次都尝试修改，但每次改的都是同一个位置，改了又错，错了又改。我第一次遇到的时候没设max_retries，系统一口气重试了九次，调用额度全烧进去了，代码还被改得一团乱。

后来的解决方案分三步：

1. 强制设置max_retries = 3。达到上限立即停止，不继续重试。
2. 失败日志去重。同一个测试的失败签名如果连续出现两次，第三轮开始就不再盲目重试，而是先生成问题定位报告，让Claude Code只做分析不做修改。
3. 策略切换。普通模式是“失败就改”，高疑点模式是“先写分析报告再改”，两种模式切换由失败次数触发。分析报告通过人工或者规则检查后再动手。

核心教训是：自动修复循环的前提，是Agent真的知道自己在修什么。如果连问题定位都没做就反复动手，那不是自动修复，是自动添乱。

5.2 经验库被污染：错误经验比没经验更可怕

自动进化系统最隐蔽的风险是：好的经验在帮你避坑，坏的经验在给你挖坑。我见过一条经验写的是“该平台接口不稳定，任何请求都要重试”，入库之后，Claude Code在调用完全没有问题的本地测试接口时，也默认先报错再重试，白白拖长了执行时间。

这类问题的根源是经验质量管控不够。经验库就像一个共用wiki，如果人人都能写，最后肯定变成垃圾场，必须有编辑审校机制。我的做法有三条：

• 置信度门槛：低于0.7的经验不准进入active状态，先丢进pending等人工审核。
• 经验有效期：给经验条目加有效期，超过一定时间且连续没被命中的，自动降级为inactive。技术环境变化太快，三年前的“避坑指南”放在今天可能本身就是坑。
• 抽检机制：每隔一段时间人工翻阅一遍moltbot新生成的经验，顺手清理明显过时或重复的条目。

经验库是这套系统的核心资产，清理它应该像清理自己家冰箱一样勤快，不能只往里面塞东西。

5.3 上下文塞太多：越跑越慢的隐形杀手

经验注入不是越多越好。top_k设得过高之后，每次任务启动时，系统会把大量历史经验拼进上下文，Claude Code的响应速度肉眼可见地变慢，同时思考质量也下降。人看一堆无关资料会抓不住重点，模型也一样。

解决办法是控制注入数量和质量，而不是无脑涨top_k。我目前的策略是：

• 经验条目默认压成两行摘要，完整细节放在后台，需要时再展开。
• top_k从5往下调，先看效果再决定要不要恢复。
• 按阶段注入：规划阶段只给流程模板，执行阶段只给对应动作类型的经验，避免一次性堆砌。

另外可以给任务打一个“风险等级”，比如高风险任务才执行深度检索，低风险任务直接按模板执行。低风险任务本来就不容易踩坑，没必要给AI塞一大堆背景资料。

5.4 权限失控：零干预不等于零防护

零干预开发很容易让人忽略一个问题：如果验证环节本身出现误判，AI会不会去执行一些危险操作？我在模拟项目X上跑过几次之后，重新审视了AI的操作权限。它执行代码、改文件、跑脚本，这些能力如果不加限制，一旦进入异常循环就可能产生破坏。

我的做法是三层防护：

1. 最小权限：AI用户只能操作workspace目录，不能访问系统级别目录，更不能读不该读的密钥文件。
2. 危险操作白名单机制：删除类命令、强制覆盖远程分支、批量发送消息、生产环境配置变更，默认全部禁止。如有特殊需要，单独为该任务开白名单。
3. 人工审批节点：涉及生产环境的操作，无论自动验证有多少次成功，都必须停在人工审批这一环。

我第一次跑这套系统的时候，最担心的问题就是“AI会不会趁我不在把项目搞没”。后来发现，只要权限和重试上限都配好，它反而比人工连续作战更克制。因为人工盯久了会疲劳，AI的自动循环只要逻辑正确，是不会犯“手滑”这种错误的。

结尾：这一路实测下来的体会

按我在模拟项目X上的实测体会，这套自动进化系统的成败，不取决于模型能力，而取决于三件事：反馈回路是否完整、经验库是否干净、规格是否可验收。这也是为什么我建议第一轮一定要人工盯着，不是信不过AI，而是你需要在早期把高质量经验喂进去。第一条经验卡片的质量，决定了第二轮系统能不能真正避坑；第一条错误经验如果被当成真理入库，后面要花十倍的时间把它纠正回来。

最后再分享一个小技巧：刚开始搭的时候，先把所有参数往保守里调。max_retries往小里设，top_k往低里设，并发任务数老老实实设成1。跑通一个小的模拟项目，确认经验能沉淀、检索能命中、自动修复不会死循环，再逐步放开。这三个“上限”都设好，自动系统才能长期稳定跑下去。