先问个扎心的问题：你给AI下过多少次那种“帮我写一篇……”的指令？

这话听起来特别正常，对吧？跟同事说“帮我优化一下”，他大概能猜到你在烦什么。但AI不一样。它会迅速给你一份看起来特别完整的东西——标题有了，结构有了，步骤也有了。可你读完之后，还是说不清它到底算不算完成了。

这是很多人在AI协作中忽略的第一道坎。你以为自己写了个“目标”（goal），其实只是写了一句“愿望”（wish）。

愿望可以很大、很顺、很有情绪。但Goal，必须能验收。结果出来以后，你得能说清楚：过了，还是没过？哪里没过？下一轮该改哪？

许愿的时候，你只需要说“我想要什么”。但写Goal的时候，你得先承认一个事实：你到底打算用什么来验收？

这个动作一旦被省掉，后面再谈什么prompt技巧、循环（loop）、状态（state）、智能体（agent），都会像是在一团雾里打转。方向都丢了。

先看看，如果你把这个关键认知补齐，效果能差多少。下面这个图是2天（2d）的成果。


愿望最会伪装成目标

来，看一个最常见的场景。多半你也经历过。

你打开AI，脑子里有个大方向：想做内容，想涨粉。你不想先写一堆规则，毕竟AI不就应该理解我吗？于是你敲下一句：“帮我写一篇能涨粉的文章。”

AI很快给你一篇。标题挺猛，开头挺顺，中间还分了三点。你读完感觉哪里不对，但又说不上来。让它改，它就把语气改“热”一点；再改，就多加几个案例。折腾三轮过后，你开始怀疑：“这AI不行啊。”

但问题可能真不在AI，问题就在你第一句话。

“帮我写一篇能涨粉的文章”，这句话里根本没有“验收口”。“涨粉”多少算涨？你的读者是谁？这篇文章要解决什么问题？你希望读者看完是收藏、转发、私信，还是点进某个课程页面？你不说，AI只能按照它见过的“平均文章”来补全。

而“平均文章”最大的问题在于，谁看都像，谁看都不动。

先把一句许愿改成可验收的Goal

第一个例子，写文章。

许愿句：

帮我写一篇爆款文章。

可验收Goal：

写一篇给“刚开始用AI做内容的人”看的公众号稿。读者读完，要能把自己的选题，从一句愿望改成一个可验收的目标。

正文至少包含3个改写案例，结尾给5行可直接复制的模板。

验收标准：读者可以直接复制模板，改出自己的下一条AI指令。

你看，第二段没有许诺“爆款”，反而更有机会被转发。因为它把“读者”、“问题”、“动作”和“交付物”都说清楚了。AI写完以后，你也能验收：没有3个案例，不过；结尾没有模板，不过；模板不能复制就用，不过。

记住这个判断：Goal是验收标准，不是施工图。它不需要把每一步都写死，而是把“成功的样子”写清楚。路径，留给后面的过程去跑。

第二个例子，规划副业。

许愿句：

帮我规划一个适合普通人的AI副业。

可验收Goal：

基于我每周可投入8小时、预算1000元以内、已有公众号和小红书账号的条件，给我设计一个30天副业验证计划。

目标不是马上赚钱，而是在30天内验证“一个可收费服务是否有人愿意咨询”。

交付物包括：目标用户画像、一个具体服务包、10条获客内容选题、第一周行动清单和放弃标准。

这段话里最关键的，不是什么“副业”，而是“30天”、“8小时”、“1000元”、“已有账号”、“咨询意愿”和“放弃标准”。很多副业规划最后变成鸡血文，就是因为没有“放弃标准”。AI会给你十条路，每条看起来都能做，你越看越兴奋，第二天却不知道先做哪个。

一个可验收的Goal，会逼你承认资源有限。你一周只有8小时，就别让AI给你设计一个像小公司一样的运营盘；你预算只有1000元，就别让AI推荐一堆投流打法；你要验证的是“咨询意愿”，就别先做一套完整的课程。

这不是把目标写小，而是把目标写到你“真的能动”。

第三个例子，做AI助手。

许愿句：

帮我做一个AI助手，能帮我提升效率。

可验收Goal：

做一个面向“公众号写作”的AI助手。

它每次接到选题后，先帮我输出：3个标题方向、1个读者痛点、1个反对意见和1个可验证的正文承诺。

