企业官网建设流程全解析

需求总返工？用这个Skill先把方案问透

有没有过这种经历：产品提了个需求说“做个报表”，你吭哧吭哧做完了，对方说“不是这个意思”，然后从头再来。又或者开发跟你说“这个功能有点复杂”，你没当回事，等排期出来才发现要翻倍。这些问题根子上都出在一个地方——方案没问透，大家脑子里的画面根本不是同一张。

我在过去半年里一直被这种返工折磨，后来干脆写了一个Skill专门治这个病。它不是那种花哨的自动化工具，也不绑定特定平台，而是一套用Prompt工程做出来的“需求拷问模板”。简单说，你把一个模糊想法丢给它，它会像最较真的产品经理一样追着你问，直到把目标用户、业务场景、边界条件、验收标准全部抠出来，最后生成一份可以直接给开发看的方案初稿。

这个Skill的核心价值不只是“多问几个问题”，而是把问问题的过程变得有结构、有层次、有判断力。你不需要自己列问题清单，它会根据你的回答动态调整方向，弱需求往深挖，强需求往边界推。前后试过的人反馈都很一致：用了它之后，需求评审会上撕扯的时间少了，开发和产品吵起来的次数也直线下降。

这篇文章想把整个设计思路、Prompt写法和实际使用过程完整拆给你看，顺便把我踩过的坑和排查技巧也一并交代清楚。不管你是产品、技术负责人还是独立开发者，只要手上经常要跟需求打交道，这套方法都能直接用。

1. 为什么需求总是返工：先搞懂“问透”的分量

很多团队把返工原因归结为“沟通不充分”，但这话太笼统了。我自己复盘过大量返工案例，发现真正的原因其实可以用一句话说清楚：需求方和交付方各自心中都有一个方案，但两边从来没有把方案的细节对齐过。

1.1 返工不是需求含糊，是方案信息缺环

举个我最近遇到的真事。运营提了个需求，大意是“要一个数据看板，能看到每天的订单情况”。听起来很简单对吧？但实际上这里的信息缺口至少有五个：

• 订单情况到底指哪些指标，是订单量、成交额、客单价、退款率还是全都要？
• 每天的数据是看当天实时，还是看T-1的汇总？
• 看板是给运营自己看，还是要给老板汇报用？
• 数据颗粒度按小时、按天还是按周？
• 移动端看还是桌面端看，要不要支持导出？

如果这些不确认直接开做，哪怕你选了一个最合理的默认值，最后大概率也会被杀回来重做。这不是需求本身含糊，而是方案层面的信息缺环。

这个Skill要解决的就是这类问题。它不会替你做决定，但会逼着所有相关方把那些“大家以为不用说”的信息全部摆到台面上。信息一旦完整，方案就成了明牌，返工自然就失去了土壤。

1.2 方案先问透的三个层次：事实层、判断层、验收层

实际操作中，我把“问透”拆成了三个层次，对应Skill里不同的提问策略。

事实层解决的是“是什么”的问题。比如：当前数据存在哪里、有没有历史数据可用、系统现在有哪些埋点、并发量大概多少。这些问题都有确定答案，答不上来说明信息准备不到位，需要先回去查证。

判断层解决的是“怎么选”的问题。比如：更看重开发速度还是扩展性？先支持核心场景还是全场景覆盖？这些问题没有标准答案，需要结合业务优先级来权衡。Skill在这一层的作用是帮你把所有选项和成本暴露清楚，避免拍脑袋决定。

验收层解决的是“怎么算完成”的问题。比如：什么样的数据表现算成功？上线后用什么指标来衡量效果？这是最容易被忽略的一层，但恰恰是它决定了未来会不会二次返工。没有验收标准的需求，做完了也会被“再改改”这四个字打回原形。

1.3 Skill和Agent到底有什么区别

很多朋友第一次看到这个名字会问，Skill和Agent不是一回事吗？这里得说清楚。Agent是那种能自主规划、自己调用工具、多步骤完成任务的智能体；Skill更像是一套“行为指南”或“工作模板”，它本身不主动干活，而是当你把它加载到对话里时，它会改变模型处理输入的方式。

可以这么理解：Agent是请了个实习生帮你跑腿，Skill是给实习生发了一张需要逐项确认的检查表。前者适合跑完整流程，后者适合在某个环节做深度控制。

我这套需求拷问Skill就是后者。它的任务不是替你完成需求的实现，而是在需求进入实现阶段之前，把所有的坑先趟一遍。它和Agent也不冲突——你在Agent前面加一道Skill关卡，反而能让Agent后续的执行更顺。

