前言

最近忙着开发自己的个人项目 (输入提示词，等待AI写代码，刷短视频，发现代码不对劲，要求AI改bug，等待AI写代码，刷短视频.jpg)，在等待AI写代码的过程中我不禁催生出了和AI开发工具相关的问题：
　　我个人平时开发的时候喜欢用vscode这种插件支持度较高的编辑器，外接Agent插件，但是这种局限性比较大，api常常会出大大小小的毛病，修改代码的时候也不是很好控制代码的替换和撤回等操作。
　　但是用深度定制化的AI编辑器(Kiro、Cursor等)，却不是很适配自己的大模型api。
　　那有没有能更加好的管理自己代码，并深度融合AI开发的自定义api编辑器呢？

现有AI工具

• 这类工具目前已经开始分化成几种路线：

- AI 是 Agent插件（Continue、Cline 等）
- AI 是 IDE本身（Cursor、Trae IDE、Qoder等）
- AI 是 Agent平台（Codex for windows），没有代码编辑功能

那么为什么会出现如此多种不同的AI工具呢。
　　如果你的目标是完全掌控自己的 API、模型路由和 Prompt，同时保留深度 AI 开发体验，我还是更倾向推荐 VS Code + Cline（Agent）。这套组合在模型选择、自定义 API 和可扩展性方面，通常比 Trae 或 Codex 更灵活。
　　而Agent平台更像是一个完全由prompt(提示词)驱动的平台，在里面你可以指挥不同的agent分别或协同工作。它比传统的IDE+AI插件的组合要更加倾向于人与AI之间的交互，用AI完成所有事情。它适合所有人(无论你是不是程序员)用聊天的方式下达并完成任务，但它并不适合拿来作为代码编辑器使用，通常需要使用外部的代码编辑器来进行编程/软件测试等。
　　不难看出，从技术范式上划分，存在两条清晰的路径：基于IDE的Agent辅助编程，这属于“自底向上”的开发者提效模式，要求开发者主导设计和实现；而基于AgentBase或Codex等平台的对话式开发，则是“自顶向下”的抽象跃迁，其目标是通过自然语言降低编码门槛，向“平民化开发”演进。不过，即便后者大幅弱化了编程语法要求，其底层环境的配置与依赖管理，依然需要基础的工程能力，并非完全“零代码”。

真实案例

　　上述的两个AI应用方向，一个是给开发者进行辅助编程的工具，而另一个是代替人进行编程的“虚拟程序员”，两者都有自己的优缺点，那有没有办法让这两者的优点结合起来呢？让我们看看各大厂商是怎么做的：

• OpenAI
  　1. codex
  　2. ChatGPT 内置 Coding Agent
  他们认为未来开发方式不是：人写代码，AI 补全。
  而是：人下达任务，Agent 完成工作。因此 Codex 更像一个开发 Agent，而不是传统 IDE。

• Anthropic
  　1. Claude Code
  他们认为开发者已经有：VS Code，Neovim，JetBrains，没有必要重新开发编辑器。
  而 Claude 应该成为一个终端里的软件工程师。

Claude → Terminal → Git → Shell → 代码

所以 Claude Code 更偏向

命令 → AI → 修改几十个文件 → 运行测试 → 提交 Git

• Google
  　1. Gemini Code Assist
  Google 没有自己做 IDE。
  Google 已经拥有：Android Studio、IntelliJ 生态合作、Cloud Workstations
  他们更希望Gemini成为：所有 IDE 的 AI。

• Microsoft
  　1. GitHub Copilot
  Microsoft已经拥有：VS Code、GitHub、Copilot
  这是目前最大的开发者生态。而他们已经有了VS Code,直接

VS Code + Copilot

