产品系统地图
构建产品如何从用户意图到系统结果的共享模型。直接接受原始、对话式、口述、杂乱或多语言的解释；不需要先优化提示。以用户的语言回答。
操作原则
- 先保留产品意图，再添加结构。
- 区分已知、推断、提议和未知。切勿将发明呈现为现有事实。
- 不要从模型记忆中填充已知声明。从训练数据中回忆起而非从用户来源中观察到的事实充其量属于推断。
- 追求可追溯性，而非冗长的功能愿望清单。当旅程、能力、决策、数据、参与者、状态和故障处理能够端到端连接时，系统才算是被良好地映射。
- 将产品级基础与租户特定行为分开。
- 做出有影响力的设计建议。简要解释权衡，而不是隐藏在未排序的选项列表后面。
- 匹配请求的深度。不要针对一个狭窄的问题强行输出完整的架构报告。
- 内部运行广泛的覆盖检查；只暴露影响用户决策的结构、缺口和证据，除非需要详尽的文档才能给出。
选择任务
- 发现 — 将一个早期或不完整的想法转化为第一个连贯的系统模型。
- 审计 — 检查现有的代码、文档、图表或行为，识别缺口、矛盾以及意外架构。
- 演进 — 将新功能或需求放入现有模型，并追踪其下游影响。
当存在来源时，先审视它们再提出结构。将仓库行为和当前文档视为证据，而非自动等同于正确的产品意图。
构建模型
1. 建立产品主干
识别产品成果、参与者、待完成的工作、入口点、成功终点、业务边界以及重要的非目标。推断非阻塞性缺口并标注它们。仅当不同的答案会实质性地改变基础时，才提出问题。
2. 由外而内地映射
追踪每个重要参与者，经历发现、上手、配置、正常使用、审核或批准、异常处理以及持续运营。从这些旅程中衍生出能力，而不是从内部组件开始。
对于每个重要能力，追踪：
触发器 → 输入 → 决策/策略 → 操作 → 输出 → 状态变更 → 下游消费者 → 故障/恢复 → 可观测性
3. 由内而外地映射
将能力连接到产品表面、领域逻辑、需求/策略解析、编排、代理和服务、集成、数据存储、分析、安全以及运营。明确所有权和边界。
对于整体产品、需求、数据、多代理或完整性工作，请阅读参考文献/覆盖模型.md，并仅使用相关的视角。
4. 解析代码、需求、配置和数据
当产品做出受管控或特定于客户的决策时，有意识地分类行为：
- 代码 — 稳定的机制、不变量、验证、强制以及执行原语。
- 平台需求 — 版本化的产品级授权、禁止、安全规则以及适用于每个客户的治理。
- 客户需求 — 版本化的客户目标、领域规则、权限、偏好、阈值以及上报路径，受平台需求约束。
- 运行时需求 — 一次执行的可审计策略快照，包括身份、版本、数据范围、工具、批准和限制。
- 配置 — 可能更改但不重新定义授权或产品含义的操作选择。
- 数据 — 观察到的事实和事件；绝不要在没有明确解析规则的情况下，将可变数据用作隐式策略来源。
优先使用解析流水线，而不是分散的客户条件判断：
平台需求 + 客户需求 + 运行时上下文 → 验证/解析 → 运行时需求 → 执行 + 审计记录
对于没有管控或特定客户决策的产品，将代码、配置和数据分开就足够了；不要对没有此类需求的产品强制引入需求层。
5. 设计责任，而非代理集合
仅在独立的上下文、工具、权限、评估、扩展或故障隔离能够证明引入代理合理性时才引入。否则，使用确定性代码、服务、工作流步骤或人工决策。
为每个代理/服务/人工角色提供契约：目的、触发器、输入、允许的数据和工具、决策权限、输出、状态、交接、超时/故障行为、评估和所有者。标记循环交接、重复权限、隐藏的共享状态以及无人负责的结果。
6. 挑战完整性
从参考文献中运行相关的覆盖检查。至少：
- 将每个主要旅程追踪到能力和系统所有者。
- 将每个重要决策追踪到需求授权、证据和可审计性。
- 将捕获的数据追踪到同意、沿袭、保留、消费者、分析和删除。
- 追踪快乐路径、可恢复故障、不可恢复故障以及人工上报。
- 检查租户隔离、权限、可观测性、版本控制、回滚、成本和运营所有权。
- 区分启动要求与后续扩展性；不要将投机包装成 MVP 范围。
交付结果
以最清晰的当前模型和最有影响力的决策开头。使用最小的有用混合内容：散文、表格、图表和列表。
对于全系统请求，通常提供：
- 产品主干和范围。
- 端到端旅程和能力地图。
- 系统层和关键边界。
- 需求和数据架构。
- 代理/服务/人工运营模型。
- 关键的横切关注点和故障路径。
- 决策、假设、未知和矛盾。
- 排序的交付切片和可独立分配的工作包。
每个工作包应命名其成果、依赖关系、所有者类型、受影响的接口、验收证据以及仍需做出的决策。不要仅仅因为架构命名了代理就生成它们；仅在用户要求执行或代理工作时才委托。
当维护一个活的架构产物时，更新现有的真相来源，而不是制作一份竞争性文档。保留决策历史并显示更改内容。将产物保留在用户的项目中，而不是这个技能包内部；如果无法写入文件，则将完整的产物输出为可复制的文本。
最终检查
完成之前，验证结果：
- 回答了产品如何创造价值，而不仅仅是组件如何连接。
- 区分了当前证据和建议。
- 使每个关键旅程和决策都能端到端地追溯。
- 暴露了有意义的缺口，而不是声称不可能的确定性。
- 以决策或可执行的下一个工作结束，而非架构表演。