ＢｕｓＱｕｅｒｙ-公交宝典

话说当前，图像识别是热门技术，有很多场合要用到。列举一二如下：
１，网上搜索，我要搜索所有“关咏荷”的图片或者我要搜索所有包含一张桌子的图片，搜索引擎如何在照片中发现关咏荷或一张桌子？
２，工业应用，流水线上，我要在所有的物件上贴一个标签，但流水线上的物体在运动过程中可能没有那么固定，位置有旋转，如何让标签贴到正确的位置？可以用图像识别技术，在贴标签之前旋转物件直到图像识别软件认为角度正确为止。
３，警察查人，可以用火车站的摄像头识别每位进站人员，把亿们的脸与通辑犯的脸进行对比，反化妆。
４，网络反黄，现在黄色图片无所不在，许多门户网站都是毒源生产地，如果开发出一款软件能自动识别黄色图片，从而不矛显示，则对于青少年的健康成长很有好处。

总之，这个技术是很有前途的。哪个公司先攻克这些技术，谁就能发大财。我对这些技术有些初步的设想，把它写了下来，希望能给将来作点参考。不过，估计这辈子也用不上了。除非我解决了衣食住行问题，可以没有生活压力地编程。

首先是这个领域的模块细分，然后，设想其中一些较易市场化的部分。

1,色彩分析组,可以分析出是否黄色图片,因为黄色图片包含更多的皮肤色彩.皮肤的色彩随拍照环境和相机的因素有不同,但毕竟在一定的范围内.进一步处理,可以分辨是否是风景摄影,是否是卡通图案,卡通图案和真实照片在色彩的表现上肯定不同.
2,形状分析组,每种物体都有不同的形状,首先得勾勒轮廓.然后要模糊计算,从而得出画面里有一个人,一张桌子等的结论.如果形状严格固定,如流水线上对操作对象的识别,可以比较标准图象和摄得图像进而调整物体的位置和角度,进行准确操作.
3,关键点分析组,每个人的脸看起来都很象,但毕竟有不同,如何在众多的图片中查找某个人,也许可以用关键点来分析,如每个人的两眼之间的距离,五官轮廓都不一样,两眼和脸面的对比度是很强的,所以人眼是很容易识别的.
4,三维分析组和动态跟踪, 这一组是针对移动的图像来说的,捕捉屏幕上的改变的部分,则可知一个动态的物体的存在,如果是一辆车,随着车的移动,车在屏幕上的形状也在变化,有可能依据车的这些图像计算出车的三维形状来.这里有另一个小分支,针对屏幕上的动态部分,把它设定在拍摄的中心,这就是动态跟踪.
5,测试等级准备组.这一组负责准备各组阶段测试用图片,凭感觉易识别的图片放在前阶段. 图片要依据各组侧重点的不同选取.

附,每一组都会依据一些基本的图像算法,如增大对比度,取轮廓,直方图分析等等.但每一组的侧重点不同,对这些算法的精确性有不同的要求,先期可以不考虑cpu速度,用开源的一些库,只要保证判断结果的正确性. 后期每一组在完成自身功能的前提下,还要对算法进行优化和加速,舍弃一些精确算法,也许会有一些误判也行,要求是速度快,适于在嵌入式产品上应用.前期获利也许还是在嵌入式的版本上.因为一些工业应用的需要.

随时都会有一些想法, 在后面补充.

百度图像搜索依据的是网页上的文字,找某个人,则出现众多相似图片,其实如果能搜索出图像中的人的话则多好啊.刘若英的脸,为什么人眼一下子就能分辨出来,不管她怎么化妆戴不戴墨镜?电脑不能做到吗?
如果在火车站飞机场安装摄像头,嵌入的软件能够把在逃嫌犯的肖像和进站人员进行快速比对,不是能够随时抓捕嫌犯吗?
进一步联想,未来的机器人都安装上机器视觉,它能识别不同的人和物体.它们的机器智能不断提高(因为全球有许多程序员在把思维程序化),而它们的运算速度和储存量都远超于人,最终,人们什么都不用做,因为机器人不知疲倦不会受伤,可以自动行走,操作流水线,还包括做家务.人类只要学习怎么给机器人编程序就行了.
有这么多的入口,单个人力是无法做好它的,单个人如果开始的话,可以从这样的编程练习开始:一张jpeg格式的照片,把它缩小后,程序还能识别它们是同一张图片.
我感觉这里面都有个模糊匹配的意思,不知道”混沌学”和”模糊学”是干什么的,对这个算法有没有指导意义.

