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

URL: https://caijiao.org/posts/131
Source: docs/posts/131.md
Description: Omni Calculator 的广告负责人说"页面速度对我们没有商量余地"。这类"什么必须为真"的清单才是 AI 之后剩下来的工作，加上 Google 已把规模化内容滥用列为整站信号，而这四件事没有一件能外包出去。

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

![Omni Calculator 计算器分类页截图](/images/2026-09/omnicalculator.com.png)

*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](/json-ld/) 的实现部分值得单独过一遍；收录和索引的基础机制在 [Google Search Central](/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](/webassembly/)，服务器只发文件。10015.io 靠这条原则撑住了 50 多个工具。

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

## 换个说法

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

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