2. 这个Skill怎么问：结构化追问的设计逻辑

很多人觉得写个Skill不就是写一段“请多问我几个问题”的提示词吗？没那么简单。第一版我就是这么干的，结果模型问了一堆通用问题，什么目标是什么、受众是谁、时间节点是什么，问了等于没问。后来我才明白，真正有效的提问必须是有逻辑、分层次、能根据回答动态调整，而不是背诵一套标准问卷。

2.1 追问的三大原则：少问选择题，多问填空题

第一版Skill失败在哪儿？它特别喜欢问选择题。比如“您更看重A还是B”，用户理都不理你，或者随便选一个答案。后来我发现，需要引导对方打开话匣子的场景，填空题远比选择题有效。

举个例子。不问“您的目标用户是谁”，改问“描述一个真实用户使用您产品的完整过程，从她遇到什么问题开始，到她最后怎么解决”。用户一旦开始描述场景，潜台词里的信息量就出来了——她是什么身份、在什么环境下用、痛点在哪里、有没有替代方案。这些细节，选择题根本套不出来。

所以我的Skill规范里有一条硬性要求：先让用户描述场景，再根据场景提炼关键约束。问得越具体，回答越有价值；问得越开放，越容易得到“随便”“都行”这种无效反馈。

2.2 如何控制追问轮次：信息饱和度判断机制

还有一个很现实的问题：追问到什么时候算完？无限问下去，用户会烦；问太少，方案还是模糊。这里需要一个“信息饱和度”的量化判断标准。

我设计了一个简单但有效的机制。每一轮追问结束后，Skill要求模型自检一个清单：

• 目标用户画像是否具体到能描述一个典型使用场景？
• 核心业务流程的数据输入输出是否明确？
• 边界条件和异常情况是否有交代？
• 是否存在至少一个可量化的验收指标？
• 技术约束（性能、安全、兼容性）是否已经暴露？

这五条全部满足，就进入方案生成阶段；哪条不满足，就针对那条继续追问。所有追问不能凭空而来，必须跟已经获得的信息产生关联。比如用户说“访问量不大”，你就接着问“不大是个什么量级，一天一百次还是一万次？访问高峰在什么时段？”，而不是翻出通用题库的下一条继续问。

这套机制有效的原因在于它给了模型一个“停下来”的理由，而不是让它机械地问满N轮。很多手写Prompt之所以不好用，就是因为没有停机条件，模型只能靠猜来判断用户什么时候不耐烦。

2.3 为什么不让Skill直接给方案，而是先逼你写“一页纸”

设计这个Skill时，我做了一个反直觉的决定：它不会在一开始就输出完整方案，而是会先引导用户自己整理一份“一页纸需求说明”。字数限制是300字以内，必须包含目标、用户、场景、约束、验收标准五个要素。

为什么这么设计？因为我发现，很多做需求的人自己能说清楚，但一写就废。而写作本身是一种更高强度的思考，逼着对方把脑子里转的东西落到纸上，很多逻辑漏洞自己就暴露了。这也是产品领域常说的“写作是思考的外化”。

实际操作下来，这个环节虽然增加了前期的摩擦感，但后端的沟通成本下降非常多。凡是认真写过这300字的人，跟开发对齐需求时明显更快，返工率也低得多。因为写作的过程已经帮他完成了一轮自我审视，很多模糊的地方在开口之前就被剔除了。

3. Skill实现细节：Prompt结构、输出格式与关键参数

讲完了理论，下面是硬核内容。这套Skill我是用标准的YAML配置编写的，兼容Claude、GPT等主流模型，也适用于各类支持自定义技能的平台。核心文件结构只有两个：一个SKILL.md描述职责和约束，一个questions.md存储标准问题模板。但真正让它好用的，是里面这些细节设计。

3.1 Prompt主框架：角色、职责边界与输出要求

整个Prompt的主框架长这样，我尽量把关键结构展示出来，你可以直接抄去改：

--- name: requirement_clarifier version: 1.2.0 description: 通过结构化追问澄清模糊需求，生成可执行方案初稿 --- # 角色定义 你是一名资深需求分析师，拥有10年以上的产品和系统设计经验。 你的任务不是直接给出解决方案，而是通过系统的提问，协助用户 把模糊的想法变成清晰、完整、可执行的需求描述。 # 行为准则 1. 每次最多提出3个问题，避免让用户一次性面对大量信息 2. 优先针对信息缺口提问，而不是漫无目的地发散 3. 禁止替用户做假设，任何未经验证的前提都要标注为待确认 4. 用户回答后，先总结你理解的信息增量，再进入下一轮追问 5. 当信息饱和度达到预设阈值时，自动停止提问并输出方案 # 输出规范 - 采用结构化输出，依次呈现：需求概述、目标用户、核心场景、 边界与非目标、技术约束、验收标准、风险清单、待确认项 - 对于信息缺口，以 [待确认] 标记，禁止用猜测填补 - 总输出控制在1200字以内，便于对话中快速审阅

