ai-coding-best-practice

2026/2/1

2026/4/1 感觉版本又更新一轮了，这里的东西有些化为理所当然的旧实践了，有些过时了

上下文管理与基本原则

大语言模型的工作方式，是词元预测，它本质上一种补全

而决定补全内容的，几乎就是上下文，这是我们作为用户能够唯一影响的因素，模型根据上下文，根据他如何被训练的，在内部进行大量计算，得出答案

可以粗糙地把他分为内部处理和外部输入两个角度，决定模型的输出内容

prompt engineering这个词曾经流行过，强调的是如何向AI提问或者说提指令上，当然内部也有提及给AI合适的上下文的技巧，但是把上下文作为一个技巧的视角淡化了上下文的概念

当你在思考给ai什么上下文，而不是思考给他什么prompt时，你很自然地就会给一些线索/情报/信息，所以我个人不喜欢提示词工程这个概念，倾向于从上下文管理的角度去思考如何让AI去得到更好的回答

毫无疑问，上下文管理是门艺术，之所以采用艺术这个词，是因为这个事情没有严谨的论证，做起来很灵活，没有什么固定的范式，但是还是有一些通用的思想的

上下文显然不是越少越好的，解决问题是需要必要的信息的

上下文也不会越多越好，大模型在做文本补全，在对下一个词做概率计算，无用的干扰信息会加大出错的概率，有一个概念叫做context rot，无关的上下文只会分散注意力

那么如何把握其中的分寸呢，一个简单的原则是把大模型当作一个人来沟通

在编程的场景就是把ai当作刚入职的经验丰富的程序员，拥有技能但对你当前的代码库十分陌生

你让他快速上手解决问题，不会让他看整个仓库的代码，如果你有解决问题的思路或者解决问题的线索，你当然应该告诉他，无用的信息干扰人的判断，有用的信息帮助人解决问题

上下文应该追求有效，简洁，清晰，标准很模糊，思考人是否可以很好的处理这些上下文是最简洁的思维模型

如果你熟悉AI 编程，或许能意识到plan模式就是在做这件事情，他会向你确认问题，引导你去迭代上下文，让模型有最好的表现

我提到两件重要的事情

外部输入和内部处理决定输出质量
把大模型当作人来对待

上下文管理的话题显然是倾向于外部输入端的，事实上作为使用者，我们只能影响外部输入，但这不意味着我们不需要了解内部处理，因为内部处理会影响我们外部输入的最佳实践

把大模型当作人来对待，这个观点就会很好理解，对一个问题描述清楚对于所有人都是相同必要的，但是提供问题的思路，描述问题的方式等等可能偏移的事情，对不同性格不同思考方式的人，效果是不同的，模型也是一样，不同的模型不同的载体都会造成提示词最佳实践的变化，而没人能搞清楚自己精确的思考模型，更别说别人了，思考方式这个东西就是个黑盒所以我说上下文管理是门艺术

搞清楚黑盒的表现只能是尝试使用不同的输入，观察他输出的表现，你要不断使用ai，观察不同模型的表现，观察不同模型的优势劣势，培养使用模型的直觉，预测他需要什么上下文才能更好的解决问题

使用ai，才能用好ai，这看似是一个废话，但是是大多数人必须要经历的过程，因为模型迭代的速度比经验迭代的速度快deepseek r1现在已经是路边一条了，但是在2025年1月它的影响力巨大

我的经验与实践

Peter Steinberger是clawdbot的作者，是一个重度AI编程的实践者，他的GitHub仓库每天都是数百个提交，维护一堆开源项目，他的观点是我一大主要参考源，相关的博客有在文末给到，使用的主力工具是codex的cli，配置在文末博客中也有提及

模型与环境对比

IDE内置的agent和codex/claude code CLI存在策略上的差异

IDE内置agent指的是和ide绑定的agent，他们更强调人的作用，强调和IDE本身的集成，能关注你光标选中的位置，选中的文件，很少主动“全仓扫描”，更偏向局部修补

CLI天生就是用来处理文件的，思考会基于大量文件，他有权限查看你的代码库，因此自然在跨文件的处理上存在优势，默认把任务当成一个需要完整理解的工程问题，愿意先花大量时间读文件、建内部模型

CLI插件则有点结合了两者的能力，是我认为目前最好的形态，像是codex/cc/opencode这类产品

而相同的环境不同的模型也有不同的表现，gpt倾向于阅读全面的上下文再解决问题，Claude倾向于尽快出一个解决问题的方案，简单问题两者都可以轻易解决，复杂问题上gpt更慢，返工率更低，Claude的速度更快，返工率更高

