DOCUMENTATION / WORKING WITH JOURNEY

让理解，跟着项目走。

建立地图只是开始。需求变化时更新局部，交付时换一种表达，积累之后回头检查薄弱环节。

Plan · 建立第一份理解

把目标拆成里程碑与步骤，再逐步加入行为、感受、触点和时间。优先保留能解释问题的信息。

帮我梳理用户从发现产品，到第一次完成核心任务的旅程。
把你不确定的地方标出来，先不要补成确定的结论。

指出什么变了、为什么变。更新对应节点时，同时检查它与前后步骤的关系。

预订现在变成可选了。
请移除提前预订步骤，修正关联引用，并列出这次修改。

确定性脚本检查结构与关联。删除一个仍被引用的步骤可能被拒绝，需要先修正引用。

ERROR … dangling cross-ref: → book-ahead
commit rejected (no changes written)

这段输出来自仓库的会议室运行记录。校验通过表示结构检查通过，不表示体验假设已经被证实。

来源标记区分模型生成、人工修改、引用依据和从其他字段合成的信息。它让后续对话能够追问，而不是把猜测越写越像事实。

- momentOfTruth: 空房间就在眼前，却不能使用
  - _provenance: source: 走廊观察

示例中的来源属于案例设定。实际使用时，应记录真实、可核对的资料。

通过脚本提交的变更会留下记录，包含作者、操作、目标和备注。直接手工编辑文件不等于经过同一条校验与记录路径。

这张旅程最近改过哪些步骤？
是谁改的？为什么修改？把相关记录列给我。

回看当前旅程里的弱点、信息缺口和相邻旅程。把需要补充的研究问题列出来，再决定下一步。

请检查这张地图：哪些关键时刻缺少依据？
哪些失败情境没有恢复路径？接下来最值得梳理哪段旅程？

可以输出故事线、一页简报、工程交接或交互 HTML。表达方式根据用途选择，原始旅程继续保留。

给行政生成一页说明，强调规则变化和运营动作。
再给工程师一份交接，列出需要实现和确认的事项。