就是官方路线，未来很多能力也会直接进入 VS Code
　　仔细观察不难发现，这四家巨头的策略虽然路径不同，但殊途同归于一个共识：AI 不应再被视为"代码补全器"，而应被赋予"自主执行能力"——无论是 Codex 的 Agent 化定位、Claude Code 对终端和 Git 的接管，还是 Gemini 和 Copilot 对 IDE 生态的全面渗透，AI 的职责边界都已从"辅助输入"扩展到了"参与开发全流程"。

　　接下来让我们看看为自家大模型专门开发了IDE的公司：

• Amazon
  　1. Kiro
  AWS作为企业来说，企业最大的痛点不是：AI不会写代码。
  而是：AI写的代码没人敢维护。
  因此 Kiro 推出了：Spec Driven Development。

Requirement → Design → Task → Implementation

• 字节跳动
  　1. Trae
  国内开发者不一定能稳定使用 Cursor，很多人需要国产模型，企业更希望使用自有模型
  因此Trae可以：接入多个模型、MCP、Agent、Builder、更适合中文开发体验

• 阿里
  　1. Qoder
  Qoder 的核心理念更像是：AI Pair Programmer（AI 结对程序员）+ Agent
  它比较强调：理解整个代码库、多文件修改、自动重构、Agent 执行复杂任务、对大型仓库的上下文理解
  而不是像 Kiro 那样，把 Specification → Design → Tasks 作为第一目标。
  Kiro关注的是项目应该怎么开发，更像一个软件工程流程工具。
  而Qoder关注的是代码应该怎么修改，更像一个AI工程师。

规范驱动开发

　　规范驱动开发（SDD），或许正是连接传统开发与agent之间的桥梁。它并非全新的概念，但在AI时代被赋予了新的生命。其核心思想是：将"规范"（Specification）作为开发过程的第一公民，而非代码。
　　在传统开发中，规范（需求文档、PRD、接口定义）是静态的、前置的，开发人员将其"翻译"成代码后，规范便逐渐与代码脱节。但在AI时代，规范可以成为动态的、可执行的"中间语言"——它既可以被人类理解和评审，也可以被AI精准地解析和生成。

让我们从三个维度进行说明：

• 上层：规范层
  　人类负责定义"做什么"（What），用自然语言或结构化语言描述需求、边界条件、验收标准。
  　　e.g.　Agent平台的Prompt输入
• 中间层：转换层
  　AI Agent负责将规范转化为设计方案、代码骨架、测试用例。
  　　e.g.　AI插件进行模型管理 + 执行
• 下层：实现层
  　人类开发者（或人类+AI协同）负责填充实现细节、审查代码、处理复杂逻辑。
  　　e.g.　VS Code + 人工编码

　　因此，如果规范能够被 AI 理解，那么开发流程就不再只是“人写代码”，而是“人编写规范，AI实现规范”。这意味着IDE的核心价值也在发生变化：它不再只是文本编辑器，而是“规范、代码与 Agent 的协作中心”。作为开发人员可以：

1. 使用结构化规范语言:如Gherkin（Given-When-Then）、OpenAPI、或者更轻量的Markdown模板，让规范本身可解析、可版本控制。
2. 规范驱动的测试生成：根据规范自动生成单元测试或集成测试的骨架，开发者只需填写断言逻辑。
3. 规范与代码的双向同步：代码变更时自动更新规范文档（或提示开发者更新），避免文档腐化。
4. 规范作为RAG的上下文：将项目规范、编码风格、架构约束向量化，注入到Agent的上下文中，让AI生成的代码天然符合规范。

未来展望

我认为未来的软件工程会逐渐演化为

需求（自然语言）
　　　↓
　　规范
　　　↓
　AI Agent
　　　↓
　代码与测试
　　　↓
人工审查与决策

程序员不会消失，但角色会发生变化：

• -从“逐行写代码”转向“定义问题与约束”
• -从“实现功能”转向“设计系统与规范”
• -从“代码生产者”转向“AI 团队的架构师”

而规范驱动开发（SDD），很可能就是连接传统软件工程与 AI Agent 时代的那座桥梁。