Nicasia Digital Solutions一个房屋项目，146 户：114 户在排屋中间，32 户在转角。每一户要装一套铁件：大门、转角户才有的侧门、栏杆，部分户型还有百叶窗。每一件都要走七个步骤：到现场量尺寸、订钢材、加工、打磨和打胶、喷底漆、安装、收尾补漆。
工人用手机回报每一步，界面有中文、孟加拉文和缅甸文。工人的应用跑在 Telegram 里，记录存在云端数据库，老板在网页驾驶舱上看得到每一栋、每一户，不用打一通电话。这套系统是我们为自己的金属加工厂做的，一直每天在用。
2026 年 9 月我们学到的，大多来自四个错误，四个都是我们自己犯的。
一栋 10 户，清单就只能有 10
9 月 4 日，老板打开厂内派工那一屏。「几件」的清单写着 1、2、3、4、5、6、8、10、12、20、30、50。他选的那一栋 B12 只有 10 户。那一项是百叶窗，这一栋每一户都要装，所以上限就是 10；换成只有转角户才装的侧门，上限只有 2。
他问：为什么这个清单不是照数据库算出来的？他说得对。清单要的每一个数字，数据库里本来就有，工人回报完工的那一屏也一直照它在算；只有厂内派工这一屏，用了一份「差不多」的固定清单。
清单错比画面丑严重得多，因为人会照着它做事。照那一屏开一张 30 件的单，厂里就会切 30 件，钢材也会照 30 件去订。
当天改了三处：
- 选栋只列出装得下这一项的栋，名字旁边写几户：「B12 · 10」。
- 件数的上限，照这一栋、这一项在记录里的数字。
- 后台自己挡掉不可能的单。画面上的清单可能被绕过、可能是旧的，后台是最后一个能说「不行」的地方。
我们也把一句话拆成了两句。「算不出来」和「这一项不按户算」，以前在画面上长得一样，上限一格空白。这是两件不同的事，而且后一种很正常：帮别的公司做的活，我们的记录里本来就没有户数。现在画面会说清楚是哪一种。
总数跟件数一样要紧
同一天，把每一份清单都拿去跟数据库对了一遍，对出一个更大的数字问题。数据库写百叶窗装在全部 146 户；工程量清单（BQ）是合约自己的数字，写的是 70。差额 76，正好等于 A 型房的数目，而百叶窗只有 B 型房才装。
就这一格，让工人可以在根本不装百叶窗的房子上回报百叶窗，也让项目的总数里多出 76 份不存在的活。改正之后，项目进度一夜之间从 4.2% 变成 4.7%。没有人做得更快，是总数缩回了真实的数字。
进度数字要给客户看之前，先拿分母去对工程量清单，再让人看百分比。
两个画面各算各的，迟早会对不上
9 月 17 日，另一个项目的一位工人，做完了他那一栋两户里的一户，回报了，却报不了第二户：再点那一栋想加第二户时，画面反而把他已经选的清掉了。后台的数据一直是对的，陷阱在画面里。
修这个的同时，我们把每个项目都查了一遍有没有同类的陷阱，又找到一个老板没报的。工人的应用和老板的驾驶舱，各自用不同的代码判断一户装哪几样。百叶窗改成只装 B 型之后，应用按「每一户记下的户型」来判断；可是那个 146 户的项目，户型是按整栋记的，所以应用认定 70 户 B 型房一户都不装百叶窗，谁都报不了。驾驶舱那边有一行写死的判断，碰巧给了对的答案，所以看起来一切正常。
改法是一条规则，两边共用：一栋如果没有按户记户型，每一户就照整栋的户型算。上线之前，我们把驾驶舱对五个按户追踪的项目、每一户的判断全部列出来，一共 2,209 组「哪一户、哪一样」，改前改后对照。变动的只有那 70 户的百叶窗，驾驶舱上的画面一格都没变。那次比对现在成了我们留着用的工具。
旧画面会一直去打新的后台
9 月 4 日，后台回传的格式换了样：栋的清单从单纯的名字，改成「名字加户数」，新画面才能印出「B12 · 10」。新画面同时上线，我们也两边一起测过。
老板手机里跑的却不是新画面。他是从一则旧的 Telegram 讯息点进去的，Telegram 给他的是之前存下来的那一页。旧的那一页把新的回传当文字印出来，他清单上的每一栋都变成了 [object Object]。
什么都没当掉，所以才危险。我们的测试永远是最新的画面配最新的后台，现场的人不是。Telegram 只有在发出新讯息时，才会换掉那则讯息打开的版本。
从那以后的规矩：应用已经在读的字段，永远不换形状。新资料放进新字段；新画面读不到新字段，就退回旧的那个，并且说出哪一项它不知道。
买工地追踪系统之前，先问这五件事
- 清单从哪里来？工人和主管点的每一个选项，都应该照你项目的记录，按栋、按户算出来。
- 挡掉不可能的单的，是后台，还是只有画面？
- 进度的总数是不是照你的工程量清单算的？图纸和清单对不上时，谁来查？
- 有人打开旧版应用时，会发生什么事？
- 它分不分得清「不知道」和「不适用」？
现在我们也帮别的公司做这种系统，一样从他们自己的记录开始。私人诊断 会看你公司里的工作是怎么流动的。