之前过来之后，弄BG的帐号体系，大致写了一票错误提示的文案，并且在文档前基本规定事项：数据提交前和数据读取前，必须先检查网络。否则提示："网络无法链接，请检查网络"

后来在重新整理购物车页面时， 便又忘了：诶当时整理出来的文案到底是怎么提示的来着？文案规划什么的还是统一的好吧。

另外一个事件，是商品筛选属性值的改造

【backgroud】大致是这么一回事儿。为了实现在搜索页面的筛选功能，我们在后台录商品的时候会有一个叫做“筛选项”的功能，筛选项所覆盖的范围（以衣服为例：颜色、面料、风格定义为筛选项）以及具体的筛选项的值（颜色里：白色、银色、玫瑰金、粉色...）在一个模块中录入，商品录入时如果选择了相应的筛选项并填写了相应的筛选项值，那么如果用户的搜索列表里有这个商品（a），那么商品a的筛选项范围和筛选项值会出现在筛选条件中

【出现的问题】后来，当用户筛选牛奶时，在一个叫做“包装”的项目下出现了以下筛选项：罐、铁罐、盒装、纸盒装、利乐装、200ml、250ml、1l。在纸尿裤下：盒装、280*150、270*110...  奶粉下：1-3个月、1-6个月、1岁以下、成人奶粉、也就是说：①选项本身重复（同义词：纸盒=利乐装） ②选项范围重复    ③无意义的选项：非典型选项例如280*150、

（附录：关于什么是无意义选项？并不是说数字乘以数字就是非标，比如床往往就只有特定的几个尺寸，所以某个选项是否”非典型“，主要取决于市面上的商品。一般来说：如果大家都通用的比如床的尺寸那就没问题。再比如苹果忽然增加了一个5.5寸，那么由于其本身的影响力那么这个选项请务必列出来）。

【问题的根源】：

①选项值本身是“称谓众多（雌性=母=女）”，（根源指数：level3）

比如有的认为盒装和利乐裝就是一个人对同一个东西称为不同。

②选项本身是有取舍的，而且该取舍具有灵活策略（根源指数：level5）

（——有取舍就意味：需要有取舍的标准，什么要？什么不要？特殊情况和紧急情况下怎么应变？取舍标准如何更新）

③权利责任分配问题（根源指数：level1）

一般来说，谁有责任谁对结果负责，那么这个人就有决定权。于是那么对于每一块后台功能，都应该在开发的时候去指定责任人、并由责任人来考虑：“该系统使用中可能出现哪些问题，这些问题分为哪几类？通过什么样的流程和标准去控制该流程”——简单来说就两件事情：①指定责任人  ②制定流程&标准。

扩展一点来说，这里还可以细化出以下属性：

1.时间表（当涉及多人合作时）：①比如对于一个开发项目来说这个是xxx在xxx日期的时候交付xxx，②对于非固定时间的事件来说应当是：小A如果想要做xx事情，应当在提前N个工作日告知B，以便B能较为宽松的安排好时间，确保在deadline之前能够完成

2.具体分工和流程：

这个是为了保证如果随便换一个人，该同学也能一目了然的知道接下来要做什么，以及每个事情应该找谁

3.检查项：

检查项这个事情在我看来，更多的像是一个简版的“操作指南”。只不过在这个指南中可能并没有说你应该如何如何做，而是换了另一种方式：“你的灯还亮着么？”（来自某书的梗，）——检查项的意义在于：“我告诉你，这些事情是必须要做的不然会完蛋哦！你check一下”，或者“嗯除了这些必须的事情之外，剩余时间可以在以下项目上下功夫：a...b...c...这个我提醒你了哦”——所以检查项更多的来说是：“我把你必须做的、最好能做的、将来可做的事情列出来。如果你没做的话这个责任算的了啦不许说不知道哦”

结论：

1.对于任意需要工作人员输入的地方，都应该考虑：该输入框内的东西是否为标品（比如：商品品牌、品牌logo这种规定死了的，就可以是标品），如果不是标品则应该考虑给非标品制定一个指定的规范（甚至：如果该规范不容易执行则应考虑在录入程序上控制、或者在录入权限上限制从而保证单个责任人）

2.对于任意需要用户对信息进行“整理”（这样就是：排除掉自定义的内容比如评论啊，文章啊等）。都应考虑当用户按自己的“奇怪的标准”来发布东西时，要如何处理掉这些无用信息（例：举报、知乎的公共编辑计划，或者smzdm的“仅自己可见，后编辑审核”的方法）

3.通过指定人员负责的方式，通过明确责任权利的方式——来保证事情的正常进行，或者出了事情能有相关人员承担责任并且在问题之后反思总结或者修正规则，另外就是不要指着几个人一起复杂就谁做谁负责，不然俩和尚就没水喝了

4.通过deadline、事件必须提前xxx天通知、xxx事物的指导流程、xxx的事件检查项等多重方式来对事情进行限制，从而更好的监控该事物