在 AI Coding ，真正拉开开发者效率差距的，往往不是谁用了 Cursor、谁用了 Copilot，而是谁更懂得怎么和 AI “对上频道”。

我越来越觉得，用好 AI Coding，关键不在工具多先进，而在于你有没有找到那些看不见、却决定协作质量的“隐形杠杆”——比如怎么提问、怎么引导、怎么复盘，甚至怎么“教”它理解你的项目。

这篇文章，就是我从自己和团队的真实复盘里，抠出来的第一版“个人杠杆清单”。

它肯定不完美，也会随着模型升级不断迭代。但对我而言，写下这些，是为了把那些“感觉对了”的瞬间，变成可复制、可传递的经验。

AI Coding 的最大杠杆就是全面拥抱，再看细节。

1.复盘中 Prompt 分析的缺失

目标

在我自己的每一次任务复盘中，我都能完整记录并分析我所使用的核心提示词（Prompt）及其迭代过程，能够清晰地将最终代码产出的优劣与我的提问方式直接关联起来。

现状

我发现在复盘AI Coding完成的任务时，往往把焦点放在了“结果”上——比如AI写的代码哪里不对，或者哪个功能没实现。但似乎忽略了整个过程中最关键的输入环节：到底是怎么问的？

只知道输出，甚至只对输出结果描述了一下，效果不好，对提升 AI Coding 效果一点帮助也没有。

目前普遍缺乏对Prompt进行记录、分析和共享的意识与流程。不分析Prompt的复盘，就像是调试一段程序却不看它的源代码，很难找到问题的根本原因。

策略

1. 像对待代码一样对待Prompt：将最终成功的Prompt或Prompt链视为与代码同等重要的交付产物。养成习惯，在提交代码时，将核心Prompt附在Commit信息或代码注释中。Prompt 的记录不仅是要记录失败的，也要记录好的。

2. 有意识地迭代而非推倒重来：当一个Prompt效果不佳时，不要立刻删掉重写。尝试在原基础上进行修改和“微调”，并观察效果的变化。这个迭代的过程本身就是宝贵的经验。

3. 使用“(P+M+T)框架”进行提问与复盘：在向他人求助或进行自我复盘时，养成使用“(Prompt + Model + Task)框架”来描述问题的习惯，即：我用某个模型，输入了某段Prompt，希望完成某个任务，但遇到了某个问题。甚至可以加上，过程中我切换了某些模型，但是效果还是不及预期。

2.AI 首次介入项目的 Onboarding

目标

当我在一个新项目中首次使用AI时，我会100%执行一次“AI入职引导”会话“。我会先花费15分钟引导AI分析并理解项目的目标、技术栈和架构，然后再分配具体的编码任务。

现状

我观察到，当我们想让AI开始在一个项目中工作时，我们常常会跳过一个至关重要的步骤：项目介绍。我们更倾向于把它当成一个即插即用的工具，直接就某个具体问题开始提问，然后当我们发现AI生成的代码不符合我们项目的特定架构，或者用了错误的技术版本时，我们又会感到很困惑 。

这其实和我们引导一个新人入职的道理一样。如果没有人告诉新人我们项目的背景、架构和技术选型，他也同样会犯错。

策略

1. 主持一次“AI项目启动会”：在一个新项目或新模块中，将你与AI的第一个会话专门用于“入职引导”。使用类似这样的指令：“请扫描分析整个项目，然后用列表形式告诉我：1.这个项目的主要目的是什么？2.核心的技术栈和框架有哪些？3.整体的软件架构是怎样的？”

2. 纠正AI的理解偏差：在AI给出分析后，进行人工核对和修正。例如：“你的分析基本正确，但有一个关键点需要强调：我们项目使用的xxx库是2.4.1版本，其API与新版不同，请在后续所有工作中严格遵守这个版本限制。”

3. 保存并复用“入职摘要”：将经过你修正后的“项目摘要”保存下来。在之后关于这个项目的每一次新对话中，都将这份摘要作为“开场白”，确保AI始终在一个正确的基础上开始工作

4. 善用 Spec-kit 和 OpenSpec，这两个是有区别的

3.AI 代码风格与开发规范的对齐

目标

AI生成的代码应有90%以上符合我个人的编码风格习惯 ，无需我花费大量时间进行手动格式化和重构。

现状

这个问题非常普遍，是大家日常使用中的一个核心痛点。我看到的情况是，我们很多人都在尝试解决这个问题，比如在工具里配置了阿里的开发规范 ，但效果时好时坏，感觉AI并没有完全听话 。

最直观的感受是，AI写的代码缺少一种“艺术感” 。它能完成功能，但实现方式很“笨拙”。比如，生成的函数经常特别长 ，逻辑也很啰嗦，像是在写教学案例，而不是生产代码 。更恼人的是，它似乎没有“复用”的概念，我亲眼见过它放着项目里现成的公共方法不用，自己又重新实现了一遍相似的逻辑 ，这无疑增加了代码的冗余度。

