需求分析是需求到用例全流程的起点。分析质量决定后续测试点提取、用例生成、用例评审的上限——分析环节的信息损耗会在下游被逐级放大分析错了后面的工作全是无用功。本文系统拆解需求分析Skill的设计方法从SKILL.md的能力边界定义、references规则的沉淀方法、隐性需求推断机制、提示词设计策略到产物持久化方案和下游Skill衔接机制。目标是为设计需求分析Skill提供完整的技术框架和判断方法。01 为什么需求分析必须是独立Skill什么是独立Skill独立Skill是指具有明确输入输出、独立能力边界、可单独调用和调试的Agent能力模块。需求分析作为独立Skill意味着它不跟测试点提取、用例生成、用例评审混在一起而是自成一个可复用的分析单元。为什么不能跟其他步骤合并需求到用例的完整流程至少包含四步分析需求文档→提取测试点→生成测试用例→用例评审。如果四步塞进一个Skill会出现两个问题。链式失败。中间任何一步出错后面全跟着错。需求分析把一个条件判断理解成了状态流转测试点就按状态流转来拆生成的用例自然全跑偏。等看到最终结果无法定位是哪一步开始歪的。拆成独立Skill后每一步都有明确的输入输出问题可以逐层定位。逻辑差异。四步的思维模式完全不同。分析需求偏理解需要上下文窗口和文档解析能力提取测试点偏推理需要测试设计方法论的知识注入生成用例偏结构化需要严格遵循模板格式用例评审偏判断需要跟已有用例和历史Bug做比对。混在一起写提示词要兼顾四种思维模式结果就是哪头都不讨好。为什么不能用Prompt替代Prompt是一次性指令用完即弃没有积累机制。每次分析新需求模型都是从零开始理解上一轮分析中发现的规则、踩过的错误、总结的经验全部丢失。Skill的本质区别在于规则可以沉淀到references目录经验可以积累到知识库提示词模板可以迭代维护。同样是做需求分析第五次执行的Skill比第一次执行的Skill质量高得多因为规则和经验在持续沉淀。Prompt做不到这一点。怎么判断是否需要拆成独立Skill判断标准这一步是否有独立的输入输出、是否需要独立的规则沉淀、是否需要单独调试。如果三个条件都满足就应该拆。需求分析三个条件都满足——输入是需求文档输出是结构化模块摘要隐性需求推断规则需要持续沉淀分析质量需要独立验证和调试。02 SKILL.md怎么写定义能力边界SKILL.md是什么SKILL.md是Skill的能力名片告诉Agent这个Skill能干什么、什么时候该用、输入输出是什么。Agent拿到一个任务时先遍历所有Skill的SKILL.md判断该调哪个。SKILL.md写得模糊Agent就可能跳过这个Skill自己干或者在不该调用时错误触发。SKILL.md的四个核心部分触发条件。定义什么情况下Agent应该调用这个Skill。需求分析Skill的触发条件触发条件 1. 用户输入是需求文档PRD、需求规格说明书、功能描述文档 2. 用户明确要求分析需求理解需求解析需求 3. 任务流程中需要从需求文档提取结构化信息作为下游输入触发条件要具体但不僵化。只写输入是文档太宽泛什么文档都触发只写用户说分析需求太窄用户可能说帮我看看这个PRD。输入格式声明。明确接受哪些输入格式输入格式 - 支持的文件格式.md / .txt / .docx / .pdf / .xlsx / .xmind / .png - 输入方式文件路径或直接粘贴文本内容 - 不支持的格式视频、音频、压缩包需先解压提取文档输出格式声明。输出是结构化的模块摘要JSON输出格式模块摘要JSON { modules: [{name: , description: , business_rules: [], abnormal_scenarios: [], dependencies: []}], cross_module_flows: [], implicit_requirements: [{content: , confidence: 高/中/低, basis: 推断依据}] }输出格式声明要精确到字段级别。模糊的输出声明如输出需求分析结果会让Agent不知道该怎么格式化结果下游Skill也无法直接解析。能力边界声明。明确这个Skill能做什么、不能做什么能力范围 - 能做提取模块结构、识别业务规则、发现异常场景、推断隐性需求 - 不能做测试点设计、用例生成、用例评审由其他Skill负责 - 不确定时标记为待确认不做主观判断能力边界声明的作用是防止Agent滥用Skill。没有边界声明Agent可能让需求分析Skill直接输出测试用例跳过中间两步破坏流程完整性。衔接声明。说明输出给谁用下游衔接输出直接作为 testpoint-extraction Skill 的输入 上游依赖无本Skill是流程起点怎么判断SKILL.md写得好不好三个检验标准Agent能否仅凭SKILL.md决定是否调用、能否正确格式化输入、能否知道输出该传给谁。如果Agent在执行中需要额外提示才知道该不该用这个Skill说明触发条件写得不够清晰如果Agent传入了错误的输入格式说明输入格式声明不够明确。03 references规则怎么写把分析经验沉淀下来references是什么references目录存放Skill执行时需要参考的规则文档。SKILL.md告诉Agent这个Skill能干什么references告诉Agent具体怎么干。两者职责分离SKILL.md保持精简控制上下文窗口占用references承载细节按需加载。需求分析Skill需要哪些referencesimplicit_req_rules.md——隐性需求推断规则。这是需求分析Skill最核心的规则文件。定义从哪些信号推断隐性需求每类信号配推断示例。后面第04章展开讲。doc_format_guide.md——文档格式解析要点。各格式文档的解析注意事项。不是通用的Excel怎么读而是需求文档场景下的具体问题格式常见问题处理方式Excel合并单元格大面积覆盖字段名和值不在同一列先拆合并填值再按行拼接字段名-值对Word嵌套七八层表格层级关系难以映射按缩进深度打平为层级文本XMind节点层级对应模块-子模块-功能点递归遍历节点映射为树状结构PDF双栏排版、图文混排按阅读顺序提取图片走多模态模型描述图片需求文档以截图形式提供直接走多模态模型描述结构化提取quality_check_rules.md——输出质量校验规则。定义分析结果的校验标准后面第06章展开讲。规则粒度怎么定单文件不超过2000字一个文件只讲一类规则。粒度细的好处Agent按需加载不会把无关内容拉进上下文修改某类规则时不影响其他文件。粒度粗的坏处一个5000字的巨型规则文件Agent每次调用都要读一遍浪费上下文窗口还可能被无关规则干扰判断。实践中一个合理的规模4-5个Skill加起来10-15个references文件。需求分析Skill单独3-4个文件就够了。怎么判断references需不需要新增判断标准同一类问题在多次执行中重复出现且可以通过规则提前规避就应该沉淀为references文件。如果只是偶发问题不需要专门建规则文件在提示词里加一条约束就够了。04 隐性需求推断需求分析Skill最核心的能力什么是隐性需求隐性需求是需求文档中没有显式描述、但逻辑上必须存在的功能点或约束条件。比如PRD写了用户登录失败但没说失败后能不能重试、重试有没有次数限制、锁定后怎么解锁——这些是隐性需求。显性需求的提取靠理解隐性需求的推断靠推理。前者模型普遍做得不错后者才是需求分析Skill真正的价值所在。四类推断信号信号一条件判断缺失。需求描述了一个动作但没说条件不满足时怎么办。示例PRD写用户输入验证码登录没写验证码过期了怎么办、输入错误验证码怎么办、频繁请求验证码有没有限制。推断产出验证码有效期约束、错误重试策略、频率限制规则。信号二异常处理缺失。需求描述了正常流程但没说异常情况。示例PRD写用户提交订单没写网络中断时订单状态、支付超时的幂等性、库存扣减失败后的回滚。推断产出网络异常恢复策略、支付幂等性要求、库存回滚机制。信号三状态未定义。需求提到了某个状态但没定义完整的流转路径。示例PRD写支付完成没描述支付中、支付失败、支付退款的界面状态和操作路径。推断产出完整的状态流转图、每个状态的界面表现和可操作项。信号四竞态条件暗示。需求描述了涉及共享资源或并发的场景。示例PRD写抢购活动隐含了库存竞争、并发请求、超卖风险。推断产出并发控制策略、库存锁定机制、超卖防护方案。推断不是猜测边界在哪隐性需求推断需要逻辑必然性。判断标准如果这个需求点缺失功能是否无法正常运转或存在明显的质量风险。如果缺失后功能只是不够好但能跑属于优化建议而非隐性需求如果缺失后功能会出错或无法完成关键路径才是隐性需求。在提示词中约束推断边界的方式要求每个隐性需求必须标注推断依据——从原文的哪个描述推导出来、推导的逻辑链是什么。没有推断依据的不算隐性需求只算推测。推断可信度分三级级别含义示例高逻辑必然缺失会导致功能异常验证码没有有效期系统无法防止过期验证码滥用中合理推断缺失可能导致体验问题登录失败没有重试提示用户可能放弃操作低可能过度属于优化建议而非必要需求验证码输入支持粘贴提升体验但非必要高可信度隐性需求直接纳入分析产出中低可信度标记后传给下游由用例评审Skill决定是否采纳。怎么判断推断质量好不好对比人工分析结果。找一个已上线功能的需求文档分别做人工分析和Skill分析对比隐性需求的覆盖情况。重点关注有没有遗漏的高可信度隐性需求、低可信度推断中有没有过度推断的。遗漏率高说明推断规则不够过度推断多说明边界约束不够需要调整references中的推断规则。05 提示词设计让AI理解需求而不是总结需求理解与总结的区别总结是复述原文——需求写了什么就输出什么信息量不增不减。理解是发现原文没说的东西——从显性描述推断隐性需求从孤立规则发现跨模块关联从模糊表述识别歧义点。实践中常见的误区提示词写请分析以下需求文档模型大概率只做总结把原文换个结构重新组织一遍。有效率和直接读原文没有区别。提示词模板的三段式结构角色定义。不是简单的你是一个需求分析师而是明确角色关注点你是一个专注于测试视角的需求分析师。你的任务不是复述需求文档而是从测试 角度提取结构化信息识别可能遗漏的测试场景。你关注的是功能完整性、边界 条件、异常路径、跨模块关联。任务定义。明确要做什么输出什么格式任务从需求文档中提取以下信息—— 1. 功能模块划分及描述 2. 每个模块的业务规则带原文依据 3. 显式提到的异常场景 4. 隐性需求推断必须标注推断依据和可信度 5. 跨模块的数据流转和状态依赖 输出格式严格按JSON Schema输出字段定义见SKILL.md输出约束。约束推断行为和格式规范约束 1. 每条业务规则必须标注原文出处段落号或原文引用 2. 隐性需求必须标注推断依据和可信度高/中/低 3. 无法确定的信息标记为待确认不自行推断 4. 不做测试设计不输出测试点或测试用例示例比规则管用告诉模型预期结果要具体可验证它不一定懂但给一个分析示例效果立刻不一样。提示词中应该包含一个完整的好示例和一个差的示例差的示例{name:登录,business_rules:[支持手机号和密码登录],abnormal_scenarios:[登录失败]}好的示例{name:登录,description:支持手机号验证码和账号密码两种登录方式,business_rules:[验证码60秒有效期原文3.2节,密码错误5次锁定30分钟原文3.2节,首次登录强制修改密码原文3.3节],abnormal_scenarios:[网络超时,验证码过期,账户冻结],implicit_requirements:[{content:切换登录方式时已输入的内容需清空,confidence:中,basis:原文描述了两种登录方式可切换但未说明切换时的输入状态处理}]}差的示例缺少业务规则细节、异常场景笼统、没有隐性需求。好的示例每条规则有原文出处、异常场景具体、隐性需求有推断依据。模型看到对比后输出的质量会有明显提升。多轮分析的策略单轮分析很难同时做好显性信息提取和隐性需求推断。两种任务需要的思维模式不同——提取显性信息需要忠实于原文推断隐性需求需要跳出原文做推理。混在一轮里做模型容易顾此失彼。实践中更有效的做法是分两轮第一轮提取显性信息。专注于模块划分、业务规则、异常场景、依赖关系。提示词约束只提取原文中明确描述的内容不做推断。第二轮推断隐性需求。基于第一轮的输出专门做隐性需求推断。提示词约束基于已提取的模块结构和业务规则识别逻辑上必须存在但文档未描述的需求点。两轮分开每轮的提示词更聚焦模型的表现更稳定。代价是多一次模型调用但需求分析通常不是高频操作多一次调用的成本可以接受。06 输出质量校验分析完了怎么知道对不对校验的必要性需求分析的结果是下游所有步骤的输入分析质量直接影响整个流程的产出。没有校验机制错误的分析结果会一直传递到最终用例到用例评审阶段才发现问题回溯成本远高于分析阶段就拦截。三层校验Schema校验——格式是否正确。检查JSON结构是否符合定义的Schema必要字段是否完整modules不能为空、每个模块必须有name和description、类型是否正确business_rules必须是数组、priority必须是枚举值、隐含约束是否满足模块名不能重复、跨模块引用的模块必须存在。Schema校验用代码实现不走模型推理。确定性校验用确定性方法更快更准。交叉校验——内容是否完整。拿分析结果反查原文检查覆盖情况每个原文段落是否被至少一个模块覆盖业务规则数量是否合理一个中等功能模块通常有3-10条规则0条或30条都不正常异常场景是否只有网络异常这种万能条目如果是说明分析不够深入交叉校验可以部分自动化用关键词匹配检查原文中的条件判断语句“如果”“当”“若”是否都有对应的业务规则。完全的语义覆盖检查需要模型参与但关键词匹配能拦截大部分明显遗漏。可信度校验——隐性需求推断是否合理。检查每个隐性需求的可信度标注是否自洽标注高的隐性需求推断依据是否真的指向逻辑必然缺失会导致功能异常标注低的隐性需求是否更适合作为优化建议而非隐性需求同一模块的隐性需求数量是否异常一个模块推断出10条隐性需求大概率过度推断校验不过的处理策略两种处理方式根据问题类型选择自动修复。Schema校验不通过的缺字段、类型错误自动补默认值或打回重新生成。交叉校验发现明显遗漏的某个段落完全未覆盖将遗漏内容作为补充输入触发第二轮分析只处理遗漏部分。标记传递。隐性需求可信度存疑的不修改分析结果而是在产物中加标记让下游Skill注意。比如一个标注中可信度的隐性需求在传递给测试点提取Skill时附带说明此条为推断产物用例评审时需重点验证。这种方式比直接删除更安全——删除可能遗漏有效信息标记传递保留信息但加强下游验证。怎么判断校验是否足够如果下游Skill在执行中经常遇到分析结果缺少某类信息的问题说明校验不够严格需要在交叉校验中增加对应的检查项。如果校验拦截了大量结果但其中大部分其实是正确的说明校验过严需要放宽阈值。理想状态校验拦截的错误占被拦截总量的70%以上误拦率低于30%。07 需求分析产物要不要持久化持久化成什么两种模式临时产物模式。分析结果只在内存中流转喂给下游Skill就丢不保存到文件系统。好处是流程简单、没有文件管理开销。坏处是下游Skill无法回溯原始分析、人工无法审阅修正、重复执行同一需求时需要重新分析。持久产物模式。分析结果保存为独立文件作为后续所有Skill的共享输入。好处是下游Skill可以随时引用、人工可以审阅修正、多次执行可对比差异。坏处是需要文件管理和版本控制。为什么要持久化三个实际场景说明持久化的必要性场景一人工审阅和修正。需求分析的隐性需求推断不可能100%准确人工审阅是必要的。如果产物不持久化人工无法在分析结果上直接修改只能修改提示词重新跑一遍——但重新跑的结果可能又变了修改没有累积效果。持久化后人工直接编辑产物文件修正后的版本被下游Skill使用结果可控。场景二下游Skill回溯原始分析。测试点提取Skill在生成测试点时可能需要回看某个模块的完整分析结果。用例评审Skill在检查覆盖完整性时需要对照模块摘要中的业务规则。如果产物只在内存中下游Skill的上下文窗口可能不够塞下完整分析结果。持久化后下游Skill按需读取不受上下文限制。场景三需求变更对比。同一份需求文档修改后重新分析持久化产物可以对比两次分析的差异——新增了哪些模块、哪些业务规则变了、哪些隐性需求消失了。没有持久化每次分析都是独立事件无法追踪需求变更对测试的影响。产物格式选择格式优势劣势适用场景JSON下游Skill直接解析无需格式转换人工可读性差编辑容易破坏结构纯自动化流转Markdown人工可读可编辑审阅体验好下游Skill需要额外解析逻辑人工审阅为主JSON Markdown机器友好人友好各取所长维护两份格式的一致性成本推荐方案推荐方案Skill同时输出JSON和Markdown两种格式。JSON给下游Skill消费Markdown给人工审阅。两份产出的信息内容一致只是呈现形式不同。人工修改Markdown后由脚本转换回JSON覆盖原文件保证下游Skill拿到的是修正后的版本。产物命名和版本命名规则{需求文档名}_analysis_{时间戳}.json。同一需求多次分析时不同时间戳的文件并存不需要覆盖。变更对比时取最新两版做diff。版本管理不需要Git这种重型工具按时间戳排序就能满足需求。关键是每次分析都保留完整产物不要只保留最新版。怎么判断是否需要持久化判断标准是否需要人工审阅修正、下游Skill是否需要回溯原始分析、是否需要需求变更追踪。三条满足任意一条就应该持久化。都不满足的简单场景一次性分析、结果直接消费、不需要人工干预临时产物模式更轻量。08 有没有需求分析产物对下游生成用例的影响有多大三种情况对比情况一没有需求分析产物测试点提取直接读原文。模型拿到原始需求文档自行理解自行提取测试点。信息损耗约40-50%——模型对需求的理解是隐性的存在于上下文窗口中不可审查不可修正。边界场景和异常路径的遗漏率最高因为模型没有经过显式的推断隐性需求环节只是凭自身能力在原文中搜索。典型表现正常流程的测试点基本齐全边界值和异常场景大量遗漏。一个登录功能正常登录一定能想到“验证码过期后重新获取”连续错误密码锁定后的解锁流程大概率遗漏。情况二有需求分析产物但不包含隐性需求推断。模块结构清晰、业务规则明确测试点提取Skill可以直接基于结构化输入工作不需要自行理解原文。遗漏率约20-30%比直接读原文好但边界场景和异常路径仍然依赖测试点提取Skill自行补充——而测试点提取Skill的设计重点在怎么设计测试而非需求还缺什么让它同时做需求补全和测试设计效果不如分工明确。典型表现业务规则对应的测试点齐全但规则之间的交叉组合、规则未覆盖的灰色地带、异常恢复路径仍然遗漏。情况三有完整需求分析产物含隐性需求。测试点提取直接基于结构化输入且隐性需求已经显式化。遗漏率约5-10%剩余遗漏主要是领域专家才能发现的深层逻辑问题超出AI当前能力。典型表现正常流程、边界值、异常场景、跨模块关联、隐性需求衍生场景都有覆盖遗漏集中在需要业务深度经验的地方。影响链路分析质量的影响不会停留在测试点提取环节会一直传递到最终用例分析遗漏 → 测试点偏 → 用例偏离实际需求 → 评审工作量翻倍 → 整体效率反而不如人工这个链条中每一环的损耗是叠加的。分析环节遗漏30%测试点提取再遗漏20%用例生成再损耗10%最终有效率可能只有40-50%。加上用例评审的返工总时间投入可能比直接人工写用例还多。关键结论需求分析产物的价值不在存下来而在给下游提供了什么信息。如果产物只是原文的结构化摘要换了个格式复述一遍对下游帮助有限——模型读原文也能做摘要。产物的真正价值在于补充了原文没有的信息隐性需求、跨模块关联、业务规则的完整推导。这些信息是测试点提取环节的输入增量有了这些增量下游质量才有质的提升。怎么评估产物对下游的实际影响找一个已上线功能的需求文档分别用三种方式跑完整流程直接读原文→有分析产物但无隐性需求→有完整分析产物对比最终用例的有效率。有效率计算方式生成的用例中描述准确、步骤可执行、断言有意义的占比。这个对比数据可以用来量化需求分析Skill的价值也可以用来指导后续迭代方向。09 下游Skill怎么使用需求分析产物测试点提取Skill的读取方式需求分析产物的核心字段是modules数组每个模块包含name、description、business_rules、abnormal_scenarios、dependencies、implicit_requirements。测试点提取Skill按模块逐个遍历business_rules → 功能测试点和边界测试点的来源abnormal_scenarios → 异常测试点的来源implicit_requirements → 补充测试点的来源根据可信度分级处理隐性需求的传递方式根据可信度分级可信度传递方式下游处理高直接作为测试点来源正常生成用例无需特殊标记中作为测试点来源附带待确认标记用例生成时加备注用例评审重点验证低不作为测试点来源放入评审清单不生成用例由人工决定是否补充这种分级传递的好处是高可信度的隐性需求直接利用不浪费低可信度的不盲目采纳避免生成无效用例中可信度的折中处理既保留信息又加强验证。产物修正后的传递人工审阅后修改了需求分析产物比如删除了一条过度推断的隐性需求、补充了一条遗漏的业务规则下游Skill以修正后的版本为准。这要求产物持久化——如果产物只在内存中人工无法干预如果产物持久化了人工直接编辑文件下游Skill读取修正后的文件。修正后的产物需要重新走质量校验确保人工修改没有破坏JSON结构。校验通过后下游Skill正常使用。上下游数据格式一致性需求分析Skill输出的JSON Schema就是测试点提取Skill的输入Schema。字段定义必须统一包括字段名一致不能一边叫business_rules另一边叫rules字段类型一致不能一边是字符串另一边是数组枚举值一致priority的取值范围两边必须相同格式不一致的后果下游Skill解析失败或解析出错误数据。排查这种问题极其耗时——你以为数据传过去了实际上字段名对不上下游Skill拿到的是空值。实践中建议定义一份共享的Schema文件所有Skill引用同一份定义不要各自维护一份。修改Schema时所有Skill同步更新。异常处理产物缺失或字段为空下游Skill在使用产物时可能遇到几种异常产物文件不存在。比如用户直接调测试点提取Skill跳过了需求分析。处理方式提示用户先执行需求分析或者降级为直接读取原始需求文档回到情况一质量下降但流程不中断。某个模块的字段为空。比如某个模块的abnormal_scenarios为空数组。处理方式不跳过该模块但在测试点提取时额外加一轮补充异常场景的分析尽量弥补分析环节的遗漏。隐性需求字段缺失。产物是老版本格式没有implicit_requirements字段。处理方式兼容处理不报错测试点提取按情况二的模式工作有分析产物但无隐性需求。怎么判断衔接是否顺畅检查下游Skill的输入日志确认产物是否被完整读取、字段值是否符合预期、是否有字段解析失败的警告。如果下游Skill的输入日志显示大量空值或解析错误说明衔接有问题需要检查Schema一致性。10 与知识库联动历史Bug在需求分析阶段的价值需求分析阶段为什么要查历史Bug知识库中存储的历史Bug记录在需求分析阶段的作用不是直接提测试点——那是测试点提取Skill的事。需求分析阶段查历史Bug的目的是发现这类需求容易出什么问题从而在分析当前需求时更关注这些脆弱点。比如知识库中有记录“登录功能的验证码校验接口在高并发下返回了已过期的验证码导致用户无法登录”。当前需求也有登录功能需求分析Skill在分析时知道了这个历史问题会在隐性需求中补充验证码校验接口的并发安全性。检索策略不是全文检索是定向检索。检索条件模块名匹配当前分析的模块名与历史Bug的模块名相同或相似业务规则关联当前模块的业务规则与历史Bug的触发条件相关检索结果的排序依据相关性不是时间。一个两年前的Bug如果跟当前需求高度相关比一个昨天的低相关Bug更有参考价值。何时走知识库何时走提示词知识库存事实——历史Bug、业务规则、已知问题。提示词存规则——怎么分析、怎么推断、怎么约束。两者职责不同不能互相替代。一个常见误区把历史Bug的描述直接写进提示词期望模型在分析时自动参考。问题在于提示词的空间有限塞几条Bug案例就满了而且Bug记录是动态增长的提示词不可能实时更新。正确做法是知识库存Bug、提示词存分析规则、Skill在执行时动态检索知识库。知识库检索结果如何融入产物检索到的历史Bug作为模块的extra_context字段高相关Bug直接关联到对应模块{name:登录,business_rules:[...],extra_context:{related_bugs:[{bug_id:BUG-2025-0412,summary:验证码校验接口并发下返回过期验证码,relevance:高,analysis_note:当前需求的验证码校验逻辑需关注并发安全性}]}}extra_context不影响模块的分析结果本身但会传递给下游Skill。测试点提取Skill看到analysis_note会在提取测试点时额外关注并发场景。怎么判断知识库联动是否有效对比有/无知识库联动时的隐性需求产出。如果启用知识库后隐性需求中出现了仅凭当前需求文档无法推断出、但历史Bug证明确实需要关注的需求点说明联动有效。如果启用后隐性需求没有明显变化说明检索策略需要优化或者知识库中跟当前需求相关的内容太少。11 常见失败模式与调试模式一需求理解偏差表现把条件判断理解成状态流转、把并列关系理解成顺序关系、把可选功能理解成必选功能。原因提示词中对理解的约束不够具体模型按自身理解去解读需求文档缺乏测试视角的引导。调试方法拿同一个需求文档人工分析出模块摘要逐字段对比Skill输出。偏差在哪个模块、哪个字段、偏差方向是什么是漏了还是理解错了定位后针对性修改提示词或补充references规则。模式二隐性需求遗漏表现推断太保守明显该推断出来的隐性需求没有推断出来。原因推断规则不够全面或者提示词中对推断的约束过严比如只推断逻辑必然的需求导致模型不敢推断合理但非严格必然的需求。调试方法检查遗漏的隐性需求属于四类信号中的哪一类对应的推断规则是否存在。如果规则缺失补充到implicit_req_rules.md如果规则存在但模型没有遵循加强提示词中的强调。模式三隐性需求过度推断表现推断太激进把优化建议、个人偏好当成隐性需求输出。原因推断边界不清晰模型把建议有当成必须有。调试方法检查过度推断的隐性需求的推断依据是否满足缺失会导致功能异常的标准。不满足的降级为低可信度或删除。同时在提示词中加强边界约束增加过度推断的反面示例。模式四格式解析失败表现复杂Excel/Word解析丢信息模块划分不完整业务规则残缺。原因文档格式过于特殊解析逻辑覆盖不了。合并单元格、嵌套表格、图文混排是重灾区。调试方法用解析后的文本与原文对比检查信息丢失发生在哪个环节。如果是解析脚本的问题修改scripts中的解析逻辑如果是模型理解的问题在doc_format_guide.md中补充对应格式的处理要点。模式五下游衔接断裂表现产物传递给下游Skill后解析失败或下游Skill拿到的字段值为空。原因上下游Schema不一致字段名不同、类型不同、枚举值不同或产物版本更新后下游Skill没有同步适配。调试方法检查下游Skill的输入日志确认产物是否被完整读取、字段值是否符合预期。Schema不一致的问题统一到共享Schema文件解决避免各Skill各自维护。通用调试流程对比人工分析结果定位偏差模块检查偏差模块的输入——是原文信息丢失还是理解错误如果是理解错误检查提示词和references规则如果是信息丢失检查文档解析逻辑修改后重新执行对比改进效果有效的修改沉淀到references或提示词模板中每次调试的结论都应该沉淀下来而不是改完就忘。references和提示词的迭代记录就是Skill的经验积累。选型总结设计决策判断标准是否拆成独立Skill有独立输入输出需要独立规则沉淀需要单独调试references要不要新增同类问题在多次执行中重复出现且可规则化产物是否持久化需要人工审阅/下游回溯/变更追踪满足任一即持久化产物格式需要人工审阅用MarkdownJSON双格式纯自动化用JSON隐性需求推断边界缺失会导致功能异常→推断缺失只是不够好→不推断多轮还是单轮分析追求质量用两轮显性隐性分开追求速度用单轮知识库联动有历史Bug且与当前需求相关时启用否则跳过需求分析Skill的设计不是一次成型的需要根据实际执行效果持续迭代。每次迭代解决一类问题规则逐步沉淀产物逐步完善。第一版Skill不需要完美能跑起来、能调试、能定位问题比追求一步到位更实际。