甲方说「我要一个能看数据的平台」——这句话里没有一个字能直接变成开发任务。
我的工作是从这句话往下拆：谁会用、他现在怎么干、卡在哪一步、系统只该改哪一步。拆完的结果必须满足三件事：甲方看得懂业务，监理查得到依据，开发照着能写。
「能看数据」最后拆成 18 个子系统：固定源、水环境、固危废、机动车、清洁生产、温室气体、生态智脑、数据湖……每个子系统再拆到功能点和字段级数据字典。拆得够细，供应商才知道边界在哪，验收时也才有话说。
一个省级平台从来不是一家公司做完的。国企的身份让我坐在总集成方的位置上——我不写代码，但我决定了代码之间怎么接。
最难的不是技术，是让两家在投标时互相压价的供应商，在交付时按同一套接口干活。我的做法很朴素：开工前把入参、出参、异常码定死，双方签字；所有人共用一个联调环境；每个问题单只有一个责任人。
外地供应商现场从 9 人缩到 2 人，本地供应商人员流动高，两家还在竞争中合作、偶有推诿。我管不了他们的人，但能管住接口和验收标准——最后 3 大平台 9 个系统还是按时上线了。
数据报上来，最危险的不是数字低，是数字看起来还行。
工会项目上线后，会员录入完成率 83.3%，看起来是「再催一催就好」。但同一个看板上，工会组织数录到了 111.9%——超录了。超录不是效率高，是同一个基层工会在不同层级被各录了一遍。这个判断改变了后面所有工作：不是催进度，是先去重、统一口径。
会员缺 16.7%，组织多 11.9%。如果只盯完成率，会一直催基层补录；实际根因是采集规则没对齐。改规则比催人有用。
现在每个方案里都要有 AI。大部分是把聊天框塞进页面，然后没人用。
我的判断标准是：这个环节是不是「人要在很多材料里找答案」。是，模型有价值；不是，加个模型只是加了个故障点。在二期规划里，我把 AI 收拢成一个能力基座和知识库，让各业务系统按需调用，而不是每上一个系统就重买一次。
法律咨询、心理关怀、疗休养推荐这几个场景适合用模型；资产台账、绩效打分不适合。分清楚这两类，比接入什么模型更重要。
系统验收通过，不等于有人用。这是两件事，很多人混在一起。
工会平台过初验那天，业务部门的使用意愿还是很弱。原因不是不好用，是「用了没好处」。我把它当增长问题做：先找一个职工愿意主动打开的理由——普惠服务。发券、对接滴滴和新华书店、按「曝光—领取—核销」看漏斗，哪一段掉得厉害就改哪一段。
券不是发出去就行。六种券型配不同场景，限领规则防止福利被少数人吃掉，核销率按渠道拆开看，再回头调选品。这套做法后来整理成了流程文档，基层工会照着就能自己办一场活动。
我做的每一个项目，入行的时候都是外行。
快速上手不是靠聪明，是有固定套路：先找这个领域里说话最有分量的那份文件——政策、规划、考核办法；再找一线的人问「你现在最烦的是哪件事」。两个答案对得上，业务逻辑就清楚了。剩下的时间用来验证，不是用来学习。
工会、生态环境、能源招采、高校校园、职教实训、数据治理——这些方向我都在同一个时期推进过，不是先做熟一个再做下一个。每一类业务的进入方式都一样：先读透考核办法，再找到一线最烦的那件事。
先把要做什么定义清楚，再看有没有人真的用起来，最后才轮到让机器接手其中一部分。
点进去能看完整过程：约束是什么、我怎么判断、做了什么、结果如何。
我在做的事情可以概括成一句话：把「很多人、很多层级、很多供应商一起干的事」，理出一条能落地的线。有时这条线落在一个省级平台上，有时落在一个职工每天会点开的入口里，有时只是一条数据口径。
我的产品观不按行业分，按「谁在用」分。 给组织用的（to B），最怕的不是功能少，是口径不一样——省、市、县各说各的，功能再全也拼不成一个平台；一个字段定义对不上，整个平台在验收时就会被判不合格。
给人用的（to C），最怕的不是不好用，是没人愿意主动打开。功能不缺，缺一个「今天为什么要用它」的理由。我做过面向 665 万会员的普惠服务：发券、对接外部渠道、按「曝光—领取—核销」拆漏斗，哪一段掉得厉害就改哪一段。
所以这几年我做的事横跨两类：一头是几千万预算、十八个子系统、多家供应商的总集成；一头是普通职工每天会点开的移动端。任务看着离得远，要判断的是同一件事：谁在用、他为什么用、哪里会断。
[email protected]