此外，AI的“想法”也经常和我自己的编码习惯打架 。我倾向于简洁直接，但它可能会为很简单的赋值操作单独创建一个方法 。这就导致我需要跟在它后面，花费额外的精力去“擦屁股”，把它写的代码改成符合我代码风格的样子。

策略

1. 提供代码范例 (Code Prompting)：在要求AI写代码时，除了描述需求，还要@一个你认为风格良好、符合规范的现有文件或代码片段，并明确指示“请严格遵循此文件的代码风格和结构进行编写”。

2. 风格总结与固化：将自己写的优质代码文件交给AI，让它帮你总结出一套代码风格规则，然后将这些规则补充到 rules 文件中，让AI“记住”你的偏好。rules 文件也需要分层级，有一个 alwasy 引用的 rules，也有属于某个项目的 rules，甚至区分到任务层级。

3. 持续调优：当AI生成不合规代码时，不要只修改代码本身。应该花一分钟优化你的提示词或配置文件，比如明确告诉它：“下次遇到类似情况，必须调用XxxUtils.doSomething()方法，禁止重新实现”。

4.处理需求或 bug 的流程

目标

对于任何预估耗时超过30分钟的开发任务，我都会先让AI生成一份包含步骤的解决方案，并在评审通过后才开始生成代码，确保100%的复杂任务都有前置规划。

现状

我发现我们团队在如何“使用”AI上，流程并不统一，这导致了效率的差异。有时候，我们似乎会陷入一个误区，即把AI当成一个无所不能的黑盒，直接把问题抛给它，然后就期望得到完美的最终代码。我见过有同事直接用UI截图让AI去实现功能，结果往往是代码跑不起来，或者需要大量的调试和返工 。

另外一个典型问题是，在处理一些冷门或者有历史包袱的技术问题时，我们容易和AI“较劲”。比如之前有同事处理一个旧版本库的兼容性问题，反复告诉AI版本号，但AI还是连续多次给出新版本的、不兼容的API方案，浪费了大量时间 。我们似乎缺少一种判断机制，来识别何时应该停止让AI“思考”，转而直接“喂”给它正确答案让它执行。

策略

1. 执行“一分钟评估”：在开始任何任务前，先花一分钟判断：这是一个常见的、AI擅长的问题，还是一个涉及冷门技术栈或历史代码的“疑难杂症”？

2. 养成“规划先行”的肌肉记忆：主动使用Cursor的plan模式或类似的提示词（例如：“针对我的需求，请先不要写代码，而是给我一份详细的、分步骤的实现计划”），或者 spec-kit。在拿到计划后，认真思考并补充其中的缺漏。

3. 成为“疑难杂症”的“投喂者”：当你判断这是一个AI不擅长的冷门问题时，改变策略。自己先通过搜索或研究找到解决方案的关键信息（比如正确的函数名、配置项），然后把这些“标准答案”直接告诉AI，让它来完成代码填充和集成的“体力活”，而不是让它去大海捞针。

5.AI 处理模式化/重复性任务的一致性

目标

当我执行一个重复性任务时（如：新增一个渠道），我会利用一个AI生成的标准操作手册来指导和校验AI的工作，确保首次生成代码的完整度达到100%。

现状

我观察到我们团队在利用AI处理一些有固定范式的重复性工作时，效率并没有达到理论上的最大化。一个典型的例子就是“新增渠道”，这个任务可能要修改好几个文件，每次让AI去做，它总能完成大概80%，但总会遗漏一些细节，导致我们必须得跟在后面人工检查，把那剩下的20%给补上 。

这导致了一种“食之无味，弃之可惜”的尴尬。用AI确实比纯手动快，但又因为不能完全信任它，每次都需要投入精力去“查漏补缺”，这部分心智负担并没有完全被省下来。

策略

1. “先做一次，再教一次”：当你和AI协作完成一个重复性任务（或手动补全了AI遗漏的20%）之后，立即进行复盘。将所有相关的代码和步骤都提供给AI，并下达指令：“请为‘新增XX功能’这个任务，总结一份详细、无遗漏、可被复用的操作手册（SOP），并以markdown格式输出”。

2. “拿着手册干活”：下次再接到同类任务时，你的第一个动作就是将这份SOP文档@给AI，并明确要求：“请严格遵循这份手册的每一个步骤来完成本次开发任务”。

3. “对着手册检查”：在AI生成代码后，进行二次校验。指令是：“请对照你刚才遵循的手册，自我检查一遍，并告诉我你是否严格执行了所有步骤。如果有遗漏，请立刻补充”。这会让AI进行自我修正。

6.AI 对话的上下文长度管理

目标

