做AI应用这一年多我最大的感受是LLM像是一个能力很强但记性很差的实习生。你刚交代完需求聊了二十轮之后它就开始放飞自我要么忘了最初的约束要么在某个细节上反复纠结要么干脆编造一个你从来没提过的目标。为了解决这个问题我试过各种Prompt技巧、记忆压缩、长期存储方案最后兜兜转转还是回到了工程化的老路上把模糊的对话流固化成明确的规格说明书。这就是flow2spec这个项目的由来——它不是什么高深的研究成果而是一套我在实际AI Agent开发中反复打磨出来的构建方法核心就是让AI在每一轮对话里都清楚地知道自己正在为什么目标服务。这套思路对做AI Agent、AI测试开发、多AI协作或者单纯想让自己用AI干活时少操点心的人都挺有参考价值。它不是某个具体工具更像是一种工作流设计模式你可以在自己项目里快速落一套。1. 为什么需要flow2specAI Agent的“失忆症”1.1 任务漂移是当前AI应用最大的隐性成本先说一个场景。我让AI帮我分析某个技术领域的专利布局刚开始几轮还挺正常它分好了技术分支列好了主要申请人还画了趋势图。但聊到第三轮我让它“把重点放在竞争对手的授权专利上”它回复的时候依然正确执行了。可当对话轮次超过二十轮问题就来了。它开始把“已公开申请”和“已授权专利”混在一起统计后来干脆把分析范围从一个领域扩大到了三个领域最后生成的报告跟最初的需求已经对不上了。我把这类现象统称为任务漂移。它不是模型变笨了而是上下文结构出了问题。在长对话里最初的目标指令被大量中间内容稀释模型的注意力在局部语境里被过度牵引于是产出逐渐偏离原始需求。这个问题在实际工程里的表现非常隐蔽它不是当场报错而是做完之后你才发现结果不对这时候返工成本往往已经很高了。我把漂移分成了四类需求漂移、角色漂移、格式漂移、事实漂移。需求漂移是目标变了味道角色漂移是AI突然不再以你设定的身份回答格式漂移是输出结构逐渐偏离约定事实漂移则是它开始在没有依据的情况下编数据。四类漂移里需求漂移的危害最大因为它最不容易被察觉——AI每轮都答得有模有样但整体方向已经偏了。1.2 flow2spec的解决思路把对话变成工程契约发现这个问题之后我第一反应是加长上下文、用更好的记忆方案比如向量检索或者自动摘要。但这些方案都有各自的问题。向量检索只能找回“相关片段”并不能保证找回“目标本身”自动摘要压缩之后细节和约束条件往往第一个被丢。试了一圈我发现最有效的做法其实最朴素在任务开始前把用户模糊的意图转化成一份结构化的规格说明之后的每一轮对话都在这份规格的约束下运行。这就是flow2spec的核心逻辑——flow是用户最初那团“流动的、模糊的想法”spec是固化后的“可执行、可验证的规格”。这一步很像软件开发里先写接口文档再写代码的流程也像施工前先看图纸再动工。传统Prompt工程要求你精心写一段提示词但提示词是静态的它无法在长任务过程中持续校准方向。flow2spec则把“提示词”升级为“契约”这份契约在任务执行中被反复引用、比对、校验自然就能对抗漂移。我还发现这件事跟测试开发天然契合。spec里包含了验收标准而验收标准可以直接翻译成测试用例。换句话说flow2spec不只是让AI“记得”任务它让任务变成可测试的——这对AI应用的质量保障来说价值非常大。2. flow2spec的整体设计与工作流2.1 核心架构三阶段流水线这个项目的整体架构并不复杂一条流水线串起三个阶段。第一个阶段是意图捕获。这个阶段处理的是用户原始输入通常是一段口语化甚至有点混乱的描述中间夹杂着背景信息、情绪倾向和隐藏目标。我的做法是先让模型做一次“复述与追问”用几个问题把模糊点钉死比如“你这次分析的时间范围是什么”“最终交付物是报告还是表格”。在这个阶段不要急着生成spec先把信息缺口补上。第二个阶段是规格生成。捕获到完整意图之后让模型按照固定模板生成规格说明。模板是我反复迭代出来的包含目标定义、输入输出、约束条件、验收标准、潜在风险、任务拆解清单六个部分。其中验收标准是最关键的字段它必须写成“可判断的客观条件”而不是“高质量”“尽量详细”这类无法量化的形容词。第三个阶段是规格驱动执行。每一轮对话开始前先把spec中与当前子任务相关的部分提取出来和最近的对话历史一起注入模型。这一步是防漂移的关键——它让模型每轮都能“重新看到”自己正在做什么、边界在哪里、验收标准是什么。执行过程中task清单里的状态需要实时更新已完成的打勾、被阻塞的记录原因这样整个项目随时处于可追溯状态。2.2 规格说明的物理形态一份可机读、可人读的文档spec最终被保存为一份YAML自然语言混合格式的文档。选择YAML的原因有两个一是结构清晰便于程序解析状态二是它足够宽容不像JSON那样字段稍有缺失就报错。自然语言部分用来承载机器不好表达的约束和背景意图比如“语气保持中立不做任何投资建议”这类需求写进约束字段让模型理解但不用程序强校验。以专利分析场景为例一份简化spec大致长这样goal: 分析智能制造领域头部企业近三年授权专利布局 inputs: - 专利检索式: IPC分类号 企业名称列表 - 时间范围: 2022-01-01 至 2025-01-01 outputs: - 一份markdown格式的分析报告 - 附带excel格式的专利清单 constraints: - 仅统计授权专利不含公开申请 - 地域范围仅限中国 - 语气保持中立不做任何投资建议 acceptance: - 报告中每个企业至少覆盖top10技术分支 - 数据来源字段必须在表格中逐条列出 risks: - 专利数据库覆盖不全可能导致统计偏差 - 企业名称存在历史变更需合并关联主体 tasks: - id: t1 name: 数据检索与清洗 status: pending - id: t2 name: 技术分支分类 status: pending - id: t3 name: 报告生成 status: pending你看这份文档同时满足了两个目的人类工程师扫一眼就知道项目在做什么机器也能通过解析YAML字段来跟踪状态。更重要的是它变成了人和AI之间共同的“工作底稿”——需求变了就先改spec再让AI改执行路径而不是直接模糊地追加一句“这里改一下”。3. 实操手写一个最小可用的flow2spec3.1 最小闭环从一句话需求到第一份spec我这里用旅游规划这个例子来说因为它足够通用方便你套用到自己的场景里。用户输入只有一句话“帮我们三个朋友规划一个周末去杭州的行程现在预算每人三千左右。”这个输入里信息缺口很多哪几个周末、什么类型活动偏好、酒店档次要求、美食还是景点优先、是否包含高铁票、是否需要避人流之类。我的做法是让LLM先做一步spec化的预处理。这一步用非常简单的Prompt你是需求分析工程师请根据用户描述生成规格说明。 用户描述{用户原始输入} 请补齐缺失信息列出你的疑问并在用户确认后生成最终spec。实际操作时我会让模型把疑问列成选择题而不是开放填空题这样可以降低用户的反馈成本。比如“交通方式偏好A高铁 B自驾 C不包含交通”用户只需要回复一个字母。补齐两到三轮后再让模型生成结构化spec然后展示给用户确认。确认之后这份spec就算“生效”了后续所有执行都围绕它进行。3.2 规格驱动执行把spec注入后续每次调用生成spec只是第一步真正决定成败的是执行阶段的注入策略。最笨的办法是把整份spec每次都塞进上下文这样既浪费token又会让模型重新陷入信息过载。我的做法是给spec运行态做一个精简快照。执行循环大致是取出当前任务状态快照提取spec中与当前任务相关的目标片段和约束再加上最近几轮对话摘要三者拼接成一个“运行上下文”。快照不是逐字复制原spec而是让模型用一句话总结当前进度和下一步计划。比如快照可以写成“数据检索已完成共清洗1200条记录下一步进入技术分类”。这段话虽然短但包含了任务状态量、当前位置、下一步动作三个关键信息足够锚定模型方向。注入的模板我会按系统、用户消息分层放def build_execution_context(spec, snapshot, history): system_prompt f 你正在执行任务任务目标{spec[goal]} 约束条件{spec[constraints]} 当前状态{snapshot} 请以此状态为基准继续执行不得偏离目标。 return system_prompt history这个办法我用了很久效果稳定。它能有效对抗的恰恰是那种“聊着聊着就自己另起炉灶”的毛病——模型不是被禁止发散而是有明确的锚点让它随时回到主线。3.3 状态维护与手动兜底在整个流程里我还会维护一个简单的状态机。任务的每个task都有四个状态pending、in_progress、done、blocked。每轮对话结束后脚本会提示用户或者让模型自行判断是否需要更新状态。blocked状态特别有用因为当任务受阻比如数据源不可用模型容易“绕路”去编造数据。给它一个blocked标记它就会明确告诉你“此步被阻塞”然后和你讨论替代方案而不是自作主张。状态机在前期的重要性容易被低估但真正的长跑型任务——比如一份跨周的市场研究报告——如果没有状态跟踪模型经常把做了第一遍的结论和第二遍的重复工作混在一起。有了状态机每轮输出都会声明“这是基于哪一版数据”追溯和回滚就变得容易了。4. 落地过程中的坑与排查实录4.1 spec生成不稳定的五个典型失败模式这工具听着好用但严格来说并不是开箱即灵的第一次跑就翻车的情况很常见。我把踩过的坑总结成了五类如果你要自己写一份flow2spec工具建议优先做防御。第一个是过度抽象。让模型生成spec时它会倾向于把目标总结得非常“高大上”但这种表述往往信息量为零。比如把“列出杭州五日游可行景点”抽象成“全面探索杭州文化历史资源并形成优化路线”这句子看起来没问题但模型自己都识别不出具体要干什么。修复方法是规定goal字段必须包含可执行动作和明确对象抽象层禁止出现。第二个是约束漏项。模型天生只关注“做什么”很少主动思考“不做什么”。少了负向约束AI就会在每个岔路口自由发挥。后来我在规格模板里强制加入constraints字段并限制至少写三条负向约束用“禁止”开头。第三个是验收标准不可测。用户写“报告质量要高”模型就原样抄进spec。这是最大的坑——因为“质量高”没法判断AI自己更判断不了。我在项目里强制验收标准必须写成“包含X”“统计Y”“每项都有Z”这类可核对的表述。比如“每个企业至少覆盖top10技术分支”“数据来源字段逐条列出”这才叫标准。第四个是幻觉字段。模型在生成spec时会自作主张添加一些源需求里没有的内容比如我在旅游场景里根本没提“加入网红打卡点”模型却把这条写成了硬性约束。这很危险因为用户一旦没细读确认后续所有执行都基于这个错误的前提。我的防御办法是在spec生成之后加一步“用户确认差异标注”让模型把“根据用户原话的条目”和“模型补充的条目”分开展示。第五个是spec与实际意图偏差。问题常出在“用户自己都没想清楚”的情况里。模型生成的spec再详细也不是用户真正想要的。这一步没有技术解法只能靠前置追问来降低风险。我通常让模型在生成spec前强制提出三个问题用户必须答复后才能进入下一步。4.2 引入flow2spec后性能反而变差的场景任何一种工程方案都有它的适用边界flow2spec也不例外。我测试下来有三类场景不建议用这套方式一次性简单问答、创意发散类任务、高度依赖模型涌现能力的开放性探索。举个例子如果你只是问“Python里怎么把字典按value排序”用flow2spec纯属浪费。生成spec的token开销和延迟已经超过了直接回答的成本体验变差是必然的。创意发散类也一样比如“帮我想几个slogan”这类需求本身就不该有硬约束过早规格化反而限制了模型的可能性空间。怎么判断该不该用我给自己定了个经验阈值任务执行轮次超过五轮、涉及至少三个子任务、交付物有明确格式要求、任何一步出错都会导致后续连锁返工。命中两条以上才值得启动规格化。这样既避免了为简单需求的过度设计也在真正复杂任务里拿到了收益。4.3 把spec变成测试集结合AI测试开发的实践spec里的验收标准字段除了防漂移之外还有一个高阶用法转换成自动化测试用例。我试过把这个能力嫁接到现有测试流程里效果出乎意料地好。常规做法是完成spec后另开一条Prompt让模型针对每个acceptance字段生成5个“探针问题”。比如验收标准是“报告中每个企业至少覆盖top10技术分支”探针问题就能是“请列出报告中技术分支数量最少的那个企业并给出其分支覆盖数”。执行环节结束后让AI带着spec回答这些探针模型撒谎时答案往往会和spec矛盾这样就完成了对结果的自动校验。这个思路相当于给AI应用做了回归测试。每次调整prompt或换模型版本我都能拿同一套探针去对比新旧输出的质量差异这比人工读报告高效得多。如果你想做AI测试开发这一套逻辑几乎是现成可用的脚手架。5. 多AI协作与规模化的进阶玩法5.1 spec即契约多Agent协作中的统一语境当任务简单时一个AI就能搞定。但一旦任务复杂拆成多Agent分工协作新问题就来了每个Agent都在自己的上下文里干活彼此对需求的理解可能完全不同最后合并出来的东西东拼西凑。我试过让一个Agent负责数据检索、另一个Agent负责报告撰写、第三个Agent负责质量审查结果数据Agent基于“2021至2023年”的假设查数据报告Agent就按“近三年”写结论因为各自对同一个模糊说法的理解不同最终报告被质量审查Agent打回重写。flow2spec解决这个问题的方式很直接所有Agent共享同一份spec各自只读取与自己相关的子集视图。数据Agent读inputs和tasks里的t1报告Agent读outputs和tasks里的t2审查Agent读acceptance。它们不是各自理解需求而是按同一份契约执行不同分工。这跟微服务里大家依赖同一个接口定义做联调是一个道理——没有契约协作就是一团乱麻。5.2 把flow2spec用于AI编程提示词的工程化改造AI编程是另一个受益明显的方向。很多把Coding Agent用于重度开发的人都有这个体验你让Agent实现一个模块它写出来的代码单测能过但需求理解完全错误因为需求本身是模糊的。这时候你没法改代码你得先把“开发提示词”重构为“可执行规格”。我的习惯是先用flow2spec把需求转成spec草稿再交给Coding Agent作为开发约束运行前让Agent检查自己是否满足每条约束。这样做的最大好处是把“AI写的代码没有需求文档”这个尴尬局面扭转了过来。出一版代码后评审者可以先看它有没有偏离规格再看代码本身质量问题定位会快很多。5.3 利用spec沉淀领域知识面向未来的AI产品设计如果持续使用flow2spec你会发现spec本身会积累成一个有价值的“领域规格库”。同样类型的任务做多了之后新需求来临时可以检索历史spec中相似度最高的那份作为新任务的初始模板让模型在历史版本上修改而不是每次从零开始。这个习惯对我的工作效率提升很大尤其是经常做同一类分析工作的时候。跑了几十次之后我手里的spec模板已经收敛到接近“最优实践”新需求来了基本只需要调参数和边界完全不用重新走一遍需求澄清流程。对一个AI产品经理来说这份规格库就是最宝贵的业务资产——它就是AI应用需求配置结构的可复用底座。我在实际使用里还有一个体会flow2spec初期会带来约10%的额外token开销和延迟但这部分成本在任务超过十轮之后几乎全部从返工成本里赚回来了。与其在长任务里反复纠正跑偏的AI不如花一次性的五分钟把方向钉死。最后再分享一个小技巧执行阶段的快照不要用模型“硬总结”而是让它以“当前完成度历史教训”的双线方式记录比如“已完成A教训是B方法不可行下一步改走C途径”。这样的快照比简单状态更新信息量大得多对后续复杂任务尤其管用。
