通过规则和示例定制 AI 行为
通过提供风格指南、示例甚至“规则文件”来引导你的 AI 助手——前期的微调能带来更卓越的产出。
我学到的一点是：你不必接受 AI 默认的风格或方法——你可以通过提供指南来深度影响它。例如，我有一个定期更新的 CLAUDE.md 文件，其中包含 Claude 需要遵循的过程规则和偏好（使用 Gemini CLI 时则使用 GEMINI.md）。这包括诸如“按照我们项目的风格编写代码、遵循我们的 Lint 规则、不要使用某些函数、偏好函数式风格而非面向对象”等内容。当我开始一个会话时，我会将此文件喂给 Claude，使其与我们的规范保持一致。正如 Jesse Vincent 所指出的，这种做法在保持模型“不跑偏”方面效果惊人——它减少了 AI 自由发挥或引入我们不想要的模式的倾向。
即使没有复杂的规则文件，你也可以通过自定义指令或系统提示词来定下基调。GitHub Copilot 和 Cursor 都推出了允许你为项目全局配置 AI 行为的功能。我利用这一点写了一段关于我们编码风格的简短描述，例如：“使用 4 空格缩进，避免在 React 中使用箭头函数，偏好描述性的变量名，代码应通过 ESLint。”有了这些指令，AI 的建议会更接近人类队友的水平。
另一个强大的技术是提供行内示例（In-line Examples）。如果我希望 AI 以特定方式编写函数，我会先展示代码库中已有的类似函数：“这是我们实现 X 的方式，请用类似的方法实现 Y。”如果你想要某种注释风格，可以自己写一个注释并要求 AI 延续这种风格。本质上，这是在为模型提供可模仿的模式。LLM 是模仿大师——给它们一两个例子，它们就能顺着思路走下去。
社区还想出了许多创意“规则集”来驯服 LLM。你可能听说过“Big Daddy”规则，或者在提示词中加入“禁止幻觉/禁止欺骗”条款。这些本质上是提醒 AI 保持诚实，不要凭空捏造不存在的代码。例如，我有时会在提示词前加上：“如果你不确定某件事或缺乏代码库上下文，请请求澄清，而不是编造答案。”这能有效减少幻觉。我使用的另一条规则是：“在修复 Bug 时，始终在注释中简要说明你的推理。”这样，当 AI 生成修复方案时，它也会留下类似 // 修复：将 X 更改为 Y 以防止 Z（根据规格说明） 的注释。这对于后续审查非常有用。
拥抱测试与自动化作为生产力倍增器
利用 CI/CD、Linter 和代码审查机器人——AI 在能自动捕捉错误的环境中表现最佳。
这是“保持人类在环”和“提供上下文”的延伸：一个运转良好的开发流水线能增强 AI 的生产力。我会确保任何大量使用 AI 编码的仓库都拥有稳健的持续集成（CI）设置。这意味着每次提交或 PR 都会运行自动化测试，强制执行代码风格检查（如 ESLint、Prettier 等），并且理想情况下，任何新分支都有可用的暂存部署。
为什么？因为我可以让 AI 触发这些流程并评估结果。例如，如果 AI 通过 Jules 或 GitHub Copilot Agent 开启了一个拉取请求，我们的 CI 将运行测试并报告失败。我可以将这些失败日志反馈给 AI：“集成测试失败，报错信息为 XYZ，让我们调试一下。”这把 Bug 修复变成了一个带有快速反馈的协作循环，AI 处理得非常好。
自动化代码质量检查（Linter、类型检查器）也能引导 AI。我有时甚至会将 Linter 的输出包含在提示词中。如果 AI 写的代码没通过 Linter，我会把错误信息复制到对话中说“请解决这些问题”。模型随后就知道该怎么做了。这就像有一个严厉的老师在盯着 AI 的肩膀。
AI 编程智能体本身也越来越多地整合自动化钩子。一些智能体在所有测试通过之前会拒绝标记任务为“完成”，这正是你想要的严谨性。
通过将 AI 与自动化结合，你会进入一个良性循环：AI 编写代码，自动化工具捕捉问题，AI 修复问题，如此往复，而你负责监督高层方向。这感觉就像雇佣了一个极其迅速的初级开发人员，其工作由一位不知疲倦的 QA 工程师即时检查。但请记住，这个环境是由你搭建的。如果你的项目缺乏测试或自动化检查，AI 的工作可能会带着细微的 Bug 或低劣的质量溜过去，直到很久以后才被发现。
