先说不接的那件事
上个月有个客户找过来，需求写得很完整：一份 AI 应用方案，页数有要求，最好配几张架构图，预算不低，周期两周。谈的时候对方很客气，反复强调"你们专业，写出来的东西肯定比我们自己拼的强"。
我问了一句：这套系统计划什么时候上线，谁来用。
对面停了两秒，说，先申报，上了再讲。
我又问，那申报过了之后，是哪个部门来推，他们现在手上有什么数据。
对面笑了一下，说，这些后面再说，先把材料做漂亮。
我就知道这活不能接。
钱是真的好赚，所以才更要小心
说句实话，这种单子做起来太舒服了。不用碰数据，不用跟 IT 部门扯权限，不用半夜起来看监控。两周交付，验收快，回款也快。比我们做真项目舒服十倍。
我犹豫过。不是装，是真犹豫。那个月现金流不算宽裕，接了这单能缓一口气。
最后没接，理由说出来有点土：做完之后我们这边什么都不会留下。
没有一套跑起来的系统，没有一份真实跑出来的日志，没有一个从不会用到会用的业务同事。我们能留下的只有一份 PDF。而这份 PDF 过两年谁都不会再打开。更麻烦的是，我们的人在这两周里学到的东西，约等于零。
做咨询的同行可能不同意，觉得写方案本身也是能力。我承认那是能力，但那是另一种能力，不是我们想攒的那种。
帮客户把技术讲清楚，是我们该干的
这里得说清楚一件事，免得被读成"我们瞧不起做方案"。
完全不是。帮客户把技术方案讲清楚，本来就是我们工作的一部分，而且是硬功夫。很多客户的痛点是，业务上想得明白，一到技术语言就散了，评审的人听不懂，预算批不下来。把这事理顺，是正经活。
区别不在"写不写文档"，在"有没有打算真的建"。
我见过一个团队，方案写得一般，架构图都是手画的，但他们已经买了三台服务器放在机房，数据也导进去了，跑着一个很粗糙的版本。这种客户的文档我们愿意写，写的时候还能顺手把他们的坑指出来。
也见过方案写得极漂亮的，一页一页全是愿景，但问到"谁来维护"就卡住。这两种客户，纸面上看差不多，往下问一层就分得开。
我们的判断标准只有一句话
内部现在流传一句很土的话：问一句上线时间和使用人，答不上来的，婉拒。
不是问"你为什么要做 AI"，那个问题太虚，谁都能答。要问的是具体的、会让人不舒服的问题：
- 这套东西上线那天，是哪一天，或者哪个季度
- 上线之后，每天用它的人是谁，叫什么岗位
- 如果这个人下个月离职了，谁接
- 现在这件事是怎么做的，用 Excel 还是用嘴
这四个问题里，能答上两个的，我们接。一个都答不上来的，我基本会当场说：这个我们做不了，但我可以推荐几家专门做申报材料的。
推荐的时候我是认真的，不是阴阳。这类活确实有它存在的道理，有它擅长的团队，只是不是我们。
说点我自己也没想明白的
这条线是不是划得太死了？
有些项目确实是先立项、再落地，顺序反过来就是做不成。政府项目尤其这样，没有那纸批文，什么都推不动。这种情况下，先做方案完全合理。我们因为这个拒掉过一两个本来可以很长的合作，现在想起来还有点可惜。
所以我们的标准其实是"往后问一层"，不是"一票否决"。立项本身不是问题，问题是立完项之后有没有人真的打算动。
这条线我自己也还在调。可能半年后我会觉得现在太保守，也可能觉得还是太松。真有变化我再来写。
写这封信不是为了让谁难堪
那位客户后来找了别家，我听说材料过了。挺好，各取所需。
我写这个，是因为最近半年这类询价明显变多了，多到我们需要一条成文的线，不然每次都得现场纠结。也因为我们团队里有人不理解，觉得老板在跟钱过不去。
这条线大概会让我们少赚一些钱。我认。
但如果三年后有人问我 YGG 做过什么，我希望我能报出几个还在跑的系统的名字，而不是一串申报通过的项目编号。