我能够主动管理与AI的对话上下文，在AI性能下降前（而不是UI百分比报警后）主动开启新对话，并熟练运用@chat或“总结-粘贴”等技巧来无缝迁移核心信息，确保沟通效率。

现状

我观察到我们中很多人在使用AI时，对上下文长度的管理是比较被动的。我们常常会一直聊下去，直到看到工具界面上的百分比变得很高（比如80%-90%）时，才意识到可能需要开启一个新的对话了 。我自己也经历过，当一个对话变得很长，或者处理的文件非常大时，AI的“记性”会明显变差 ，它可能会忘记我们之前定下的某个规则，或者给出与前面内容矛盾的回答。

策略

1. 从“被动重置”到“主动切换”：改变习惯，不要等到UI报警。当你完成了一个独立的子功能，或者感觉对话焦点开始发散时，就应该主动开启一个新的对话窗口。为自己设定一个更严格的个人阈值，比如60%或70%。阈值的设置，通常也要跟模型有关。

2. 掌握上下文“搬家”技巧：熟练运用两种核心的上下文迁移方法。

   • 精确引用：使用@功能直接引用之前的某个或某几个对话窗口。

   • 总结继承：在一个对话结束前，使用“请帮我用要点形式总结我们这次对话的核心结论、代码变更和待办事项”这样的指令，然后将AI生成的精华摘要作为第一个提示词，开启下一段对话。

3. 识别“上下文污染”的信号：学会识别AI“累了”的迹象，比如：开始问你已经给过的信息、无视了你之前强调的某个约束条件、生成的代码风格与之前不一致等。一旦出现这些信号，就应立刻切换新对话。

7.前后端协作开发的 AI 提效

目标

当我在进行全栈开发时，我会100%使用IDE的“工作区（Workspace）”功能来同时管理前后端项目 ，确保AI能够无缝地@两个项目的文件，实现跨项目推理和代码生成。

现状

我观察到我们目前的前后端协作，很大程度上还在沿用一种“交接棒”式的传统流程。后端同事会先用AI把功能写好，然后生成一份Markdown接口文档，前端同事再根据这份文档去开发 。这个模式虽然能跑通，甚至成功率还不低 ，但它的核心媒介是一份静态文档，信息传递是单向的，这在需求快速迭代时容易造成信息不同步，增加了沟通成本。

此外，一个很容易被忽略的细节是，我们有时会忘记检查AI工具的代码索引（Codebase Index）是否已经100%完成 。在索引没建好的情况下就匆忙开始提问，AI因为没“读”完整个项目，自然也无法给出高质量的回答，这也会让我们误以为是AI本身的能力不行。

策略

1. 将“工作区”作为全栈开发标配：只要任务同时涉及前后端，就应立刻创建IDE工作区，并将两个项目添加进去 。要明确区分“在一个窗口打开多个文件夹”和“创建一个工作区”是两种不同的操作，后者才能让AI真正理解项目间的关联。

2. 养成“索引检查”的检查习惯：在开始一项复杂的开发任务前，花5秒钟检查一下AI工具的索引状态，确保它已经达到100% 。如果索引仍在进行中，就耐心等待它完成，避免在信息不全的情况下进行无效提问。

3. 练习跨项目提问：在工作区中，有意识地练习跨项目的提问方式。例如：“请根据我后端@/api/controller/UserController.java中的接口变更，修改前端@/views/UserManagement.vue中对应的服务调用和数据展示逻辑”。

8.AI Coding 的模型感知

目标

对于每一个具体的开发任务，我都能有意识地选择最合适的模型，而不是下意识地使用默认模型。例如，能做到“写文档我选Gemini，因为它表达更流畅；写复杂逻辑我选Claude，因为它上下文理解更深”。

现状

我观察到，我们团队在模型选择上还没有形成统一的章法。很多时候，大家（包括我自己）会习惯性地依赖某一个自己用得最顺手或者公司推荐的模型来处理所有问题。这就像一把“万能锤”，虽然能用，但效率和质量不一定是最高的。

也缺乏一个机制去横向比较：当我用A模型磕磕绊绊解决一个问题后，其实并不知道B模型是否能一次性给出更完美的答案。

策略

1. 主动测试，形成体感：在处理不同类型的任务时，有意识地尝试使用不同的模型，并留意它们的表现差异。例如：“这次是写文档，我试试Gemini；下次是重构代码，我用Claude Code。”

2. 切换模型作为首要调试手段：当一个模型连续2次给出的答案不满意时，应将“切换模型”作为和“优化提示词”同等优先级的操作，而不是最后的无奈之举。

3. 记录个人发现：随手记录下关键发现，例如“Claude Opus在处理SSE（Server-Sent Events）相关逻辑时，代码质量很高”、“Gemini在理解项目启动流程、做性能分析时，思路更广”。

