核心论点AI 编码质量的瓶颈不在模型能力而在模型对项目的认知。解决思路不是换更强的模型而是搭建一个让模型越来越了解你项目的认知漏斗。一个经典场景你用 Claude Code 加一个新功能——在客服系统里给订单查询加个缓存。AI 噼里啪啦写了一堆代码跑起来没问题但你一看classOrderCache:def__init__(self):self._cache{}# 内存 dict重启即失defget(self,key):returnself._cache.get(key)defset(self,key,value,ttl3600):self._cache[key]value你沉默了。项目里已经有redis_cache_service.py带连接池、三级降级、TTL 自动过期。AI 写出一个内存 dict 缓存不是它不会写更好的——是它不知道你有一个更好的。这不是一个孤例。翻翻你最近 AI 写的代码大概率能找到这类问题的变体自己写了个 HTTP 重试逻辑没用到项目里的tenacity封装手写了一套 JSON Schema没用到 Pydantic 的model_json_schema()在 router 里写了 30 行业务逻辑没调用已有的 service 层共性AI 不知道你有什么于是按一般做法重写了一遍。问题的本质把 AI 编码看成一个输入→输出系统输入你的需求 少量上下文当前文件 ↓ AI 模型 ↓ 输出能跑的代码但可能不兼容项目已有基础设施输入端缺了什么项目认知。AI 默认只看到你当前打开的文件和对话里的要求。它不知道AI 不知道的后果项目里有哪些可复用的 Service/Util自己写一套团队约定的编码规范日志、异常处理、命名风格不一致哪些做法是被禁止的硬编码、裸调 API踩已知的坑之前做过类似功能的实现重复造轮子模型本身再强也解决不了这个问题——GPT-5 来了也不知道你的Settings类在哪个文件里。解法三层认知漏斗核心思路不是让模型变强而是扩大输入端的项目认知。分三层递进┌─────────────────────────┐ │ 流程层正确的协作模式 │ ← Agent 流水线、Plan 模式 │ 什么时候让 AI 做什么 │ ├─────────────────────────┤ │ 交互层精准输入 │ ← 引用文件、搜索后生成 │ 每次对话喂什么 │ ├─────────────────────────┤ │ 上下文层持久化规则 │ ← Rules、组件清单、禁止清单 │ AI 自动知道什么 │ └─────────────────────────┘第一层上下文层Rules—— AI 自动知道的Rules 是 CodeBuddy 的规则系统。你在.codebuddy/rules/下写的规则AI 在编辑匹配的文件时自动加载。不需要每次对话提醒。做什么编码规范“日志统一用 structlog禁止 print()”组件清单“缓存用redis_cache_service限流用rate_limiter”禁止清单“禁止在 router 里写内联业务逻辑必须在 core/ 下写 service”效果AI 每次写代码前就已经知道你的基础设施有哪些、规范是什么。这是最省力的一层——写一次永久生效。第二层交互层 引用 搜索—— 每次对话精准喂入Rules 解决AI 永远需要知道的事但有些信息是任务相关的——比如这次要改的参数抽取逻辑依赖tool_registry.py的哪些接口。做什么 引用对话里拖入相关文件AI 会理解上下游调用链搜索后生成动手写代码前先搜索项目中是否已有类似实现效果AI 不只是知道项目有什么而是知道这个任务和项目的哪些部分相关。比 Rules 更精准但需要每次对话手动操作。第三层流程层模式 Agent—— 正确的协作节奏输入对了但流程不对还是会返工。比如你用 Craft 模式让 AI 一口气改 5 个文件——它改到第 3 个就开始漂移。做什么Ask → Plan → Craft 模式选择讨论用 Ask设计用 Plan实现用 CraftAgent 流水线architecture-designer 出设计 → coder 实现 → test-generator 补测试 → code-reviewer 审查效果每步可验证不会出现改了一大片才发现方向错了的情况。三层之间的协作关系三层不是孤立的它们互相增强没有 Rules ──→ 每次对话都要手动 所有依赖文件容易遗漏 没有 引用 ──→ Rules 只告诉 AI 有什么但不知道这次用哪个 没有搜索后生成 ──→ Rules 有延迟刚加的组件还没入库AI 仍可能重造 没有 Plan 模式 ──→ 即使用对了文件也可能在错误的方向上越走越远真实的最佳实践是三层都用场景哪层起作用AI 想写class OrderCache第一层禁止清单 → “已有 redis_cache_service”改工具调用逻辑但不知道入口在哪第二层 tool_registry.py → “dispatch() 是入口”参数抽取要从正则升级到 LLM第三层Plan 模式先出方案 → “要改 3 个文件顺序是…”刚加了一个新 serviceAI 不知道第二层搜索后生成 → “找到了刚加的 service”一个完整的例子回到开头的缓存场景。三层漏斗下AI 的行为完全不同第一层Rules 已注入 禁止清单说禁止新建 cache 类用 redis_cache_service → AI 不会写 class OrderCache 第二层 引用当前 router src/modules/chat/core/redis_cache_service.py → AI 看到了 set() / get() / delete() 的接口签名 第三层Plan 模式 计划 1. 在 router 里注入 cache_service 2. 订单查询前加缓存读取 3. 查询后写缓存 → 你确认方案后 AI 再动手 结果改 3 行代码5 分钟搞定零返工。对比之前AI 写了 30 行内存 dict 代码你手动改了 15 行Review 发现还有边缘情况没处理又改了两轮。从 30 行返工到 3 行一次通过差距不在模型——在认知输入。核心要点AI 写出不兼容代码根因不是模型不够强是它不够了解你的项目。三层漏斗是最小可落地的解法——从 Rules自动知道到 引用精准喂入到 Plan 模式正确流程每一步都在扩大 AI 的项目认知。三层要配合使用——只有 Rules 没有搜索组件更新了 AI 不知道只有 Plan 没有 RulesAI 仍然可能自己写class Cache。投入产出比最高的起点先写一个禁止清单 Rules10 分钟立刻生效。你项目中下周不会再出现裸调 openai、手写 cache 类的代码。