AI Coding 工具的实践经验
摘要
暂无摘要 (评价: E)
本文由作者提供想法和校验，DeepSeek V4 Flash协助编写、整理和发布。
这篇文章是我几个月来使用 AI Coding 工具的一些实践经验总结，希望能帮助刚接触这些工具的朋友理解它们是怎么工作的，以及怎么用得更好。
基本原理
首先需要理解 AI Coding 的工作方式。
大模型能写代码吗？能创建文件吗？不可以。它只有一个最基本的能力——你输入一段文字，它给你输出一段文字。写代码、编辑文件这些权限从哪里来？从软件工程中来。
因为 AI 有很强的规则遵守能力和结构化输出能力，我们可以把一些操作封装成 API 调用。比如写文件，就提供一个 Edit 工具，定义好必要的参数和输入范围。当 AI 判断需要完成某个任务，而且在工具列表中发现了匹配的工具，它就会调用这个工具。这样就完成了最基本的功能——编辑文件。
但实际开发不是一次对话就能搞定的。AI Coding 工具能自动化调用多个工具，这又是怎么做到的？同样基于 AI 的结构化输出能力。
举个例子，我们要求 AI 在完成某个任务、需要人类介入时，输出一个特定的标识（比如 “promise done”）。工具只要检测到这个标识，就知道流程可以结束了。更进一步，我们可以把这个"结束标识"也封装成类似工具的形式。整个工作流就变成了这样：
- 你输入第一句话
- AI 输出一段文字，里面没有结束标识，工具判断流程没结束
- 根据输出内容调用对应工具
- 把工具返回结果再封装成输入，自动送给 AI
- AI 继续输出，如此往复循环
这就构成了 AI Coding 最基本的自动化单元。
权限控制
理解了基本原理，就知道了 AI 自身只有生成文字的能力，它对现实世界的影响完全受软件限制。
比如它要写文件，或者删除某个重要文件，就必须调用工具。在软件层面，我们完全可以通过硬编码感知这种操作，并加以限制。比如绝对不允许操作 .env 文件。
限制分两层：
- Prompt 层面：通过输入规则来约束 AI 的行为
- 软件层面：直接在代码层面禁止某些操作，AI 调不了工具就是调不了
现在的 AI Coding 工具中，权限一般通过 Agent 来管理。每个 Agent 可以定义自己的权限范围。比如 Plan Agent 不允许写代码（或者只能写计划文档），Build Agent 可以任意操作文件和执行命令。
什么场景需要关注权限？比如做 Code Review，你肯定不希望 Agent 擅自修改代码。可以设计专门的 Review Agent，只给读权限，不给写权限。或者在制定规划时，你只想和 AI 聊天确定方案，不希望它直接写代码——这时除了 Prompt 约束，更需要软件层面的硬限制。
Tool 和 MCP
Tool 和 MCP 都提供工具能力，但设计思路不同。
Tool 是 AI Coding 工具内置的函数接口，每个工具定义了名称、参数和作用说明，AI 可以直接调用。它简单直接，但和具体工具深度绑定。
MCP（Model Context Protocol）则是一套标准化协议，让 AI 通过统一的接口和外部服务通信。MCP 以服务端形式运行，可以常驻后台、维护状态、提供实时数据。比如通过 MCP 查询数据库，第一次请求建立连接，后续请求可以复用，这是内置 Tool 不容易做到的。
但 MCP 的核心价值不是"有状态"，而是标准化互操作——任何实现了 MCP 协议的服务端都可以无缝接入任何支持 MCP 的 AI 工具，不用为每个工具单独适配。状态管理只是它作为独立服务端的副产品，不是本质区别。反过来说，MCP 也可以完全无状态，取决于服务端怎么设计。
Skill 和 Command
Skill 主要定义工作流程。简单理解，它就是一份文档，描述一件事要怎么做，然后让 AI 去参考。一个 Skill 可以包含多个工具调用，也可以包含自定义脚本。
Tool 和 MCP 相当于基层建筑，提供基础方法。Skill 则在更上层，指导怎么组合这些工具来完成特定目标。
比如"如何在 Bitbucket 上做 Code Review"，这是一个上层目标。它包含 review 规范、如何访问 Bitbucket、如何把结果贴回去、如何获取 diff、怎么保证安全性。整个流程就是一个 Skill，里面定义了第一步做什么、第二步做什么、如果 A 则 B 否则 C 之类的逻辑。
Command 和 Skill 类似，但更轻量。在 opencode 中，Skill 是通过 Coding Agent 自动发现、注入到 System Prompt 中的；Command 则是用户自定义、手动调用的。如果只是需要一份简单的 Code Review 规范来 review 本地代码，不需要复杂的 Skill，做成一个 Command 就够了，里面定义规范和输入格式就行。
Plan 和 Build
现在的 AI Coding 工具一般都会提供 Plan 和 Build 两种 Agent。
- Plan Agent：做规划，一般没有写权限（或只能写特定文件）
- Build Agent：全权限，负责执行
推荐的开发模式是：先用 Plan 聊清楚具体要怎么做——修改范围是哪些、怎么验证修改。通过和 Plan Agent 逐步对话确定方案，然后把上下文交给 Build Agent 执行。
但也不是所有任务都需要 Plan。这就体现人的价值了——我们可以基于项目经验判断任务的复杂度：
- 简单任务（修改单个文件，或者明确知道要改什么）：直接把需求写进文档，让 Build Agent 按文档执行，不需要 Plan 参与
- 复杂任务（不确定改哪些文件、不知道怎么约束测试流程）：先和 Plan 聊清楚
Plan 到 Build 的传递也有几种方式：
- 上下文传递：把 Plan 的上下文直接给 Build
- 文档传递：让 Plan 把规划写到文档中，review 确认后，用 Build 读取并执行
后者在上下文过长时特别有用——与其压缩上下文，不如把清晰的方案写进文档，新开 session 让 Build 去执行。
沟通技巧
AI Coding 工具通常都提供 Fork、Copy、Revert 功能，可以用来优化上下文。
比如在沟通过程中，AI 提供了一些方案，但某些方案你不了解。可以先让它解释这些方案。解释完了，你清楚了，但解释过程中产生的新上下文对你来说是不必要的。这时候可以直接 Revert 到开始解释之前的状态，然后基于刚了解的信息选择方案。
类似的，也可以 Fork 一个新的 session，之前 AI 的解释保留在另一个 session 中，方便回头查看。
一些想法
最后，这几个月用下来，我越来越觉得 Web APP 可能是一个发展方向。
一方面它没有太复杂的平台限制和兼容性问题，可以快速开发，很适合现在的 AI Coding。如果 Web APP 能大量普及，对很多普通人来说——当有某个需求，市面上没有合适的应用时，可以直接让 AI 帮你 Coding 一个。质量不用太高，能用就行，反正是自己用或者小范围用，不作为一个商业产品。
这感觉就像现在的 DIY——需要什么，就自己做一个。