暂时不要求自动写完整文章。验收标准是：我连续用5个选题测试，每次都能在10分钟内得到可用于开稿的判断材料。

这才是更健康的AI协作方式。人负责判断“这个助手该服务什么结果”，AI负责把中间的“动作”跑快。你不需要一上来就做一个“什么都能干”的超级助手，先让它稳定解决你最烦的一个小步骤，比如开稿前不知道从哪下手。能连续5个选题跑通，才说明这个助手有价值。跑不通，也知道哪里坏了——是标题方向太空，还是读者痛点太泛，还是反对意见不够尖。这比“提升效率”四个字清楚多了。

Goal放哪？别写成玄学

Goal写在哪里，确实会影响长任务里的稳定性。

更准确地说，在长上下文中，模型不一定能稳定利用所有位置的信息。相关研究（如《Lost in the Middle》）观察到，信息放在输入开头或结尾时，模型表现往往更好；放在中间时，更容易掉性能。所以，对普通人来说，一个很实用的建议就是：

别把Goal埋在几千字的聊天记录中间。每次让AI继续长任务时，先把当前Goal、验收标准和当前状态，重新摆到它眼前。你可以把它放在本轮消息的开头，也可以放在一段固定的摘要里。

比如下面这种自然语言式写法：

你是一个公众号写手。请帮我写一篇关于loop和goal搭配使用的文章，目标读者是AI工程师。文章要通俗易懂，要有案例，要有反常识点，结尾要给一个可执行的动作。字数2500字左右。

但更稳的写法，是把验收项拆出来：

{ "role":"公众号主笔", "goal":"写一篇让读者能跟做的loop和goal搭配指南", "audience":"刚开始把AI用于内容和项目的人", "acceptance":["读者能分清愿望和goal","至少3个可照抄案例","结尾有5行模板"], "loop":"每一轮检查是否服务同一个goal", "state":"记录当前进度、已删论据和下一步" }

这个改法不是为了显得“工程化”，而是为了“少猜”。Goal一旦成了独立字段，AI和人都更容易看见它。下一轮改稿时，你也不用重新解释半天，只要看这几个字段有没有变化。

没有Goal，Loop只是在换着方式猜

讲到这里，才轮到Loop。

Loop就是反复执行、检查、修正的一套动作。写文章时，它可以是“先出标题→再写开头→再检查案例→再补模板”。做副业时，它可以是“先找用户→再写服务包→再发内容→再看有没有人来问”。做AI助手时，它可以是“先跑5个选题→再记录失败→再改提示词”。

但Loop有一个前提：得有一个可验收的终点。没有Goal的Loop，只是让AI更勤快地跑偏。你让它改，它就改语气；你让它再具体点，它就加例子；你让它高级点，它就换一层更漂亮的词。一个任务跑到第六轮，AI开始偏离最初方向，很多人会说“AI忘了初心”。其实不一定是忘了，有时是你从来没有给它一个稳定、可读的“初心”。你把目标埋在最早那条消息里，后面一路追加资料、意见、吐槽、临时想法。到最后，AI只能从一堆碎片里猜“现在什么最重要”。它不是不努力，它是在努力猜错。

所以，Loop和Goal的关系可以概括成一句话：Goal管终点，Loop管每轮怎么靠近终点。Goal太糊，Loop会跑飞；Goal写得太死，Loop又没发挥空间。

更好的写法是：Goal精确到“成功的样子”，路径留给Loop。

反例：“写一篇2500字的文章，分5节，每节500字。”这个Goal看起来很具体，但它把“施工图”写死了，AI可能会凑出5节每节差不多长的PPT。

另一个反例：“写一篇好文章。”这个Goal太糊，AI只能去找“平均意义上”的好。

更好的写法：“写一篇让刚开始用AI做内容的人，看完想立刻把自己的一句许愿prompt改成可验收goal的文章。正文要有写文章、副业、AI助手3个改写案例。读者5分钟内能照着模板改出自己的下一条指令。” 这段话没规定每一节怎么写，但成功标准很清楚。AI可以自己组织路径，你也可以验收结果。

State不是上下文，是下一轮能接着跑的会议纪要

很多人把上下文和State混在一起，以为聊天记录越长，AI就越懂自己。这个误会挺要命。

