# Product

## Register

product

## Users

主要面向需要理解脚本构建过程与最终脚本的业务人员。他们不需要理解数据库、事件或 Agent 内部实现，但需要快速看懂每轮做了什么、为什么这样决定，以及最终产出了什么。

## Product Purpose

以横向 n8n 式流程还原真实的脚本构建过程，并提供与原业务页一致的最终脚本表，让非技术用户可以从流程故事下钻到完整业务数据。

## Brand Personality

清晰、克制、可信。

## Anti-references

- 不做将数据库字段直接堆到界面上的技术审计台。
- 不用大量套话、重复标签和缺失提示干扰主流程。
- 不为某个 Run、Case 或 Branch 编写展示特例。

## Design Principles

- 主画布先讲清业务顺序和决策，技术记录只在下钻时出现。
- 数据库业务事实优先，运行事件只做补充，不把推测写成事实。
- 每张卡片只回答该阶段最重要的问题，完整原文放入 Inspector。
- 主 Agent 的前三阶段按“当前结论、形成前可见信息、明确理由”分层；运行中看过的信息不能自动写成已采用依据。
- 严格区分“主 Agent 直接读取”“评审 Agent 返回报告”和“仅按运行顺序关联”，评审 Agent 内部读取不得归到主 Agent。
- 创作目标显示当前数据库保存值并保留运行版本记录；实现规划显示当前规划，历史修订只在详情中展开。
- 所有 Agent 决策卡使用一个主结论、默认两个摘要、最多三个摘要；不同决策保留各自的业务问题，不套用同一组固定句式。
- 业务详情只解释问题、输入关系、决定、理由和结果；表名、字段名、内部 ID、Tool、原始 Markdown 和 JSON 统一进入技术记录。
- 评审建议与最终决定必须视觉和语义分离；多方案评审、整体评审都没有替主 Agent 做最终取舍的权限。
- “本次真实任务”来自运行事件；“当前版本规则”来自当前数据库或文件配置，不得称为当次运行时的完整 Prompt。
- 最终脚本表尊重已有业务表达，不为了“简化”丢失字段或改变语义。
- 相同交互在不同 Run 与不同屏幕上保持一致。

## Decision Relationship Vocabulary

- `主 Agent 直接读取`：同一主 Agent scope、`agent_role=main`、`agent_depth=0` 的真实读取。
- `主 Agent 收到评审`：评审 Agent 已完成并把报告返回到主流程。
- `形成前可见`：记录在决定前出现，但没有证据证明被采用，只能描述时间关系。
- `明确作为依据`：只有业务记录或运行记录明确表达采用关系时才能使用。
- `评审建议`：评审 Agent 返回的判断和建议，不等于主 Agent 的最终决定。
- `最终决定`：主 Agent 或当前实现方案内有明确决定权的 Agent 实际保存的取舍。
- `当前保存值`：数据库现在能够确认的结果，不等同于不可覆盖的永久版本。

## Accessibility & Inclusion

保证键盘可操作、明确焦点、减少动效支持、语义化表格表头，以及文字与背景的可读对比度。