夜雨聆风上一篇我写了自己那个"假 AI"——平台里的运维助手，回答我的不是大模型，是二十来个 if。
后台有人问：那你现在还敢用 AI 写代码吗？
敢。而且比以前更敢了。只不过我改了个用法：以前我把它当会打字的实习生，现在我把它当一个能力很强、但完全没长记性、还特别爱讨好我的工程师来管。
这篇就把我这套"管法"摊开讲。
先说最反直觉的一条：越急，越要按住它别写
大部分人打开 AI IDE，第一句话就是"帮我做个 XX 系统"。AI 特别配合，立刻建文件、装依赖、写页面。
爽。但基本会翻车。
因为这时候产品定位、第一版边界、数据长什么样、验收标准是什么，你自己都没想清楚。AI 只能猜。你今天说给个人用，它明天可能给你写成企业后台；你说第一版只做核心流程，它顺手塞进一堆你没要的功能。
我现在的第一句话永远是：当前阶段只讨论，不要写代码。
先让它当产品合伙人，陪我把项目聊清楚，再让它当代码生成器。这个顺序反过来，后面全是返工。
AI 没记忆，所以文档是它唯一的记忆
运维这行有个东西叫 runbook——把处理某类故障的步骤写下来，谁来了照着做都不会错。我用 AI 的时候，把这套习惯整个搬了过来。
AI 每开一个新会话，就是一次"失忆"。你昨天跟它吵了半天定下来的方案，今天它一概不认。
所以我给每个项目都建一个文件，就叫"施工日志"：现在做到哪、下一步做什么、定过哪些规矩、踩过哪些坑。每次让 AI 干活前，先让它读这个文件。
> 别指望 AI 记住你说过的话。它不记。你把该记的写进文件，它才有"记忆"。
这一条听起来最朴素，但省下来的返工是最多的。
逼它给判断，逼它给证据
AI 有两个讨好型毛病，运维人一眼就能看穿。
一个是爱说模糊话："基本完成""应该没问题""理论上可以"。这话我太熟了——线上出事时最怕听到的就是这三句。我现在直接给它立规矩：要么通过，要么未通过，加原因，不许用基本。
另一个是爱甩锅。你问它选哪个方案，它给你列三个让你自己挑。我会追一句："基于我的项目给唯一推荐，并说明为什么不选其他。"
还有更狠的一招，也是从运维带过来的——要证据。它说某个功能做完了，我让它说清楚：改了哪个文件、怎么验证的、实际输出是什么。没有证据的，一律标"未验证"。
服务说自己 running，你得看端口通不通。AI 说自己完成了，你得看它拿不拿得出证据。一个道理。
给项目设几道"过不去就不许走"的门
我一个人干活，最怕的不是慢，是稀里糊涂往前冲，冲到一半发现地基是歪的。
所以我把整个开发切成几个阶段，每个阶段结束设一道"门"：方向没定死，不许进入选型；架构没跑通，不许写业务；功能没测过、安全没审过，不许上线。
每道门都有一张清单，逐项打勾。关键是——每一项必须有证据才能勾，不许凭感觉。
这套东西我最早是给自己定的纪律，后来干脆写成了模板，新项目直接套。它治的不是 AI，是我自己那颗想抄近道的心。
if / then：几个能直接抄的判断
if 你脑子里只有个模糊想法，then 别急着让 AI 写，先让它反问你、帮你补盲区，把想法聊成文档。
if AI 开始用"基本""应该""理论上"这类词，then 立刻打断，要它给"通过/未通过 + 原因"。
if 你发现一个会话里已经聊了几十轮、它开始前言不搭后语，then 果断开新会话，把进度摘要贴过去重新开始——上下文太长，它会变笨也变贵。
if 某段代码你既看不懂也没法测，then 别让它碰核心链路。写个查询页、导个报表可以，别让它写权限和会真正下发命令的那一段。
你是 PM，不是 coder
最后这条是心态，也是我卡了最久才想通的。
用 AI 做项目，你的角色不是"更快的程序员"，是"项目经理"。你的活是：把需求定义清楚、把成果验收明白、把 AI 管住。不是逐行去读它写的每一行代码——那样你会累死，而且根本读不完。
高层级验收，靠的是能不能跑、功能对不对、测试过不过，不是靠你一行行盯。
想通这点之后，我反而轻松了。我不再跟 AI 比谁代码写得快，我只负责判断它写的对不对、该不该往下走。
写在最后
AI 能把写代码的成本压到几乎为零。但"写出能用的东西"这件事的成本，一分没少——只是从"敲键盘"挪到了"定规矩、做判断、扛验收"上。
这套规矩我打磨了三年，现在整理成了一整套方法。接下来我打算一篇篇拆开讲：怎么立项、怎么管上下文、怎么让 AI 改 Bug 不越改越乱、怎么在它说"完成"时逼它拿证据。
你要是也在用 AI 做东西，评论区说说你最头疼的是哪一步，我优先写那篇。