引言
"我们要提升团队的AI能力。"
这句话我在很多团队都听到过。说这话的人往往是团队管理者——他们看到的场景惊人地相似：有人用得风生水起，有人连Prompt都写不顺；同一个AI助手，换个任务就翻车；上周还好好的功能，这周换了个模型版本就崩了。于是他们开始推动各种方案：有人钻进提示工程，有人搭Agent框架，有人研究上下文工程，有人在设计Harness架构……技术层出不穷，团队疲于奔命。
但投入了大量精力之后，效果却像打地鼠——解决一个问题，冒出新问题。原因是大多数团队在做的，是用战术上的勤奋掩盖战略上的懒惰：他们忙着学新技术、调参数、堆工具，却从来没有停下来问一个最根本的问题——
所有这些技术，到底在解决什么问题？
如果连问题都定义不清楚，所谓的"提升"就只是一顿乱拳。我在大量使用AI编码助手的实践中发现，无论你用的是什么模型、什么工具，AI协作中出错的模式其实只有两种。搞清楚这两种模式，你就有了一个诊断框架，不管技术怎么变，都能自己找到正确的方向。
而这正是团队管理者最需要的东西：不是更懂技术，而是更懂判断。你不需要成为Prompt专家，只需要一个框架来问对问题、定对方向。
两类问题
你和AI协作时，所有让你不满意的结果，都可以归为以下两类之一：
第一类：缺失——该做的没做
你想要A，AI给了你A的一部分，或者干脆给了你B。
最常见的例子是编写测试。你让AI Agent"实现一个订单金额计算函数，运行测试验证通过后提交PR"，它写出了核心逻辑，代码看起来没问题，但测试文件空空如也。等你追问"测试呢？"，它才补上。于是你学聪明了，在 System Prompt 里写明了"所有新代码必须先写测试"，结果呢？它三次对话里有两次还是先写实现，测试像是事后补交的作业。你忍不住想：我都写进System Prompt了，还不够吗？
更复杂的情况出现在多文件变更中。你让AI"将模块A的数据库访问层替换为新的ORM"，它确实改了数据访问代码，却忘了同步更新模块B中直接引用旧ORM查询结果的逻辑——模块B编译报错，但AI在提交PR时根本没有运行项目构建。你布置了一个跨多个文件的重构任务，它只完成了其中一部分，并且没有告诉你哪些部分没做。
还有一种更隐蔽的缺失：它没做完，却告诉你做完了。你让它写一个跨服务的数据迁移脚本，它回复"已完成"，你审查代码发现核心逻辑有个严重的事务边界问题，脚本跑起来就造成数据不一致。它根本没验证过。缺失叠加了错误的状态报告——你不光要补上没做的事，还得先识破"已完成"这个假象。
这就引出了缺失的两种子类型：静默缺失和谎报缺失。前者是AI漏了东西但没吭声——跑一下构建就能发现。后者是AI漏了东西却说做完了——只有深度审查后才能发现真相。两者应对策略不同：静默缺失靠更结构化的指令和自动化检查来补；谎报缺失则需要你养成"默认不信任AI的自检报告"的习惯——它说"已完成"，你的第一反应是"那我验证一下"。
表面看是AI"能力不够"，但再想一步：是你没说清楚，还是你说了它没做到？
我的经验是，大多数情况是后者。提示里写得明明白白，但它就是不照做。直到你找到某种表达方式——比如更结构化的指令、更明确的约束、更细的步骤拆解、更详细的例子——它才有"较大概率"按你要求的执行。
这不是"提示不够好"，这是指令遵循的可靠性问题。
第二类：越界——不该做的做了
AI做了你从来没让它做的事。
另一种更让人头疼的情况，是你发现AI擅自扩大了行动范围。你跟它说"重构订单服务中的计算逻辑"，它分析到一半，自己决定"顺便把整个服务的依赖注入框架也换了吧"，然后真的去改了十多处基础配置——你只想动一个函数，它拆了半栋楼。这种越界是显性的：动作大、范围广，你一眼就能发现出了问题。
但越界不总是这么明目张胆。更多时候它是隐性的——你根本不知道它碰了不该碰的东西。你让AI修改一个配置文件的端口号，它改完之后，顺手把同一目录下另一个配置文件里的数据库连接串改成了localhost——你根本不知道它碰了那里。等你部署到预发布环境才发现数据库连不上了。
上面两种越界都发生在文件层面——AI动了不该动的文件或代码。还有一种越界发生在信息层面：它会对不存在的东西言之凿凿。你问"这个数据管道支持哪些字段"，它列了一大串，每条看起来都头头是道。你一查数据字典，里面有一半字段根本不存在，全是它"合理想象"出来的——你没让它编，它替你编了。
三种越界，从显性到隐性，从文件层面到信息层面。它们有一个共同特征：AI不会主动告诉你它越界了。你只能在后果里发现——要么是编译报错，要么是数据库连不上，要么是数据字典对不上。
但说实话，"越界"也不全是坏事。有时候AI"擅自"做的那些事，反而是帮你省了事。比如你写了一个函数调用，忘了导入对应的模块，AI发现之后顺手把import加上了——你都没说，它帮你补了。或者你写完一段逻辑，AI发现有个明显的边界条件没处理，自动帮你加上了检查——这种"多做的事"你巴不得它多做。
这时候问题就来了：同样是"主动多做"，凭什么有的让你恼火，有的让你感激？
答案藏在四个维度里。
第一，可预测性——一个有经验的团队成员在这里会怎么做？你让AI重构一个API端点，它发现接口缺少版本号，顺手帮你加了URL版本前缀。如果你的团队里随便哪个同事做这个重构都会顺手加上版本号，那AI做了就是"意料之中的主动"。但如果你的团队技术决策明确说了"版本控制通过请求头处理，不修改URL路径"，AI自作主张改了路由设计，那就是越界。
第二，可逆性——做错了容易回滚吗？AI在生成API响应时顺手加了一个冗余字段——前端不用的话删掉就行，git checkout 一秒还原。但AI"顺手"改了数据库迁移脚本的结构——回滚时需要专门的回滚迁移，已上线的生产数据可能受影响，十几个下游服务都要跟着验证一遍。可逆性越高，越可以接受AI的主动；可逆性越低，越需要严格限制。
第三，授权范围——AI有没有被授权做这类操作？修改业务代码通常是在授权范围内的，但修改CI/CD流水线配置、数据库迁移脚本、生产环境密钥管理，这些通常不在授权范围内。在 Multi-Agent 架构中，授权范围还需要细分到不同 Agent：Planner Agent 可以设计方案，但只有 Executor Agent 才能写代码。
第四，认知价值——AI的越界有没有给你带来新的思路？你让它"优化支付服务的查询性能"，它不光优化了数据库查询，还跑回来说"我发现你们的数据模型可以引入事件溯源来消除报表查询对主库的压力，要不要看看？"——虽然越界了，但这个建议你从没想过。这种越界的价值不在于"省了多少事"，而在于认知上的意外收获。 它的成本极低——看到了不想用就忽略，没有任何损失。这恰恰是AI相比人类同事的一个独特优势：你给同事分配任务，他跑题了你会觉得他在浪费时间；但AI跑题，你扫一眼不感兴趣就跳过，完全不产生摩擦成本。 在 Multi-Agent 系统中，这种认知价值更加突出——Planner Agent 在生成方案时"跑题"到一个你没想过的架构方向，可能比聚焦执行更有价值。
这就引出了一个微妙的平衡：你既要限制AI的越界来保证安全和可靠，又要有意识地保留一定的越界空间来获取那些"意料之外的认知价值"。
把四个维度放在一起，完整的判断框架就出来了：
核心原则——有害的越界要严格限制，有益的越界要善加利用。 你不需要容忍所有越界，但如果你发现AI在某个领域的越界经常给你带来新启发，那不妨在那个领域给它更大的自主空间。驯服AI的越界不是为了消灭它，而是为了可控地利用它。值得注意的是，有害越界和有益越界这两个分类并非静止——当你发现某种越界持续有价值时，把它显式纳入规则，它就从越界变成了缺失的一部分。
但具体怎么把握"严格"和"宽松"之间的尺度？答案在你当前的工作场景。同一个框架，在不同场景下的应用策略截然不同：
高精度执行场景（生产环境代码、财务交易、医疗诊断）→ 严格限制越界，安全第一，可预测性和可逆性是最高优先级
探索式场景（架构方案设计、技术选型调研、头脑风暴）→ 放宽越界容忍度，拥抱意外收获，认知价值是最高优先级
日常编码场景（写函数、修bug、小型重构）→ 权衡四个维度做日常判断，留出小窗口给"意外发现"
但真正棘手的是——缺失和越界往往穿着相似的外衣：AI多做了不该做的，同时少做了该做的，两件事搅在一起。搞清楚了这两种错误类型，下一步就是在实践中快速识别它们。
如何诊断：遇到问题先分类
下次AI给出的结果不如意，别急着改Prompt。先做一件事：判断这是缺失还是越界。诊断对了，后续才能找对方向——方向错了，再多的调整也是白费。
一个简单的诊断方法：
检查输出少了什么？ 如果你能明确说出"它没做X"，这大概率是缺失。比如没写测试、没按格式输出。
检查输出多了什么？ 如果它的行为或输出里包含了你从未要求的东西，这大概率是越界。比如修改了无关文件、自己加了一个步骤、输出了不存在的事实。
两者都有？ 很多复杂任务中，两者是并发的——它缺了你要求的，同时做了不该做的。这时候优先处理越界，因为越界行为可能正在搞破坏——那些它不该碰的文件可能已经被修改了。
两种优化方向：补充 vs 限制
诊断出是"缺失"还是"越界"之后，你就能确定优化方向了。
缺失 → 补充（Supplement）
"缺失"的核心问题是AI做得不够——你想要的，它没做完。
优化方向是补充：让AI补齐缺失的部分，更完整地覆盖你的要求。你需要告诉它更多它应该做的事，把"缺失"的那些填充进去。
这不是简单地"多写Prompt"，而是有策略地补全——补充知识、补充规则、补充验证。比如：你告诉它"每次修改代码时必须同步更新测试"，然后配上自动化测试和测试覆盖率检查——这就是成功补充的结果。
越界 → 限制（Restrict）
"越界"的核心问题是AI做得太多。它做了你明确没让它做、或者不应该做的事。
优化方向是限制：给AI圈定明确的边界，告诉它"到这里为止，不要再往前"。你希望它更克制、更精准地执行你的要求，不擅自扩大范围。
这里有一个值得注意的不对称：补充可以直接通过对话完成——你补充知识、明确规则，AI当场就能用上；限制往往需要更强的执行保障——对AI说"别越界"不一定管用，越界行为通常需要外部验证机制来兜底。
但这只是方向层面的判断。具体怎么执行，取决于谁来纠正AI的偏差——是你在每次对话中手动调整，还是建立一个自动机制来替你兜底？
谁来执行：两种反馈模式
上一节说了"往哪个方向走"，这一节回答"谁来做这件事"。
补充和限制是方向，但同一个方向有两种截然不同的执行方式。以"补充知识"为例：你可以在每次对话中口头告诉 AI"我们的测试框架是 pytest"——这是手动补充；也可以把这条写进 Agent Skills，让 AI 每次新对话自动加载——这是自动补充。限制也一样：你可以每次审查 AI 的输出时口头纠正越界行为——这是手动限制；也可以在 CI 里配一个文件白名单检查，越界的修改直接拦截——这是自动限制。
每个方向都有手动和自动两条路。这两种路本质上不同。《Cybernetics and the "human-on-the-loop" in agentic coding》 中提到的 Human in/on Loop 框架，正好能帮助我们把这两种方式描述清楚。
模式一：Human in Loop（人在回路中）——你就是反馈器
Human in Loop 是最直观的反馈模式：你看到AI的输出，判断它缺了什么或多了什么，然后直接动手调整——补充上下文、修改指令、纠正方向。AI根据你的反馈重新生成，你再检查、再调整，直到满意为止。
它的优势在于灵活和精准。你可以依据上下文做出最合适的判断：发现AI不理解项目惯例，立刻补充一段背景知识；发现AI的代码风格不对，当场给一个示例。这种即时调整的能力是任何自动化机制都难以替代的。
但它的代价也不小。首先是认知负荷——你得全程盯着AI的输出，不能走神。其次是不可扩展——同样的错误，这次你手把手纠正了，下次出现你还得再来一次。你在回路中承担的角色本质上是一个"人类反馈器"，每次处理的是同一个任务的变体，而不是在系统层面解决问题。
模式二：Human on Loop（人在回路上）——你建立自动反馈器
Human on Loop 走出了另一种路径：你不再亲自担任反馈器，而是在系统层面建立一个自动反馈循环——让工具、脚本甚至另一个AI来做反馈器。你的角色从"反馈器"升级成了"反馈器的反馈器"。
典型例子：你不再在对话中反复告诉AI"别忘了检查跨模块影响"，而是设计一个自动反馈循环——给 AI 配一个 Evaluator Agent，每次它提交代码变更后，Evaluator 自动分析变更文件的引用关系、运行构建检查、报告依赖冲突。这个循环由 Agent SDK 编排自动执行，不需要你每次参与。更重要的是，当某种遗漏模式反复出现时，这个反馈循环可以自己更新 Evaluator 的评分标准、自动将新规则写入 Agent Skills——它在进化，而你不需要动手。你要做的，是给这个进化设定方向：它该朝什么质量标准收敛、哪些知识和原则需要纳入考量。你的角色从"操作者"变成了"设计者"——设计一个能自我调优的系统。
它的优势在于可扩展、可持续和可进化。循环一旦建立，每次都会生效，不依赖你是否在场、是否记得。而且循环是可以进化的——你发现一个问题、加一条规则、问题不再复发，这个循环意味着团队的知识正在被系统化。
但它的代价同样存在。首先是建立成本——配置一个AI评审Agent需要搭建环境。其次是维护成本——反馈过于严格会误拦正常操作，过于宽松又形同虚设。你需要在"守得住"和"不碍事"之间找到平衡。
自动反馈器的两种形态：工具 vs AI
Human on Loop 的"自动反馈器"有两种实现方式，它们各有优劣。
基于工具的方式——像一个静态规则引擎。你在pre-commit hook里写"提交必须包含测试变更"，这个规则是确定的、可预测的。每次触发的行为都一样，不会今天拦明天不拦。缺点是灵活度不够——它只能做你明确写进规则的事。如果你写"只允许修改src/和tests/目录下的文件"，AI刚好需要改一下README.md来更新文档，工具就会误拦。你只能手动加一条例外规则，规则集越积越厚。
基于AI的方式——像一个动态评审员。你让一个AI Agent去评审执行AI的输出：你看一下这段代码的质量怎么样？有没有潜在的边界问题？修改范围是否符合要求？AI评审员能理解上下文，判断"这次改README.md是合理的文档更新"还是"它跑题了擅自改了文档"。灵活很多，但稳定性差一些——同一个评审标准，今天它觉得没问题，明天可能就判不过了。
两种方式不冲突，实际项目中往往是配合使用的：
工具守"硬边界"，AI做"软判断"。工具保证底线，AI筛选需要判断力的东西。而人在最上层把控：建规则、定标准、处理边界情况、持续迭代这个自动反馈器本身。
但这两种反馈器之间还有一个更本质的区别，在长期使用中会被急剧放大——
只有AI反馈器能自我进化
基于工具的反馈器是静态的。你的 pre-commit hook 今天怎么拦，明天还是怎么拦。它不会从拦截记录里学到任何东西。当团队发现一个新类型的越界模式——比如"AI 在改微服务 A 的 API 时顺手改了共享 Proto 文件却没通知下游团队"——你只能手动分析、手动加一条新规则、手动推到所有人的配置里。每一次进化，都需要人的介入。规则集是你的经验沉淀，但沉淀的过程完全靠你。
基于 AI 的反馈器是可进化的。它本身就是 AI，这意味着它能做三件工具做不到的事：
收集失败信息：每次 Evaluator Agent 评审代码发现问题——跨模块影响遗漏、依赖版本误升级、测试覆盖不足——它可以把这次失败的完整上下文（任务描述、变更内容、判定理由）结构化记录下来，形成一条"失败案例"。
从失败中总结经验：当同类失败案例积累到一定数量后，AI 反馈器可以自动归纳——"过去两周，AI 在涉及 Proto 文件变更的任务中，有 7 次没通知下游团队。模式识别：AI 不理解 Proto 文件的变更影响范围。"
将经验写回系统：总结出的规则可以自动更新到 Agent Skills（写入
SKILL.md的约束条件）、同步到 MCP 工具的描述中（增加"修改此文件前必须确认下游依赖"的提示）、注入到 Evaluator 的评分标准里（增加"Proto 变更通知"检查项）。
整个过程形成一条进化飞轮：缺失或越界发生 → AI 反馈器捕获 → 积累案例 → 归纳模式 → 自动更新规则 → 同类问题减少。这个飞轮一旦转起来，它就在自己变聪明。你不需要每次发现问题都手动修改规则——你的角色从"规则维护者"变成了"进化方向校准者"，偶尔抽查 AI 自动生成的规则是否合理即可。
这不是科幻。在 Multi-Agent 架构中，Evaluator Agent 的输出本身就可以作为另一个"规则提炼 Agent"的输入——你不需要自己写代码来串联，只需要在 Agent 编排中定义这个反馈链路。
而基于工具的反馈器，永远做不到这一点。因为它不会"看"、不会"归纳"、不会"写"——它只会执行你写好的固定逻辑。工具反馈器是你的经验的忠实执行者，AI 反馈器是你经验的自主放大器。
两种模式的协作关系
Human in Loop 和 Human on Loop 不是互斥的，而是分层协作的：
Human in Loop 解决的是"当下这个任务"的问题——你直接参与，让AI当场做对。Human on Loop 解决的是"以后所有类似任务"的问题——你建立自动反馈循环，让系统自动反馈、自己解决问题、自主进化。
两者结合，给出了完整的行动指南：对个人，在回路中给出反馈；对团队和组织，建立自动反馈回路并对该回路给出反馈——既回答了"做什么方向"，也回答了"谁来做"。
对于团队管理者来说，这个分层模型给出了一个清晰的角色分工：你不需要亲自参与每次 AI 对话来纠正错误（那是 Human in Loop 的事），但你需要为团队搭建"回路上"的自动机制——评审流程、工具链、Agent Skills 知识库。你的价值不在"比AI更会写Prompt"，而在"设计一个让AI越用越好的系统"。
为什么要走出回路？
理解了两种模式的协作关系之后，一个自然的问题浮出水面：既然 Human in Loop 灵活准确，为什么不一直留在回路里？
原因在于一个物理层面的上限：AI 以机器速度产生的代码变更、设计决策、Bug 修复，远超一个人能同时关注的信息量。你要么成为瓶颈，要么被动走过场。这就是"认知负荷"和"不可扩展"的本质——不是不够努力，而是人的带宽匹配不了机器的输出速度。走出回路不是选择，而是必然。
而走出回路的方向，就是将有效的反馈从 Human in Loop "升格"为 Human on Loop 的持久化资产。这就引出了一个更本质的视角——
一个更本质的视角：一次性的 vs 可复用的
从"努力的成果能存续多久"这个角度重新审视两种模式，你会发现一个更深层的区分：
Human in Loop 是一次性的。 你在对话中补充的知识、指出的方向，都只存活在这个对话上下文中。任务完成，对话关闭，这些信息也随之消散。下次新开一个对话，AI 又回到了"不知道"的状态——你得把同样的规则再说一遍。Human in Loop 的产物是对话记录——私有的、不可迁移的、用完即弃。
Human on Loop 是可复用的。 你写进 Agent Skills 的领域知识、配置到 MCP 的工具接口、沉淀下来的 Harness 架构——这些不会随着对话关闭而消失。下次打开一个新对话，AI 仍然能读取 Skills 中的规则，仍然能通过 MCP 调用数据源，仍然运行在同样的 Harness 流程中。Human on Loop 的产物是持久化资产——可跨任务复用、可团队共享、可持续积累。
理解了这一点，你也就知道什么时候该用哪种模式了：发现一个问题反复出现，就应该把它从 Human in Loop "升格"到 Human on Loop。
但还有一个问题没有回答：当你身处回路之中、或者正在设计回路之上的自动反馈器时，你用什么来判断偏差的本质？反馈模式回答的是"谁来修正偏差"，而接下来要讲的 SRK 模型回答的是"偏差从何而来"——两者结合，才知道谁来做什么、做什么最有价值。
根因分析：用SRK框架定位错误类型
确定了优化方向之后，下一步是定位根因。这里我借用SRK行为模型（Skill-Rule-Knowledge）来进一步分析AI为什么会出这样的错。这个模型最早用来理解人类的错误行为，我发现它对分析AI同样适用。
SRK模型将行为按认知负荷分为三个层级：
注：AI 的"技能"层问题与人类的有所不同——人类的技能失误源于注意力分散或肌肉记忆偏差，AI 的技能缺口则源于缺少工具或操作入口。但 SRK 的三层分类框架对定位问题仍然有效。
现在，我们把"诊断→优化方向→SRK根因"串起来：
缺失场景的SRK根因
知识错误：AI不知道你的项目对旧ORM有隐性依赖——替换为新ORM时漏掉了模块B中直接引用旧ORM查询结果的逻辑。→ 补充知识（如通过 MCP 连接项目知识库）
规则错误：AI采用"先写代码后写测试"作为默认工作流，而你的团队需要"先写测试，确认测试失败，再写实现使其通过"。→ 将流程规则写入 Agent Skills
技能缺口：AI需要运行构建来验证跨模块影响，但它不知道项目的构建命令是
pnpm build而非npm run build，也没有配置好的构建工具可以调用——它想做，但缺少操作入口。→ 通过 Agent Skills 提供命令参考，或为 AI 配置可直接调用的构建工具
越界场景的SRK根因
知识错误：AI不知道数据库连接串配置文件是禁止修改的——它以为改端口时"顺便更新一下"是合理操作。→ 通过 MCP 工具权限控制
规则错误：AI认为"重构时升级依赖库到最新版本是标准做法"，但你的团队策略是"只升级有安全漏洞或明确需求的依赖"。→ 将依赖管理决策规则写入 Harness Prompt
技能缺口：AI有文件写入工具但没有细粒度的路径限制——工具给了它"能改任何文件"的能力，它本应只被允许修改
src/目录。→ 工具层做权限控制：文件写入工具只暴露授权目录，超出范围的路径操作直接拒绝
到这里你会发现一个有意思的分层：知识问题的改进主要依赖个人——你把项目信息写进文档就好；规则问题的改进需要团队协作——规则需要团队一起讨论、对齐，否则你定的规则可能和别人已有的习惯冲突；技能问题的改进则需要组织层面的工具建设——给 AI 配置 MCP 工具、设计工具权限模型、搭建可调用的命令和 API，这些不是一个人能搭起来的。三个层面——个人、团队、组织——缺一不可。这恰好和《如何让团队真正接受AI编程助手？》中讨论的信任提升模型一一对应。
知道了问题从哪里来，下一步就是针对每种根因找到对应的打法。
提升路径：优化方向 × SRK 的实践矩阵
把"优化方向"和"SRK"两个维度组合起来，就形成了一张完整的实践地图：
刚才用 SRK 定位了"偏差从何而来"，现在换个方向——每种根因该怎么打。下面按三个维度展开。
针对知识问题
核心策略：AI不知道的，你得喂给它。
知识的本质是"AI脑子里没有的信息"——项目架构、技术栈选型、团队约定、业务上下文。不管是缺失还是越界，解法都是把信息补进去。
补充场景：AI跨模块重构时漏了模块B的依赖调整 → 把项目架构关系写入文档或 Agent Skills，让 AI 在改模块 A 时能查到模块 B 的依赖
限制场景：AI修改了不该动的数据库连接串配置 → 明确标注哪些配置文件是"禁区"，并将这些边界知识同步到 System Prompt 或 Agent Skills
关键变化：知识问题的解法正在从"一次性投喂"转向"动态检索"。与其把所有文档一股脑塞进上下文，不如让 AI 在需要时按需获取——就像给新同事的不再是一本静态手册，而是一个可以随时按关键词查阅的内部知识库。
针对规则问题
核心策略：给AI明确的规则，不要让它猜。
规则的本质是"什么情况下该做什么决策"。AI 需要清晰的 if-then 约束，而不是模糊的原则。
补充场景：AI遇到架构决策时自行做主 → 规则："当需求涉及多个可行方案时，先输出方案对比（含 trade-off 分析），等待确认后再继续"
限制场景：AI在修改 A 模块时顺手升级了 B 模块的依赖 → 规则："任何依赖版本变更，必须单独评估、单独提交，不得与其他代码修改混杂"
关键挑战：规则问题比知识问题更难处理，因为规则会冲突。你同时说"严格遵守编码规范"和"不要重写现有代码"，AI 遇到一个编码不规范的文件时就左右为难。解法是通过试验-改进的循环持续打磨规则集——每次发现冲突就补充优先级，一个规则一个规则地验证。
针对技能问题
核心策略：AI想做但做不到的，给它工具和能力。
技能的本质是"AI有意图但没有执行手段"。它知道要运行测试、要查数据库、要调用 API，但没有对应的工具、不知道命令、缺少操作入口。这和知识问题不同——知识问题是"不知道"，技能问题是"做不到"。
补充场景：AI知道重构后要验证，但不知道项目的构建命令是
pnpm build而非npm run build，也没有配置好的构建工具可以调用。→ 通过 Agent Skills 提供命令参考，或为 AI 配置可调用的构建/测试工具补充场景：AI需要查询数据库来确认迁移脚本是否正确执行，但没有数据库连接工具。→ 通过 MCP 暴露数据库查询能力，让 AI 能自主验证
限制场景：AI有文件写入工具但没有路径限制——工具给了它"能改任何文件"的能力。→ 工具层做权限控制：文件写入工具只暴露授权目录，超出范围的路径操作直接拒绝
限制场景：AI被授予了过宽的工具集——它既能改代码又能改 CI/CD 配置。→ 按任务类型分配工具：编码任务只挂载代码相关工具，部署配置任务单独授权
关键洞察：技能问题的解法不是"对AI说更多遍"，而是在工具层面做文章——给什么工具、不给什么工具、工具的参数范围划到哪里。这不是 Prompt Engineering 能解决的，需要工具链和平台层的配合。
一个完整的实践框架
现在把整个方法串起来。不管面对什么任务、什么技术栈，你都可以这样做：
第一步：诊断（发现问题）
AI的输出少了什么？ → 缺失
AI的输出多了什么？ → 越界
两者都有？ → 先处理越界，再处理缺失
第二步：定方向（明确优化方向）
缺失 → 补充：让AI补齐缺失的部分
越界 → 限制：给AI圈定明确的边界
第三步：找根因（用SRK定位）
信息不足？ → 知识问题
规则不对？ → 规则问题
缺少工具或能力？ → 技能问题
第四步：选对策（从实践矩阵中匹配方法）
知识 + 补充 → 补充该做的事的信息
知识 + 限制 → 补充不该做的事的信息
规则 + 补充 → 建立该做的事的规则
规则 + 限制 → 建立不该做的事的规则
技能 + 补充 → 提供工具和能力，让AI能做该做的事
技能 + 限制 → 收窄工具权限，不让AI有越界的能力
第五步：验证与迭代
用同样的方式再触发一次，问题解决了吗？
如果解决了，把修复措施固化为模板，下次复用
如果没有，回到第一步重新诊断
最后一点提醒：规则和工具并不是建好就一劳永逸的。你配置的检查可能过于严格，让 AI 连合理操作也不敢做；你写的限制可能遗漏了某类边界情况，悄悄放行了问题。定期回到操作层面——随机抽查几个 AI 生成的 PR，深度看看实际代码质量——是保持你对 AI 系统的真实认知、而不是只看仪表盘的唯一方式。
结论
"提升AI能力"不是什么玄学。拆开来看，无非是两件事：
让AI完成你要求的所有事（减少缺失），并且只做你要求的事（减少越界）。
前者的优化方向是补充——补齐AI缺失的输出和行为；后者的优化方向是限制——给AI圈定边界，不越雷池一步。
具体怎么补充、怎么限制？用SRK框架来定位根因：
知识不够就补充信息，
规则不对就明确约束，
技能不够就提供工具和能力。
一个系统化的方法就够了：
发现偏差 → 判断缺失还是越界 → 确定补充还是限制 → 用SRK定位根因 → 针对性采取措施 → 验证 → 固化为模板
对个人来说，这已经是够用的诊断工具。但对团队管理者来说，这套框架还有一个额外的价值：它让"提升AI能力"从一个模糊的口号，变成了一张可分解的任务清单。 你可以用它来做团队复盘——下次回顾时，不再是泛泛地说"AI用得不好"，而是逐条诊断：最近频繁出现的那些问题是缺失还是越界？根因在知识、规则还是技能层面？每一类问题应该由谁负责解决？
技术会变，模型会变，但这个框架不会变。掌握了它，你在任何新技术面前都有了自己的判断力。
当你的团队成员也能这样思考时，"提升AI能力"就不再是一个模糊的口号，而是一套可执行、可衡量、可迭代的方法论。
现在就用起来。下一次AI给的结果不如意时，别急着改Prompt——先问自己：这是缺失，还是越界？就像医生看病不会直接开药，诊断对了，方案自然就出来了。
