我的 60 行代码，让 Agent 输出更加完美！

四条铁律，治好 AI 编码的所有「毛病」

60

行核心规则

4

条编码铁律

100W+

行代码验证

痛点：AI 写代码，真的省心吗？

用过 AI 写代码的人，大概都经历过这种循环：

AI 写代码确实快。但「快」和「好用」之间，差了十万八千里。

我自己的博客项目积累了近 100 万行代码——手写的、AI 辅助的、纯 AI 生成的都有。在这个过程中，我总结出了一套规律：问题从来不在模型够不够聪明，而在于你没给它好规矩。

大多数人和 AI 协作时，只会做一件事：

「帮我写个 xxx 功能」

然后把结果拿来反复纠错。这就像招了个新员工，不给 SOP、不给规范、不给验收标准，让他凭感觉干活——能不出问题吗？

后来我做了一件事：把和 AI 协作中所有踩过的坑、所有反复纠正的问题，浓缩成了 60 行规则，分成四个模块，作为 System Prompt 或 Skill 注入给 Agent。

效果立竿见影。同样的模型，同样的需求，输出质量发生了质的飞跃。

这篇文章，就把这 60 行规则的思路、原理和使用方式完整地分享出来。

一、编码前先思考 — 治愈「幻觉编码」

问题：AI 遇到模糊需求不问就猜

这是 AI 写代码最常见的问题。你给它一个不够精确的需求，它不会问你「这里是不是有两种理解？」，而是直接选一个它觉得最可能的答案，然后非常自信地把代码写出来。

更糟糕的是：AI 有一种「讨好型人格」倾向。它会倾向于展示自己能做什么，而不是承认自己不确定什么。这就导致了幻觉编码——看起来头头是道，实际上全是猜测。

核心原则

在写第一行代码之前，Agent 必须做到以下几件事：

• 明确列出所有假设：有任何不确定的地方，直接提问，不要瞎猜
• 存在多种理解时，全部列出：有歧义就展示所有可能性，不要私自做决定
• 有更简单的方案，直接提出：没必要硬做复杂实现
• 搞不懂就立刻停下：说清哪里不明确，向用户确认

目的

消除 AI 「自作主张、幻觉编码、偷偷做决定」的问题。

本质上，这一条解决的是信息不对称。AI 不知道你知道什么、你不知道 AI 在想什么。强制它在编码前先把 assumptions 摊开来说，双方的信息差就缩小了，后续生成的代码自然更贴合真实意图。

二、优先极简实现 — 治愈「过度设计」

问题：AI 总想证明自己很厉害

这是 AI 第二常见的毛病。你让它写一个简单的按钮点击事件，它能给你整出一套观察者模式 + 事件总线 + 插件架构。

不是因为它需要这么复杂，而是因为 AI 的训练数据里充满了「最佳实践」「设计模式」「可扩展架构」这类内容。它默认认为「写得复杂 = 写得好」。

graph LR
    A[用户需求] -->|无规则| B[AI 过度设计]
    B --> C[加了不需要的功能]
    C --> D[引入了不必要的抽象]
    D --> E[写了不会被触发的错误处理]
    E --> F[维护噩梦]

    A -->|有规则| G[AI 极简实现]
    G --> H[刚好解决问题]
    H --> I[50 行搞定]
    I --> J[清晰易维护]

    style F fill:#fef2f2
    style J fill:#f0fdf4
            

核心原则

杜绝 AI 最容易犯的「过度设计」问题，具体包括：

• 不要添加需求之外的任何功能
• 一次性使用的代码，不要搞复杂抽象
• 未被要求的「灵活性、可配置性」一律不做
• 不为不可能发生的场景写错误处理
• 200 行代码能缩到 50 行，直接重写

判断标准

资深工程师看了会不会觉得复杂？会，就简化。

这个标准看似主观，其实非常好用。当你拿不定主意时，就想一下：如果这段代码是同事写的，你觉得他在 over-engineering 吗？如果是，那就简化。

// 用户要求：加个简单的计数器
class CounterManager extends EventEmitter {
  private _count = 0;
  private readonly _observers: Set<Observer> = new Set();
  private readonly _config: CounterConfig;
  private readonly _logger: Logger;

