POC 跑通了，就真以为能做出来？

AI 让做出来变得不值钱也让做对变得前所未有地值钱。先讲个我在公司里反复看到的场景。上周,产品经理找到我,兴奋地甩过来一个截图:你看,我用 AI 半个小时就把这个功能做出来了,客户下周三要验收,咱们直接上就行。我点开一看,是一个能点、能跳转、能展示的页面 Demo,UI 还挺像那么回事。问题埋在哪?我随手试了一次:连点两下提交按钮,数据插进去两条一模一样的;把手机号那个输入框里填进一串乱码,后端直接 500;点导出报表,100 条数据都要转十来秒,而客户明确说过他的数据量是几十万条。我把这三个问题截图发回去。产品回了一句:“这些小细节,上线前让 AI 再改改不就行了?”你看,这就是问题的起点——在很多人眼里,POC 跑通,就等于做出来了,剩下的都是小细节。而商务那头,拿着同一个录屏,已经跟客户把合同里的工期、验收标准都聊妥了。等传回技术,就变成一句:“客户已经确认了方向,咱们赶紧落地。”落地之后呢?键盘敲得飞快,AI 多轮对话,代码一行行往外吐。三个月后系统上线,再三个月后到处是坑。于是开会:现有实现问题太多,重构一版。再过一段时间,再重构一版。忙是真的忙,东西却一直没个靠谱的基线。这不是哪一家公司的特例,是 AI 时代一股正在蔓延的风气。我想尽量客观地聊这件事——不否定 AI,也不让它当背锅侠。真正的问题,藏在一个被很多人忽略的边界上。一、先把话说清楚:AI 没错,这笔账要认AI 写代码这件事,是实打实的进步,不该被妖魔化。以前一个 POC,从想法到跑通,可能两周。现在呢?可能两天,甚至一个下午。原本根本不敢试的方向,因为试错成本低了,现在就敢先做个东西出来看看。这是好事。低成本快速验证,能更早地看出方向对不对,把错误憋死在摇篮里,而不是等写了几万行代码再发现走错了路。所以这篇文章不是要劝你别用 AI coding。恰恰相反——只有真正把它当回事的人,才更需要搞清楚它的边界在哪里。工具越有用,越要明白哪些责任它替不了人类扛。二、但快和对,是两个完全不同的目标,AI 只解决了前者这里要拆一个概念,很多人混着用:POC(概念验证)验证的是能不能做到,不是该怎么做才可靠。一个能跑的 Demo,走的是 “happy path”——最顺利的那条路:输入正常、网络正常、没有同时操作、没有恶意请求、数据量小、出错就重来。可真实用户的使用,恰恰是各种不顺利叠加出来的:两个人在同一时刻点了同一个按钮,数据会不会乱?网络抖一下,请求发了一半断了,这单算成功还是失败?有人故意传个乱七八糟的参数进来,系统崩不崩?用户量从 100 涨到 10 万,那几行查询还转得动吗?出了问题,能不能快速定位是哪一步错了,能不能回滚?这些,才是做对的真正成本。而 AI 生成代码,最容易在看起来没问题的地方埋雷——happy path 一眼就能看出对不对,但边界条件的错误,往往是跑起来才炸,甚至要等很久、等到数据已经错了才炸。一句话:AI 把写出第一版的成本打到了接近零,但做对、做好、能长期维护的成本,不降反升。三、最危险的从来不是 AI,是把AI 的产出当成了验收标准到这里,才触及核心。最近幻觉这个词很火。但工程上更危险的,不是 AI 偶尔说错话,而是整个组织把看起来能跑当成了真的能用的验收线。具体怎么发生的?看三个典型动作:动作一:商务拿 POC 敢签约。商务敢拍胸脯,本质上不全是商务的错。是因为组织里没有一个角色,在量化技术可实现性这条边界。技术没把这 Demo 离交付还差多少、风险在哪、要多久说成一个能约束承诺的数字,那商务就只能凭感觉——凭感觉,自然往乐观了想。动作二:技术拿多轮对话当验证通过。AI coding 的过程,是一轮轮对话、一行行让它改、让它收敛。但收敛到的是什么?是看起来合理,不是正确。要命的是,很多接手的人,自己其实也不完全清楚这段逻辑该不该这么写。当你自己都不具备 review 能力时,AI 写出来的东西,你是 hold 不住的。你以为你在用它,其实是它在替你做了本该你做的判断。动作三:每隔一段时间就想重构一遍。这是最隐蔽、也最值得警惕的一个信号。以前重构有成本,所以大家会先想办法把现有问题搞清楚、验证清楚,才敢动手。现在 AI 让重新生成一版变得太便宜了。于是推倒重来成了一个逃避的动作:我不用搞懂它为什么错,我重新写一版不就行了。结果就是——用一代没有验证的代码,去替换上一代没有验证的代码。循环打转,永远没有稳定基线。这种重构上瘾,不是工程进步的标志,恰恰是工程不成熟的信号。健康的系统是增量演进的,只有浑身是债的系统,才需要隔三差五推倒。四、AI 时代,真正值钱的能力正在转移把上面三层串起来,会得出一个反直觉、但很重要的结论:以前工程师值钱,是因为会写代码。现在写代码几乎免费了,值钱的变成了另外两件事:知道什么是对,以及敢为对负责。工具的边界一旦模糊,人就容易把生产活动误当成成果。但工程这件事,从来不是看谁键盘敲得响,是看谁交付的东西经得起时间、经得起真实世界的折腾。所以我的态度很明确:不是不让用 AI,而是不能因为 AI 太快,就把工程该守的底线也一起丢了。速度是工具给的,底线是人该守的。这两件事,谁也别替谁。五、最小可行方案:把技术评估这道闸重新立起来光吐槽不建设,等于没说。给一个不复杂、能立刻用起来的办法。核心就一句话:在POC 能跑和商务去承诺之间,重新插一道技术评估的闸。1. 交付前,强制过一道非 POC 清单。把 Demo 没覆盖到的地方,列成一张纸,每项标注已验证 / 未验证 / 风险未知。这张清单不要求全部做完,但要求商务出去承诺之前,必须先看一眼,知道哪些是赌的。只要把我们赌它能行和我们验证过它能行分开对待,就已经比现在强一大截。下面这张清单,可以直接抄走用:维度要问的具体问题状态已验证 / 未验证 / 风险未知并发/一致性两人同时操作同一数据,会不会写乱?多事务之间有没有竞态?幂等性用户手抖连点两次提交、网络超时重试,会不会重复下单/重复扣款?异常兜底依赖的服务挂了、超时了,是优雅降级还是直接崩溃?输入边界空值、超长字符串、乱码、负数、特殊字符,有没有统一校验?事务完整性一段操作里步与步之间失败了,前面已经写进去的数据能回滚吗?权限与安全谁在什么时候能访问什么?有没有越权、注入、数据泄露的口子?性能与容量真实数据量下,关键查询/接口耗时多少?能扛住预期的并发峰值吗?可观测性出了问题,日志够不够定位到是哪一步错的?有没有监控和告警?数据迁移/兼容老数据怎么迁?历史版本怎么兼容?会不会上线就丢数据?回滚方案上线后发现严重问题,能不能安全快速地退回上一版?第三方依赖依赖的外部 API 有 SLA 吗?它变了、限流了,我们怎么办?文档与交接半年后换个人接手,他能不能看懂、改得动?这张表不是为了让你全部填成已验证才敢交付,而是逼着所有人在拍胸脯之前,先诚实面对哪些地方是没验证过的。很多时候,光是把风险写出来这一个动作,就能拦住一半的草率承诺。2. 技术明确写:从 Demo 到交付,还差多少。不是一句还有不少工作量,而是给一个量化的、能约束承诺的数字:还差几个模块、哪些是高风险、预计多久。责任不在于技术要把所有风险都消灭,而在于把风险边界说清楚,让敢承诺变成一个知情的决定,而不是一个无知的乐观。3. 给重构立个规矩:先写清楚现在的它错在哪,再谈重写。这是治重构上瘾最直接的一招。谁要重构,先写一份两百字的说明:现有实现具体的问题是什么、为什么改不动只能重写、重写后验证哪些点。写不出来,就先别动。这一招的妙处在于,它逼着人去面对、去理解旧代码,而不是借重写来逃避理解。AI 让重写变便宜了,我们就该反过来,让重写的门槛变高一点、而不是更低。这三件事,没有一件是要你少用 AI。恰恰相反,它们是让你用得更稳、更久。AI 越强,越需要一个清醒的人,站在能跑和能交付之间,守住那条越来越容易被忽视的线。AI 负责快,人负责对。各司其职,才不至于把 demo 当成了产品,把热闹当成了成果