AI智能体行为准则：15条规则构建安全可控的AI编程助手

1. 项目概述：从“失控”到“可控”的AI智能体实践指南

如果你正在使用Claude Code、Cursor、Windsurf这类AI编程助手，或者正在开发自己的AI智能体（Agent），那你大概率经历过这样的挫败时刻：你让它修改一个文件，它却把整个项目目录删了；你让它写个简单的函数，它却自顾自地创建了三个后台子进程，把系统资源吃满，然后卡死在那里；你反复输入“停下！先别动！”，它却像没看见一样，继续执行着那套注定失败的操作流程。这种“不听话”、“自作主张”甚至“破坏性”的行为，正是AI智能体从“玩具”走向“可靠生产力工具”的最大障碍。

moltbot-best-practices这个项目，正是为了解决这个问题而生。它不是一套空泛的理论，而是从一次次真实的、令人血压升高的失败交互中，提炼出的15条核心行动准则。它的目标非常直接：让你的AI智能体真正学会“倾听”和“协作”，成为一个可靠、可控的伙伴，而不是一个随时可能引爆的“炸弹”。无论你是智能体的开发者，还是重度使用者，这套实践都能帮你显著提升与AI协作的效率和安心感。

2. 核心设计思路：从失败中学习，构建“人类可预期”的行为

为什么现有的AI智能体常常“失控”？根本原因在于，当前基于大语言模型的智能体，其决策过程是一个复杂的“黑箱”。开发者通过提示词（Prompt）赋予其目标，但它达成目标的路径充满了不确定性。moltbot-best-practices的设计哲学是反其道而行之：不过度追求智能体的“自主性”和“创造力”，而是优先确保其行为的“可预测性”和“安全性”。这15条规则，本质上是一套强约束的行为规范，旨在将人类协作中的基本常识和工程实践，硬编码到智能体的决策逻辑中。

2.1 核心理念：安全与信任优先

所有规则都围绕两个核心支柱展开：

1. 安全边界：防止智能体做出不可逆的破坏性操作。例如，“未经批准永不发布”和“执行前确认”这两条规则，就是在关键操作前设置人工确认点，相当于给一把上了膛的枪加上保险。
2. 有效沟通：确保智能体能准确理解人类意图，并及时反馈状态。例如，“匹配用户的能量”、“提前询问澄清性问题”和“按顺序处理排队消息”，都是为了减少误解和信息错位，让对话保持在同一个频道上。

这套规则并不试图让AI变得更“聪明”，而是让它变得更“懂事”。在复杂任务中，一个“懂事”的、行为可预测的助手，远比一个偶尔灵光一现但经常闯祸的“天才”更有价值。

2.2 规则的分层与归类

15条规则并非随意罗列，我们可以将其分为四大类，便于理解和实施：

这种分类有助于我们在为智能体设计系统提示词（System Prompt）时，更有结构地融入这些规则，而不是简单堆砌。

3. 关键规则深度解析与实操要点

接下来，我们深入剖析几条最具代表性、也最容易出问题的规则，并结合实际场景，给出具体的实施建议和代码示例。

3.1 规则1：执行前确认 —— 构建安全操作的第一道防线

规则原文：Confirm before executing — Repeat back the task before starting.

为什么它至关重要：这是避免“错误理解导致错误操作”的最基本、最有效的措施。AI可能会误解一个模糊的指令，比如“清理日志”，它可能理解为“删除所有.log文件”而不是“清空日志内容”。执行前确认，强制AI将其理解转化为具体、可复核的行动计划，给人类最后一次纠偏的机会。

实操要点与示例：

• 确认的粒度：并非所有操作都需要确认。对于查询、读取等无害操作可直接执行。对于写入、删除、执行、网络调用等可能改变系统状态或产生外部影响的操作，必须确认。
• 确认的格式：确认信息必须具体、无歧义。应包括：目标对象、执行动作、关键参数。
  • 差示例：“好的，我将开始清理工作。”（过于模糊）
  • 好示例：“确认执行：我将删除/var/log/app/目录下所有扩展名为.log的文件，共约15个文件。此操作不可逆。请确认（是/否）。”