我的选择是使用codex，这里是因为我的经验和我阅读博客的人的经验是一致的，返工比codex的漫长思考时间更耗时，codex在收集自己需要的上下文上做的更好，其次较长的思考时间允许人并行处理，有便宜的购买方式也是它的优点

AI能处理复杂问题吗？

基于大量文件思考的模式，天生就是自然的计划模式，能够拥有更高质量的上下文和输出，当然有的人会认为他们更高频率的是在做局部修改，认为这种模式太重了

我认为这取决于你让ai做多少事，你想让ai处理更多任务，那么就应该倾向于CLI，因为这种模式注定能处理更多更复杂的任务

常见的观点是真正复杂的任务还是要让人来处理，AI在这类问题上做不好，我的观点是其实可以尝试去交给AI去做，人们以一种不公平的方式评价人类和ai，你给复杂问题和简单问题相同的复杂度的上下文，去指望ai能有一样好的产出，这就是不公平的，因为你处理简单问题也不需要过多的上下文，但处理复杂问题的时候往往会根据对项目的理解分析问题，寻找线索，再给出方案，却没把这些过程给AI

为什么不应该指望AI去自动化的做这件事，还是一样的观点，AI是对你代码库从零开始理解去解决问题的优秀工程师，你对代码库有所理解的再处理问题的工程师，在复杂问题下这种不公平才会显露出来

当然上下文详细到说出每一行代码怎么改，那AI可能确实能处理一切问题，但就只是一个代笔工具也没那么大的价值了

关键是分配和步数的问题，只用三步解决的问题你可以把描述问题的第一步做完直接让AI解决，需要分析，思考，抽象的十步才能解决的问题你不能一样只做描述问题的第一步，你可能要做分析问题的第二步和提供解决问题方向的第三步，以及定位问题的第四步，作为上下文给到AI才是公平的较量

在一个满分的上下文下，AI能准确解决一切问题，你如果知道每一行代码怎么写，你不可能无法用AI做到，所以这么看，AI就是万能的

而现在你可能不需要知道每一行代码怎么写，给出明确的解决问题方案这样一个八十分的上下文，AI就能解决百分之八十以上的问题

我作为一个初级工程师遇到的复杂问题，做到提供解题思路的提示这一步就能解决绝大多数我认为复杂的问题了，比如说在A情况下代码正常工作，B情况下不行，从这个角度分析，或者先分析这段代码时序，再去修复这个代码

现在AI进步的速度是很夸张，或许未来十步的问题真的能简化到一步，二十步的问题才你才需要提供四步的思路也说不定

codex的一大优势就体现在对你提供上下文要求更低，返工率更低，Peter也认为在codex中prompt可以不那么详细，它会自己收集需要的信息

使用 claude 的时候，我过去总是写非常详尽的提示（当然不是，我说话），因为这种模型提供越多的上下文，“理解我”的效果就越好。虽然这在任何模型上都是真的，但我发现使用 codex 后，我的提示显著缩短了。通常只需要 1-2 句话加上一张图片。模型在阅读代码库方面非常出色，直接就能“理解我”。我甚至有时会回到打字，因为 codex 需要很少的上下文就能理解。

培养直觉

这块没什么方法论，就是要多做，这里贴一下Peter的相关描述

当你进行足够多的自主式工程时，你会对哪些地方容易实现、哪些地方模型可能会遇到困难有直觉，因此我经常只是输入一个提示，Codex 会持续运行 30 分钟，我就能得到我需要的结果。有时需要一些调整或创造性思维，但通常事情都很直接。

我构建软件的方式非常迭代。我构建一些东西，然后玩玩它，看看它“感觉”如何，然后产生新想法来完善它。很少情况下我脑海中会有一个完整的概念。当然，我有一个大致的想法，但通常在探索问题领域时，这个想法会发生巨大变化。因此，那些将完整想法作为输入然后输出结果的系统对我来说效果不佳。我需要与之互动，触摸它，感受它，观察它，这就是我如何发展它的。

每当我想到一个变更时，我就能相当准确地预感到它需要多长时间以及会影响到多少文件。我可以在我的代码库中扔很多小炸弹，或者扔一个“胖子”炸弹和几个小炸弹。如果你扔多个大炸弹，那就无法进行隔离式提交，如果出了问题也难以重置。

这也是我在观察我的智能体时一个很好的指标。如果某件事比我预想的要花更长时间，我就直接按 Esc 键，然后问“状态如何”来获取状态更新，然后要么帮助模型找到正确的方向，要么中止或继续。不要害怕中途停止模型，文件更改是原子的，它们非常擅长从停止的地方继续。

当我不确定影响时，我会使用“在做出更改前给我几个选项”来评估它。