上下文像会议录音，什么都在里面。State更像会议纪要，只记三类事：做到哪了？哪些坑别再犯？下一步改什么？

像LangGraph这类框架，其核心思想就是用于构建长期运行、有状态的智能体。你不用一上来就学框架，但方向值得记住：生产级的长任务不能只靠一串聊天记录硬撑，它需要知道失败后从哪里继续，人在哪里接手，哪些状态要跨轮保存。


放回普通人的场景，State可以非常简单。写文章时，State不是全文聊天记录，而是这几行：

{ "current_goal":"让读者把许愿句改成可验收goal", "accepted_cases":["写文章","副业规划","AI助手"], "removed_claims":["第30个词权重不到50%","80%场景用workflow"], "next_action":"把旧稿的自举prompt库改成小白能做的版本" }

副业验证时，State也不用复杂：

{ "current_goal":"30天内验证是否有人愿意咨询", "week":1, "done":["写出服务包","发出3条内容"], "signals":["1个人私信问价格"], "next_action":"继续发7条内容，不急着做课程" }

你看，这里面没有神秘的东西。State就是把下一轮最该知道的东西留下来，让下一轮不用从头猜。

Workflow和Agent，别搞反了

很多人一听AI助手，就想上Agent。好像只要叫Agent，任务就会自动变聪明。

事实上，Workflow和Agent是两码事。Workflow是“LLM和工具按预设路径被编排”；Agent是“LLM能动态决定流程和工具使用”。行业共识是：先找最简单可行的方案，只有需要时再增加复杂度，因为Agent系统通常会用更多的延迟和成本，来换取任务表现的提升。


用大白话说：

如果你的任务是每周生成同一类复盘、按固定模板整理客户反馈、每天把素材改成小红书标题，那你这更像Workflow。轨道清楚，Goal清楚，State字段也能固定。

如果你的任务是调研一个陌生行业、拆一个没有固定路径的项目、让AI自己决定先查资料还是先写代码，那才更像Agent。路径不确定，模型需要动态判断下一步。

多数人搞反了。对账这种固定任务做成Agent，结果到处乱跑；探索任务写成死流程，遇到新情况就卡住。判断方法很简单：先问自己，这个任务的路线能不能提前写下来？能写下来，先用Workflow；写不下来，每一步都需要根据新发现改路线，再考虑Agent。

这个选择背后还是同一件事：你必须先有Goal。没有Goal，Workflow只是机械重复，Agent只是自由乱跑。

这和当下很多“Agent平台”、“Agent工厂”的宏大叙事完全相反。简单总结：Workflow = 轨道列车，Goal写死，Loop写死，State固定字段，适合“每周给老板发报表”“按模板生成合同”。Agent = 自动驾驶，Goal模糊，Loop动态生成，State可演化，适合“调研陌生行业”“开放式探索”。下次接到任务，先问一句：这是轨道车还是无人车？想清楚再选。

Devin最值得学的，不是估值，是它的外层Loop

2026年5月的一则报道提到，Cognition以260亿美元估值融资超过10亿美元，并且其CEO称公司内部超过90%的代码由Devin完成。


对普通人更有启发的，不是其估值，而是它的“外层循环”（Outer Loop）。Devin写代码，团队再用这些结果改进Devin；改完的Devin继续写更多代码，再暴露更多问题，再反过来改自己。这个结构比单次写代码更重要。

你当然不需要复刻Cognition，也不可能今晚就搭一个Devin。但你可以有一个很小、人肉版的“外层循环”。每天睡前问自己一句：“今天我让AI干的活，哪些能让明天少干一点？”

如果今天你让AI写了3次类似的标题，那就把最有用的那次变成模板。如果今天它连续两次把读者写错了，就把“读者字段”加进你的固定Goal。如果今天它总忘记你不要“营销号口吻”，就把这个边界写进State。

这就是个人版的“自举”。不是AI突然变聪明，而是你把失败反馈喂回了下一轮。

手把手操作：30分钟搭一个“自举Prompt库”

理论说完了，下面给你一个今晚就能跑通的小循环。

场景：你每天让AI干很多杂活，但Prompt都是临时拍的。用下面这套方法，一周就能攒出一个属于自己的小型Prompt库。

准备：你电脑上已经装了Claude Code（其他类似工具也行）。