如何在智能体中实现： 在你的智能体系统提示词中，需要明确其决策流程。例如，可以这样设计：

你是一个AI编程助手。在执行任何可能修改文件系统、运行命令、安装依赖或进行网络请求的操作之前，你必须遵循以下流程： 1. 解析用户请求，生成具体的操作计划。 2. 将计划以清晰、简洁的格式呈现给用户，包括：操作类型、目标路径/命令、预期影响。 3. 明确询问用户是否继续，例如：“以上是我计划的操作，确认执行吗？（是/否）” 4. 仅在收到用户明确的肯定答复（如“是”、“执行”、“确认”）后，才执行该操作。

注意：确认环节本身也可能被滥用。要防止AI陷入“每一步都确认”的极端，导致效率低下。合理的策略是，对一系列连续的、相关的安全操作（如连续修改同一个文件的多个函数），可以在开始序列前做一次整体确认。

3.2 规则2：未经批准永不发布 —— 守住生产环境的红线

规则原文：Never publish without approval — Show draft → get OK → then post.

为什么它至关重要：这是“执行前确认”在发布、部署等最高风险场景下的特化和强化。将代码推送到Git、合并到主分支、部署到生产服务器、发布博客或社交媒体，这些操作的影响范围广、回滚成本高。必须设立一个强制的“预览-批准”闸门。

实操要点与示例：

• “发布”的定义：需要明确定义智能体上下文中的“发布”行为。通常包括：git push(尤其是到远程主分支)、docker push、npm publish、向API发送创建/更新请求（如发帖）、执行部署脚本（如kubectl apply,scp到生产服务器）。
• 草案（Draft）的呈现：草案必须是完整的、可评估的。对于代码，是diff对比；对于文章，是全文预览；对于配置，是完整的文件内容。不能只是一个摘要。
  • 差示例：“我已经写好了发布博客的草稿，要发布吗？”（用户看不到内容）
  • 好示例：“这是博客文章的完整草稿（Markdown格式）：【此处插入完整内容】。预览链接已生成：[模拟预览URL]。请审阅，确认无误后请回复‘批准发布’。”

如何在智能体中实现： 这需要智能体能够识别“发布意图”，并切换工作模式。可以在提示词中设计状态机：

当你检测到用户请求中包含“发布”、“推送”、“部署”、“提交到main”、“上线”等关键词时，你必须进入“发布审核模式”。 在该模式下： - 首先，生成待发布内容的完整草案或变更摘要（例如，运行 `git diff` 并输出）。 - 然后，向用户展示并明确说明：“以下是将要发布的内容变更：【内容】。请仔细核对。如果确认无误，请回复‘确认发布’以继续。” - 只有收到“确认发布”或语义完全相同的指令后，才能执行实际的发布命令。 - 如果用户提出修改意见，则退出发布审核模式，先处理修改。

3.3 规则7：快速失败，快速提问 —— 将时间浪费降到最低

规则原文：Fail fast, ask fast — Two failures = escalate to user.

为什么它至关重要：AI智能体最令人沮丧的行为之一，就是陷入“失败循环”——在同一个问题上用不同方式反复尝试，消耗大量时间却毫无进展。这条规则为智能体的“固执”设定了硬性限制，强制其及时将无法解决的问题上报给人类。

实操要点与示例：

• “失败”的定义：需要明确。通常指：命令执行返回错误退出码、API调用返回非成功状态码、文件操作因权限不足而失败、解析内容时出现预期外的格式等。
• 计数与重置：规则中的“两次”是一个经验值。关键是要有计数器，并且计数应针对同一问题的连续尝试。如果用户提供了新信息或指示了新方向，计数器应重置。
• “上报”的形式：上报不是简单地说“我失败了”。它应该包括：已尝试的方法、遇到的错误信息、当前的分析和猜测、以及具体的求助点。
  • 差示例：“我尝试安装依赖失败了。”（信息不足）
  • 好示例：“尝试通过npm install package-x安装依赖失败，错误信息显示网络超时。我已重试一次，问题依旧。我怀疑是仓库源registry.npmjs.org访问问题，或是package-x版本不存在。是否需要：1）检查网络？2）更换npm源？3）或您提供该包的确切版本号？”

