# 别只记住最后选了什么，也留下为什么这么选。 | EasyNet

Source: https://easynet.run/cases/problems/keep-why-the-decision-was-made

[easynet.run · 全部问题场景](https://easynet.run/cases#problem-scenarios)

# 别只记住最后选了什么，也留下为什么这么选。

当初为了赶演示，你们选了一个临时方案。半年后助手看到“项目采用这个方案”，把它当成永久架构原则继续扩展。选项留下来了，交付期限这个决定性前提却不见了。后来的人只能继承结论，没法重新判断。

一份简短的架构决策记录本来就能解决这件事。团队已有这样的记录时，继续维护即可。EasyNet 的作用可以是让不同助手在需要时找到这些材料，不必把成熟做法重新包装成另一套知识系统。

通过 Context 关联决定与出处时，值得保留的是当时约束、主要替代方案、选择理由和确认人。例如，“本次演示使用本地文件，因为时间不足以接入数据库；多人同时编辑前重新评估”。这一段比孤立的“使用本地文件”更能指导后续工作。

这些理由需要参与者确认。摘要可以从讨论中提取候选内容，但一次成功运行不能证明当时为什么作出选择。接手者还需要获得这个项目的决定记录与出处的读取权限，不能因分享一条引用就开放整段私人讨论。没有留下原因的旧决定，应找负责人核实，不由助手补写一个听起来合理的故事。

新任务使用旧决定时，先比较条件是否还成立。现在要支持多人编辑，正好触及原先约定的复查条件；助手应提出重新评估，而不是自行推翻，也不是无条件沿用。这种条件连接与提醒需要在任务入口补齐，单有资料引用不会自动触发。

拿一个已经遇到规模变化的项目检验这份记录：新同事能否看出哪些是硬约束、哪些只是当时的妥协，以及下一步该找谁决定。保留理由并非为了把所有讨论存下来，而是让过去的决定可以被理解、被继承，也能在条件变化后被有依据地改变。

01

记录当时约束

演示期限不等于永久架构原则。

02

保留决定出处

理由、替代方案与确认者。

03

触及条件后复查

多人编辑前找负责人重新决定。

把临时选择的前提留住，条件变了才知道该复查什么。

一句结论补齐选择理由

简短的人工决策记录；review_when是提醒依据，不是自动触发器。
示例内容 · json

```
{
  "decision": "local files for the demo",
  "reason": "database integration would miss the demo deadline",
  "alternative": "shared database",
  "review_when": "more than one editor needs to write",
  "confirmed_by": "<actual decision owner>"
}
```

预期结果：后续多人编辑需求会指向复查，而不是盲目继承本地文件方案。

接入时的检查项

决定可回查其理由和确认者。

条件变化时能识别需要复查的记录。

过期决定与现行约束在交接中明确区分。

源码与接入资料

[上下文接入指南](https://easynet.run/docs/connect/context)