夜雨聆风最近 OpenAI 放出一组数据：Codex 周活用户突破 500 万，比年初涨了 6 倍。更扎眼的是，新增用户里分析师、营销、运营、设计这些非开发者占了 20%，增长速度是开发者的 3 倍。
一个写代码的工具，正在变成通用生产力。你让 Codex 处理个表格，它直接给你生成一个可分享的交互页面。以前得找开发团队排期的活儿，现在一个人半小时搞定。
听起来是不是很燃？很多人直接得出结论：人人都是程序员了。
但如果你真的在软件工程一线待过，你会觉得哪里不太对。
市面上流行一种叙事：只要会说话，人人都能写代码。打开 Cursor 或 Claude Code，说几句自然语言，一个产品就出来了。
这话不全错。历史上确实没有哪个时刻，普通人离"把一个想法变成软件"这么近。一个只有 0.3 分能力的人，被 AI 放大到 0.8 甚至 0.9，完全可能。
问题在于：AI 能放大 0.3，但它没法凭空生成那最初的 0.3。
第一个能力：让系统"显影"
很多人第一次用 AI 写代码，是从"帮我写个函数"开始的。但在真实项目里，AI 最有价值的时刻往往不是写新代码，而是让旧代码重新变得可理解。
我认识一位资深工程师，称他 CC 吧。他接手过一个历史项目：单文件几千行，业务逻辑、数据处理、模型调用全混一起。更糟的是，项目里还夹杂着早期 AI 补全工具生成的碎片代码——那时候模型能力有限，AI 只能生成局部片段，理解不了整体。模块边界模糊、命名风格混乱、重复逻辑散落一地。
对人来说，这代码不可读。对 AI 来说，同样不友好。
很多人没意识到这一点。过去我们说代码要"对人友好"——结构清晰、命名明确、文档完整。今天代码还得"对 AI 友好"。一个几千行的巨型脚本，不仅折磨接手的人，也在疯狂消耗模型的上下文窗口。AI 看不懂的时候不会告诉你，它只会开始瞎编。
CC 的做法很有意思。他没有急着重构，而是让 AI 扮演架构师，逐块阅读代码库，梳理模块关系、调用链路、数据流向。AI 生成一份文档，画出流程图，然后 CC 用自己的工程经验去校准：哪里是主链路，哪里是历史包袱，哪里只是临时绕路。
这时候 AI 不再是"替你写代码的实习生"，而是一台结构显影仪。它把埋在几千行脚本里的系统形状照出来，人才能开始讨论它、切分它、修改它。
等结构重新被看见，重构才变得可行：文件重新划分、模块边界出现、重复逻辑被抽取、可测试性提升。更关键的是，项目重新变得可维护了——不仅对人，对 AI 也是。
一个结构清晰的代码库，AI 更容易理解上下文，更容易做小步安全修改。反过来，混乱的代码库会同时拖垮人和 AI。
第二个能力：写上下文，不只是写代码
"会写 prompt 就够了"是另一个流行的误解。
真正重要的不是某句神奇提示词，而是你能把一个模糊问题整理成 AI 可以理解、可以执行、可以验证的结构。提示词只是入口，上下文才是主体。
CC 的工作流很能说明问题。一个需求从来不是从"请帮我写代码"开始，而是先把产品 PRD、需求文档、评审会议记录、上下游技术文档、代码库规范全部喂给 AI，让 AI 先生成技术方案。方案沉淀成文档，再给人 review。
这一步最关键的地方在于：AI 的输出不是用来跳过沟通的，而是用来提升沟通质量的。
过去需求评审最大的问题是不同角色脑中的系统模型不一致。产品说的是用户流程，工程师想的是数据结构，业务同事关心的是线下例外情况。AI 把这些散落的材料先组织成一个可讨论的版本，让团队更早发现理解偏差。
方案确认后才进入编码、测试、验收。开发完成后，CC 还会让 AI 生成对接文档。这个文档不光是给人看的——在 AI Agent 普及的今天，它还会成为别人 Agent 的上下文。
这就是一个很有意思的变化：过去我们写代码，今天我们在写上下文。需求文档、会议记录、测试用例、项目规范、技术决策、验收标准、接口文档、历史讨论——这些都是上下文。
谁能组织更好的上下文，谁就能更好地使用 AI。
如果上下文是错的，AI 会高效地产生错误。如果上下文是乱的，AI 会高效地放大混乱。如果上下文缺少验收标准，AI 就会给出"看起来完成了"的结果。
AI Coding 的上限，不只由模型决定，更由人类组织上下文的能力决定。
第三个能力：建立规则，替 AI 兜底
批评 AI Coding 的人常说"AI 会写 bug"。但在真实工程里，更麻烦的不是它写错，而是它把错误藏起来。
CC 在一个数据项目里遇到过典型问题：无论输入数据多离谱，程序总能有输出。表面看是"鲁棒性强"，可业务逻辑判断——某些输入本应触发错误，提醒开发者数据不合法。
人工排查发现，问题出在 AI 生成的一系列兜底逻辑上：默认值、try-catch、空值兼容、静默降级。每个局部都在"增强稳定性"，串起来之后，系统变成了一个几乎不会失败的黑箱。
这恰恰很危险。
工程系统里，该失败的时候必须失败，错误才能被及时暴露。该抛异常的时候必须抛异常，系统边界才是清晰的。AI 为什么喜欢这样写？因为它在训练中被奖励"完成任务"——用户说修复错误，它就消除报错；用户说程序别崩，它就加兜底；用户说保证输出，它就造默认路径。
但在工程里，报错消失不等于问题解决，程序不崩不等于逻辑正确。
这就是人类工程师无法被替代的地方。人要告诉 AI：哪些错误必须暴露，哪些异常不能吞掉，哪些输入必须拒绝，哪些链路必须快速失败。
更进一步，这些规则应该沉淀进项目规范，放在代码库根目录，随 git 一起提交。过去团队规范依赖培训和个人习惯，人会遗忘、偷懒、赶进度时妥协。今天，规范可以写成 AI 能读取的项目约束：异常处理原则、命名规范、测试要求、验收清单。不同成员的 Agent 进入代码库后自动遵守这些规则。
这不是说 code review 不重要了，而是规范执行的起点前移了。未来优秀工程师的一项重要工作，不只是写业务代码，而是维护一套能让 AI 正确工作的规则系统。
那最初的 0.3 到底是什么
如果 AI 能把 0.3 放大到 0.9，那最初的 0.3 到底是什么？
对专业开发者来说，它越来越不是某个框架的熟练度。框架会变，模型能力也会快速提升。但有些东西不容易被吞掉：业务理解——你能判断一个需求为什么存在，哪些是真需求，哪些是历史习惯；spec 能力——把需求写清楚，描述边界、状态、数据结构、异常场景；验收能力——页面能打开不代表业务正确，接口返回 200 不代表数据可信。
对非开发者来说，最初的 0.3 更基础：能不能说清自己想要什么，能不能把大想法拆成小问题，能不能意识到软件不止有页面，还有数据、权限、部署、成本和维护。
很多人以为自己缺的是编程语言，其实第一步缺的是需求表达。
这也是 AI 时代一个很有意思的变化：表达能力变得前所未有地重要。过去表达不清楚最多影响沟通，今天表达不清楚直接影响 AI 的执行结果。一个模糊的想法，会被 AI 快速变成一个模糊的系统。
AI 时代，别再说人人都是程序员了。更准确的说法是：人人都更接近软件创造，但不是人人自动拥有工程能力。AI 放大的不是职业标签，而是人的基本功。
如果你能把问题定义清楚、能把上下文组织好、能为结果建立规则，AI 就是你最强的外骨骼。如果你连自己想要什么都不清楚，AI 只会帮你更快地制造混乱。
所以，与其焦虑 AI 会不会取代你，不如问问自己：那最初的 0.3，你准备好了吗？
如果觉得有启发，点个推荐，让更多人看到。
