晚上9点多，项目群里突然弹出一条消息。
产品 @ 研发同学：
这个需求很简单，就是招生的时候做个小程序，让新同学提前互相认识一下。
群里安静两秒，产品又补了一句：
最好里面可以聊聊天，有个社区，新生可以发发动态。
过了几秒，领导也进来了：
对，老师和教授资料也放进去，方便学生提前了解。
产品继续：
班级入学以后能不能自动加群？这样学生不用自己找群。
页面先不用太复杂，现在 AI 也能先生成一版，我们尽快搞个简单版出来。
群里前端、后端、测试，没人马上反驳。
不用猜太多，几个开发脑子里应该已经开始同时跑东西了。
大家盯着屏幕停了几秒。
最后群里回出去的是：
我们先看一下。
这句话看起来很克制。
但研发侧脑子里已经不是“做个小程序”了。
脑子里大概率都是这些问题：
账号怎么来？
新生怎么认证？
谁能看谁？
聊天要不要审核？
社区谁运营？
老师资料谁维护？
自动加群失败谁处理？
最后出问题是不是又会问“你们系统怎么回事”？
是做过真实项目的人，听到这几句话，都会下意识开始拆系统。
表面上情绪稳定。
实际脑子里已经开始疯狂弹窗。
前端在想页面状态微信接口限制。
后端在想表结构和权限。
测试在想异常用例。
大家嘴上没说，心里大概都是一句：
这事要是按“很简单”排期，后面肯定要寄。
产品大概率不懂技术，所以才觉得简单
这句话可能有点直，但真实项目里就是这样。
产品很多时候不是坏，也不是故意甩锅。
他就是不懂技术。
不懂技术的人看这个需求，看到的是一条很顺的用户路径。
新生还没入学，对学校不熟，对同学不熟，对班级也不熟。这个时候给一个小程序，让他登录进去，看看同班同学，看看老师介绍，找到班级群，发个自我介绍，确实挺合理。
产品脑子里的路径大概是这样：
打开小程序 -> 登录 -> 完善资料 -> 看同学 -> 看老师 -> 进群 -> 发动态 -> 聊两句。
这个画面当然没问题。
甚至看起来还挺温暖。
但问题就在这。
产品看到的是“用户点了几下”。
开发看到的是“用户每点一下，后面要有多少东西兜着”。
登录认证 -> 身份绑定 -> 班级关系 -> 权限判断 -> 内容发布 -> 消息服务 -> 资料维护 -> 审核举报 -> 异常处理 -> 后台管理。
这两条链路根本不是一个量级。
产品说“新生互相认识一下”。
开发听到的是：
先把身份、关系、权限、内容、消息和运营责任都安排一下。
这就很离谱。
不是需求离谱。
是把它叫“很简单”这件事离谱。
所以开发不是非要抬杠。
开发只是知道，页面越像“就几个入口”，背后越可能藏着一堆坑。
第一个内心 OS：这个“新同学”到底是谁
产品说：
让新同学互相认识一下。
这句话在群里很轻。
但开发脑子里第一个问题通常不是页面怎么画，而是：
谁是新同学？
这是一个很现实的问题。
新生数据从哪里来？招生系统有没有接口？还是学校给 Excel？学生自己注册行不行？如果自己注册，用手机号、学号，还是录取通知书？
再细一点。
学号还没发怎么办？
家长能不能登录？
老生能不能进来围观？
外部人员如果随便注册，怎么挡？
学生选错班级怎么办？
招生系统数据延迟，学生登录失败，前端提示什么？
这里面没有一个问题看起来很大。
但只要没说清楚，后面都会变成坑。
因为“互相认识”不是一个页面功能。
它先是一套身份规则。
开发真正听到的是：
先把用户体系搭起来。
这时候你如果在群里直接回“这个不简单”，气氛会很尴尬。
但你如果不问，后面更尴尬。
上线那天学生进不来，或者不该进的人进来了，大家不会回头说“当时身份边界没定义”。
大家只会问：
登录怎么有问题？
第二个内心 OS：聊天不是聊天框
产品说：
最好里面可以聊聊天。
这句话更典。
因为聊天在界面上太简单了。
一个输入框，一个发送按钮，一排消息气泡。产品看的是这个。
开发听到“聊天”，脑子里出来的是另一套东西。
是单聊还是群聊？
同班同学才能聊，还是全校新生都能聊？
陌生人能不能主动私聊？
老师能不能进群？
辅导员能不能发公告？
能不能发图片、语音、文件？
要不要已读未读？
要不要撤回？
离线消息怎么办？
消息推送怎么办？
这还只是功能。
真正让人皱眉的是风险。
有人骚扰同学怎么办？
有人发广告怎么办？
有人发违规内容怎么办？
聊天记录保存多久？
用户投诉以后谁看记录？
要不要拉黑、禁言、封号？
晚上十点有人在群里闹事，谁处理？
所以产品说“聊聊天”，开发会本能地停一下。
研发侧不是在想输入框怎么写。
大家是在想这个功能上线以后，会不会变成一个持续产生麻烦的系统。
聊天不是一个 UI。
聊天是一条责任链。
第三个内心 OS：社区一上线，就不是纯技术问题了
产品说：
再做个社区，新生可以发发动态。
这个也很容易被低估。
发动态本身不难。
发帖、评论、点赞、图片上传、话题标签，开发当然能做。AI 甚至能很快给你生成一个看起来还不错的社区首页。
问题是，社区真正难的地方不在“能不能发”。
在“发了以后怎么办”。
新生能发什么？
能不能发广告？
能不能发兼职？
能不能发交友内容？
能不能匿名？
能不能评论别人？
评论吵起来怎么办？
图片要不要审核？
敏感词谁维护？
举报谁处理？
误删了怎么申诉？
这些都不是“页面先做出来”能解决的。
社区是很典型的东西：你上线之前，它像功能；你上线之后，它像运营。
没人管的社区，很快就会走向几个方向。
要么没人发。
要么乱发。
要么变成广告墙。
要么变成吐槽区。
最怕的是一开始还挺热闹，热闹到你发现学校需要有人天天盯着。
这时候再回头说“我们只是想做个简单社区”，就晚了。
第四个内心 OS：老师资料不是放几个页面
领导说：
老师和教授资料也放进去。
这个听起来最像静态内容。
姓名、头像、职称、学院、研究方向、授课课程、邮箱。排个列表，再做个详情页，好像就结束了。
但开发脑子里又会往后走一步。
资料从哪里来？
官网抓吗？教务系统同步吗？学院给表吗？老师自己填吗？
谁来更新？
老师离职了怎么办？
新老师入职了怎么办？
职称改了怎么办？
研究方向变了怎么办？
老师不想公开邮箱怎么办？
信息错了谁负责？
这类需求特别容易出现一个很真实的画面。
上线前大家都觉得“就是放资料”。
上线后某个老师发现自己的资料不对，找到学院，学院找到产品，产品找到开发：
这个能不能帮忙改一下？
开发问：
谁有权限改？改完要不要审核？历史记录要不要留？
然后群里安静了。
因为这时候大家才发现，原来“放资料”的后面是维护流程。
不是开发爱复杂化。
是信息只要会变，就一定有人要维护。
没人维护，它就会慢慢变脏。
第五个内心 OS：自动加群听着小，错了很麻烦
最后一个更刺激。
产品说：
入学以后自动加群。
这个需求听起来非常合理。
学生分好班，系统自动把他加到班级群。少一步人工操作，体验也更顺。
但“自动”这两个字，开发一般都不会轻易点头。
因为自动化一旦错了，比不自动还麻烦。
加什么群？
微信群、企业微信群，还是小程序内部群？
班级群、专业群、学院群，还是新生总群？
分班数据什么时候确定？
转专业怎么办？
换班怎么办？
休学怎么办？
群满了怎么办？
学生没授权怎么办？
微信接口限制怎么办？
加错群怎么办？
重复加群怎么办？
失败后要不要重试？
重试失败以后谁人工补？
每个问题单独看都不吓人。
但自动化最怕的就是这样。
平时没人关注，一旦错了，它直接影响真实世界里的组织关系。
一个学生被加进错班群，可能不是一个 bug 单。
可能是老师、辅导员、家长、学生一起问：
怎么回事？
所以开发听到自动加群，不会只想到“调个接口”。
研发侧会先想到失败场景。
这不是悲观。
这是经验。
AI 让误会变得更快了
现在 AI 都能生成页面了，这个应该很快吧？
这句话现在很常见。
也确实有一半是对的。
AI 现在生成页面确实快。
新生资料页、老师列表页、社区首页、聊天界面、班级群入口，几分钟就能出个看起来像样的 Demo。
产品一看：
这不已经差不多了吗？
研发侧一看：
截图是差不多了，麻烦还没开始。
AI 能生成页面，但它生成不了需求边界。
它不知道新生怎么认证，不知道聊天骚扰谁处理，不知道社区内容谁审核，不知道老师资料谁维护，也不知道自动加群失败以后谁去补。
所以问题不在于能不能用 AI。
当然能用。
但别只用它来画页面。
更好的用法是顺手让它拆风险：
页面可以先生成，但我们也让 AI 把用户边界、数据来源、权限、审核、异常和责任清单一起列出来。不然生成得越快，返工越快。
所以现在很多开发听到“AI 都能生成了”，其实不用马上反驳。
更稳的反应是先问：
生成页面没问题，那这次我们要不要一起把边界、异常和责任也生成出来？
这种时候，不要只回“这个不简单”
开发最容易吃亏的一句话，就是：
这个不简单。
这句话可能是真话。
但在群里，它很容易被听成另一句话：
我不想做。
所以遇到这种需求，第一步不是反驳。
是先把目标复述出来。
比较稳的回法是这样：
方向我们理解，核心应该是让新生入学前先确认班级、同学、老师和官方入口，降低信息差。这个可以做。
但现在里面混了几类能力：信息聚合、聊天、社区、老师资料维护、自动加群。它们的复杂度不一样，建议先确认第一版边界。
这段话的重点是“可以做”。
先接住目标，再拆范围。
不要一上来就把产品打到对立面。
你真正要做的，不是证明需求很难。
是把“很简单”翻译成“我们这一版到底做什么”。
研发侧可以把它拆成三个版本
如果这个需求直接丢给研发侧，最好不要马上报一个总排期。
先拆版本。
因为只要你直接报总排期，后面所有没说清的东西都会默认被塞进去。
第一版，建议做“新生信息聚合”。
目标很明确：
让新生知道自己是谁，在哪个班，老师是谁，官方入口在哪里。
这一版做登录、身份认证、个人资料、班级信息、同班同学列表、老师资料展示、官方班级群入口、学校公告。
这一版先不做站内私聊，不做开放社区，不做自动建群，不做复杂关系链。
它解决的是信息不透明。
不是解决社交。
第二版，再做轻互动。
比如自我介绍墙、点赞、评论、举报入口、基础审核。
但边界要卡住：不匿名，不做热榜，不做推荐，不做私信，不让它长成一个完整社区。
这一版解决的是破冰。
不是做校园版小红书。
第三版，如果真的要做聊天、群组、社区运营、自动加群、内容风控，那就按完整项目评估。
这时候就不能再叫“简单版”了。
它需要技术方案，也需要运营方案。
更需要责任人。
三档方案摆出来以后，大家其实更好选。
想快，就选第一版。
想完整，就承认成本。
最怕的是嘴上说第一版，心里想第三版，排期按第一版给，上线按第三版验收。
这个项目不炸才怪。
评审时要问的，不是“能不能做”
这种需求评审，最重要的问题不是“能不能做”。
能做。
大多数功能都能做。
真正该问的是：
做到什么程度算完成？
比如用户身份。
新生数据从哪里来？学号还没发怎么认证？家长能不能进？外部人员怎么拦？身份信息错了谁改？
比如聊天。
第一版必须站内聊天吗？官方群入口能不能先满足？陌生人能不能私聊？聊天内容要不要审核？被骚扰以后谁处理？
比如社区。
第一版是自我介绍墙，还是完整社区？内容先发后审，还是先审后发？能不能匿名？举报以后谁看？
比如老师资料。
资料来源是谁？谁维护？哪些字段能公开？老师不同意公开联系方式怎么办？错误信息谁负责？
比如自动加群。
加微信群、企业微信群，还是站内群？分班数据什么时候确定？加错群怎么办？群满了怎么办？接口失败以后谁补？
这些问题不是为了把产品问住。
是为了让大家一起看到现实。
很多需求不是做不了。
是还没到能排期的状态。
“暂不做”一定要写下来
评审会上最危险的默契，是：
这个后面再说。
后面是谁？
再说是什么时候？
说给谁听？
没人知道。
所以这类需求一定要把“暂不做”写下来。
不是写在脑子里，也不是散在聊天记录里。
最好写进 PRD、评审纪要，至少也要在群里发一条确认。
比如可以这样发：
我这边同步一下本期范围：
本期先做新生信息聚合版，目标是让新生完成身份确认，查看个人资料、班级信息、同班同学、老师资料和官方班级群入口。
本期暂不做站内私聊、开放社区、自动建群、热榜推荐、复杂关系链、老师资料自助维护后台。
还需要产品侧确认三件事：新生数据来源和同步方式；老师资料字段和维护责任人；官方班级群入口提供方式。确认后再进入详细排期。
这条消息看起来很普通。
但它能把很多“我以为你知道”提前消掉。
产品可以补充。
领导可以拍板。
研发侧也不用靠记忆保护自己。
项目里最怕的不是大家有分歧。
分歧可以谈。
最怕的是所有人都觉得自己已经达成一致，但其实每个人脑子里的版本都不一样。
这不是给需求泼冷水
说产品不懂技术，不是骂人。
这本来就是分工现实。
产品不懂表结构、权限模型、消息队列、审核链路、异常补偿，这很正常。
开发不懂招生场景、学生服务、学校管理流程，也很正常。
问题不在于谁不懂。
问题在于，不懂技术的人把技术复杂度说成“很简单”，懂技术的人又不好意思把坑摊开。
最后大家一起装作没事。
这才是最容易炸的地方。
产品要讲愿景。
新生提前认识、降低陌生感、提升学校服务体验，这些目标都对。
开发要讲落地。
身份怎么验，数据怎么来，权限怎么设，异常怎么兜，事故怎么查，上线后谁维护。
这不是谁高级谁低级。
只是看的东西不一样。
产品负责把“应该有的体验”说出来。
研发侧负责把“为了这个体验要付出的代价”摊开。
真正的问题从来不是愿景太大。
愿景大一点没关系。
真正的问题是愿景很大，但被包装成“很简单”。
最后成本不会消失。
它只会换一种方式回来。
变成延期。
变成返工。
变成线上事故。
变成开发深夜改数据。
变成上线后那句很熟悉的话：
这个当时怎么没考虑到？
其实考虑到了。
只是当时它被叫作“简单版”。
最后再回到那条群消息
产品在群里说：
需求很简单，就是给新同学互相认识一下。
开发群里回：
我们先看一下。
这几个字后面，通常不是敷衍。
而是几个开发已经在脑子里把系统跑了一遍。
谁能登录。
谁能看谁。
资料从哪来。
聊天谁管。
社区谁审。
加群怎么失败。
第一版做什么。
这期不做什么。
出事谁处理。
所以遇到这种需求，别只防御性微笑。
笑完以后，把话说清楚。
先复述目标，再拆边界，再给版本，再写确认。
这不是给需求泼冷水。
这是让需求真的有机会做完。
AI 可以生成页面。
研发要交付的是系统。
这中间差的不是几行代码。
是边界、取舍和责任。