这段Prompt的功力在于“禁止替用户做假设”这一条。很多模型生成方案时喜欢脑补，用户没说的技术栈、部署环境、数据规模都替你安排好了。但需求澄清阶段，脑补就是返工的源头。我踩过最大的坑就是让模型自由发挥生成方案，结果漂亮是漂亮，可三分之一的假设都是错的。

输出规范里我特意控制了长度。1200字的限制逼迫Skill必须挑重点写，不会给你洋洋洒洒写五千字没人看。每个字段如果信息不完整，宁可留白标注[待确认]，也不能用套话填充。这个要求从效果上看非常关键，等于给输出加了一个“不糊弄”的过滤器。

3.2 追问模板设计：六个维度覆盖需求全貌

追问模板我设计了六个维度，每个维度下有一组标准问题，模型会根据对话进度选择切入。这里贴出我的标准问题清单：

每个维度都不是必问的，模型会根据已有信息判断跳转或取舍。比如用户说“内部工具，数据量很小”，性能维度就可以浅尝辄止；如果是“对外服务，月活百万”，那性能和稳定性就必须追到细节。

还有一个单独的小技巧：所有问句都要求以“如果...会怎样？”的形式出现至少一次。比如“如果数据量翻十倍会怎样？”“如果用户同时在线一千人会怎样？”。这种假设性问题能快速把隐藏的风险点暴露出来，比干巴巴地问“有什么约束”高效得多。

3.3 核心代码片段：让Skill能自动判断“信息缺口”

Skill的灵魂在于能识别信息缺口。这部分我写了一段伪代码来定义判断逻辑，实际应用中你可以用模型原生能力实现，也可以用外部脚本调用：

def identify_gap(conversation_history, requirement_fields): """ 基于对话历史，识别仍未覆盖的关键需求字段。 """ collected = set() for message in conversation_history: content = message.get("content", "") # 简单关键词匹配，判断该字段是否已在对话中出现 for field in requirement_fields: if field["keyword"] in content or field["alias"] in content: collected.add(field["name"]) gaps = [f for f in requirement_fields if f["name"] not in collected] # 按预设优先级排序，返回缺口最大的3个 gaps.sort(key=lambda x: x["priority"], reverse=True) return gaps[:3]

实际部署时，你不需要写这么复杂的代码。我在CLAUDE.md里定义了一个“自检函数”，让模型每次输出前“运行”一遍判断逻辑，效果几乎一样。关键不在于实现方式，而在于你必须显式告诉模型“你有权决定什么时候停止提问”，否则模型会一直问下去，把用户问到崩溃。

3.4 Skill的扩展能力：从需求澄清到自动生成Stories

到了后期，我给这个Skill加了一份附带的输出模块：当需求澄清完成后，它会自动把结果转换成三到五张用户故事的草稿。这个扩展非常实用，因为需求澄清的产出如果只是口头共识，后面还是容易变形；但一旦转成结构化的用户故事，开发团队直接可以用。

用户故事模板我选的是标准的“作为_[角色]，我希望[功能]，以便[价值]_”格式，但加了一个细节：每个故事后面必须附带验收条件，且至少写出一个“非验收条件”。这一步把验收层的思考固化到了交付物里，后续开发自测时也有了依据。

如果你用的是飞书或者Notion管理需求，这个Skill产出的Markdown格式可以直接粘贴进文档模板，不需要重新格式化。这也是我刻意选择Markdown作为输出的原因之一——几乎所有工具都原生支持，省掉了格式转换这一步。

4. 实际跑通全流程：从一句模糊需求到方案初稿

理论说了半天，不如直接上一次实操。我用最近一个真实案例走一遍完整流程，你就知道这个Skill是怎么一层层把模糊需求“榨”清楚的。

4.1 案例背景：共享单车租赁点需求预估

背景是这样的，有个客户想做一个“共享单车租赁需求预估”的功能。原始需求就一句话：“我们要预测每个站点未来几天的单车需求，好决定调度方案。”听起来是个典型的数据分析小项目，但实际上坑非常多。我把这句话直接丢给Skill，它的追问流程大概是这样的。

