企业官网建设流程全解析

Loop Engineering 中的 Maker Agent Prompt：为自动化循环设计实现者角色的完整指南

【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址: https://gitcode.com/gh_mirrors/le/learn-harness-engineering

导读：本文以 Maker Agent Prompt 为核心，讲解在 Loop Engineering（循环工程）中如何为"实现者"（Maker）这一子代理角色编写一份可复用、可验证的提示词模板。你会理解 Maker 与 Checker 为什么必须分离、Maker 的五步工作流程与四条工作规则的背后原理、它的标准交付物与输出格式，以及如何结合 goal 模板 与 循环状态模板 把它放进一个真正能自主运行的循环里。读完后，你将能独立为/goal、Codex 子代理或自建循环系统编写一份高质量的 Maker 提示词。

一、为什么循环里需要一个专门的 "Maker" 角色

在 Lecture 13：从手动提示到自主循环 中有一个贯穿全篇的核心论断：写代码的代理和检查代码的代理必须分离。讲义原文将其称为 "generator/evaluator separation"，并给出了一句值得记住的话："someone in your crew must not believe you"（你的团队里必须有人不信你）。

原因在于生成式模型的固有属性：一个模型既是自己输出的作者，又是它自己的"最佳辩护律师"。当它回头审视自己写的代码时，看到的是自己的推理过程，而不是错误。因此，"让写代码的人给自己的作业打分"这条路径从一开始就是不可信的——无论这个模型是 Claude、GPT 还是其他任何生成模型。

这正是 Maker Agent Prompt 存在的意义：它把"实现"这一职责从"评判"中剥离出来，让实现者只专注于一件事——把功能做出来（"making it work"），而把"找毛病"交给另一份独立的 Checker 提示词。在 同一目录下的 Checker Agent Prompt 中，这一分工被表达得更加直白：Checker 的职责是"找问题，而不是说好话"（find problems, not say nice things），"找不到问题就是你的失职"。

二、Maker Agent Prompt 逐段精读

Maker Agent Prompt 全文是一份不到 50 行的 Markdown 提示词模板，分为四大部分。下面逐段解读其设计意图与使用要点。

1. Your Role：定义"你是谁"

模板开头用引言（blockquote）点明定位：

For the implementation agent. Focus on "making it work."

随后是角色宣言："You are the Maker. Your job is to implement features and write code."（你是 Maker，你的工作是实现功能、编写代码。）

这是角色提示词最重要的一步：先给代理一个清晰的自我身份。角色声明越收敛，代理越不会越界去做评审、改需求或自行扩张范围——这正是 Lecture 7 "为什么代理会越界和虎头蛇尾" 所讨论问题的提示词层面的解法之一。

2. 五步任务流程：从理解需求到移交评审

当 Maker 收到一个任务时，它应该依次执行：

1. Understand the requirements（理解需求）
2. Design the approach（设计方案）
3. Write the code（编写代码）
4. Run basic verification（运行基础验证：构建、lint、单元测试）
5. Hand the result to the Checker for review（把结果移交给 Checker 评审）

这个流程有两个关键设计：

• 先理解、先设计，再动手。步骤 1-2 前置，是为了防止代理跳过思考直接改文件。这也与 goal 模板 中 "How to Work" 一节的要求一致：先读AGENTS.md和feature_list.json理解项目结构与既有功能，动手前先写出设计方案。
• 第 4 步是"基本验证"而非"完整验证"。Maker 只负责确认"至少能跑起来"（make sure it at least runs），深度的独立验证属于 Checker 的职责。如果 Maker 既实现又做完整验证，就回到了"自己给自己打分"的老路上。

3. Working Rules：五条工作规则

模板给出了五条工作规则，每一条都对应一个具体的可靠性问题：

其中第 4 条"不要编造"在长循环中尤其重要——一个自主运行的循环如果无法识别自己的知识边界，就会把幻觉当成事实写进代码和文档。第 5 条则直接呼应了 Lecture 5 "为什么长任务会失去连续性" 与讲义中六原语之一的External State：模型在每次运行之间会忘记一切，记忆必须落到磁盘上（markdown 文件、issue tracker、看板），而 Maker 逐步骤记录进度，正是为这份"循环的记忆"提供原始素材。

4. Deliverables：四类标准交付物

Maker 每次完成任务后必须产出：

• List of files modified（修改过的文件清单）
• Brief implementation summary（简明的实现摘要）
• Basic verification results（基础验证结果：build / lint / tests）
• Areas you're unsure about（不确定的地方，供 Checker 重点审查）

