TL
规划与流程：
- 先写计划，让AI先评论，再编码
- 使用编辑测试循环：编写失败测试→AI 修复→重复
- 频繁提交小的更改以获得可读的差异
快捷工程：
- 保持提示简短，具体上下文膨胀会降低准确性
- 在编写代码之前要求逐步推理
- 使用文件引用（@path/file.rs:42-88）而不是代码转储
上下文管理：
- 在重大更改后重新索引你的项目以避免出现幻觉
- 使用 gitingest.com 等工具获取代码库摘要
- 使用 Context7 MCP 与最新文档保持同步
- 像对待初级开发人员一样对待 AI 输出，PR 审查一切
无效的方法：
- 将整个代码库转储到提示中
- 期望人工智能理解隐含的要求
- 无需审查即可将安全关键代码托付给人工智能
1. 从书面计划开始（先认真打好基础）
让你的人工智能为你正在构建的功能起草一份Markdown 计划。然后让它变得更好：
- 询问有关边缘情况的澄清问题
- 让其批评自己的计划是否存在漏洞
- 重新生成改进版本
将最终计划保存为 instructions.md，并在每次提示中引用。仅此一步就能避免 80% 的“AI 中途出错”的情况。
真实示例：
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?
2. 掌握编辑-测试循环
这是 TDD，但由 AI 来实现：
- 让人工智能编写一个能够准确捕捉你想要的内容的失败测试
- 自己检查测试——确保测试正确的行为
- 然后告诉人工智能：“让这个测试通过”
- 让人工智能进行迭代——它可以自动运行测试并修复故障
关键在于实施前审查测试。糟糕的测试会导致代码无法满足要求。
3. 要求逐步推理
将其添加到你的提示中：
Explain your approach step-by-step before writing any code.
你可以在错误的假设变成错误代码之前将其捕捉到。能够“自发思考”的人工智能模型会减少犯愚蠢的错误。
4. 不要抛弃上下文关联
大型项目会分散 AI 的注意力。解决方法如下：
使用 gitingest.com 获取代码库摘要
- 前往 gitingest.com
- 输入你的 repo URL（或将任何 GitHub URL 中的“github.com”替换为“gitingest.com”）
- 下载生成的文本摘要
- 引用此文件而不是复制粘贴文件
不要这么给prompt：**将 10 个文件粘贴到提示中
而是这样： “请参阅附件 codebase_summary.txt 了解项目结构”
对于文档：使用 Context7 MCP 或 Live Docs
Context7 MCP 通过显示文档的“最新页面”使 AI 与最新文档保持同步。
什么时候用：当你的文档频繁更改时，请参考 MCP 连接，而不是每次都粘贴过时的片段。
5.控制版本是你的安全壁垒
- 颗粒度提交，确保
git add -p差异可读
- 永远不要让未提交的更改堆积起来：干净的 git 状态可以更轻松地隔离 AI 引入的错误并干净地回滚
- 使用有意义的提交信息：它们帮助 AI 理解变化背景
6. 保持Prompt的精准
错误： “这是我的整个代码库。为什么身份验证不起作用？”
正确： “当 JWT 格式错误时，@src/auth.rs第 85 行会出现混乱。请修复此问题并添加适当的错误处理。”None
具体的问题有具体的解决方案。模糊的问题会产生幻觉。
在提示中使用代码术语：引用代码库中的精确标识符，而不是通用的业务术语。例如，使用“ createOrder()and”processRefund()而不是“下订单”或“退款”，或者使用“use”UserEntity而不是“账户”。这种精确性有助于 AI 应用正确的抽象，并避免领域语言和代码之间的不匹配。
7. 重大变更
如果你使用带有项目索引的 AI 工具，请在进行重大重构后重建索引。过时的索引是 AI“找不到”确实存在的函数的原因。
大多数工具都会自动索引，但当出现问题时会强制刷新。
8. 使用文件引用，而不是复制粘贴
大多数 AI 编辑器都支持类似 的引用 @src/database.rs。使用它们代替粘贴代码块。
好处：
- AI 看到的是当前文件状态，而不是过时的快照
- 更少的 token 使用量 = 更高的准确率
- 减少提示混乱
**注意：**语法因工具而异（Forge使用 @，有些使用 #，等等）
9. AI编写测试，你编写规范
告诉人工智能到底要测试什么：
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>)
一旦你指定了案例，AI 就擅长生成测试样板。
10. 使用诊断报告
当遇到困难时，要求系统地分解：
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
这迫使人工智能系统地思考，而不是猜测和检查。
11. 设置清晰的样式指南
给你的AI一个简短的系统提示：
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
一致的规则=一致的代码质量。
12. 像高级工程师
将每一次 AI 变化都视为初级开发人员的 PR：
安全审查：
绩效考核：
- 观察 N+1 查询
- 检查算法复杂度
- 查找不必要的分配
正确性审查：
- 手动测试边缘情况
- 验证错误处理
- 检查是否存在偏差一错误
AI 很聪明，但并非明智。你的经验很重要。
为什么行不通
“Magic Prompt”错误
不存在完美的prompt能让 AI 永不犯错。更好的工作流程胜过更好的提示。
期待读
人工智能无法推断你未提出的需求。“使其投入生产”如果没有具体细节，就毫无意义。
信任人工智能的架构决策
AI 擅长实现你的设计，但在高级系统设计方面却很糟糕。你负责架构，AI 负责实现。
忽略特定领域上下文
除非你告知，否则 AI 不会知道你的业务逻辑、部署约束或团队约定。
争议观点：人工智能结对编程比人类结对编程
对于大多数实施任务。
人工智能不会疲倦，没有自我，不会争论代码风格，也不会评判你的谷歌搜索习惯。它就像一个拥有无限耐心和完美记忆力的初级开发人员。
但它也无法捕捉逻辑错误，无法理解业务背景，也无法抵制糟糕的想法。棘手的事情还是需要人类来解决。
最终现实检验
AI 编程工具可以显著提升生产力，但前提是你必须系统地使用它们。那些获得巨大收益的工程师并非依靠神奇的提示，而是依靠规范的工作流程。
首先制定计划，测试一切，像你的生产系统依赖它一样进行审查（因为确实如此），并记住：人工智能是你的实习生，而不是你的架构师。
编码的未来并非人类与人工智能的对决，而是拥有人工智能的人类与没有人工智能的人类的对决。请明智地选择你的阵营。
微信登陆 
