2026.06.11 (四)

✨ GPT-5.5 的总结  

从面试中体感到的开发者角色变化,到 vibe coding 的局限和 harness engineering 的必要性,整理 AI 时代核心能力正从手写代码转向企划、设计、执行、反馈、上下文判断和领域理解的记录。

越来越像刻进身体里的范式转变

面试里钉下来的结论

今天面试里最刺进来的结论是这个。

开发者需要的能力重心,正在从亲手写代码,转向企划/设计/执行/反馈能力。

还要加上理解整体上下文所需的概念、领域知识和直觉。只是说“我会用 AI”远远不够。

一直在累积的感觉

这种感觉并不是今天才突然出现的。

在 GPT, o3, AGI, Humanoids… the Singularity Is Coming… 里,我写过把 GPT 感觉成外置大脑时的冲击。

在 A Shift in the Development Paradigm 里,我已经看到开发流程的一部分从写代码苦力转向借助 AI API 的“点击”。只是当时 context window 和 output token 的限制还很明显,所以最多像是简单 MVP。

所以我不是现在才发现 vibe coding 的局限。一开始就看到了。只是那条边界正以疯狂速度向后退。

之后在 Survival Guidelines for the AI Era 里,我试图抓住 AI literacy、上下文智能和人类判断。

在 The Level of VSCode Copilot AI Autocomplete 里,把企划意图写成注释交给 AI、读生成结构、批准应用的方式已经落到现实。

到了 Whether Claude Code or Codex, It Is a Garbage-Tier, Oblivious Genius.,问题更清楚了。不是 AI 会不会写代码,而是要怎样把这些没有眼力见的天才停住,关进验证循环里。

以就业市场的语言返回

这条线今天以就业市场的语言回来了。现在开发者被要求拥有带有商业感的企划、设计、执行和反馈能力。

生产力已经比过去月薪 500 万韩元以上的开发者还高,但工资却……唉。很难受。

所以这不是只在脑子里理解的变化,而是慢慢用身体挨到的范式转变。

写代码的时代结束了

亲手写代码不再是核心

粗暴一点说,现在 coding 能力已经没有以前那么重要了。

当然,学习 C、汇编、机器码能帮助理解系统结构。代码知识本身不会变得毫无价值。

但市场更看重的,已经不再是“能不能亲手实现”。

Python 曾经让大部分普通重复问题变成几行就能解决。现在 AI 正在对大量实现问题做同样的事。

抽象化的历史在重复

在 The Chicken Game Over Humanity’s Fate After the AI Boom 里,我曾经这样列过技术发展。

  • 终于造出火了!开心。(约 50 万年前)
  • 终于造出电了!开心。(1880 年代)
  • 终于造出计算机了!开心。(1940 年代)
  • 终于造出人工智能了!开心。(2010 年代)
  • 终于造出通用人工智能了!开心。(预计 2030 年代……?)
  • 终于造出超级智能了!开心。(2050 年代……?)

开发也差不多。

  • 电灯开关一按。(1880 年代)
  • 机器码一按。(1940 年代)
  • 汇编一按。(1940-1950 年代)
  • C 语言一按。(1970 年代)
  • Python 一按。(1990 年代)
  • 框架一按。(2000-2010 年代)
  • AI 一按。(2020 年代)
  • harness 一按。(2020 年代中期以后)

听起来像玩笑,但本质上就是抽象化的历史。

人类不断把更低层交给机器。每一次,不懂底层的人都会不安,能直接摸到底层的能力也仍然有价值。但市场中心最终会上移。

所以“coding 能力不重要”不是说完全不用懂代码,而是说它正在从开发中心被推开。

范式变了,评价标准也会变

现在动摇的不是一个工具,而是开发这件事本身的范式。

旧范式里,好开发者靠自己写好代码解决问题。新范式里,AI 生成代码,人类定义问题、提供上下文、设计执行环境、验证结果。

