真正有效的方法：AI 结对编程的12个技巧
<h2>TL</h2><p><strong>规划与流程：</strong></p>
<ul>
<li>先写计划，让AI先评论，再编码</li>
<li>使用编辑测试循环：编写失败测试→AI 修复→重复</li>
<li>频繁提交小的更改以获得可读的差异</li>
</ul>
<p><strong>快捷工程：</strong></p>
<ul>
<li>保持提示简短，具体上下文膨胀会降低准确性</li>
<li>在编写代码之前要求逐步推理</li>
<li>使用文件引用（@path/file.rs:42-88）而不是代码转储</li>
</ul>
<p><strong>上下文管理：</strong></p>
<ul>
<li>在重大更改后重新索引你的项目以避免出现幻觉</li>
<li>使用 gitingest.com 等工具获取代码库摘要</li>
<li>使用 Context7 MCP 与最新文档保持同步</li>
<li>像对待初级开发人员一样对待 AI 输出，PR 审查一切</li>
</ul>
<p><strong>无效的方法：</strong></p>
<ul>
<li>将整个代码库转储到提示中</li>
<li>期望人工智能理解隐含的要求</li>
<li>无需审查即可将安全关键代码托付给人工智能</li>
</ul>
<hr />
<h2>1. 从书面计划开始（先认真打好基础）</h2>
<p>让你的人工智能为你正在构建的功能起草一份<strong>Markdown 计划。然后让它变得更好：</strong></p>
<ol>
<li><strong>询问</strong>有关边缘情况的澄清问题</li>
<li><strong>让其批评自己的计划</strong>是否存在漏洞</li>
<li><strong>重新生成改进版本</strong></li>
</ol>
<p>将最终计划保存为 <code>instructions.md</code>，并在每次提示中引用。仅此一步就能避免 80% 的“AI 中途出错”的情况。</p>
<p><strong>真实示例：</strong></p>
<pre><code>Write a plan for adding rate limiting to our API. Include:
- Which endpoints need protection
- Storage mechanism for rate data
- Error responses and status codes
- Integration points with existing middleware
Now critique this plan. What did you miss?
</code></pre>
<h2>2. 掌握编辑-测试循环</h2>
<p>这是 TDD，但由 AI 来实现：</p>
<ol>
<li><strong>让人工智能编写一个</strong>能够准确捕捉你想要的内容的失败测试</li>
<li><strong>自己检查测试</strong>——确保测试正确的行为</li>
<li><strong>然后告诉人工智能：“让这个测试通过”</strong></li>
<li><strong>让人工智能进行迭代</strong>——它可以自动运行测试并修复故障</li>
</ol>
<p>关键在于实施前审查测试。糟糕的测试会导致代码无法满足要求。</p>
<hr />
<h2>3. 要求逐步推理</h2>
<p>将其添加到你的提示中：</p>
<pre><code>Explain your approach step-by-step before writing any code.
</code></pre>
<p>你可以在错误的假设变成错误代码之前将其捕捉到。能够“自发思考”的人工智能模型会减少犯愚蠢的错误。</p>
<hr />
<h2>4. 不要抛弃上下文关联</h2>
<p>大型项目会分散 AI 的注意力。解决方法如下：</p>
<h3>使用 gitingest.com 获取代码库摘要</h3>
<ol>
<li>前往 gitingest.com</li>
<li>输入你的 repo URL（或将任何 GitHub URL 中的“github.com”替换为“gitingest.com”）</li>
<li>下载生成的文本摘要</li>
<li>引用此文件而不是复制粘贴文件</li>
</ol>
<p>不要这么给prompt：**将 10 个文件粘贴到提示中<br />
<strong>而是这样：</strong> “请参阅附件 codebase_summary.txt 了解项目结构”</p>
<h3>对于文档：使用 Context7 MCP 或 Live Docs</h3>
<p>Context7 MCP 通过显示文档的“最新页面”使 AI 与最新文档保持同步。</p>
<p>什么时候用：当你的文档频繁更改时，请参考 MCP 连接，而不是每次都粘贴过时的片段。</p>
<hr />
<h2>5.控制版本是你的安全壁垒</h2>
<ul>
<li>颗粒度提交，确保 <code>git add -p</code>差异可读</li>
<li><strong>永远不要让未提交的更改堆积起来</strong>：干净的 git 状态可以更轻松地隔离 AI 引入的错误并干净地回滚</li>
<li><strong>使用有意义的提交信息</strong>：它们帮助 AI 理解变化背景</li>
</ul>
<hr />
<h2>6. 保持Prompt的精准</h2>
<p><strong>错误：</strong> “这是我的整个代码库。为什么身份验证不起作用？”</p>
<p><strong>正确：</strong> “当 JWT 格式错误时，<code>@src/auth.rs</code>第 85 行会出现混乱。请修复此问题并添加适当的错误处理。”<code>None</code></p>
<p>具体的问题有具体的解决方案。模糊的问题会产生幻觉。</p>
<p>在提示中使用代码术语：引用代码库中的精确标识符，而不是通用的业务术语。例如，使用“ <code>createOrder()</code>and”<code>processRefund()</code>而不是“下订单”或“退款”，或者使用“use”<code>UserEntity</code>而不是“账户”。这种精确性有助于 AI 应用正确的抽象，并避免领域语言和代码之间的不匹配。</p>
<hr />
<h2>7. 重大变更</h2>
<p>如果你使用带有项目索引的 AI 工具，请在进行重大重构后重建索引。过时的索引是 AI“找不到”确实存在的函数的原因。</p>
<p>大多数工具都会自动索引，但当出现问题时会强制刷新。</p>
<hr />
<h2>8. 使用文件引用，而不是复制粘贴</h2>
<p>大多数 AI 编辑器都支持类似 的引用 <code>@src/database.rs</code>。使用它们代替粘贴代码块。</p>
<p><strong>好处：</strong></p>
<ul>
<li>AI 看到的是当前文件状态，而不是过时的快照</li>
<li>更少的 token 使用量 = 更高的准确率</li>
<li>减少提示混乱</li>
</ul>
<p>**注意：**语法因工具而异（Forge使用 <code>@</code>，有些使用 <code>#</code>，等等）</p>
<hr />
<h2>9. AI编写测试，你编写规范</h2>
<p>告诉人工智能到底要测试什么：</p>
<pre><code class="language-text">For the new `validate_email` function, write tests for:
- Valid email formats (basic cases)
- Invalid formats (no @, multiple @, empty string)
- Edge cases (very long domains, unicode characters)
- Return value format (should be Result<(), ValidationError>)
</code></pre>
<p>一旦你指定了案例，AI 就擅长生成测试样板。</p>
<hr />
<h2>10. 使用诊断报告</h2>
<p>当遇到困难时，要求系统地分解：</p>
<pre><code class="language-text">Generate a diagnostic report:
1. List all files modified in our last session
2. Explain the role of each file in the current feature
3. Identify why the current error is occurring
4. Propose 3 different debugging approaches
</code></pre>
<p>这迫使人工智能系统地思考，而不是猜测和检查。</p>
<hr />
<h2>11. 设置清晰的样式指南</h2>
<p>给你的AI一个简短的系统提示：</p>
<pre><code class="language-text">Code style rules:
- Use explicit error handling, no unwraps in production code
- Include docstrings for public functions
- Prefer composition over inheritance
- Keep functions under 50 lines
- Use `pretty_assertions` in test
- Be explicit about lifetimes in Rust
- Use `anyhow::Result` for error handling in services and repositories.
- Create domain errors using `thiserror`.
- Never implement `From` for converting domain errors, manually convert them
</code></pre>
<p>一致的规则=一致的代码质量。</p>
<hr />
<h2>12. 像高级工程师</h2>
<p>将每一次 AI 变化都视为初级开发人员的 PR：</p>
<p><strong>安全审查：</strong></p>
<ul>
<li>检查注入漏洞</li>
<li>验证输入有效性</li>
<li>寻找硬编码的秘密</li>
</ul>
<p><strong>绩效考核：</strong></p>
<ul>
<li>观察 N+1 查询</li>
<li>检查算法复杂度</li>
<li>查找不必要的分配</li>
</ul>
<p><strong>正确性审查：</strong></p>
<ul>
<li>手动测试边缘情况</li>
<li>验证错误处理</li>
<li>检查是否存在偏差一错误</li>
</ul>
<p>AI 很聪明，但并非明智。你的经验很重要。</p>
<hr />
<h2>为什么行不通</h2>
<h3>“Magic Prompt”错误</h3>
<p>不存在完美的prompt能让 AI 永不犯错。更好的工作流程胜过更好的提示。</p>
<h3>期待读</h3>
<p>人工智能无法推断你未提出的需求。“使其投入生产”如果没有具体细节，就毫无意义。</p>
<h3>信任人工智能的架构决策</h3>
<p>AI 擅长实现你的设计，但在高级系统设计方面却很糟糕。你负责架构，AI 负责实现。</p>
<h3>忽略特定领域上下文</h3>
<p>除非你告知，否则 AI 不会知道你的业务逻辑、部署约束或团队约定。</p>
<hr />
<h2>争议观点：人工智能结对编程比人类结对编程</h2>
<p><strong>对于大多数实施任务。</strong></p>
<p>人工智能不会疲倦，没有自我，不会争论代码风格，也不会评判你的谷歌搜索习惯。它就像一个拥有无限耐心和完美记忆力的初级开发人员。</p>
<p>但它也无法捕捉逻辑错误，无法理解业务背景，也无法抵制糟糕的想法。棘手的事情还是需要人类来解决。</p>
<hr />
<h2>最终现实检验</h2>
<p>AI 编程工具可以显著提升生产力，但前提是你必须系统地使用它们。那些获得巨大收益的工程师并非依靠神奇的提示，而是依靠规范的工作流程。</p>
<p>首先制定计划，测试一切，像你的生产系统依赖它一样进行审查（因为确实如此），并记住：人工智能是你的实习生，而不是你的架构师。</p>
<p>编码的未来并非人类与人工智能的对决，而是拥有人工智能的人类与没有人工智能的人类的对决。请明智地选择你的阵营。</p>
结对编程确实效率更高，不过还是得掌握技巧，不然就跟倆傻子一起工作一样了哈哈哈哈哈 AI编程方法很实用
页:
[1]