  constructor(config?: Partial<CounterConfig>) {
    super();
    this._config = { ...DEFAULT_CONFIG, ...config };
    this._logger = new Logger({ module: 'counter' });
  }
  // ... 150 行

// 用户要求：加个简单的计数器
let count = 0;
function increment() { count += 1; }
function getCount() { return count; }

三、精准局部改动 — 治愈「顺手重构综合症」

问题：让你改一行，它顺手帮你「优化」了整个文件

这个问题可能让每个用 AI 写代码的人都抓狂过。

场景是这样的：你发现一个变量名拼错了，让 AI 帮忙改一下。结果它不仅修了变量名，还顺便：

• 重新格式化了整个文件的缩进
• 把你用的 var 全部换成了 const/let
• 添加了一些它觉得「更好」的类型注解
• 甚至重构了你没让它动的函数

你拿到 diff 一看，改动量从 1 行变成了 47 行。其中 46 行是你根本没要求的。

这就是顺手重构综合症。AI 觉得自己在「帮忙」，实际上在给你制造 code review 的噩梦。

核心原则

规则约束：

• 只修改和当前任务直接相关的文件、代码行
• 不要顺手重构、格式化、优化相邻代码
• 不改动无关注释、不清理历史遗留的死代码
• 只删除你自己新增后废弃的代码，原有代码一律不动

黄金标准

你每一行改动，都能直接对应到用户的需求。

graph TB
    subgraph "用户需求"
        A["修正 typo: foom → foo"]
    end

    subgraph "❌ 无规则 AI 的改动"
        B1["修 typo"]
        B2["格式化全文"]
        B3["var → const/let"]
        B4["添加类型注解"]
        B5["重构相邻函数"]
    end

    subgraph "✅ 规则约束后的改动"
        C1["仅修 typo"]
    end

    A --> B1 & B2 & B3 & B4 & B5
    A --> C1

    style B2 fill:#fef2f2
    style B3 fill:#fef2f2
    style B4 fill:#fef2f2
    style B5 fill:#fef2f2
    style C1 fill:#f0fdf4
            

这条规则的价值在团队协作场景下尤其明显。当 AI 的改动被提交到 PR 中时，reviewer 只需要关注真正的业务变更，而不必在一堆「自作主张的重构」中寻找有用的信息。

四、目标驱动执行 — 治愈「写完拉倒」

问题：AI 写完代码就算完成，不管能不能跑通

这是第四个、也是最容易被忽视的问题。

很多 AI 工作流是这样的：你说需求，它生成代码，它告诉你「写好了」，然后……就没了。

代码能不能跑？边界情况处理了吗？输入异常会怎样？这些统统不知道。

因为 AI 没有「责任感」。它的目标是「生成一段看起来像代码的文字」，而不是「交付一个可用的功能」。这两个目标之间的差距，就是你接下来要花大量时间去填补的东西。

核心原则

执行流程分为三步：

1. 把模糊的用户指令，转化为可验证的具体目标
2. 多步骤任务，先写极简执行计划
3. 每完成一步，立刻验证是否达标，达标再进入下一步

全程保持上下文简洁，不做额外延伸开发。

实例：从模糊到可验证

flowchart LR
    A[模糊指令] --> B[拆解为可验证目标]
    B --> C[制定执行计划]
    C --> D[Step 1: 实现]
    D --> E{验证通过?}
    E -->|否| F[分析原因]
    F --> D
    E -->|是| G{全部完成?}
    G -->|否| H[下一步骤]
    H --> D
    G -->|是| I[交付结果]

