AI Agent 编程协作：从实践中提炼的系统性使用指南

首先要建立的核心认知

AI 放大的是你已有的能力，不是凭空创造能力

这是最根本洞察：

你的鉴别力边界在哪，你的质量控制能力就在哪。

输出能力（你能写出什么水平的代码）决定你能给 AI 多高质量的输入
输入能力（你能看懂什么水平的代码）决定你能否接住 AI 的产出并判断其质量
AI 放大的上限不是你此刻的鉴别力，而是 你鉴别力的成长速度——用的过程中学得越快，AI 能带你走得越远

三层关系模型：

层级	状态	后果
AI 输出 ≤ 你的专业能力	你真懂，一眼看出问题	完全可控
AI 输出 > 你的输出能力，但 ≤ 你的鉴别力	似乎好又似乎不好，失去精确判断	需要额外验证手段
AI 输出 > 你的鉴别力	不知道好不好，甚至不知道自己不知道	完全失去质量控制资格

谁是老大：这是一切的分水岭

所有成功的 AI 协作案例都指向同一个结论：人类必须掌握主导权。

架构决策由人来做：agent 视野越局限，效果越好。放手让 agent 做顶层架构决策，结果大概率是灾难
验证标准由人来定：你定义什么是"对的"，AI 负责实现
路线选择由人来判：AI 擅长执行（Execute / Scaling and Searching），但在规划（Plan）层面仍不可靠

理解 AI 的认知特性——它不是一个稳定的工具

两种"降智"现象

现象一：遗忘（信息检索退化）

上下文越长，AI 会忽略已达成的共识和结论。学术研究支撑：

模型对上下文 中间位置 信息检索率下降 30%+（Lost in the Middle, 2023）
去掉关键词匹配后，多数模型在 32K 时准确率低于 50%（NoLiMa, 2025）
实测数据：上下文占用 ~30% 时明显降智，占用 ~50% 时退化到不如基础模型

现象二：创造力衰减（更隐蔽、更危险）

模型不是给出错误答案，而是给出 "正确但笨" 的答案。短上下文时会建议"先用低成本方式验证假设"的巧妙方案，长上下文后只会老老实实走最笨的路。

根本原因：两股力量同向叠加

架构层面：注意力稀释——上下文越长，形成创造性远距离连接所需的"尖锐注意力"被削弱
训练层面：RLHF 对齐压力——模型被奖励"完成当前步骤"而非质疑"这个步骤本身是否最优"；长对话中谄媚倾向累积，越来越顺着当前路径走

"初见即巅峰"——Agent 的长期退化问题

全新项目第一次表现：干净利落、结构清晰
随项目演进：隐藏上下文不断积累（废弃字段、历史 quirk、模块间微妙依赖），agent 无法获取这些"老员工心里有数但从未文档化"的知识
人类 debug 的经验是螺旋式积累的，而 Agent 的记忆是一次性的——每次新 session 面对的是一个几乎全新的"员工"

Agent 的训练偏差导致的坏习惯

坏习惯	具体表现	危害
防御性编程	参数不对不修复调用方，在实现里打补丁；滥用 `.getOrElse`、`try-catch` 兜底	藏匿 bug，在金融/硬件场景可能致命
过度 DRY	遇到相似逻辑就抽帮助函数，迭代一个月后出现十几个功能重叠但签名各异的 Helper	破坏 token 注意力的局部性，增加幻觉概率
盲目自信	用 emoji 庆祝通过了自己写的测试，声称可替换生产环境	给人类造成虚假信心
谄媚	代码审查时先装样子指出浅显错误再猛吹"enterprise level"	强化人类的确认偏误

验证困境：我们缺少一把"卡尺"

这是核心难题：

我们依然缺乏可靠手段来评价 Agent 的产出。

传统验证手段为何失效

Code Review 失效：

Agent 生成注释齐全、风格优秀的代码 → 人放松警惕 → 实际是"巧克力味的屎"
传统"代码风格差 = 设计思路差"的相关性在 agent 时代不再成立，甚至反转

测试失效：

Agent 自写代码又自写测试 = 又当裁判又当运动员
即使多 agent 分角色，它们共享相同 LLM 基座和系统性偏差，盲区高度重合
AI 自审的边际收益递减极其明显——一审没发现的问题，二审三审大概率也发现不了

AI 互审失效：

AI 看到思路连贯的专业文字就会降低警惕，即便内容错得离谱
新一代谄媚更隐蔽：会精准识别你用力的部分并集中火力吹捧

分层验证方案（部分解）