第1步：建一个State文件

在你的项目目录下新建`~/.ai_state/daily_review.json`：

{ "date":"2026-06-17", "today_done":[], "repeated_patterns":[], "new_prompts":[], "errors":[], "next_action":"" }

第2步：创建一个Hook，自动提取今日输入

Hook是我个人最常用的工具之一，作为硬性的自动化工具，它确实好用。这里以Claude Code为例，你只需把下面这段话复制给AI，让它帮你生成代码即可。其他平台的需要自行研究修改，AI会自己搞定的。

记得一个基础认知：采集不消耗token是边界。

// collect-today.mjs // 作用：扫今天的 Claude Code 日志，把你今天输入过的话提取出来，写进 daily_review.json import fs from"fs"; import path from"path"; import os from"os"; const STATE = path.join(os.homedir(), ".ai_state", "daily_review.json"); const ROOT = path.join(os.homedir(), ".claude", "projects"); const today = new Date(); today.setHours(0, 0, 0, 0); const inputs = []; (function walk(dir) { for (const e of fs.readdirSync(dir, { withFileTypes: true })) { const p = path.join(dir, e.name); if (e.isDirectory()) { walk(p); continue; } if (!e.name.endsWith(".jsonl")) continue; if (fs.statSync(p).mtime < today) continue; // 只看今天改过的日志 for (const line of fs.readFileSync(p, "utf8").split("\n").filter(Boolean)) { try { const o = JSON.parse(line); if (o.type === "user" && o.message && typeof o.message.content === "string") { const t = o.message.content.replace(/\s+/g, " ").trim(); if (t) inputs.push(t); } } catch {} } } })(ROOT); let state = {}; if (fs.existsSync(STATE)) try { state = JSON.parse(fs.readFileSync(STATE, "utf8")); } catch {} state.date = new Date().toISOString().slice(0, 10); state.today_done = inputs; fs.mkdirSync(path.dirname(STATE), { recursive: true }); fs.writeFileSync(STATE, JSON.stringify(state, null, 2)); console.log(`采集完成：${inputs.length} 条 → ${STATE}`);

第3步：复制下面这段Prompt给AI

同样以Claude Code举例，直接复制到对话框。

你是我的AI工作流复盘员。 日期：[今天] 我已经跑过采集脚本，今天我输入过的内容都在 ~/.ai_state/daily_review.json 的 today_done 字段里。请你： 1. 读取这个文件的 today_done，把里面同类的事情归在一起，只挑出今天出现 ≥ 2 次的类别。 2. 每个类别做成一个可复用的 prompt 模板，模板里必须有三部分：使用场景、输入示例、输出格式。 3. 把每个模板存成一个文件，放到 ~/.ai_state/prompts/ 目录下，文件名用英文短词，比如 bug-fix.md、refactor.md。 4. 把你挑出来的重复类别和新模板文件名，写回 daily_review.json 的 repeated_patterns 和 new_prompts 字段。 规则： - 只记录重复 ≥ 2 次的，只发生一次的事不记录。 - 如果今天没有任何重复的事，直接告诉我"今天没有重复任务"，不要编造。 - 如果 ~/.ai_state/prompts/ 目录不存在，先创建它。 做完后回复我：今天发现了哪几类重复、各出现了几次、生成了哪些模板文件。

第4步：每天晚上用一次

打开Claude Code，运行：

cc "读取 ~/.ai_state/daily_review.json，按里面的 prompt 复盘今天的事"

你会看到今天的重复内容。比如我测试时，跑出来的结果大概是这样：


跑完之后，你可以看到`today_done`字段被填满，`repeated_patterns`列出了今天重复的事，`~/.ai_state/prompts/`目录下多出了几个新文件。


然后，你就能得到一个优化后的Prompt版本。比如下图是我今天跑出来的三个：


第5步：周末合并Prompt

周末花20分钟：

把这周新生成的prompt文件过一遍 合并相似的（重复的合并成一个） 删掉用不到的 把高频prompt收录到 ~/.ai_state/INDEX.md

第6步：第二周看效果

坚持7天后，回到State文件看一眼：

1. `repeated_patterns`是不是越来越短了？说明AI帮你减少了重复。

2. `prompts/`目录下是不是攒了10个可用模板？说明Prompt库在自举。

