先喂对上下文，再谈 AI 编码效率

认真用 AI 写代码大概两年了。最开始那两个月体验很差：生成的代码风格和项目格格不入、会引用项目里根本没有的库、让它改一个函数，它能顺手「优化」三个不相关的文件。我一度觉得是模型不行，直到某天盯着一段它生成的代码反应过来——它不是不行，它是在盲猜。它根本看不到我的项目。

后来模型升级了一代又一代，但我体验的跃升，反而是从换用法开始的。同一代模型，用得烂和用得好，产出质量能差出一个档次，差别大多不在话术，在上下文。

一、把项目约定写成一个文件

现在每个项目我做的第一件事，是在根目录放一个说明文件（AGENTS.md / CLAUDE.md 之类，工具叫法不一，作用相同），写清楚：

• 技术栈与版本：Python 3.11 + FastAPI + SQLAlchemy 这种粒度；
• 目录结构：哪个目录放什么，新代码应该加在哪；
• 硬性规矩：比如「错误必须显式处理，禁止裸 except」「不引入新依赖，除非先说明理由」；
• 不要做的事：不要动 legacy/ 目录，不要「顺手」重构。

这个文件相当于新同事入职第一天看的 Wiki。写一次，之后每一次会话都受益。最开始我嫌麻烦，后来发现它省下的解释成本是十倍不止。

二、贴真实的报错，别转述

我见过最多的浪费是这种对话：「这个函数报错了，帮我看看」，配一张截了一半的截图。转述会丢掉九成信息，模型拿到的信息比你少，它就只能靠猜。

现在我的固定动作是：完整复制 stack trace、贴出复现命令、附上相关代码段。当模型「看到」的东西和你看到的一样多时，它的表现才会像传说中那么好。

三、任务切小，一次只做一件事

「帮我重构整个模块」这种任务，人做不好，模型也做不好。我会把大任务拆成台阶：先让它梳理现状，再定方案，然后一个函数一个函数地迁移，每步都跑测试。中间任何一步不对，回退的成本都很小。

一个对照

同样是「修一个导出报错」，两种给法：

# 之前
这个函数报错了，帮我修一下

# 之后
项目：Python 3.11 + FastAPI，测试跑 pytest。
报错：pytest tests/test_export.py 全红，完整输出如下：
（贴完整 stack trace）
相关代码：app/services/export.py 第 40–68 行：
（贴代码）
预期行为：导出 CSV 时金额列保留两位小数。
要求：只修复这个问题，不要改其他文件。

下面这个版本没有一句「提示词技巧」，全是事实。

上下文工程比提示词技巧重要一个数量级。提示词是话术，上下文是事实。

AI 编码的效率上限由模型决定，下限由你喂的上下文决定。而日常体验的主宰，往往是下限。

· 完 ·