#在进入实现前评审一条知识工作流

让知识持续可靠 · 先确认用户结果，再开始实现

这不是维护者的发布清单，而是采用团队在把一条知识流程交给实现前的共同评审。它让业务使用者、资料负责人和集成方确认：未来实现到底要兑现什么，哪些问题仍没有准备好。

#评审时只问用户结果

#用三个问题决定是否进入实现

1. 能否让一个新加入的业务人员判断答案是否越界？
2. 能否让资料负责人说明一份新政策何时会影响回答？
3. 能否让集成方实现后用真实场景证明“有证据”和“资料更新”都成立？

有任何一个问题无法回答时，结论应是“返回文档补齐”，而不是“先写一个最小接口”。接口越早被固定，越容易把不完整的用户理解变成长期兼容负担。

#三种评审结论

#评审记录应保留什么

记录业务语言的决策，而不是内部实现猜想：问题卡版本、知识空间边界、主证据列表、样例回答、更新演练结论、能力缺口和明确的验收场景。这样未来无论采用何种 adapter 或 API 设计，团队都能检验它是否仍服务同一位使用者。

下一步：查看 0.x 目标行为合同。