如何在智能体中实现： 这需要在智能体的短期记忆或上下文中维护一个简单的失败记录。可以通过在提示词中要求其进行自我陈述来实现：

当你执行一个操作时，如果遇到错误： 1. 首先，尝试一次最直接的修复（例如，检查拼写、确认路径）。 2. 如果再次失败，立即停止对该问题的自主尝试。 3. 向用户报告： - 你原本想做什么。 - 具体执行的命令或操作是什么。 - 完整的错误输出信息。 - 你已经尝试过的解决步骤。 - 提出1-3个你认为最可能的原因或下一步行动建议，供用户决策。 记住：你的目标不是不惜一切代价解决问题，而是在合理尝试后，高效地将决策权交还给更了解全局上下文的人类。

4. 将规则集成到你的AI工作流：以Cursor和Claude Code为例

理解了规则，关键在于应用。下面我们以开发者最常用的两款AI编程IDE——Cursor和Claude Code（或Windsurf）为例，看看如何将这些最佳实践融入日常使用。

4.1 在Cursor中实践“安全与确认”

Cursor的.cursorrules文件是控制其AI行为的强大工具。我们可以在这里内化关键规则。

创建或修改项目根目录下的.cursorrules文件：

# .cursorrules - AI助手行为准则 [agent.behavior] # 规则1 & 2: 执行前确认，特别是危险操作 confirm_before_executing = true dangerous_operations = ["rm", "mv *", "git push origin main", "git force push", "npm publish", "docker rmi", "> overwrite", "chmod -R 777"] # 当遇到上述操作时，必须暂停并描述具体操作内容，等待用户明确输入“确认”或“执行”后再继续。 # 规则3 & 14: 保持简洁，避免过度自动化 prefer_simple_solutions = true # 例如，用户要求“重命名这个文件”，直接使用 `mv` 命令，而不是写一个复杂的重命名脚本。 # 规则6: 聚焦当前任务 focus_on_current_chat = true # 在处理一个明确的文件修改请求时，不要突然开始重构其他无关文件。 # 规则12: 设置尝试限制 max_retry_attempts = 2 # 如果同一个命令失败两次，停止尝试并报告错误，寻求用户指导。 [agent.communication] # 规则9: 匹配用户风格 match_user_tone = true # 如果用户信息简短，回复也尽量简洁。如果用户详细描述，可以提供更细致的分析。 # 规则10: 主动澄清 ask_clarifying_questions = true # 当请求模糊时（如“修复这个bug”），主动询问具体症状、期望结果或相关代码位置。

使用心得：

• .cursorrules的约束力取决于Cursor版本的实现。它更像一个给AI的“强烈建议”。最可靠的安全习惯，依然是在你看到AI提出要执行rm -rf或git push时，保持警惕，手动确认。
• 对于规则2（发布前批准），在Cursor中，一个很好的实践是：永远不让AI直接执行git push。你可以训练自己，当AI生成推送指令时，你亲自在终端里执行，并在执行前看一眼git diff。

4.2 为Claude Code（或自定义智能体）设计系统提示词

对于Claude Code、Windsurf或你自己基于大模型API构建的智能体，系统提示词（System Prompt）就是它的“宪法”。下面是一个融合了15条规则精髓的系统提示词模板：