注意最后一个交付物："Areas you're unsure about"是这份模板最容易被忽略、却最有价值的一项。它让 Maker 主动暴露自己的不确定性，等于给 Checker 递了一张"重点怀疑清单"，把 Checker 的注意力引导到最可能出错的位置——这比让 Checker 从头到尾盲扫一遍高效得多。

5. Output Format：标准化的输出模板

Maker 的报告必须严格遵循以下格式，以方便 Checker、人类或下游脚本解析：

## Implementation Summary ... ## Modified Files - ... ## Basic Verification - Build: pass / fail - Lint: pass / fail - Unit tests: X passed, Y failed ## Known Issues and Risks - ...

标准化输出格式是循环工程的关键工程实践：当循环要连续运行数小时甚至数天时，只有机器可解析、结构稳定的输出，才能被 Checker 代理或循环控制逻辑稳定地消费。模板中Build: pass / fail、Unit tests: X passed, Y failed这类"填空式"表述，正是为了把模糊的叙述收敛为可验证的二元/数值结论。

三、Maker 与 Checker：一枚硬币的两面

要真正用好 Maker 提示词，必须同时理解它的对照物 Checker Agent Prompt。两者在设计上刻意形成镜像：

Checker 的输出要求比 Maker 严格得多：每个问题必须包含Description（描述）、Where（文件与行号）、Evidence（证据）、Severity（Critical / Medium / Minor），最后给出总体裁决（Pass / Fail / Minor issues, acceptable）。这种"证据驱动"的要求，正是 Lecture 9 "为什么代理过早宣告胜利" 中"独立评判者"角色的具体化：它杜绝了 Checker 用"感觉差不多"这种模糊话术放行不合格的实现。

在 Lecture 13 的完整循环解剖 中，两者在循环里的配合关系是：

• Implementer（Maker）写修复与测试 → Verifier（Checker）独立运行测试 + lint + 评审
• Verifier 判定 Fail → 进入重试队列，换一种思路再交给 Implementer
• Verifier 判定 Pass → 通过 Connector 打开 PR、关联 issue、更新进度文件

也就是说，Maker 和 Checker 之间的"失败-重试"回路，本身就是循环的发动机；没有这个分离，循环就没有可靠的质量闸门。

四、把 Maker 放进一个完整的循环

Maker 提示词不是孤立存在的，它需要与其他循环原语配合。在 Lecture 13 的六原语框架（Automations / Worktrees / Skills / Connectors / Sub-agents / External State）中，Maker 属于Sub-agents一环，并依赖其余五环：

• Automations（自动化触发）：定时器或事件把任务唤醒后，Maker 才会被调用。讲义中的例子：/loop 30m Run the test suite and fix any failing tests。
• Worktrees（工作树隔离）：当多个子代理并行时，每个 Maker 在独立的git worktree中工作，从物理上杜绝文件冲突。
• Skills（技能）：项目约定、构建步骤、历史教训以SKILL.md的形式固化，Maker 每次冷启动时无需重新解释项目上下文。
• Connectors（连接器）：基于 MCP 协议让循环触及 issue tracker、数据库、CI 等外部系统。
• External State（外部状态）：loop-state.md记录每轮进度，Maker 每轮结束后写入，下一轮开始时读取。

配套的两个模板与本主题直接相关：

• Goal Loop Template：把任务写成包含 Goal（目标）、Acceptance Criteria（可机器验证的验收标准）、Scope（含 Fair game / Hands off 边界）、Verification Method（按序执行npx tsc --noEmit→npm run lint→npm test→npx vitest --coverage）、Stop Conditions（验收全过 / 达 20 轮 / 连续 3 轮无进展 / 无法独立解决的阻塞）、How to Work 六部分的文档，再交给 Maker 或/goal。其中"Scope 明确什么不能碰"（如入口文件src/main.ts、数据库迁移、package.json依赖版本、CI/CD 配置）与 Maker 的"动手前先读 AGENTS.md"规则相互配合，共同约束代理不越界。
• Loop State Template：要求每个循环都有一个状态文件，每轮记录"Maker 做了什么、验证结果（Pass/Fail/Partial）、发现的问题、下轮计划、是否需要人工介入"，并在最后汇总 Rounds completed / Passed rounds / Failed rounds / Total issues found / Human interventions / Files changed 等累计指标。它把 Maker 的"每步记录进度"规则提升到了循环级别——这就是 External State 的具体形态。

