最近看了 Jest 创始人 Christoph Nakazawa 的发文 —— “现代工程价值观”，和大家分享一下这位大佬是如何使用 AI 的。
这个大佬最近做了很多事情：
-
Vite+：用 Rust 写的构建工具功能（他甚至不懂 Rust），90% AI 写的
-
fate 1.0：一个完整的框架更新，包括 live views、GraphQL 支持、Vite 插件和垃圾回收，100% AI 写的
-
Codiff：一个高性能、极简、漂亮的 diff review 工具，100% AI 写的
-
Athena Crisis：70+ bugfix 和新功能，100% AI 写的
他还拿出了自己的 GitHub 贡献数据举例：
过去 30 天，他提交了 770 个 commit，平均每天改动 15000 行代码。而一年前的同期，只有 328 个 commit，每天改动约 5000 行。
也就是说，他这几个月，几乎 100% 的代码都是 AI 写的，但产出是以前的 3 倍！
那这位大佬是如何用 AI 的呢?
欢迎围观我的“朋友圈“，关注我的公众号 —— 冴羽。
1. 大佬是怎么用 AI 的？
尝试过多个模型后，Christoph 主要用的是 Codex CLI，GPT 版本是 5.5 high。
通常每个项目他会开一个 Ghostty 窗口，左侧是 Codex 标签页，右侧是终端。
通常他会同时跑 3 到 6 个项目，他发现瓶颈通常在于代码的讨论和审查。
关于 prompt，他说自己“很懒”，通常是这样开头：
"I want to build X. Get context from Y and Z, make a proposal, and ask me any questions you might have."
这其实就是典型的 AI 最佳实践 —— 先让 AI 读上下文，做提案，提问题。在提案阶段就反复迭代，而不是直接让 AI 撸代码。
修复 bug 时，他会指定一个可复现的问题场景或上下文，并强制模型首先创建一个失败的测试用例。
因为他发现这能显著提高模型以正确方式修复正确问题的概率。
这是因为如果你不逼 AI 先写失败的测试，它往往会修错问题、用错方法、写错测试。但一旦有了 “red → green” 的约束，AI 的修复质量会大幅提升。
审查代码，他用的是自己写的 Codiff 工具，输入 codiff -w 命令，让 AI 生成一个改动走读（walkthrough）。
大佬也承认：有些代码他根本不会细看🤣。 如果测试看起来靠谱、代码结构没问题、而且是在不那么关键的模块里，他就直接合并了。
2. AI 时代的 6 条工程价值观
Christoph 说他一直在想：到 2026 年乃至更远的未来，哪些工程价值观还重要？哪些已经过时了？
他的结论是——表面上看，一切都变了。但深层次看，变的不多。
我很认同这个判断。下面是他总结的 6 条价值观：
2.1. 强大的所有权（Strong Ownership）
���个对产品有深度理解的人，现在可以比以往快十倍地执行。而一个没有背景知识的人，用同样的 AI 工具，只会生成更多噪音。
这直接带来的结果就是 —— 协调成本变贵了。
Christoph 的判断很直接：
最有效率的团队会变得很小，可能就两三个人，每个人有清晰的责任划分，各自维护独立的仓库。
这会带来强大的所有权，你需要理解架构、理解产品需求、理解 trade-off、理解系统的长期方向。
2.2. 品味最重要（Taste, Taste, Taste）
Christoph 原话是：“I have a low tolerance for bullshit, and with agents, everyone can generate a lot of bullshit all day long. Please just stop.”
翻译一下：我对 bullshit 的容忍度很低，而有了 AI，每个人都能全天候批量制造 bullshit。求求你们，停下来。
这可太真实了🤣。
因为AI 时代最大的问题不是“AI 写不好代码”，而是“AI 太能写了”——你给它一个模糊的 prompt，它能在 30 秒内吐出一坨功能齐全但你完全不需要的东西。
所以 Christoph 强调品味的含义是 —— 你得花更多时间去想“什么值得花时间做”，而不是直接开干。
2.3. 严格护栏 + 快速反馈（Strict Guardrails & Fast Feedback Loops）
这一点特别容易被忽视。
Christoph 说：跟 AI agent 合作，本质上就像在大厂工作——你随时在往代码库里丢“新人”，这些新人对背景一无所知，带着你的 prompt 就上了。
那肯定会出现问题，那该如何解决呢？
靠护栏呗：
lint 规则、自动化测试、类型检查、严格的 CI —— 这些约束越强，AI 就越快、越正确地完成工作。
也因此工具的性能变得更重要了。因为代码量会呈爆炸式增长，工具必须能够快速处理发生更改的文件。
Christoph 认为：严格护栏和快速反馈，是决定 AI agent 在 1 分钟内完成工作，还是 60 分钟完成工作的分水岭。
2.4. 把上下文塞进仓库（Context in the Repo）
过去，一个项目的上下文分散在很多地方：
-
Notion / Google Docs
-
人的脑子里
-
口头约定（没写下来，或者写下来但忘了）
-
生产环境里的实际行为
-
Commit message
-
代码本身
**每个 AI agent 就像一个“新员工”，他们对这些地方的访问权参差不齐。 **
因此最好的解决方案是把所有相关的上下文集中起来，放在仓库里。
在仓库里放一份 CLAUDE.md 或 AGENTS.md，告诉 AI 你的偏好、你的风格、你禁止做哪些事情。
好的上下文文件，能让 AI 和人类都能更快上手。
这里还有一个反直觉的点：
虽然现在我们逐行读代码的时间变少了，但代码的“可读性”变得更重要了。
因为越简单、越少的代码，在你需要亲自介入的时候就越容易理解和修复。
代码量暴增的时代，越需要“一眼就能看懂的代码”。
2.5. 拥有自己的技术栈（Own your Stack）
Christoph 的观点很激进：有了 AI，你没有理由再把产品的核心部分外包给第三方依赖。
过去你可能会依赖某个数据获取库、某个 UI 框架——因为它们节约了你大量开发时间。
但每一层依赖，都带来了你不完全理解的代码、你不完全控制的设计决策、以及你不完全承担的后果。
每一行第三方代码，出问题的时候都是你的问题。
因此 Christoph 在过去几年里，自己建了一整套 JavaScript 开源技术栈：数据层、国际化、UI 库、工具配置、项目模板、slideshow……
他说这让他能快速启动新项目，同时对产品和用户体验拥有完全控制权。
3. 关于管理的思考
Christoph 对管理的思考也很有意思。
他说：过去团队规模、范围和管理层级都存在着根本的人为限制。但现在这些限制正在被推开。
虽然短期内，一定会有些公司走错方向——但大方向是：工程管理会变得更技术化，而不是更少技术化。
很多技术经理一进入中层管理，就慢慢“脱离了代码”。这在以前是可以的，还需要你管方向、管人、管流程。
但 AI 时代不行了。
当执行成本趋近于零，个人贡献者的杠杆变得巨大。管理者如果不懂代码、不敢自己上手改项目、不能提供技术领导力——那你的存在感从哪来？
Christoph 多年前写过一篇文章叫《Tech Lead Management》，他现在更坚定了：Tech Lead Manager 是 AI 时代最正确的管理角色。
抄一段他的原话：
As execution becomes cheaper and individual contributors gain more leverage, managers can no longer just own outcomes or direction. They have to retain domain expertise in the area they work in, be able to make changes to their projects confidently, and provide technical leadership.
在 AI 时代，管理者的核心能力不再是“管人”，而是“能判断”。
4. 大佬焦虑吗？
Christoph 说：
"Sometimes I feel like I'm just carrying context from one agent session into a GitHub Issue, or into Discord, and back to the agent."
有时候我觉得自己就是一个“上下文搬运工”——从 agent 拿到结果，搬到 GitHub Issue，再搬到 Discord，再搬回 agent 🤣。
虽然调侃自己像个搬运工，但从行文中，明显感受到他雀雀欲试。
他认为：我们正在解锁以闪电般的速度交付卓越产品的能力，而我们需要比以往任何时候都更多的人来实现这一目标。 我之前受限于编写代码，现在受限于做出判断。让我们开始交付吧！
也希望大家走出焦虑，在 AI 时代发挥出自己的潜力。
最近看了 Jest 创始人 Christoph Nakazawa 的发文 —— “现代工程价值观”，和大家分享一下这位大佬是如何使用 AI 的。
这个大佬最近做了很多事情：
Vite+：用 Rust 写的构建工具功能（他甚至不懂 Rust），90% AI 写的
fate 1.0：一个完整的框架更新，包括 live views、GraphQL 支持、Vite 插件和垃圾回收，100% AI 写的
Codiff：一个高性能、极简、漂亮的 diff review 工具，100% AI 写的
Athena Crisis：70+ bugfix 和新功能，100% AI 写的
他还拿出了自己的 GitHub 贡献数据举例：
过去 30 天，他提交了 770 个 commit，平均每天改动 15000 行代码。而一年前的同期，只有 328 个 commit，每天改动约 5000 行。
也就是说，他这几个月，几乎 100% 的代码都是 AI 写的，但产出是以前的 3 倍！
那这位大佬是如何用 AI 的呢?
欢迎围观我的“朋友圈“，关注我的公众号 —— 冴羽。
1. 大佬是怎么用 AI 的？
尝试过多个模型后，Christoph 主要用的是 Codex CLI，GPT 版本是 5.5 high。
通常每个项目他会开一个 Ghostty 窗口，左侧是 Codex 标签页，右侧是终端。
通常他会同时跑 3 到 6 个项目，他发现瓶颈通常在于代码的讨论和审查。
关于 prompt，他说自己“很懒”，通常是这样开头：
这其实就是典型的 AI 最佳实践 —— 先让 AI 读上下文，做提案，提问题。在提案阶段就反复迭代，而不是直接让 AI 撸代码。
修复 bug 时，他会指定一个可复现的问题场景或上下文，并强制模型首先创建一个失败的测试用例。
因为他发现这能显著提高模型以正确方式修复正确问题的概率。
这是因为如果你不逼 AI 先写失败的测试，它往往会修错问题、用错方法、写错测试。但一旦有了 “red → green” 的约束，AI 的修复质量会大幅提升。
审查代码，他用的是自己写的 Codiff 工具，输入
codiff -w命令，让 AI 生成一个改动走读（walkthrough）。大佬也承认：有些代码他根本不会细看🤣。 如果测试看起来靠谱、代码结构没问题、而且是在不那么关键的模块里，他就直接合并了。
2. AI 时代的 6 条工程价值观
Christoph 说他一直在想：到 2026 年乃至更远的未来，哪些工程价值观还重要？哪些已经过时了？
他的结论是——表面上看，一切都变了。但深层次看，变的不多。
我很认同这个判断。下面是他总结的 6 条价值观：
2.1. 强大的所有权（Strong Ownership）
���个对产品有深度理解的人，现在可以比以往快十倍地执行。而一个没有背景知识的人，用同样的 AI 工具，只会生成更多噪音。
这直接带来的结果就是 —— 协调成本变贵了。
Christoph 的判断很直接：
最有效率的团队会变得很小，可能就两三个人，每个人有清晰的责任划分，各自维护独立的仓库。
这会带来强大的所有权，你需要理解架构、理解产品需求、理解 trade-off、理解系统的长期方向。
2.2. 品味最重要（Taste, Taste, Taste）
Christoph 原话是：“I have a low tolerance for bullshit, and with agents, everyone can generate a lot of bullshit all day long. Please just stop.”
翻译一下：我对 bullshit 的容忍度很低，而有了 AI，每个人都能全天候批量制造 bullshit。求求你们，停下来。
这可太真实了🤣。
因为AI 时代最大的问题不是“AI 写不好代码”，而是“AI 太能写了”——你给它一个模糊的 prompt，它能在 30 秒内吐出一坨功能齐全但你完全不需要的东西。
所以 Christoph 强调品味的含义是 —— 你得花更多时间去想“什么值得花时间做”，而不是直接开干。
2.3. 严格护栏 + 快速反馈（Strict Guardrails & Fast Feedback Loops）
这一点特别容易被忽视。
Christoph 说：跟 AI agent 合作，本质上就像在大厂工作——你随时在往代码库里丢“新人”，这些新人对背景一无所知，带着你的 prompt 就上了。
那肯定会出现问题，那该如何解决呢？
靠护栏呗：
lint 规则、自动化测试、类型检查、严格的 CI —— 这些约束越强，AI 就越快、越正确地完成工作。
也因此工具的性能变得更重要了。因为代码量会呈爆炸式增长，工具必须能够快速处理发生更改的文件。
Christoph 认为：严格护栏和快速反馈，是决定 AI agent 在 1 分钟内完成工作，还是 60 分钟完成工作的分水岭。
2.4. 把上下文塞进仓库（Context in the Repo）
过去，一个项目的上下文分散在很多地方：
Notion / Google Docs
人的脑子里
口头约定（没写下来，或者写下来但忘了）
生产环境里的实际行为
Commit message
代码本身
**每个 AI agent 就像一个“新员工”，他们对这些地方的访问权参差不齐。 **
因此最好的解决方案是把所有相关的上下文集中起来，放在仓库里。
在仓库里放一份 CLAUDE.md 或 AGENTS.md，告诉 AI 你的偏好、你的风格、你禁止做哪些事情。
好的上下文文件，能让 AI 和人类都能更快上手。
这里还有一个反直觉的点：
虽然现在我们逐行读代码的时间变少了，但代码的“可读性”变得更重要了。
因为越简单、越少的代码，在你需要亲自介入的时候就越容易理解和修复。
代码量暴增的时代，越需要“一眼就能看懂的代码”。
2.5. 拥有自己的技术栈（Own your Stack）
Christoph 的观点很激进：有了 AI，你没有理由再把产品的核心部分外包给第三方依赖。
过去你可能会依赖某个数据获取库、某个 UI 框架——因为它们节约了你大量开发时间。
但每一层依赖，都带来了你不完全理解的代码、你不完全控制的设计决策、以及你不完全承担的后果。
每一行第三方代码，出问题的时候都是你的问题。
因此 Christoph 在过去几年里，自己建了一整套 JavaScript 开源技术栈：数据层、国际化、UI 库、工具配置、项目模板、slideshow……
他说这让他能快速启动新项目，同时对产品和用户体验拥有完全控制权。
3. 关于管理的思考
Christoph 对管理的思考也很有意思。
他说：过去团队规模、范围和管理层级都存在着根本的人为限制。但现在这些限制正在被推开。
虽然短期内，一定会有些公司走错方向——但大方向是：工程管理会变得更技术化，而不是更少技术化。
很多技术经理一进入中层管理，就慢慢“脱离了代码”。这在以前是可以的，还需要你管方向、管人、管流程。
但 AI 时代不行了。
当执行成本趋近于零，个人贡献者的杠杆变得巨大。管理者如果不懂代码、不敢自己上手改项目、不能提供技术领导力——那你的存在感从哪来？
Christoph 多年前写过一篇文章叫《Tech Lead Management》，他现在更坚定了：Tech Lead Manager 是 AI 时代最正确的管理角色。
抄一段他的原话：
在 AI 时代，管理者的核心能力不再是“管人”，而是“能判断”。
4. 大佬焦虑吗？
Christoph 说：
有时候我觉得自己就是一个“上下文搬运工”——从 agent 拿到结果，搬到 GitHub Issue，再搬到 Discord，再搬回 agent 🤣。
虽然调侃自己像个搬运工，但从行文中，明显感受到他雀雀欲试。
他认为：我们正在解锁以闪电般的速度交付卓越产品的能力，而我们需要比以往任何时候都更多的人来实现这一目标。 我之前受限于编写代码，现在受限于做出判断。让我们开始交付吧！
也希望大家走出焦虑，在 AI 时代发挥出自己的潜力。