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 收到一个任务时它应该依次执行Understand the requirements理解需求Design the approach设计方案Write the code编写代码Run basic verification运行基础验证构建、lint、单元测试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五条工作规则模板给出了五条工作规则每一条都对应一个具体的可靠性问题规则原文要点解决的问题1先读AGENTS.md和相关文档理解项目结构代理冷启动时对项目一无所知会凭猜测行事2改动前先说明你的计划Explain your plan before making changes让计划可被追踪、可被人类或 Checker 复核3写完代码后自己做基础验证确保至少能运行防止把编译都过不了的半成品交给 Checker4不知道就直说不知道不要编造Dont make things up对抗生成模型的自信幻觉倾向5每一步都记录进度Record progress at each step为外部状态External State提供持久化的进度数据其中第 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 / testsAreas youre unsure about不确定的地方供 Checker 重点审查注意最后一个交付物Areas youre 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。两者在设计上刻意形成镜像维度MakerChecker引言定位Focus on making it workFocus on finding problems — the stricter, the better核心动机实现功能、写代码找问题不说好话输出实现摘要 修改清单 基础验证逐条问题描述/位置/证据/严重级别 总体裁决验证深度基础验证build / lint / 单测完整验证npm test、lint 零错误、TS 类型检查、覆盖率心态要求不确定就直说找不到问题就是失职Checker 的输出要求比 Maker 严格得多每个问题必须包含Description描述、Where文件与行号、Evidence证据、SeverityCritical / Medium / Minor最后给出总体裁决Pass / Fail / Minor issues, acceptable。这种证据驱动的要求正是 Lecture 9 为什么代理过早宣告胜利 中独立评判者角色的具体化它杜绝了 Checker 用感觉差不多这种模糊话术放行不合格的实现。在 Lecture 13 的完整循环解剖 中两者在循环里的配合关系是ImplementerMaker写修复与测试 → VerifierChecker独立运行测试 lint 评审Verifier 判定 Fail → 进入重试队列换一种思路再交给 ImplementerVerifier 判定 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 角色的定位实践中要特别注意以下几点不要让 Maker 给自己做最终评判。Maker 的基础验证只是最低门槛最终裁决必须来自独立 Checker。这对应讲义中的Verification Debt验证债务循环跑得越快越容易用Looks fine代替confirmed correct而 Maker 提示词里的基础验证 移交 Checker 的强制流程正是对抗验证债务的第一道防线。Stop conditions 必须是机器可检查的。目标不能写成做得差不多就行而要写成 goal 模板中那样的可执行条件npm test全过、覆盖率 ≥ 80%、lint 零错误、npx tsc --noEmit通过。每一轮都必须写入外部状态。Maker 的每步记录进度如果只在会话内生效循环一重启就归零。要把它落到loop-state.md这类磁盘文件上。计划先行改动有据。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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Loop Engineering 中的 Maker Agent Prompt：为自动化循环设计实现者角色的完整指南
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 收到一个任务时它应该依次执行Understand the requirements理解需求Design the approach设计方案Write the code编写代码Run basic verification运行基础验证构建、lint、单元测试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五条工作规则模板给出了五条工作规则每一条都对应一个具体的可靠性问题规则原文要点解决的问题1先读AGENTS.md和相关文档理解项目结构代理冷启动时对项目一无所知会凭猜测行事2改动前先说明你的计划Explain your plan before making changes让计划可被追踪、可被人类或 Checker 复核3写完代码后自己做基础验证确保至少能运行防止把编译都过不了的半成品交给 Checker4不知道就直说不知道不要编造Dont make things up对抗生成模型的自信幻觉倾向5每一步都记录进度Record progress at each step为外部状态External State提供持久化的进度数据其中第 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 / testsAreas youre unsure about不确定的地方供 Checker 重点审查注意最后一个交付物Areas youre 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。两者在设计上刻意形成镜像维度MakerChecker引言定位Focus on making it workFocus on finding problems — the stricter, the better核心动机实现功能、写代码找问题不说好话输出实现摘要 修改清单 基础验证逐条问题描述/位置/证据/严重级别 总体裁决验证深度基础验证build / lint / 单测完整验证npm test、lint 零错误、TS 类型检查、覆盖率心态要求不确定就直说找不到问题就是失职Checker 的输出要求比 Maker 严格得多每个问题必须包含Description描述、Where文件与行号、Evidence证据、SeverityCritical / Medium / Minor最后给出总体裁决Pass / Fail / Minor issues, acceptable。这种证据驱动的要求正是 Lecture 9 为什么代理过早宣告胜利 中独立评判者角色的具体化它杜绝了 Checker 用感觉差不多这种模糊话术放行不合格的实现。在 Lecture 13 的完整循环解剖 中两者在循环里的配合关系是ImplementerMaker写修复与测试 → VerifierChecker独立运行测试 lint 评审Verifier 判定 Fail → 进入重试队列换一种思路再交给 ImplementerVerifier 判定 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 角色的定位实践中要特别注意以下几点不要让 Maker 给自己做最终评判。Maker 的基础验证只是最低门槛最终裁决必须来自独立 Checker。这对应讲义中的Verification Debt验证债务循环跑得越快越容易用Looks fine代替confirmed correct而 Maker 提示词里的基础验证 移交 Checker 的强制流程正是对抗验证债务的第一道防线。Stop conditions 必须是机器可检查的。目标不能写成做得差不多就行而要写成 goal 模板中那样的可执行条件npm test全过、覆盖率 ≥ 80%、lint 零错误、npx tsc --noEmit通过。每一轮都必须写入外部状态。Maker 的每步记录进度如果只在会话内生效循环一重启就归零。要把它落到loop-state.md这类磁盘文件上。计划先行改动有据。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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考