所以这不是“写代码更快了”就结束。它会一起动摇该学什么、该招什么样的人、什么教育还有用。

行业已经在看同一个方向

Vibe coding

Vibe coding 大概是这样一种开发方式:把自然语言意图丢给 AI,代码只看必要部分,跑结果,再用语言改。

Andrej Karpathy 提出这个说法时,核心也是人和代码直接搏斗的时间减少,自然语言意图驱动模型实现。1

他的 Software 3.0 讨论也在同一方向:自然语言成为新的编程接口,模型承担大量实现。2

大人物们也在说同一件事

这不是 Karpathy 一个人在说。

  • NVIDIA CEO Jensen Huang 说人类语言本身已经成为新的编程语言。3
  • Meta CEO Mark Zuckerberg 说 2025 年公司会拥有能写中级工程师水平代码的 AI。4
  • Anthropic CEO Dario Amodei 更激进地预测 AI 很快会写 90% 的代码,之后甚至几乎写完全部。5
  • Microsoft CEO Satya Nadella 认为如果 SaaS 的业务逻辑进入 AI agent 层,现有商业应用的形态会被动摇。6
  • GitHub CEO Thomas Dohmke 把开发者角色整理为从写代码转向委托和验证。7

OpenAI 也已经把 Codex 推成 software engineering agent,而不是单纯的 coding model。89

学习代码语法的时代结束了

基础依然重要。C、汇编、数据结构、网络、操作系统都能帮助判断 AI 生成物。

但“背语法就能就业”的 coding 课程还在流行,确实很悲哀。现在更重要的是看着 AI 生成的实现说出:

  • “方向错了。”
  • “用户流程在这里断了。”
  • “这个结构以后维护会爆。”
  • “现在需要的不是加功能,而是重新定义问题。”

Vibe coding 只是入口

代码会出来,但还不是产品

做小原型时,vibe coding 几乎像魔法。说出想要的东西,画面出现,API 接上,数据流动,按钮能按。

问题在之后。应用只要稍微变大,“看起来能跑的代码”和“能持续运营、持续修改的结构”就是两回事。

  • 需求中途变化。
  • 例外情况出现。
  • 权限和数据流缠在一起。
  • UI 在动,但产品意图错了。
  • 没有测试,修一处炸一处。
  • AI 忘掉上一轮自己做的结构。

没有上下文和权限边界,就会出事故

AI 漏掉规则时更危险。

  • 以为是开发 DB,结果删了生产 DB。
  • 本想删测试账号,却删了真实用户数据。
  • 回滚迁移时跑了没有备份的 destructive query。
  • 为了简化权限,把 private 数据打开成 public。
  • 为了通过 build,删掉验证代码或把类型盖成 any。

这不是说 AI 邪恶,而是说上下文、权限边界、验证一弱,就很容易往这边滑。

对几乎没有计算机知识的非开发者来说,前期会觉得“哇,能动”,但最后会撞上上下文极限。看不出什么命令危险、哪个文件是 source of truth、DB/Storage/Auth/Deploy 怎么连在一起,就无法审查 AI 的输出。

反馈不是情绪排泄,而是瞄准

当然,有时第一反应会是“不是,我说的是这个吗?”但把怒气原样扔出去,对我自己也不好。

没有确凿证据能说骂人一定降低模型性能,但研究确实显示 prompt 的语气和情绪 framing 会影响输出。1011

最大问题不是 AI 的心情,而是我的理性。一直发火,我会更情绪化,指令会更模糊,压力只会堆起来。

真正的限制不是实现,而是上下文

Anthropic 关于 long-running agents 的文章也说到这点。只靠高层 prompt 很难到 production-quality app,需要任务分解、持续记忆、上下文管理和验证循环。12

Vibe coding 的真正限制不是不会生成代码。它会生成,而且生成得太快。