中医脉象仪计划

古中医对脉象与疾病的对应关系是很明确的。用脉象仪采集病人的脉象，把脉象公之于互联网，所有有经验的中医都可以为他（她）诊断。这种设备一旦应用，势必造成全世界对中医的祟拜。脉象采集设备并不需要智能诊断疾病，它只要把脉象采集成直观的波形就可以了。电脑端软件，可以逐步地加强诊断水平，是一个漫长的过程。在电脑端软件还没有很“智能”之前，可以用人工对波形进行判断，得出诊断结果。中国古代出了许多神医，他们说的话非常灵验，如检查到肾脉‘伏’，他们说“必小腹疼”，这是非常准的。中医的光芒在世界照耀起来的时侯，海外会对中医和中国改观的，会更坚信中国文明古国的坚实地位。
鉴于中医治法千变万化，中医脉象仪不包含“开处方”部分。第一步是要把脉象数字化，便于网上流通，让千人会诊。第二步是把古中医的脉象诊断编入PC平台程序中，此程序可以分析脉象波形，并得出病人所患何病及何处何种不舒服的结论。这一步需时较长，一定要稳扎稳打，不能出现错误的判断。可以先让程序学会判断一些很容易判断的。这个程序的难点是分析脉波，得出“浮滑沉伏涩弦数促石毛…”等脉象。即使是最著名的中医，要分辨脉象之间的细微差异也是非常困难的。中医要从患者的症状对照脉形，仔细体味各种脉形的细微差异，使用反推的方法了解各种脉形。举个例子说，中医从脉象或手感上看到肾脉很深，用手使劲按下去才会感觉到肾部脉搏的跳动，这个脉是“沉”还是“伏”，看他（她）的症状，如果小腹疼，说明是伏，因为古中医说“尺脉伏，犯小腹疼”。否则就是“沉”。编这个软件的程序员要经过几年的中医的学习，分析大量患者的波形，不断提高自身脉象分析水平，才能把这个程序编好。中医脉象采集仪不应该成为脉象分析的阻碍。程序员要先把几种显著的脉象从手感上掌握。然后看肪象仪采集到的波形是否有足够的差异度来分辨这几种脉象，如果不能，则要适时地调整脉象仪的设计。当脉象仪基本定形后，就不要轻易改变脉象仪的设计了，宁可增大软件分析的难度，也不要造成不同版本脉象仪采集到不同版本的波形。脉象仪一旦定版，势必要在全世界范围内推广，PC端智能分析软件也逐步完善。我希望看到的是PC端软件不断升级，但脉象仪采集脉搏的特征还是保持原来的样子。否则前一个版本的患者自行采集的波形，因为版本不兼容的关系，不能被新版AI软件分析，则会造成误诊，而且，人工检视波形，也需要波形固定，如果用两个版本的脉象仪采集到了两个不同形状的波形，中医也很难学习“浮滑数石毛沉弦…”与波形的对应关系。
当前一些所谓“脉象诊疗仪”的现状是：脉象诊疗仪捆绑了脉象采集系统和智能分析系统，甚至还捆绑了“开处方”系统。结果是把脉一按，出来一个处方，处方的有效性有多高，我们从中医的疗效就不难猜到了。
软件的智能程度的增加方式让我联想到了google翻译，google翻译没有把每个单词对应的释义作为翻译的手段。它只是简单地把所有的已翻译网页拿出来对比，哪一篇更象当前要翻译的文章，就把那种翻译作为结果。也就是说，结果是搜出来的。如果我们的脉象仪采集到了大量患者的波形，也积累了大量的对应症状和病名。以后碰到波形，也可以采用搜的方法查找最相近波形，然后直接把相关症状作为结果呈现给使用人。
中医一般用三指分别采集患者左右手寸关尺三部位的脉象，简而言之，此三部对应着人体上的六个不同部位：心肝肾肺脾“三焦”。又有，寸与关之间，或关与尺之间等，又对应着其它的小部位。独立分析这些小部位却不是大医所为。大医首先要把握三部的整体趋势。古中医言“有根无叶愈，有叶无根死”指的是不同部位在脉象中的重要性，又言脉无胃气死，指的是脉象整体上要给人一种“濡动”的感觉，如果没有，三部脉独立时再正常，也是要死之脉。假如脉象仪的传感探头类似人的三指的话，这三指放置的位置也是与采集正确性密切相关的。中指本要采集关部的脉，如果你把它放在病人的其它部位了，采集到的结果就是错误的，会导致误诊。我们可以培训用户，让他们学会正确的放置方法。传感探头可以不只三个，在原有的三个之间插入多个，则采集到的结果更丰富，而且，实际上，脉搏涌来，探头按从里往外的顺序探测到脉搏，宛如海浪涌向岸边、再退去。也象海浪一样因人而异，有的浪头在中间就沉下去了，有的浪头一直涌到岸边，这些与人体的病有很大关系。所以更多的传感器探头，会有利于精细分析。指头感受到的是一个平面的压力感觉，包含众多的点，甚至可以认为是一个球面，但探头感受到的是一个平面上所有点压力的平均值，要不要安排双排的探头是需要在实践中探索的事情。在满足分析数据的前提下，探头尽可能简单是宗旨。探头越简单，操作起来就越简单，探头越简单，脉象采集仪的硬件电路越廉价。
在试制之初，先假定脉象仪的探头是单线多探头，大约含十个探头，其中一个探头必须对准患者的“关”部位。探头采集到的是探头上的压力变化，探头在Y轴上排列，压力在X轴上变化。一脉来，迅速从左端推到右边。恢复平静，再脉来，又从左边推到右边。由于脉搏跳动是很快的，所以你看不到从左向右推的过程，但我认为既然手指可以感觉得到，那么慢镜头放脉象波也应该能看得出来。在脉象图上，要标明“关”所在的位置以及三个部位大致的分割线，以便判断生病的部位，其它部位也是。脉象仪采集的点是有限的，但在X轴上排列的点要很多，才能显示成一条平滑的曲线，可以用计算的方法把中间的点都补上。
中医按脉时会根据脉的深浅在指头上使用不同的力，脉有浮沉，就是指脉的位置的差别。指的力道不同，感受到的脉的强弱是不不同的。如何真实的反映脉的强弱及三部之间的对比关系。脉回去之后，手指对皮肤的压力可以看作是手指的力道，就让这个力道相等，那么当脉来的时侯，对这三部的脉的感受就是在相同的力道下取得的。然后力道不应该只有一种，应该有至少三种力道。在脉去的时候测量探头的压力，这就是力道，必须自动移动探头使得所有探头的力道相等。在脉来的时候读取压力，就是脉的强弱了。在不同的力道下读取脉压力，测出几组动态数据。力道分为轻中重三组，每组有个大致的力道，要不要根据人的肥瘦的不同调整这三个数据，就看以后的实验了。这三组数据可以同时观看，也可以分开观看，可以同时使用慢镜头，可以调整这三组数据的相位，使它们大致同步。但这三组数据毕竟不是同时采集的，心跳频率有没有改变都是说不定的，所以不太可能每次脉搏都同步，而且中医中有所谓代脉，即五来一往，指脉连来五次才回去一次。当然这里的“来往”不是指平常的跳和不跳，而是一种感觉，来到的脉是否真的象潮水退潮一样完全无力地回去了，还是意欲未尽地留在原地。前期只有人工检视才能体会到这种脉。也就是说脉的变化很多，不一定会同步。脉象仪采集的结果是不是会比中医的手指差很多？不一定哦，电脑的灵敏度其实比手指强很多，用图像的形式直观地呈现出来有可能令异常之处更显眼。编制程序之初，要采集众多的无病的人的脉搏，各种年龄层次都要有，但以十七八岁常常运动的年青人为主参照，因为这些人可以肯定是没有病的，有些年纪大的人虽然表面看起来没有病，但实际上已经是亚健康状态或是潜伏着很严重的病，这些虽然用医学仪器检查不出来，但在脉象上却是可以检查出来的，只要医生足够高明。这些参照脉的波形熟悉之后，也许很容易发现到一些异常的波形，因为图形化的东西真是太直观了。

