软件开发 on KnightLi的博客

OpenClaw 作者 Peter Steinberger 如何看 AI 软件开发？从 OpenClaw 到闭环编程

Sun, 17 May 2026 20:02:26 +0800

Peter Steinberger 的经历很适合用来观察 AI 软件开发正在发生什么变化。

他不是“突然被 AI 带火的新人”。在 OpenClaw 之前，他已经是 PSPDFKit 的创始人，长期做 PDF 渲染、文档处理和开发者工具。这类产品很难靠概念包装取胜，必须面对性能、兼容性、API 设计、企业客户和长期维护。

所以，当 Steinberger 后来用 AI 工具做出 OpenClaw，并围绕 AI Agent、个人自动化和 AI 编程发表观点时，重点不只是“一个人写了很多代码”。更值得看的，是他把多年软件工程经验和新一代 AI coding agent 结合后，对开发流程的重新理解。

AI 编程不是魔法按钮

很多人讨论 AI 编程时，会把它简化成两个极端。

一种说法是：AI 已经能写代码，程序员快没用了。

另一种说法是：AI 写的代码不可靠，真正工程还是得靠人手写。

Steinberger 的经验更接近第三种：AI 让软件开发的操作单位变了，但没有取消工程判断。

过去，开发者主要以“编辑代码”为中心工作。需求拆解、架构判断、写实现、跑测试、修 bug，都围绕人工修改代码展开。

AI coding agent 介入后，开发者越来越像在管理一个执行系统：

说明目标。
提供上下文。
约束边界。
让 agent 修改代码。
运行测试和检查。
根据结果继续迭代。

这不是简单把键盘交给模型，而是把人从“每一行都亲手敲”转到“定义方向、设计反馈、判断结果”。

为什么他不喜欢把这叫 vibe coding

围绕 Steinberger 的讨论里，一个高频词是 vibe coding。

这个词原本用来形容一种新开发方式：开发者用自然语言描述想法，让 AI 生成大量代码，再通过运行结果和反馈不断调整。

但 Steinberger 对这个词并不完全买账。公开报道中提到，他认为 vibe coding 容易变成一种贬义表达，暗示 AI 辅助开发只是“凭感觉乱生成”，忽视了背后的技能、判断和经验。

这个批评有道理。

真正有效的 AI 编程并不是随便输入一句话，然后相信模型输出。它需要：

能把模糊需求拆成可执行任务。
能识别模型是否误解了目标。
能设计测试和验收标准。
能判断代码结构是否会影响长期维护。
能知道什么时候应该停止生成、转向人工审查。

换句话说，AI 降低了写代码的摩擦，但没有降低理解系统的责任。

闭环才是关键

Steinberger 相关访谈和文章里，经常被总结出的一个核心思路是“闭环”。

只让 AI 生成代码，是开环。

让 AI 生成代码、运行代码、读取错误、修复问题、再运行测试，才更接近闭环。

这个差别非常重要。

开环生成很容易制造表面可用的软件。页面能打开，功能看起来有，代码也不少，但一旦进入真实场景，就会暴露状态管理、权限、异常处理、边界条件和部署问题。

闭环开发要求输出必须被反馈约束。最简单的闭环是：

写清楚目标。
让 AI 修改代码。
自动运行测试、类型检查、lint 或构建。
把错误反馈给 AI。
重复直到通过。
最后由人审查关键路径。

这也是 AI 软件开发真正能提高效率的地方。不是因为模型一次就写对，而是因为它可以快速参与“生成、验证、修复”的循环。

经验越多，越能用好 AI

AI 编程最容易产生的误解之一，是“经验不重要了”。

Steinberger 的案例反而说明，经验会变得更重要，只是作用方式变了。

一个有经验的工程师更容易判断：

哪些任务适合交给 agent。
哪些模块需要先写测试。
哪些改动风险太高，不该让 AI 大范围重构。
哪些生成代码只是看起来合理。
哪些问题应该通过架构调整解决，而不是继续补丁式修复。

AI 可以生成大量候选方案，但候选方案越多，越需要判断力。没有经验的人可能会被“能跑起来”迷惑，有经验的人更会追问：能不能维护？能不能扩展？会不会破坏安全边界？出了问题能不能定位？

这也是为什么 AI coding agent 并没有让软件工程变成纯聊天。它更像把一部分执行劳动外包出去，同时放大了规划、审查、验证和取舍的重要性。

OpenClaw 的意义不只是项目本身

OpenClaw 被关注，不只是因为它是一个开源 AI agent，也不只是因为它的增长速度快。

它更像一个信号：开发者开始希望 AI 不只回答问题，而是能接入真实工具，完成真实动作。

传统聊天机器人停留在对话框里。它可以解释代码、写草稿、给建议，但很多时候还需要人复制、粘贴、打开软件、执行命令。

