👀 最新、最有用的AI编程姿势，总来自「知识药丸」
《贾杰的AI编程秘籍》付费合集，共10篇，现已完结。30元交个朋友，学不到真东西找我退钱；）
以及我的墨问合集《100个思维碎片》，1块钱100篇，与你探讨一些有意思的话题（文末有订阅方式
写在前面
今天读到Peter Steinberger的一篇文章《Shipping at Inference-Speed》，看完直接震撼到了。
不是那种"哇又一个AI工具"的震撼。
是那种突然意识到游戏规则已经彻底变了的震撼。
我接触AI编程也有大半年了，一直觉得"嗯还不错，能提升点效率"。但读完这篇，我才发现：我可能还停留在石器时代。
Peter用他半年多的实战经验告诉我们：我们已经不需要写代码了。
最震撼的一句话
"这些天我基本不怎么读代码了。"
第一次看到这句，我的反应是：啥？
不读代码？那你怎么知道AI写对了？怎么知道有没有bug？怎么把控质量？
但他后面补充的才是关键：
我知道哪些组件在哪，系统怎么设计的。这就够了。
突然就懂了。
这就像《三体》里的降维打击（没错我又用这个比喻了）。
以前我们在"代码行"这个维度工作。现在我们在"系统架构"这个维度工作。
降了一个维度，但能看到的反而更多。
GPT-5 vs Opus：两种工作节奏
Peter花了很大篇幅对比这两个模型。
GPT-5 Codex像个学霸。
拿到作业，先把书翻一遍。有时候翻10分钟，有时候翻15分钟。
你看着它在那翻书，啥也不干，心里着急。
但它一旦动手，基本一次就对。
Opus像个快枪手。
拿到题目立刻开写。
写得快，改得也快。
小任务特别爽，大任务容易翻车。
Peter的结论是：Codex虽然慢4倍，但总体反而更快。
为什么？
因为修bug的时间被省掉了。
这让我想起《深入浅出NodeJS》里说的一句话："异步不是为了快，是为了不浪费时间等待"。
这里也一样：慢的是AI在读代码，快的是你不用改代码。
Oracle：给AI装个外脑
这个设计太妙了。
以前AI遇到解决不了的问题，Peter会手动整理资料，自己去查。
后来他想：这不就是在当AI的秘书吗？
于是写了Oracle。
一个CLI工具，让AI能自己调用GPT-5 Pro去深度研究。
AI遇到难题 → 自动调Oracle → Oracle爬50个网站深度思考（有时要1小时）→ 返回答案 → AI继续干活
整个过程不需要人。
这就是闭环的力量。
P.S. 有意思的是GPT-5.2出来后，Oracle使用频率从每天几次降到每周几次。说明模型进化有多快。
并行的艺术
Peter说他同时跑3-8个项目。
听起来很疯狂。
但想想传统编程是怎么回事：
你写代码 → 编译 → 测试 → 改bug → 再编译
全程串行。
你的时间和编译器的时间绑死了。
现在呢？
- • 项目A：AI在重构（2小时）
- • 项目B：AI在写功能（30分钟）
- • 项目C：你在和AI讨论设计
- • 项目D：你在测试刚完成的部分
你的时间和AI的时间解耦了。
这就像从单核CPU升级到多核。
不是快了一点，是工作方式完全变了。
当然，这要求你对每个项目都有清晰的心理模型。所以Peter也说了，只能在家安静的时候这么干。
三个反直觉的做法
1. 直接commit到main
我以前觉得feature branch是基本素养。
Peter的逻辑很简单：我一个人开发，为啥要给自己找麻烦？
爬山不会走直线，但路径是连续的。
2. 几乎不回滚
传统思维：改错了就reset。
Peter的做法：告诉AI改成对的。
为什么？
因为回滚是在浪费AI已经完成的工作。
与其推倒重来，不如基于现状调整。
3. 不用issue tracker
一开始我不理解。
后来想明白了：
issue tracker的本质是延迟处理。
但如果你的开发速度够快（得益于AI），为什么要延迟？
发现问题立刻解决，不重要的问题自然会被遗忘。
这反而是天然的优先级筛选。
Prompt的变化：从啰嗦到沉默
以前：
用语音输入长篇大论。
生怕AI理解不了。
反复强调重点。
现在：
拖个截图，写"fix padding"。
或者直接："write docs to docs/*.md"，让AI自己决定文件名。
为什么会这样？
因为模型变聪明了。
就像你跟工作三年的同事说话，和跟实习生说话，肯定不一样。
好的模型，你只需要说"做什么"，不需要说"怎么做"。
人的价值在哪里？
看到这你可能会想：那我还有什么用？
恰恰相反。
以下几件事依然需要人：
- 1. 技术选型：用什么语言？哪个框架？哪些依赖？
- 2. 系统设计：数据怎么流？前后端怎么分工？
- 3. 质量把控：AI跑了很久还没搞定，说明有问题
Peter有句话说得特别好：
我不是在设计让我容易浏览的代码库，我是在设计让AI能高效工作的代码库。
这才是新时代的工程思维。
不是为人优化，是为AI优化。
但这不代表放弃思考。
而是把思考从战术层提升到战略层。
可以直接用的技巧
配置优化：
tool_output_token_limit = 25000 # 让AI一次读更多 model_auto_compact_token_limit = 233000 # 给压缩留空间
默认配置太保守了。
就像给人一次只能看一页书。
跨项目复用：
"去看../vibetunnel怎么做的，照着来"
不用重复解释，AI自己参考。
文档驱动：
每个项目维护docs文件夹。
用脚本强制AI处理相关任务时读这些文档。
这是显式的知识管理。
比依赖AI的"记忆"靠谱多了。
从CLI开始：
无论想做什么，先做CLI版本。
为什么？
因为CLI最简单，最容易调试，AI最容易直接调用验证。
等核心逻辑跑通，再包装成UI。
Peter的YouTube总结工具就是这么做的：先CLI，确保核心功能OK，一天做成Chrome扩展。
知识新鲜度的价值
GPT-5.2知识到8月底。
Opus只到3月中旬。
差5个月。
这5个月意味着什么？
意味着你能不能用最新的工具。
软件世界变化太快。
知识新鲜度本身就是能力。
写给怀疑者
有人会说："AI写的代码质量不行"、"这是偷懒"。
但Peter的观点是：
当你和AI相处够久，你完全知道某个任务该花多久。它没能一次搞定时，我就已经察觉了。
AI不是让你不思考，是让思考更聚焦。
以前：80%时间写代码，20%时间想架构
现在：20%时间管AI，80%时间想架构
哪种更接近工程师的本质？
一些局限
当然，这篇文章也有限制：
Peter是独立开发者。很多做法（直接commit、不用issue tracker）在团队里未必适用。
而且要培养出"知道AI该搞定"的直觉，得烧很多tokens。
但这不妨碍我们学习他的思维方式。
总结
读完最大的收获不是技巧。
是看到了一种新的可能性。
软件开发正在从手工作坊变成工业生产。
你不需要亲手写每一行（手工）
但你需要设计好架构（工业设计）
需要选好工具（技术选型）
需要把控质量（QA）
这不是编程的终结。
这是编程的升级。
就像工业革命没有消灭工匠。
只是让工匠能做出更复杂、更精美的产品。
AI不会消灭程序员。
只会让程序员能构建更复杂、更有创造性的系统。
问题只有一个：
你准备好了吗？
参考资料
- • 原文：Shipping at Inference-Speed
- • 作者Twitter：@steipete
- • VibeTunnel：vibetunnel.sh
- • Clawdis：clawdis.ai
P.S. 强烈建议关注作者的Twitter。碎片化的思考有时候比完整文章更有启发性。
坚持创作不易，求个一键三连，谢谢你～❤️
以及「AI Coding技术交流群」，联系 ayqywx 我拉你进群，共同交流学习～