“蚁兵”信息共享系统使用方法：
　　本信息共享系统以提高企业协同工作效率为目的，以用户自定义的复杂程度满足用户从简单信息共享到任务自动分配的全方位应用，以简单抽象的逻辑提供即学即用的傻瓜式平台。
　　信息共享系统主要包括两个部分，一个是信息发布平台，一个是任务自动分配平台。使用此信息共享系统的用户为有效帐户，登录后方可使用。所有用户都属于“部门”，用户权限按所在部门的行政等级处理。下级部门的权限由上级部门分配，并且上级部门给下级部门分配的权限只能是自身拥有的权限。权限包括但不限于:浏览其它部门信息、发布信息等。
　　信息发布平台提供快速的信息共享服务，类似论坛。任务分配系统的进度或问题也会由系统自动作为“新闻”信息发布到信息发布平台，那是在定义了任务与部门之后的事。用户发布的共享信息只是一般信息，它没有转变成任务系统的“需求”之前，不会自动进入任务分配系统。发布者可以把信息转化为“需求”。“需求”代表了一个部门发布的任务，它应当由其它提供相应“功能”的部门来完成。
　　蚁兵信息共享系统初始没有任何功能，你看不到“人力资源”“财务”“客户关系”“物料采购”“订单”“生产单”等模块，使用者必须首先设计它。首先要定义顶级“需求”（需求0），这是所有部门协同工作的终极标靶。然后定义“需求0”的依赖“需求”（需求1），多个，……然后定义部门，“总经理办公室”可以算是顶级部门，接着定义旗下“人力资源部”、“财务部”、“研发部”、“工程部”等部门。并且给每个部门定义“功能”。“功能”是与“需求”对应的，每一项“功能”必然对应着一项“需求”。你会注意到0级需求是由下层的某部门来提供的，而下层部门必然提出一些“薪金”及其它协作等需求，也就是1级需求。1级需求有另外一些部门来完成，而它们同样也有它们自身的需求。可以用这种依赖关系来同时创建“部门”和“需求”及“部门的功能”。：）最后别忘了创建总经理办公室，这个部门的大部分功能其实已经被本系统代替了，应证了“你什么都不会干？那你当领导吧！”的哲言，可以这样说，当应用了本系统后，总经理办公室可以撤消了。
　　首先来试验一下“信息共享平台”，用户发个帖子试试，帖子的署名不是一般论坛所谓的用户名，而是“**部门**人”。
　　