限制在于 AI 很难独自稳定握住:这段代码为什么存在、哪里可以改、要过什么标准、哪些上下文不能破坏。

所以企业才试图用 harness 接住 vibe coding 的限制。

所以 harness 才是本局

Harness 是模型周围的执行结构

Harness 本来就是用来控制强大对象、把它引向想要方向的装备、带子、牵引结构。

戴着粉色 harness 和牵引绳的狗

Prompt engineering 更像一次对话里怎么说。Harness engineering 是设计模型周围的整个执行环境。

LangChain 把 agent 描述为 Model + Harness,harness 提供状态、工具执行、反馈循环和可强制的约束。13

Martin Fowler 也说,要少盯着 coding agent 使用,就需要 feedforward 和 feedback sensor。14

OpenAI 的 Codex harness 文章也指出瓶颈不是代码生产,而是人类能审查的量,于是把日志、指标、浏览器操作、结构化测试交给 agent。15

所以竞争力不只是哪个模型更会写代码,而是给什么上下文、开放什么工具、阻止什么权限、强制什么测试、在哪里让人介入。

Harness 结构就是竞争力

Claude Code 源码泄露之所以吵,是因为泄露的不是一句 prompt,而是它如何组合上下文、工具、guardrail、用户指令和系统指令的结构。1617

如果模型性能才是一切,这只会是小八卦。但它成了大事件,因为 harness 结构本身已经是产品竞争力。

越强的模型越需要强 harness

Mythos 和 Project Glasswing 在安全领域更强烈地说明了这一点。

Mythos 是 Anthropic 的未公开 frontier model,不只是会写代码的聊天机器人,而是能找到软件漏洞并组成 exploit,也就是攻击代码。Anthropic 说 Claude Mythos Preview 在主要 OS 和浏览器中找到了大量高风险漏洞。18

Project Glasswing 更像是为了防止这种高性能模型直接释放到世界后造成冲击的防御项目。它向 AWS、Apple、Google、Microsoft、NVIDIA、CrowdStrike 等伙伴有限开放,让关键软件先被防御性扫描。18

Axios 报道 Mythos 能在几小时内把公开漏洞信息变成可运行 exploit,并在 31 分钟内做出 Windows kernel 漏洞 proof-of-concept。19

这种能力不能随便扔给普通用户。谁能访问、能扫什么代码、结果怎么公开、补丁由谁验证、exploit 生成在哪里被阻止,全都要用强 harness 绑住。

弱 harness 抓不住模型

我对 AI Studio 类 harness 感到憋屈的地方也在这里。

当然,AI Studio 不是毫无价值。Google 也把 AI Studio Build mode 解释为快速制作应用、测试 Gemini 功能、用自然语言做原型的工具。20

但持续运营软件的开发 harness 是另一个问题。真实开发 harness 需要 repo、terminal、IDE、diff、test、review、deployment log、permission boundary。Google 另外推 Gemini CLI 和 Gemini Code Assist,也正说明差异。2122

如果只有聊天框、运行按钮和模型选择,却没有工作范围、权限边界、rollback、test、review、source of truth、长期上下文管理,就很难叫好的开发 harness。

模型再强,脖子上的绳子太松,最后还是会扯断绳子乱跑。

人负责企划/设计/执行/反馈

核心不是 AI 一按。核心是怎样设计一个精密系统,让 AI 在里面执行,并把结果反馈回去。

人类剩下的能力不是手写更多代码,而是决定做什么、设计 AI 运行的场、实际运行、审查结果、重新定方向。

这需要理解整体上下文的概念和领域知识,也需要快速发现异常的直觉。

最后只能乘上浪

如果在这里直接说“所以一起上 AI 浪潮吧”,确实会跳太快。那是在跳过所有可怕问题,用乐观包装。

我想说的不是 AI 时代来了所以开心,而是手写代码价值下降、AI 拿走实现、人类背负更大企划/设计/执行/反馈责任的流向,不会因为我不喜欢就停下。