第一轮追问，Skill先稳住了“事实层”：

• 当前每个站点的历史借还车数据是从哪里获取的？有没有现成的数据仓库？
• 站点的地理信息（经纬度、周边POI）是否已数字化？
• 整个城市的站点数量大概是多少？单车总量又是多少？
• 这个预测结果是要直接驱动自动调度，还是仅作为人工决策的参考？

这4个问题一出来，客户马上意识到自己连数据来源都还没完全理清。原来他们手上只有一部分站点的借还记录，而且格式还不统一。这个信息在整个后续方案里非常关键——因为它直接决定要不要先做数据清洗的预处理模块。

第二轮追问，Skill转向“判断层”：

• 预测精度和响应速度哪个更优先？可不可以接受“预测结果生成慢一点，但准确率更高”的方案？
• 时间颗粒度上，你是需要未来7天每天的总量，还是需要未来24小时逐小时的热力需求？
• 调度决策是人工为主，模型为辅，还是希望通过模型输出全自动的调度指令？

客户在回答这些问题时开始出现分歧。运营端希望看到逐小时的精细数据，技术端觉得做逐日预测就够了。这个分歧如果靠开发时再发现，工期至少多出两周。Skill在前期就把它暴露出来，后续方案里我们特意设计了一个“时间粒度可选”的配置项，两边都不得罪。

第三轮追问，Skill终于触及“边界与验收层”：

• 大雨天、节假日、临时封路这些异常情况，需不需要在首版中考虑？
• 预测准确率达到多少，运营团队会认为“这个功能能用”？70%还是85%？
• 如果预测出现严重偏差，需要什么样的兜底机制？

这些问题让客户意识到，原来“预测准确率”本身就是一个需要定义的指标。是预测总量准确，还是按站点逐个比对准确，差异非常大。最终我们把验收标准设计成了“站点维度平均MAPE小于25%”，听起来不惊艳，但已经足够支撑调度决策，而且实现成本可控。

4.2 最终输出长什么样：一页纸方案展示

三轮追问之后，Skill自动生成了方案初稿。这里展示部分核心内容，你可以感受一下输出格式的质量：

需求概述： 构建共享单车各站点短期需求预测模型，为每日/每周的车辆调度计划提供数据支持。 目标用户： 城市运营团队的调度员（核心）、区域运营负责人（辅助）。 核心场景： 调度员每天上午9点查看系统生成的未来24小时站点需求热力图， 在10点前完成当日调度计划。 边界与非目标： - 首版不包含恶劣天气的自动修正规则（标注为[待确认]） - 不涉及车辆维修、报废等生命周期管理 - 不做实时流量监控，只看需求预测 技术约束： - 数据源：现有历史借还记录（覆盖约80%站点，格式未统一） - 计算周期：预测任务每日运行一次，可接受30-60分钟的耗时 - 输出形式：Web看板 + CSV导出 验收标准： - 站点维度平均MAPE < 25% - 模型可在1小时内完成全城市站点的预测 风险清单： - 历史数据质量不足，可能导致模型精度不达标 - 新增站点无历史数据，冷启动问题需要解决 待确认项： - 天气数据的获取来源和更新频率 - 是否包含节假日效应，需进一步确认历史节假日数据是否完整

看到没有，这份输出里没有一句废话，每一个字段都是后续开发可以直接拉取用的信息。而且“[待确认]”的标记非常关键，等于给团队留了一份明确的跟进清单。客户看到这份方案后，很快就组织了内部评审，把天气数据和节假日效应的两个待确认项补上了。整个过程前后不到一天，整个需求就从“一句话”变成了“可执行”。那这种方案的质量其实也不难验证，开发团队看完之后直接给出了开发量预估，明确表示“这个需求现在可以排期了”。

4.3 使用Skill的三种模式：对话式、文档式与混合式

这么一套流程，实际使用时不一定要在线对话。我在实际探索中总结了三种使用方式，适用场景各不相同。

对话式是最直接的用法。把Skill加载进支持的AI对话工具中，然后直接把需求丢进去，一路回答追问，最后拿到输出。优点是动态性好，Skill可以根据你的回答实时调整方向；缺点是必须有耐心，三轮追问下来大概要花15到20分钟，急性子可能会中途放弃。

文档式则是把Skill当成一个“审稿人”。你先自己把需求写成草稿文档，然后让Skill以这个文档为输入，输出它发现的信息缺口和追问清单。这种方法不需要实时对话，适合需求方比较忙、只能异步沟通的场景。

