一个 Claude Code + Codex 用了 万多刀的人，对于 AI 的理解。

这篇不是工具教程，网上教你用 AI 的文章和视频已经太多了。我想说的是烧了这么多钱和时间之后我真正想明白的几件事。不管你是写代码的、做产品的、还是完全不碰技术的人，这些东西都跟你有关。

一、我的方法

从 Copilot 出世开始。tab 补全代码，那时候觉得这东西挺好，省了不少打字的时间。

接下来是写 plan，让 AI 按计划执行。再到 agent 模式，让它自己探索、自己决策、自己写代码。老实说，再是 MCP，把各种工具连起来让 AI 能调用外部能力。接下来是 skill，把经验封装成可复用的能力包。再到 multi-agent，多个 AI 并行协作。最终到了现在的 harness，让 AI 军团的协作更加流畅可控。

痛点：投入大量资金后仍然看不到明确回报； 项目进度被无形的“AI 记忆压缩”拖慢。

万刀花在哪了？可见的有 个项目、个小工具、套 multi-agent skill、套 harness kit还有很多不可统计的地方。

Harness 要解决什么？我把它拆成四层：

• 能力层AI 能用什么规则、什么工具
• 连接层程序之间怎么连
• 建立层想法如何按规范产出
• 管控层产出如何追踪和审计

这四层不管你是做项目还是做业务，都是通用的。区别只是每一层填什么内容。

不是模型多聪明，而是测试质量决定一切、为 AI 的认知特点设计执行环境、用 CI 防止回退。本质上就是在做 harness 这件事。

OpenAI 也发了一篇《Build AI-Native Engineering Team》，主要框架是把软件开发的每个阶段拆成三层：哪些委派给 AI、哪些人来审查、哪些人必须拥有。说白了就是在每个环节定义清楚人和 AI 的边界——这不就是 harness 的管控层在干的事吗？不过，

Claude Code 后面上线了 Agent Teams——一个 leader 协调多个 teammate。共享任务列表，互相通信，各自在独立上下文里干活。HN 上讨论很热，有人搞了 个 agent 跑 阶段 Kanban。也有人说“这不是在模拟人类组织架构吗”。

痛点：Plan 质量低导致多 agent 并行时产生大量垃圾代码；缺乏统一治理导致团队协作混乱。

二、踩过最大的坑

Pain point: 盲目信任 AI 的记忆与上下文，以为它会自动纠正错误。

一开始你会觉得 AI 记住了你的偏好、你的项目结构、你的决策逻辑，它确实在短期内表现得很好。但越往后走越偏——它开始把你的规则和它自己的推断混在一起。产出的东西半对半不对，你还不好发现问题在哪。说起来，

Pain point: 上下文压缩导致历史信息被遗忘。三天前设定的约束已经被丢弃，却仍然被当作有效前提使用。

最致命的是上下文压缩。其实，对话一旦变长，程序会压缩上下文，被忘掉的东西比你想象的多。更糟糕的是你带入新的上下文试图补救，它也没办法做准确的——因为压缩后的记忆里已经有脏东西了新信息建立在错误的地基上。

Pain point: 错误信息沉淀后难以定位根源——究竟是输入结构不完整还是边界定义不清？

# 关键教训：

• 不要信任 AI 的记忆，要信任你给它的结构。
• 所有关键信息必须显式地写在执行环境里不能靠对话历史。
• 有限。记忆会失真，但写下来的东西不会失真。不过，

三、用好 AI 的主要：输入、决策、环境

Pain point: 大多数团队把精力放在美化 prompt 或堆砌 skill。而忽视输入结构化和关键决策点介入，从而导致效率提高有限甚至出现倒退。

# 基础要素：

1. 基座模型能力决定上限

If base model is weak,any overlay becomes a “空中楼阁”。老实说，选择高质量模型是第一步先，也是唯一能让后续工作产生价值的前提。

2. 高质量输入 ≠ 好 prompt。而是完整执行环境

• A. 程序边界
• B. 业务上下文
• C. 红线/合规要求
• D. 验收标准与证据要求
• E. 数据来源与可信度
• * Pain point: 缺少结构化输入导致AI自行填补空白，引发错误决策。

3. 高质量决策 = 在关键节点介入而非全程盯梢

• 方向是否正确
• 边界是否被越界
• 产出能否
• 风险是否可控

Pain point: 团队往往在所有细节上“微管理”，结果浪费人力且难以发挥AI潜能；相反，在关键节点失去控制则会产生灾难性错误。

四、AI 提效一定是自上而下的

• Pain point: 单个员工偷偷使用工具提高一点速度，却无法形成组织级别效益； 说起来，没有统一治理的话，“碎片化提效”只会导致技术债务增加。

