企业官网建设流程全解析

终极指南：HumanLayer Skills design-control-loop 的 8 阶段工作流详解

【免费下载链接】skills项目地址: https://gitcode.com/GitHub_Trending/skills53/skills

skills是 HumanLayer 开源的 Claude Code 技能（Skills）合集，其中的design-control-loop是一个"智能体控制回路设计"技能：它会像顾问一样访谈你，然后针对你的代码库量身定制并构建一个智能体控制回路（传感器、控制器、执行器），让代码库按节奏、以小步可审查的改动逼近目标状态。本文将完整拆解它的 8 阶段工作流，帮助你快速上手这套 AI 自动化方法论。

design-control-loop 是什么？为什么值得用

想象你的代码库是一个不断被"扰动"的动态系统：队友提交、依赖升级、生成代码……传统做法是一次性大重构，而 design-control-loop 借鉴控制理论，把目标拆解为持续逼近的过程 🎯：

• 设定点（Set point）：期望的终态，如"覆盖率 ≥ 80%"或"某模式下不再出现旧写法"
• 传感器（Sensor）：测量当前状态与目标的差距（lint 工具、类型检查、AST 搜索、测试套件等）
• 控制器（Controller）：从测量结果中挑选下一个"小而低风险"的改动
• 执行器（Actuator）：编码智能体（Claude Code、Codex、OpenCode 等）应用改动并自动开 PR
• 扰动（Disturbance）：回路外改变系统的一切因素，回路必须"顶着扰动"持续进步

它不是一套固定模板，而是带着访谈式提问，基于你仓库的现有工具栈讨论权衡、共同设计、最后落地实现的完整流程。核心理念可参见 SKILL.md。

一键安装与启动

在项目根目录执行：

npx skills add humanlayer/skills --skill design-control-loop

然后在 Claude Code 中输入/design-control-loop即可启动访谈流程。技能入口定义见 SKILL.md。

8 阶段工作流详解

整个技能被划分为 A～H 八个阶段，每阶段都先读取对应的参考资料文件，确保设计有据可依。

阶段 A：先读代码库，再开口提问

技能会带着提案而非空白表格来访谈你。它会先扫描：

• 现有 CI 配置（.github/workflows/*.yml等）
• 包管理器文件（package.json、go.mod、Cargo.toml……）
• 已有的类型检查 / lint / 测试 / 格式化命令
• 已有的.claude/skills或.agents/skills约定

完成标准：能准确说出项目的包管理器、安装命令、验证命令和 CI 平台。

阶段 B：与你共同设计控制回路

这是核心访谈环节，围绕五个组件逐项讨论并记录决策：

1. 设定点：驱动什么属性、目标是什么，并明确作用范围（哪些目录可改、哪些只读）
2. 传感器：如何可重复地测量差距，讨论稳定性、成本与可重复性
3. 控制器：如何从测量结果中挑选增量——可以是纯脚本，也可以是智能体决策
4. 执行器：选择哪个 CLI 编码智能体、需要什么凭证、遵循哪些"黄金模式"
5. 扰动 + 阻尼器：识别外部变化，并可选地提供一个防回退门禁（比如 PR 检查，防止问题在回路改善期间恶化）

设计概念体系完整阐述于 control-loop-taxonomy.md，还有一个真实生产环境的完整示例 example-control-loop.md（React Doctor 案例，仅供启发而非照抄）。

阶段 C：编写执行器技能

产出一个仓库本地技能（如.claude/skills/migrate-foo/SKILL.md），把智能体的"判断力"固化下来：

• 用带可检查完成标准的步骤描述行为，长模板放进同级参考文件
• 编码阶段 B 发现的"黄金模式"，让智能体遵循既有约定
• 每条规则只保留单一事实来源，避免在技能、提示词、记忆文件中重复
• 附带响应模板，定义智能体最终输出格式（即 PR 正文）

骨架与示例见 skill-template.md 和 example-skill.md。

阶段 D：让每个组件先本地可运行

在写任何 CI 之前，传感器、控制器、执行器必须各自独立跑通：

• 单独运行传感器，确认输出稳定可用
• 用真实传感器输出跑控制器，确认选择合理
• 在控制器选中的目标上本地运行执行器，确认改动通过验证

这条原则保证回路始终可调试，CI 工作流只是"薄编排层"。

阶段 E：把回路接入 CI

将组件组装为周期性任务（默认 GitHub Actions，也可以用仓库现有的 CI）：

• 按传感器 → 控制器 → 执行器的离散步骤运行，再用智能体最后一条消息作为 PR 正文开 PR
• 若组件实际是融合的（比如一个工具同时做了传感与控制），就合并为一步，不制造虚假分离
• 根据任务风险与审查负担决定节奏（每天、每工作日、每周……）
• 把记忆文件注入执行器上下文

基础骨架见 workflow-template.yml，嵌入提示词结构见 prompt-template.md，各智能体（Claude Code、Codex、OpenCode、CodeLayer）的无头命令与响应提取方式见 agent-runner-templates.md。

阶段 F：让人保持在回路上

计划任务必然漂移，需要两条"转向"通道，且都要改变未来的行为而非仅当前 PR：

• 记忆/反馈文件：版本化的 Markdown（如.github/agent-memory/<任务>.md），每次运行都确定性地加载进上下文。好内容是长期范围排除、已知误报区、评审者偏好——不是一次性指令
• PR 上的/iterate：维护者在 PR 评论/iterate，对应工作流加载 PR 上下文与反馈，智能体更新记忆文件和 PR 本体。辅助脚本 agent-iteration.ts 提供footer（PR 正文标记）与prompt（迭代提示词构建）两种模式

记忆文件骨架见 memory-template.md。

阶段 G：流量控制，防止 PR 堆积

推荐默认：每个回路最多一个开放 PR。定时运行时检查工作流标签下是否已有开放 PR，有则直接 no-op；手动workflow_dispatch可绕过该检查。没有这一步，每日循环会在无人审查时堆满重复、互相冲突的 PR。

阶段 H：验证、试运行、再加速

• 验证：用bunx js-yaml、Python 或yq校验工作流 YAML，确认技能、工作流、记忆文件引用的每个路径都存在
• 试运行：工作流必须先跑过一次才能被手动触发——临时加push触发器、推送、观察运行，再移除
• 加速：等回路产出稳定高质量后，可提高调度频率、扩大控制器批处理量、单次运行多轮"感-控-动"循环，甚至每个 PR 分配给不同队友

关键文件速查表

总结：把"AI 定时跑"变成可观测的工程系统

design-control-loop 的价值不在于某个具体工具，而在于它把"智能体偶尔跑一下"升级为一个可观测、有边界、可审查的控制系统：本地先跑通、CI 只做编排、人类通过记忆文件和/iterate持续调参。遵循这套 8 阶段工作流，你得到的不只是一个定时任务，而是一个会越跑越准的代码改进引擎 ⚙️。

【免费下载链接】skills项目地址: https://gitcode.com/GitHub_Trending/skills53/skills