Muniu Liumia

解析 PRD 需求、设计系统架构、拆解开发任务、生成实现指导、审计交付质量——覆盖从原始需求到可交付代码全流程的 Skill 包。当用户需要分析需求文档、做架构设计、准备开发或检查需求完成情况时使用，通过 /mnlm 命令触发。

MuniuLiuma（木牛流马）

将原始需求文档高效转化为可交付代码的全流程 Skill 包。5 个 Phase 按数据依赖串联，根据用户意图和上下文状态自动决策执行范围。

命令

text

/mnlm           触发 Skill，Agent 根据用户意图和上下文自动决策执行范围

用户也可通过自然语言触发（如"解析这份需求"、"做架构设计"、"拆任务"、"检查完成情况"），Agent 自动识别对应的执行范围。

触发判断

第一步：开发意图检测

意图类型	示例	是否触发
显式命令	/mnlm	✅ 触发
解析请求	"分析/解析/拆解这份需求"	✅ 触发
开发动作前置	"根据这个需求做架构"、"基于PRD排任务"	✅ 触发
质量审查	"检查PRD有没有遗漏"、"需求有什么模糊点"	✅ 触发
仅分享无动作	"你看下这份需求"、"先看看"	❌ 不触发
无附加说明	直接甩链接/文件，无附加文字	❌ 不触发
闲聊	"这PRD写得太长了"	❌ 不触发

第二步：自动触发建议

在开发意图检测过程中，如果用户没有主动要求结构化分析，但检测到以下信号，Agent 主动建议是否使用 MuniuLiuma：

信号	Agent 建议
用户描述了复杂需求但未要求结构化分析	"检测到你的需求涉及多个功能点，建议先走 /mnlm 结构化梳理，确保不遗漏。"
用户开始编码但未做需求梳理	"检测到当前需求尚未结构化梳理，建议先运行 /mnlm 解析。"
用户对话中累积了多个零散需求点	"检测到对话中已累积多个需求点，建议统一走 /mnlm 梳理。"

• 用户拒绝后不再重复建议，除非需求复杂度显著增加（如新增 3 个以上功能点）
• 用户主动说"不用""直接做"时，尊重用户选择

不触发时保持静默，等待用户进一步指示。

第三步：输入内容验证（仅 Phase 1）

触发后判断文档类型：

• 是 PRD / 需求文档 / 功能描述 → 进入解析流程
• 是其他类型（API 文档、设计稿、会议纪要等） → 告知"这不是需求文档（检测到类型：XX）"，询问意图
• 无法判断 → 主动询问"这是需求文档吗？需要我解析吗？"

范围评估

触发后、进入决策流程前，评估需求规模是否适合走全流程：

评估结果	判定标准	Agent 行为
太大	涉及多系统重构、跨团队架构迁移、完整产品从零搭建	建议用户拆分为多个独立需求，逐个走流程
太小	修改单个变量、调整一行配置、修复一个明确的 bug	建议用户直接实现，无需走全流程
刚好	一个完整功能的需求、一个用户故事、一个模块的新增或重构	进入决策流程

用户坚持走全流程时尊重用户选择，但在输出中标注范围评估结果。

项目模式识别

根据上下文判断当前属于哪种开发模式：

模式	识别信号	流程差异
Greenfield（新项目）	项目目录为空、无已有代码、用户明确说"从零开始"	标准流程：Phase 1 → 5
Brownfield（已有项目）	项目目录有代码、用户提到现有功能、"给XX加个功能"、"重构XX模块"	Phase 2 必须先扫描现有架构，做增量设计而非全量设计
Retrofit（逆向补文档）	用户说"帮我理解这段代码"、"给这个模块补 Spec"	Phase 1 从代码反向生成 Spec，而非从 PRD 正向提取

Brownfield 模式下 Phase 2 的额外步骤：

1. 扫描项目现有架构（模块划分、技术栈、API 风格）
2. 分析新需求对现有架构的影响（新增/修改/不变）
3. 做架构一致性检查（新设计是否与现有模式冲突）
4. 标注与现有架构不一致的地方，供用户确认

决策流程

收到用户指令后，按以下步骤判断执行范围：

第一步：确定目标 Phase

