说实话我第一次听到 flow2spec 这个词是在一次多智能体项目的复盘会上。当时我们做了个 AI 编程助手能连续干活几个小时但最大的问题不是模型不够聪明而是聊着聊着AI 就忘了最开始那句话到底要它干什么。你问它刚才那个需求你还记得吗它记得你再让它按最初的方向继续它已经开始自作主张发挥想象力了。这种目标漂移几乎每个用 AI 干活超过半小时的人都遇到过。flow2spec 就是我针对这个问题梳理出来的一套很务实的思路——把用户脑子里那条流程flow持续转成 AI 随时能查、能对、能更新的规格说明spec让 AI 永远知道自己正在做什么、为什么做、做到哪一步了。这套方法不挑场景写代码、写文档、做数据分析、让 AI Agent 批量处理任务都能用上。如果你也被AI 聊着聊着就跑偏折腾过或者正在做多 Agent 协作、AI 工程化落地的实践这篇文章应该能给你一些直接能抄作业的抓手。1. 先聊聊 AI 为什么会聊到一半忘了要干什么1.1 我踩过最典型的一次目标漂移有一次我让一个 AI Agent 帮我整理项目里所有接口文档要求是只提取每个接口的入参、出参和错误码生成一张 Markdown 表格。前两轮它做得很好第三轮开始它主动贴心地帮我补充了接口的调用示例第四轮加上了鉴权说明第五轮甚至开始给我写优化建议。你说这是坏事吗内容本身没问题。但问题是我原本的目标是整理一份表格式文档而它产出的东西已经悄悄变成了一份包含建议的接口分析报告。当我要求它回到最初的格式时它又需要我把前面几轮的上下文重新喂一遍而且它还表现得很困惑你到底是要简洁的表还是要完整的分析我当时就在想AI 不是不聪明ChatGPT 级别以上的模型理解能力都很强。它的真正问题是整个对话过程中目标从来没有被显式地固化成某种可校验的东西。目标只存在于最开始的那条用户消息里而那条消息会随着对话轮次增长、上下文膨胀逐渐被淹没。1.2 目标漂移的三个根源我把目标漂移拆成三个根源这三个根源在 flow2spec 出现之前几乎是无解的理解了它们你才能真正知道 flow2spec 在治什么病。第一个根源是上下文窗口的竞争。模型的上下文容量是有限的当你的对话历史越来越长加上各种中间输出、错误修正、示例代码最开始的目标描述在 Token 里面占的比例就越来越小。你可以把注意力机制理解成一个会议室人越多最初说话那个人就越来越难被听见。很多长任务的漂移本质上不是模型变笨了而是初始目标在上下文里的优先级被稀释了。第二个根源是目标的隐性化。用户最初说的目标往往包含大量隐含信息比如整理接口文档其实隐含了只要接口层不要业务逻辑说明、表格格式为主不要散文、错误码要列全不要省略。这些隐含信息在最初那条消息里根本没有写出来AI 只能靠猜。而每次它猜的方向和你预期不一致你就会觉得它跑偏了。其实它从来不知道你的完整流程是什么它只是在你给的零散信息里做最大概率的推测。第三个根源是任务状态的不可见性。在多轮对话或 Agent 执行过程中到底哪些步骤已经完成、哪些还没做、哪些验收标准已经满足、哪些被忽略了这些执行状态完全没有被记录。AI 只能靠着对话历史勉强判断而且很多时候它的判断是错的。当前这一步做完了下一步该做什么它是临时推测出来的而不是从一个明确的计划列表里取出来的。这三座大山叠在一起长任务就变成了碰运气。我在多个 AI Agent 项目里调优的结论是光靠改提示词解决不了这个问题必须引入一份实时更新的规格文档作为外部记忆。这就是 flow2spec 的起点。2. flow2spec 到底做了什么把流程变成规格说明书2.1 Flow 和 Spec 怎么从一张意图链互相转化Flow 和 Spec 是一对映射关系我习惯把它们的转化过程叫意图链展开。先说 Flow。Flow 就是用户脑中的完整流程它是隐性的、松散的、有时甚至用户自己都没想清楚。举个例子用户说帮我做一个每周自动汇总周报的脚本这句话背后的 Flow 可能是这样的我希望有个工具能自动抓取各项目成员提交的周报内容按项目分类提取关键结论每周五下午自动生成一份汇总文档并且发到我的邮箱格式最好是 Markdown如果某个项目这周没提交要标红提醒。这一整条链条用户不会一次性说出来甚至很多环节用户自己都没意识到。但 AI 如果想一直知道我要做什么就必须把这条链条完整抽取出来。flow2spec 要求你把 Flow 中的关键节点一个一个问清楚、列出来这个过程其实也是帮用户把需求想清楚的过程。Spec 就是把这条 Flow 固化下来的结构化规格说明它不是用户消息的复述而是一份独立于对话历史的、可执行、可校验的任务契约。我常用的最小 Spec 结构包含六个字段goal一句话描述任务最终要达成的结果。scope明确做什么、不做什么这一步最核心防止 AI 自由发挥。input任务需要的输入数据来源或格式。steps固定的执行步骤每一步都有明确的输入输出。acceptance验收标准AI 判断自己做完没做完的依据。updates变更记录用户后续的每一次修改都追加在这里。Flow 和 Spec 的转化路径简单说就是先展开再固化先通过几次提问把用户脑中的隐含流程展开成完整链路然后再把这条链路拆成上述六个结构化的字段。一旦 Spec 被固化下来后续所有对话、所有 Agent 动作都以这份 Spec 为准而不是以某一条聊天消息为准。2.2 为什么规格比提示词靠得住我见过很多团队试图用写一份超长提示词来解决目标漂移效果都很差。因为提示词本质上还是一段文本它存在于上下文窗口中依然要和其他对话内容竞争注意力。而规格之所以靠得住是因为它做了三件提示词做不到的事。第一它把目标从对话流里剥离出来。对话历史是线性增长的越到后面旧消息离模型当前决策位置越远。而 Spec 是一个独立的、稳定的结构化对象你可以通过系统设计保证它在每次模型调用时都被放在最靠前的位置而且内容不会因为对话轮次增长而劣化。第二它允许 AI 主动自检。有了 acceptance 字段AI 每完成一个步骤都可以回头对照验收标准是不是满足了。它是按图施工而不是凭记忆施工。我在实际使用中AI 的输出质量会明显更稳定因为它完成每一步时会主动检查自己有没有偏离验收标准。第三它是可共享的外部记忆。AI 对话不共享历史但你完全可以共享一份 Spec 文件。多 Agent 协作时Agent A 做完自己的部分把结果更新到 Spec 的对应字段Agent B 读取这份 Spec就能无缝接着干。这比让 Agent B 重新读一遍聊天记录高效得多也准确得多。我自己在实践时有一个很朴素的类比没有 Spec 的 AI 协作就像你在做一个项目时所有人都靠口头传话消息传十轮以后版本早就歪了。有了 Spec相当于你把需求写成了 PRD 放在共享文档里所有人只认文档不认嘴。3. 一个完整案例让 AI 持续帮你做周报整理全程不跑偏3.1 先把 Flow 问清楚直接讲原理容易飘我拿一个真实跑通的案例来拆解。目标是一个很常见的场景让 AI 做一个每周自动汇总周报的小工具。用户最开始只说了一句话帮我整理一下每个项目的周报汇总成文档。 这句话信息量太少了如果直接把这句话丢给 AI 开干它一定会根据自己的经验脑补很多。所以 flow2spec 的第一步不是让 AI 开始动手而是先展开 Flow。我建议用一组固定的问题去追问我称它为Flow 五问周报的来源是什么钉钉群文件某个网盘邮件汇总的维度是按项目还是按人输出格式有偏好吗Markdown、Word、Excel多久跑一次还是手动触发有没有特殊处理规则比如某项目没提交怎么办、总结的时候要求侧重什么这个环节看起来像是在收集需求但实际上它是在把 AI 的隐形假设变成显性的 Flow 节点。用户说按项目汇总但他没说的可能是同一项目多个人分别提交周报时要合并成一段。这种东西如果你不问出来AI 就会随机猜测。3.2 生成并固化 SpecFlow 展开完以后下一步就是生成 Spec。这一步可以让 AI 自己把答案整理成结构化 JSON也可以手写。我倾向于让 AI 边问边生成最后人工确认一遍。确认过的 Spec 长这样{ flow_id: weekly-report-summarize, goal: 每周五 17:00 自动汇总各项目周报生成一份 Markdown 周报总览并发送到指定邮箱, scope: { do: [读取指定网盘路径下的周报文件, 按项目分组汇总, 提取每份周报中的关键结论, 生成 Markdown 汇总文档, 发送邮件], do_not: [不修改原始周报内容, 不补充未提交项目的信息, 不做跨周历史对比] }, input: { source: /shared-drive/weekly-reports/, file_types: [.md, .docx], email_receiver: team-leadexample.com }, steps: [ 扫描目录列出本周新增的周报文件, 按文件名前缀识别所属项目, 逐文件提取关键结论保留原作者的要点表达, 按项目分组将汇总结果写入 weekly-summary.md, 将生成的 Markdown 文件以邮件附件发送 ], acceptance: [ 每个有周报的项目在汇总文档中都有独立小节, 每份周报至少提炼出 1 条关键结论, 未提交周报的项目在文档中标记为本周未提交, 文档格式严格为 Markdown不含额外分析或建议 ], updates: [] }这份 JSON 看起来平平无奇但它的作用非常大。关键是它把做什么、不做什么、做完的标准是什么全部写死了。AI 后续执行时每一步都可以拿 acceptance 来对照不会自我发挥。3.3 AI 执行与主动自检Spec 固化之后就可以让 AI 按 spec 执行了。我建议的执行方式是每次调用模型前把这份 Spec 作为系统上下文优先注入然后告诉 AI按照 steps 逐项执行每完成一步检查自己是否满足 acceptance 中的对应条款全部满足后才算任务完成。这样做之后最大的变化是AI 会在执行过程中主动向你确认边界情况。比如它发现某个文件命名不规范无法判断项目归属时它会停下来问你而不是自作主张丢进其他分类里。这在没有 Spec 的裸对话里几乎不会发生因为 AI 没有必须严格遵守 scope这种规矩它只会顺着上下文里最近一段话的自然趋势走。再举一个生动的差异。没给 Spec 的时候AI 汇总完周报可能顺手加一句整体来看本周各项目进展良好这在无伤大雅但如果你拿它当正式输出这句话就会污染数据。有了 Spec 的 scope 里写了 do_not 是不补充未提交项目的信息、不做跨周对比AI 就会把整体来看这种话收住因为它知道自己是在按规格施工不是在陪聊。3.4 中间变更怎么同步真实的项目里用户中途改需求太常见了。flow2spec 对变更的处理也很直接不要在新消息里模糊地提把汇总格式改成表格而是同步更新 Spec 的对应字段把变更记录追加到 updates 里。举个例子用户跑完第一周后发现邮件标题里需要带上周日期而且网盘目录结构变了。那么我只需要修改 Spec 的 input 和 steps 字段然后追加一条更新记录2025年3月8日接收邮箱不变周报目录新增子目录 archive发送邮件时标题需要包含本周一日期。改完之后让 AI 重新执行一遍它会立刻按照新规格干活不会把改需求理解成新开一个聊天话题。这里有一个很重要的操作习惯变更要落在 spec 上而不是落在聊天里。因为聊天记录会忘而 spec 是每次执行时都会重新注入的。我在几个团队里推广这个习惯的时候不少人觉得麻烦。但你会发现一次变更花 30 秒更新 spec能省掉后面好几轮你理解错了 / 我不是这个意思 / 重新再来的拉扯长期来看非常划算。4. 多 Agent 协作和长时间任务里flow2spec 能发挥更大的价值4.1 多 Agent 协作的共享记忆单 Agent 场景里 flow2spec 已经很有用了但它的潜力大头其实在多 Agent 协作上。现在很多人做 AI 工程实践已经不再只靠单个大模型完成一个复杂任务而是拆分多个 AI Agent一个负责拆任务一个负责写代码一个负责测试一个负责写文档。这种架构下面临一个很现实的问题Agent 之间怎么交接上下文直接把聊天记录甩给下一个 Agent 显然不现实因为里面全是相互对话产生的噪音。而 flow2spec 的作用是指定唯一一份 Spec 作为整个协作链路的共享记忆任务拆解 Agent 读完用户需求后把结果写进 Spec代码 Agent 只读 Spec 里属于它的部分产出后更新到对应字段测试 Agent 继续读更新后的 Spec按 acceptance 逐条验证。我实际搭建过一套这样的协作流程跑起来的稳定度比原来的逐 Agent 传对话历史高非常多。关键就在于两个词唯一事实来源。整个系统里只有 Spec 是唯一事实来源任何 Agent 拿到的上下文都是从此展开的不存在我以为你知道了其实你不知道的情况。4.2 长时间任务中的上下文压缩长时间运行的任务比如 AI 连续跑几个小时的批量数据处理最大的威胁就是上下文窗口爆掉。flow2spec 天然适合做上下文压缩的骨架。思路是这样的执行过程中产生的细碎中间输出该丢弃就丢弃该写日志就写日志但是每一次模型调用都只保留三样东西——最新版 Spec、当前步的输入、当前步需要产出的结果。因为 Spec 已经把目标、步骤、验收标准全部固化了模型不需要依赖那些庞大又杂乱的历史对话来判断该做什么。它只需要看到我在哪一步以及这一步的标准是什么。我在一个每天定时跑的 Agent 服务里应用了这个模式任务跨度两周每天迭代一次基本没有再出现过目标漂移。靠的就是每次都从 Spec 重新拉起上下文而不是把所有中间结果都塞给模型。这也是 flow2spec 在长时间任务里最迷人的地方对话历史可以忘规格不能忘。模型只需记得一份极其精简、结构明确的规格就永远知道自己在干什么。4.3 和 AI 编程、AI 测试这些场景结合如果你做 AI 编程类应用flow2spec 更是直接命中了痛点。AI 写代码的时候经常写着写着就把最初的架构约束给忘了比如不要引入额外依赖保持接口兼容注释用英文这些约束在对话初期说得清清楚楚中途一次帮我看下某个函数的实现就把初始约束挤出了上下文焦点。把这些约束写进 Spec 的 scope 字段之后AI 每次生成代码前都会先对照一遍跑偏率肉眼可见下降。同样的道理也适用于 AI 测试开发你可以把测试覆盖路径mock 规则需要断言的关键指标作为 Spec 固化下来测试 Agent 每一轮生成用例时都以它为准。我自己在 AI 工程实践里一个核心体会就是模型这层负责能力而 flow2spec 这层负责方向感。能力的上限模型说了算但方向的稳定性取决于你有没有搭好外部记忆系统。很多团队抱怨模型不行其实不是模型不行是它根本没有一份可以信赖的任务规格在手里。使用场景没有 flow2spec 时的典型问题使用 flow2spec 之后单 Agent 长对话多轮之后目标漂移越改越偏每轮都对标 Spec输出稳定多 Agent 协作上下文交接丢信息各干各的共享唯一 Spec执行口径一致长时间批处理任务上下文窗口爆掉中途失忆压缩上下文用 Spec 重新拉齐AI 编程写着写着忘了架构约束scope 固化约束代码符合预期AI 测试开发测试用例越生成越散按 acceptance 逐项覆盖收敛度高5. 我实际使用中踩过的三个坑5.1 Spec 写得太满AI 反而抓不住主目标我第一次做 Spec 的时候恨不得把所有细节全塞进去包括输出文档里每个字怎么排版、邮件标题的每个字符格式、各种边界情况的处理方式。结果 AI 反而表现变差了因为它被几十条 acceptance 项淹没每做一步都要停下来思考我到底有没有满足第 17 条整体执行变得非常犹豫甚至出现前后矛盾。后来我总结的规律是Spec 里的 acceptance 三到七条是最佳区间只写真正影响任务成败的硬标准而不是把所有偏好都变成硬标准。排版细节这种写成 fixed rules 放在说明区就可以不要放进 acceptance。因为 acceptance 是决定是否完成的关卡关卡太多模型就会把大量注意力浪费在自检上反而丢了主目标。5.2 Flow 变了Spec 没跟着更新这个坑几乎每个刚开始用 flow2spec 的人都会踩。用户中途说了一句顺便把邮件也发给我一份你觉得这只是一个小修改于是继续往下走没去更新 Spec。结果后面几轮模型一会儿记得要发邮件一会儿又忘了因为它没有外部的规格支撑只能靠那个顺便的聊天消息的记忆去猜。我的经验是任何需求变更都要主动走一遍刷新 Spec流程哪怕只是加一个收件人。这不是申请制而是你自己花十秒钟改一下字段。如果你发现自己在对话里反复强调同一个变更那就说明 Spec 该更新了这就是一个很实用的信号。总之记住这句话聊天里出现的需求变更如果没有同步到 Spec等于没改。5.3 把 flow2spec 用在小任务上纯属过度设计这个坑和前面相反刚体会到 flow2spec 的好处之后我会忍不住什么都套。让 AI 帮我翻译一段话也要写个 Spec让 AI 生成一张图片也要 Spec结果文档比任务本身还大。这种过度设计不仅浪费时间而且在小任务上强行加规格化流程反而破坏了对话的自然顺畅感。我给自己的划分标准很简单一次性问答不需要 Spec涉及三步以上的执行、或者执行期间有可能被反复打断和调整的任务才值得用 flow2spec。写一个小场面比喻就是你去买杯咖啡不需要签合同但是你要是请装修队给整屋装修改造那就得有一份明确的设计图纸和验收单。所以flow2spec 本质上是任务的图纸验收单你要判断的是这个任务配不配得上这张图纸。从训练出第一个完整流程到现在把它沉淀成团队内部的标准实践我对 flow2spec 的感受越来越像一句话AI 的能力决定了它能不能把事情做好而规格系统决定了它会不会始终朝着同一件事往前做。后者看起来不如模型能力性感但真正在工程场景里拼刺刀的时候拼的就是这个。如果你也被目标漂移困扰了很久我建议你从手头最常做的那类任务开始写一份最小规格试试坚持一两周你可能会重新审视AI 到底该配什么样的指导系统。