从 AI 代码生成，到真正的开发伙伴关系

Claude 4 甫一亮相，市场就被其强大的推理和编程能力折服。但在连续使用数月之后，我意识到大模型真正的革命不在于生成更好的代码片段，而是其中蕴藏的自主性潜力。

很多人更多关注 AI 编程的语法正确性、基准测试得分和代码有效率，但我在对 Claude 4 的实际测试中体会到：能够全面理解开发目标、持续寻求解决方案并自主克服障碍的 AI 系统正在出现。

不同于常规的基准测试，我通过一项真实开发任务来评估 Claude 4 的自主能力：构建一款与 OpenAI API 集成的 OmniFocus 功能插件。这项任务不仅需要编写代码，还要求理解文档、处理错误、提供连续的用户体验并切实解决问题。这里考察的不只是语法正确性，更需要主动探索与持续推进。

正是这种对自主能力的感受，让我意识到开发者与 AI 系统的协作方式即将彻底改变。

三种模型，三种自主方式

Opus 4：不止于代码生成，走向合作开发

在使用 Opus 4 的过程中，我意识到与之前擅长根据特定指令生成代码片段的 AI 系统不同，Opus 4 表现出真正的开发自主性——独立推动开发进程，最终找到可行的解决方案。

在遇到数据库错误时，Opus 4 不仅修复了相应代码，还主动给出根本原因：

“我发现问题了——OmniFocus 插件需要使用 Preferences API 进行持久存储，而非直接访问数据库。我可以协助解决这个问题。”

之后它用 OmniFocus 的 Preferences API 实现了一套完整的解决方案。

这就是代码生成和智能体间的核心差异。代码生成器只是输出代码形式的文本，而智能体可以理解开发环境、发现问题，并在更广泛的应用需求框架内解决现实问题。

最让我印象深刻的，则是 Opus 4 如何在需求之外自主增强以下功能：

• 用于 API 设置的配置界面；

• 用于调试的详细错误消息；

• 用于防止无效请求的输入验证；

• API 调用期间的进度指示器。

Opus 4 对于良好开发者体验明显有自己的理解，这是传统代码生成工具所不可能实现的。

Sonnet 4：谨慎的协作者

Sonnet 4 同样展现出强大能力，但需要指引才能进一步发挥潜力。它的交互感受像是一位能力出众但谨慎的开发者，需要我定期检查。它对任务需求的理解效果不错，但在 API 集成中犯了一些小错误。对此，Sonnet 4 提出了一些需要澄清的问题：

“我注意到 OmniFocus 采取一种特殊的 HTTP 请求处理方式，能否向我提供它的 URL 获取功能说明文档？”

在收到提示后，它成功修复了问题，不过仍经历了七到八次迭代才给出完全可行的解决方案。

有趣的是，Sonnet 4 曾做出意想不到的判断——在与 OpenAI 集成遇到困难时，它建议暂时移除该功能，转而使用本地分析。这体现出它完成任务的强烈意愿，甚至不惜为此调整对原始需求的遵循。

体验 Sonnet 3.7：响应式工具

Sonnet 3.7 给我的感觉像是一款编程助手。它需要明确的指令，且很难与我正在构建的内容保持更广泛的上下文关联。

典型的交流过程如下：

• 我：“此插件需要将任务转换为 TaskPaper 格式，再将结果发送至 OpenAI。”

• Sonnet 3.7: “我将建立一条将任务转换为 TaskPaper 格式的函数。” [实现基本功能，但未提供错误处理。]

• 我：“现在我们需要实现 Open API 集成。”