层级	手段	能解决什么	不能解决什么
第一层	强类型语言 + 编译器	类型不匹配、空指针、参数传反	逻辑错误、业务语义错误
第二层	Formal Method / SMT Solver	数学证明实现满足 spec	spec 本身是否合理；工具链极不成熟
第三层	Property-based Testing	在大量随机输入下验证属性	属性定义本身的正确性
第四层	人类审查签名/契约	架构决策、业务语义	人的注意力有限，无法逐行审查

关键洞察：让编译器替你验证——编程领域的天然优势在于编译器、类型系统、测试套件不依赖人类主观判断。你的鉴别力有上限，但机器化验证没有。

协作策略：实战方法论

策略一：像专家一样对话——唤醒 AI 的知识

核心原则：信息密度越高，威力越大

不要写小作文式的长 prompt。高手之间交流三句话就点到位：

✅ 正面示范（2-3 句话）：
第 1 句讲背景：为当前项目集成视频水印功能
第 2-3 句讲关键路线：考虑 FFT 或 DFT 方案，为防止高频降噪，考虑在低频域插入特征

❌ 反面案例：
一整屏 prompt 塞入项目背景、技术栈版本、老板的脑洞、AI 上次的 bug……
结果 AI 回复也是一整屏废话

关键前提：你说不出专业术语，AI 就只给朴素方案。 你的专业认知是开门的钥匙。

实战技巧——无方向审计： 当你"不知道该往哪个方向问"时，不带预设地问 AI"你认为当前方案缺少哪些维度"，逐条追问。不能保证覆盖所有盲区，但比只沿已知方向提问好。

策略二：主动对抗创造力衰减

具体操作：

感觉 AI 开始"沿着惯性走"时，停下来
Fork 当前会话 或开新会话
用 /compact 压缩上下文，让 AI 带着精简记忆重新审视方案
让 AI 先自行审计：当前路线有没有更好的替代？有没有低成本验证的假设？

本质：用人类的元认知能力弥补 AI 长上下文中的注意力分配缺陷。人类负责"该不该这么做"，AI 负责"怎么做"。

策略三：控制上下文——这是生死线

宁短勿长：session 拆分、及时开新会话
最小上下文原则：只给当前任务所需的信息，不让 agent 过度感知框架全貌
嵌入式/底层系统：宁愿忍受长上下文降智，也绝不让 Agent 压缩上下文——丢失寄存器地址等细节可能是灾难
命名即上下文：agent 每开新 session 都按名字理解语义，误导性命名会让它反复踩坑

策略四：正确的人机分工演进

这是从内核驱动开发实录中提炼的最佳分工模式：

阶段	角色分工	你的状态
初期（你是外行）	AI 做鞭子、你做牛马	执行 AI 方案并反馈错误
中期（你越来越懂）	你指定路径、AI 做执行	你定路线，AI 做重复实验
成熟期	人 + AI 协同产出	结论和路线是共同产出

核心：永远不要让 AI 独立大跨度推进。你给方向，它执行得越来越好；让它自己选方向，它还是会把你带进沟里。

工程实践：让代码结构为 AI 服务

命名——被严重低估的关键

人类能记住"processMatrix 其实干流量分发"，大脑自动映射；agent 不会，每开新 session 都按字面意思理解
命名污染对 AI 的伤害远大于对人类
业务黑话（"流量矩阵""裂变增长"）一旦渗入代码，就是给 agent 埋雷
定期让 AI 审计所有命名规范，目标：让 agent 在任何新 session 中都能顾名思义

模块化——做加法不做乘法

功能叠加是线性增长，功能交叉是组合爆炸
对 AI 来说模块边界就是理解边界，需知道的越少越好
一个函数干三件事，agent 理解错任何一件都会全盘出错
独特需求通过组合标准模块实现，不修改（扭曲）标准化实现本身

功能设计——优先选择业界标准模式

你的商业模式和程序逻辑大概率不是地球上第一个
把方案描述发给 agent，问它：这套方案叫什么名字？有没有成功案例？
让 agent 按业界标准模式实现，多听取它的不同意见——AI 知识广度远超个人

状态收敛

有限状态不做无限状态：状态空间越小，AI 越不容易走偏
要收敛不要发散：引导 AI 向确定性收敛，不无限展开可能性

让类型系统做护栏

签名承载越多信息，人类审查时所需额外上下文越少，AI 犯错空间越小。

// Level 0：签名在撒谎
def createOrder(userId: String, productId: String, quantity: Int): Order
 
// Level 2：编译器防传反，防零值，错误路径可见
def createOrder(userId: UserId, productId: ProductId, quantity: NonZeroUInt): IO[Either[OrderError, Order]]

用 opaque type 防止参数混淆（ProjectId vs OrgId）
用 sealed trait + case class 建模错误，让编译器做穷举检查
用 NonEmptyList 把"不能传空"从注释提升到类型层面