A I 提效本质是让数据、经验与知识在不同岗位之间重新流转协作。这属于基建，是业务协作基础。它必须由老板或管理者牵头推动——不是因为他们更懂 AI。而是因为只有高层才能改动协作结构，而非个人工作方式。

• Pain point: 大多数公司业务复杂度不足以支撑结构化描述，一味强推 AI 会导致旧程序迁移成本飙升。怎么说呢，

五、只需要两种人。其余都会被淘汰

• Pain point: 很多岗位只负责“传话筒”，缺乏业务深度或技术实现能力，在AI时代这些角色将被边缘化甚至淘汰。

"业务专业。就是 AI 的沙盒环境专业"
对业务非常了解，知道哪些流程可以 A I 化还有哪些不能碰，还能抽取经验沉淀为 skill。如果不了解业务，就不知道该给 AI 什么边界。

对 A I 开发非常熟悉，可把业务知识转化为可运行 / 可复用 / 可验证程序。他们直接决定落地效率，

 Pain Point:: 没有业务背景就只能靠猜测搭框架，一遍遍返工浪费时间。说起来，Pain Point:: 团队内部角色错配。使得“skill”无法复用或传播。

六、不必给 Agent 套岗位标签

目前岗位协同 Agent 很火。有需求就叫我的机器人去办事。这种思路类似公司内部 HR 给人的职称标签，只但是对象换成了 Bot。但我越来越觉得，不该给 Agent 限制岗位，同理公司也不应限制人。

岗位本质是一种组织分配责任的方法，用于 HR 管理还有职责归属。而 Agent 不需要这种外壳，应该直接对产出负责。

Agent 应该能自行发现并建立所需资源，无需人工干预这些细枝末节。如果你限制 Agent，就等于限制自己的创新空间。

真正决定你使用 AI 程度的是对其本质理解程度。说到请先弄清楚，我到底想让它完成什么？ 我们要避免把“Title”当成评估标准，而应该关注结果本身 .

七 、以后方向展望

当前我们建立 Harness。本质仍然是在人为制定规则 —— 边界定义 / 合约维护 / 验证门禁，这是最务实却也是过渡性的做法。但长期来看，仅靠自己从零搭建 Agent Harness 已经没有太大价值。模型升级会让大量规则瞬间失效，而且迭代速度远快于小团队跟进。

更具价值的是基于成熟 Harness 为垂直领域提供方案：

MCP 已解决连接问题 —— 知道可以调用哪些外部工具 Skill 已解决领域知识 —— 把领域经验抽象成可执行模块 但仍缺乏完整落地链路。需要：
将老工作流改造成 A I 原生 Agent 流程
• 在人机交互环节重新设计 UI/UX
• 垂直领域高质量数据整理
• 把专家判断方法转化为 A I 可执行流程

 最终目标不是抢占技术壁垒，而是在特定领域里跑通全链路，

形成业务理解壁垒，这才是真正竞争力。

接下来可能出现几个趋势：

#1 : 模型继续变聪明 – 推理 / 长上下文 / 多模态提高 → 人工约束需求下降 #2 : 更细粒度记忆 – 每次执行细节都被记录 → Harness 从静态规则演进为动态自学习约束 #3 : 垂直领域自动化 – 从需求到交付全链路自动化将成为爆发点 #4 : 人类角色从「定义边界」转向「定义方向」 – 从 Human‑in‑‑Loop 到 Human‑on‑‑Loop 再到 Human‑over‑‑Loop

但现实依旧如此：不给它明确边界，它就没有方向。

---

即便大家都喊「AI 提效」。真正能够持续获利的是那些衍生品赚钱方式，门槛低但窗口期短。主要不是「能赚多久」,而是在过程中沉淀下来的五大资产：

I 能力 – 将模糊需求拆解并形成可执行方案、 程序设计与实现能力；#II 思考 – 对所在领域深刻洞察及框架；#III 认知 – 判断何时交付给 A I 、何时亲自介入；#IV 审美 – 对产出质量标准及好坏判定；#V 执行力 – 快速落地并交付成果；

如果您对此感兴趣，可参考以下资源：

<> <>

• Anthropic 并行 Claude 团队建立 C 编译器 — 多 agent 并行·万行代码·万刀经验分享

---

：应作如是观

AI 是放大镜；新闻教程只是催化剂，你才是真正主要。怎么说呢，当 A I 放大你的执行力时你对生活、 世界好奇心还有面对问题时韧性才是真正价值所在。

《金刚经》云这方面，

网站不同、人不同。但唯一永恒的是：你的想法仍在你仍掌握着主动权。

无论裁员还是焦虑，都不能抹去多年积累。这恰恰提供机会重新审视： * 我擅长什么？* 我真正想做什么，* 我愿意为哪类结果负责？

AI 时代最稀缺的不再是工具，而是知道自己要什么的人。

不要让机器定义你，也不要让外部噪声左右你的判断。应作如是观。

---