Agent 的方向是把模型接到工具上：

文件系统。
浏览器。
终端。
邮件。
日历。
第三方服务。
项目仓库。

一旦模型能使用这些工具，软件开发的边界就会变化。AI 不再只是“代码补全”，而会参与项目阅读、任务拆解、文件修改、测试执行、PR 整理和工作流自动化。

这也是 Steinberger 加入 OpenAI 后被关注的原因。他代表的不是单个开发者故事，而是一种产品方向：个人 agent 会从演示玩具走向日常工作层。

这对普通开发者意味着什么

对普通开发者来说，Steinberger 的经验不一定能直接复制。

不是每个人都能同时管理多个 agent，不是每个项目都适合高强度 AI 生成，也不是每个团队都能接受“先生成再快速迭代”的节奏。

但有几件事值得学。

第一，先把任务写清楚。

AI 对含糊目标很敏感。你说“优化一下”，它可能改风格、改结构、加功能、删逻辑。你说“把登录失败时的错误提示从英文改成中文，不改变认证流程”，结果通常更可控。

第二，把验证命令固定下来。

如果一个项目没有测试、没有构建命令、没有 lint，AI 就很难形成闭环。哪怕只是最基础的 npm test、go test ./...、pytest、hugo，也比完全靠肉眼检查强。

第三，控制改动范围。

一次只让 AI 处理一个模块、一个 bug、一个页面，通常比让它“重构整个项目”更可靠。

第四，保留人工审查。

尤其是认证、支付、权限、数据删除、部署脚本、数据库迁移、安全配置这些地方，不要因为代码是 AI 生成的就降低审查标准。

第五，复盘 prompt 和失败模式。

如果 AI 经常误解某类任务，就把约束写进项目规则、agent instructions 或技能文件。AI 编程能力不是只来自模型，也来自你给它搭建的工作环境。

AI 软件开发会走向哪里

Steinberger 的故事说明，AI 软件开发正在从“辅助写代码”走向“组织软件生产流程”。

早期 AI 编程工具的价值主要是补全函数、解释报错、生成模板。现在的变化是，agent 可以跨文件工作，可以调用工具，可以运行检查，可以根据反馈继续修复。

这会带来几个趋势：

第一，个人开发者的产能上限会提高。

一个人可以同时推进更多原型、脚本、内部工具和小型产品。但产能提高不等于质量自动提高。越快生成，越需要验证。

第二，项目结构会更重要。

代码越清晰，测试越明确，文档越完整，AI 越容易正确修改。混乱项目对人难，对 AI 也难。

第三，软件工程师会更像工作流设计者。

未来重要的不只是会不会写某门语言，而是能否把需求、上下文、工具、测试、部署和权限组织成一个可控循环。

第四，安全边界会更敏感。

Agent 能做事，就可能做错事。它能读文件、执行命令、访问服务，也意味着权限、审计和回滚会成为 AI 开发环境的基础设施。

小结

Peter Steinberger 的 AI 软件开发观，最有价值的地方不是“AI 生成了多少代码”，而是他展示了一种新的开发姿势。

人不再只是在编辑器里逐行输入，而是在设计目标、管理 agent、构造反馈回路、审查结果和调整系统。代码仍然重要，但代码不再是唯一的劳动中心。

如果说传统软件开发强调“把代码写对”，AI 软件开发会更强调“让系统持续产出可验证的正确结果”。

这不是降低工程门槛那么简单。它是在改变工程能力的形态：从手工实现，转向任务分解、上下文管理、工具编排、自动验证和最终判断。

参考资料

Karpathy 的 65 行 CLAUDE.md：让 AI 编程少犯三类错误

Sun, 19 Apr 2026 18:27:23 +0800

最近 GitHub 上有一个围绕 AI 编程的项目很火，核心其实只是一个大约 65 行的 CLAUDE.md 文件。它之所以能拿到大量 star，不是因为技术实现复杂，而是因为它抓住了很多人使用 AI 写代码时反复遇到的问题。

这个项目的背景，要从 Andrej Karpathy 对 AI 编程的观察说起。Karpathy 是 AI 领域很有影响力的教育者和工程师：斯坦福博士，参与过 OpenAI 早期工作，也曾在 Tesla 负责 Autopilot 视觉系统。后来他持续分享对大模型、教育和 AI 工具的理解，所以他对编程方式变化的判断，总会引起很多开发者关注。

他在一次分享中提到，自己使用 Claude Code 几周后，编程方式发生了明显变化：过去大概是 80% 手写代码、20% AI 辅助，现在更接近 80% 让 AI 写代码，自己做 20% 修改。他形容这像是“用英语编程”，通过自然语言告诉 LLM 要写什么。

但他也指出了 AI 编程的几个典型问题。

01 错误假设