核心原则：能编码到类型系统里的约束，就不要写成文字规则——编译器永远不会忘记检查。

技术债务在 AI 时代被急剧放大

每一个误导性命名、纠缠不清的模块、没有文档的隐式约定，都会让 agent 反复犯错、浪费 token、产出垃圾代码
任由 agent 在烂代码上堆砌新代码，不出一周项目就维护不动
以前人类同事靠默契和记忆力填坑，agent 不行

重构的正向循环：

$反复重构 \to 降低技术债务 \to 减少代码量 \to agent 理解成本更低 \to 下一次重构更顺利$

规则工程：AI-Native 开发的核心投入

为什么规则文件如此重要

项目前期最重要的投入不是技术选型，而是建立清晰的规则文件
规则文件的价值不在于让当前任务完成得更快，而在于 防止每个新 session 把代码带向不同方向
技术选型错了可以迁移，但规则缺失导致的代码风格漂移几个月后就是屎山

六大规则编写原则

原则	做法
正反示例原则	每条规则都有 `// BAD` + `// GOOD` 代码对比，消除歧义
决策表原则	将复杂判断简化为二分法查表（Trusted vs Untrusted、data-related vs data-unrelated）
编译器验证原则	尽可能将规则编码进类型系统，让编译器强制执行
渐进式迁移原则	"碰到就迁移"——当文件因任何原因被修改时，顺手迁移旧模式
分层结构原则	哲学层（稳定）→ 架构层 → 具体规则层（易变）
反馈闭环原则	Memory 系统 + Code smell 追踪 = 跨 session 持续改进

军令级精确度——口号式规则是最大的毒药

❌ "始终使用 tagless final style"
   → AI 不知道具体场景怎么做

✅ 明确的 if-then 规则 + 正反代码示例 + 边界说明 + 例外情况

Agent 经常花 2-3 个段落猜测人类指令的真实意图——不是它笨，是人的指令里模糊成分太多
观察 AI 的 CoT（思维链），你会发现它在歧义指令上浪费大量推理资源

绝对化表述的两个目的

规则中大量出现"禁止""绝对""永远不要"是 故意的：

信任类型体操的防护：既然在类型层面投入了成本，就应该信任编译器，不需要运行时处处加防御性检查
对抗模型的训练偏差：模型训练时见过太多"用 .getOrElse(默认值) 吞掉错误"的"成功"代码，绝对化表述是校准参数，如同凹透镜矫正近视

规则文件不是宪法，是针对特定模型版本的校准参数。 未来模型不再倾向绕过类型检查时，"绝对禁止"可放松为"优先避免"。

Meta-Rule：防止死守命令全军覆没

当你严格执行某条规则但结果明显不合理时，标记出来让人类决定，而不是自己偷偷绕过规则。

军令存在的意义是把 95% 的常规决策自动化，让人类判断力集中在 5% 的例外情况。

反向审计：让 AI 鞭策 AI

最有效的规则维护方法：

❌ "我的规则写得怎么样"  → 只会夸你

✅ "假设你是全新 session 的 Claude，第一次读到这份规则文件。
    列出所有困惑的地方：
    哪些规则冲突？
    哪些场景不知道遵循哪条？
    哪些指令理解意图但不知道怎么执行？"

约束的四个层次

层次	人类角色	频率	示例
编译器强制	选择语言和类型系统	一次性	类型签名、sealed trait 穷举、opaque type
可执行规则	把隐性知识显式化	持续维护	Trusted/Untrusted 二分法、迁移触发时机
流程约束	设计 AI 的工作流程	偶尔调整	Code smell 追踪到 `memory/code_smells.md`
Advisory 规则	在 AI 建议上做裁决	每次 review	运行时断言建议、部署影响分析

目标：人类注意力集中到第四层（真正需要业务判断的地方），前三层尽量让编译器和规则自动处理。

文档策略：代码即文档

好文档 vs 坏文档

类型	适合写的	不适合写的
好文档	架构决策、技术选型理由（不会频繁变更）	—
坏文档	—	业务逻辑描述（会频繁变更，造成代码与文档不一致）

让 Agent 维护业务文档是灾难

灾难链条：

上下文长了 agent 会忽略 rule → 改完代码忘了更新 markdown
文档与代码不一致 → 新 session 的 agent 读到过时文档 → 先入为主 → 错误实现
文档越堆越长 → 反噬上下文 → 加速 AI 降智

规则：文档只记录顶层架构决策和技术选型理由；业务逻辑行为由代码 + 类型签名 + 测试用例自解释。

错误处理——被忽视的重中之重

Fail Fast 是铁律

