make-loop

--- name: make-loop description: 把用户一句大白话的任务，改写成一个写得清清楚楚、能放心让 AI 自己跑的循环（loop）任务说明。结构是三段：目标（我要做什么）→ 过程（它要怎么做）→ 检查迭代（做完检查，再接着改）；里面写全五件事：目标是什么、每轮做什么、怎么检查、记录什么、什么时候停。自带这些经验：评审一次给全清单、开发一口气改完；评审用统一的尺子；定期让用户本人看前后对比；刹车写全但不乱停。用户不会写 loop，只要说「帮我变成 loop」「做成循环」「写个 loop」「让它自己一轮一轮改到好」「反复迭代直到没问题」「让它一直跑」，或者丢来一个任务加一句 /make-loop，就用这个技能。适用任何任务。它只负责把任务写成 loop，任务本身的专业知识由当时的对话和其他技能提供。 --- # make-loop：把任务变成一个好 loop 用户不会写 loop。他给你一个任务（可能就一句话），你把它改写成一份**完整、可直接执行的循环任务说明**。 一个循环就三段，每段里要写清楚的事细化开是五件： | 三段 | 五件事 | 一句话 | |---|---|---| | **目标**：我要做什么 | 1. 目标是什么 | 做成什么样算好，必须能检查 | | **过程**：它要怎么做 | 2. 每轮做什么 | 先做第一版，然后每轮固定几个动作 | | **检查迭代**：做完检查，再接着改 | 3. 怎么检查 · 4. 记录什么 · 5. 什么时候停 | 拿证据检查、留记录、有刹车 | ## 怎么做 1. **读任务，自己补全**。不要问用户选择题：缺的信息先从对话、项目文件、记忆里找，找不到就用合理默认值，并在说明里标「默认：……，要改告诉我」。只有一种情况要先问：缺了它就完全没法开工（比如不知道要改的是哪个项目）。 2. **先定两个开关**（从用户的话里判断，判断不了就用默认值）： - **用户在不在场**：用户说「我睡了」「一直跑」「别来烦我」，或者任务要跑很久，就是**无人值守**：卡住了先搁置、换别的做，只有截止、用户叫停、救不回来才停。用户说「卡住就问我」，或者任务短、风险高，就是**有人值守**：卡住就停下来问。默认按无人值守。 - **批量还是小步**：有评审的任务默认**批量**，即评审一次给全清单、开发一口气改完再评；只有每一步都有风险、必须逐步确认的任务才用小步。 3. **按 `references/template.md` 填写**三段五件事，逐条对照 `references/checklist.md` 自查：好 loop 必须有的东西一样都不能缺。 4. **交付**： - 把完整说明放在一个代码块里，方便用户一键复制到新对话。 - 如果任务在某个项目文件夹里，同时存一份到项目里（比如 `LOOP_BRIEF.md`），并且不提交到公开仓库。循环每轮开始前要先读它，因为对话被压缩后早期指令会丢。 - 代码块下面用三五行大白话说明：你补了哪些默认值、两个开关选了什么、最关键的刹车是什么。 5. **要不要现在就跑**：用户的话里有「跑」「执行」「直接做」「开始」，就在当前对话里按这份说明开始干；否则只交付说明，最后提一句「要我现在就在这里跑，说一声就行」。 6. **之后用户再补要求**：改说明文件本身，再告诉执行的那一方「说明文件第几节改了，去读」。不要只发零散消息：一条条补丁叠起来，执行方会理解成前后矛盾，或者被后一条覆盖前一条。 ## 写的时候必须守住的几条（最常见的坑） **目标** - **目标要能检查**：「更好看」「更好玩」「关卡科学」不算目标，要换成能检查的标准。比如「新手 3 分钟内通过第一关」「每段跳跃都跳得过去」「375px 宽度下没有横向滚动」。 - **查清真实的截止时间**，不要自己推算了事；截止前留一段只修问题、不开大改动的收尾时间。 - **估一下预算**：大概跑多少轮、会花多少额度。用户额度紧张时，写明降级方案（只修最严重的），或者交给云端会话（先存档、写交接说明）。 - **范围就是用户的原话**：用户说「参考」就只是参考，说改 A 就只改 A，不要替用户扩大范围。 **过程** - **「用」要真的用**：截图、录屏、数值、日志、实际操作走完的步骤。「实际试一遍」要真的操作（浏览器自动点、真的运行脚本），不是读代码推断。 - **问题分级，先清高级**：致命（用不了、崩溃、卡死）→ 体验（不好用、不顺、看不懂）→ 打磨（锦上添花）。 - **批量做、批量评**：评审一次给出全部问题和「每项再加 1 分要做什么」，开发一口气改完，中间只做最基本的检查（比如能构建），改完再评。不要改一处评一次，太慢。 - **连续干，别空等**：一轮做完直接接着下一轮，不要每轮结束再定时唤醒（每次至少白等 1 分钟）。只有等外部的东西（部署、生成任务、后台评审）时才用定时唤醒，另外留一个约 20 分钟的兜底唤醒。 - **工具要快**：比如截图别每张都重开浏览器、固定傻等几秒。慢工具会把每一轮都拖慢。 - **最后再发布**：做产品类任务，默认全程在本地做和评，弄好了再一次性发布；只有确定中途有人会看，才阶段性更新。 **检查** - **每一项「过」都要有证据**，只说「检查过了」不算。 - **从用户的角度验**：自动化脚本按代码去点，永远不会「找不到按钮」。凡是给人用的东西，要开一个全新子代理，只看屏幕上的提示去操作（盲测）。给用户看在线结果时，注意缓存（链接带随机参数）。 - **主观质量要有靠谱的独立评审**：好不好看、好不好玩、写得好不好，自己打分会放水，换个评审又会忽高忽低。所以要写清： - **统一的尺子**：每个分数代表什么水平，用真实的标杆举例。 - **定标卷**：一份固定不变的样本配一份标准分，评审先打它，再按差值校正当前分数。 - **多个评审取平均**，并且每次都是全新的子代理。 - **和上一个最好版本并排比**，看到底是变好还是变差。 - **一份清单给全**：所有问题、每项怎么加分、卡分的结构性原因。 - **只有严重问题才封顶**，否则任何大作品都能挑出小毛病，分数永远卡死。 - **不许和评审争分**，也不许换宽松的说法重评。 - **用户把关**：AI 评审会集体看走眼（分数不降，人一看「越改越丑」）。每隔几批，或者有大改动之后，把前后对比发给用户本人看，不用等回复，接着干。用户说不对，就停下相关改动，把几个版本摆出来让用户挑；挑中的定为**基准版本**，之后不许比它差。 **记录** - 写进文件，不只留在对话里：开工时的目标、默认值、截止时间、待办；每轮做了什么、证据在哪、分数；用户的新要求；停下时停在哪、还剩什么。 **停** - **刹车写全**，六种都要有：做完了、卡住了、没进展、来回摆、上限（轮数或截止时间）、用户说暂停。 - **按开关决定刹车是「停下」还是「绕过去」**（见上面第 2 步）。无人值守时，卡住就搁置换别的做；分数卡在一个区间不动，就换打法（比如做一次方向性的大改，在分支上做，和原版比，更好才合并）；来回摆就选评分高的那版定下来。 - **阶段性胜利不等于收工**：某个改版赢了、合并了、上线了，只要收工条件没满足，就接着跑。 - **「觉得做完了」不算收工**：想停之前，先把收工条件逐条对一遍，结果写进记录。 - **收尾要写清**：停掉循环、关测试服务、清临时文件、恢复测试数据、关掉为了长时间运行开的「不休眠」。 **红线** - 花钱和不可逆的事写进红线：付费接口、生图额度、删除、发布、对外发消息，默认先问用户或者禁止。 - 任何时候都留一个能用的版本。 - 汇报用中文大白话，只说结果。 ## 范例 `references/examples.md` 里有一个改写前后对照：抖音上的「双人横版闯关游戏」loop。

存档时间线

版本索引永久保留；内容副本只保留最新 1 份，更早版本仅留索引与哈希（存档时间线的证据链不会因此断裂）。

下载存档内容副本