第一个问题是模型很容易替用户做假设，然后沿着这个假设一路写下去。它不一定会主动管理自己的困惑，也不一定会在需求含糊时停下来追问。

比如用户只说“添加用户导出功能”，模型可能会默认导出全部用户，默认输出 JSON，默认写成本地文件，默认权限和字段都不需要再确认。等代码写完，用户才发现它理解的需求和真实场景并不一致。

更好的做法应该是先把不确定点列出来：导出全部用户还是筛选结果？是浏览器下载还是后台任务？需要哪些字段？数据量大不大？是否有权限限制？这些问题不问清楚，后面写得越快，偏得也越远。

02 过度复杂化

第二个问题是模型很容易把简单问题写复杂。一个函数能解决的问题，它可能加上抽象类、策略模式、工厂模式、配置层和一堆“未来可能有用”的扩展点。

这类代码看起来很工程化，实际却增加了维护负担。AI 尤其擅长快速生成大量结构，但并不总能判断这些结构是否真的必要。结果就是一百行能解决的任务，被膨胀成一千行。

判断标准其实很直接：一个资深工程师看到这段改动，会不会觉得它过度设计？如果答案是会，就应该删掉多余层次，用最少的代码解决当前问题。

03 附带伤害

第三个问题是模型有时会修改或删除自己没有充分理解的代码。它可能在修一个小 bug 的时候顺手改注释、重排格式、清理看似无用的 import，甚至动到和当前任务无关的逻辑。

这类“顺手优化”很危险，因为它扩大了变更范围，也让 review 变得更困难。用户本来只想修复一个空邮件导致验证器崩溃的问题，结果模型顺便增强了邮件验证、加了用户名校验、改了文档字符串，最后很难判断到底哪一行影响了行为。

更稳妥的原则是：只动必须动的代码，只清理自己造成的问题。原本就存在的死代码、格式问题或历史包袱，除非任务明确要求处理，否则最多提醒一句，不要直接改。

04 把吐槽变成 CLAUDE.md

在 Karpathy 的观点被大量传播后，开发者 Forrest Cheung 做了一件很聪明的事：他把这些吐槽整理成可以执行的行为准则，写进一个 CLAUDE.md 文件。

这个项目没有复杂代码，关键就是把 AI 编程中最容易出问题的地方，转成明确的工作规则。大致可以概括为四条。

第一条是先想再写。不要默默假设，不要隐藏困惑；如果需求有多种理解，就把它们列出来；如果存在更简单的方案，也要说出来；该追问时追问，该反驳时反驳。

第二条是简单优先。不添加没被要求的功能，不为一次性代码做抽象，不加入多余配置，也不为极小概率场景写大量防御代码。如果 50 行能解决，就不要写成 200 行。

第三条是精准修改。每一行改动都应该能直接追溯到用户请求。不要顺手改善邻近代码，不要重构没坏的东西，尽量匹配项目既有风格。

第四条是目标驱动。不要只给模型一个模糊指令，而是给它可验证的成功标准。比如“修复 bug”可以变成“先写一个能复现 bug 的测试，再让测试通过”；“添加校验”可以变成“写无效输入测试并通过”。成功标准越清楚，模型越容易自己循环到完成。

05 为什么它会火

这个项目能火，不是因为内容很玄，而是因为它足够贴近真实开发。

很多人用 AI 编程时都经历过类似场景：模型自信地误解需求，代码越写越复杂，或者在不该动的地方动手。CLAUDE.md 的价值，是把这些经验变成可以放进项目里的协作规则。

它的门槛也很低：一个文件就能开始生效，不需要复杂接入。再加上 Karpathy 本人的影响力，以及项目里有实战对比案例，它很自然会在 Claude Code 用户和 AI 编程社区里传播开来。

更重要的是，这类规则不是只适用于 Claude Code。无论使用哪种 AI 编程工具，本质问题都很相似：模型需要知道什么时候该问、什么时候该简化、什么时候该停手、怎样判断任务已经完成。

06 对普通开发者的启发

这件事给普通开发者的启发很简单：AI 编程不是把一句需求丢给模型，然后等待奇迹发生。真正有效的方式，是给模型建立边界。

需求不清楚时，让它先暴露假设。实现方案变复杂时，让它主动回到最小可行解。修改代码时，让它只围绕任务目标行动。完成任务时，用测试、命令或明确检查点来验证结果。

AI 写代码的能力已经很强，但它仍然需要好的协作约束。一个短小的 CLAUDE.md 能获得大量关注，说明开发者真正需要的并不只是更聪明的模型，也包括更可靠的工作方式。

简单总结：

先想再写，减少错误假设。
简单优先，避免过度设计。
精准修改，控制变更范围。
目标驱动，用可验证标准推动完成。

这四条并不复杂，却很实用。AI 编程真正提升效率的前提，不是让模型写得更多，而是让它写得更准、更少、更可控。