在 Project 07：构建你的第一个自动化循环 中，Maker-Checker 循环被设计成三个递进实验的最后一个：先在p07-goal-loop分支把任务从手动运行改为/goal运行，再在p07-timer-loop分支把监控任务变成定时心跳，最后在p07-maker-checker分支写出三份提示词——Maker 指令（做什么、怎么做、什么不能碰）、Checker 指令（验证什么、怎么验证、什么算通过、如何给反馈）、循环控制逻辑（谁先执行、交接如何发生、如何启动下一轮），并至少运行 5 轮，逐轮记录"Maker 做了什么、Checker 发现了什么问题、通过与否、你是否干预"。

这个项目实验直接验证了本文主题：一份高质量的 Maker 提示词，是你能"从循环里走出来"的前提。只有当 Maker 的行为可预测、输出可解析、边界可约束时，你才敢把循环交给它自己跑。

五、验证基础：Maker 依赖的 harness 构件

Maker 的第一条工作规则是"先读AGENTS.md和相关文档"。在 projects 目录下（project-01 至 project-06 的 solution/starter 中）可以看到这套 harness 构件的真实形态：

• AGENTS.md：项目指令文件，定义启动路径、工作规则与完成标准（definition of done）。
• feature_list.json：功能清单，约束代理的作用范围，防止越界与虎头蛇尾。
• init.sh：环境初始化脚本，确保每次运行环境一致。
• claude-progress.md：进度记录文件，对应 Lecture 13 中"循环每天早上先读取昨天的 claude-progress.md"这一外部状态读写动作。
• session-handoff.md：会话交接文档，让下一轮可以从干净状态自动启动。

Maker 的"基础验证"（build / lint / 单元测试）在真实项目里通常对应package.json中配置的脚本。从 项目 06 的 package.json 与 goal 模板的验证方法可以看到，一个可用的验证命令链通常包括：TypeScript 类型检查（npx tsc --noEmit）、代码风格检查（npm run lint）、单元测试（npm test）、覆盖率（npx vitest --coverage）。Maker 至少要通过前几项"能跑起来"的门槛，再交棒给做完整验证的 Checker。

六、常见误区与最佳实践

结合 Lecture 13 的"四种隐性成本" 与 Maker 角色的定位，实践中要特别注意以下几点：

1. 不要让 Maker 给自己做最终评判。Maker 的"基础验证"只是最低门槛，最终裁决必须来自独立 Checker。这对应讲义中的Verification Debt（验证债务）：循环跑得越快，越容易用"Looks fine"代替"confirmed correct"，而 Maker 提示词里的基础验证 + 移交 Checker 的强制流程，正是对抗验证债务的第一道防线。

2. Stop conditions 必须是机器可检查的。目标不能写成"做得差不多就行"，而要写成 goal 模板中那样的可执行条件：npm test全过、覆盖率 ≥ 80%、lint 零错误、npx tsc --noEmit通过。

3. 每一轮都必须写入外部状态。Maker 的"每步记录进度"如果只在会话内生效，循环一重启就归零。要把它落到loop-state.md这类磁盘文件上。

4. 计划先行，改动有据。Maker 的"改动前先说明计划"规则，在循环里意味着每次实现尝试都应有明确的假设与理由——这正是 Karpathy autoresearch 这类"棘轮式"循环（只前进、不后退，失败即git reset回滚并记录）能持续产出可靠改进的原因。

七、总结

Maker Agent Prompt 表面上看只是一份不到 50 行的提示词，但它浓缩了循环工程中关于"可靠实现"的全部关键设计决策：

• 角色收敛：只做实现，不做评判；
• 流程固定：理解 → 设计 → 编码 → 基础验证 → 移交评审，五步缺一不可；
• 规则防幻觉：不确定就直说，不编造；
• 交付物可验证：文件清单、实现摘要、基础验证结果、不确定项，全部结构化输出；
• 输出可解析：标准化的报告模板，让 Checker 与循环控制逻辑能稳定消费。

当这份 Maker 提示词与 Checker 提示词、Goal 模板、循环状态模板 组合使用时，你就拥有了一个 maker/checker 分离、有记忆、可验证的自主循环的最小完备集。正如讲义所言："循环让生成几乎免费，而判断成为稀缺资源"——把生成交给结构良好的 Maker，把判断留给独立的 Checker 和你自己，这就是从手动提示走向循环工程的第一步。

【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址: https://gitcode.com/gh_mirrors/le/learn-harness-engineering