职贝云数AI新零售门户

标题: 读完 Manus 那篇长文,我不再把 AI 编程工具当万金油 [打印本页]

作者: BLpt8N 时间: 前天 14:54
标题: 读完 Manus 那篇长文,我不再把 AI 编程工具当万金油
最近，Manus 团队发布了一篇干货满满的长文《AI 代理的上下文工程》，分享了他们在构建智能体过程中的一系列工程阅历。文中提出的许多实际方法，对于正在运用 AI 编程工具的开发者而言，极具参考价值。

在实践开发中，我亲身验证了其中两条核心准绳：

1. 拆分义务，外部分析，别让 AI编程工具自作主张
2. 只运用必需的第三方插件。

在遵照这两条准绳后，我分明感遭到：AI 编程的准确率、效率，以及我对工具的信任感，都有了肉眼可见的提升。
❌ 不要把AI 编程工具当成“全能助手”

很多人在运用 Claude Code 等 AI 编程工具时，容易堕入一个常见误区：

把代码、报错、目的统统丢出来，让 AI 自行分析、修复、完成。

我也曾这么做。刚末尾我把 Claude Code 当成“全能 AI 工程师”来用：输入上下文，它就应该能了解、设计、执行、调试，一气呵成。

但当我的输入越来越长，工程越来越复杂时，成绩就出现了：

我常常为同一个成绩延续问了四五次，Claude Code给出的答案却一直在绕圈。

最后我以为是提示词不够精准，但后来我尝试用 O3 模型做前置分析，再把结果交给 Claude Code 执行——准确率和效率瞬间提升。

所以我看法到，成绩不在于AI编程工具不够强，而在于我一末尾把它当成全能选手，既要分析成绩、又要设计方案、还要执行修复。

我提供的上下文也变得越来越嘈杂，AI编程工具也在混乱中迷失了方向
最佳实际：外部分析 + 受控执行，让AI了解成绩

在阅历过多次 Claude“自作聪明但跑偏”的挫败后，我找到了一套当前阶段波动高效的实际范式：

把“思索”交给更擅长分析的模型（如 GPT-O3），把“执行”留给 Claude Code。
第一步：用 O3 做结构化分析

我先把报错信息、上下文和目的交给 O3，并用下面的提示词引导它输入明晰的结构化结论：
请你分析这个代码报错的缘由，并输入结构化内容：
- 能够缘由分析
- 可行的修复策略（至少两种）
- 引荐方案 + 简要理由

O3 的回答通常逻辑明晰、分层明白，非常合适作为 Claude 的“下游输入”。
第二步：控制 Claude Code，只让它按引荐道路修复

然后我把 O3 的分析结果复制进 Claude Code，并明白提示它：
按照以下引荐方案停止修复：
【错误缘由】
……

【引荐修复】
……

结果非常冷艳：Claude 不再跑偏，也没有反复尝试，而是一次性输入了准确的修复代码。

这种“外部分析 + 受控执行”的形式，实践上是一种轻量的模块化协作智能体，非常合适当前阶段的 AI 编程工具链建设。

第三方插件越多，AI编程工具越容易“乱跳”

很多人第一次用 Claude Code 这些AI编程工具的时分，能够会兴奋地把一堆市面上引荐的工具全挂出去，希望 AI 能像个“全能开发助手”一样，自动判别、自动调度。

但我试上去发现，工具越多，Claude 的表现反而越不波动。

详细会出现这些成绩：

这其实和 Manus 在文章里讲的阅历高度分歧：

“上下文中频繁动态添加/移除工具，会毁坏 KV 缓存，让模型越来越困惑。”

所以他们选择的是“遮盖（mask）而不是移除”工具——意思是工具列表在上下文中保持波动不变，但模型在某个时辰只能看见一部分工具可以选。
底层逻辑：模块化智能优于单体智能

这种实际方法，实践上也是对 Manus Agent 架构理念的工程化归纳：

模块	职责	实际手腕
外部分析器	拆解义务、明白目的	GPT-4o / O3
执行器	修复代码、完成调试	Claude Code
形态控制器	控制工具暴露、波动上下文结构	手动 prompt / token mask

经过这种“结构化分工”，我们不只能更精准地控制义务上下文，还能避免 Claude 被工具链拖入不必要的复杂逻辑

做 AI 工具运用者，而非幻想者

Claude Code 很强，但不是万金油。

它最合适的角色，其实是：

一个超级靠谱的执行者 —— 前提是你给了它明白目的、合理工具、波动上下文。

这也许是我们这些开发者在 AI 编程时代，最需求建立的新看法：

Prompt 工程，不只是“怎样问”，更是“怎样组织上下文、怎样控制途径、怎样设计角色职责”。

在这场由言语模型驱动的工程转型中，人类依然是那位最重要的上下文工程师。

欢迎光临职贝云数AI新零售门户 (https://www.taojin168.com/cloud/)