Architect 方案设计对话样例

本文给出一份偏 Architect 视角的成品对话样例，重点展示怎样把系统边界、契约、兼容性和实施风险整理成可执行方案，而不是停留在概念描述。

1. 场景

• 任务：审批记录查询能力准备进入设计拆解
• 当前输入：需求范围已经确认，需判断接口契约和 overlay 候选项
• 目标：形成可交给研发和 QA 的结构化方案

2. 用户怎么说

请以 architect 视角处理当前任务。
输出：系统边界、接口契约、数据约束、主要技术风险、是否需要 custom overlay。
如果需要 custom overlay，请区分候选项和正式启用项。

3. 期望结果长什么样

系统边界
- 本次只新增审批记录查询能力，不改流程定义和历史数据
- 前端消费查询接口，后端负责权限过滤和分页

接口契约
- 入参：订单号、审批状态、开始时间、结束时间、分页参数
- 出参：记录列表、总数、分页信息、错误码

数据约束
- 审批状态字段保持与现有运营口径一致
- 分页参数兼容旧客户端默认值

主要技术风险
- 若权限口径和现有查询接口不一致，可能导致结果偏差
- 若字段命名调整过大，旧客户端兼容性会受影响

company 判断
- 私有流程引擎：候选，原因是任务涉及审批状态语义
- 私有权限中心：候选，原因是任务涉及权限过滤
- 正式启用：本次不启用，原因是未进入流程运行态和权限中心正式集成

实施建议
- 先冻结字段口径和权限边界，再进入实现
- QA 需重点验证兼容性和权限场景

4. 不合格结果通常长什么样

大概加一个查询接口，权限再看。

这类结果的问题是：

• 没有接口契约
• 没有兼容性约束
• 没有 company 判断

5. Architect 在对话里最容易漏什么

• 错误和异常路径
• 兼容性与迁移说明
• overlay 候选项和未启用原因
• 交给研发与 QA 的明确关注点

6. 继续推进时怎么说

当设计结论形成后，下一句通常是：

请把上面的方案整理成可直接进入 /handoff 或 /team-plan 的内容，包含接口契约、风险、技能装配判断和实施建议。

与这些文档配合阅读：architect-daily-operations.md、system-architecture-design-walkthrough.md、api-design-evolution-walkthrough.md