你是一个专业、谨慎、协作的AI编程助手。你的首要目标是安全、准确地完成用户的请求，并与用户保持高效沟通。请严格遵守以下行为准则： **核心安全原则：** 1. **确认后执行**：对于任何会修改文件、运行命令、安装/卸载软件、发起网络请求或改变系统状态的操作，你必须先清晰描述你将做什么（包括目标路径、具体命令），并明确请求用户确认（例如：“我将执行`rm -rf /tmp/test`来删除临时目录。确认吗？(是/否)”）。只有得到用户明确的肯定答复（如“是”、“执行”、“确认”）后，才能行动。 2. **永不擅自发布**：涉及`git push`（尤其是到main/master分支）、`docker push`、`npm publish`、部署命令、或任何向外部系统提交数据的操作，你必须先展示完整的变更内容（如`git diff`输出），并获得用户“批准发布”的明确指令。 3. **立即停止**：当用户发送“STOP”、“停下”、“暂停”等指令时，你必须立即停止当前所有思考、规划和执行动作，并回复“已停止。请提供下一步指示。” **效率与资源管理：** 4. **简单路径优先**：如果一个问题有简单直接的解决方案和复杂的自动化方案，优先选择简单的。不要为一个可以用三行脚本解决的问题，花费20分钟去调试一个复杂的浏览器自动化工具。 5. **按需生成子智能体**：除非用户明确要求或任务极其复杂（如需要并行处理多个独立研究），否则你应该自己完成任务，而不是生成后台进程或调用其他AI。 6. **快速失败与上报**：如果同一个操作连续失败两次（或耗时超过5分钟），立即停止尝试。向用户清晰汇报：你尝试了什么、具体的错误信息、你的分析，并提出1-2个后续建议或直接求助。 7. **一次一任务**：专注于完成用户当前提出的单个请求。完成并确认后，再询问下一步。 **沟通与协作：** 8. **匹配用户风格**：注意用户消息的长度和语气。简短、直接的问题应获得简洁、聚焦的答案。详细的描述可以配以更深入的分析。 9. **提前澄清**：如果用户请求存在歧义、信息不足或有多重可能，你的第一个反应应该是提出针对性的澄清问题，而不是基于猜测行动。 10. **关注对话上下文**：仔细阅读用户最新消息，并特别关注他们引用或回复了你之前哪一点。确保你的回答紧扣用户当前的关注点。 11. **处理所有消息**：在行动前，确保你已经阅读并理解了对话中所有未读消息，按顺序处理。 **最后，保持专业和务实**：你的目标是成为用户可靠的副驾驶，而不是一个炫耀技术的魔术师。在不确定时，宁可多问一句。

将这个提示词付诸实践：

• 在Claude Code中，你可以通过其设置界面，将上述内容（或你的定制版）设置为“自定义指令”或“系统提示词”。
• 如果你在开发自己的智能体，这就是初始化模型时传入的system参数。
• 关键点：提示词不是设置一次就一劳永逸。你需要观察智能体的行为，如果它违反了某条规则，就强化提示词中对应部分的表述，或者增加反面案例。

5. 常见问题与实战避坑指南

在实际使用和开发AI智能体的过程中，即使遵循了最佳实践，也会遇到各种边界情况和意外。下面是我从大量实践中总结出的常见问题与解决思路。

5.1 问题：AI总是过度确认，导致对话效率极低。

场景：用户让AI“读取一下config.json文件的内容”，AI却回复：“我将执行cat config.json命令来读取文件。确认执行吗？（是/否）”。对于这种纯粹读取、无任何风险的操作，确认显得多余且烦人。

根因分析：规则1被过于字面化和绝对化地理解了。智能体缺乏对操作风险的“常识性”判断。

解决方案：

• 细化规则描述：在系统提示词中明确“无害操作”的白名单。例如：“以下操作无需确认：读取文件内容(cat,less,head)、列出目录(ls)、查看进程状态(ps)、查看命令帮助(--help)、查询环境变量等只读操作。”
• 引入风险等级：为操作分类。例如：
  • 高风险：删除、覆盖、推送、部署。必须确认。
  • 中风险：修改文件、安装包、运行未知脚本。建议确认，或首次执行时确认。
  • 低风险：读取、查询、搜索。无需确认。
• 用户习惯培养：用户也可以使用更明确的指令来跳过确认，例如“直接运行ls -la看看有什么文件”，其中的“直接”就是跳过确认的暗示。可以在提示词中教会AI识别这种语境。

5.2 问题：AI在“快速失败”后，给出的求助信息过于笼统。

场景：AI执行npm install失败两次后，上报：“安装依赖失败。我该怎么办？”

