用 AI 开发越久，我越不敢省流程

我现在用 AI 改自己的博客，功能、样式、翻译、部署，都让它参与。

方便是真方便。但做下来，我反而更确定一件事：代码可以让 AI 写，开发流程不能跟着省。

拿未一博客来说。字体看着挤，就改字体；手机上表格看不全，就修表格。这类调整，需求直观，改完打开页面看看，基本能判断效果。

可一旦涉及多语言、统计和后台接口，事情就不一样了。页面正常，不代表功能正确；构建通过，也不代表线上没有问题。

我吃不准的地方，不让 AI 自己补答案

博客做六语种，看起来就是把中文翻译成另外五种语言。

真做起来，远不止这些。

中文原来的链接不能变，各语言要有独立地址，切换语言得去对应文章，不能一点击就回首页。搜索、分类、分享提示也要跟着切换。阿拉伯语从右往左排，碰到代码和英文型号，还得处理混排。

这些事情，你不说清楚，AI 可能也能交出一个“多语言网站”。只不过，它理解的完成，和我要的完成，不是一回事。

所以现在碰到这种任务，我会先把边界定下来：哪些必须保留，哪些需要一起改，最后看什么来验收。

不用写几十页文档。把关键几条说清楚，后面能少绕很多路。

不能拿一句模糊的需求，换一堆具体但未必正确的代码。

博客的统计脚本就很典型。

之前为了减少页面加载负担，统计脚本做过延迟加载。单看性能，这个方向不难理解。但统计有自己的要求：用户很快离开时，延后的脚本可能还没执行；平台的安装检测，也可能因此判断不准。

后来，百度统计和 GA4 恢复了在页面头部异步加载的方式。

这件事让我更在意一个问题：让 AI “优化一下”，到底优化什么？

加载速度、统计完整性、搜索表现、维护成本，不一定总能一起变好。目标不说清楚，它很容易朝着一个局部指标使劲。

分数可以参考，网站得让人用着舒服。统计也是一样，不能为了少加载一点东西，把该记录的访问漏掉了。

而且，检查线上源码里有没有脚本，和确认统计后台有没有收到真实事件，是两件事。前一项通过，不能顺手把后一项也算完成。

AI 写得快，很容易让人顺手加需求：

既然都改了，把移动端也调一下，旧代码清一清，接口顺便重构。

每一项单看都合理，放在一起就麻烦了。改动越大，越难判断是哪一处出了问题，也越难退回去。

我现在更认可的做法是，一次围绕一个目标改。字体就看阅读体验，表格就检查不同屏幕，统计调整就核对加载方式和线上结果。

DORA 在 2026 年 3 月的一篇分析里提到，AI 省下来的编码时间，经常会重新花在审核和验证上。

这和我的判断一致。代码出来得快，不代表人能同样快地看懂、确认。一次丢过来几十个文件，光弄清楚它改了什么，就不轻松。

小步改动不是浪费 AI 的能力，是控制我自己的验证成本。

AI 最容易让人放松警惕的，是它会很认真地告诉你：已经完成，测试通过。

我现在更关心后半句：做了什么测试，证明了什么？

构建通过，可以排除一部分问题，但证明不了手机上的表格没有被截断。接口返回正常，也证明不了用户从页面进去，能完整走完操作。

Anthropic 的长任务 Agent 实践也记录过类似问题：模型会在缺少充分测试时，把功能标记为完成。他们后来补上功能清单、进度记录和端到端验证。

所以，AI 可以负责执行，验收标准要提前有。

对我的博客来说，本地改完、构建通过、部署成功、线上核验，是不同的状态。不能因为前面几步顺利，最后一步就省了。

我不是要给个人博客搬一套大公司的审批制度。

字体改一点，没必要开评审会。涉及链接结构、后台接口或者数据，就得多想一步：影响哪些地方，怎么验证，出问题怎么恢复。

这就够了。

我用 AI，是为了少做重复劳动，把原来嫌麻烦的事情做起来。不是为了得到一个代码更多、自己反而更不敢碰的项目。

所以现在我判断一次开发做得好不好，不太看 AI 多快写完，而是看：需求有没有落实，改动能不能看懂，线上有没有核验，后面还好不好维护。

代码让 AI 多写，关键的判断和检查，一项都别糊弄。