常见问题解答

先看你的需求能不能落到一个明确的交付结果上。如果需求可以用一句话说清“做完之后能看到什么、能核对什么”，通常就能在 服务方向索引 里找到对应条目。反过来，如果需求还在“先聊聊看能做什么”的阶段，建议先在索引页比对适配对象和典型任务，再决定要不要进入沟通。

建议准备三样东西：需求背景（为什么现在要做这件事）、期望结果（做完之后用来做什么）、已有的约束（时间安排、已有资料、必须满足的条件）。这三项不需要写成正式文档，能在沟通时讲清楚即可。缺少其中一两项也不影响沟通，只是确认阶段会多一轮来回。

可以。合作前的疑问不需要等到需求完全成型再提。把不确定的点列出来，比带着模糊印象进入执行更省时间。你可以先参考 交付范围与验收标准 了解结果约定方式，再针对仍然不清楚的部分提问。

客户侧主要负责确认需求口径、提供必要资料、在关键节点给出反馈；囧次元侧负责方案梳理、执行推进、阶段成果提交与问题同步。具体分工在 合作流程 的四个阶段里逐段列出，可以在开工前对照确认。

先说明调整的原因和影响范围，再判断属于口径澄清还是范围变更。口径澄清在阶段沟通中直接确认即可；涉及交付条目的调整，需要按交付范围页说明的变更处理流程走一遍，避免执行到后期才发现双方理解不一致。

不需要。阶段反馈以能否推动下一步为准，列出“认可的部分、需要修改的部分、暂不处理的部分”三类意见就够了。反馈越具体，返工越少。如果意见之间存在冲突，建议先内部对齐再统一给出。

验收围绕交付条目逐项核对，核对依据在开工前就已经确认，不在交付时才临时约定。具体条目与核对方式见 交付范围与验收标准 ，建议在合作开始前先通读一遍，确认每条都能接受。

先区分是交付范围内的遗漏，还是新增需求。属于条目范围内的遗漏，按验收流程处理；属于新增需求，则作为新的条目重新确认。这样处理是为了让双方对“哪些算完成”有一致判断，避免反复拉扯。

验收通过代表当前条目的结果已经确认，后续是否需要继续推进取决于你的实际使用情况。如果使用中出现新的需求方向，可以回到服务方向索引重新比对，按新的合作流程走一遍。