为什么德小馨第一阶段只读

本文目录 · 5 个章节

把答案与业务动作分开

德小馨的公开定位是权限内只读查询与辅助分析，回答说明来源和数据口径，不直接修改业务数据。本文解释这个边界的设计意义；不是已经完成安全认证或实际可靠性验证的声明。^[1]

“帮我理解一条记录”和“替我改变一条记录”看似只差一个按钮，错误后果却不同。前者仍可能误导人，后者还可能把误解直接写进业务状态。将两者拆开，不是断言自动化永远不该发生，而是为不同风险设定不同的验证要求。

设计说明 · 不连接企业系统，三条分支不代表线上测试结果

先确认请求者与可访问范围，再从受控知识源检索，组织上下文，输出回答及引用。权限不应只藏在提示词里，等待模型自觉遵守；资料在进入回答上下文之前，就需要经过相应的访问控制。这里给出的是设计要求，而不是公开内部实现细节。

来源说明也应足够具体：回答依据哪一份资料、资料表达什么口径、何时有效。一个有链接的答案仍可能引用了不支持结论的段落，因此“附上出处”和“证据成立”必须分开检查。

说明性查询场景 · 输入不包含真实业务记录

证据不足不总是技术失败。它可能是资料没有维护，也可能是问题本身需要现场判断。把这一状态真实地呈现给用户，比掩盖缺口更有价值。但也不能无限制拒答：如果每个普通问题都被退回人工，工具就没有履行辅助任务。应记录可公开分析的失败类型，再改进资料和检索，而不是只调整语气。

只读系统仍可能泄露资料、引用过期信息，或让人误把一个建议当成事实。提示注入与恶意文档也不能因为没有写入接口就被忽略。NIST 的风险框架把治理、场景映射、测量和管理放在持续过程中；它提供思考风险的框架，并不替任何产品保证安全。^[2]

因此，这个阶段至少需要检查访问边界、引用一致性、资料时效和人工复核入口。反馈不应只收集“喜欢／不喜欢”，还应区分无资料、找错资料、误解资料和表达不清。不同原因需要不同改进。

当任务范围足够窄、输入可以验证、权限可独立执行，并具备确认、审计、幂等与恢复机制时，才有理由讨论受控写入。某些高风险动作可能仍需保留人工审批。它们是后续设计条件，不是当前已具备功能的路线图承诺。

我的判断是：第一阶段的价值不在“AI 做得越多越好”，而在让每一条答案都能被理解和质疑。先建立清楚的证据与责任关系，才有基础判断下一步自动化是否真的减少了工作，而不是把错误转移到更难看见的地方。