蚁兵信息共享系统是一套独具特色的信息共享系统，其灵感来源于汶川大地震，在大地震的救援中，身为总指挥，事无巨细都得操心，难免会造成偶尔的疏漏。还有，从前线传来的一个要求，在广播、电视、电话、口头等多种渠道中传播，后方众多单位立即行多准备相关物资，可是你是否会想到物资已经重复。一个共享的信息交流平台会使救援工作有条不紊地进行。由于网络资源的馈乏，此平台要设计成满足在极低的网络连通性及手机类弱终端条件下可靠使用的平台。也就是传递的信息流量尽可能少。另外，此平台要设计成极易使用的，突出关键功能，并且让此平台适用于各行各业。我努力把它打造为最易实施的开源ERP平台。我希望同诸多同仁一起努力，共同开创一个ERP的新概念。希望加入这个行列中来的朋友，把你已有的项目经历及自我评价发到我的邮箱，我会跟你讲解蚁兵信息系统第一阶段的实施细则。我计划用spring来架设框架。会有较多的网页编程。有j2ee或jsp经验的人都可以跟我交流。然后我们在某个开源站点把项目跑起来。

简化的蚁兵信息系统

1，部门和功能
2，底层部门的需求反馈给上级部门，依次递传。直到
需求被分配。上级可以给下级分配任务。当任务被分配不再上传。
3，所有人都可以修改功能，可以随时把功能分得更细。
4，当新的需求需要被分配时，相应的部门会闪烁（多个）。
5，部门信息发布区，可选择是否进入共享区，进入共享区的信息则同时在本部门和共享区出现。

细节：
1，页面布局，左边是部门，右边是“功能”。
2，每个部门都有任务列表，任务按优先级顺序排列。进行中任务排在前面。当一个某优先级的任务进入任务列表中时，它会依据它的优先级向上升，直到遇到一个同优先级或进行中任务。可以同时进行多个任务。
3，每个任务都有计划完成时间。随时可以设定从几天后的几点开始进行，经历多少小时后可完成。预计完成时间在某天的几点。任务进行过程中，可以随时把进度标示出来，软件依据已完成量除以投入的人力和时间，得到此部门的人均生产力。如果没有已成进度，即进度是零，则用预计完成时间作为估计参考。
4，每个任务都有一个直接相关的数字。如要完成产品多少个？一旦这个量词确定，则会一直伴随这个功能。修改功能必须把原有数字转化成新量词对应的数字，如以前用“个”这个量词，后用“箱”这个量词。
5，每个部门都可以修改自身功能。但不能修改其它部门功能。可以给相关功能细分。
6，当一个新的任务被提出时，软件会计算拥有相关功能的部门的剩余人力与劳动生产力的乘积，把任务按各部门的劳动生产力分配，建议各部门各分配百分之多少的任务。以让它们同步完成。领导分配任务时，可以同意此种分配，也可以直接给相关部门按百分比分配任务。分配之后，此任务进入相关部门的任务队列。
7，提供图示描述项目中的各功能的阻抗。
8，每个部门都有工作人员数，和总人数。工作人员数是指可投入的劳动力。

