AI写代码之后，程序员真正需要做什么？

Omni Calculator 的广告负责人 Alexander Utz 说过一句话，我觉得可以直接当作答案的一半：“页面速度对我们没有商量余地，我们的整个增长都依赖 SEO，Core Web Vitals 直接影响排名。”

Omni Calculator 首页连 Sports 都单独分类，111 个计算器对应各类赛事和成绩换算。

这句话里没有一个字是关于怎么写代码的。它讲的是"什么必须为真"。

AI 接管了大部分代码产出之后，剩下来的工作可以概括成一件事：定义并守住那些必须为真的事情。

第一件：把"什么必须为真"写成清单

一个站上线前，有些条件是不能用"大概可以吧"带过去的：

页面的 HTML 在关闭 JS 之后还有没有内容——决定了搜索引擎拿到的是不是空壳。

每个工具是不是独立 URL——决定了页面矩阵存不存在。

上传的文件多久删除——决定了磁盘是固定值还是增长曲线。

写操作有没有串行瓶颈——决定了 SQLite 这类单写者方案还能用多久。

这些条目 AI 一条都不会主动列出来。它能写满足这些条件的代码，但前提是你先把条件说清楚。Omni Calculator 2026 年 6 月估算访问约 1429 万、支持 30 多种语言，把计算器抽象成配置、页面由模板生成——这种规模下，任何一条"必须为真"被破坏，影响都是全站级别的。

第二件：为批量产出负责

AI 让产出变成了批量的，而批量产出是有政策成本的。

Google 的垃圾内容政策里有几条现在必须知道：Scaled Content Abuse（4.6.5） 针对的就是大量生成、没有独立价值的页面；MC Created with Little Effort（4.6.6） 针对低投入的正文；Site Reputation Abuse（4.6.4） 针对寄生在他人站点信誉下的内容。更要紧的是，Helpful Content System 在 2025 年升级成了整站信号——不再是单页判定，一个部分的低质会拖累整个域名。

这几条和 AI 的关系很直接：AI 生成 200 个"工具页面"的速度，远快于你验证其中任何一个有价值的速度。用同一个模板改几个词批量产出，正是这几条政策瞄准的形态。

所以程序员要做的不是"生成更多"，是为每一份批量产出给出独立价值的证据——这个页面解决的动作是不是真的存在、是不是和别的页面重复。这件事只能人来做。

页面能不能被正确理解，还牵涉到结构化数据字段填得对不对，JSON-LD 的实现部分值得单独过一遍；收录和索引的基础机制在 Google Search Central 里讲得最权威。

第三件：守住会进排名的硬指标

Utz 那句话点出了身份变化：以前页面速度是"体验优化"，现在是排名因子。

Core Web Vitals 这类指标的共同特点是——代码看起来都对，但指标是错的。AI 生成的代码在功能上无可挑剔，却可能让首屏多加载 300 KB、让某个资源没有缓存头、让一次计算跑在了服务端。

能发现这些的不是 code review，是测量。所以这部分工作变成了：设定指标、持续观测、指标坏了就回滚。它是工程活，但是是那种 AI 做不了的工程活。

第四件：决定不做什么

JetBrains 的调研里 90% 的专业开发者每周至少用一次 AI 编码 agent。当生产代码变得便宜，稀缺的就不再是"能不能做出来"，而是"该不该做"。

两个参照：

10015.io 把"什么时候做什么"写成了硬门槛——50 个工具才写文章发社媒、64 个才上 Product Hunt、128 个才做 v2、256 个才做 v3。这些门槛在 AI 时代反而更重要，因为突破门槛的能力变强了。

Cakedesk 2025 年收到 44 个功能请求、完成 13 个。那 31 个没做的，就是这个产品在这一年里最重要的决策。

验收要落到具体动作，不能落到"看起来对"

AI 的产出几乎总是"看起来对"的：结构完整、命名规范、注释齐全。所以验收必须落到可执行的检查上，而不是阅读体验。

页面类：关掉 JS 看内容还在不在，看源码里有没有真实文本。

请求类：走一遍主流程看网络面板，确认没有意外的上传，确认静态资源带上了缓存头。

数据类：看慢查询日志，确认常查字段上有索引，确认写路径不会因为长事务阻塞。

收录类：查 sitemap 有没有覆盖新页面，查结构化数据的字段有没有报错。

这四类检查都可以在几分钟内做完，而它们覆盖的恰恰是 AI 最容易给出"功能正确但方向错误"的地方。把它们写成一份固定清单，每次提交前过一遍，比任何 prompt 技巧都稳，也比事后返工便宜得多。

还有一件：把活放对位置

最后一件事最具体，也最容易被 AI 带偏——判定每一块计算该在哪一端执行。

AI 的默认答案通常是服务端，因为语料里这类例子最多。但工具站的成本结构要求的是另一条路：能在浏览器跑的都留在浏览器，编解码和重计算走 WebAssembly，服务器只发文件。10015.io 靠这条原则撑住了 50 多个工具。

这个判断不在代码里，在架构里，而且改动代价极高——所以它必须在第一句提示之前就定下来。

换个说法

Andy Cloak 一个人在伦敦运营 Data Fetcher，600 个付费客户、MRR 23000 美元。这个产出对应的不是代码行数，是一连串"什么必须为真、什么可以不做"的判断。

AI 把写代码变成了廉价劳动，剩下的四件事——列清单、为批量产出负责、守指标、决定不做什么——没有一件能外包。你的项目里，这四件事现在有人负责吗？