• Sonnet 3.7: [实现基本 API 调用，但未提供错误处理或用户反馈机制

• 在遇到错误时，Sonnet 3.7 也很难独立完成错误诊断：

• 我：“我收到「文件为目录」的错误。”

• Sonnet 3.7: “很奇怪，但提供完整的错误信息吗？”

• [我给出错误详情。]

• Sonnet 3.7: “这可能与文件路径有关。我来检查一下插件的保存位置。”

经过 10 多次交互后，我仍未得到功能完备的插件成果。

智能体光谱：不止于高质量代码

AI 编程系统间的差异，已经不只体现在其生成正确代码的能力，而更多表现为智能体水平——即在极少指导下理解并实现开发目标的能力。

根据我的测试，我整理出以下智能体光谱：

• 代码生成器：根据特定提示词生成有效代码，但缺乏持久性和上下文理解能力。

• 响应式助手：生成可用代码，但在开发各阶段须明确指引，专注于即时指令而非整体目标。

• 协作型智能体：拥有较均衡的指令执行与主动性水平，可在定期指引下半自主工作，但可能需要随时调整方向。

• 开发合作伙伴：将开发目标内化并坚持朝着目标努力，无需明确指引即可主动识别并解决问题。

由此可见，对 AI 编程系统的评估方式将发生彻底转变——不只是代码质量，而是其在实际开发环境中自主解决问题的能力。

对开发实践有何影响？

具备智能体水平的 AI 系统对于开发工作流程有着深远影响：

从微指令到开发目标

代理式 AI 系统的有效协作，标志着从分步提示转化为更高层次的开发目标和背景。我给 Opus 4 的指令如下：

“构建一款插件，将 OmniFocus 任务发送给 OpenAI 进行分析和汇总。此插件应可优雅处理错误并提供良好的用户体验。”

只需这种宏观指引，它就能构建起完整的解决方案——早期代码生成系统则完全不具备此等能力。

超越 token 计数：一种新的经济模式

Claude 4 模型的智能体模式为成本效益分析开辟了新的维度。虽然 Opus 4 的单 token 成本更高（输入/输出分别为 15/75 美元，Sonnet 4 则为 3/15 美元），但其自主寻求解决方案的能力显著减少了实际交互次数。

Opus 4 需要 3 到 4 次交互的任务，在 Sonnet 3.7 上往往需要 10 次以上，效率的提升抵消了相对更高的每 token 成本。更重要的是，这节约了开发者的时间和认知负担，大大改善了工作体验。

调整开发流程，适应 AI 智能体

随着 AI 系统展现出真正的智能体能力，开发流程也将随之演变。也许未来的 AI 系统不仅能生成代码，还能处理实施规划、错误诊断和质量保证，确保开发者集中精力应对：

• 架构与系统设计；

• 目标与质量标准制定；

• 对 AI 生成方案进行批判性评估；

• 软件开发的人性化与伦理问题。

AI 并不是要取代开发者，而是帮助开发者迈向更高层次的指导和监督角色。

未来之路：超越现有一切

AI 智能体的快速发展呈现出以下几大趋势：

• 智能体专用开发系统：未来的 AI 系统可能专门针对开发需求而生，为不同开发领域建立专门的合作伙伴。

• 新的协作界面：现有聊天界面尚未针对开发协作做出优化。未来 AI 系统或将拥有更强调其自主性的工具，可探索代码库、运行测试并提出一致的解决方案。

• 持续发展的评估框架：智能体的成熟要求以新的方法评估 AI 系统，更多关注其理解和实现开发目标的能力。

• 组织适应：开发团队需要重新审视如何整合 AI 智能体，创造出专注于指导和评估 AI 贡献的全新职能角色。

智能体：新的前沿

大模型的发展代表着 AI 编程系统迎来重要里程碑，特别是其对于人机开发关系的颠覆。

我个人从测试中得到的重要启示在于，AI 前沿已经从“能否编写出正确代码”转为“能否理解开发者的实现意图”。新模型表明，我们正迈入 AI 系统成为真正开发伙伴、而非复杂代码生成工具的伟大时代。

行业拓展

分享一个面向研发人群使用的前后端分离的低代码软件——JNPF。

基于 Java Boot/.Net Core 双引擎，它适配国产化，支持主流数据库和操作系统，提供五十几种高频预制组件，内置了常用的后台管理系统使用场景和实用模版，通过简单的拖拉拽操作，开发者能够高效完成软件开发，提高开发效率，减少代码编写工作。

JNPF 基于 SpringBoot+Vue.js，提供了一个适合所有水平用户的低代码学习平台，无论是有经验的开发者还是编程新手，都可以在这里找到适合自己的学习路径。

此外，JNPF 支持全源码交付，完全支持根据公司、项目需求、业务需求进行二次改造开发或内网部署，具备多角色门户、登录认证、组织管理、角色授权、表单设计、流程设计、页面配置、报表设计、门户配置、代码生成工具等开箱即用的在线服务。