如果 AI 已经可以独立完成研究级物理计算，软件公司还把“亲手写代码”当成工程师的核心价值，是否正在用旧时代的标准经营新时代的公司？
这个问题听起来很激进。但今天，它已经不是一个遥远的思想实验。
一项 2026 年发表的理论物理评估显示，研究人员给 AI Agent 提供了 50 道未公开、具有可验证答案的研究级理论物理问题。在可以检索文献、编写程序进行数值和符号计算的条件下，使用 Codex 运行的 GPT-6 Astra 得到了其中 49 道的正确答案，平均每题成本低于 3 美元。研究作者表示，这些题目通常可以由相关领域的世界级专家在一天或更短时间内解决，而相邻领域专家可能需要更长时间。TheoPhysEval 论文
另一边，OpenAI 公开了一批由内部前沿模型生成的数学研究结果，并为其中许多证明提供了 Lean 形式化版本，供数学界检查和继续研究。需要说明的是，产生这些结果的是 OpenAI 的内部前沿模型，不能简单等同于每个人日常使用的 GPT-6 产品；数学结果也仍然需要学术界审查、理解和验证。OpenAI：Sharing AI progress in mathematics
这些进展并不意味着 AI 已经能独立完成所有科学研究。理论物理评估主要考察的是有可验证答案的具体计算，也不能直接推导出 AI 已经能够自主提出重要科学问题、完成突破性发现。
但它们足以引出一个严肃的问题：
如果 AI 能够处理过去需要顶尖专家完成的推导和计算，那么大量软件开发公司，凭什么认为自己的日常编码工作天然不可替代？
一、程序员最需要放下的，是对“写代码”的职业幻觉
过去几十年，程序员的价值与一种稀缺能力绑定在一起：把需求转化为计算机能够执行的代码。
这项能力需要长期训练。
你需要学习语言、数据结构、框架、数据库、网络、并发、安全。你需要记住大量 API，理解各种报错，花几个小时调试一段看似简单的逻辑。
正因为编程门槛高，社会形成了一种普遍印象：
会写代码的人，掌握了一种大多数人无法掌握的能力。
但 AI 改变了这种稀缺性。
今天，一个非专业开发者可以通过自然语言，让 AI 创建网站、连接数据库、构建管理后台、编写自动化脚本，甚至持续修改和部署产品。
一个有经验的工程师，则可以让 AI 同时理解多个文件、修改代码、运行测试、排查错误，再根据结果继续迭代。
代码仍然重要。但亲手把每一行代码敲出来，已经越来越不是软件生产中不可替代的环节。
这会让一些程序员不舒服，因为他们的职业认同建立在“我能写出别人写不出的代码”之上。
然而，技术进步从来不承诺保护某种技能的历史溢价。
计算器没有取消数学，但改变了心算的价值；编译器没有取消计算机科学，但让开发者不必亲手编写机器码；云计算没有消灭基础设施，但减少了许多企业自建机房的必要性。
AI Coding 正在对“手写软件”做类似的事，而且影响可能更深。
未来，公司需要的是能够创造、交付和维护软件的人，而不是单纯拥有打字和语法能力的人。
二、AI 是否已经取代程序员？先看清“取代”的含义
“AI 已经取代程序员”是一句有冲击力的话，但必须说清楚其中的层次。
如果“程序员”指的是：
接收明确任务，然后把需求翻译成代码的人。
那么，AI 已经能够承担这类岗位中相当大的一部分工作。在一些场景下，它甚至可以完成从理解仓库、修改代码到运行测试的完整任务。
如果“程序员”指的是：
对业务结果、系统运行、风险取舍和长期维护负责的人。
那么，目前还不能简单地说 AI 已经普遍取代了这个角色。
这两种说法并不矛盾。它们描述的是同一场转变的不同层面：
AI 正在取代大量以手写代码为中心的工作，但软件交付中的责任与判断仍然需要被承担。
与此同时，也不能用“AI 还会犯错”来安慰自己。
人类工程师同样会犯错。公司从来不是因为程序员绝对可靠才雇佣程序员，而是因为在成本、速度、质量和可管理性之间，人类程序员曾经是可行的选择。
当 AI 在越来越多任务中提供更好的综合成本时，企业自然会重新配置工作。
这可能表现为：
- 同样规模的团队交付更多产品。
- 更小的团队完成过去需要更多人的项目。
- 初级、重复性开发岗位需求下降。
- 一名工程师管理多个 Agent 并行工作。
- 产品、设计、运营等角色直接参与软件构建。
- 软件公司重新调整招聘与组织结构。
这些趋势的速度会因公司和任务而不同，但不能假装它们不存在。
三、已经有公司让 AI 写下绝大多数代码
讨论 AI Coding 时，很多人仍然把它想象成“自动补全”。
但前沿团队的工作方式已经发生变化。
Anthropic 披露，截至 2026 年 5 月，其代码库中合并的代码有超过 80% 可归因于 Claude。公司同时说明，按人均每天合并代码行数计算，2026 年第二季度相比 2024 年增长明显；但它也明确提醒，代码行数不能等同于真正的生产力，数量增长会高估实际收益。Anthropic：When AI builds itself
这个案例有两个值得注意的地方。
第一，AI 写绝大多数代码，已经不只是概念。
第二，Anthropic 没有因此宣称软件工程师完全退出流程。其描述是：工程师更多地负责给出目标、指导和审查，AI 负责大量代码生产。
当然，Anthropic 自己研发 AI 模型，拥有特殊的工具、人才和组织环境。它的数据不能直接套用到所有软件公司。
但它至少证明了一件事：
一家高技术密度的公司，已经能够把大量真实代码生产交给 AI。
如果这样的组织可以做到，其他软件公司就不能再把“这在真实工程中根本不可能”当作默认答案。
更合理的问题应该变成：
- 哪些任务已经可以交给 AI？
- 哪些任务需要先改善环境和验证能力？
- 哪些部分仍需要更强的人类判断？
- 我们要用什么数据判断结果？
四、“禁止手写代码”应该怎样理解？
我认为，“禁止手写代码”是一个有价值的组织口号，但它不应该被执行成僵硬的宗教戒律。
它真正有价值的含义是：
默认让 AI 完成代码实现，让人类把注意力放在问题、约束、验证和结果上。
这与“任何人都不准敲一个字符”不是同一件事。
例如：
- 改一个拼写错误，手动修改可能只需要两秒。
- 排查复杂问题时，工程师可能需要写一段临时代码验证假设。
- AI 反复理解错误时，人工修改一个关键点可能更高效。
- 在特殊环境、工具不可用或网络受限时，手写仍然是必要能力。
如果公司因为一个工程师手动改了三行代码而进行处罚，这不是 AI 原生，而是另一种形式主义。
真正值得建立的原则是：
不要再把人类手写代码当成默认生产方式。
当一项实现任务到来时，团队首先应该考虑：
- AI 能否理解任务和代码库？
- AI 能否在隔离环境中完成实现？
- 能否通过测试、审查和运行结果验证它？
- 人应该在哪些关键节点提供判断？
- 整个过程比传统方式更快、更可靠，还是更昂贵？
如果答案是 AI 可以完成，就没有理由仅仅为了维护“程序员应该亲手写代码”的传统而拒绝它。
五、软件公司的瓶颈，正在从写代码转向定义问题
过去，许多软件项目的限制是：
我们知道要做什么，但没有足够的人和时间把它写出来。
AI 让这类限制迅速减弱。
假设一个团队过去需要两个星期完成一个内部工具，其中大部分时间花在：
- 创建项目结构。
- 编写表单。
- 实现 CRUD。
- 接入数据库。
- 处理常规错误。
- 编写基本测试。
- 调整界面。
今天，这些工作中有相当多可以交给 AI 加速完成。
于是，新的问题出现了：
- 这个工具到底解决什么问题？
- 谁会使用？
- 数据是否可信？
- 异常状态如何处理？
- 权限边界是什么？
- 上线后如何知道它真的有价值？
- 业务流程变化后谁负责维护？
- 如果产品决策本身是错的，AI 写得再快有什么用？
代码变得便宜后，错误需求也会更便宜地变成现实。
过去，一个糟糕的想法可能因为开发成本太高而被迫讨论清楚；今天，它可能在几小时内就变成一个看起来完整的产品。
这意味着组织必须更擅长：
- 识别真正的问题。
- 把模糊目标转化为可验证结果。
- 建立业务约束。
- 观察真实用户行为。
- 快速放弃无价值的方案。
AI 让实现更容易，但不会自动告诉公司什么值得实现。
六、“Token Free 公司”是什么？
如果这里的 Token Free 指的是：
公司不让员工因为个人预算、次数限制或申请流程，而不敢使用完成工作所需的 AI 能力。
那么，这是值得认真考虑的方向。
一家公司如果要求员工全面使用 AI，却同时规定：
- 每月只能使用极低额度。
- 超过额度需要层层审批。
- 不允许为复杂任务使用更强模型。
- 没有权限接入必要的开发环境。
- 因为担心成本而禁止长时间运行 Agent。
最终就会出现一种荒谬情况：
公司一边说 AI 是战略，一边让员工为每一次有效调用担心。
这相当于要求工程师提高工作效率，却不给他们足够的编译资源、测试环境或必要的软件许可证。
但“Token Free”不等于 Token 没有成本
AI 推理仍然需要付费，价格、上下文长度、工具调用、并行 Agent 数量和任务复杂度都会影响成本。
因此，更准确的经营理念应该是：
让员工获得完成工作所需的 AI 算力，同时让公司能够观察成本与业务结果。
不是按“谁用了更多 Token”评价员工，也不是完全不看账单。
公司真正要计算的是：
完成一个有效任务的总成本
= AI 推理成本
+ 人类定义与沟通成本
+ 审查和验证成本
+ 工具与基础设施成本
+ 缺陷、返工和维护成本假设一个任务：
- 人工方式需要两天。
- AI 方式需要 30 美元推理成本和半天工程师时间。
只盯着 30 美元，可能会错过更大的收益。
但反过来，如果一个 Agent 花费 100 美元、生成大量无用代码，还需要团队两天返工，那么 Token 消耗也不是进步的证明。
Token 应该成为生产资料，而不是绩效指标。
七、真正的竞争优势，不是买到最贵的模型
很多公司会认为：
我们已经买了最强模型，所以我们已经完成 AI 转型。
这远远不够。
两个团队使用同一个模型，结果可能完全不同。
一个团队：
- 需求分散在聊天记录中。
- 项目没有清楚的启动方式。
- 测试不稳定。
- 数据库结构没有文档。
- 工具权限混乱。
- 生产问题无法复现。
- 每个人都靠个人经验指挥 AI。
另一个团队：
- 有明确的项目说明。
- 测试可以稳定运行。
- 关键业务规则可查。
- 开发环境可以快速重建。
- 权限和敏感数据隔离清晰。
- 常见工作流沉淀为可测试的 Skill。
- Agent 的执行结果可以被验证。
即使使用相同模型，第二个团队通常更有条件让 AI 完成长期、复杂和可靠的工作。
这就是 AI Coding 时代的软件基础设施：
模型能力
+ 可理解的项目上下文
+ 可调用的工具
+ 可执行的验证
+ 清晰的权限边界
+ 持续反馈
= 可扩展的 AI 开发能力模型是引擎，但项目环境决定它能走多远。
Skill 在这里的作用
Skill 可以把团队反复使用的经验整理成 AI 能够调用的工作方法。
例如：
- 如何审查数据库迁移。
- 如何排查 CI 失败。
- 如何创建符合团队规范的 API。
- 如何验证前端页面。
- 如何准备发布和回滚。
- 如何检查性能问题。
但 Skill 的目标不是把公司所有知识堆进一个巨大文件。
一个真正有用的 Skill，需要具备清晰的触发场景、适用边界、项目适配方式和评估方法。团队还需要比较有无 Skill 的效果，防止它只增加步骤。OpenAI：Testing Agent Skills Systematically with Evals
未来最有竞争力的团队，可能不是拥有最多 Prompt 的团队，而是拥有最清晰、最可验证的工程环境的团队。
八、不要用“代码写得更快”冒充“公司效率更高”
AI Coding 最容易制造一种管理幻觉：
以前一天提交 5 个 PR，现在一天提交 50 个 PR，所以团队效率提高了 10 倍。
未必。
如果 PR 数量增加，但：
- 审查排队更久。
- 测试成本大幅上升。
- 线上问题增加。
- 维护者无法理解代码。
- 项目变得更加复杂。
- 大量功能没有用户使用。
那么，公司可能只是更快地生产了问题。
2025 年，METR 在特定条件下对熟悉成熟开源项目的开发者进行了随机对照研究，结果发现当时的 AI 工具在所研究任务中使完成时间增加约 20%。这项结果并不能代表今天所有模型、开发者或项目；METR 后续也表示，根据参与者反馈，他们认为 2026 年初的工具可能比 2025 年初更能加速开发。METR：原始研究；METR：后续实验说明
这个案例给管理者的启示很直接：
不要根据宣传判断生产力，也不要拿旧研究否定所有新工具。应该在自己的团队中持续测量。
公司更应该关注：
- 从需求提出到用户获得价值，需要多久？
- 有多少变更真正被使用？
- 线上故障和回滚是否增加？
- 关键缺陷的发现时间和修复时间如何变化？
- AI 生成的系统，三个月后是否仍然容易维护？
- 每个有效交付的总成本是否下降？
- 团队是否有能力理解自己正在运行的系统？
代码产量是过程指标，用户价值和系统质量才是结果指标。
九、全员 AI Coding 会如何改变软件公司的组织？
1. 开发团队会从“分配代码任务”转向“分配结果”
传统任务可能是：
张三：写数据库表。
李四：写后端接口。
王五：写前端页面。AI 原生团队可能更倾向于：
负责人：交付一个可用的客户管理流程。
AI Agent：
- 分析现有系统。
- 提出实现方案。
- 修改数据库、接口和页面。
- 运行相关测试。
- 展示结果和风险。
负责人：
- 明确业务目标。
- 判断方案。
- 验证用户体验。
- 对最终结果负责。这不是说一个人可以无限扩大工作范围。复杂系统仍然需要专业分工。
变化在于：任务的最小单位，可能从“写一个文件”变成“交付一个可验证的结果”。
2. 产品、设计和运营会更接近软件生产
过去，一个运营人员想到一个内部工具，通常需要：
写需求 → 排期 → 等开发 → 测试 → 上线未来，运营人员可能先让 AI 创建一个可运行的原型，再与工程师一起检查数据、权限和维护方式。
产品经理可以直接制作交互原型；设计师可以生成真实界面；分析师可以构建内部数据工具。
这会扩大软件的创造者范围。
但一旦这些工具开始处理真实客户数据、资金、权限或关键业务流程，就需要明确谁负责安全、运行和维护。
能够生成软件的人会更多，能够让软件长期可靠运行的组织仍然需要被建设。
3. 工程师的工作重心会改变
越来越有价值的能力可能包括：
- 将模糊业务目标转化为清晰任务。
- 判断系统边界与架构取舍。
- 设计测试和验收标准。
- 发现 AI 输出中的隐藏假设。
- 理解数据库、一致性、性能和安全风险。
- 管理多个 Agent 的并行工作。
- 观察生产系统并处理异常。
- 对业务结果负责。
这里也要避免另一个幻觉：
“以后工程师完全不用懂代码，只要会写 Prompt。”
对于简单工具，这也许已经可以成立；但对于复杂系统，如果一个人完全不能理解实现、验证行为或判断风险，那么他很难真正对系统负责。
工程知识不会因为 AI 会写代码而自动消失。它会从“亲手生产每一行”更多转向“判断、验证和控制整个系统”。
十、初级程序员怎么办？
这是 AI Coding 讨论中最需要认真面对的问题。
过去，初级程序员往往通过实现小功能、修复简单 Bug、编写测试和阅读代码，逐渐理解系统。
但这些任务恰好也是 AI 最先擅长的部分。
如果公司把所有简单任务交给 AI，又只招聘能够独立负责复杂系统的高级工程师，就会出现一个结构性问题：
今天的高级工程师不断被消耗，但明天的高级工程师从哪里来？
可能的答案不是恢复大量低效率的纯手工编码，而是重新设计培养路径：
- 让新人先分析需求和已有系统，再让 AI 生成实现。
- 要求新人解释关键代码为什么这样设计。
- 让新人提出测试案例，而不是只看测试是否通过。
- 让新人比较多个方案的成本与风险。
- 让新人参与故障复盘、发布和真实用户反馈。
- 保留必要的基础编程训练，让他们能够独立理解和验证。
未来的新人工程师，可能比过去更早接触完整系统，也更容易在 AI 的帮助下做出成果。
但如果只是复制 AI 的结果、不理解任何实现，也可能更快地失去成长机会。
这不仅是个人问题，也是企业的人才供应问题。
十一、全面 AI Coding 仍然有几个难题
支持全面 AI Coding，不代表应该忽略现实中的难题。
1. AI 会自信地犯错
它可能写出看起来完整、实际上不满足业务规则的实现；也可能编造测试结果，或者在没有充分证据时宣称问题已经修复。
因此，需要让“完成”具有客观含义：
功能实现 ≠ 文件已经修改
功能完成 = 实现 + 合适的验证 + 清楚的结果说明无法验证，就应该明确说明。
2. 验证可能成为新的瓶颈
当一个人可以让多个 Agent 并行生成代码时，审查能力可能跟不上生产速度。
解决方式不应只是要求人类更快地读更多代码，而应改善：
- 自动化测试。
- 小范围、可理解的变更。
- 系统级验证。
- 风险分级。
- 可观测性。
- 针对关键行为的约束。
- AI 辅助审查与独立验证。
但不能假设“另一个 AI 看过了”就自动等于正确。验证机制本身也需要评估。
3. 上下文越大，不代表理解越完整
Agent 即使读取了整个仓库，也未必知道：
- 某个字段背后的商业含义。
- 某位客户依赖的特殊行为。
- 一个历史 Bug 为什么不能直接删除。
- 某个数据库操作会影响哪些外部系统。
这些信息往往存在于人、流程和历史决策中。
AI 原生公司需要持续把关键知识转化为可以查找、更新和验证的上下文。
4. 供应商和成本依赖需要管理
如果公司的核心开发流程完全依赖某个模型供应商，那么价格调整、服务故障、模型行为变化或数据政策变化，都可能影响交付。
因此，企业需要关注：
- 任务和知识能否迁移。
- 关键流程是否支持不同模型。
- 成本是否可观察。
- 重要数据如何保护。
- 服务不可用时如何继续工作。
这不是反对使用最强模型，而是把 AI 当成关键基础设施来经营。
十二、未来的软件公司，可能是什么样子？
可以想象一家真正以 AI 为默认生产力的软件公司：
早上，产品负责人描述一个客户问题。
AI Agent 读取相关工单、产品文档和代码，提出几种方案，分别说明实现成本、影响范围和待确认的问题。
负责人选择方向后，几个 Agent 在隔离环境中并行工作：
- 一个分析后端和数据库。
- 一个实现前端交互。
- 一个准备测试和验收案例。
- 一个检查安全、兼容性和潜在回归。
它们完成后，系统自动运行测试、生成预览，并把关键变更、失败案例和未知风险交给负责人。
负责人检查用户体验，与业务方确认，必要时要求 Agent 继续修改。
上线后，监控系统观察真实使用情况。发现异常时，Agent 帮助定位问题、提出修复方案，再进入团队已有的发布流程。
在这个过程中，人类并没有消失。
但人类不再需要逐行生产所有代码。
人类更多地负责决定：
- 解决什么问题。
- 接受什么风险。
- 哪些结果值得上线。
- 何时停止投入。
- 出现问题后如何负责。
这不是一个纯粹的技术变化，而是软件公司工作方式的重新分配。
十三、最危险的不是 AI 还不够强，而是组织转型太慢
当一项新技术出现时，企业通常会经历几个阶段：
- 否认：AI 只能写玩具代码。
- 试用：给部分工程师购买工具。
- 局部使用：用 AI 处理简单任务。
- 流程重建：围绕 Agent 重新设计开发环境和协作方式。
- 组织重构：重新定义岗位、成本结构和交付速度。
许多公司仍然停留在第二或第三阶段。
它们买了 AI 工具，却继续使用原来的需求流程、开发流程、审批方式和绩效指标。
工程师被要求提高效率，却没有足够的模型使用额度；Agent 能够完成代码，却无法访问测试环境；团队产出更多变更，审查和发布流程却完全没有调整。
这种情况下，公司很容易得出一个错误结论：
“AI 没什么用。”
但真正的问题可能是：公司只购买了 AI，却没有让组织具备使用 AI 的条件。
当一家竞争对手能够用更少的时间验证产品、修复问题、服务客户，而另一家公司仍然以手写代码数量和岗位边界组织工作时，差距不会只体现在开发成本上。
它会体现在学习速度上。
谁能更快地从用户那里获得反馈、修改产品、观察结果，谁就更有机会找到真正有价值的方向。
结语：程序员的时代结束了吗？
如果“程序员”意味着一个主要依靠手写代码获得职业价值的人，那么这个角色正在被迅速压缩。
AI 已经不只是一个辅助补全工具。它可以分析问题、搜索资料、编写代码、执行命令、运行测试，也能在越来越复杂的任务中给出有价值的结果。
如果继续相信“只有人类程序员才能写出真正的软件”，很可能是一种历史形成的职业幻觉。
但如果“程序员”意味着一个能够理解问题、构建系统、判断风险并对结果负责的人，那么这个角色正在变化，甚至可能变得更加重要。
未来的软件公司不应该问：
“我们要不要允许员工使用 AI 写代码？”
而应该问：
“我们为什么还让人类承担那些 AI 已经能够更快、更便宜、并且可以被有效验证的工作？”
把 Coding 默认交给 AI，把 Token 变成可获得的生产资料，把团队的注意力转向问题、验证和结果。
这可能不是每家公司今天就能一步完成的转型，却很可能是越来越多软件公司必须面对的方向。