产品治理

为什么系统不会在您不知情的情况下改变行为

一个决定销售团队把时间花在哪里的系统，可能以三种方式毁掉运营：让不该有权限的人获得访问权、不打招呼就改变标准，或抹掉已发生事情的痕迹。本页说明针对每一种情况现有的防护措施。

权限不等于隐藏按钮

在界面上隐藏一个选项并不能阻止任何事——只是让人不容易找到它。在 Stonen 中，执行拒绝的是服务器：界面隐藏某人不能做的操作，是因为服务器本来就会拒绝。

对贵公司的运营而言，这意味着销售人员即使绕道也无法操作他人的客户组合，而负责集成的技术角色看不到价格、利润和客户组合。

“谁能做什么”的权限表由代码生成，而不是手工编写。手写的权限文档会悄无声息地过时；而这份权限表一旦与代码不一致，生成器就会报错。

系统不会自行发送消息，不会自行成交，也不会自行更换商机的负责人。它负责准备、解释，然后等待。

经理在自己的客户组合之外操作时，必须填写原因，不会更换商机的负责人，负责的销售人员也会收到通知。设置这一例外是为了不让经理被卡住——而且它是可见的，不是静默的。

原始推荐与人的决定一并保存，即使两者不一致。正因如此，事后才能追问：遵从或违背系统的建议，到底值不值得。

每一轮推荐都会保存当时已知情况的快照：石材、纳入考虑的客户范围、证据和所采用的策略。之后才出现的结果不会回写进这份快照——它们从外部与快照关联。

这避免了最容易犯、也最难察觉的错误：用今天的规则重新计算过去的推荐，然后得出系统一直都是对的结论。

在实践中，正是这一点让我们在六个月后能够诚实地评估引擎本身——也正是这一点让我们能够坦言：它还没有接受过这样的评估。

优先级策略有版本管理。更改队列的排序标准，是一项经过记录和批准的变更，而不是某个周一突然出现的参数调整。

有三套统计机制并行运行，不触碰团队正在使用的队列，目的正是在做出任何更换之前先进行比较。如果其中任何一套出错，系统不会发布部分结果：已知的队列照常保留。

在没有经过训练、评估和批准的模型之前，“学习”模式会被系统拒绝。这是代码中的一道锁，而不是写在文件里的一个意向。

产品的每一次变更在发布之前，都要经过一整套自动检查：类型、代码规则、超过 1,500 项测试，以及一套在真实浏览器中打开系统、重走主要流程的测试套件。

每个已发布的版本都带有其所含代码的标识，回退到上一个版本只需几秒钟，流程有文档记录，并且已经实际执行过。

测试数量并不能证明质量，这里也不是要把它当作证明。它带来的是另一样东西：有人改动某处时，坏掉的地方会在影响贵公司运营之前暴露出来——而不是之后。

改变产品行为的决策都会以书面形式记录，包括日期、促成该决策的问题以及被放弃的备选方案。当一项决策被替代时，旧决策不会被删除：它会被标记为已替代，并指向取代它的新决策。

对系统使用者来说，效果很简单：“为什么是这样运作的？”这个问题的答案是存在的、可以找到的，不需要去问某个人。

这份记录属于产品开发的内部资料，而不是合同承诺。它保证的是理解上的连续性——而不是客户的一项权利。

页面更新于 2026年9月22日.