3. 某天的`errors`字段是不是开始重复同一条？说明那个Prompt写得不对，要改。

这就是Loop × Goal合理搭配的真实样子：Goal是“攒一个自举的Prompt库”，Loop是“每天晚上复盘 → 周末合并”，State就是`daily_review.json`这个文件。三层到位之后，AI真的能越用越好用。

五个零件，够你先用

一个能用的Goal，通常有五个零件：

第一，使用者是谁。写给刚开始用AI做内容的人，和写给已经有团队的运营负责人，完全不是一篇文章。

第二，结果长什么样。不要只写“变好”、“提升”、“优化”，要写“交付什么东西”，“使用者能做出什么动作”，“项目能进入哪个状态”。

第三，验收标准是什么。数量、范围、边界、示例、测试方式都可以是标准。标准不一定复杂，但一定要能判断。

第四，约束是什么。时间、预算、平台、素材、能力、不要做什么，都要说清楚。约束不是限制AI发挥，是防止它替你幻想资源。

第五，下一轮怎么改。一个好的Goal不是只管第一稿，它应该能告诉你“结果不合格时往哪修”。

这五个零件放进去以后，AI反而更自由了。因为它不用猜你的真实意图，可以把所有力气用在生成、比较、整理和执行上。

小白最该避免的三个写法

第一，别写“写得好一点”、“专业一点”、“高级一点”。你自己都没定义什么叫“好”，AI只会拿平均审美糊你一层。

可以改成：保留原观点，把开头改得更像一个刚开始用AI做内容的人正在现场卡住的样子，前150字内出现一个具体的许愿句。

第二，别写“给我一个完整方案”。完整方案很容易变成“大而全”，读起来很满足，做起来没入口。

可以改成：先给我一个7天内能验证的最小方案，只包含每天一个动作、一个产出、一个失败判断。

第三，别写“你自由发挥”。自由发挥适合你已经有了审美、有了验收、有了边界的时候。刚开始用AI，先别这么潇洒。

可以改成：在不改变主线的前提下，给我3种表达路径，每种说明适合什么读者，最后推荐一个。

你会发现，这些改法没有让AI少做事，它们只是把AI从“猜心思”，拉回到“交付结果”。

真正的分工：人写Goal，AI跑过程

说实话，我是不太相信那种把任务全部扔给AI，然后等它自动给你一个完美结果的用法。听起来省事，实际很容易返工。特别是内容、项目、副业这种东西，里面有太多人的判断。

你要不要讨好流量？你愿不愿意露脸？你能不能持续30天？你到底想要粉丝、收入、作品集，还是只是想试试水？这些不是AI能替你决定的事。

更舒服的方式是：人先把Goal写成可验收结果，AI再帮你拆步骤、找材料、生成初稿、做检查。结果出来以后，人再验收。验收不过，回到Goal里看是哪一项没满足。

这时候，Loop才有意义——它不是让AI一直转，而是让AI每次都围着同一个可验收结果修。State也才有意义——它不是堆上下文，而是记住这一轮为什么改、改到了哪、哪些边界不能碰。

AI进入普通人工作的分工，其实很朴素：人别偷懒到只许愿，AI别越界到替人决定什么才算成功。

五行模板

最后，给你一个可以直接复制的五行模板。下次打开AI，先别写“帮我做一个什么”，先填这五行。

我要完成的可验收结果是： 这个结果服务的对象是： 交付物必须包含： 不做或不能越过的边界是： 我会用这几个标准验收：

如果你只能填出第一行，说明你现在还在许愿。没关系。能发现这一点，已经比直接让AI开干强很多了。

今晚先改一句就行。别急着搭系统，别急着喊Agent，也别急着整理100个Prompt。先把一句愿望，改成一个你真的能收货的Goal。

今晚睡前，把这段Prompt复制给AI：

“读取 ~/.ai_state/daily_review.json（如果不存在就帮我建一个），按里面的字段格式复盘今天。找出今天我重复做的事，告诉我。”

然后看AI的回答。如果它找到了≥2个重复的事……恭喜，你的外层Loop跑起来了。

我不懂代码，英语也不好，但靠AI确实做出过不少东西。我真心希望能影响更多的人来尝试这些新的技巧，去迎接这个新的时代。

谢谢你读到这里。如果觉得有启发，也欢迎给个星标，我们下一篇再见。