最近这两周context-mode这个词在技术社区里出现的频率明显高了起来。群里有人问它是不是某个编辑器新加的开关有人说它是一套提示词模板还有人干脆觉得这是又一轮概念炒作。我自己的态度比较明确context-mode 背后那套东西值得每个重度使用 AI 编程助手的人认真学一遍。它本质上不是某个功能按钮而是一种把喂给 AI 的上下文从随缘变成工程化管理的模式。不管你在用的是聊天式助手、终端里的命令行工具还是 IDE 插件只要你希望 AI 从一个爱随口给方案的聊天对象变成一个真正懂你项目的协作同事context-mode 这套思路就绕不开。这篇文章我会从原理讲起再把模板、实测数据和翻车经验一次性说清楚适合所有想提高 AI 编码产出质量的人。顺便说一句我最早是在同事的终端里看到某个 CLI 工具的参数列表里有--context-mode这个开关后来发现各家工具都在往这个方向收敛所以这篇讲的是方法论不绑定任何特定产品。1. context-mode的本质从聊天切换到协作的思维转变1.1 先分清三件常被混为一谈的事很多人觉得 context 不就是把资料贴给 AI 吗实际操作起来发现时灵时不灵根本原因是把概念搅在一起了。在 context-mode 的语境下至少要分清三样东西上下文Context当前这一次请求里AI 能看到的全部信息。它是短期、瞬时的请求结束就清零。记忆Memory跨会话保留的长期信息比如账号资料、偏好设定、项目知识库。它是持久层。模式ModeAI 当前的行为范式比如用某位资深开发者的口吻回答只输出代码不解释严格按公司规范提交。模式决定了同样的输入会被加工成什么样的输出。context-mode 的作用是把三者串起来你先主动选定一种模式再把正确的上下文灌进去中途不断沉淀关键事实三者配合才能稳定产出。我见过太多人只在提示词层面纠结今天加一句请详细解释明天删一句请直接给代码方向却从没对准过。模式没定上下文再多也是浪费。换句话说如果你不知道想让 AI 以什么身份、按什么规矩、为了什么目标干活那贴再多资料也只是在碰运气。1.2 为什么上下文窗口变大之后问题反而更严重了模型能塞进的 token 越来越多按说上下文焦虑应该缓解才对实际恰恰相反。我自己的体会是上下文窗口变大以后喂给 AI 的东西里九成都是噪音的概率也变大了。把整个仓库的 readme、几十个文件一股脑塞进去AI 确实看得到所有内容但它不是全文精读而是按注意力权重挑重点。业界把这种现象叫lost in the middle——长上下文里信息放在开头和结尾最容易形成记忆塞在中间的内容特别容易被忽略。你用 20 万 token 的窗口一次装满结果最关键的约束条件刚好落在中段那还不如只给它 5000 token 的短而精的上下文。我自己踩过这个坑把一个 3 万行的后端项目整个扔进对话问框架是什么它能答对问新增接口该遵守哪个异常处理规范它就开始一本正经地编。原因很简单那段规范埋在某个中段的文件里注意力权重早被无关代码稀释了。这就是 context-mode 存在的理由不是给更多而是给得对、给得少、按顺序给。2. Token预算有限注意力下的取舍艺术2.1 喂饱和喂对是两回事假设你有一个 20 万 token 的窗口这不代表你该用满。AI 的注意力是稀疏的每个 token 都在争夺有限的权重塞进去的废料越多关键信息的相对权重就越低。打个生活化的比方让你在一屋子人里找一位穿红衣服的朋友屋子里只有 10 个人时你一眼就能看到挤进 1000 个穿着花里胡哨的人你得翻半天还容易认错人。这个机制决定了 context-mode 的核心动作是做减法。我后来做过一次对照实验同一个问题第一次把模块里所有文件按字母序全部贴给 AI第二次只贴模块的入口文件加一段 200 字的职责说明。第二次的回答质量和准确度明显更高而且消耗的 token 只有第一次的五分之一。从那之后我就形成了一个习惯贴文件之前先问自己三个问题——这个文件 AI 必须逐行看吗还是只需要知道它的存在它提供的信息会不会和任务目标无关答不上来就坚决不贴。2.2 什么样的信息值得进上下文我自己的优先级排序从高到低大概是任务目标和不接受的行为这直接决定输出方向没有目标就没有判断对错的依据本任务直接相关的代码文件或目录结构让 AI 在正确范围内改动项目的技术栈与既有约定避免它拿出一个和全项目不兼容的方案历史对话中已经沉淀下来的关键结论保证跨轮次一致泛泛的行业背景、百科知识这一类能省则省更直观一点我平时是这么分类的信息类型是否必须原因任务目标 验收标准必须没有目标AI 只能自行脑补成功标准目标文件 / 模块必须改动范围不收敛AI 会满仓库乱跑技术栈与目录约定建议防止它用不兼容的依赖或设计历史结论摘要建议保持对话一致性避免前后矛盾无关文件全文不要纯噪音挤占注意力还误导方向2.3 一份可执行的预算参考具体数字因模型而异但思路通用。我通常按单次请求总 token 的 70% 以上留给任务相关信息来控制。假设模型支持 20 万 token我一般只用到 8000 到 15000其中项目说明书放在开头作为锚点1500 到 3000任务描述紧随其后500 到 1000相关代码文件3000 到 8000其他示例、历史结论、临时参考1000 以内剩余的空间我宁可空着留给模型生成时使用。顺便提一句很多人忽略了一个细节输出也会消耗上下文预算。如果你把窗口塞到 95% 满模型写到一半可能就开始丢前面的关键信息然后出现前面说好的结论后面又忘了的诡异表现。给生成留余量是 context-mode 里很容易被忽视的一环。3. 我的三件套Context Mode工作流项目级、任务级、会话级3.1 项目级一份常驻的入职手册我给每个长期维护的项目都建了一份context.md放在仓库根目录随代码一起更新。它的作用是让 AI 每次进入项目时都像新员工拿到了一份入职手册而不是靠你现场口述。我目前用的模板长这样# 项目说明书context.md ## 技术栈 - 语言Python 3.11 - Web 框架FastAPI - ORMSQLAlchemy 2.0 Alembic - 数据库PostgreSQL 15表名统一小写下划线 ## 目录结构 - app/main.py应用入口注册路由 - app/routers/只放路由层不写业务逻辑 - app/services/业务逻辑统一抛 AppError 供路由层捕获 - app/models/SQLAlchemy 模型禁止放工具函数 ## 编码约定 - 接口统一返回 {code: 0, data: ...} 结构 - 异常一律抛 AppError(code, message)不要直接抛 HTTPException - 格式化使用 ruff提交前跑 make lint ## 已知坑 - User 表的 deleted_at 是软删除标记查全量用户必须带 filter(deleted_at.is_(None)) - 导出功能不要用内置 streaming 路由会撑爆默认 worker 的内存这份文档的价值在于它把项目里的隐性知识显性化了。目录结构告诉你路由层不该写业务逻辑已知坑告诉你查用户要注意软删除这些都是代码本身不会主动告诉 AI、但 AI 一旦不知道就会反复踩雷的信息。我实测下来维护这样一份文档的边际成本很低收益却极高——每次开新会话只需要丢给它一个文件链接或一段粘贴就能省下开头十几分钟的互相试探。3.2 任务级用4W1H加约束写需求有了项目手册每次具体任务还得有一份任务说明书。我在群里见到太多人直接甩一句帮我加个导出功能然后就抱怨 AI 写得不行。AI 不是不想写好是你根本没告诉它什么叫好。我用的是下面这个结构目标Goal我要给管理后台新增一个导出用户名单的 CSV 接口返回按创建时间倒序的用户列表 背景Why运营每周需要导出名单做线下分析目前只能手动查数据库 范围What只改 app/services/user_export.py 和 app/routers/admin.py不触碰认证逻辑 步骤How先写 service 层组装数据再在 admin router 注册 /admin/users/export 路由 约束Constraints遵循项目现有的异常处理规范CSV 用 utf-8-sig 编码文件超过 1 万行时拒绝导出并提示 验收Test调用接口返回 200打开 CSV 能正常显示中文表头空数据时返回空表头文件每个字段都不是摆设。目标字段决定了 AI 不会跑偏去做下载全部用户范围字段防止它顺手改掉认证逻辑约束字段避免它写出在 Windows 上打开乱码的 CSV验收字段让你不需要靠肉眼一点一点猜它做没做对。这个模板我用了大半年最大的感受是写得越具体AI 的第一次输出质量越高。很多人以为详细等于字多其实不是详细指的是关键约束没有遗漏。哪怕你的任务描述只有三句话只要把范围、约束、验收说清楚效果也远好过一千字的漫谈。3.3 会话级对话中途如何更新事实项目手册和任务说明书解决的是开局问题但对话进行到一半情况经常变化你发现设计不对删掉了某个模块或者测试暴露了一个此前不知道的前提条件。这时候如果只是普通地补一句哦对了现在不用那个文件了AI 大概率不会把它当成一个重要更新后面还会继续引用旧信息。我现在的做法是给更新操作加一个固定标记比如记忆更新关于导出模块之前提到的 xlsx 方案整个作废。 从现在起导出统一走 CSV并遵循 app/services/user_export.py 中现有的编码逻辑。 请在后续所有回答中以此为准不要再提及 xlsx。关键点是作废这两个字。AI 在面对前后矛盾的信息时通常会默认用最新信息覆盖旧信息但如果你不点明旧信息作废它可能会试图融合两套矛盾逻辑结果就是产出一个四不像。把话说死明确告诉它旧结论不再成立是会话级 context 维护里最实用的一招。另外我还会在长对话里隔几轮做一次小结确认格式很简单到目前为止我们确认了 1. 新增 CSV 导出接口 2. 不走认证逻辑 3. 大于 1 万行拒绝导出 请确认我理解没偏差然后继续。这样做有两个好处一是让 AI 把分散在对话里的结论重新凝聚一遍二是万一之前的某个结论理解错了你能在最早期发现而不是等到代码写完才知道。4. 实测同一个需求开不开Context Mode的差距4.1 复现条件口说无凭我把自己上周做的一个真实任务原样复述一遍。场景是一个已有 15 个模块的 FastAPI 项目要新增一个导出用户名单为 CSV的接口。我分别在两组条件下让 AI 实现同样的需求A 组直接贴一句帮我加一个导出用户名单为 CSV 的接口然后把包含该模块的两个相关文件一起甩过去。B 组用我前面说的三件套——先给context.md项目说明书再给填好的4W1H加约束任务模板最后附上同一个相关文件。两组都要求 AI 在给出代码前先用文字描述实现思路然后给出完整代码。对比维度包括第一版可用性、是否符合项目规范、返工次数、总 token 消耗和总耗时。4.2 结果对照指标A 组直接贴任务B 组Context Mode第一版可直接用否接口路径风格写成了/api/v1/export而项目实际用/admin/...是路径、命名与现有风格一致是否遵循项目异常处理规范否自己抛了 HTTPException是正确使用 AppError是否处理软删除否把已删除用户也导出了是自动加了 deleted_at 过滤返工次数3 次0 次总耗时约 40 分钟约 15 分钟总 token 消耗约 3.2 万约 1.1 万最反直觉的是最后一行B 组给了那么多前置资料总 token 居然比 A 组还少。原因很简单A 组的第一版代码方向就错了后面三次返工每次都要重新粘贴文件、重新解释错误这些来回纠错的对话极其消耗 token。而 B 组把纠错成本前移到了任务开始前的几分钟里后续一次通过整体反而更省。4.3 为什么结构化上下文能显著提升准确率从机制上讲AI 写代码最大的成本在于第一个错误版本会污染后续所有输出。一旦它把接口路径写成了/api/v1/export后续对话里它默认这个路径是对的你越纠正它越混乱。结构化上下文的本质是在动手之前把错误前提出现的概率压到最低。另一个容易被忽略的点是上下文里的信息位置会影响模型注意力。项目手册放在开头等于先给模型划定世界观任务模板紧接其后等于在世界观里指定当前目标相关文件最后给等于让它在既定框架里找细节。这个顺序不是随意排的而是尽量让关键约束落在模型最早读到、最容易记住的位置。5. 最容易翻车的四个场景与止损手段5.1 上下文污染无关信息挤占注意力最常见的翻车场景是把相关和无关的东西一股脑塞进去。表现是 AI 开始引用错误文件、混淆模块职责甚至把 A 模块的写法搬到 B 模块。我见过有人为了方便把整个项目目录树都在上下文里展开结果 AI 只是记住了几个路径真正的业务逻辑反而看不清。止损手段很直接一次只给相关文件并且在对话开头就声明你只需要关注这些文件其他的一律忽略。如果 AI 开始跑偏用忽略你刚才提到的 tools.py它和当前任务无关明确划界。5.2 过期上下文代码改完了AI 还在按旧结构建议第二个坑是上下文没有跟着代码演进。你可能上周重构了某个模块但context.md里还写着旧的文件结构于是 AI 给出的建议全都基于旧版本。这个坑最隐蔽因为 AI 不会主动提醒你你给我的资料和实际代码对不上。止损手段是约定一条铁律任何文件结构或关键逻辑变更后5 分钟内更新项目说明书。我在写context.md时给已知坑部分留了位置所有结构变化都同步记录这比临时想起来再改靠谱得多。5.3 一次性灌入大文档导致上下文耗尽第三个坑是把几百页的接口文档、整本团队规范一次性贴进去。表面上看很完整实际上模型读到后面已经忘了前面你的任务描述反而被挤到注意力边缘。止损手段是拆段。需要大文档时先让 AI 读目录或摘要再由你提问逐步深入。比如这份文档的第四章讲了认证流程请只总结认证相关的校验规则把一次性的海量输入变成可控的分步加载。5.4 多文件协调场景下的局部偏见最后一个坑是只给 AI 看单个文件它给出的方案和其他模块冲突。比如你让它改数据访问层却没告诉它缓存层有对应的失效逻辑结果它设计了一个绕过缓存的方案线上性能直接出问题。止损手段是多文件场景不给全文给接口契约。列出当前任务需要遵守的上下游方法签名、返回结构、约束条件等于把协调规则抽象成文档而不是把每个文件都甩给 AI 让它自己读。这比贴 50 个文件效率高得多也准确得多。6. 我现在每天在用的固定套路可直接抄作业6.1 一小时内建好项目说明书很多朋友说这套方法论好是好但担心前期建文档太花时间。我的经验是一个中型项目建好context.md只需要不到一个小时先用tree命令生成目录树然后对照目录写职责说明再回忆最近踩过的三个坑写进已知坑部分基本就够了。别追求一次写完美先有骨架后面边用边补。如果你实在懒得维护也可以做一个简化版只写三段——技术栈一段、目录职责一段、已知坑一段。这三段覆盖了 AI 最快出错的三个方向。我实测下来即使简化版也能避免 80% 以上的AI 写出风格完全不一致代码的问题。6.2 三条铁律大半年用下来我把自己的经验浓缩成三条铁律上下文宁少勿多。每次请求前问一句这里头有没有一句是多余的有就删掉。文件一改说明书就改。宁可花五分钟同步也不要让 AI 在过时信息上跑二十分钟。输出不对劲先怀疑上下文再怀疑模型。大部分翻车不是 AI 笨是你给的输入有问题。这三条里最难做到的是第一条因为人总是下意识觉得给得越多 AI 越懂我真相恰恰相反。我后来养成了一个习惯贴完资料会数一下大概有多少行超过 500 行就开始怀疑里面是不是混进了无关内容。最后分享一个小细节。我现在每次开新会话的第一句话都是固定的以下是我的项目说明书和本次任务模板请你先不要写代码只总结你从这两份材料里理解到的项目背景和任务约束。这算是一个快速校准动作让 AI 在动手前先复述一遍它理解了什么。如果它的复述和你本意有偏差这时候改还来得及如果它复述得对后面基本不会再跑偏。这个小动作不花什么成本但对产出质量的提升非常明显你试过一次就会明白我在说什么。
最近这两周context-mode这个词在技术社区里出现的频率明显高了起来。群里有人问它是不是某个编辑器新加的开关有人说它是一套提示词模板还有人干脆觉得这是又一轮概念炒作。我自己的态度比较明确context-mode 背后那套东西值得每个重度使用 AI 编程助手的人认真学一遍。它本质上不是某个功能按钮而是一种把喂给 AI 的上下文从随缘变成工程化管理的模式。不管你在用的是聊天式助手、终端里的命令行工具还是 IDE 插件只要你希望 AI 从一个爱随口给方案的聊天对象变成一个真正懂你项目的协作同事context-mode 这套思路就绕不开。这篇文章我会从原理讲起再把模板、实测数据和翻车经验一次性说清楚适合所有想提高 AI 编码产出质量的人。顺便说一句我最早是在同事的终端里看到某个 CLI 工具的参数列表里有--context-mode这个开关后来发现各家工具都在往这个方向收敛所以这篇讲的是方法论不绑定任何特定产品。1. context-mode的本质从聊天切换到协作的思维转变1.1 先分清三件常被混为一谈的事很多人觉得 context 不就是把资料贴给 AI 吗实际操作起来发现时灵时不灵根本原因是把概念搅在一起了。在 context-mode 的语境下至少要分清三样东西上下文Context当前这一次请求里AI 能看到的全部信息。它是短期、瞬时的请求结束就清零。记忆Memory跨会话保留的长期信息比如账号资料、偏好设定、项目知识库。它是持久层。模式ModeAI 当前的行为范式比如用某位资深开发者的口吻回答只输出代码不解释严格按公司规范提交。模式决定了同样的输入会被加工成什么样的输出。context-mode 的作用是把三者串起来你先主动选定一种模式再把正确的上下文灌进去中途不断沉淀关键事实三者配合才能稳定产出。我见过太多人只在提示词层面纠结今天加一句请详细解释明天删一句请直接给代码方向却从没对准过。模式没定上下文再多也是浪费。换句话说如果你不知道想让 AI 以什么身份、按什么规矩、为了什么目标干活那贴再多资料也只是在碰运气。1.2 为什么上下文窗口变大之后问题反而更严重了模型能塞进的 token 越来越多按说上下文焦虑应该缓解才对实际恰恰相反。我自己的体会是上下文窗口变大以后喂给 AI 的东西里九成都是噪音的概率也变大了。把整个仓库的 readme、几十个文件一股脑塞进去AI 确实看得到所有内容但它不是全文精读而是按注意力权重挑重点。业界把这种现象叫lost in the middle——长上下文里信息放在开头和结尾最容易形成记忆塞在中间的内容特别容易被忽略。你用 20 万 token 的窗口一次装满结果最关键的约束条件刚好落在中段那还不如只给它 5000 token 的短而精的上下文。我自己踩过这个坑把一个 3 万行的后端项目整个扔进对话问框架是什么它能答对问新增接口该遵守哪个异常处理规范它就开始一本正经地编。原因很简单那段规范埋在某个中段的文件里注意力权重早被无关代码稀释了。这就是 context-mode 存在的理由不是给更多而是给得对、给得少、按顺序给。2. Token预算有限注意力下的取舍艺术2.1 喂饱和喂对是两回事假设你有一个 20 万 token 的窗口这不代表你该用满。AI 的注意力是稀疏的每个 token 都在争夺有限的权重塞进去的废料越多关键信息的相对权重就越低。打个生活化的比方让你在一屋子人里找一位穿红衣服的朋友屋子里只有 10 个人时你一眼就能看到挤进 1000 个穿着花里胡哨的人你得翻半天还容易认错人。这个机制决定了 context-mode 的核心动作是做减法。我后来做过一次对照实验同一个问题第一次把模块里所有文件按字母序全部贴给 AI第二次只贴模块的入口文件加一段 200 字的职责说明。第二次的回答质量和准确度明显更高而且消耗的 token 只有第一次的五分之一。从那之后我就形成了一个习惯贴文件之前先问自己三个问题——这个文件 AI 必须逐行看吗还是只需要知道它的存在它提供的信息会不会和任务目标无关答不上来就坚决不贴。2.2 什么样的信息值得进上下文我自己的优先级排序从高到低大概是任务目标和不接受的行为这直接决定输出方向没有目标就没有判断对错的依据本任务直接相关的代码文件或目录结构让 AI 在正确范围内改动项目的技术栈与既有约定避免它拿出一个和全项目不兼容的方案历史对话中已经沉淀下来的关键结论保证跨轮次一致泛泛的行业背景、百科知识这一类能省则省更直观一点我平时是这么分类的信息类型是否必须原因任务目标 验收标准必须没有目标AI 只能自行脑补成功标准目标文件 / 模块必须改动范围不收敛AI 会满仓库乱跑技术栈与目录约定建议防止它用不兼容的依赖或设计历史结论摘要建议保持对话一致性避免前后矛盾无关文件全文不要纯噪音挤占注意力还误导方向2.3 一份可执行的预算参考具体数字因模型而异但思路通用。我通常按单次请求总 token 的 70% 以上留给任务相关信息来控制。假设模型支持 20 万 token我一般只用到 8000 到 15000其中项目说明书放在开头作为锚点1500 到 3000任务描述紧随其后500 到 1000相关代码文件3000 到 8000其他示例、历史结论、临时参考1000 以内剩余的空间我宁可空着留给模型生成时使用。顺便提一句很多人忽略了一个细节输出也会消耗上下文预算。如果你把窗口塞到 95% 满模型写到一半可能就开始丢前面的关键信息然后出现前面说好的结论后面又忘了的诡异表现。给生成留余量是 context-mode 里很容易被忽视的一环。3. 我的三件套Context Mode工作流项目级、任务级、会话级3.1 项目级一份常驻的入职手册我给每个长期维护的项目都建了一份context.md放在仓库根目录随代码一起更新。它的作用是让 AI 每次进入项目时都像新员工拿到了一份入职手册而不是靠你现场口述。我目前用的模板长这样# 项目说明书context.md ## 技术栈 - 语言Python 3.11 - Web 框架FastAPI - ORMSQLAlchemy 2.0 Alembic - 数据库PostgreSQL 15表名统一小写下划线 ## 目录结构 - app/main.py应用入口注册路由 - app/routers/只放路由层不写业务逻辑 - app/services/业务逻辑统一抛 AppError 供路由层捕获 - app/models/SQLAlchemy 模型禁止放工具函数 ## 编码约定 - 接口统一返回 {code: 0, data: ...} 结构 - 异常一律抛 AppError(code, message)不要直接抛 HTTPException - 格式化使用 ruff提交前跑 make lint ## 已知坑 - User 表的 deleted_at 是软删除标记查全量用户必须带 filter(deleted_at.is_(None)) - 导出功能不要用内置 streaming 路由会撑爆默认 worker 的内存这份文档的价值在于它把项目里的隐性知识显性化了。目录结构告诉你路由层不该写业务逻辑已知坑告诉你查用户要注意软删除这些都是代码本身不会主动告诉 AI、但 AI 一旦不知道就会反复踩雷的信息。我实测下来维护这样一份文档的边际成本很低收益却极高——每次开新会话只需要丢给它一个文件链接或一段粘贴就能省下开头十几分钟的互相试探。3.2 任务级用4W1H加约束写需求有了项目手册每次具体任务还得有一份任务说明书。我在群里见到太多人直接甩一句帮我加个导出功能然后就抱怨 AI 写得不行。AI 不是不想写好是你根本没告诉它什么叫好。我用的是下面这个结构目标Goal我要给管理后台新增一个导出用户名单的 CSV 接口返回按创建时间倒序的用户列表 背景Why运营每周需要导出名单做线下分析目前只能手动查数据库 范围What只改 app/services/user_export.py 和 app/routers/admin.py不触碰认证逻辑 步骤How先写 service 层组装数据再在 admin router 注册 /admin/users/export 路由 约束Constraints遵循项目现有的异常处理规范CSV 用 utf-8-sig 编码文件超过 1 万行时拒绝导出并提示 验收Test调用接口返回 200打开 CSV 能正常显示中文表头空数据时返回空表头文件每个字段都不是摆设。目标字段决定了 AI 不会跑偏去做下载全部用户范围字段防止它顺手改掉认证逻辑约束字段避免它写出在 Windows 上打开乱码的 CSV验收字段让你不需要靠肉眼一点一点猜它做没做对。这个模板我用了大半年最大的感受是写得越具体AI 的第一次输出质量越高。很多人以为详细等于字多其实不是详细指的是关键约束没有遗漏。哪怕你的任务描述只有三句话只要把范围、约束、验收说清楚效果也远好过一千字的漫谈。3.3 会话级对话中途如何更新事实项目手册和任务说明书解决的是开局问题但对话进行到一半情况经常变化你发现设计不对删掉了某个模块或者测试暴露了一个此前不知道的前提条件。这时候如果只是普通地补一句哦对了现在不用那个文件了AI 大概率不会把它当成一个重要更新后面还会继续引用旧信息。我现在的做法是给更新操作加一个固定标记比如记忆更新关于导出模块之前提到的 xlsx 方案整个作废。 从现在起导出统一走 CSV并遵循 app/services/user_export.py 中现有的编码逻辑。 请在后续所有回答中以此为准不要再提及 xlsx。关键点是作废这两个字。AI 在面对前后矛盾的信息时通常会默认用最新信息覆盖旧信息但如果你不点明旧信息作废它可能会试图融合两套矛盾逻辑结果就是产出一个四不像。把话说死明确告诉它旧结论不再成立是会话级 context 维护里最实用的一招。另外我还会在长对话里隔几轮做一次小结确认格式很简单到目前为止我们确认了 1. 新增 CSV 导出接口 2. 不走认证逻辑 3. 大于 1 万行拒绝导出 请确认我理解没偏差然后继续。这样做有两个好处一是让 AI 把分散在对话里的结论重新凝聚一遍二是万一之前的某个结论理解错了你能在最早期发现而不是等到代码写完才知道。4. 实测同一个需求开不开Context Mode的差距4.1 复现条件口说无凭我把自己上周做的一个真实任务原样复述一遍。场景是一个已有 15 个模块的 FastAPI 项目要新增一个导出用户名单为 CSV的接口。我分别在两组条件下让 AI 实现同样的需求A 组直接贴一句帮我加一个导出用户名单为 CSV 的接口然后把包含该模块的两个相关文件一起甩过去。B 组用我前面说的三件套——先给context.md项目说明书再给填好的4W1H加约束任务模板最后附上同一个相关文件。两组都要求 AI 在给出代码前先用文字描述实现思路然后给出完整代码。对比维度包括第一版可用性、是否符合项目规范、返工次数、总 token 消耗和总耗时。4.2 结果对照指标A 组直接贴任务B 组Context Mode第一版可直接用否接口路径风格写成了/api/v1/export而项目实际用/admin/...是路径、命名与现有风格一致是否遵循项目异常处理规范否自己抛了 HTTPException是正确使用 AppError是否处理软删除否把已删除用户也导出了是自动加了 deleted_at 过滤返工次数3 次0 次总耗时约 40 分钟约 15 分钟总 token 消耗约 3.2 万约 1.1 万最反直觉的是最后一行B 组给了那么多前置资料总 token 居然比 A 组还少。原因很简单A 组的第一版代码方向就错了后面三次返工每次都要重新粘贴文件、重新解释错误这些来回纠错的对话极其消耗 token。而 B 组把纠错成本前移到了任务开始前的几分钟里后续一次通过整体反而更省。4.3 为什么结构化上下文能显著提升准确率从机制上讲AI 写代码最大的成本在于第一个错误版本会污染后续所有输出。一旦它把接口路径写成了/api/v1/export后续对话里它默认这个路径是对的你越纠正它越混乱。结构化上下文的本质是在动手之前把错误前提出现的概率压到最低。另一个容易被忽略的点是上下文里的信息位置会影响模型注意力。项目手册放在开头等于先给模型划定世界观任务模板紧接其后等于在世界观里指定当前目标相关文件最后给等于让它在既定框架里找细节。这个顺序不是随意排的而是尽量让关键约束落在模型最早读到、最容易记住的位置。5. 最容易翻车的四个场景与止损手段5.1 上下文污染无关信息挤占注意力最常见的翻车场景是把相关和无关的东西一股脑塞进去。表现是 AI 开始引用错误文件、混淆模块职责甚至把 A 模块的写法搬到 B 模块。我见过有人为了方便把整个项目目录树都在上下文里展开结果 AI 只是记住了几个路径真正的业务逻辑反而看不清。止损手段很直接一次只给相关文件并且在对话开头就声明你只需要关注这些文件其他的一律忽略。如果 AI 开始跑偏用忽略你刚才提到的 tools.py它和当前任务无关明确划界。5.2 过期上下文代码改完了AI 还在按旧结构建议第二个坑是上下文没有跟着代码演进。你可能上周重构了某个模块但context.md里还写着旧的文件结构于是 AI 给出的建议全都基于旧版本。这个坑最隐蔽因为 AI 不会主动提醒你你给我的资料和实际代码对不上。止损手段是约定一条铁律任何文件结构或关键逻辑变更后5 分钟内更新项目说明书。我在写context.md时给已知坑部分留了位置所有结构变化都同步记录这比临时想起来再改靠谱得多。5.3 一次性灌入大文档导致上下文耗尽第三个坑是把几百页的接口文档、整本团队规范一次性贴进去。表面上看很完整实际上模型读到后面已经忘了前面你的任务描述反而被挤到注意力边缘。止损手段是拆段。需要大文档时先让 AI 读目录或摘要再由你提问逐步深入。比如这份文档的第四章讲了认证流程请只总结认证相关的校验规则把一次性的海量输入变成可控的分步加载。5.4 多文件协调场景下的局部偏见最后一个坑是只给 AI 看单个文件它给出的方案和其他模块冲突。比如你让它改数据访问层却没告诉它缓存层有对应的失效逻辑结果它设计了一个绕过缓存的方案线上性能直接出问题。止损手段是多文件场景不给全文给接口契约。列出当前任务需要遵守的上下游方法签名、返回结构、约束条件等于把协调规则抽象成文档而不是把每个文件都甩给 AI 让它自己读。这比贴 50 个文件效率高得多也准确得多。6. 我现在每天在用的固定套路可直接抄作业6.1 一小时内建好项目说明书很多朋友说这套方法论好是好但担心前期建文档太花时间。我的经验是一个中型项目建好context.md只需要不到一个小时先用tree命令生成目录树然后对照目录写职责说明再回忆最近踩过的三个坑写进已知坑部分基本就够了。别追求一次写完美先有骨架后面边用边补。如果你实在懒得维护也可以做一个简化版只写三段——技术栈一段、目录职责一段、已知坑一段。这三段覆盖了 AI 最快出错的三个方向。我实测下来即使简化版也能避免 80% 以上的AI 写出风格完全不一致代码的问题。6.2 三条铁律大半年用下来我把自己的经验浓缩成三条铁律上下文宁少勿多。每次请求前问一句这里头有没有一句是多余的有就删掉。文件一改说明书就改。宁可花五分钟同步也不要让 AI 在过时信息上跑二十分钟。输出不对劲先怀疑上下文再怀疑模型。大部分翻车不是 AI 笨是你给的输入有问题。这三条里最难做到的是第一条因为人总是下意识觉得给得越多 AI 越懂我真相恰恰相反。我后来养成了一个习惯贴完资料会数一下大概有多少行超过 500 行就开始怀疑里面是不是混进了无关内容。最后分享一个小细节。我现在每次开新会话的第一句话都是固定的以下是我的项目说明书和本次任务模板请你先不要写代码只总结你从这两份材料里理解到的项目背景和任务约束。这算是一个快速校准动作让 AI 在动手前先复述一遍它理解了什么。如果它的复述和你本意有偏差这时候改还来得及如果它复述得对后面基本不会再跑偏。这个小动作不花什么成本但对产出质量的提升非常明显你试过一次就会明白我在说什么。