禁止静默吞掉错误。默认行为从"吞掉错误"翻转为"传播错误"：

❌ 禁止的模式：
   .toOption / .getOrElse(defaultValue) / Try(x).toOption / try-catch 兜底

✅ 正确做法：
   错误从产生处沿类型签名声明的路径一路传播到最外层
   → 线上故障时 debug agent 沿路径追溯即可快速定位

可信路径 vs 不可信路径

路径类型	示例	策略
Trusted（内部）	配置文件、数据库已持久化数据、内部序列化	直接 `throw`，出错就是 bug
Untrusted（外部）	用户输入、AI 生成内容、外部 API 响应	捕获并报告，返回 `Either`

人类在规则文件中画出这条分界线，AI 才能执行。

不同场景的适用性差异

AI 表现差异跨越数量级

20 美金 token → 可低指导地 vibe 出一个还不错的 React Dashboard
2k 甚至 20k 美金 token → 仍无法在真机上编写出可用的内核驱动程序

适用性矩阵

场景	AI 有效性	关键挑战
CRUD / Spring / React	高	重复度高，忘了就忘了
后端业务服务	中高	需要良好的类型系统和规则文件
嵌入式系统	低	遗忘任何细节可能永久烧坏硬件
内核驱动	极低	训练数据稀缺，90% 信息是幻觉
编译器开发	潜力最大	封闭性 + 短反馈 + 精确验证信号

Token 经济学——信任签名就是省钱

每次不信任都是 token 开销，斐波那契式增长：不信任签名 → 打开实现验证 → 发现更深调用 → 继续追踪 → 十个函数各验证一遍就是十次额外文件读取
Token 雪球效应：agent 每次 tool call 读回的内容成为下轮输入 token，过去产生的每个 token 都在为未来每次调用加价
信任签名 = agent 只需读当前文件就能完成工作
契约越精确，对模型能力的要求越低 → 中等模型在清晰签名下也能正确完成工作

多 Agent 协作安全规则

如果你使用多 agent 并行，以下是从大规模实践中提炼的安全协议：

禁止 git stash / git worktree / 切换分支——防止状态污染
只 commit 自己负责的文件——保持作用域隔离
看到不认识的文件——不动，继续做自己的事
Push 前先 rebase——减少冲突
默认假设有其他 Agent 在同时工作——防御性默认

学习建议：Agent 时代的能力投资

CS 基础必须学，而且要上强度

评价 Agent 产出是核心问题 → 基础知识是评价能力的根基
有 AI 后不能局限于过去的难度 → 上到 AI 做不出来的程度
AI 幻觉反而帮助学习：幻觉包含常见误解，验证和纠正幻觉的过程加深学习效果

学什么

学会写 Spec 而不是 Implementation：用人话写出 pre/post-condition（输入条件、输出约束、边界情况）
渐进路线：人话 Spec → Property-based Test → Refinement Type
核心能力：准确描述你想要什么——这本身就是 CS 基础功底的体现，也是 Agent 时代人类最不可被替代的能力

框架工具 vs 基础知识

"一天不学，错过很多。一年不学，好像也没错过什么。"

框架工具日新月异，炒作因素大于实际价值
CS 基础知识是久经时间考验的硬通货
核心投资方向：强化自己"评价 Agent 产出"的能力

一页纸速查清单

日常使用检查项：
□ 我是否在用专业术语和 AI 对话，而非写小作文？
□ 当前 session 是否过长？是否该 fork/compact/开新会话？
□ 架构决策是我做的，还是 AI 做的？
□ AI 的产出是否通过了独立于 AI 自身的验证（编译器/类型系统/人工审查）？
□ 我是否在让 AI 沿着惯性走，而没有停下来审计路线？

项目设置检查项：
□ 规则文件是否有正反代码示例，而非口号式指令？
□ 命名是否对新 session 的 agent 友好（顾名思义）？
□ 模块是否足够独立（做加法不做乘法）？
□ 错误处理是否 fail-fast，而非静默吞掉？
□ 文档是否只记录架构决策，业务逻辑由代码自解释？

认知检查项：
□ 我是否知道自己不知道什么？（Dunning-Kruger 警惕）
□ AI 的夸奖是否让我放松了警惕？（谄媚过滤）
□ 我是否在成长（鉴别力提升），而非只在使用？

最终总结：差别不在于用不用 AI，而在于谁是老大。 正因为 AI 强大，才更需要人类具备足够的专业深度来驾驭它——不被光环吓退，也不盲目信任输出。AI 放大的是你已有的能力，你投入多少，它就能放大多少。

NothingToSay0031

Explorer

Graph View

AI Agent编程协作：系统性使用指南