真实案例库 第二辑：6 个更高阶的判断
第一辑讲"会出什么技术事故"。这一辑更进一层——讲"判断力"：什么时候该质疑需求本身、什么时候该克制不动手、哪些坑藏在安全和合规里、怎么让 AI 做的东西不掉档次。这些决定了你是"AI 操作工"还是"能扛事的主理人"。
为什么这一辑更难，也更值钱
第一辑的坑，AI 配合你查日志、加防御就能补。这一辑的坑，AI 帮不了你——因为它会忠实地执行你那个"本身就错"的需求。你让它合并账号，它就给你写合并逻辑；你让它加个弹窗，它就加。"该不该做"永远是人的判断。
案例一：忙了 5 轮做"账号合并"，最后发现这题根本不该做
场景：一个 App，用户在手机上买了会员，想在平板上也能用。工程师问："两个账号怎么合并，会员、时长、词库这些字段按什么规则合？"
发生了什么：一头扎进去答"合并规则"，结果 5 轮里推翻自己 4 次——"老账号优先"被驳（凭啥老的值钱）、"按剩余订阅价值"被驳（两个反例就击穿）、"完全不合并"被驳（海外用户跨平台没救）……每一版规则都有致命漏洞。直到有人一句话点破："用户根本不需要'合并'——他只要能在新设备上，登录他买了会员的那个账号，不就共享了吗？"
真答案：问题不是"两个账号怎么合"，而是"用户怎么在新设备上登入原账号"。把"合并"整个删掉，改成"同一个身份多端登录"，后端代码净删了 100 多行——题目对了，砍代码比写代码还快。
带走的教训（最高阶的一条）
① 当 AI 或同事问"怎么做 X"，先停下来问"到底该不该做 X"——很多需求本身就是错题；② 发现自己在不停打补丁、加条件、解释边角情况，多半是抽象层级错了，跳上一层重新看；③ 行业里几乎没人做的事，往往是有原因的；④ 用用户的语言想问题（用户只懂"账号"，不懂"身份合并"）。AI 会忠实实现你要的任何东西——所以"要对的东西"是你的责任。
案例二：总想"加点什么"，而正确答案常常是"什么都不加"
场景一：某个登录后的弹窗在个别情况下像噪音。第一反应是"加个后端字段让弹窗更聪明"，被驳后退到"删弹窗但加个设置页说明"。
场景二：给"加购套餐"加了个限制——"主余额没用完不让买"，理由是"防止用户白花钱"。
真相：两个都该是"什么都不加"。弹窗讲的是"同账号多端共享会员"——这是用户在 Apple/Google 早就懂的常识，再教一遍就是把用户当傻子、暴露业余。加购限制更离谱："用户给你付钱你拦着干嘛？"（会员剩 20 分钟、马上要开 1 小时会议，凭什么不让加购？）。
带走的教训（克制是第一价值观）
面对任何"加个弹窗／提示／限制"的冲动，强制自问三点：① 这东西用户主动需要，还是我假设他需要？② 这概念主流产品是不是早教过了？③ 什么都不加会有什么具体坏处——想不出具体坏处，答案就是别加。"加东西"是舒适区（显得在做事），"什么都不加"才需要判断力。被驳回时别急着找"折衷的轻量版"，而要问"反驳的逻辑是不是对我的折衷版同样成立"。
案例三：一把密钥同时用在两处，等于给自己埋了核弹
场景：填各种平台的"公钥"字段时图省事，把给 App 做代码签名的那把密钥，又拿去填了支付平台的"应用公钥"——反正"技术上能跑通"。
埋了什么雷：为了让支付签名能过，服务器被迫装上了"能给 App 签名的私钥"。这意味着——万一服务器被入侵，攻击者就能签发假 App 冒充你上架钓鱼，后果是整张签名证书作废、所有已上架版本失效、用户被迫重装。一把密钥跨了两个"信任域"，任何一边出事，两边一起遭殃。
带走的教训（安全的铁律）
一把密钥只服务一个"信任域"，绝不跨域复用——代码签名、服务器接口签名、身份标识，各用各的密钥对。填任何"公钥/密钥"字段前先问：对应的私钥要放在哪？那个环境一旦被攻破，所有用到这把钥匙的地方会怎样？（只有"纯标识、不涉及私钥签名"的指纹类字段，复用才安全。）AI 帮你接支付/签名时，一定要让它为每个用途单独生成密钥，别图省事共用。
案例四：改数据前不看"单位约定"，5 条记录错出 3 种方向
场景：手工补几条老订单的金额。直觉地写了 amount: 68（就是 ¥68 嘛）。
出了什么事：系统里这个字段的真实约定是"毫单位"——¥68 要存成 68000（有清清楚楚的代码注释写着）。直接写 raw 数字后，同一张表里单位混了，而后台显示又是靠"数字大小"去猜单位的，结果 5 条订单错出了 3 种方向（有的放大 10 倍、有的缩小 100 倍、有的碰巧对）。
带走的教训（动数据库前的三步）
任何手工改数据（不只是补数据，也包括热修）前，严格走：① 先查同一张表、同类型的现有记录长什么样（字段格式、单位）；② 读写入这个字段的代码和注释——Apple/Google/Stripe 各家都有自己的单位约定（毫/微/分），别凭直觉；③ 先改一条、验证显示对了，再批量。AI 帮你写迁移脚本时，第一句就该让它"先读现有数据和写入代码的单位约定，再动手"。
案例五：为什么 AI 做出来的网站，总是"一眼假、显廉价"
场景：让 AI 做个品牌官网，出来的东西"能用，但一看就是 AI 做的"——廉价、套模板、没质感。问题出在哪？
廉价感的真凶（大多数人意识不到）：
- 字体：AI 默认爱用"粗黑体 + 全大写"，一眼廉价。高级做法——大标题用衬线体或 Helvetica 血统、句首大写（不全大写）、收紧字距、字号敢放大；中文用宋体做标题更有品牌感。
- 配色不克制：满屏强调色 = 传单。高级站常常整站就一两个灰阶 + 一个主色，强调色出现不超过三处。
- 没留白：区块挤在一起 = 廉价。敢用巨量留白（区块上下留白 150–200px）。
- 缺"档案感"细节：小号等宽字的编号、坐标、文件号（如
REC—01）；一致的 1px 细线边框语言。这些是质感的隐藏来源。
- 动效要克制有叙事：开场 loader、标题逐行升起、滚动驱动的视差——而不是满屏乱飞。
⚠ 中国大陆的隐藏大坑
AI 生成的网站默认从 Google Fonts（fonts.googleapis.com）加载字体——这个域名在中国大陆被墙，会导致国内访客白屏卡死。做给国内用户的站，字体必须自托管（下载到自己服务器）。这正是你这门课的站点要部署到国内服务器、而不是只靠境外平台的原因之一。
带走的教训
① 质感是"减"出来的：克制的字体 + 克制的颜色 + 巨量留白 + 一致的细节语言；② 想做高级，找个你欣赏的参考站，让 AI 帮你"抄参数不抄资产"（抄字距/留白/配色这些设计参数是学习，搬人家的付费字体/图片是侵权）；③ 给国内用户的站，字体一定自托管。
案例六：技术上完全能做，却被一条"2000 万"的门槛挡死
场景：国内版想做"自动续费订阅"——像 Apple/Google 那样到期自动扣款，省得用户每月手动续。技术实现毫无难度。
撞上什么墙：支付宝的"周期扣款（自动续费）"产品，要求商户注册资本 2000 万人民币以上——主体不满足，根本申请不下来。代码写得再好也没用，这是资质门槛，不是技术问题。
怎么破：不硬刚，改成"手动续费"的合规替代——到期前 7 天提醒、用户主动再付一次、未到期续费就叠加天数不浪费。体验略打折，但合规、能上线、跑得通。
带走的教训（最容易被工程师忽略的一类）
① "技术能实现" ≠ "商业/法律/平台政策允许"——支付、金融、医疗、内容、数据出境，到处是资质和合规门槛；② 做一个功能前，先查清楚有没有"资质/牌照/政策"卡点，别等开发完了才发现上不了线；③ 撞上硬门槛时，找一个合规的简化替代（手动续费照样能收钱），而不是钻空子。这一条 AI 基本提醒不了你——它懂代码，不懂你当地的监管。
第二辑：6 条"判断力"清单
| 案例 | 一句话 |
|---|
| ① 质疑前提 | 先问"该不该做"，再问"怎么做" |
| ② 克制不瞎加 | "什么都不加"常是正确答案，也最需要勇气 |
| ③ 密钥不跨域 | 一把钥匙只服务一个信任域 |
| ④ 先看单位约定 | 动数据前先查现有格式和写入代码 |
| ⑤ 前端质感靠"减" | 克制字体/颜色 + 巨量留白；国内站字体自托管 |
| ⑥ 合规先于技术 | 技术能做 ≠ 法律/平台允许，先查门槛 |
✓ 两辑合起来，是同一句话
第一辑教你"凡事用证据验证"，第二辑教你"凡事先质疑前提"。AI 把"动手"变得几乎免费，于是真正稀缺的，是"做对的事 + 不出事"的判断力。这正是你在这门课、和别处那些"教你让 AI 写代码"的内容之间，最大的不同。