这篇是《生成式人工智能与超级增强的编码》的第二篇。先说个前提默认你已经看过第一篇至少动手试过把生成式AI装进编辑器、写几个提示词让模型补全或生成代码。那是最初级的“能用”。这次聊的是“强很强”同样一坨生成式AI为什么有的人能靠它半天改完一个模块有的人还陷在复制回答、粘贴报错、来回打转的循环里。我的结论很直接超级增强的编码不是模型参数太小不够聪明而是你的上下文准备不够反馈回路断了工程规则没跟上。这篇把方法和坑都摊开讲。1. 从“能用”到“增强”差在哪一步1.1 不是“生成代码”而是“接着你的思路写”接触生成式AI改造代码这件事我前后经历了三个阶段。第一个阶段是搜答案丢一段报错问它怎么回事当搜索引擎用。第二个阶段是生成函数把需求说清楚拿到代码能跑就行。第三个阶段才勉强摸到“增强”的边缘把整个代码库的上下文、业务规则、调用关系一起塞进去让AI生成的东西能直接在团队里继续演进而不是每次生成完都要人肉重写一遍。这三个阶段的分水岭不在模型层而在使用者的工作方式上。大多数人的误会有两处。一是把所有希望寄托在“提示词技巧”上觉得只要自然语言描述得够具体AI就会给出正确代码。二是反过来了觉得要让AI生成好代码就必须把自己练成提示词工程师把每个指令写得像法院判决书一样滴水不漏。这两种思路都偏了。我现在的理解是生成式AI在代码场景里的核心价值是“接上文”而不是“创造标准答案”。如果你让它接的上文足够完整包括目录结构、既有接口、依赖约束、报错信息、以及你刚才改到一半的思路那么它给出的代码大概率是贴着你的写法延展的。反之哪怕模型本身再强上来就是一句“帮我写个订单模块”得到的也只是公共代码库层面的模板跟你的业务、命名、异常策略毫无关系。所以“增强编码”在我这儿有个更朴素的定义想办法让AI成为团队里那个看过全部代码、记得所有约束、还能随时被追问的实习生。这个实习生能力上下限很大程度取决于你喂给它什么。1.2 三个支撑要素索引、规则、反馈构成超级增强编码的要素我拆成三项代码索引、工程规则、反馈回路。先说代码索引。它不是把整个仓库文件全部塞给模型——现在的上下文窗口再大也经不起几千个文件的消耗。索引指的是把仓库的骨架结构、模块职责、关键入口、常见依赖整理成一屏能看懂的抽象地图。理想情况下模型看到地图之后大概知道“这个模块由哪些文件组成谁负责入口谁负责配置哪些接口是被外部调用的”。哪怕细节不放进去也能在生成时避免迷路。第二项是工程规则。这部分最容易被人忽略。团队协作里有大量的隐性契约新代码不允许直接操作某类私有状态、错误必须走统一的异常包装、对外返回的字段命名要遵守兼容约定、禁止把对外稳定接口复制到别处改一版再抽走……这些规则在人类开发者之间通常靠代码评审和文档传递但AI不会默认知道。你不在规则里写清楚它就会按互联网上的公开范式生成一份“教科书代码”可用但不合口味。第三项是反馈回路。这里说的反馈不是“不对重来”而是把编译器的报错、测试框架的回执、代码评审的意见系统性地接回来再送回给模型。我见过不少团队把索引和规则做得挺正规规则文档贴了好几页结果生成完代码不跑一轮完整验证就提交CI爆掉以后骂模型不行。项目一旦跑到这个阶段已经不是模型的问题是闭环断了。1.3 靠模型还是靠编排你得早做决定还有一件容易踩的事过分在意某一个模型的能力标杆比参数、比上下文长度、比单次生成质量。实际上在真实工程里真正决定效率的往往是编排能力。你是不是能把任务拆成三步交给模型逐步完成你是不是能判断哪部分让AI做、哪部分自己动手你是不是能把一次失败转化成下一轮有效输入这些动作合在一起才叫“超级增强”。模型从青年变成正式员工不是变了个算法而是你把岗位说明书、入职培训、工作流对齐这三件事做到位了。2. 上下文工程把代码库“刻”进模型视野2.1 先建一份项目地图别让AI在仓库里瞎转我第一次认真做上下文工程是在某个内部运维工具的改造上。那个仓库不算大大概四五十个文件但历史包袱很重有人从老框架里迁移了一半还剩一半没迁完配置文件有三种书写习惯模块间的依赖方向完全看心情。刚开始我懒得整理直接把相关文件贴进对话框让AI看。结果它经常把“旧接口”当成“新接口”给出的代码调用旧方法运行时报错后才反应过来自己写的是祖传API。后来我痛定思痛先花四十分钟做了一份项目地图。这个地图大概长这样项目某命令行统计工具 入口bin/run.py参数由 cli.py 解析 核心模块config_loader解析配置文件stats_engine聚合统计reporter输出结果 依赖限制只允许使用标准库禁止引入新的第三方依赖 外部接口bin/run.py 暴露的子命令存量脚本依赖其输出格式 已知遗留config_loader 里有两套解析逻辑old_parse 仅被旧脚本使用禁止继续扩展四十分钟并不亏。因为之后每一轮AI对话我都可以把这段地图作为固定开头贴进去。它相当于告诉模型你在哪个项目的哪块区域可以动哪里不能动哪里。项目地图的标准不是“全”而是“覆盖核心决策节点”。你至少要让它知道这么几件事入口在哪个文件关键依赖往哪个方向走哪些文件内部可以动但接口不能变哪些历史代码只能看不能用。做不到这一步后面的规则再细都有限。2.2 把规则写进文件而不是只写进提示词项目地图解决的是“哪里”工程规则解决的是“怎么改”。规则能不能落地最大的检验场景是换一个同事来执行同一件事看着同一份规则得出的行为是不是一致的。所以规则本身不能太抽象比如“注意代码质量”就是废话。我习惯把它拆成模糊但可执行的样子错误处理统一走 exceptions.py 里的 ConfigError禁止抛裸异常解析配置时环境变量优先级高于配置文件新增函数必须带类型注解返回值类型必须明确不修改现有测试的公共断言需要调整时先说明原因对外输出保持纯文本不做彩色转义。这些规则写好后不应该只存在于某个人对话窗口的提示里。我会把它放到项目根目录一个叫 ai_dev_rules.md 的文件下平时做AI辅助开发时固定贴到输入框的最前面。如果团队里多个人一起用AI编码这份文件就是大家的公共规范源。好处是减少重复劳动也让AI生成的代码风格逐渐收敛到同一套约定上。2.3 任务文案四要素目标、约束、范围、验收很多人让AI生成代码时只给目标“帮我把XX功能实现了”。这相当于安排一个新人去干活只告诉他要做出什么东西却不告诉他边界在哪、什么风格才算合格、做到什么程度就可以交付。我现在的提示词习惯是固定承载四个要素目标、约束、范围、验收。它们不一定每次都完整出现但缺哪个就得意识到缺了哪个。目标也就是这个任务最终要解决的业务问题。要求我写得具体不是“提升性能”而是“缓存config解析结果让连续三次访问命中同一块配置时不再重新解析文件”。约束是边界条件不引入新依赖、不改插件协议、兼容旧调用方式等。范围是允许触碰的文件清单这个越明确AI越不容易发挥到别处。验收是交付前的评价标准跑哪些测试、满足哪些输出格式、看哪些指标。模板大概是这样目标把 config_loader 的解析结果加上缓存命中时直接返回对象。 约束 - 不引入新的第三方依赖 - 缓存失效策略文件变更时间更新则清空 - 不改 load_config 的返回类型。 范围config_loader.py以及配套的单元测试。 验收 - python -m pytest tests/test_config_loader.py 全部通过 - 手工修改配置后热加载能看到新值。把任务文案写成这样AI输出的偏差会显著减少。原因很简单它不再需要替你做设计决策。你替它把模糊地带填完了它的任务只剩翻译。3. 一次完整实操改造一个命令行工具3.1 从解析配置的老代码里抓出一串问题为了把上面这套方法落到有真实感的场景我拿某命令行统计工具做例子。这个工具运行起来之后会读取一份格式比较松散的配置文件里面记录了一串服务器主机的名字和状态标记最终输出一份统计结果告诉你有几台在线、几台维护。早期实现用的是正则抽取加上一个不小的 switch 分布处理不同类型字段。这个工具跑了一年以后问题很典型配置格式又加了两种新字段正则解析开始顾此失彼维护状态出现“在线但标记为维护”的异常组合后面的人为了修bug又堆了两层临时修补。代码乱归乱但它是线上工具不能直接推倒重来。我的目标是把解析部分升级成基于严格结构的分段解析同时保证原有输出格式完全不变。任务范围我限定在两个文件config_loader.py 和 tests/test_config_loader.py。外部所有调用 config_loader 的代码都不动。这样的话AI就算被放开手脚也只会在可控区域里改。3.2 给AI的第一轮提示词第一轮提示词我写成这样项目地图 入口 bin/run.pyconfig_loader 负责解析配置 reporter 消费 Loader 的输出对外输出格式不能改。 依赖限制仅标准库。 当前问题config_loader 里用正则解析新增字段多次出现误判。 目标重写 config_loader 的核心解析逻辑改为按结构分段解析并保留原有的返回字段名和类型。 约束 - 不修改其他文件 - 返回的 dict 结构必须保持 keys 完全一致 - 保留旧版命令的默认行为 - 异常统一抛出 ConfigError。 范围config_loader.py 与其单测。 验收 - pytest tests/test_config_loader.py 全部通过 - 手工传一份含两种新字段的样例配置输出与预期一致。这轮AI生成的第一版从编译角度看没问题结构和注释也整齐。我紧接着没看细节直接跑单测有两个用例挂了。一个挂在“配置文件包含非法组合”的场景它抛了标准 ValueError忘了统一异常包装另一个挂在空文件处理上它返回了一个空字典但旧代码在这时会返回一个带默认值的 dict外部有脚本依赖这个默认值。这个结果完全在预期里。反馈回路不是用来追求第一版100分而是用来把差距快速补上所以我立刻把两个失败用例的报错和断言原样粘贴回去加了一句注意异常必须转换为 ConfigError空配置需要返回带默认字段的字典以兼容外部脚本。只修复这两个用例不要扩大改动范围。第二轮它只改了这两处单测通过。3.3 生成之后的“人肉评审”还是不能省单测通过以后我没有立刻结束而是做了一次贴近代码评审的复查。复查的目的不是看AI有没有实现功能而是看它生成的代码是不是“过熟”是不是实现了未来某一天才需要的功能是不是偷偷引入了一个本来不存在的轮子。这回复查发现的问题很有意思它在某段解析里没调用现有 helper而是自己写了一段内联逻辑效果一模一样。单独看这段代码不算错但项目里已经有一个被单测覆盖过的同逻辑函数。放着现成代码不用会造成两处维护点这是团队很忌讳的。于是我追加了一条规则新写逻辑时必须复用现有模块中工具函数除非实测确认不能复用。你看这个教训不是模型特有的而是工程里一直存在的。把这类问题和对应规则反复回流到提示词里AI才慢慢长出“团队口味”。这也是为什么我一直强调超级增强的编码本质上是“持续把团队共识转译成模型的上下文”而不是某个天才提示词的一次性胜利。4. 常见问题排查AI辅助编码的五个深坑4.1 生成的代码里总有“幽灵依赖”“幽灵依赖”是我起的名字AI生成的代码默认使用了第三方库或者某个模块里根本不存在的方法但它不会在依赖清单里声明。比如让AI解析配置文件它毫不犹豫导入一个解析库项目里压根没装又比如项目一直手动维护版本号AI却在代码里调用了一个不存在的外壳类。排查思路分两步。第一生成后先跑一遍构建或者静态检查不要看人眼。让报错替你先碰一遍。第二在规则里写明“依赖以项目现有 requirements 清单为准不得新增任何未经确认的第三方包”。一旦把钱“封死”这类问题会大幅下降。这个场景很像带实习生默认路径他会用“网上最流行的做法”而不是“当下仓库最适配的做法”。规则正是用来把行业默认变成项目偏好。4.2 上下文太长模型把前面要求忘了我踩过最频繁的坑是长对话里让AI帮改多个函数。开始一两轮没问题等对话到第八九轮模型把最早的约束忘了给出的代码开始跑偏。这里要区分两种场景写在固定规则文件里的不会丢写在某条历史消息里、之后没人再提的非常容易丢。模型对对话内容的注意力本身就是有衰减的越靠前的约束越容易被忽略。应对办法是超过一定轮次后不要继续累加气泡而是开启一个新对话把项目地图、规则、当前任务三件套重新组装一遍再继续。我一般以“一轮任务”为单位一个任务对应一个新对话任务内部最多跑五轮修复。超过五轮还没解决要么是任务切得太大要么是上下文里混入了太多杂物这时切新对话反而更快。4.3 两个长得很像的函数被改错系统里经常会有两个功能接近但逻辑相反的旧函数AI经常分不清。有名公案是一个函数用来做A格式到B格式的转换另一个用来做反向转换名字只差一个字母。AI默认认为它们内部结构对称结果在“反向”里照抄了“正向”的逻辑字段映射全反了。问题根因是上下文里的“区分度不够”。你只告诉它函数名却没给它足够多的标识信号。如果目标是修改某个关键映射函数我会单独给出它的完整签名、典型的出入参示例并且在提示词里标明“不要参考相似函数 build_reverse_config”把容易造成岔路的对象主动排除。4.4 测试是真的测试还是面子测试AI生成单元测试有一大坑它会为了覆盖而覆盖。明明应该断言某个异常被抛出它却只验证“没有抛错”明明应该检查返回值内容它却只检查返回类型。这样的测试跑起来全绿一上真实数据就漏。我的校验方法是抽查测试里有没有真正的行为断言。它必须是“给定输入X经过系统Y结果必须是Z”而不是“调用成功即可”。如果AI写测试时用了大量 mock 且断言里全是 expect_not_called我会直接要求它写至少三个基于真实输入输出的集成型单测不要全用模拟对象。验收标准放在任务文案里能大幅提高这一环的质量。4.5 风格像“教材”不像团队代码有时候AI生成的代码功能全对但一眼假变量名特别完整注释到处都是函数拆得比教学大纲还细。这种代码放进老仓库里反而显得很扎眼。要解决这个单纯说一句“代码风格保持一致”没什么用因为模型没有统一的参考对象。更好做法是在项目地图后面贴一份仓库现有模块的公共函数样例。不用太长够给“参照风格”就行。模型会模仿样例里的命名长度、注释节奏、代码密度的分布感。这个方法我一直用效果比抽象的风格描述稳得多。5. 个人经验里的五个小秘方5.1 优先求稳再求优雅AI生成代码时我很关注它有没有触碰“本可以不改动”的边界。能局部改的就不要重写能保持稳定接口的就不动签名能不加新依赖就不加。这个原则放在第一优先级比“让代码更优雅”更重要。优雅是后续重构的事AI首要任务是不引入新风险。5.2 用描述现状代替下达命令我早期写提示词总是带明显命令感“你必须使用XX模式”“你要严格遵循XX风格”。这类强调词看起来有效实际常常带来反效果。模型更擅长吸收对现状和目标的描述而不是吸收人格化指令。我把“必须”改成“当前仓库的既有约定是本次改动也应延续”反而输出更贴近预期。5.3 别把设计决策外包给AI这个边界我一直守得很牢。要改架构、定义模块边界、认定某个废弃接口是否真的不再需要——这些决策我会自己下判断。AI能辅助列举选项、提示风险、生成草案但把设计方向盘交出去短期可能省事长期一定出问题。它不具备对历史包袱和团队默契的感知能力。5.4 保留可复现的任务底座每次做一个有代表性的AI改造任务我会把项目地图、规则、提示词、上一轮失败的报错整理成一个 task_memory 文档。下次遇到类似任务不用重头搭脚手架直接改改范围描述就能复用。这听起来像文档工作很像不产出功能代码但长期使用下来是“超级增强”最稳定的一笔杠杆收益。5.5 团队共享开发清单如果是一个团队一起使用AI辅助编码我会建议把上面这些沉淀成一份公共清单而不是每个人自己记一套。包括哪些文件允许AI直接改动哪些目录必须人工评审提示词里至少要包含哪几个字段生成完必须先跑哪几条命令。有了公共清单新人也能快速接入而不是靠个人摸索积累三个月经验。我在实际操作中最明显的一个变化是现在很少再跟AI“商量”怎么写代码了。更多时候是我负责把项目地图和工程规则提前摆好它负责在约定的范围内把执行细节快速落地之后我再从评审视角挑问题。整套流程跑顺以后代码质量的下限明显抬高生成结果很少出现那种一眼就不能用的东西。如果你也正在从“让AI写个函数”往“让AI扛起一个完整模块”的方向走这套上下文工程和工作流可能正好是你需要的。