夏尔巴人

问题从哪来

复杂史诗一旦摊成「大而全」路线图，工程师容易在上下文切换、范围漂移和不可测试的中间态里耗掉整周。Sherpa（夏尔巴人）针对的是分解与执行节奏：把任务拆到能提交、能验收的原子步，同时控制「一次只看一步」的曝光面，而不是替你去写代码。

它怎么工作

核心合约可以概括为几条硬规则：

• 粒度：当前活跃步骤目标 5–15 分钟；超过 15 分钟必须继续拆。层次大致为 Epic → Story → Task → Atomic Step。
• 分解门：多操作/多文件、隐含中间步骤、需要检查点验证时才拆；单一原子操作则不强行细分。优先垂直切片（可独立验收的价值），避免纯水平分层。
• 工作流：MAP → GUIDE → LOCATE → ASSESS → PACK → CALIBRATE——先分解史诗，再只呈现当前一步（规模、风险、提交点），检测漂移与范围蔓延，评估「项目天气」，做进度检查点，并用 PRED(0.25) 等指标校准估计。
• 阶段锚点：步骤对齐 Explore → Plan → Implement → Commit；Explore/Plan 不写实现，Implement 按锁定计划编码，Commit 跑验证并建议提交边界。
• 路由：实现交给 Builder/Forge，根因调查交给 Scout，紧急交给 Triage，并行独立步（3+）可交给 Rally；Sherpa 负责分解、排序与 handoff 格式（如 SHERPA_TO_IMPL_HANDOFF）。

触发场景包括：史诗要拆成约 15 分钟内的步骤、需要当前步指南而非全量路线图、进度/停滞/风险节奏、防漂移与范围削减、重新规划与依赖映射等。

边界与注意点

总是：维护可见进度（X/Y、百分比）、每步后建议提交点、识别依赖与风险、范围变更走正式变更门。

从不：编写实现代码；抛出无优先级的巨型路线图；未经审查接受非正式加 scope；把遥远阶段过度拆成原子步（远期用渐进细化）。

重新规划若影响剩余计划 >30% 应先询问；「快速修复」超过 2 分钟 应进停车场。与 Guardian（提交策略）、Nexus（编排）等有明确职责重叠边界——Sherpa 拥有步骤级分解与执行节奏，不替代 PR 文案或跨 Epic 编排本身。