1，每个任务为中心
2，完成指定任务，被指定需要一些指定功能模块
3，功能模块是所有部门的属性之一。每个部门创建时，被指定它们的功能模块。所有功能模块在系统运行之前定义。可以以倒置的方式分析系统功能模块的划分。先分析核心任务的需求，然后把这些功能分配给
假设的某些人，然后，看这些人又需要什么样的功能来配合它们。每个大功能可以分割成很多小功能。一个部门既可以有完成一个大功能的能力，也可以同时具有完成此大功能下部分或全部小功能的能力。基于这样的假设：某部门既可以独立完成某个产品的生产，也可以把别的部门生产的半成品再加工成产品。
4，软件设计的原则是：高度的可设置性，部门是可设置的，核心任务的需求是可设置的，要求以信息共享为核心，系统功能是随使用者的不断更新的设计而细化增强的。刚刚运行的系统没有什么功能，只有一个信息共享功能，只有使用它的所有人共同努力，细致地设置它，它才会精确地按照人的意愿去服务，形象地说：它只是一个机器人，你教会它的东西越多，它越能干。这也是它比其它erp软件先进的地方。其它ERP软件都有陡峭的学习曲线，你公司原有的处理程序都要为了ERP改变。蚁兵让你按照你公司原有的操作流程设计它。对于任何人，它都是极具亲和力的。
5，每个部门可指定自身的功能，当上层一个新的需求提出后，此需求分配给服务于它这一层的部门，按需求的功能模块不同，分配给提供相应功能的一部分部门。这些部门，为了完成这些功能，它提出一些需求，这些需求被传送给提供此项功能的其它部门。每个部门都自动地接到任务。系统支持手工添加任务，一般由上级给下级添加。
6，每个部门，每个功能都有完成进度图示。软件必须自动分析任务之间的依赖关系，并能按照相关任务的进度调整自身的进度图示。进度图示用图形的方式直观地显示，性能瓶颈被警告出来。
7，每个部门默认登录后页面是自身部门的待完成任务。此种设计是节省网络流量，支持手机访问服务器和进行操作。
8，每个部门可以提示新的需求，每个部门可以主动领取任务。
9，按功能来划分系统的大模块
10，有可能以人为中心（部门）来划分模块
11，权限策略：
保密策略：发布的共享信息可以是公共的，也可以是指定的上级才有权力查阅，上级拥有下级的所有权限。下级的权限可以被上级指定。共享信息发布权并不是每个人都有，由上级设定。每条信息，可以由主动领取任务的部门标记为“处理中…”,完成之后，标记为“已完成。”
任务指定:上级可以把任务指派给下级。
12，有些需求是隐含的，如增加一个新部门后，这些人需要吃饭，睡觉，如何保证他们的基本生活。这些需求是隐含的，自动提出的。它们自动被指派给相应部门。这是可设置的，系统最初的状态是没有任何隐含需求的，随着核心任务的进行，设计人员发现其中的隐含任务，把它提取出来之后，让它在一定的条件下自动产生一些需求。所以系统最好支持宏指令。设计人员能用它产生一些隐含任务。
13，可以用一个xml文件描述系统的所有功能，和权限设计等。设计好的系统用一个xml设置文件就代表了。可见系统的高度抽象性，它可以脱离任何具体的环境。这种高度的抽象性使得在任何行业应用这套软件的使用方法是一样的。可以为各行业设计基本的xml文件，提供各行业基本的功能，以帮助用户快速应用。
14，可以方便地设计系统，从头设计一个系统应该最多需要一个晚上的时间。提供工具图示系统所有功能关系图，并能轻易地给某个功能增加依赖功能。
15，每个部门可能不只一个功能，如担任救人的军队可能同时能给自己补给。那么它的补给功能就不需要别人来完成了。
16，任务可以超额完成，如给前方运送了超过一月的粮食，那么系统应该把这部分作为特别低阻抗的状态，图形化地直观表现出来。这部分人员其实应该被分配其它任务了。
17，同一功能的模块可能必须指定不同的部门来完成。如同是运输需求，可能运往汶川的需求由济南军区某部来完成，运往理县的却必须由成都军区某部完成。
18，最低级别的信息是可以被所有用户看到的，但似乎所有的分析图表都没有定义权限。一般来说，下级的任务完成图表可以被上级看到。上级可以公布一些图表给指定下级用户。这就构成了新闻发布系统。上级给下级分配任务，这其实也算一条新闻信息，只要上级指定它的公开级别，它就可能对部分部门公开。任务完成信息也是新闻信息。还有，瓶颈任务变为非瓶颈任务也是一条重要的新闻信息。或者任务出现严重瓶颈也是一条新闻。
19，必须有共享文件系统，上级发布的相关文件给下级。文件有权限控制系统。
20，每个任务都有预计的完成时间。从任务开始执行计算任务的执行时间。这样可以预测未来时间里，任务的进行状态，瓶颈在哪里。任务是不是都有时间段属性？每个部门都可以并行运行几个任务。
21，还有，任务是不是都有时限属性，过了时限后任务可能已无法完成，如周二的午餐，时间到周三了，那个任务还能完成吗？还需要完成吗？
22，任务有优先级属性，分派之后，高优先级的任务应该得到提示，让执行者轻易发现高优先级任务，并能尽早完成。当然任何任务的优先级都是随着等待时间的增加而增加优先级的。如，第一批200件物料要生产，第二批300件物料要生产，另外还有一个高优先级任务。虽然高优先级任务优先级高，但第一批物料任务等待的时间最久，迫切需要生产，它的优先级未必会低于高优先级任务。这种要求的提出，是基于这样一种假设：前方需要运输物资和救援人员，救援人员的优先级会更高。物资任务可能执行三天，但救援人员不定期地随时都有可能派过来等待运输，那么，应该随时中断物资的运输而运输救援人员。高优先级的任务之所以有高优先级是上级分发任务时，根据此部门已有任务的比较作出的优先级排列。所以上级指派每个任务时都要给下级的任务排一下序。
23，每个功能都有唯一代码，必须有办法，让任务自动地被指派到相关部门。如果有多个部门拥有相关功能，任务自动被分配。分配任务按照每个部门的生产力。可见必须有一个参数指示每个部门的相关功能的执行能力。此执行能力既是一个估计数字，也是一个计算数字，系统从前几个任务的执行时间不断评价每个部门每个功能的执行力。
24，完成一个需求可以有不只一种方法。如完成一个部件的生产，可以用一种方法：独立完成这个部件的生产。也可以用另外一种方法：把部件的生产分拆成几道工序，分配给几个具有其中工序功能的部门来完成。
25，任务的受益方负责检验任务是否完成。如，运输物资是服务于前方救援部队的，前方救援部队负责在系统里更改此任务已完成。这是一条新闻信息。可以撤消更改。撤消更改是一条“更正”新闻。
26，每个登录者可以设定自己是接收所有的新闻信息还是和本部门密切相关的信息。这样可以节约通讯流量。
27，新闻信息是一个共享信息的主要方式，它的信息量不能太大，以免用户在大量的讯息中淹没。可以设定跟核心任务以下几级内的用户相关的信息在新闻信息中显示。一般来说，核心任务相关的新闻最重大。但如果某个下级部门的新闻造成了核心任务的状态发生了大的改变，则这条新闻也是重要新闻。如某个高阻抗任务完成了，核心任务立即容易执行多了，那么那个新闻也应该出现在新闻信息中。
28，一般隐含的需求自动分配到其它部门。非隐含需求先被提交到同级部门，看同级部门能否在规定的时间内完成此需求，不能的话则交给上级部门，上级部门经过批准发布，此需求在上级同级部门中被分配，不行的话再提交到上上级。
29，只有最高行政长官才能设计隐含需求，最高行政长官可以把此项权限授予其它用户。
30，对于有设计权限的人来说，每个“部门”、“功能”、“需求”都是可以轻易改名的。系统要给有设计权限的人最大的设计方便。
31，除了系统自动分配任务以外，具有适当权限的人都能随意修改任务。上级可以修改下级的任务。但同时会给上上级发一个通知，上上级如果不同意，只要签个不同意，则修改被放弃，依然启用任务。只有还未完成的任务需要签署，已完成任务则不会显示签署选项。
32，人工的操作：如修改设计、任务下达、修改任务、任务完成、严重瓶颈等，都要作为任务的进度日记被写入日记系统，这些信息是被分类的，以便于快速找到某个信息。
33，以图示化信息显示项目进程中的瓶颈。