用户意图	目标 Phase
"全流程"或明确要求跑完全部	Phase 1 → 5 全链路
"解析需求"、"分析这份 PRD"	Phase 1
"做架构设计"、"设计方案"	Phase 2
"拆任务"、"排任务"	Phase 3
"准备开发"、"实现指导"	Phase 4
"检查完成情况"、"审计"	Phase 5

第二步：递归检查前置依赖

text

目标 Phase N 的 [必需] 输入都存在？
  ├── ✅ 全部存在 → 直接从 Phase N 开始执行
  └── ❌ 缺失 → 回溯到 Phase N-1
        ├── Phase N-1 的输入存在 → 执行 Phase N-1 → 输出传给 Phase N
        └── 仍缺失 → 继续回溯...直至 Phase 1

各 Phase 的必需输入：

Phase	必需输入	缺失时的补齐策略
Phase 1：prd-parser	PRD/需求文档（文本）	无法补齐，主动询问用户提供
Phase 2：arch-designer	结构化 Spec	检查上下文有无原始 PRD → 有则先跑 Phase 1
Phase 3：task-planner	架构设计方案	检查上下文有无 Spec → 有则先跑 Phase 2
Phase 4：implementation	任务清单 + 架构设计	检查上下文有无任务清单 → 有则先跑 Phase 3 → 无则继续回溯
Phase 5：trace	Spec + 架构 + 任务清单 + 实现指导 + 代码	逐层回溯补齐全部上游产物

第三步：执行并输出

1. 按补齐后的链路依次执行，中间产物保留在对话上下文中
2. 遵循「输出规范」完成最终输出
3. 每个 Phase 执行完毕后，将关键产物展示给用户确认，用户确认后再进入下一 Phase

Agent 停止规则

以下场景中 Agent 必须暂停执行并向用户确认，而非自行继续：

停止场景	触发条件	Agent 行为
范围过大	需求涉及 5 个以上独立功能域或跨系统重构	列出拆分建议，等待用户确认拆分方案
需求矛盾	Spec 中发现 3 个以上无法自动解决的需求冲突	列出矛盾项和可选方案，等待用户决策
架构风险	Phase 2 检测到现有架构存在严重问题（如单点故障、硬编码依赖）	标注风险并建议优化，用户决定是否先处理
回退请求	用户在任意 Phase 表示上游产物有问题	暂停当前 Phase，回退到用户指定的上游 Phase 重新执行
Phase 完成	每个 Phase 输出完毕后	展示产物摘要，询问用户是否确认继续

执行示例

标准路径

用户说	上下文状态	决策	实际执行
"根据这个 PRD 做架构"	有 PRD，无 Spec	Phase 2 缺 Spec → 回溯 Phase 1	Phase 1 → Phase 2
"解析这份需求" + 文件	无上下文	Phase 1 有文档输入	Phase 1
"检查需求完成情况"	全链路产物齐全	Phase 5 输入齐全	Phase 5
"帮我拆任务"	仅有 Spec	Phase 3 缺设计 → 回溯 Phase 2	Phase 2 → Phase 3
"准备开发"	有任务清单	Phase 4 有输入	Phase 4
"审计一下代码"	仅有代码	回溯至 Phase 1 也缺 PRD	告知用户缺少需求基线，由用户决策

范围评估场景

用户说	范围评估	Agent 行为
"帮我重构整个电商系统"	太大	建议拆分为独立模块（用户服务、订单服务、支付服务等），逐个走流程
"把按钮颜色改成蓝色"	太小	建议直接实现，无需走全流程
"给登录模块加双因子认证"	刚好	进入决策流程

Brownfield / 已有项目场景

用户说	上下文状态	决策	实际执行
"给现有的用户模块加个权限管理"	项目已有代码	Brownfield 模式 → Phase 2 先扫描现有架构	Phase 1 → Phase 2（含现有架构分析）
"帮我理解这段遗留代码，补个文档"	无 PRD，有代码	Retrofit 模式 → Phase 1 从代码反向生成 Spec	Phase 1（逆向提取）
"这个模块之前做过架构设计，现在要加新需求"	有历史架构文档	Phase 2 加载历史架构，做增量设计	Phase 1 → Phase 2（增量模式）

异常与回退场景