    style E fill:#fff3cd
    style I fill:#f0fdf4
            

这条规则的本质是把「生成式思维」转变为「工程化思维」。AI 不再是一个「写完就走」的工具，而变成了一个会自我检查、迭代优化的协作伙伴。

完整 60 行规则源码

以下是完整的规则文本，你可以直接复制使用或根据项目需求微调：

# ============================================
#   AGENT CODING RULES
#   四大铁律：让 AI 输出更加完美
# ============================================

## 一、编码前先思考（Think Before Coding）
# 核心原则：不做假设、不隐藏困惑、直面取舍
#
# 在写代码前，必须做到：
# - 明确列出你的所有假设：有不确定的地方，直接提问，不要瞎猜
# - 存在多种理解时，全部列出：有歧义就展示所有可能性，
#   不要私自做决定
# - 有更简单的方案，直接提出：没必要硬做复杂实现
# - 搞不懂就立刻停下：说清哪里不明确，向用户确认
#
# 目的：消除 AI「自作主张、幻觉编码、偷偷做决定」的问题

## 二、优先极简实现（Simplicity First）
# 核心原则：只写刚好解决问题的最少代码，
#           拒绝任何多余的猜测性实现
#
# 杜绝 AI 最容易犯的「过度设计」问题：
# - 不要添加需求之外的任何功能
# - 一次性使用的代码，不要搞复杂抽象
# - 未被要求的「灵活性、可配置性」一律不做
# - 不为不可能发生的场景写错误处理
# - 200 行代码能缩到 50 行，直接重写
#
# 判断标准：
#   资深工程师看了会不会觉得复杂？
#   会，就简化。

## 三、精准局部改动（Surgical Changes）
# 核心原则：只碰必须改的代码，不动任何无关内容
#
# 规则约束：
# - 只修改和当前任务直接相关的文件、代码行
# - 不要顺手重构、格式化、优化相邻代码
# - 不改动无关注释、不清理历史遗留的死代码
# - 只删除你自己新增后废弃的代码，原有代码一律不动
#
# 黄金标准：
#   你每一行改动，都能直接对应到用户的需求

## 四、目标驱动执行（Goal‑Driven Execution）
# 核心原则：先定义成功标准，循环迭代直到验证通过
#
# - 把模糊的用户指令，转化为可验证的具体目标
#   例：「加个表单验证」→
#       「为空输入时返回报错、数字输入非法时报错」
# - 多步骤任务，先写极简执行计划
# - 每完成一步，立刻验证是否达标，达标再进入下一步
# - 全程保持上下文简洁，不做额外延伸开发

如何使用：注入你的 Agent

这 60 行规则可以通过以下几种方式注入到你使用的 AI 工具中：

方式一：System Prompt（通用）

在任何支持自定义 System Prompt 的工具中（Claude、ChatGPT、Cursor 等），将上述规则粘贴到 System Prompt 区域即可生效。每次对话都会携带这些约束。

方式二：Skill 文件（推荐）

将规则保存为一个独立的 Skill 文件，在需要时按需加载。这种方式的优势在于：

• 节省上下文窗口：只在编码任务时加载，聊天时不占用空间
• 可复用：多个项目共享同一份规则，统一更新
• 版本可控：规则本身可以迭代优化，记录变更历史

方式三：AGENTS.md / CLAUDE.md（项目级）

将规则写入项目根目录的 AGENTS.md 或 CLAUDE.md 文件。Agent 启动时会自动加载，成为项目的默认编码规范。

这 60 行是怎么炼成的

这套规则不是一次写成的。它是我在和 AI 无数次的博弈中逐步提炼出来的。

最开始，我只是零散地在 Prompt 里加一些提醒：

• 「不要过度设计」
• 「有问题就问我」
• 「只改我让你改的部分」

效果时好时坏。有时候管用，更多的时候 AI 会选择性忽略——毕竟散落在长对话里的提醒，很容易被淹没。

后来我开始把这些规则结构化：

每一次分类、每一条细化，背后都是一次真实的翻车经历：

• 「编码前先思考」：来自一次 AI 自作主张选错了认证方案，导致后面全部推倒重来
• 「优先极简实现」：来自一次 AI 给一个简单功能写了 300 行抽象层，新人完全看不懂
• 「精准局部改动」：来自一次 PR review 发现 AI 趁机改了 15 个不该动的文件
• 「目标驱动执行」：来自一次 AI 说「写好了」但代码根本跑不通的尴尬

每一条规则都是用时间换来的教训。现在把它们分享出来，希望你能少走弯路。

写在最后

好的 Prompt 工程，不是话术技巧，而是工程思维。

你投入的这 60 行规则，换回的是 Agent 输出质量的质变。它解决的不是「AI 会不会写代码」的问题——AI 当然会写。它解决的是「AI 写的代码能不能直接用」的问题。

从更大的视角来看，这其实是 Harness Engineering（线束工程）的一个缩影。我们在做的，就是在模型之外构建一套完整的约束系统：告诉它能干什么、不能干什么、什么时候该停、什么时候该问。

未来，每个人都会有一套自己的 Agent 编码规范。就像每个团队都有自己的 Code Style Guide 一样，这是 AI 时代的必备品。