复现一个熟悉的产品，很容易从页面开始：把菜单、表单、状态和按钮做出来，再把它们连成流程。但界面相似，不代表理解了它背后的判断。
我参与过企业客服 Agent 项目 AgentOne，质量治理是其中的工作重点。后来做同名个人版本时，我选择围绕这部分机制展开。本文沿用博客名称 ResolveAI，公开讨论个人版本的设计，业务资料使用模拟内容。
需要重新梳理的是：什么情况下算处理错误，应该检查哪一段过程，改动之后怎样继续验证？
先选问题，而不是复制整个系统
企业项目包含很多相互配合的能力，个人复现不必承担同样范围。起点应当是一个足够清楚的问题，而不是完整功能清单。
质量治理里的问题可以拆成三层：业务要求是否明确，运行是否留下足够信息，确认问题以后能否纳入后续检查。
只有日志而没有标准，不知道偏差在哪里；只有标准而没有过程，不知道为什么偏离；只有一次修复而没有后续检查，同类问题仍可能回来。
场景页面历史截图：先按业务任务组织预期，再进入具体配置。
因此，复现范围可以围绕这一组问题收敛。身份系统和工具先使用模拟适配，处理依据与对象关系则需要写清楚。
从经验中抽取可复用的关系
一个具体问题通常同时包含客户表达、业务规则、接口表现和处理习惯。直接照搬案例，容易把偶然条件也固化进设计。
我更关心哪些关系在不同场景中仍然成立：
| 需要保留的关系 | 个人版本中的表达 |
|---|---|
| 处理对象与客户诉求 | 明确对象来源，缺少信息时追问 |
| 规则与当时业务状态 | 将规则版本和业务快照关联到运行 |
| 动作与实际结果 | 分开保存工具回执与业务 Outcome |
| 问题与后续改动 | 调查、复测资产与配置修订相互关联 |
退款案例可以说明对象和状态，政策咨询可以说明资料适用范围，人工转交可以说明责任变化。它们用于解释不同关系，不是质量治理的全部范围。
保留“不继续”的路径
一个流程如果只有成功分支，很难表达真实判断。
对象不明确时应追问；结果未知时应保留待核实；人工确认误报时不进入修复；配置变化以后，旧结论需要重新检查适用性。这些分支决定了用户能否正确理解当前状态。
尤其是误报：如果出现异常自动等于需要优化，就可能对正确动作做出修改。调查需要允许结束于“处理符合要求”，而不是每次都以生成改进任务收尾。
这也影响数据建模。调查结论不能覆盖原始运行，编辑对话不能撤销已发生的业务动作，后来修改规则不能改写历史时点。每个对象都需要明确职责。
机制解释图：运行保留过程，调查形成判断，复测承接后续检查。
用操作问题检查设计
站在操作者的位置，可以连续问四个问题：
- 为什么会看到这条记录？
- 应该先看什么？
- 哪个结果支持当前判断？
- 做完以后，下一步在哪里？
技术上可以分别有配置、Run、Case 和 Release，但用户的任务是找到问题并决定后续动作。如果必须记住很多编号、反复切换页面才能拼出结论，就需要重新组织入口。
合理的界面让对象出现在恰当的位置：先看到当前任务，再按需要展开配置、调用与历史。技术深度仍然保留，使用者却不需要先学会内部数据模型。
把工程取舍与问题放在一起
本地记录与模拟业务适配，便于查看同一组对象在不同阶段的变化。它们适合研究状态关系；多实例运行、身份认证和真实工具接入需要另外的实现。
重要的是保持接口分工清楚：客户身份与消息内容分开，能力选择与执行授权分开，可编辑对话与已保存运行分开。以后替换业务适配或存储时，这些关系仍有可以保留的部分。
复现也会产生新的设计，不必逐项对应原企业系统。客户模拟入口与导览页围绕个人版本的使用需要组织：前者让自然表达进入共享执行链路，后者帮助读者从业务问题找到对应功能。
什么情况下值得继续扩展
增加功能前，可以先问它是否改变一个重要判断。
新的知识能力，是否需要不同的资料范围和生效规则？新的业务动作，是否引入对象归属或重复执行风险？新的运营入口，是否帮助用户找到判断依据？
如果只是因为别人也有这个功能，可以先放一放；如果现有对象无法表达新问题，才需要扩展契约或流程。
同样，复现阶段先把操作路径打通，再考虑实际使用中的收益。处理效率、运营采用和业务效果，需要在对应环境里观察，不能直接从功能是否存在推算。
结语
个人复现最有意思的部分，是把熟悉的工作问题重新拆开：哪些是场景特有的，哪些是普遍关系，哪些只是过去习惯的做法。
围绕质量治理，我选择保留处理标准、执行过程、人工判断和后续验证之间的关系。页面与技术栈承载这些关系，却不是复现的终点。
当一个具体案例能被解释清楚，同时这套方法还能容纳另一个场景，复现就开始从功能重做转向设计积累。