前面几篇聊过 Vibe Coding、全栈生命周期，说实话，那时候更多是 看到趋势之后的判断，纸上得来的东西占多数。 这段时间不太一样——我手上的几个项目，AI 是真正从第一行参与到最后一个命令的。
所以这一篇不聊趋势，聊复盘：把这几个月的经历按开发链路拆开， 看看 AI 在每个环节到底能干什么、干不了什么，以及我还远没有吃透的部分。
能跑通一条完整链路，和真正吃透 AI，是两件完全不同的事。前者我已经做到了，后者才刚开始。
一、变化是从哪开始的
最早我用 AI，本质上是个高级补全：写个函数、补个正则、解释一段报错。 它的作用域是一个编辑器标签页。
现在不一样了。当 AI 能直接读文件、跑命令、看运行结果、再根据报错改回来时， 它的作用域变成了整个项目目录。这个差别是性质性的—— 它不再只回答"这段代码怎么写"，而是能参与"这件事怎么落地"。
- 作用域：单个代码块
- 提问方式：贴代码进去问
- 产出：一段片段，我自己拼
- 失败代价：重问一次
- 作用域：整个仓库 + 运行环境
- 提问方式：描述目标和约束
- 产出：可运行的改动 + 验证结论
- 失败代价：可能污染工作区
注意最后一行的差异。能力变大的同时，出错的后果也变大了—— 这是我在这一轮实践里体会最深的一点，后面会专门讲。
二、按链路拆开：AI 在每一环到底做了什么
我把它分成六段。下面这张图里，每一段都标了 AI 干什么、我干什么。
举例：一次真实的根因定位
有一个后台进程，历史重启次数到了 1268 次，处于崩溃循环里。 表面看是"它不稳定"，但真正的原因藏在管理方式里：
# 进程管理器用 fork 模式跑多个实例，而程序里端口是写死的
Error: listen EADDRINUSE :::2567
# 多实例同时启动 -> 互相抢同一个端口 -> 抢不到的那个崩
# -> 崩溃后被自动重启 -> 再抢 -> 再崩，循环成立这个 bug 有意思的地方在于，日志里每一条都是真的，但每一条都不是根因。 AI 在这里的价值不是"知道答案"，而是能快速提出多个候选假设， 并且设计出能证伪它们的检查步骤——比如把重启次数和端口冲突次数对齐看， 两者几乎一一对应，根因就浮出来了。
之后形成的是一条约定：任何新进程都要加熔断策略， 限制重试次数和最小运行时间。这类约定我都会写进项目的长期笔记里， 下次开工前先加载。
举例：一个看起来该信的数字
还是这个项目，需要评估服务器带宽。第一次测出来的数字完全不可信—— 因为测量方式本身有问题：在我本机到 CDN 的链路上测，结果只能反映我的家用宽带， 跟服务器的出口上限没有任何关系。
正确做法是让服务器自己往外推数据，并换三条不同路径交叉验证。 收敛之后拿到了一个稳定值：
三条路径交叉验证后收敛的结果 —— 瓶颈在带宽，不在算力
结论反过来了：机器的 CPU、内存、磁盘全都有三到五倍余量， 卡住的是出口带宽。 如果信了第一次那个数字，后面的架构设计会整个跑偏。
这件事给我的教训是：不要让 AI 在一个错误的测量方法上给你一个精确的答案。 精度和方法论是两回事，前者很容易伪造，后者不容易。
三、几个真的踩进去的坑
这一段比上面更有用。因为"AI 能做什么"到处都在讲， 但"AI 会在哪里坑你"得自己撞过才知道。
有一次需要确认两个模块之间的调用关系，代码检索工具返回了 4 条命中， 看起来清清楚楚。一条一条核对之后发现：4 条全在注释里， 真实的调用行为完全不同。
这类问题最危险的地方是，它有一份"证据"在手上。 所以我现在的规矩是：任何结论，都要能说出统计口径—— 排除了什么、怎么排除的。说不清就等于没验证。
我写过一个全项目脚本编译检查器，跑一遍输出"全部通过"， 心里很踏实。后来做了一次注入实验——故意造一个已知错误进去—— 它照样输出全部通过。
原因很讽刺：框架对编译失败的脚本并不返回空值，而是返回一个残缺对象， 我用来判断"是否编译成功"的那个条件，从头到尾就没生效过。
现在的规矩：任何校验脚本，上线前必须做双向受控实验—— 故意放一个错，确认能抓到；再清掉，确认能回到通过。 两个方向都要验。通过的绿色对勾本身毫无意义， 有意义的是"它到底检查了什么、漏掉了什么"。
本地跑得好好的，传上去直接起不来。原因各不相同： 服务器只装了生产依赖，构建后的产物格式对不上； 某个命令行工具服务器根本没装； Node 脚本放在临时目录会导致模块解析失败……
这些都是AI 无从得知的环境事实，它不知道你的服务器缺什么包、 开了哪些端口、防火墙有几层。这个信息的鸿沟只能靠自己补， 或者——把它写进笔记，让每次开工都带上。
一个项目跑久了，AI 会渐渐忘记开工时定下的规矩。 不是它记性差，是上下文有窗口、有取舍。
我的应对是把约定外置成文件：架构决策记录、项目长期笔记、 每次开工前先加载。听起来笨，但它把"记住"这件事 从模型的不确定性里剥离出来了。
四、我现在怎么跟它配合
踩完这些坑，流程慢慢收敛成几条比较硬的规矩。不一定适合所有人， 但对我是有效的：
- 约定写在文件里，不写在对话里。 项目名称、目录结构、命名规范、禁止事项，全部落盘。 每次开工加载一次，比每次口头重复可靠得多。
- 先审计，再授权。 分析阶段鼓励它大胆下结论、给到行号，这时候的输出越锋利越好； 但真正动代码之前必须过我这一关，而且一次只批一批改动。
- 区分验证等级。 改完之后要明确标注这是"没跑过的修复"还是"验证过的修复"。 这两个词混着用，迟早要出事。
- 把它的产出当 PR 看，不当真理看。 PR 是要审的，要跑测试的，可以打回的。真理不用。
- AI 负责把路铺出来，我负责选路和负责。 出问题的时候，跪在线上的是我，不是模型。责任归属决定了谁该拍板。
AI 让"做出来"变便宜了，但它没有让"做错"变便宜。省下来的时间，应该花在验证上，不是花在赶工上。
五、还没吃透的部分
写到这里得诚实一点。链路跑通了，但离"吃透"还差得远：
- 长周期项目的一致性。 短期任务它做得很好，但一个跨越几个月的项目， 怎么保证三个月前定的架构今天还在被遵守？现在我靠文档补，很笨重。
- 生成代码的长期可维护性。 能跑、能读、结构漂亮，是三件事。半年后回来改的时候会不会骂人， 这个账还没到期，现在下结论太早。
- 什么时候不该用它。 两行的改动、需要精确控制内存布局的地方、我自己比它更清楚上下文的角落—— 这些场景写提示词的成本比直接写还高。这条边界我现在还是靠感觉。
- 判断力的训练。 不逐行写代码之后，"这段代码有问题"的直觉该怎么练？ 这是我觉得未来几年最关键、也最没有标准答案的一题。
写在最后
回头看，这段时间最大的收获不是效率提高了多少—— 说实话效率提升是有的，但不是最值钱的部分。
最值钱的是"我想做个东西"到"它真的在跑"之间的距离变短了， 短到我开始愿意去碰那些以前觉得"太麻烦了算了"的想法。 一个物联网平台的想法，从方案到上线撑起真实设备， 中间隔的时间比我预想的短太多。
与此同时我也比以前更清楚它的边界在哪： 它会检索，但不验证；它给选项，但不担责；它记得很多，但不记得你没写下来的东西。
所以这篇叫复盘，不叫教程。 链路是跑通了，AI 这门课还在吃透的过程中。 下一阶段的重点大概会从"怎么用"转向"怎么管"——怎么管上下文、 怎么管验证、怎么管一整个项目的长期健康度。
等有新的体会了，再来写。