混合式是我目前最推荐的模式。第一轮用文档式让各方先各自提交自己的需求理解和缺漏清单，然后开一个短会，用对话式的Skill把分歧暴露出来，现场逐项确认。这套流程看起来多了一道工序，但实际节约的时间远超预期，因为很多矛盾在会议前就被暴露了。

5. 常见问题与排查技巧实录

Skill用久了，会遇到一些典型问题。这里整理一份速查表，直接标注现象、原因和解决办法，方便你遇到问题时快速对应。

5.1 常见问题速查表

5.2 实战翻车经历：一次失败的需求澄清过程

说一个我自己的翻车案例。有一次内部要做一个“CRM字段自定义”功能，我把Skill跑了一遍，看起来输出非常完整，目标用户、场景、边界都说得清清楚楚。但因为我在设计Prompt时没有处理好“技术可行性”这个维度，导致一个关键问题漏掉了：CRM当前架构根本不支持动态字段扩展，如果要支持，底层表结构要大改。

结果就是方案初稿做得再漂亮，到技术评审环节直接被否掉了。后来我在Skill的行为准则里加了一条硬性要求，追问过程中必须包含“当前系统的核心架构约束是什么？做一个类似功能，改动会涉及哪些模块？”这个问题听上去有点技术化，但能把技术风险提早暴露，价值巨大。

这次翻车也让我悟出一个道理：Skill不是万能的，它更像一个高质量的问询框架，把你“知道自己不知道”的东西暴露出来，但如果你“不知道自己不知道”，它可能会跟着你的思路一起跑偏。所以我现在会让Skill在输出前加一句“我可能遗漏的假设”，把所有它做过的隐性假设全部列出来，逼着自己再审视一遍。

5.3 针对不同需求的微调：技术需求、业务需求、研究需求

不同的需求类型，追问的重点和节奏差别很大。我用这个Skill处理过三类典型需求，微调经验分享一下。

技术类需求，比如系统部署、性能优化方案，追问的重点要放在现状和约束上。技术栈版本、数据规模、可用资源、兼容性要求，这些缺一个后面都可能出大问题。我通常会在Prompt里补充一句“请优先确认用户当前的技术环境和资源限制，再深入了解目标”。

业务类需求，比如运营活动、产品迭代，追问的重点放在目的和度量上。活动期望拉新还是促活？提升多少留存算成功？这种需求最容易出现“目标不清晰”的问题，尤其要小心“提升用户体验”这种没法衡量的伪目标。遇到这种表述，Skill会直接追问“什么时候体验算好？好到什么程度算达标？”

研究类需求，比如数学建模、数据分析，追问的重点放在数据处理和假设上。数据源在哪里？数据是否干净？模型可解释性要求多高？这类需求常常卡在“数据不可用”这个坑里，前期多问几句能省掉后面大量的返工。

5.4 怎么判断你的Skill写得好不好：自测清单分享

最后分享一份自测清单，是我现在每写完一个Skill都会跑的检查项。你可以拿它来测试自己的Prompt设置：

• 丢进去一句模棱两可的话（比如“帮我做个东西”），它能问出有意义的问题吗？
• 把它的追问记录拿给完全不懂背景的第三方看，对方能否理清需求的逻辑脉络？
• 连续追问五轮以上，用户会产生“它在教我做事”的不适感吗？
• 用户回答自相矛盾时，它能敏锐地发现并指出矛盾吗？
• 输出的方案是否能让刚接手的人直接从零开始执行，而不需要再去找需求方确认？

如果这五条全部通过，恭喜你，这个Skill基本达到了可以放心使用的水平。如果某条不通过，回去调整对应的Prompt段落通常就能解决。这个迭代方法我一直在用，效果很稳定。

结尾：这个Skill还能怎么扩展

跑了大半年，这套Skill帮我把需求返工率压到了一个非常低的水位。但我个人的体会是，它的价值不止于“少返工”本身。当你习惯用结构化追问的方式去理解需求后，你会发现在写技术方案、做个人规划、甚至跟家人沟通时，都会本能地先去确认那些容易被忽略的边界条件。这是一种思维方式的训练，Skill只是那个帮你入门的工具。

最后再分享一个小技巧：如果你觉得每次手动加载Skill麻烦，可以把它的核心逻辑写进团队的共享文档里，让产品和技术都按同一套框架来组织需求描述。所有人对“完整需求”的定义一致了，沟通成本自然断崖式下降。这个Skill的终极目的不是替代人的判断，而是让每个参与需求的人，都学会在动手前先把方案问透。