用户说	上下文状态	决策	实际执行
"Spec 里漏了一个功能，补上"	Phase 2 已执行	回退到 Phase 1 补充，再重新执行 Phase 2	Phase 1（增量更新）→ Phase 2（重跑）
"这两份 PRD 有冲突，帮我分析"	两份 PRD	Phase 1 逐份解析 + 交叉对比矛盾	Phase 1 × 2 + 矛盾报告
"需求变了，之前的设计要改"	已有 Spec + 架构	标注变更影响范围，增量更新 Spec 和架构	Phase 1（增量）→ Phase 2（增量）
Phase 2 扫描发现现有架构有严重问题	Brownfield 项目	暂停 Phase 2，报告架构风险	输出架构风险报告，等待用户决策

错误处理与降级

遇到异常时采取降级而非中断：

异常场景	处理策略
无法读取项目代码	跳过代码扫描，仅基于已有产物做部分审计，标注"代码审计未执行"
WebFetch 抓取失败	告知用户，请求手动粘贴内容或导出文件
Spec 质量不确定	标注置信度低的条目，建议用户人工审核关键功能点
上下文接近窗口极限	建议将已完成的产物保存为文件，在新对话中通过文件引用继续
输入文档格式异常	告知支持的格式，请求提供可解析的版本

降级原则：

• 即使降级也要输出部分结果，而非直接失败
• 降级输出必须标注哪些环节被跳过或简化，以及原因
• 始终提供可操作的下一步建议

上下文管理

1. 按需加载：只加载目标 Phase 对应的 reference 文件，不预加载下游 Phase
2. 产物传递：上游输出直接作为下游输入，不重复生成或复述
3. 大文档分段：PRD 过长时按章节/模块分段处理，独立提取后合并
4. 输出精简：只包含结构化结果，不包含分析过程和备选方案论述
5. 产物外部化：每个 Phase 输出末尾建议用户保存为文件（遵循「产物保存规则」，不主动创建）
6. 溢出降级：优先保证目标 Phase 的必需输入和结构化输出完整，可裁剪分析过程

输出规范

所有 Phase 遵循以下规则：

• 输出为纯 Markdown，不依赖特定渲染器
• 输出语言默认中文，可通过自然语言指令切换英文（如"用英文输出"）
• 只输出目标 Phase 的结果（中间 Phase 的产物不单独展示，除非用户要求）
• 产物末尾附"建议保存为文件"的提示（仅提示，不主动写入）
• 上游 Phase 在本次调用中重新执行过时，标注"⚠️ 下游产物可能已过期"

产物保存规则

产物默认输出到对话上下文，不主动创建文件。文件保存遵循以下规则：

触发条件

仅在以下情况才创建或写入文件：

• 用户明确要求"保存到文件"、"写入文件"、"导出"等
• 上下文接近窗口极限时，提示用户是否需要保存（仍需用户确认后才执行）

禁止在无用户授权的情况下自行创建文件。

保存路径

• 首次保存：询问用户希望保存到哪个目录，并给出建议路径（如 prd/specs/）
• 后续保存：复用同项目中已确认的目录，无需重复询问
• 如用户未指定，使用以下默认建议路径：

Phase	默认建议路径	文件命名建议
Phase 1	prd/specs/	SPEC-{文档编号}_{功能名}.md
Phase 2	prd/architecture/	ARCH-{文档编号}_{功能名}.md
Phase 3	prd/tasks/	TASK-{文档编号}_{功能名}.md
Phase 4	prd/implementation/	IMPL-{文档编号}_{功能名}.md
Phase 5	prd/audit/	AUDIT-{文档编号}_{功能名}.md

保存后

• 告知用户文件已保存的完整路径
• 询问用户是否继续执行下一步（如架构设计、任务拆解等），用户确认后 Agent 自动执行

Phase Reference

执行对应 Phase 时，加载以下 reference 文件获取详细指令：

Phase	Reference 文件	职责
Phase 1	references/phase-1-prd-parser.md	原始文档 → 结构化 Spec + 追问清单
Phase 2	references/phase-2-arch-designer.md	结构化 Spec → 架构设计方案
Phase 3	references/phase-3-task-planner.md	架构设计 → 可执行任务清单
Phase 4	references/phase-4-implementation.md	任务清单 → 实现指导规范
Phase 5	references/phase-5-trace.md	全链路产物 → 完工审计报告