9.将个人专家经验沉淀并传授给AI

目标

当我凭借个人经验发现AI的解决方案存在更优解时，我会100%进行一次“教学对话”。我会向AI解释我的思路，并引导它理解为什么我的方案更好，目标是每周至少让AI“学会”一个我独有的分析模式或解题技巧。

现状

我观察到一个普遍现象：我们团队里一些资深同事的分析能力和直觉，常常能秒杀AI。最经典的例子就是那个“单播改多播”的需求，AI给出了一个改动范围巨大的复杂方案，而有经验的同事一眼就看出，其实只需要改一行代码就够了 。

在这种情况下，我们目前的普遍做法是，凭借自己的专业能力，直接修正或弃用AI的方案，然后继续推进工作。这虽然解决了当下的问题，但我们似乎错过了一个宝贵的“教学”机会。我们很少会停下来，跟AI进行一次深入的对话，去探究“你为什么会觉得要改这么多地方？”或者“我只改动了一行，你能分析一下我的方法好在哪里吗？” 。

策略

1. 从“修正者”转变为“引导者”：当你发现AI的解决方案有缺陷时，不要立刻手动修改。第一步应该是向AI展示你的更优解，并提出引导性问题：“这是一个更简洁的方案，请你分析一下我的方案好在哪里，以及你最初的方案存在哪些考虑不周的地方？”

2. 将“直觉”显性化为“规则”：尝试将你解决问题时的“专家直觉”拆解成AI可以理解的规则或步骤。例如，在排查性能问题时，你的直觉可能是先看启动脚本，你可以把这个经验总结成规则告诉AI：“记住一条规则：在排查应用启动性能时，应优先分析启动脚本的耗时，而不是直接分析应用主进程。”

3. 反思并优化你的提问：在完成一次“教学”后，可以进一步追问AI：“理解了我的专家经验后，你认为我当初应该如何提问，才能让你第一次就给出最优的解决方案？”利用AI的回答，来打磨自己未来的提问技巧。

10.打破新旧项目的“次元壁”

目标

我能够将 AI Coding 的思维和策略平等地应用于所有项目，无论是全新的项目还是有历史包袱的遗留系统。我理解并接受“教”AI理解旧项目需要更多的耐心和前期投入，并视其为必要投资，而不是“不敢用”的理由。

现状

AI Coding 给很多人的感觉就是新项目很爽，但旧项目不敢用。我一开始也很认同这个观点。大家普遍担心 AI 无法理解复杂的遗留代码，或者会“好心办坏事”，破坏原有的稳定逻辑。因此，在面对旧项目时，我们倾向于退回到纯手动编码，放弃了 AI 提效的可能。

策略

1. 心态转变：接受“教学成本”：首先要认识到，新项目终将变成旧项目。对旧项目使用 AI，本质上只是把 “AI 首次介入项目的 Onboarding”（见上文）的过程延长和加深了。不要期待 AI 一上来就能看懂所有历史包袱。
2. 耐心“投喂”而非“放弃”：对旧项目需要更多的耐心，要“教”AI 教得久一点。这包括但不限于：主动“投喂”旧项目的特定架构、设计模式、和“坑”点（参考“将个人专家经验沉淀并传授给AI”）。用于 AI Coding 的思维不分新旧。
3. 从“不敢用”到“辅助用”：不要一开始就让 AI 碰核心逻辑。可以从低风险的、模式化的修改开始（例如：按新规范修改旧代码格式、补充单元测试、迁移旧API），逐步建立你和 AI 之间的信任。
4. 应用一致的 AI 策略：在旧项目上，更要严格执行“规划先行”（plan模式）、“代码范例”（Code Prompting）和“SOP”（操作手册）等策略。用这些结构化的方式，引导 AI 在复杂的“旧土壤”上逐步上手。

总结

AI 不会取代人，但会用 AI 的人，正在悄悄拉开差距

一开始用 AI Coding，总觉得是它在帮我；现在越来越觉得，是我得先学会怎么“带”它。

这正是本文想探讨的核心——一个从“使用者”到“领导者”的思维转变。

它不是万能的队友，但如果你愿意花点心思去引导（如 AI Onboarding）、校准（如 代码风格对齐）、复盘（如 Prompt 分析），它真的能变成你工作流里最可靠的那个“副驾驶”。

本文总结的这十个“隐形杠杆”，都不是灵光一现的技巧，而是从一次次“它又写错了”、“怎么又忘了规则”、“旧项目根本不敢用”的挫败里慢慢磨出来的。

当然，这肯定不是终点。随着模型变强，有些杠杆可能会失效，有些新杠杆会冒出来。我们能做的就是先跑起来，再迭代。

如果你也在摸索怎么和 AI 更舒服地一起写代码，欢迎留言聊聊你的“杠杆”。

下一篇：团队篇。