夜雨聆风2026 年 4 月，我妈花了 2 周，用 Codex 写了一个家庭记账小程序。
她 60 岁，完全不会编程。
她花了 2 周跟 AI 聊了几十轮，最后真的交付了一个能跑的程序。她在家庭群里发截图，亲戚们都说"哇，你居然会写代码了"。
同一时期，我用 Claude Code 交付了一个公司级的后台系统。
从用户视角看，我们交付的东西"形式上一样"——都是能跑的程序。
声明：上文"我妈用 Codex"是虚构场景，但反映的是现实中正在大量发生的事——2026 年 4 月以来，大量非技术人员用 AI Coding 工具交付了能跑的产物。一个销售用 Cursor 写了个客户跟进系统，一个运营用 Codex 写了个数据抓取脚本，一个老师用 Devin 写了个作业批改工具。
但 3 个月后，我们交付的东西的"本质"完全不同。
AI Coding 让"不写代码的人"和"不会写代码的人"达到了"形式上一样"的结果——但本质完全不同。
一、3 个月后，分化开始了
先说我妈的小程序 3 个月后的状态。
第 4 周，她想加一个新功能——按月统计。她打开 Codex，问"怎么加按月统计"。
Codex 改了一通，原始的"按日"功能坏了。她又问怎么修复，修完按月又坏了。再问，再坏。
来回折腾 1 个月，最后她放弃了——整个程序变成"只读不写"的状态。能看不能用，想改改不动。
同一时期，我的系统 3 个月后是这样：
第 4 周要加一个新模块。我打开 Claude Code，把架构意图喂给 Harness。Harness 把新模块的"架构边界"明确化，AI 一次性交付 85%+ 符合设计意图的代码。我只需要验收"设计意图是否实现"，不看代码细节。
加新功能没破坏旧架构。
形式上，我妈的小程序和我的系统都"交付了一个能跑的程序"。本质上，差距已经拉开：
● 我妈的小程序：加新功能失败 / 异常直接崩 / 没人能接手 / 技术债堆积
● 我的系统：加新功能不破坏旧架构 / Harness 强制边界场景 / 架构清晰可交接 / 持续演化
决定这个差距的，不是"会不会写代码"，也不是"用的是什么 AI Coding 工具"——而是 Harness 在不在。
二、行业数据：3 个月内 Tokenmaxxing 崩盘
"我妈用 Codex"的故事不是个案。2026 年 3-6 月，整个硅谷经历了一场"AI Coding 用 token 砸出效率"的热潮，3 个月内就退烧了。
4 个真实崩盘案例
① Amazon：关掉内部 Kirorank 排行榜——员工刷榜让 AI 跑无意义任务，单纯把 token 消耗量刷上去
② Uber：95% 工程师月用 Claude Code，70% 提交代码来自 AI，每工程师月 $500-2000，4 月底烧光全年 Claude Code 预算
③ 微软：6 月底前取消大部分 Claude Code 内部授权，迁回 GitHub Copilot CLI
④ 迪士尼、Visa：加入 Tokenmaxxing → ROI 受质疑
4 家大公司，同一个剧本：先用 token 砸出"AI 用量"，再发现"用量 ≠ 产出"。
Berkeley 的 2.6% 通过率
加州大学伯克利分校联合 250 多名行业专家在 6 月发表了《Agents' Last Exam》（arXiv 2606.05405）。他们测试了制造、法律、医疗、视觉媒体等 55 个子领域、1400 多个真实专业任务。
结果：
主流系统平均完整通过率仅 2.6%，最好配置也才 8.6%。
研究团队对 Claude Code + Opus 4.7 的失败案例做了系统性归因分析：
● 75% 失败归因于"理解"层（31%）和"策略"层（47%）
● 只有 22% 是执行层错误（代码 bug、格式错误、GUI 操作失败）
AI 不是"手脚不灵"，是"脑子里没有行业 know-how"。它不知道注塑模流分析该跑哪些步骤，不知道胸片判读的流程是什么，不知道管弦乐转谱要交付哪些文件。
MIT：代码产量 ≠ 用户使用量
MIT 5 月发表的《Writing Code vs. Shipping Code》（NBER w35275）用了 10 万多名 GitHub 开发者的数据：
AI Coding 推动了新 app 数量增长，但没有带来总使用量增长。
也就是说，市场上 app 变多了，用户并没有因此多用软件。供给增加了，需求没有同步扩大。
三、J 型增长曲线：为什么"3 个月崩盘"是必然
为什么 3 个月崩盘是必然？这背后有经济学解释。
J 型曲线
技术进步带来的市场增长往往呈 J 型曲线：
① 初期：技术上线，生产率下降（企业在付学习成本）
② 拐点：组织、设备、流程、技能同步改变
③ 上升：J 型曲线的回报才显现
3 个月崩盘的就是 J 型曲线的下探部分。
Token 消耗越来越多，算力和软件支出越来越高，但有效产出并没有同步增长。企业一边支付技术成本，一边支付组织改造成本，统计上的生产率甚至可能下降。
只有当数据、流程、人员、评测和责任体系逐渐成熟后，前期投入才可能开始产生回报。
可替代性理论
复杂产品是由一组互补要素共同决定的，任何一个要素都能成为瓶颈。代码生产效率提高 100 倍，如果企业连需求都说不清楚，整个项目的效率很难提升。
Agent 一天可以生成一千个方案，如果人类只能审核十个，多出来的九百九十个方案不是产出，而是待处理库存。
我妈用 Codex 写的小程序，本质就是"待处理库存"。
没有 Harness 沉淀约束，每加一个新功能，AI 就有一万种"实现方式"——这些方式大部分会跟旧功能冲突，最后变成改 A 坏 B 的死循环。
四、三个真实路径：小白 / 工程师 / 架构师
3 个月崩盘有三种不同的路径：
路径 A：小白用 Codex（我妈）
直接用 → 交付能跑的程序 → 加新功能失败 → 放弃
原因：无 Harness 沉淀 → 每次从零开始 → 改 A 坏 B → 技术债堆积
路径 B：工程师用 AI Coding（Amazon/Uber 内部员工）
KPI 激励用 AI → 刷榜让 AI 跑无意义任务 → 表面"AI 用量大" → 实际生产率不增 → 撤榜
原因：有 Harness 但没机制约束"什么时候该用 AI、什么时候不该" → 滥用
路径 C：架构师用 Harness + AI Coding（我）
明确架构意图 → Harness 沉淀约束 → AI 在约束内交付 → 一次性成功率 85%+ → 系统持续演化
原因：有 Harness + 有机制 = 双层收敛
三条路径里，只有路径 C 越走越好。A 和 B 都在 J 型曲线的下探部分挣扎。
五、三个错的关键认知
错 1：AI Coding 让编程门槛归零了
反例：实现门槛降了，工程门槛没降。
写代码 ≠ 软件工程。你交付一个能跑的程序很容易，交付一个能演进的系统很难。
错 2：AI Coding 让小公司可以替代大公司
反例：小公司用 AI Coding 交付功能快 → 但交付"一次性功能"；大公司用 Harness + AI Coding 交付"持续演进的系统"。
短期看小公司快，长期看大公司稳。
错 3：Token 越多 = 效率越高
反例：Uber 月烧 $500-2000/人 → 4 月底烧光全年预算。
Token 不是越多越好，要有 ROI 收敛机制。
六、给不同角色
给个人开发者
不要再用"AI Coding 让我快 10 倍"叙事。
真实问题是：你的 Harness 在哪里？
没有 Harness 的 AI Coding ≈ 不会编程的人 + Codex = 形式上一样。
给 Tech Lead
不要再纠结"团队成员会不会用 AI Coding"。
真正要解决的是：团队的 Harness 沉淀机制是什么。
没有 Harness 的 AI Coding 用得越多，技术债越多。
给老板
一个会用 AI Coding 的工程师 ≠ 一个产出高 10 倍的工程师。
真正的杠杆是：让团队有 Harness，让"一次性功能"变成"可演进系统"。
否则你只是在买一个能跑的程序，不是在买工程能力。
七、所以我真正想对我妈说的话
"我妈用 Codex"的故事有虚构成分，但她代表的是一类人——没有架构能力、不懂工程、但被 AI Coding 赋能的普通用户。
他们交付了功能，但他们交付的不是"系统"。
系统的特征是：
● 明天加一个功能不会破坏昨天的功能
● 下一个人能接手维护
● 三个月后还能记得当初为什么这样设计
● 错误处理、边界场景、安全性都在设计时被考虑
Harness 就是让 AI 交付从"功能"升级到"系统"的关键基础设施。
没有 Harness，AI Coding 让每个人都能"写代码"。
有了 Harness，AI Coding 让每个团队都能"构建系统"。
八、一个开放问题
Tokenmaxxing 退烧之后，下一步是什么？
我的判断：
① 短期（6-12 个月）：Harness 工程化（系列五 + 系列十一）
② 中期（1-3 年）：组织级 AI 系统（Harness + 知识库 + 评测体系）
③ 长期（3 年+）：AI 时代的"软件工程"重新定义——不是"写代码"，而是"设计可演进的系统"
最后留一个开放问题给你：
如果"AI Coding 让小白也能交付功能"，那"专业开发者"的核心价值到底是什么？
我的答案：设计可演进的系统，让 Harness 把"功能交付"升级成"系统演化"。
你呢？
📚 素材溯源：
① 36 氪《Tokenmaxxing 3 个月崩盘》—— Amazon / Uber / 微软 / Disney / Visa 真实数据
② UC Berkeley《Agents' Last Exam》(arXiv 2606.05405)—— 1400+ 任务，主流系统 2.6% 通过率
③ MIT《Writing Code vs. Shipping Code》(NBER w35275)—— 10 万 GitHub 开发者数据
④ 康奈尔《AI and the Quantity and Quality of Creative Products》(2026-01)—— 内容市场需求天花板
⑤ J 型曲线 + 可替代性理论—— 来自 36 氪那篇的引用
⑥ Chad 自己的 Harness 实践—— 来自系列十 #1《Claude Code 6 个月真实记录》