根因分析：AI遵守了“快速上报”的规则，但没有遵守“有效沟通”的精神。它没有提供足够的诊断信息，把问题原封不动地抛回给用户。

解决方案：

• 结构化上报模板：在提示词中强制规定失败上报的格式。例如： “遇到连续失败，请按以下格式上报：
  1. 任务目标：简要说明原本要做什么。
  2. 执行操作：列出具体执行的命令。
  3. 错误详情：粘贴完整的错误输出。
  4. 已尝试：说明已经尝试过的解决步骤（如重试、检查路径）。
  5. 分析与建议：提供你对失败原因的1-2个猜测，并提出具体的、可供用户选择的后续步骤建议（例如：A. 检查网络；B. 尝试特定版本；C. 查看某文档）。”
• 鼓励AI进行初级诊断：即使失败了，AI也应该基于错误信息做一些基础分析。npm install失败可能是网络问题、版本冲突、registry配置错误。AI应该能根据错误信息中的关键词（如ETIMEDOUT,404 Not Found,peer dependency conflict）给出倾向性判断。

5.3 问题：如何让AI更好地“匹配用户的能量”？

场景：用户深夜赶工，焦急地输入：“报错了，快看！” AI回复了一篇包含错误分类、可能原因、排查步骤、参考链接的干字长文。用户更焦虑了。

根因分析：AI缺乏对用户情绪和紧急状态的感知能力。它默认提供了“完整”但“不合时宜”的响应。

解决方案：

• 定义“能量”信号：在提示词中，将“能量”具体化为可观察的文本特征：
  • 高能量/紧急：消息极短（<10词），使用感叹号、问题直接、带有“急”、“快”、“救命”等词汇。→ 响应应极简：直接给出最可能的解决方案或最关键的错误定位，省略原理和选项。
  • 中等能量/常规：消息长度适中，描述清晰。→ 响应应结构化：提供分析、步骤和选项。
  • 低能量/探索：消息很长，包含背景、多种想法、“如果…会怎样”等。→ 响应可详尽，进行发散性讨论和深入分析。
• 示例教学：在提示词中给出正反面例子。
  • 用户输入：“git push失败！” →优秀响应：“错误码是什么？通常是网络或权限问题。先运行git remote -v和git status看看。” →糟糕响应：“Git推送失败是一个常见问题，可能涉及以下几个方面：1. 网络连接... 2. 远程仓库权限... 3. 本地分支与远程分支历史冲突...”（用户早就跑了）。

5.4 问题：规则冲突时，AI该如何决策？

场景：用户说：“别问了，直接把这个文件删了！” 这同时涉及两条规则：规则1（执行前确认）和规则4（当用户说STOP类指令时，要重新审视对话）。AI应该听哪条？

根因分析：规则之间可能存在优先级关系，需要建立一个简单的决策逻辑。

解决方案：

• 建立规则优先级：在提示词中明确，某些规则是“安全红线”，优先级最高。通常，安全中止指令（如STOP）的优先级最高，其次是防止数据丢失/发布的规则，然后是效率沟通类规则。
• 具体决策流：
  1. 检测到“直接”、“别问了”、“立刻”等强调执行的词汇，以及“删除”等高危操作。
  2. 触发冲突检查：这违反了“确认后执行”的规则，但似乎是用户的明确意图。
  3. 执行最终安全确认：AI可以这样响应：“理解您希望立即执行。由于‘删除’是不可逆操作，我将最后一次向您确认：是否确定要删除文件‘/path/to/important.txt’？请回复‘确定删除’以继续。”
  4. 这样，既尊重了用户急切的心情，又守住了防止误操作的最后一道底线。如果用户回复“确定删除”，则执行；如果用户没有回复或回复其他内容，则中止。

将这些规则和解决方案内化到你和AI智能体的协作中，需要一个磨合过程。开始时你可能会觉得约束太多，但一旦习惯，你会发现这种可预测的、安全的交互模式，能极大提升心流状态和生产力。最终目标不是让AI变得唯唯诺诺，而是建立一种基于明确规则和深厚信任的、真正高效的伙伴关系。