关于与合作

我的做事方式

我做过的活集中在一种类型上：企业里那些反复在做的数据活。它们通常有三个共同点——步骤固定、材料不规范、对错要靠人判断。

干这类活久了我发现，真正决定成败的不是工具，是在动手之前把规则说清楚：哪一步谁拍板、什么算对、错了怎么发现。规则说不清的项目，做出来也没人敢用。

服务范围

能做的

• 图纸、清单、台账、报表类的提取与比对
• 文档、规程、制度类的知识库与问答检索
• 每天/每周重复的固定流程，做成能一键跑完的东西
• 给具体的人用的单文件小工具

不做的

• 需要长期驻场运维的系统
• 需要特定资质或涉密审批的项目
• 纯视觉设计
• 没有验收标准的活

最后一条不是姿态。说不清什么算做对的项目，我做完你也没法验收，两边都难受。

交付流程

1. 需求澄清。 先聊你的活现在是怎么干的，卡在哪一步，谁在干。
2. 写验收标准。 在写任何代码之前，先把「什么算做对」写成几句话，你确认。
3. 小样验证。 先拿一小批真实材料跑通，用最难的样例试，而不是用最漂亮的样例。
4. 交付与复盘。 交付时一并说明：哪里会错、错了怎么查、下次要改怎么改。

验收标准

和首页那三条是同一套，这里展开说：

1. 能解释。 界面上任何一个状态，都要能用一句话说清「为什么是它」。解释不清的界面，等于让人猜。
2. 能查。 每个结论都要能回指到原始时刻、原始条目、原始那一行。查不回去的结论，在别人那里就只是你的说法。
3. 不编。 数据不足就写「暂无推算」。一个看起来合理的假数字，比一个空位危险得多。

边界与代价

• 我偏好的形态是单文件、零外部依赖、本地运行。好处是断网可用、没有订阅费、数据不出机器；代价是没有多端同步，换设备要手动导一次。这个取舍我在案例里写明了，不是没想到。
• 我不做「先搭一个大平台、以后再说」的活。范围先砍到能验收的最小一块，跑通了再加。
• 需要你配合两件事：一份真实的样例材料（脱敏即可），和一位懂业务的人给我半小时。这两样缺一样，项目就会在验收阶段卡住。
• 有一条我会主动先说：让机器读图纸、读文档，一定会错。 所以我在验收标准里写的是「错了怎么让你发现」，而不是承诺不出错。