即刻App年轻人的同好社区
下载
置顶Yibie 的自我策展
我整理之前发过的帖子，这些是值得推荐一看的。也顺道向你暴露我的世界观、性格、兴趣和观点，有机会的话交个朋友😊
✨ AI 与新世界
得到 Prompt 系列（共 18 个） ⭐️已被“提示词图书馆收录”
m.okjike.com
Promopt: 文章精炼大师
web.okjike.com
Promopt: 概念卡片制作专家
web.okjike.com
Promopt: PPT 大纲制作助手 ⭐获得即刻精选推荐
web.okjike.com
Promopt: Kiweb. 文章精华浓缩专家
web.okjike.com
开发 12 Weeks LifeRPG 背后的过程与思考
web.okjike.com
用 AI 帮忙总结笔记（测试了 ChatGPT、Gemini、Kiweb.、豆包）
web.okjike.com
微软 CTO Kevin Scott 接受 every 访谈
web.okjike.com
吴恩达总结 AI 工程师制作 Promopt 的经验
web.okjike.com
OpenAI 2024 年春季发布会源文件， 包括演讲稿和演示用代码
web.okjike.com
视频内容识别是 Gemini Pro 1.5 的杀手锏
web.okjike.com
Perplexity 的官方 Promopt
web.okjike.com
大模型公司对 Token 的计算方法都不一样
web.okjike.com
AI 与创作者经济
web.okjike.com
------------------------------------
🤔我对这个世界有点看法
every 长文: AI 将冲击广告业, 后果很严重
web.okjike.com
Vision Pro 之我见
web.okjike.com
社会生活的趋同让人恐惧
web.okjike.com
「探索式」笔记法 ⭐获得即刻精选推荐
web.okjike.com
子弹日记法
web.okjike.com
商业价值的 3 个重要特征
web.okjike.com
Arc 这家公司的特点
web.okjike.com
新产品形态: Jina AI 将 URL 变为 API
web.okjike.com
------------------------------------
📒囤了一些清单
值得推荐的豆瓣小组
web.okjike.com
包豪斯设计的精华链接
web.okjike.com
Design Engineer 的 Twitter List
web.okjike.com
------------------------------------
📖️那些值得推荐的好书
读完斯多葛主义代表人物塞涅卡的书信集 <短暂的生命>
web.okjike.com
程序员超强大脑笔记
web.okjike.com
读完<巨人的工具>
web.okjike.com
读完<为什么伟大不能被计划>
web.okjike.com
精要主义读书笔记
web.okjike.com
读《了不起的盖茨比》
web.okjike.com
------------------------------------
💭️脑海里闪过的一句话
天才税
web.okjike.com
高度抽象的现代生活损害人类天生的类比能力
web.okjike.com
你能列出充分反映时代精神的 3 家公司吗？
web.okjike.com
解决拖延症的办法是找出之前最想完成但一直没做的事
web.okjike.com
美 = 深刻的简洁
web.okjike.com
尊重常识 = 不犯基本错误
web.okjike.com
与其花 1 小时如昙花一现, 不如花 10 倍时间震惊四座
web.okjike.com
这个世界有种人，以好人为食。
web.okjike.com
最难沟通的，是被灌输了标准答案的人
web.okjike.com
拖延 = 甩锅给未来的自己
web.okjike.com
折腾的定义
web.okjike.com
------------------------------------
🛠喜欢折腾工具
开启 Mac 系统自带白噪音音乐的方法
web.okjike.com
20-20-20 护眼原则
web.okjike.com
用哔哩哔哩替代网易云音乐
web.okjike.com
中国著名羽毛球运动员郑思维学习英语的工具和方法
web.okjike.com
------------------------------------
📁未归类的答案
「参考答案」的策展原则
web.okjike.com
我整理之前发过的帖子，这些是值得推荐一看的。也顺道向你暴露我的世界观、性格、兴趣和观点，有机会的话交个朋友😊
✨ AI 与新世界
得到 Prompt 系列（共 18 个） ⭐️已被“提示词图书馆收录”
m.okjike.com
Promopt: 文章精炼大师
web.okjike.com
Promopt: 概念卡片制作专家
web.okjike.com
Promopt: PPT 大纲制作助手 ⭐获得即刻精选推荐
web.okjike.com
Promopt: Kiweb. 文章精华浓缩专家
web.okjike.com
开发 12 Weeks LifeRPG 背后的过程与思考
web.okjike.com
用 AI 帮忙总结笔记（测试了 ChatGPT、Gemini、Kiweb.、豆包）
web.okjike.com
微软 CTO Kevin Scott 接受 every 访谈
web.okjike.com
吴恩达总结 AI 工程师制作 Promopt 的经验
web.okjike.com
OpenAI 2024 年春季发布会源文件， 包括演讲稿和演示用代码
web.okjike.com
视频内容识别是 Gemini Pro 1.5 的杀手锏
web.okjike.com
Perplexity 的官方 Promopt
web.okjike.com
大模型公司对 Token 的计算方法都不一样
web.okjike.com
AI 与创作者经济
web.okjike.com
------------------------------------
🤔我对这个世界有点看法
every 长文: AI 将冲击广告业, 后果很严重
web.okjike.com
Vision Pro 之我见
web.okjike.com
社会生活的趋同让人恐惧
web.okjike.com
「探索式」笔记法 ⭐获得即刻精选推荐
web.okjike.com
子弹日记法
web.okjike.com
商业价值的 3 个重要特征
web.okjike.com
Arc 这家公司的特点
web.okjike.com
新产品形态: Jina AI 将 URL 变为 API
web.okjike.com
------------------------------------
📒囤了一些清单
值得推荐的豆瓣小组
web.okjike.com
包豪斯设计的精华链接
web.okjike.com
Design Engineer 的 Twitter List
web.okjike.com
------------------------------------
📖️那些值得推荐的好书
读完斯多葛主义代表人物塞涅卡的书信集 <短暂的生命>
web.okjike.com
程序员超强大脑笔记
web.okjike.com
读完<巨人的工具>
web.okjike.com
读完<为什么伟大不能被计划>
web.okjike.com
精要主义读书笔记
web.okjike.com
读《了不起的盖茨比》
web.okjike.com
------------------------------------
💭️脑海里闪过的一句话
天才税
web.okjike.com
高度抽象的现代生活损害人类天生的类比能力
web.okjike.com
你能列出充分反映时代精神的 3 家公司吗？
web.okjike.com
解决拖延症的办法是找出之前最想完成但一直没做的事
web.okjike.com
美 = 深刻的简洁
web.okjike.com
尊重常识 = 不犯基本错误
web.okjike.com
与其花 1 小时如昙花一现, 不如花 10 倍时间震惊四座
web.okjike.com
这个世界有种人，以好人为食。
web.okjike.com
最难沟通的，是被灌输了标准答案的人
web.okjike.com
拖延 = 甩锅给未来的自己
web.okjike.com
折腾的定义
web.okjike.com
------------------------------------
🛠喜欢折腾工具
开启 Mac 系统自带白噪音音乐的方法
web.okjike.com
20-20-20 护眼原则
web.okjike.com
用哔哩哔哩替代网易云音乐
web.okjike.com
中国著名羽毛球运动员郑思维学习英语的工具和方法
web.okjike.com
------------------------------------
📁未归类的答案
「参考答案」的策展原则
web.okjike.com
57 1621
Google 工程主管 Addy Osmani 把 2026 年的编码工作流摊开：
经典软件工程纪律在 AI Coding 时更重要了。
《我 2026 年的 LLM 编码工作流》
My LLM coding workflow going into 2026
AI 编程助手在 2025 年成了游戏规则改变者，但有效驾驭它们需要技巧和结构。这些工具极大地提升了 LLM 对真实编码能做的事，很多开发者（包括我）都拥抱了它们。在 Anthropic，工程师如此重度采用 Claude Code，以至于今天 Claude Code 约 90% 的代码是它自己写的。然而，用 LLM 编程不是一个按钮魔法体验——它"困难且反直觉"，要拿到好结果需要学习新的模式。批判性思维仍然是关键。经过一年多项目，我收敛到一个和许多有经验开发者正在发现的工作流相似的东西：把 LLM 当作一个强大的结对程序员，它需要清晰的方向、上下文和监督，而不是自主判断。
在这篇文章里，我会分享 2026 年我如何规划、编码和与 AI 协作，提炼我自己经验和社区集体学习的技巧与最佳实践。这是一种更自律的"AI 辅助工程"方法——激进地利用 AI，同时对产出的软件保持问责。
从清晰的计划开始（先规格后代码）
别把愿望直接扔给 LLM——先定义问题、规划解决方案。
一个常见错误是带着模糊提示直接进入代码生成。我的工作流里（也是很多其他人的），第一步是和 AI 一起头脑风暴详细规格，然后列出逐步计划，然后才写任何实际代码。对新项目，我会描述想法，让 LLM 迭代地向我提问，直到我们把需求和边界情况都厘清。最后，我们把所有内容编译成一份完整的 spec.md——包含需求、架构决策、数据模型，甚至测试策略。这份规格构成开发的基础。
接下来，我把规格喂给一个带推理能力的模型，提示它生成项目计划：把实现拆成合乎逻辑的小任务或里程碑。AI 基本是在帮我做一次迷你"设计文档"或项目计划。我经常迭代这份计划——编辑、让 AI 批评或细化——直到它连贯完整。然后我才开始编码。这笔前置投入感觉慢，但回报巨大。就像 Les Orchard 说的，这等于做一次"15 分钟的瀑布"——一个快速的结构化规划阶段，让后面的编码顺畅得多。
有清晰的规格和计划意味着，当我们放出代码生成时，人和 LLM 都确切知道我们在构建什么、为什么。一句话：先规划逼着你和 AI 对齐，防止浪费循环。很多人想跳过这步，但有经验的 LLM 开发者现在把扎实的规格/计划当作工作流的基石。
把工作拆成小的迭代块
范围管理就是一切——喂给 LLM 可管理的任务，而不是一次整个代码库。
我学到的一个关键教训是避免向 AI 要大型整体输出。相反，我们把项目拆成迭代步骤或工单，一个一个地攻克。这镜像了良好的软件工程实践，但有人在循环里时它更重要。LLM 在收到聚焦提示时表现最好：一次实现一个函数、修一个 bug、加一个功能。比如规划之后，我会提示代码生成模型："好，让我们实现计划的第 1 步"。我们编码、测试，然后进入第 2 步，如此类推。每块小到 AI 能在上下文里处理、你能理解它产出的代码。
这个方法防模型脱轨。如果你一次要太多，它很可能困惑或产出难解的"一团乱"。有开发者报告，当他们试图让 LLM 生成应用的大块时，结果是不一致和重复——"像 10 个开发者在没互相沟通的情况下工作"。我感受过那种痛；解法是停下、后退、把问题拆成更小的块。每轮迭代，我们带上已构建内容的上下文，增量添加。这也很好地配合测试驱动开发（TDD）——我们可以边走边为每块写或生成测试。
几个编码 agent 工具现在显式支持这种分块工作流。比如，我经常生成一个结构化的"提示计划"文件，包含每个任务的提示序列，这样 Cursor 之类的工具能逐个执行。关键点是避免巨大的跳跃。通过小循环迭代，我们大幅降低灾难性错误的概率，并能快速纠偏。LLM 擅长快速、受限的任务——利用这一点。
提供充分的上下文和指导
LLM 的好赖取决于你提供的上下文——展示它们相关代码、文档和约束。
在代码库上工作时，我确保把 AI 表现好所需的全部信息喂给它：它要修改或引用的代码、项目的技术约束、以及任何已知陷阱或首选方法。现代工具有帮助：Anthropic 的 Claude 可以在"Projects"模式下把整个 GitHub 仓库导入上下文；Cursor 或 Copilot 这类 IDE 助手自动把打开的文件包含进提示。但我经常更进一步——如果怀疑模型没有某些内容，我会用 MCP（如 Context7）或手动把代码库或 API 文档的重要部分复制进对话。
专家 LLM 用户强调这个"上下文打包"步骤。比如做一次"大脑倾倒"——把模型在编码前应该知道的一切倒出来，包括：高层目标和不变式、好解决方案的例子、以及要避免的方法的警告。如果我让 AI 实现一个棘手的方案，我可能会告诉它哪些 naive 方案太慢，或者从别处提供一个参考实现。如果我用一个冷门库或全新 API，我会把官方文档或 README 贴进去，这样 AI 不是盲目飞行。所有这些前置上下文都大幅提升输出质量，因为模型不是在猜——事实和约束就在它面前。
现在有工具可以自动化上下文打包。我试过 gitingest 或 repo2txt 这类工具，它们把你的代码库相关部分"倾倒"成一个文本文件给 LLM 读。处理大项目时它们是救星——生成一个关键源文件的 output.txt 包，让模型消化它。原则是：别让 AI 在残缺信息上运行。如果修一个 bug 需要理解四个不同模块，就展示那四个模块。是的，我们必须注意 token 上限，但当前前沿模型有相当大的上下文窗口。明智地使用它们。我经常只选任务相关的那部分代码，并明确告诉 AI 哪些不要关注（省 token）。
我觉得 Claude Skills 有潜力，因为它们把以前脆弱、重复的提示变成持久可复用的东西——把指令、脚本和领域专长打包成模块化能力，工具能在请求匹配时自动应用。这意味着比通用提示更可靠、更上下文感知的结果，从一次性交互转向编码可重复程序和团队知识的工作流。社区策展的 Skills 集合不少，但我最喜欢的例子是 frontend-design skill——它能"终结"LLM 生成 UI 里泛滥的紫色设计美学。在更多工具官方支持 Skills 之前，也有变通方案。
最后，用提示里的注释和规则引导 AI。我可能在一个代码片段前写："这是 X 的当前实现。我们需要扩展它做 Y，但小心别破坏 Z。"这些小提示大有帮助。LLM 是字面主义者——它们会遵循指令，所以给它们详细、有上下文的指令。通过主动提供上下文和指导，我们最小化幻觉和离谱建议，得到契合项目需求的代码。
选对模型（需要时用多个）
不是所有编码 LLM 都平等——有意图地挑选工具，别怕中途换模型。
2025 年我们被各种能力强大的编码 LLM 宠坏了。我工作流的一部分是为每个任务选择最适合的模型或服务。有时甚至并行试两个或更多 LLM，交叉检查它们如何不同地处理同一个问题。
每个模型都有自己的"性格"。关键是：如果一个模型卡住或产出平庸，换一个试试。我真的把同一个提示从一个聊天复制到另一个服务，看它能不能处理得更好。这种"模型抢椅子"能在你撞上模型盲区时救你。
另外，确保你用的是最好的版本。如果可以，用最新的"pro"级模型——因为质量很重要。是的，通常意味着付费，但生产力收益能证明它。最终，选那个"气质"和你合拍的 AI 结对程序员。我认识有人偏爱某个模型只是因为喜欢它回复的感觉。那完全合理——当你基本在和 AI 持续对话时，UX 和语气有影响。
我个人现在很多编码工作倾向于 Gemini（坦白：我在 Google 做 Gemini，自然更熟悉），因为交互感觉更自然，常常第一次就能理解我的请求。但需要时我会毫不犹豫换模型；有时第二意见能帮解决方案浮现。总结：用最适合工作的工具，记住你手头有一整支 AI 兵工厂。
在整个生命周期利用 AI 编码
命令行出现了新的 AI agent。Claude Code、OpenAI 的 Codex CLI 和 Google 的 Gemini CLI 都是 CLI 工具，你在项目目录里直接和它们对话——它们能读文件、跑测试、甚至多步修问题。我也用过 Google 的 Jules 和 GitHub 的 Copilot Agent——这些是异步编码 agent，实际上把你的仓库克隆进云 VM，在后台工作（写测试、修 bug，然后为你开 PR）。有点诡异：你发出"重构支付模块做 X"的命令，一会儿之后你收到一个带代码改动和通过测试的 pull request。我们真的活在未来。
话虽如此，这些工具不是万无一失的，你必须理解它们的局限。它们加速编码的机械部分——生成样板、应用重复改动、自动跑测试——但依然非常需要你的指导。比如，当用 Claude 或 Copilot 这类 agent 实现东西时，我经常把前面步骤的计划或待办列表提供给它，让它知道确切的任务序列。如果 agent 支持，我会在执行前把 spec.md 或 plan.md 加载进上下文。这让它保持在轨道上。
我们还没到让 AI agent 无人看管地编码整个功能并期待完美结果的阶段。相反，我以监督的方式使用这些工具：我让它们生成甚至运行代码，但盯着每一步，看到不对劲随时介入。还有 Conductor 之类的编排工具，让你在不同任务上并行跑多个 agent（本质上是规模化 AI 帮助的方式）——一些工程师在实验一次跑 3-4 个 agent 处理不同功能。我试过这种"大规模并行"方法；它能高效完成很多事，但监视多个 AI 线程也很费神！多数情况下，我一次只用一个主 agent，也许再加一个次要的做审查。
记住，这些是强力工具——你仍然控制扳机、引导结果。
保持人在循环——验证、测试、审查一切
AI 会很乐意产出看起来可信的代码，但你对质量负责——总是彻底审查和测试。我的一条基本原则是绝不盲目信任 LLM 的输出。就像 Simon Willison 精辟说的，把 LLM 结对程序员想成"过度自信、容易犯错"。它带着完全的自信写代码——包括 bug 或胡说——而且不会告诉你哪里不对，除非你抓到。所以我对待每一段 AI 生成的片段，都像来自初级开发者的代码：读一遍、跑一遍、按需测试。你必须测试它写的东西——跑单元测试，或手动演练功能，确保它真的做了它声称的事。
事实上，我把测试织进工作流本身。我早期的规划阶段经常包括为每步生成测试列表或测试计划。如果用 Claude Code 这类工具，我会指示它在实现任务后跑测试套件，有失败就调试。这种紧密反馈循环（写代码→跑测试→修复）正是 AI 擅长的——只要有测试存在。那些从编码 agent 获益最多的人，往往是有强大测试实践的人。Claude 这样的 agent 能在好测试套件作为安全网时"飞"过项目。没有测试，agent 可能心安理得地假设一切正常（"当然，都好！"）而实际上它已经弄坏了几处。所以，投资测试——它放大 AI 的用处和你对结果的信心。
即使超越自动化测试，做代码审查——人工和 AI 辅助都做。我例行暂停，逐行审查已生成的代码。有时我会开第二个 AI 会话（或不同模型），让它批评或审查第一个产出的代码。比如，我可能让 Claude 写代码，然后问 Gemini："你能审查这个函数有没有错误或改进吗？"这能抓到微妙问题。关键是别因为代码是 AI 写的就跳过审查。如果有的话，AI 写的代码需要额外审查，因为它有时表面上令人信服，却藏着人类不会立刻注意的缺陷。
我也用 Chrome DevTools MCP——和上一个团队一起做的——用于调试和质量循环，弥合静态代码分析和实时浏览器执行之间的鸿沟。它"给 agent 一双眼睛"，让它直接访问浏览器能看到的、检查 DOM、拿丰富的性能追踪、控制台日志或网络追踪。这个集成消除了手动上下文切换的摩擦，允许通过 LLM 直接做自动化 UI 测试。bug 可以基于真实运行时数据被高精度诊断和修复。
跳过人工监督的严重后果有据可查。一个重度依赖 AI 生成赶工项目的开发者，把结果描述为不一致的乱摊子——重复逻辑、错配的方法名、没有连贯架构。他意识到自己一直在"建、建、建"，没有退后一步真正看看 AI 编织出了什么。解法是一次痛苦的返工，以及再也不让事情失控到那种地步的誓言。我记住了。无论我用多少 AI，我仍然是负责的工程师。
实际操作上，这意味着只有在我理解代码之后才合并或发布。如果 AI 生成的东西绕来绕去，我会让它加注释解释，或者用更简单的术语重写。如果有什么感觉不对，我深挖——就像人类同事贡献了有危险信号的代码那样。
一切都是心态：LLM 是助手，不是自动可靠的编码者。我是资深开发者；LLM 是来加速我的，不是取代我的判断。保持这种姿态不仅产出更好的代码，也保护你自己作为开发者的成长。一句话：保持警觉，多测试，常审查。归根结底这还是你的代码库。
频繁提交，用版本控制当安全网。绝不提交你解释不了的代码。
频繁提交是你的存档点——它们让你撤销 AI 的失手、理解改动。
当和一个能快速生成大量代码的 AI 工作时，事情很容易跑偏。我通过采纳超细粒度的版本控制习惯来缓解。我早提交、频繁提交，甚至比手工编码时更频繁。每完成一个小任务或每次成功的自动编辑，我就带着清晰消息做一次 git 提交。这样，如果 AI 的下一个建议引入 bug 或混乱改动，我有一个最近的检查点可以回退（或 cherry-pick），不会丢失几小时工作。一位实践者把它比作"游戏里的存档点"——如果 LLM 会话翻车，你总能回滚到最后一个稳定提交。这条建议非常有用。当你知道必要时可以用 git reset 撤销时，大胆的 AI 重构实验压力小得多。
正确的版本控制在和 AI 协作时也有帮助。既然不能指望 AI 记住它做的一切（上下文窗口限制等），git 历史就成了宝贵的日志。我经常扫最近的提交来给 AI（或自己）简报改了什么。事实上，LLM 自己能利用你的提交历史——我把 git diff 或提交日志贴进提示，让 AI 知道哪些代码是新的、之前状态是什么。有趣的是，LLM 非常擅长解析 diff 和使用 git bisect 这类工具找 bug 是哪里引入的。它们遍历提交历史有无限的耐心，能增强你的调试。但这只有在你一开始就有整洁的提交历史时才有效。
另一个好处：带好消息的小提交基本上记录了开发过程，做代码审查（AI 或人类）时有帮助。如果一个 AI agent 一次做了五处改动然后坏了，那些改动在单独提交里，更容易定位哪个提交导致问题。如果全在一个叫"AI 改动"的巨型提交里，祝你好运！所以我自律：完成任务，跑测试，提交。这也和前面拆小块的建议契合——每块最终成为自己的提交或 PR。
最后，别怕用分支或 worktree 隔离 AI 实验。我采用的一个高级工作流（受 Jesse Vincent 等人启发）是为新功能或子项目开一个全新的 git worktree。这让你能在同一个仓库并行跑多个 AI 编码会话而不互相干扰，之后合并改动。有点像给每个 AI 任务一个自己的沙箱分支。如果一个实验失败，丢掉那个 worktree，主分支什么都没丢。如果成功，合并进去。这个方法在比如"让 AI 实现功能 A，同时我（或另一个 AI）做功能 B"时至关重要。版本控制正是让这种协作成为可能的东西。一句话：频繁提交、用分支组织工作、拥抱 git，把它作为让 AI 生成的改动可控可逆的控制机制。
用规则和示例定制 AI 的行为
通过提供风格指南、示例甚至"规则文件"来引导你的 AI 助手——一点前置调校换来好得多的输出。
我学到的一件事是，你不必接受 AI 的默认风格或方法——你可以通过给指南来极大影响它。比如，我有一个定期更新的 CLAUDE.md 文件，包含 Claude（Anthropic 的模型）要遵循的流程规则和偏好（用 Gemini CLI 时类似的有 GEMINI.md）。内容包括"用我们项目的风格写代码、遵守我们的 lint 规则、不要用某些函数、偏好函数式而非 OOP"等。开始会话时，我把这个文件喂给 Claude 让它对齐我们的约定。让模型"保持在轨道上"的效果惊人地好——它减少了 AI 脱稿或引入我们不想要模式的倾向。
即使没有花哨的规则文件，你也可以用自定义指令或系统提示设定基调。GitHub Copilot 和 Cursor 都引入了让你为项目配置 AI 行为的特性。我利用过这个——写一小段关于我们编码风格的文字，比如"用 4 空格缩进、React 里避免箭头函数、变量名要描述性、代码要过 ESLint"。有了这些指令，AI 的建议会贴合人类队友可能写的东西。Ben Congdon 提到他惊讶于很少人用 Copilot 的自定义指令，考虑到它多有效——通过提前提供示例和偏好，他能引导 AI 输出匹配团队习语的代码。我附议：花时间教 AI 你的期望。
另一个强大技巧是提供行内示例——你想要的输出格式或方法。如果我想让 AI 以非常特定的方式写一个函数，我可能先给它看代码库里已有的相似函数："这是我们实现 X 的方式，对 Y 用类似的方法。"如果我想要某种注释风格，我会自己写一条注释，让 AI 按那种风格继续。本质上，用模式引导模型。LLM 擅长模仿——给它们一两个示例，它们就会沿着那个方向继续。
社区也想出了创造性的"规则集"来驯服 LLM 行为。你可能听说过 "Big Daddy" 规则，或在提示里加"不许幻觉/不许欺骗"条款。这些基本是提醒 AI 诚实、不要过度编造不存在的代码的技巧。比如，我有时在提示前加："如果你不确定某事或代码库上下文缺失，要求澄清而不是编造答案。"这减少幻觉。我用另一个规则："修 bug 时总是在注释里简短解释你的推理。"这样 AI 生成修复时，也会留下"// Fixed: 改了 X 为 Y 以防 Z（按规格）"这样的注释。对后续审查超有用。
总结：别把 AI 当黑盒——调校它。通过配置系统指令、分享项目文档、写下明确规则，你把 AI 变成团队里更专业的开发者。类似给新人入职：你会给他们风格指南和一些入门提示，对吧？对你的 AI 结对程序员也一样。投资回报巨大：你得到需要更少调整、和你的代码库更顺滑集成的输出。
【未完，请看评论区】
经典软件工程纪律在 AI Coding 时更重要了。
《我 2026 年的 LLM 编码工作流》
My LLM coding workflow going into 2026
AI 编程助手在 2025 年成了游戏规则改变者，但有效驾驭它们需要技巧和结构。这些工具极大地提升了 LLM 对真实编码能做的事，很多开发者（包括我）都拥抱了它们。在 Anthropic，工程师如此重度采用 Claude Code，以至于今天 Claude Code 约 90% 的代码是它自己写的。然而，用 LLM 编程不是一个按钮魔法体验——它"困难且反直觉"，要拿到好结果需要学习新的模式。批判性思维仍然是关键。经过一年多项目，我收敛到一个和许多有经验开发者正在发现的工作流相似的东西：把 LLM 当作一个强大的结对程序员，它需要清晰的方向、上下文和监督，而不是自主判断。
在这篇文章里，我会分享 2026 年我如何规划、编码和与 AI 协作，提炼我自己经验和社区集体学习的技巧与最佳实践。这是一种更自律的"AI 辅助工程"方法——激进地利用 AI，同时对产出的软件保持问责。
从清晰的计划开始（先规格后代码）
别把愿望直接扔给 LLM——先定义问题、规划解决方案。
一个常见错误是带着模糊提示直接进入代码生成。我的工作流里（也是很多其他人的），第一步是和 AI 一起头脑风暴详细规格，然后列出逐步计划，然后才写任何实际代码。对新项目，我会描述想法，让 LLM 迭代地向我提问，直到我们把需求和边界情况都厘清。最后，我们把所有内容编译成一份完整的 spec.md——包含需求、架构决策、数据模型，甚至测试策略。这份规格构成开发的基础。
接下来，我把规格喂给一个带推理能力的模型，提示它生成项目计划：把实现拆成合乎逻辑的小任务或里程碑。AI 基本是在帮我做一次迷你"设计文档"或项目计划。我经常迭代这份计划——编辑、让 AI 批评或细化——直到它连贯完整。然后我才开始编码。这笔前置投入感觉慢，但回报巨大。就像 Les Orchard 说的，这等于做一次"15 分钟的瀑布"——一个快速的结构化规划阶段，让后面的编码顺畅得多。
有清晰的规格和计划意味着，当我们放出代码生成时，人和 LLM 都确切知道我们在构建什么、为什么。一句话：先规划逼着你和 AI 对齐，防止浪费循环。很多人想跳过这步，但有经验的 LLM 开发者现在把扎实的规格/计划当作工作流的基石。
把工作拆成小的迭代块
范围管理就是一切——喂给 LLM 可管理的任务，而不是一次整个代码库。
我学到的一个关键教训是避免向 AI 要大型整体输出。相反，我们把项目拆成迭代步骤或工单，一个一个地攻克。这镜像了良好的软件工程实践，但有人在循环里时它更重要。LLM 在收到聚焦提示时表现最好：一次实现一个函数、修一个 bug、加一个功能。比如规划之后，我会提示代码生成模型："好，让我们实现计划的第 1 步"。我们编码、测试，然后进入第 2 步，如此类推。每块小到 AI 能在上下文里处理、你能理解它产出的代码。
这个方法防模型脱轨。如果你一次要太多，它很可能困惑或产出难解的"一团乱"。有开发者报告，当他们试图让 LLM 生成应用的大块时，结果是不一致和重复——"像 10 个开发者在没互相沟通的情况下工作"。我感受过那种痛；解法是停下、后退、把问题拆成更小的块。每轮迭代，我们带上已构建内容的上下文，增量添加。这也很好地配合测试驱动开发（TDD）——我们可以边走边为每块写或生成测试。
几个编码 agent 工具现在显式支持这种分块工作流。比如，我经常生成一个结构化的"提示计划"文件，包含每个任务的提示序列，这样 Cursor 之类的工具能逐个执行。关键点是避免巨大的跳跃。通过小循环迭代，我们大幅降低灾难性错误的概率，并能快速纠偏。LLM 擅长快速、受限的任务——利用这一点。
提供充分的上下文和指导
LLM 的好赖取决于你提供的上下文——展示它们相关代码、文档和约束。
在代码库上工作时，我确保把 AI 表现好所需的全部信息喂给它：它要修改或引用的代码、项目的技术约束、以及任何已知陷阱或首选方法。现代工具有帮助：Anthropic 的 Claude 可以在"Projects"模式下把整个 GitHub 仓库导入上下文；Cursor 或 Copilot 这类 IDE 助手自动把打开的文件包含进提示。但我经常更进一步——如果怀疑模型没有某些内容，我会用 MCP（如 Context7）或手动把代码库或 API 文档的重要部分复制进对话。
专家 LLM 用户强调这个"上下文打包"步骤。比如做一次"大脑倾倒"——把模型在编码前应该知道的一切倒出来，包括：高层目标和不变式、好解决方案的例子、以及要避免的方法的警告。如果我让 AI 实现一个棘手的方案，我可能会告诉它哪些 naive 方案太慢，或者从别处提供一个参考实现。如果我用一个冷门库或全新 API，我会把官方文档或 README 贴进去，这样 AI 不是盲目飞行。所有这些前置上下文都大幅提升输出质量，因为模型不是在猜——事实和约束就在它面前。
现在有工具可以自动化上下文打包。我试过 gitingest 或 repo2txt 这类工具，它们把你的代码库相关部分"倾倒"成一个文本文件给 LLM 读。处理大项目时它们是救星——生成一个关键源文件的 output.txt 包，让模型消化它。原则是：别让 AI 在残缺信息上运行。如果修一个 bug 需要理解四个不同模块，就展示那四个模块。是的，我们必须注意 token 上限，但当前前沿模型有相当大的上下文窗口。明智地使用它们。我经常只选任务相关的那部分代码，并明确告诉 AI 哪些不要关注（省 token）。
我觉得 Claude Skills 有潜力，因为它们把以前脆弱、重复的提示变成持久可复用的东西——把指令、脚本和领域专长打包成模块化能力，工具能在请求匹配时自动应用。这意味着比通用提示更可靠、更上下文感知的结果，从一次性交互转向编码可重复程序和团队知识的工作流。社区策展的 Skills 集合不少，但我最喜欢的例子是 frontend-design skill——它能"终结"LLM 生成 UI 里泛滥的紫色设计美学。在更多工具官方支持 Skills 之前，也有变通方案。
最后，用提示里的注释和规则引导 AI。我可能在一个代码片段前写："这是 X 的当前实现。我们需要扩展它做 Y，但小心别破坏 Z。"这些小提示大有帮助。LLM 是字面主义者——它们会遵循指令，所以给它们详细、有上下文的指令。通过主动提供上下文和指导，我们最小化幻觉和离谱建议，得到契合项目需求的代码。
选对模型（需要时用多个）
不是所有编码 LLM 都平等——有意图地挑选工具，别怕中途换模型。
2025 年我们被各种能力强大的编码 LLM 宠坏了。我工作流的一部分是为每个任务选择最适合的模型或服务。有时甚至并行试两个或更多 LLM，交叉检查它们如何不同地处理同一个问题。
每个模型都有自己的"性格"。关键是：如果一个模型卡住或产出平庸，换一个试试。我真的把同一个提示从一个聊天复制到另一个服务，看它能不能处理得更好。这种"模型抢椅子"能在你撞上模型盲区时救你。
另外，确保你用的是最好的版本。如果可以，用最新的"pro"级模型——因为质量很重要。是的，通常意味着付费，但生产力收益能证明它。最终，选那个"气质"和你合拍的 AI 结对程序员。我认识有人偏爱某个模型只是因为喜欢它回复的感觉。那完全合理——当你基本在和 AI 持续对话时，UX 和语气有影响。
我个人现在很多编码工作倾向于 Gemini（坦白：我在 Google 做 Gemini，自然更熟悉），因为交互感觉更自然，常常第一次就能理解我的请求。但需要时我会毫不犹豫换模型；有时第二意见能帮解决方案浮现。总结：用最适合工作的工具，记住你手头有一整支 AI 兵工厂。
在整个生命周期利用 AI 编码
命令行出现了新的 AI agent。Claude Code、OpenAI 的 Codex CLI 和 Google 的 Gemini CLI 都是 CLI 工具，你在项目目录里直接和它们对话——它们能读文件、跑测试、甚至多步修问题。我也用过 Google 的 Jules 和 GitHub 的 Copilot Agent——这些是异步编码 agent，实际上把你的仓库克隆进云 VM，在后台工作（写测试、修 bug，然后为你开 PR）。有点诡异：你发出"重构支付模块做 X"的命令，一会儿之后你收到一个带代码改动和通过测试的 pull request。我们真的活在未来。
话虽如此，这些工具不是万无一失的，你必须理解它们的局限。它们加速编码的机械部分——生成样板、应用重复改动、自动跑测试——但依然非常需要你的指导。比如，当用 Claude 或 Copilot 这类 agent 实现东西时，我经常把前面步骤的计划或待办列表提供给它，让它知道确切的任务序列。如果 agent 支持，我会在执行前把 spec.md 或 plan.md 加载进上下文。这让它保持在轨道上。
我们还没到让 AI agent 无人看管地编码整个功能并期待完美结果的阶段。相反，我以监督的方式使用这些工具：我让它们生成甚至运行代码，但盯着每一步，看到不对劲随时介入。还有 Conductor 之类的编排工具，让你在不同任务上并行跑多个 agent（本质上是规模化 AI 帮助的方式）——一些工程师在实验一次跑 3-4 个 agent 处理不同功能。我试过这种"大规模并行"方法；它能高效完成很多事，但监视多个 AI 线程也很费神！多数情况下，我一次只用一个主 agent，也许再加一个次要的做审查。
记住，这些是强力工具——你仍然控制扳机、引导结果。
保持人在循环——验证、测试、审查一切
AI 会很乐意产出看起来可信的代码，但你对质量负责——总是彻底审查和测试。我的一条基本原则是绝不盲目信任 LLM 的输出。就像 Simon Willison 精辟说的，把 LLM 结对程序员想成"过度自信、容易犯错"。它带着完全的自信写代码——包括 bug 或胡说——而且不会告诉你哪里不对，除非你抓到。所以我对待每一段 AI 生成的片段，都像来自初级开发者的代码：读一遍、跑一遍、按需测试。你必须测试它写的东西——跑单元测试，或手动演练功能，确保它真的做了它声称的事。
事实上，我把测试织进工作流本身。我早期的规划阶段经常包括为每步生成测试列表或测试计划。如果用 Claude Code 这类工具，我会指示它在实现任务后跑测试套件，有失败就调试。这种紧密反馈循环（写代码→跑测试→修复）正是 AI 擅长的——只要有测试存在。那些从编码 agent 获益最多的人，往往是有强大测试实践的人。Claude 这样的 agent 能在好测试套件作为安全网时"飞"过项目。没有测试，agent 可能心安理得地假设一切正常（"当然，都好！"）而实际上它已经弄坏了几处。所以，投资测试——它放大 AI 的用处和你对结果的信心。
即使超越自动化测试，做代码审查——人工和 AI 辅助都做。我例行暂停，逐行审查已生成的代码。有时我会开第二个 AI 会话（或不同模型），让它批评或审查第一个产出的代码。比如，我可能让 Claude 写代码，然后问 Gemini："你能审查这个函数有没有错误或改进吗？"这能抓到微妙问题。关键是别因为代码是 AI 写的就跳过审查。如果有的话，AI 写的代码需要额外审查，因为它有时表面上令人信服，却藏着人类不会立刻注意的缺陷。
我也用 Chrome DevTools MCP——和上一个团队一起做的——用于调试和质量循环，弥合静态代码分析和实时浏览器执行之间的鸿沟。它"给 agent 一双眼睛"，让它直接访问浏览器能看到的、检查 DOM、拿丰富的性能追踪、控制台日志或网络追踪。这个集成消除了手动上下文切换的摩擦，允许通过 LLM 直接做自动化 UI 测试。bug 可以基于真实运行时数据被高精度诊断和修复。
跳过人工监督的严重后果有据可查。一个重度依赖 AI 生成赶工项目的开发者，把结果描述为不一致的乱摊子——重复逻辑、错配的方法名、没有连贯架构。他意识到自己一直在"建、建、建"，没有退后一步真正看看 AI 编织出了什么。解法是一次痛苦的返工，以及再也不让事情失控到那种地步的誓言。我记住了。无论我用多少 AI，我仍然是负责的工程师。
实际操作上，这意味着只有在我理解代码之后才合并或发布。如果 AI 生成的东西绕来绕去，我会让它加注释解释，或者用更简单的术语重写。如果有什么感觉不对，我深挖——就像人类同事贡献了有危险信号的代码那样。
一切都是心态：LLM 是助手，不是自动可靠的编码者。我是资深开发者；LLM 是来加速我的，不是取代我的判断。保持这种姿态不仅产出更好的代码，也保护你自己作为开发者的成长。一句话：保持警觉，多测试，常审查。归根结底这还是你的代码库。
频繁提交，用版本控制当安全网。绝不提交你解释不了的代码。
频繁提交是你的存档点——它们让你撤销 AI 的失手、理解改动。
当和一个能快速生成大量代码的 AI 工作时，事情很容易跑偏。我通过采纳超细粒度的版本控制习惯来缓解。我早提交、频繁提交，甚至比手工编码时更频繁。每完成一个小任务或每次成功的自动编辑，我就带着清晰消息做一次 git 提交。这样，如果 AI 的下一个建议引入 bug 或混乱改动，我有一个最近的检查点可以回退（或 cherry-pick），不会丢失几小时工作。一位实践者把它比作"游戏里的存档点"——如果 LLM 会话翻车，你总能回滚到最后一个稳定提交。这条建议非常有用。当你知道必要时可以用 git reset 撤销时，大胆的 AI 重构实验压力小得多。
正确的版本控制在和 AI 协作时也有帮助。既然不能指望 AI 记住它做的一切（上下文窗口限制等），git 历史就成了宝贵的日志。我经常扫最近的提交来给 AI（或自己）简报改了什么。事实上，LLM 自己能利用你的提交历史——我把 git diff 或提交日志贴进提示，让 AI 知道哪些代码是新的、之前状态是什么。有趣的是，LLM 非常擅长解析 diff 和使用 git bisect 这类工具找 bug 是哪里引入的。它们遍历提交历史有无限的耐心，能增强你的调试。但这只有在你一开始就有整洁的提交历史时才有效。
另一个好处：带好消息的小提交基本上记录了开发过程，做代码审查（AI 或人类）时有帮助。如果一个 AI agent 一次做了五处改动然后坏了，那些改动在单独提交里，更容易定位哪个提交导致问题。如果全在一个叫"AI 改动"的巨型提交里，祝你好运！所以我自律：完成任务，跑测试，提交。这也和前面拆小块的建议契合——每块最终成为自己的提交或 PR。
最后，别怕用分支或 worktree 隔离 AI 实验。我采用的一个高级工作流（受 Jesse Vincent 等人启发）是为新功能或子项目开一个全新的 git worktree。这让你能在同一个仓库并行跑多个 AI 编码会话而不互相干扰，之后合并改动。有点像给每个 AI 任务一个自己的沙箱分支。如果一个实验失败，丢掉那个 worktree，主分支什么都没丢。如果成功，合并进去。这个方法在比如"让 AI 实现功能 A，同时我（或另一个 AI）做功能 B"时至关重要。版本控制正是让这种协作成为可能的东西。一句话：频繁提交、用分支组织工作、拥抱 git，把它作为让 AI 生成的改动可控可逆的控制机制。
用规则和示例定制 AI 的行为
通过提供风格指南、示例甚至"规则文件"来引导你的 AI 助手——一点前置调校换来好得多的输出。
我学到的一件事是，你不必接受 AI 的默认风格或方法——你可以通过给指南来极大影响它。比如，我有一个定期更新的 CLAUDE.md 文件，包含 Claude（Anthropic 的模型）要遵循的流程规则和偏好（用 Gemini CLI 时类似的有 GEMINI.md）。内容包括"用我们项目的风格写代码、遵守我们的 lint 规则、不要用某些函数、偏好函数式而非 OOP"等。开始会话时，我把这个文件喂给 Claude 让它对齐我们的约定。让模型"保持在轨道上"的效果惊人地好——它减少了 AI 脱稿或引入我们不想要模式的倾向。
即使没有花哨的规则文件，你也可以用自定义指令或系统提示设定基调。GitHub Copilot 和 Cursor 都引入了让你为项目配置 AI 行为的特性。我利用过这个——写一小段关于我们编码风格的文字，比如"用 4 空格缩进、React 里避免箭头函数、变量名要描述性、代码要过 ESLint"。有了这些指令，AI 的建议会贴合人类队友可能写的东西。Ben Congdon 提到他惊讶于很少人用 Copilot 的自定义指令，考虑到它多有效——通过提前提供示例和偏好，他能引导 AI 输出匹配团队习语的代码。我附议：花时间教 AI 你的期望。
另一个强大技巧是提供行内示例——你想要的输出格式或方法。如果我想让 AI 以非常特定的方式写一个函数，我可能先给它看代码库里已有的相似函数："这是我们实现 X 的方式，对 Y 用类似的方法。"如果我想要某种注释风格，我会自己写一条注释，让 AI 按那种风格继续。本质上，用模式引导模型。LLM 擅长模仿——给它们一两个示例，它们就会沿着那个方向继续。
社区也想出了创造性的"规则集"来驯服 LLM 行为。你可能听说过 "Big Daddy" 规则，或在提示里加"不许幻觉/不许欺骗"条款。这些基本是提醒 AI 诚实、不要过度编造不存在的代码的技巧。比如，我有时在提示前加："如果你不确定某事或代码库上下文缺失，要求澄清而不是编造答案。"这减少幻觉。我用另一个规则："修 bug 时总是在注释里简短解释你的推理。"这样 AI 生成修复时，也会留下"// Fixed: 改了 X 为 Y 以防 Z（按规格）"这样的注释。对后续审查超有用。
总结：别把 AI 当黑盒——调校它。通过配置系统指令、分享项目文档、写下明确规则，你把 AI 变成团队里更专业的开发者。类似给新人入职：你会给他们风格指南和一些入门提示，对吧？对你的 AI 结对程序员也一样。投资回报巨大：你得到需要更少调整、和你的代码库更顺滑集成的输出。
【未完，请看评论区】
30 215
之前给自己的博客做了一个「留言板」，现在把它独立了出来，叫「往来」。
目前，它适用于 Hugo，靠 Cloudflare 和 GitHub 运行，不需要另外维护服务器或数据库。
基本的运作方式很简单：读者在文章末尾写下一封信，来信会先经过 Cloudflare Turnstile，拦截大部分自动化的垃圾留言，然后进入作者自己的 GitHub 私有仓库。作者读过以后，可以只公开这封来信，也可以先回一封；加上 publish 标签，它才会出现在博客里的「往来」中。
读者不用注册，也不用登录 GitHub，留下的邮箱不会公开。
我做它的原因也很简单。我并不太需要一个热闹的评论区。读者能把话送到作者手里，已经很重要；至于要不要公开、要不要回复，可以留给作者慢慢决定。
项目刚独立出来，目前只支持 Hugo：
github.com
目前，它适用于 Hugo，靠 Cloudflare 和 GitHub 运行，不需要另外维护服务器或数据库。
基本的运作方式很简单：读者在文章末尾写下一封信，来信会先经过 Cloudflare Turnstile，拦截大部分自动化的垃圾留言，然后进入作者自己的 GitHub 私有仓库。作者读过以后，可以只公开这封来信，也可以先回一封；加上 publish 标签，它才会出现在博客里的「往来」中。
读者不用注册，也不用登录 GitHub，留下的邮箱不会公开。
我做它的原因也很简单。我并不太需要一个热闹的评论区。读者能把话送到作者手里，已经很重要；至于要不要公开、要不要回复，可以留给作者慢慢决定。
项目刚独立出来，目前只支持 Hugo：
github.com
15 21
分享我最新写的博客
《质变带来成功，量变则不会》
亲爱的朋友，
我最近读到一篇非常好的文章，来自美国顶级文理学院汉密尔顿学院的社会学教授丹尼尔·F·钱布利斯（Daniel F. Chambliss）。1989年，他发布的《卓越的日常性》（The Mundanity of Excellence），引起了社会各层面的极大反响。因为该论文，丹尼尔教授被授予美国游泳学会理论分会奖，以及美国社会学协会理论分会1989年度奖。
丹尼尔教授的个人经历丰富，除学术之外，还长期担任校队助理游泳教练，《卓越的日常性》包含着作者对从初学者到奥运选手各层级运动员的多年观察；跟随Mission Viejo Nadadores顶级俱乐部生活和训练；参加美国国内、奥运选拔赛及1984年洛杉矶奥运会；以及访问约120名全国级和世界级运动员与教练。
《卓越的日常》对我最大的启发，则是告诉我3个道理：1.卓越的表现，来自「质变」；2.一昧的追求「量变」，是不会卓越的；3.卓越是可拆解的。
丹尼尔教授观察到，乡村俱乐部的游泳运动员和奥运冠军之间的差异，来自3个层面：技术动作、纪律性、态度。
维度 细分项 C级选手/初学者 AAAA级选手/顶尖水平
技术 动作效率 动作幅度大，力量分散 动作紧凑，发力路径优化
蛙泳技术 手臂后拉，双腿外翻宽踢 手臂内扫，窄蹬夹水
转身技巧 身体抬高，速度损失 身体低位，快速衔接
水下与触壁 水下动作短，触壁随意 水下拉臂充分，严格双手触壁
动作表现 水花大，效率低 安静流畅，动作经济
纪律 训练执行 关注完成训练即可 严格执行标准与规则
细节意识 容忍小错误 追求每个细节完美
生活管理 准备不稳定 饮食、作息、热身高度规律
态度 对苦练的理解 认为训练是痛苦牺牲 认为训练是成长过程甚至享受
对重复训练 感到枯燥无聊 进入专注、冥想状态
目标与动力 避免困难，缺少挑战 主动寻找挑战，追求极限
从这张表看到，奥运冠军与一名普通的游泳运动员的，光技术动作就有了5、6项的不同，更别提其它各个方面，可以这么说，奥运冠军与其它选手之间的差异不是某个方面的差异，而是方方面面都存在这差异，这里体现出了一种「系统性」。普通选手在一个系统，而奥运冠军在另外一个系统。
所以，我认为，《卓越的日常》提示了一点，卓越来自系统性的做事方式不同。
那么是否训练时长变长，也能达到同样的效果呢？论文里，举了一个例子，「1968年奥运会400米栏金牌得主David Hemery访问了22个项目的世界级运动员。他报告说，在许多案例中，从开始专项训练直到最高水平，训练时间并没有显著变化。」换言之，顶级运动员的训练效果，相对于普通运动员的，可以称得上事半功倍。
不过，丹尼尔教授讨论的，是比较达到职业水平运动员之间的表现，而不是所有人都拿来比较。我要特别提这一点，因为在某个领域里「职业水平」，本身并非易事，也需要付出相当的努力，但显然，达不到「职业水平」是无法站在竞技台上与他人竞争。朋友，这里需要特别提醒你，无论是什么人，只要他在一个领域达到「职业水平」，那么就不要贸然兴起傲慢之心。
《卓越的日常性》还提出了一个反直觉的怪论，优秀的运动员成功并非来自某种天赋。论文里引用了Kalinowski的研究，多名运动员表示，「有天赋」这个评价往往来自他们取得了重要赛事的奖项之后，而非之前。也就是说，通常我们称一个人「有天赋」，往往是一种事后贴上的标签，而非提前就预知。所以丹尼尔教授认为，「也许根本没有所谓“天赋”，只有卓越的表现本身」。
论文的另外一个怪论，「卓越是日常的」，没有Drama戏剧性的效果。丹尼尔教授说，
「超常表现其实是几十种小技能或小活动的汇流。每一种技能都是学会的，或偶然发现的；随后经过认真练习成为习惯，最后组合成一个综合整体。任何一个行动本身都没有什么非凡或超人之处；只有当它们被稳定、正确地完成并全部组合起来时，才产生卓越。」
女游泳运动员Mary T. Meagher，外号「蝴蝶夫人」，职业生涯里一共获得奥林匹克5枚奖牌（3金1银1铜），在1981年创造了100米（57.93秒）和200米（96秒）蝶泳世界纪录，这两项纪录分别保持了长达近20年及21年之久。她面对采访时的回答是，「人们不知道成功有多么普通。」
论文里记录，自从她获得全国锦标赛资格后，就立志要打破200蝶泳世界记录。为此，她对自己的日常训练，施加了2个改变：1.每次训练都准时到场；2.在日常训练中严格按照比赛规则正确完成每一次转身。一年之内，她就打破了蝶泳世界记录。
可能你觉得到这里就结束了，但是《卓越的日常性》还提出另外一个反直觉的观点，即便是优秀的运动员，也只会为自己先为自己定下可实现的短期目标，而不会为自己设定那些高不可攀的宏大叙事。还是「蝴蝶夫人」的原话：「我从不看下一年以外，也从不看下一个层级以外。十岁时我没有想过奥运会；那时我想的是州锦标赛。达到地区赛资格标准后，我才开始想地区赛；达到全国青少年奥运赛资格后，我才开始想全国青少年奥运赛……我现在甚至无法去想1988年奥运会……想得太远会把人压垮。」
在日常，多名优秀的运动员将精力集中在可以实现的目标，比如某种技术动作的改进，邀请教练对训练效果进行深入的评估等等，一切都在循序渐进。而在重大比赛中，优秀的运动选手业也保持着这种「日常感」，他们并没有把那些重要比赛，比如奥林匹克运动会当成某种戏剧性时刻，而是认为「那不过是又一场比赛」。这种放平的心态有助于他们在关键时刻保持水准，而不是发挥失常。
朋友，不知道你是否和我也有同样的感觉，《卓越的日常性》就好像在揭示魔法背后的原理：卓越是可积累的，是正确的，是系统性，是质变的。关键是「质变」，由于我国从小学开始，就喜欢提倡「精诚所至，金石为开」，还有「愚公移山」的例子，但他们往往被引导在重复做某件事情上，而不是教人从「质变」的角度来看待事情。
朋友，我觉得这篇文章是我近年来阅读最有收获的一篇文章，期待与你一起讨论。
下载《卓越的日常性》中文版（PDF）
Keybr
这是一个练习打字的网站，我上周每天在上面练习30分钟，打字的速度比之前提升了很多。现在我终于在电脑前打字，没有一种憋住的感觉了。
Keybr的训练方式非常有趣，首先它的初级训练课程，训练你习惯输入包括单个字母的单词，只有正确率和速度达到一定程度之后，才能进入下一个字母。而在它的评价体系中，正确率要比速度重要很多。当完成了所有字母的初级训练，就会进入下一个阶段，此时Keybr会随机提供多个单词，让你完成输入。但它会统计，你这一次训练容易在输入哪个字母中犯错，然后再下一次训练里，提供更多包含该字母的英文单词。
我在5天内，将自己的打字速度从30 WPM提升到60 WPM，效果非常显著。
想下载 PDF 的请看评论区
《质变带来成功，量变则不会》
亲爱的朋友，
我最近读到一篇非常好的文章，来自美国顶级文理学院汉密尔顿学院的社会学教授丹尼尔·F·钱布利斯（Daniel F. Chambliss）。1989年，他发布的《卓越的日常性》（The Mundanity of Excellence），引起了社会各层面的极大反响。因为该论文，丹尼尔教授被授予美国游泳学会理论分会奖，以及美国社会学协会理论分会1989年度奖。
丹尼尔教授的个人经历丰富，除学术之外，还长期担任校队助理游泳教练，《卓越的日常性》包含着作者对从初学者到奥运选手各层级运动员的多年观察；跟随Mission Viejo Nadadores顶级俱乐部生活和训练；参加美国国内、奥运选拔赛及1984年洛杉矶奥运会；以及访问约120名全国级和世界级运动员与教练。
《卓越的日常》对我最大的启发，则是告诉我3个道理：1.卓越的表现，来自「质变」；2.一昧的追求「量变」，是不会卓越的；3.卓越是可拆解的。
丹尼尔教授观察到，乡村俱乐部的游泳运动员和奥运冠军之间的差异，来自3个层面：技术动作、纪律性、态度。
维度 细分项 C级选手/初学者 AAAA级选手/顶尖水平
技术 动作效率 动作幅度大，力量分散 动作紧凑，发力路径优化
蛙泳技术 手臂后拉，双腿外翻宽踢 手臂内扫，窄蹬夹水
转身技巧 身体抬高，速度损失 身体低位，快速衔接
水下与触壁 水下动作短，触壁随意 水下拉臂充分，严格双手触壁
动作表现 水花大，效率低 安静流畅，动作经济
纪律 训练执行 关注完成训练即可 严格执行标准与规则
细节意识 容忍小错误 追求每个细节完美
生活管理 准备不稳定 饮食、作息、热身高度规律
态度 对苦练的理解 认为训练是痛苦牺牲 认为训练是成长过程甚至享受
对重复训练 感到枯燥无聊 进入专注、冥想状态
目标与动力 避免困难，缺少挑战 主动寻找挑战，追求极限
从这张表看到，奥运冠军与一名普通的游泳运动员的，光技术动作就有了5、6项的不同，更别提其它各个方面，可以这么说，奥运冠军与其它选手之间的差异不是某个方面的差异，而是方方面面都存在这差异，这里体现出了一种「系统性」。普通选手在一个系统，而奥运冠军在另外一个系统。
所以，我认为，《卓越的日常》提示了一点，卓越来自系统性的做事方式不同。
那么是否训练时长变长，也能达到同样的效果呢？论文里，举了一个例子，「1968年奥运会400米栏金牌得主David Hemery访问了22个项目的世界级运动员。他报告说，在许多案例中，从开始专项训练直到最高水平，训练时间并没有显著变化。」换言之，顶级运动员的训练效果，相对于普通运动员的，可以称得上事半功倍。
不过，丹尼尔教授讨论的，是比较达到职业水平运动员之间的表现，而不是所有人都拿来比较。我要特别提这一点，因为在某个领域里「职业水平」，本身并非易事，也需要付出相当的努力，但显然，达不到「职业水平」是无法站在竞技台上与他人竞争。朋友，这里需要特别提醒你，无论是什么人，只要他在一个领域达到「职业水平」，那么就不要贸然兴起傲慢之心。
《卓越的日常性》还提出了一个反直觉的怪论，优秀的运动员成功并非来自某种天赋。论文里引用了Kalinowski的研究，多名运动员表示，「有天赋」这个评价往往来自他们取得了重要赛事的奖项之后，而非之前。也就是说，通常我们称一个人「有天赋」，往往是一种事后贴上的标签，而非提前就预知。所以丹尼尔教授认为，「也许根本没有所谓“天赋”，只有卓越的表现本身」。
论文的另外一个怪论，「卓越是日常的」，没有Drama戏剧性的效果。丹尼尔教授说，
「超常表现其实是几十种小技能或小活动的汇流。每一种技能都是学会的，或偶然发现的；随后经过认真练习成为习惯，最后组合成一个综合整体。任何一个行动本身都没有什么非凡或超人之处；只有当它们被稳定、正确地完成并全部组合起来时，才产生卓越。」
女游泳运动员Mary T. Meagher，外号「蝴蝶夫人」，职业生涯里一共获得奥林匹克5枚奖牌（3金1银1铜），在1981年创造了100米（57.93秒）和200米（96秒）蝶泳世界纪录，这两项纪录分别保持了长达近20年及21年之久。她面对采访时的回答是，「人们不知道成功有多么普通。」
论文里记录，自从她获得全国锦标赛资格后，就立志要打破200蝶泳世界记录。为此，她对自己的日常训练，施加了2个改变：1.每次训练都准时到场；2.在日常训练中严格按照比赛规则正确完成每一次转身。一年之内，她就打破了蝶泳世界记录。
可能你觉得到这里就结束了，但是《卓越的日常性》还提出另外一个反直觉的观点，即便是优秀的运动员，也只会为自己先为自己定下可实现的短期目标，而不会为自己设定那些高不可攀的宏大叙事。还是「蝴蝶夫人」的原话：「我从不看下一年以外，也从不看下一个层级以外。十岁时我没有想过奥运会；那时我想的是州锦标赛。达到地区赛资格标准后，我才开始想地区赛；达到全国青少年奥运赛资格后，我才开始想全国青少年奥运赛……我现在甚至无法去想1988年奥运会……想得太远会把人压垮。」
在日常，多名优秀的运动员将精力集中在可以实现的目标，比如某种技术动作的改进，邀请教练对训练效果进行深入的评估等等，一切都在循序渐进。而在重大比赛中，优秀的运动选手业也保持着这种「日常感」，他们并没有把那些重要比赛，比如奥林匹克运动会当成某种戏剧性时刻，而是认为「那不过是又一场比赛」。这种放平的心态有助于他们在关键时刻保持水准，而不是发挥失常。
朋友，不知道你是否和我也有同样的感觉，《卓越的日常性》就好像在揭示魔法背后的原理：卓越是可积累的，是正确的，是系统性，是质变的。关键是「质变」，由于我国从小学开始，就喜欢提倡「精诚所至，金石为开」，还有「愚公移山」的例子，但他们往往被引导在重复做某件事情上，而不是教人从「质变」的角度来看待事情。
朋友，我觉得这篇文章是我近年来阅读最有收获的一篇文章，期待与你一起讨论。
下载《卓越的日常性》中文版（PDF）
Keybr
这是一个练习打字的网站，我上周每天在上面练习30分钟，打字的速度比之前提升了很多。现在我终于在电脑前打字，没有一种憋住的感觉了。
Keybr的训练方式非常有趣，首先它的初级训练课程，训练你习惯输入包括单个字母的单词，只有正确率和速度达到一定程度之后，才能进入下一个字母。而在它的评价体系中，正确率要比速度重要很多。当完成了所有字母的初级训练，就会进入下一个阶段，此时Keybr会随机提供多个单词，让你完成输入。但它会统计，你这一次训练容易在输入哪个字母中犯错，然后再下一次训练里，提供更多包含该字母的英文单词。
我在5天内，将自己的打字速度从30 WPM提升到60 WPM，效果非常显著。
想下载 PDF 的请看评论区
5 22
早两天，在练习羽毛球的时候，发现很多羽毛球教学视频所说的「顶肘才能发力」的原因，其实，它属于以前经常提到的「鞭打发力」，和「内旋发力」里的发力环节之一。
而我理解中的「鞭打发力」和「内旋发力」，都是羽毛球发力技巧的一种。尤其是陶菲克的暴力杀球和反手，都需要先将手肘顶出去，然后摆动前臂发力——力量十分集中，爆发力强，球又快又重。
为何需要先把手肘顶出去？就我的体验，手肘顶出去，就是为了创造一个「旋转」的空间，让发力得更充分，更透。就这个发力过程中的「旋转」，不光羽毛球有，「拳术」也涉及。我从百度百科查询到定义：
#+begin_quote
拳术中的旋转发力是通过脚地蹬地、腰胯拧转与肩臂旋动将全身力量合为一体的打击方式。
#+end_quote
非常有趣，从这个定义看，拳术的动力链和羽毛球简直一模一样，不同的两者一个是赤手空拳，一个手里拿着羽毛球拍，所以最后的爆发阶段有所不同。
然后，我观察「拳术」最后阶段，也就是肩臂旋动时，也不是直接将拳头直接击打出去，而是要拧一下，将拳头从竖拧到横。我以前不理解这一下的作用，但我现在大概理解了。其实最后拳头拧一下，依然是肩臂旋动发力的一环，而且是力量传递的最后一环，如果不增加这一环节，力量在传递过程中反而会耗散——这个常识非常反直觉。
而在羽毛球发力过程当中，最后这一下顶肘也起到了「拧」的效果，不同的是，顶肘的作用实际上是为旋转前臂创造空间，将动力链的力量传导一直传递到最后挥拍那一步上。
「鞭打发力」和「内旋发力」中，顶肘这个基本动作环节必不可少。首先，顶肘之后，在之后的挥拍里，主要依靠的是前臂，如果说前臂握着拍子是在空中旋转画圆，那么手肘和大臂则在这个过程中起到旋转轴的作用，这个轴是基本固定不动的——这就是「鞭打发力」，和「内旋发力」。只不过「鞭打发力」侧重描述，大臂和肘部伸展之后固定，而让前臂带动球拍像鞭子一样「甩」出去；而「内旋发力」则侧重描述手肘和大臂直接作为旋转轴的作用。
大部分球员发力都需要顶肘，尤其是陶菲克的动作，从他挥拍动作和发力框架可以看到，在架拍阶段，他通常要把前臂和大臂夹成一个锐角，这就是「顶肘」。我唯一发现不太一样的，是晚年林丹，他的前臂和大臂之间夹角已成一个钝角，那么问题是，他有无鞭打和内旋呢？观察下来也是有的，基本框架没变，依然是固定大臂和肘部，然后前臂旋转。只不过林丹的身体素质太好，除了杀球，他的发力基本上就集中在手臂内，不需要完整的动力链。
而我理解中的「鞭打发力」和「内旋发力」，都是羽毛球发力技巧的一种。尤其是陶菲克的暴力杀球和反手，都需要先将手肘顶出去，然后摆动前臂发力——力量十分集中，爆发力强，球又快又重。
为何需要先把手肘顶出去？就我的体验，手肘顶出去，就是为了创造一个「旋转」的空间，让发力得更充分，更透。就这个发力过程中的「旋转」，不光羽毛球有，「拳术」也涉及。我从百度百科查询到定义：
#+begin_quote
拳术中的旋转发力是通过脚地蹬地、腰胯拧转与肩臂旋动将全身力量合为一体的打击方式。
#+end_quote
非常有趣，从这个定义看，拳术的动力链和羽毛球简直一模一样，不同的两者一个是赤手空拳，一个手里拿着羽毛球拍，所以最后的爆发阶段有所不同。
然后，我观察「拳术」最后阶段，也就是肩臂旋动时，也不是直接将拳头直接击打出去，而是要拧一下，将拳头从竖拧到横。我以前不理解这一下的作用，但我现在大概理解了。其实最后拳头拧一下，依然是肩臂旋动发力的一环，而且是力量传递的最后一环，如果不增加这一环节，力量在传递过程中反而会耗散——这个常识非常反直觉。
而在羽毛球发力过程当中，最后这一下顶肘也起到了「拧」的效果，不同的是，顶肘的作用实际上是为旋转前臂创造空间，将动力链的力量传导一直传递到最后挥拍那一步上。
「鞭打发力」和「内旋发力」中，顶肘这个基本动作环节必不可少。首先，顶肘之后，在之后的挥拍里，主要依靠的是前臂，如果说前臂握着拍子是在空中旋转画圆，那么手肘和大臂则在这个过程中起到旋转轴的作用，这个轴是基本固定不动的——这就是「鞭打发力」，和「内旋发力」。只不过「鞭打发力」侧重描述，大臂和肘部伸展之后固定，而让前臂带动球拍像鞭子一样「甩」出去；而「内旋发力」则侧重描述手肘和大臂直接作为旋转轴的作用。
大部分球员发力都需要顶肘，尤其是陶菲克的动作，从他挥拍动作和发力框架可以看到，在架拍阶段，他通常要把前臂和大臂夹成一个锐角，这就是「顶肘」。我唯一发现不太一样的，是晚年林丹，他的前臂和大臂之间夹角已成一个钝角，那么问题是，他有无鞭打和内旋呢？观察下来也是有的，基本框架没变，依然是固定大臂和肘部，然后前臂旋转。只不过林丹的身体素质太好，除了杀球，他的发力基本上就集中在手臂内，不需要完整的动力链。
9 30
当前 AI 领域有各种新的工具出现，但看完李永乐老师讲解王虹、邓煜获得菲尔兹奖背后的成果，和历史上的沿革，我深深地感到：
当前 AI 在工具层面领域，工程太多，而数学太少。
不应该沉湎于过往的软件工程实践经验，还应该从数学的角度来解题才对啊。
当前 AI 在工具层面领域，工程太多，而数学太少。
不应该沉湎于过往的软件工程实践经验，还应该从数学的角度来解题才对啊。
2 00
RLM 架构的提出者 Alex L. Zhang 在最新的博客里，分享了他实践 了 Agent Harness 架构的经验。
他用数学框架论证了一件事：一个好的 harness 能让模型把两个看上去完全不同的任务，但能够像资深专家一样将它们看成「同一个」。
Alex L. Zhang 用等价类和同构给了这个直觉一个严格的描述。
《语言模型 Harness 是组合泛化器》
Alex L. Zhang，2026 年
问题
现代 post-training 已经变成了一种蛮力范式：堆更多的环境、更长的训练视野。为什么？因为前沿 Transformer 在组合泛化——将已学到的能力组合起来解决新问题——这一点上依然很弱。
过去几年，我们通过给 Transformer 加 scaffold 来攻克更难的任务——先是思维链，再是工具调用。但泛化本身一直留给了底层的神经网络和它 2017 年的 token 级归纳偏见。这让每个新领域都要求自己的训练数据投入——scaling 的回报递减。
核心论点
更好的泛化应该是 harness 的活。harness 是那个坐在外部世界和神经网络之间的程序——它决定如何把任意长度和复杂度的环境状态编码成一个或多次 LLM 输入，以及如何决定下一步行动。
"harness 的首要职责应该是承载一个更高层次的归纳偏见，能够将不熟悉、复杂的问题，简化成底层神经网络已经熟悉的问题的组合。"
具体来说，一个好的 harness 应该让每一次对底层 Transformer 的调用都处于"局部 in-distribution"——即每次调用处理的 prompt 在模型的训练数据范围内。一个经常被忽略的事实是：一个好的 harness 可以把那些看起来需要 post-training 突破的问题，简化成现有模型的基础能力。
RLM（递归语言模型）
RLM 是一个具体的 harness 实例，它做两件事：
1. 上下文卸载（Context Offloading）：把输入特定的上下文作为符号变量传递出去，根模型调用不直接看到它。这样两个结构相似但领域不同的任务，在根模型的上下文窗口里看起来 token 级别一模一样。
2. 程序化子 agent 调用（Programmatic Sub-Agent Calling）：中间计算和信息存在 REPL 里，不被塞回主上下文。标准 agent 用工具调用的信息直接回到主上下文，改变了输出分布。RLM 的子调用让主上下文避开任务特定信息。
这让 harness 能够在轨迹空间上诱导等价类：两个共享潜在结构但领域完全不同的任务（比如 BrowseComp-Plus 的信息搜寻和 OOLONG 的 TREC 问题聚合），在根 LM 眼里是同构的——字面意思上的同构，token 级别相同。
实验结果
RL 训练只在短任务上进行，但在以下维度实现泛化：
长度泛化：训练任务 8-32 倍长的 held-out 任务上保持性能。如果 RLM 学会了一个与长度无关的策略，它直接泛化到更长长度。
策略泛化（跨领域）：在三个场景下验证——底层策略相同（聚合、搜索过滤、MapReduce），但输入领域完全不同：
• OOLONG：TREC 问题 → spam 检测问题
• OBLIQ-Bench：写作作者识别 → 数学推理模式匹配
• OBLIQ-Bench Descriptive：Twitter 立场检测 → Wildchat 错误查找
结果：同样训练量的提升，RLM harness 的泛化收益大约是裸 Transformer 的 10 倍。
更深层的含义
作者很小心地没有掉进"我们应该都去手工设计 harness 策略"的陷阱。他的真论点不是"handcrafted > learned"。而是：
"Scaling 数据仍然是进步的最大驱动力，但我们将数据输入的那个机器的结构和它的归纳偏见，将决定这个 scaling 的系数。"
Transformer 的设计空间——主要由可微神经元算子组成——缺少某种根本性的东西。但语言作为一个强大的底层基础，已经让我们能在数年间大规模训练。现在，AI 系统的架构不再被限制在简单的可微算子上。我们可以通过 RL 端到端地训练编码了更高层次、更符号化的归纳偏见的系统。
RLM 是这个方向的一个具体路径。通过上下文卸载和程序化子 agent，它做到了 Transformer 做不好的事：把不同但结构化相似的任务，压缩到同一 token 轨迹上，让 RL 在更小的数据上也能泛化。
alexzhang13.github.io
他用数学框架论证了一件事：一个好的 harness 能让模型把两个看上去完全不同的任务，但能够像资深专家一样将它们看成「同一个」。
Alex L. Zhang 用等价类和同构给了这个直觉一个严格的描述。
《语言模型 Harness 是组合泛化器》
Alex L. Zhang，2026 年
问题
现代 post-training 已经变成了一种蛮力范式：堆更多的环境、更长的训练视野。为什么？因为前沿 Transformer 在组合泛化——将已学到的能力组合起来解决新问题——这一点上依然很弱。
过去几年，我们通过给 Transformer 加 scaffold 来攻克更难的任务——先是思维链，再是工具调用。但泛化本身一直留给了底层的神经网络和它 2017 年的 token 级归纳偏见。这让每个新领域都要求自己的训练数据投入——scaling 的回报递减。
核心论点
更好的泛化应该是 harness 的活。harness 是那个坐在外部世界和神经网络之间的程序——它决定如何把任意长度和复杂度的环境状态编码成一个或多次 LLM 输入，以及如何决定下一步行动。
"harness 的首要职责应该是承载一个更高层次的归纳偏见，能够将不熟悉、复杂的问题，简化成底层神经网络已经熟悉的问题的组合。"
具体来说，一个好的 harness 应该让每一次对底层 Transformer 的调用都处于"局部 in-distribution"——即每次调用处理的 prompt 在模型的训练数据范围内。一个经常被忽略的事实是：一个好的 harness 可以把那些看起来需要 post-training 突破的问题，简化成现有模型的基础能力。
RLM（递归语言模型）
RLM 是一个具体的 harness 实例，它做两件事：
1. 上下文卸载（Context Offloading）：把输入特定的上下文作为符号变量传递出去，根模型调用不直接看到它。这样两个结构相似但领域不同的任务，在根模型的上下文窗口里看起来 token 级别一模一样。
2. 程序化子 agent 调用（Programmatic Sub-Agent Calling）：中间计算和信息存在 REPL 里，不被塞回主上下文。标准 agent 用工具调用的信息直接回到主上下文，改变了输出分布。RLM 的子调用让主上下文避开任务特定信息。
这让 harness 能够在轨迹空间上诱导等价类：两个共享潜在结构但领域完全不同的任务（比如 BrowseComp-Plus 的信息搜寻和 OOLONG 的 TREC 问题聚合），在根 LM 眼里是同构的——字面意思上的同构，token 级别相同。
实验结果
RL 训练只在短任务上进行，但在以下维度实现泛化：
长度泛化：训练任务 8-32 倍长的 held-out 任务上保持性能。如果 RLM 学会了一个与长度无关的策略，它直接泛化到更长长度。
策略泛化（跨领域）：在三个场景下验证——底层策略相同（聚合、搜索过滤、MapReduce），但输入领域完全不同：
• OOLONG：TREC 问题 → spam 检测问题
• OBLIQ-Bench：写作作者识别 → 数学推理模式匹配
• OBLIQ-Bench Descriptive：Twitter 立场检测 → Wildchat 错误查找
结果：同样训练量的提升，RLM harness 的泛化收益大约是裸 Transformer 的 10 倍。
更深层的含义
作者很小心地没有掉进"我们应该都去手工设计 harness 策略"的陷阱。他的真论点不是"handcrafted > learned"。而是：
"Scaling 数据仍然是进步的最大驱动力，但我们将数据输入的那个机器的结构和它的归纳偏见，将决定这个 scaling 的系数。"
Transformer 的设计空间——主要由可微神经元算子组成——缺少某种根本性的东西。但语言作为一个强大的底层基础，已经让我们能在数年间大规模训练。现在，AI 系统的架构不再被限制在简单的可微算子上。我们可以通过 RL 端到端地训练编码了更高层次、更符号化的归纳偏见的系统。
RLM 是这个方向的一个具体路径。通过上下文卸载和程序化子 agent，它做到了 Transformer 做不好的事：把不同但结构化相似的任务，压缩到同一 token 轨迹上，让 RL 在更小的数据上也能泛化。
alexzhang13.github.io
1 01
Matt Pocock 这个 60 秒视频，推荐了一本书，而且他认为在「战略编程」方面，毫无疑问排行第一。
Matt Pocock：#1 战略性编程书籍推荐
"AI 已经吃掉了日常编码和战术性编程。所以很多人问我：怎么学战略性编程？怎么学长期视角？怎么让你能提前看到代码库的问题，让 AI 在你的代码库里有效工作？
我的建议是回到这些老书。今天要说的是 The Pragmatic Programmer。
这本书是我永远推荐的一本。它可能是我读过布局最好的技术书。里面有太多关于'编程时如何战略性思考'的见解。我从中拿了很多东西直接塞进 system prompt 里，效果很好。比如可追溯性（traceability）、'不要超过你的车灯'（don't outrun your headlights）、巧合编程（programming by coincidence）——我们开发者用的很多术语，都源自这本书。
几个月前重读这本书让我确信：真正的软件基础仍然重要。 因为这本书里的每一条，都像是为 AI 时代写的。
So, The Pragmatic Programmer, David Thomas, Andrew Hunt. Get it."
视频：youtube.com
Matt Pocock：#1 战略性编程书籍推荐
"AI 已经吃掉了日常编码和战术性编程。所以很多人问我：怎么学战略性编程？怎么学长期视角？怎么让你能提前看到代码库的问题，让 AI 在你的代码库里有效工作？
我的建议是回到这些老书。今天要说的是 The Pragmatic Programmer。
这本书是我永远推荐的一本。它可能是我读过布局最好的技术书。里面有太多关于'编程时如何战略性思考'的见解。我从中拿了很多东西直接塞进 system prompt 里，效果很好。比如可追溯性（traceability）、'不要超过你的车灯'（don't outrun your headlights）、巧合编程（programming by coincidence）——我们开发者用的很多术语，都源自这本书。
几个月前重读这本书让我确信：真正的软件基础仍然重要。 因为这本书里的每一条，都像是为 AI 时代写的。
So, The Pragmatic Programmer, David Thomas, Andrew Hunt. Get it."
视频：youtube.com
5 12