需求返工是每个做过项目的人都心有余悸的事尤其是那种需求方只丢过来一句“我要做个类似的系统”开发排期已经倒排结果做到一半发现方向错了产品、研发、测试一起返工谁都不好受。我之前也长期被这个问题折磨直到有一天我把一套提问流程沉淀成了可复用的Skill让它在方案阶段先把人“问透”返工情况才真正好转。这篇文章就是把我这套做法完整拆开讲清楚Skill怎么设计、怎么配置、怎么跑进真实工作流不只给结论也把踩过的坑一起说了。1. 需求返工的根源动手前缺一轮“反向追问”1.1 “需求”其实分三层大多数人只接了第一层做过几年产品或者项目管理的人应该都有这种感觉需求方说出来的话往往不是真实需求只是他脑子里临时找的一个表达方式。我第一次意识到这个问题是在一个内部报表系统项目里。需求方说“我要一个数据大屏”开发团队真的就去做大屏了屏幕、图表、实时刷新全部搞定结果对方看完很失望“我要的不是一块屏幕我是想知道昨天订单为什么跌了10%。”那一刻所有人沉默了屏是能做但跌的原因分析完全不在方案里。后来我把“需求”拆成三个层次来理解口头表达层需求方直接说出来的那句话比如“做一个大屏”“支持导入”“最好能一键生成”。字面规则层这句话落到文档里能写成具体功能描述比如“页面必须有12个图表”“数据每天凌晨同步一次”。真实问题层需求方真正想解决的业务痛点比如“管理层每天要花两小时开会对数我想让指标异常一眼可见”。大部分需求文档只写到了第二层甚至只写了第一层。方案评审时大家讨论的也是字段、按钮、页面这些表象真实问题层从来没被单独拎出来问过。返工就是从这里埋下的表象理解得再透彻底层问题只要偏一点整个方案都是错的。1.2 返工的真实成本比你以为的大得多很多人对返工的理解还是“开发改代码多花几天”。实际在方案阶段漏掉一个关键约束到了开发阶段根本不是改代码这么简单。我见过一个在技术方案里没有确认数据量的项目按照每天几万条数据设计结果上线第一个月就跑到千万级数据库表结构、查询接口、缓存策略全要推倒重来测试用例也跟着全部重写。返工有个特点时间越靠后修复成本越呈现指数级增长。方案阶段发现一个问题改的是几行文档设计阶段发现问题改的是架构图代码阶段发现问题改的是模块上线之后发现问题改的是用户信任。所以很多人问为什么项目老是延期原因不在开发速度而是大多数时间都花在“做出来的东西不是对方要的”上面。1.3 Skill在这里扮演的角色把资深分析师的提问经验固化成资产我最初意识到“要留出更多时间提问”是受一位老产品总监的启发。他接手任何项目第一周什么设计都不做就是开会问问题问得需求方有时候都烦了。但他的项目很少返工因为他把业务里的边界、冲突、异常情况全在脑子里过了一遍。问题在于这种能力高度依赖个人经验团队里不是每个人都有他那种问题库。后来AI Agent和Skill的概念流行起来我才想到能不能把他的提问框架拆出来做成一个可以复用的配置让任何项目在开始前都自动跑一轮“灵魂拷问”这就是我标题里说的“用这个Skill先把方案问透”的来历。这里说的Skill不是一句简单的提示词而是一整套包含角色定义、提问流程、输出模板、触发条件在内的可配置文件。你可以把它挂在Claude这类Agent环境里也可以接到n8n这类工作流工具中还可以单纯当成一份团队 SOP 文档来用。本质上是把“问透方案”这件看起来很玄的事情变成一套确定性很强的执行流程。2. 一个“方案问透Skill”的构成四个追问引擎2.1 引擎一目标与背景先确认“为什么现在要做”我设计的Skill第一轮问题全部围绕“目标和背景”展开这一轮的核心任务是逼着需求方把动机说清楚。很多人一上来就聊功能其实功能讨论得越细致越容易忽略“这件事到底为了达成什么效果”。这一轮我会让Skill固定问几个问题这次业务希望改变什么现状这个问题是从什么时候开始出现的如果不做这个方案一个月后会怎样谁是这个需求的最终受益者他会怎么感受到变化你拿什么指标判断这件事做成了这些问题看起来简单实际效果却很明显。有个做仓储系统的需求方一开始说“我要上自动化分拣”被Skill追问之后才承认真正的问题不是分拣慢而是仓库晚上经常找不到临时工次日发货经常延误。如果是这样方案的方向完全不一样可能先做任务排班系统甚至考虑和第三方劳务平台打通比一上来上昂贵分拣线实际得多。2.2 引擎二干系人与边界划清“谁做、谁看、谁说了算”需求返工还有一个高频原因需求方自己都没搞清楚决策链。经常是产品经理和开发对完方案需求方回去问领导领导说“方向不对”然后又推倒重来。所以一个合格的问透Skill必须有专门一轮问题处理干系人。这轮问题包括谁使用这个系统谁只是偶尔看一眼报表谁能拍板接受最终方案数据由哪个部门提供质量谁来负责系统出现问题的时候谁来处理用户投诉这个系统需要和哪些现有系统对接对接边界在哪里有一次我接一个企业级n8n部署方案需求方反复强调要“高可用、能扛住流量高峰”但问到“谁运维”时对方沉默了。他们公司没有专职运维整个技术团队都是业务系统开发出身。沿着这个问题追下去方案从自建三节点集群改成了云上托管加自动化备份因为没有人值班的情况下复杂架构只意味着半夜出故障时没人能处理。这就是干系人问题的价值它能把方案拉回现实。2.3 引擎三场景细化用遍历代替“应该没问题吧”场景问题是最容易被忽略的。很多需求文档只描述了“正常情况下用户怎么做”对异常情况只写一句“系统应进行错误提示”这等于什么都没写。我设计的Skill在第三轮会专门遍历各种场景包括正常流程、边界条件和异常情况。流程本身不复杂可以写成一套分支追问正常流程走通是什么样从哪一步开始到哪一步结束最频繁的操作是什么一个熟练用户一天操作几次哪些操作可以失败失败后用户应该看到什么哪些数据一定不能丢丢了多少分钟之内能接受多人同时操作同一个数据时会发生什么做“共享单车租赁需求预估”这个场景时需求初始版本非常简单只说“预测一下每个站点的用车需求方便调度”。如果只问功能需求方案就是一个时间序列模型加一张热力图。但Skill的第三轮追问多问了几个场景问题“下雨天数据要不要区分”“演唱会散场时单量暴涨怎么处理”“新站点没有历史数据怎么办”这几个问题直接把需求从“预测平均值”拉到了“预测分位数并适配突发场景”方案的复杂度、数据需求、算法选型全都变了。这就是场景遍历的价值——不是制造麻烦而是提前发现麻烦。2.4 引擎四验收标准把“差不多”逼成“可测试”最后一个引擎是验收标准这在很多需求文档里是空白。没有验收标准需求方验收的时候就可以凭感觉说“这个不太对”开发和产品只能被动接受。我让Skill在这一轮输出的是一组可测试的验收断言格式固定如下当用户执行操作A时系统应返回结果B在C毫秒/秒以内。数据源更新频率为D时系统最迟在E时间后完成同步。在用户数达到F的并发条件下系统核心接口错误率不超过G%。不支持的操作H系统应给出提示I而不得静默失败。把验收标准写清楚之后返工概率会大幅下降因为双方对“完成”的定义终于达成了共识。需求方再说“我觉得不太行”的时候你可以翻开文档问“哪条验收断言没满足”这不是抬杠这是在维护方案契约。3. 从零配置把Skill落到AI工具链里3.1 先把角色、目标和记忆文件定义好Skill落地第一步不是急着写问题列表而是先定义清楚它“是什么角色”。我习惯在Skill配置里写这样一段name: requirement-clarify-master description: 在项目启动前通过多轮提问澄清业务需求输出可验收的需求规格。 role: 资深业务分析师与项目顾问 behavior: - 不直接给方案而是通过提问启发需求方思考 - 每轮最多提6个问题按优先级排序 - 对模糊描述主动要求举例 - 捕捉到冲突后要求需求方做出唯一选择 output: - 需求澄清记录 - 需求规格说明书初稿 - 待确认问题清单这段配置别看简单它解决了两个常见问题。第一它约束了Skill“不要直接给方案”这一点极其重要否则AI会抢答直接给出一个听起来很美但实际上漏洞百出的方案反而掩盖了真实需求。第二它限制了每轮问题数量防止一上来生成四十个问题把需求方吓跑。记忆文件也是需要的。我一般会给Skill准备一个单独的知识库文档里面放三样东西历史项目中学到的典型需求坑、公司常用的业务流程术语、必须符合的数据安全规范。这样Skill提问时会自带“领域经验”而不是问一些通用但没用的问题。3.2 提问清单不是堆问题而是要分轮收敛踩过一次坑之后我强烈建议不要把提问清单做成一个平铺的大表格那样Skill运行时容易一次性全部抛出来。正确做法是分四轮每轮有明确目标下一轮基于上一轮的回答继续追问。我目前使用的Skill配置逻辑如下第一轮目标与背景输出“目标清单”和“成功指标”。第二轮干系人与边界输出“干系人地图”和“系统边界列表”。第三轮场景细化输出“正常流程列表”“异常场景列表”“边界条件列表”。第四轮验收标准输出“验收断言表”。每一轮的问题字段我会在Skill里用列表结构存好类似这样rounds: - name: 目标与背景 questions: - 这次业务希望改善的核心指标是什么 - 当前流程中最让用户头疼的环节是哪一个 - 如果资源有限哪个目标可以先放弃 next_round: 干系人与边界为什么要分轮而不是一次性问完因为人的注意力是有限的。需求方花十分钟回答问题的时候质量最高超过二十分钟就开始敷衍地回答“这个你看着办”。把问题切分成几轮中间夹着AI对上一轮回答的整理和反馈需求方会觉得自己被认真倾听回答质量也会更高。3.3 输出模板绑定“需求规格说明书”的结构Skill问完问题之后必须输出一个结构化文档而不是聊天记录。我是把输出模板直接定义成需求规格说明书的样子这样方案评审时可以直接用。模板包含以下区块项目背景记录原始需求与澄清后的真实目标用户与角色列出使用人群、决策者、受影响系统业务规则把对话中确认的每个规则单独编号功能清单每条功能要关联到“解决哪个业务问题”非功能需求性能、安全性、兼容性、可维护性验收标准表格形式每条包含操作、预期结果、容忍条件待确认问题所有没有当场确认的问题标明责任人和完成期限采用这个结构之后需求评审会从“大家自由发挥提意见”变成“每一条编号过”。效率提升非常明显而且每次评审都有文档可以追溯不会出现“上次不是说了吗”的扯皮。3.4 把Skill接进编排层变成团队可复用的流程Skill配置完成之后如果只在我本地的AI工具里使用价值有限。我的做法是把它接到了n8n上做成一个完整的自动化工作流。这个工作流大致是有人提交需求表单触发Skill进行第一轮提问AI整理答案后生成在线文档在文档中列出第二轮问题需求方填写之后再次触发如此循环直到四轮全部完成最后生成需求规格说明书。这种自动化流程非常适合团队协作场景。需求文档的填写不再依赖某一个人约时间开会而是所有人可以在自己方便的时间异步回答。AI在中间扮演“追问者”的角色回答有冲突时它会用不同颜色的标注标出来提醒相关人员确认。n8n里具体的节点配置我就不逐一刻板复刻了核心思路是HTTP Webhook接收表单触发用大模型节点调用Skill配置把输出结果写入数据库或在线表格再通过邮件/IM通知下一轮被提问人。这整套流程对于十人以内的小团队半天就能搭完关键不是节点多不多而是Skill本身的质量。4. 一场实际演练从模糊输入到可开发方案4.1 原始输入一句不到30字的需求为了演示效果我用一个最常见的场景来跑一遍。需求方提交的原始需求只有一句话“我们想做一个共享单车租赁需求预估用于辅助调度。”信息量几乎为零。没说是哪个城市、什么数据源、预测目标是什么、给谁看、怎么调度。把这句话直接交给开发团队大概率做法是先找一份开源骑行数据训练一个预测模型做个Web页面展示预测结果。听起来是不是很合理但需求方拿到之后大概率会说“不是这个意思。”这就是返工的原点。4.2 第一轮追问暴露出真正的业务盲区Skill的第一轮追问开始后对话大概是这样的Skill问“你希望通过预测结果改善什么现状”需求方答“调度员目前是凭经验上班上午潮汐点位经常空车用户投诉多。”Skill问“如果预测准确了调度员会怎么使用这个结果”需求方答“我们希望系统告诉他哪个站需要补车、补几辆最好是提前两小时。”Skill问“现在这个决策链条里谁对最终调度结果负责”需求方答“调度主管整个区域大概8个人。”到这里方向已经从“做一个无所不能的预测系统”收敛为“辅助调度主管做补车决策的预测工具”。后续所有功能设计都必须围绕调度主管的工作流进行。模型精度再高如果调度主管不看或者看了不知道怎么做系统就是废的。4.3 第二轮追问边界、约束和控制权目标澄清之后接着是边界问题。Skill这一轮问了几个关键问题“数据源有哪些实时车辆位置数据目前有接口吗”“预测是按站点粒度还是区域粒度”“时间维度上是每30分钟预测一次还是每小时”“调度员也需要一个移动端入口还是只在后台大屏上看到结果”需求方在回答这些问题时发现了自家数据的问题车辆位置数据目前只是每隔5分钟上报一次而且部分老车型不具备上报能力。这意味着无论模型多好实时调度会有至少5分钟延迟而且有10%的车无法被系统识别到。这些约束如果等到开发到一半再暴露整个调度方案的逻辑都要改。提前确认边界之后大家在方案层就接受了“预测工具展示的是近似车辆分布状态而不是精确到每辆车”的定位技术上也不会为了虚假精度做无用功。4.4 第三、四轮之后输出一份可开发的规格经过两轮追问需求方对系统的期待已经变得非常具体。第三轮场景细化跑完之后Skill输出了这样几条场景规则早高峰时段7:30-9:00系统应重点识别居住区附近站点的车辆溢出风险。演唱会、赛事等大型活动结束时允许调度员手动创建临时热点预测结果显示为高置信度预警。当站点为新开站点且无历史数据时系统应使用周边500米范围内站点的均值作为冷启动值。第四轮验收标准也直接量化了编号场景预期结果容忍范围A-1调度主管选择某区域查看未来2小时预测2秒内展示每个站点缺车/淤积等级3秒以内A-2数据源正常频率为5分钟/次预测结果延迟不超过数据源周期最多延迟5分钟A-3大型活动散场后30分钟内系统推荐临时调度任务响应时间10秒不出现漏推A-4新站点无历史数据使用邻近站点均值并在页面标注“冷启动”标注清晰到这个阶段开发团队可以直接拆任务了模型、数据管道、前端展示、调度员任务模块、冷启动逻辑、异常预警模块每个模块都有明确的输入输出和判定标准。这就是“问透”的价值。5. 真正常踩的坑Skill不是万能是半自动防呆5.1 坑一一轮抛出的问题太多需求方直接摆烂我第一次把Skill接到Agent环境时犯了一个典型错误为了让方案更严谨我在配置里写了三十多个问题让AI一次性问完。结果是需求方看了一眼就回复我说“太多了我晚点看”然后这一晚就再也没下文了。项目在原计划里卡了一周。后来我调整了策略每轮最多问6个问题并且按照优先级排序。前面几个是结构化的问题比如“你的目标是什么”后面一两个才是开放式的比如“还有什么我没想到的场景吗”。这招对大多数需求方都有效因为回答压力变小了人就有耐心继续对话。记住一条经验问透不等于一次性问完而是分轮把每一层的底磨穿。5.2 坑二只问“能不能做”没问“做不到怎么办”大多数技术出身的人提问时会偏向“能不能做”“怎么做”但需求澄清更关键的是“如果做不到可接受的降级方案是什么”。我在配置Skill时后来专门加了一个规则要求每一轮至少包含一个“如果……怎么办”式问题。比如对于预测需求不能只问“预测精确度要达到多少”还要问“如果预测准确率只有75%你的业务还能用它做调度吗还是说准确率必须超过90%”这个问题很有杀伤力因为它逼着需求方思考容错空间很多需求方在思考之后会说“其实60%都能用主要是趋势方向要对”。一旦确认这种容忍度整个方案的技术路线就简单了可能不需要上复杂模型一个移动平均加规则判断就能解决问题。技术方案省下来的成本全看这一问。5.3 坑三把AI整理的结果当最终方案缺少人的评审Skill再厉害本质也是对信息的整理和追问它不能代替真实业务中的人际沟通。我见过一个团队用了类似Skill之后把AI输出的需求文档直接发起评审结果业务方要求补充大量部门内部的潜规则这些规则在文档里从来不会写但直接影响流程设计。所以我现在固定执行一个动作Skill输出需求规格说明书之后必须加一页“人工评审记录”由需求方、技术负责人、测试负责人三人签字确认。Skill负责把所有已知信息问清楚人负责核算所有未说出口的默认前提。两个环节缺一不可。5.4 Skill本身也要持续迭代不要放在那里吃灰Skill不是一次配置就永久好用的。每个行业、每个公司甚至每个团队追问的重点都不一样。我在实际使用中会把每轮对话里那些特别有效的追问单独摘出来补充进Skill的配置。比如有一次我发现对于硬件类需求追问“新版和老版之间用户愿不愿意改变操作习惯”特别管用我就把这条加到了干系人那一轮里。我也建议给Skill加版本号每次修改都记录一下变更原因。比如当前我维护的版本是 v3.2这个版本在第三轮场景细化之后增加了一个“数据质量评估”子环节因为在两个项目中都发现数据源质量是返工重灾区。版本化不是为了仪式感而是让团队知道这个Skill是活的每次上线前都值得重新跑一遍。6. 落地一周后的体感变化我用这套Skill跑了三个不同类型的项目之后明显感受到几个变化。第一个变化是需求评审会上大家开始讨论具体业务规则了而不是对着概念图互相试探。“这个字段到底怎么定义”的讨论明显变多这其实是好事因为最模糊的地方被提前暴露出来了。第二个变化是需求方开始尊重文档了因为多轮追问之后他自己也觉得这不是一个“随口说说”的需求回答问题时明显更认真。当然也有人一开始很不适应觉得问题太多、太细。我的处理方式是把第一轮问题控制在五个以内并且告诉对方这些问题都是为了让方案不跑偏回答清楚之后不会再反复打扰。大多数人试过一次之后其实是很欢迎的因为最终拿到的方案确实更贴近他脑子里的想法。回到开头那句话需求返工的根子大部分不在开发手里而在前期方案讨论的颗粒度上。Skill的价值就是把这些年靠经验才能做好的“提问活”变成团队里每个人都能用的标准动作。如果你也经常被需求返工折腾不妨从本周就把问问题的流程写下来固化成你自己的Skill。哪怕不是挂在AI Agent里只是做成一张团队评审检查表返工率也会肉眼可见地下降。
需求返工频繁？用AI Skill把方案问透再开发
需求返工是每个做过项目的人都心有余悸的事尤其是那种需求方只丢过来一句“我要做个类似的系统”开发排期已经倒排结果做到一半发现方向错了产品、研发、测试一起返工谁都不好受。我之前也长期被这个问题折磨直到有一天我把一套提问流程沉淀成了可复用的Skill让它在方案阶段先把人“问透”返工情况才真正好转。这篇文章就是把我这套做法完整拆开讲清楚Skill怎么设计、怎么配置、怎么跑进真实工作流不只给结论也把踩过的坑一起说了。1. 需求返工的根源动手前缺一轮“反向追问”1.1 “需求”其实分三层大多数人只接了第一层做过几年产品或者项目管理的人应该都有这种感觉需求方说出来的话往往不是真实需求只是他脑子里临时找的一个表达方式。我第一次意识到这个问题是在一个内部报表系统项目里。需求方说“我要一个数据大屏”开发团队真的就去做大屏了屏幕、图表、实时刷新全部搞定结果对方看完很失望“我要的不是一块屏幕我是想知道昨天订单为什么跌了10%。”那一刻所有人沉默了屏是能做但跌的原因分析完全不在方案里。后来我把“需求”拆成三个层次来理解口头表达层需求方直接说出来的那句话比如“做一个大屏”“支持导入”“最好能一键生成”。字面规则层这句话落到文档里能写成具体功能描述比如“页面必须有12个图表”“数据每天凌晨同步一次”。真实问题层需求方真正想解决的业务痛点比如“管理层每天要花两小时开会对数我想让指标异常一眼可见”。大部分需求文档只写到了第二层甚至只写了第一层。方案评审时大家讨论的也是字段、按钮、页面这些表象真实问题层从来没被单独拎出来问过。返工就是从这里埋下的表象理解得再透彻底层问题只要偏一点整个方案都是错的。1.2 返工的真实成本比你以为的大得多很多人对返工的理解还是“开发改代码多花几天”。实际在方案阶段漏掉一个关键约束到了开发阶段根本不是改代码这么简单。我见过一个在技术方案里没有确认数据量的项目按照每天几万条数据设计结果上线第一个月就跑到千万级数据库表结构、查询接口、缓存策略全要推倒重来测试用例也跟着全部重写。返工有个特点时间越靠后修复成本越呈现指数级增长。方案阶段发现一个问题改的是几行文档设计阶段发现问题改的是架构图代码阶段发现问题改的是模块上线之后发现问题改的是用户信任。所以很多人问为什么项目老是延期原因不在开发速度而是大多数时间都花在“做出来的东西不是对方要的”上面。1.3 Skill在这里扮演的角色把资深分析师的提问经验固化成资产我最初意识到“要留出更多时间提问”是受一位老产品总监的启发。他接手任何项目第一周什么设计都不做就是开会问问题问得需求方有时候都烦了。但他的项目很少返工因为他把业务里的边界、冲突、异常情况全在脑子里过了一遍。问题在于这种能力高度依赖个人经验团队里不是每个人都有他那种问题库。后来AI Agent和Skill的概念流行起来我才想到能不能把他的提问框架拆出来做成一个可以复用的配置让任何项目在开始前都自动跑一轮“灵魂拷问”这就是我标题里说的“用这个Skill先把方案问透”的来历。这里说的Skill不是一句简单的提示词而是一整套包含角色定义、提问流程、输出模板、触发条件在内的可配置文件。你可以把它挂在Claude这类Agent环境里也可以接到n8n这类工作流工具中还可以单纯当成一份团队 SOP 文档来用。本质上是把“问透方案”这件看起来很玄的事情变成一套确定性很强的执行流程。2. 一个“方案问透Skill”的构成四个追问引擎2.1 引擎一目标与背景先确认“为什么现在要做”我设计的Skill第一轮问题全部围绕“目标和背景”展开这一轮的核心任务是逼着需求方把动机说清楚。很多人一上来就聊功能其实功能讨论得越细致越容易忽略“这件事到底为了达成什么效果”。这一轮我会让Skill固定问几个问题这次业务希望改变什么现状这个问题是从什么时候开始出现的如果不做这个方案一个月后会怎样谁是这个需求的最终受益者他会怎么感受到变化你拿什么指标判断这件事做成了这些问题看起来简单实际效果却很明显。有个做仓储系统的需求方一开始说“我要上自动化分拣”被Skill追问之后才承认真正的问题不是分拣慢而是仓库晚上经常找不到临时工次日发货经常延误。如果是这样方案的方向完全不一样可能先做任务排班系统甚至考虑和第三方劳务平台打通比一上来上昂贵分拣线实际得多。2.2 引擎二干系人与边界划清“谁做、谁看、谁说了算”需求返工还有一个高频原因需求方自己都没搞清楚决策链。经常是产品经理和开发对完方案需求方回去问领导领导说“方向不对”然后又推倒重来。所以一个合格的问透Skill必须有专门一轮问题处理干系人。这轮问题包括谁使用这个系统谁只是偶尔看一眼报表谁能拍板接受最终方案数据由哪个部门提供质量谁来负责系统出现问题的时候谁来处理用户投诉这个系统需要和哪些现有系统对接对接边界在哪里有一次我接一个企业级n8n部署方案需求方反复强调要“高可用、能扛住流量高峰”但问到“谁运维”时对方沉默了。他们公司没有专职运维整个技术团队都是业务系统开发出身。沿着这个问题追下去方案从自建三节点集群改成了云上托管加自动化备份因为没有人值班的情况下复杂架构只意味着半夜出故障时没人能处理。这就是干系人问题的价值它能把方案拉回现实。2.3 引擎三场景细化用遍历代替“应该没问题吧”场景问题是最容易被忽略的。很多需求文档只描述了“正常情况下用户怎么做”对异常情况只写一句“系统应进行错误提示”这等于什么都没写。我设计的Skill在第三轮会专门遍历各种场景包括正常流程、边界条件和异常情况。流程本身不复杂可以写成一套分支追问正常流程走通是什么样从哪一步开始到哪一步结束最频繁的操作是什么一个熟练用户一天操作几次哪些操作可以失败失败后用户应该看到什么哪些数据一定不能丢丢了多少分钟之内能接受多人同时操作同一个数据时会发生什么做“共享单车租赁需求预估”这个场景时需求初始版本非常简单只说“预测一下每个站点的用车需求方便调度”。如果只问功能需求方案就是一个时间序列模型加一张热力图。但Skill的第三轮追问多问了几个场景问题“下雨天数据要不要区分”“演唱会散场时单量暴涨怎么处理”“新站点没有历史数据怎么办”这几个问题直接把需求从“预测平均值”拉到了“预测分位数并适配突发场景”方案的复杂度、数据需求、算法选型全都变了。这就是场景遍历的价值——不是制造麻烦而是提前发现麻烦。2.4 引擎四验收标准把“差不多”逼成“可测试”最后一个引擎是验收标准这在很多需求文档里是空白。没有验收标准需求方验收的时候就可以凭感觉说“这个不太对”开发和产品只能被动接受。我让Skill在这一轮输出的是一组可测试的验收断言格式固定如下当用户执行操作A时系统应返回结果B在C毫秒/秒以内。数据源更新频率为D时系统最迟在E时间后完成同步。在用户数达到F的并发条件下系统核心接口错误率不超过G%。不支持的操作H系统应给出提示I而不得静默失败。把验收标准写清楚之后返工概率会大幅下降因为双方对“完成”的定义终于达成了共识。需求方再说“我觉得不太行”的时候你可以翻开文档问“哪条验收断言没满足”这不是抬杠这是在维护方案契约。3. 从零配置把Skill落到AI工具链里3.1 先把角色、目标和记忆文件定义好Skill落地第一步不是急着写问题列表而是先定义清楚它“是什么角色”。我习惯在Skill配置里写这样一段name: requirement-clarify-master description: 在项目启动前通过多轮提问澄清业务需求输出可验收的需求规格。 role: 资深业务分析师与项目顾问 behavior: - 不直接给方案而是通过提问启发需求方思考 - 每轮最多提6个问题按优先级排序 - 对模糊描述主动要求举例 - 捕捉到冲突后要求需求方做出唯一选择 output: - 需求澄清记录 - 需求规格说明书初稿 - 待确认问题清单这段配置别看简单它解决了两个常见问题。第一它约束了Skill“不要直接给方案”这一点极其重要否则AI会抢答直接给出一个听起来很美但实际上漏洞百出的方案反而掩盖了真实需求。第二它限制了每轮问题数量防止一上来生成四十个问题把需求方吓跑。记忆文件也是需要的。我一般会给Skill准备一个单独的知识库文档里面放三样东西历史项目中学到的典型需求坑、公司常用的业务流程术语、必须符合的数据安全规范。这样Skill提问时会自带“领域经验”而不是问一些通用但没用的问题。3.2 提问清单不是堆问题而是要分轮收敛踩过一次坑之后我强烈建议不要把提问清单做成一个平铺的大表格那样Skill运行时容易一次性全部抛出来。正确做法是分四轮每轮有明确目标下一轮基于上一轮的回答继续追问。我目前使用的Skill配置逻辑如下第一轮目标与背景输出“目标清单”和“成功指标”。第二轮干系人与边界输出“干系人地图”和“系统边界列表”。第三轮场景细化输出“正常流程列表”“异常场景列表”“边界条件列表”。第四轮验收标准输出“验收断言表”。每一轮的问题字段我会在Skill里用列表结构存好类似这样rounds: - name: 目标与背景 questions: - 这次业务希望改善的核心指标是什么 - 当前流程中最让用户头疼的环节是哪一个 - 如果资源有限哪个目标可以先放弃 next_round: 干系人与边界为什么要分轮而不是一次性问完因为人的注意力是有限的。需求方花十分钟回答问题的时候质量最高超过二十分钟就开始敷衍地回答“这个你看着办”。把问题切分成几轮中间夹着AI对上一轮回答的整理和反馈需求方会觉得自己被认真倾听回答质量也会更高。3.3 输出模板绑定“需求规格说明书”的结构Skill问完问题之后必须输出一个结构化文档而不是聊天记录。我是把输出模板直接定义成需求规格说明书的样子这样方案评审时可以直接用。模板包含以下区块项目背景记录原始需求与澄清后的真实目标用户与角色列出使用人群、决策者、受影响系统业务规则把对话中确认的每个规则单独编号功能清单每条功能要关联到“解决哪个业务问题”非功能需求性能、安全性、兼容性、可维护性验收标准表格形式每条包含操作、预期结果、容忍条件待确认问题所有没有当场确认的问题标明责任人和完成期限采用这个结构之后需求评审会从“大家自由发挥提意见”变成“每一条编号过”。效率提升非常明显而且每次评审都有文档可以追溯不会出现“上次不是说了吗”的扯皮。3.4 把Skill接进编排层变成团队可复用的流程Skill配置完成之后如果只在我本地的AI工具里使用价值有限。我的做法是把它接到了n8n上做成一个完整的自动化工作流。这个工作流大致是有人提交需求表单触发Skill进行第一轮提问AI整理答案后生成在线文档在文档中列出第二轮问题需求方填写之后再次触发如此循环直到四轮全部完成最后生成需求规格说明书。这种自动化流程非常适合团队协作场景。需求文档的填写不再依赖某一个人约时间开会而是所有人可以在自己方便的时间异步回答。AI在中间扮演“追问者”的角色回答有冲突时它会用不同颜色的标注标出来提醒相关人员确认。n8n里具体的节点配置我就不逐一刻板复刻了核心思路是HTTP Webhook接收表单触发用大模型节点调用Skill配置把输出结果写入数据库或在线表格再通过邮件/IM通知下一轮被提问人。这整套流程对于十人以内的小团队半天就能搭完关键不是节点多不多而是Skill本身的质量。4. 一场实际演练从模糊输入到可开发方案4.1 原始输入一句不到30字的需求为了演示效果我用一个最常见的场景来跑一遍。需求方提交的原始需求只有一句话“我们想做一个共享单车租赁需求预估用于辅助调度。”信息量几乎为零。没说是哪个城市、什么数据源、预测目标是什么、给谁看、怎么调度。把这句话直接交给开发团队大概率做法是先找一份开源骑行数据训练一个预测模型做个Web页面展示预测结果。听起来是不是很合理但需求方拿到之后大概率会说“不是这个意思。”这就是返工的原点。4.2 第一轮追问暴露出真正的业务盲区Skill的第一轮追问开始后对话大概是这样的Skill问“你希望通过预测结果改善什么现状”需求方答“调度员目前是凭经验上班上午潮汐点位经常空车用户投诉多。”Skill问“如果预测准确了调度员会怎么使用这个结果”需求方答“我们希望系统告诉他哪个站需要补车、补几辆最好是提前两小时。”Skill问“现在这个决策链条里谁对最终调度结果负责”需求方答“调度主管整个区域大概8个人。”到这里方向已经从“做一个无所不能的预测系统”收敛为“辅助调度主管做补车决策的预测工具”。后续所有功能设计都必须围绕调度主管的工作流进行。模型精度再高如果调度主管不看或者看了不知道怎么做系统就是废的。4.3 第二轮追问边界、约束和控制权目标澄清之后接着是边界问题。Skill这一轮问了几个关键问题“数据源有哪些实时车辆位置数据目前有接口吗”“预测是按站点粒度还是区域粒度”“时间维度上是每30分钟预测一次还是每小时”“调度员也需要一个移动端入口还是只在后台大屏上看到结果”需求方在回答这些问题时发现了自家数据的问题车辆位置数据目前只是每隔5分钟上报一次而且部分老车型不具备上报能力。这意味着无论模型多好实时调度会有至少5分钟延迟而且有10%的车无法被系统识别到。这些约束如果等到开发到一半再暴露整个调度方案的逻辑都要改。提前确认边界之后大家在方案层就接受了“预测工具展示的是近似车辆分布状态而不是精确到每辆车”的定位技术上也不会为了虚假精度做无用功。4.4 第三、四轮之后输出一份可开发的规格经过两轮追问需求方对系统的期待已经变得非常具体。第三轮场景细化跑完之后Skill输出了这样几条场景规则早高峰时段7:30-9:00系统应重点识别居住区附近站点的车辆溢出风险。演唱会、赛事等大型活动结束时允许调度员手动创建临时热点预测结果显示为高置信度预警。当站点为新开站点且无历史数据时系统应使用周边500米范围内站点的均值作为冷启动值。第四轮验收标准也直接量化了编号场景预期结果容忍范围A-1调度主管选择某区域查看未来2小时预测2秒内展示每个站点缺车/淤积等级3秒以内A-2数据源正常频率为5分钟/次预测结果延迟不超过数据源周期最多延迟5分钟A-3大型活动散场后30分钟内系统推荐临时调度任务响应时间10秒不出现漏推A-4新站点无历史数据使用邻近站点均值并在页面标注“冷启动”标注清晰到这个阶段开发团队可以直接拆任务了模型、数据管道、前端展示、调度员任务模块、冷启动逻辑、异常预警模块每个模块都有明确的输入输出和判定标准。这就是“问透”的价值。5. 真正常踩的坑Skill不是万能是半自动防呆5.1 坑一一轮抛出的问题太多需求方直接摆烂我第一次把Skill接到Agent环境时犯了一个典型错误为了让方案更严谨我在配置里写了三十多个问题让AI一次性问完。结果是需求方看了一眼就回复我说“太多了我晚点看”然后这一晚就再也没下文了。项目在原计划里卡了一周。后来我调整了策略每轮最多问6个问题并且按照优先级排序。前面几个是结构化的问题比如“你的目标是什么”后面一两个才是开放式的比如“还有什么我没想到的场景吗”。这招对大多数需求方都有效因为回答压力变小了人就有耐心继续对话。记住一条经验问透不等于一次性问完而是分轮把每一层的底磨穿。5.2 坑二只问“能不能做”没问“做不到怎么办”大多数技术出身的人提问时会偏向“能不能做”“怎么做”但需求澄清更关键的是“如果做不到可接受的降级方案是什么”。我在配置Skill时后来专门加了一个规则要求每一轮至少包含一个“如果……怎么办”式问题。比如对于预测需求不能只问“预测精确度要达到多少”还要问“如果预测准确率只有75%你的业务还能用它做调度吗还是说准确率必须超过90%”这个问题很有杀伤力因为它逼着需求方思考容错空间很多需求方在思考之后会说“其实60%都能用主要是趋势方向要对”。一旦确认这种容忍度整个方案的技术路线就简单了可能不需要上复杂模型一个移动平均加规则判断就能解决问题。技术方案省下来的成本全看这一问。5.3 坑三把AI整理的结果当最终方案缺少人的评审Skill再厉害本质也是对信息的整理和追问它不能代替真实业务中的人际沟通。我见过一个团队用了类似Skill之后把AI输出的需求文档直接发起评审结果业务方要求补充大量部门内部的潜规则这些规则在文档里从来不会写但直接影响流程设计。所以我现在固定执行一个动作Skill输出需求规格说明书之后必须加一页“人工评审记录”由需求方、技术负责人、测试负责人三人签字确认。Skill负责把所有已知信息问清楚人负责核算所有未说出口的默认前提。两个环节缺一不可。5.4 Skill本身也要持续迭代不要放在那里吃灰Skill不是一次配置就永久好用的。每个行业、每个公司甚至每个团队追问的重点都不一样。我在实际使用中会把每轮对话里那些特别有效的追问单独摘出来补充进Skill的配置。比如有一次我发现对于硬件类需求追问“新版和老版之间用户愿不愿意改变操作习惯”特别管用我就把这条加到了干系人那一轮里。我也建议给Skill加版本号每次修改都记录一下变更原因。比如当前我维护的版本是 v3.2这个版本在第三轮场景细化之后增加了一个“数据质量评估”子环节因为在两个项目中都发现数据源质量是返工重灾区。版本化不是为了仪式感而是让团队知道这个Skill是活的每次上线前都值得重新跑一遍。6. 落地一周后的体感变化我用这套Skill跑了三个不同类型的项目之后明显感受到几个变化。第一个变化是需求评审会上大家开始讨论具体业务规则了而不是对着概念图互相试探。“这个字段到底怎么定义”的讨论明显变多这其实是好事因为最模糊的地方被提前暴露出来了。第二个变化是需求方开始尊重文档了因为多轮追问之后他自己也觉得这不是一个“随口说说”的需求回答问题时明显更认真。当然也有人一开始很不适应觉得问题太多、太细。我的处理方式是把第一轮问题控制在五个以内并且告诉对方这些问题都是为了让方案不跑偏回答清楚之后不会再反复打扰。大多数人试过一次之后其实是很欢迎的因为最终拿到的方案确实更贴近他脑子里的想法。回到开头那句话需求返工的根子大部分不在开发手里而在前期方案讨论的颗粒度上。Skill的价值就是把这些年靠经验才能做好的“提问活”变成团队里每个人都能用的标准动作。如果你也经常被需求返工折腾不妨从本周就把问问题的流程写下来固化成你自己的Skill。哪怕不是挂在AI Agent里只是做成一张团队评审检查表返工率也会肉眼可见地下降。