选择大概只有两个。

  • 继续埋头旧式语法学习,然后被淘汰。
  • 或者把 coding 交给 AI,磨 prompt,进一步设计 harness,积累 AI literacy,然后活下去。

我现在确信只能选后者。

乘上浪不是说很快乐,而是如果巨大海啸已经来了,毫无防备站着只会被吞掉。只能先上去,抓方向,稳住姿势。

参考资料

  1. Andrej Karpathy, X post, 2025-02-02. https://x.com/karpathy/status/1886192184808149383 ↩

  2. Y Combinator, Karpathy lecture, 2025. https://www.ycombinator.com/library/MW-andrej-karpathy-software-is-changing-again ↩

  3. Business Insider, Jensen Huang interview coverage, 2025-06-09. https://www.businessinsider.com/nvidia-ceo-jensen-huang-ai-prompts-human-lets-anyone-program-2025-6 ↩

  4. ITPro, Mark Zuckerberg interview coverage, 2025-01-14. https://www.itpro.com/software/development/a-sign-of-things-to-come-in-software-development-mark-zuckerberg-says-ai-will-be-doing-the-work-of-mid-level-engineers-this-year-and-hes-not-the-only-big-tech-exec-predicting-the-end-of-the-profession ↩

  5. Skeptics Stack Exchange, 2025-09. https://skeptics.stackexchange.com/questions/59213/as-at-september-2025-is-ai-not-writing-90-of-code ↩

  6. CX Today, Satya Nadella interview summary, 2024-12-23. https://www.cxtoday.com/customer-analytics-intelligence/microsoft-ceo-ai-agents-will-transform-saas-as-we-know-it/ ↩

  7. Thomas Dohmke and Irini Kalliavakou, “Developers, Reinvented”, 2025-08-03. https://ashtom.github.io/developers-reinvented ↩

  8. OpenAI, “Codex is now generally available”, 2025-10-06. https://openai.com/index/codex-now-generally-available/ ↩

  9. OpenAI, “Introducing GPT-5.2-Codex”, 2025-12. https://openai.com/index/introducing-gpt-5-2-codex/ ↩

  10. Ziqi Yin et al., arXiv, 2024-02-22. https://arxiv.org/abs/2402.14531 ↩

  11. Cheng Li et al., arXiv, 2023-07-14. https://arxiv.org/abs/2307.11760 ↩

  12. Anthropic, “Effective harnesses for long-running agents”, 2025-11. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents ↩

  13. LangChain, “The Anatomy of an Agent Harness”, 2026. https://www.langchain.com/blog/the-anatomy-of-an-agent-harness ↩

  14. Martin Fowler, “Harness engineering for coding agent users”, 2026-04-02. https://martinfowler.com/articles/harness-engineering.html ↩

  15. OpenAI, “Harness engineering”, 2026-02-11. https://openai.com/index/harness-engineering/ ↩

  16. Varonis Threat Labs, 2026-04-03. https://www.varonis.com/blog/claude-code-leak ↩

  17. Drew Breunig, 2026-04-04. https://www.dbreunig.com/2026/04/04/how-claude-code-builds-a-system-prompt.html ↩

  18. Anthropic, “Project Glasswing”, 2026-04-07. https://www.anthropic.com/glasswing ↩ ↩2

  19. Axios, 2026-06-08. https://www.axios.com/2026/06/08/exclusive-anthropics-mythos-can-exploit-new-flaws-in-hours ↩

  20. Google AI for Developers, 2026. https://ai.google.dev/gemini-api/docs/aistudio-build-mode ↩

  21. Google, 2025-06-25. https://blog.google/innovation-and-ai/technology/developers-tools/introducing-gemini-cli-open-source-ai-agent/ ↩

  22. Google for Developers, 2026. https://developers.google.com/gemini-code-assist/docs/write-code-gemini ↩

留下评论