Claude代码工具集：AI编程从对话到项目协作的实践指南
函数调用（Function Calling）是大型语言模型（LLM）实现与外部系统交互的核心技术原理，它使AI模型能够理解和执行结构化操作指令。这项技术的核心价值在于将AI从单纯的文本生成器升级为可执行具体任务的智能代理，极大地扩展了其在自动化工作流中的应用潜力。在软件工程领域，这一能力尤其适用于代码生成、项目重构、自动化测试等需要精准操作和上下文感知的场景。通过为AI模型配备如文件读取、代码修改
1. 项目概述与核心价值
最近在折腾AI辅助编程工具链，发现了一个宝藏项目： pchalasani/claude-code-tools 。这可不是一个简单的代码片段集合，而是一个专门为Anthropic的Claude模型（特别是Claude 3系列）设计的、旨在深度集成到开发者工作流中的工具集。简单来说，它让Claude从一个“能聊天的代码助手”，变成了一个能直接在你的项目里“动手干活”的智能代理。
我自己作为一线开发者，尝试过各种AI编程方案，从简单的ChatGPT对话，到复杂的本地部署模型，再到各种IDE插件。一个核心痛点始终存在： AI给出的建议或代码，从对话窗口到我的实际项目文件，总有一道“最后一公里”的鸿沟 。我需要复制、粘贴、调整路径、处理依赖，这个过程本身就很打断思路。 claude-code-tools 瞄准的就是这个痛点。它通过一系列精心设计的工具函数和模式，让Claude能够以结构化的方式理解你的项目上下文（比如文件树、特定文件内容），并执行安全的文件操作（读取、编辑、创建），甚至运行简单的Shell命令来验证代码。这相当于为Claude装上了“手”和“眼睛”，让它能在你的代码库中直接导航和操作。
这个项目特别适合以下几类朋友：
- 全栈或后端开发者 ：经常需要跨模块修改、重构代码，或者处理复杂的项目初始化配置。
- 技术负责人或架构师 ：需要快速生成项目脚手架、设计文档，或者审查不同部分的代码一致性。
- 对AI编程有深度集成需求的极客 ：不满足于简单的问答，希望将AI作为自动化工作流的核心组件。
它的核心价值在于 提升AI编程的“操作密度”和“上下文感知能力” 。你不再需要反复描述“我在 src/utils/helper.js 文件的第45行有一个函数……”，而是可以直接让AI去查看、修改它。接下来，我就结合自己的实践，拆解一下这个工具集的设计思路、怎么把它用起来，以及过程中会遇到哪些坑、怎么避开。
2. 核心设计思路与架构拆解
刚接触这个项目时，不要被它“工具集”的名字迷惑，以为是一堆零散的脚本。它的设计有很强的整体性，核心思路是构建一个 “结构化提示词（Structured Prompt）+ 工具调用（Tool Calling）” 的增强回路。
2.1 核心交互模式：从对话到协作
传统的AI编程是“你问我答”的对话模式。而 claude-code-tools 推动的是一种“你指挥，我执行”的协作模式。这个转变依赖于几个关键设计：
-
项目上下文的具象化 ：工具集里提供了像
list_files、read_file、search_files这样的函数。在给Claude的提示词（System Prompt）中，你会明确告诉它：“你可以使用这些工具来探索项目”。当Claude需要了解项目结构时，它不再依赖于你模糊的描述，而是主动调用list_files获取目录树，或者用read_file查看具体文件内容。这确保了AI对项目状态的认知是精确、实时的。 -
安全边界内的操作能力 ：最核心的工具是
apply_diff。AI不直接覆盖你的文件，而是生成一个标准的Unix diff格式补丁。这个补丁描述了从原文件到新文件的变更。你的程序（或你本人）可以审查这个diff，然后再应用它。这是一个极其重要的安全设计，避免了AI因误解而直接破坏文件。它让操作变得可审查、可回滚。 -
闭环验证机制 ：除了看和写，工具集还提供了
run_command（在安全沙箱或子进程中运行命令）。这意味着AI在修改了一段代码后，可以主动建议运行相关的测试命令（如npm test、pytest）或代码检查（如eslint、black），并将结果反馈给后续的决策。这就形成了一个“分析-修改-验证”的微型工作流闭环。
2.2 工具链的组成与角色
项目中的工具大致可以分为三类，它们在协作中扮演不同角色：
- 侦察兵（Exploration Tools） ：
list_files,read_file,search_files。用于获取信息，建立上下文。这是AI“了解战场”的第一步。 - 工兵（Modification Tools） ：
apply_diff。核心的修改工具。AI所有的写操作都通过生成diff来提议，这是一种非破坏性的、精准的修改方式。 - 检验员（Verification Tools） ：
run_command。用于执行构建、测试、格式化等命令，验证修改的正确性或获取运行环境信息。
这种架构的好处是 职责分离且可组合 。你可以根据任务复杂度，选择性地为AI提供工具。比如，一个简单的代码解释任务，可能只需要 read_file ；而一个复杂的重构任务，则需要全套工具。
2.3 与Claude API的深度集成
这个工具集是围绕Claude的 Function Calling（函数调用） 能力构建的。你需要使用Claude的API（通常是 claude-3-5-sonnet 或更高版本），并在创建消息时，将工具的定义以JSON Schema格式传入。当Claude认为需要执行某个操作时，它会返回一个特殊的响应，指示需要调用哪个工具、传入什么参数。你的程序接收到这个响应后，实际执行工具对应的函数，将结果（如文件列表、命令输出）再作为新的上下文发送给Claude，让它继续思考。
这意味着，使用 claude-code-tools 本质上是在 编写一个能够与Claude API交互、并管理工具执行状态的应用程序 。项目源码提供了清晰的模式（比如 code_interpreter.py ），但你需要根据你的技术栈（Node.js, Python等）和项目需求进行适配。
3. 环境搭建与核心工具详解
理论讲完了，我们来看看具体怎么把它跑起来。这里我以Python环境为例，因为这是最通用的方式，而且项目本身也提供了Python的参考实现。
3.1 基础环境准备
首先，你需要一个能访问Claude API的环境。
- 获取API密钥 ：前往Anthropic的官网注册并获取API Key。妥善保管，它按Token计费。
- Python环境 ：建议使用Python 3.10+。创建一个虚拟环境是好的实践。
python -m venv venv source venv/bin/activate # Linux/macOS # venv\Scripts\activate # Windows - 安装依赖 ：核心是Anthropic的官方SDK和本项目。
pip install anthropic # 克隆项目仓库（或者你可以直接复制核心工具函数到你的项目） git clone https://github.com/pchalasani/claude-code-tools.git cd claude-code-tools # 查看项目中的requirements.txt，安装可能需要的其他依赖，如 `diff_match_patch` 用于处理diff。
注意 ：项目本身可能没有严格的
setup.py或requirements.txt，因为它更像一个模式参考。你需要关注的是tools.py或code_interpreter.py这样的核心文件，并将其逻辑整合到你自己的脚本中。
3.2 核心工具函数解析与安全配置
我们来深入看看几个最关键的工具函数，理解它们的输入、输出和安全考量。
apply_diff(file_path: str, diff: str) -> dict 这是重中之重。它的输入是一个文件路径和一个符合Unified Diff格式的字符串。
# 一个diff示例，它描述了变更
diff_content = """--- a/src/app.js
+++ b/src/app.js
@@ -10,7 +10,7 @@
console.log('Starting server...');
// Old configuration
- const port = 3000;
+ const port = process.env.PORT || 8080; // Use environment variable
app.listen(port, () => {
console.log(`Server running on port ${port}`);
你的程序在接收到Claude返回的、要求调用 apply_diff 的请求后， 必须 在真正应用前做几件事：
- 路径安全检查 ：检查
file_path是否在允许的项目根目录内，防止AI尝试修改系统文件（如/etc/passwd）。可以使用os.path.commonpath和os.path.realpath进行验证。 - Diff解析与预览 ：将diff解析出来，并在终端或日志中高亮显示即将发生的变更（增、删、改）。这给了你最后一次人工审查的机会。
- 备份（可选但推荐） ：在应用前，对原文件进行备份。一个简单的复制即可。
run_command(command: str, timeout: int = 30) -> dict 这个工具威力巨大，但也最危险。 绝对不能 允许AI运行任意命令。
- 安全沙箱是必须的 ：在生产环境或敏感项目中，你应该在一个隔离的容器（Docker）或高度受限的子进程中运行命令。至少，要使用
subprocess.Popen并设置shell=False来防止命令注入。 - 命令白名单机制 ：定义一个允许运行的命令列表。例如，只允许
['npm', 'yarn', 'python', 'pytest', 'black', 'isort', 'git add', 'git status']等与项目构建、测试、格式化相关的命令。禁止rm,curl | bash,wget等危险操作。 - 超时与资源限制 ：务必设置
timeout，并考虑限制最大内存和CPU使用，防止AI陷入死循环或运行资源消耗型命令。
list_files(directory: str = “.”) -> dict 和 read_file(file_path: str) -> dict 这两个工具相对安全，但也要注意：
- 目录遍历限制 ：为
list_files设置深度限制，比如最多递归3层，防止AI要求列出整个庞大的node_modules或.git目录，浪费Token。 - 大文件处理 ：在
read_file中，如果文件过大（如超过100KB），可以考虑只读取前N行和后N行，或者拒绝读取，并提示AI文件过大，请指定具体关注的行号范围。这能有效控制上下文长度和API成本。
3.3 构建你的第一个AI代码助手脚本
理解了工具后，我们来组装一个最简单的可运行脚本。这个脚本能处理一次完整的“AI提议-工具执行-结果反馈”的循环。
import os
import anthropic
from typing import List, Dict, Any
import subprocess
import difflib
import json
# 假设你已经将 tools.py 中的工具函数定义复制过来了
from my_tools import list_files, read_file, apply_diff, run_command
# 工具定义列表，必须与Claude API要求的格式一致
TOOLS = [
{
"name": "list_files",
"description": "List files and directories in a given path.",
"input_schema": {
"type": "object",
"properties": {
"directory": {"type": "string", "description": "Directory path, defaults to current directory '.'"}
},
"required": []
}
},
{
"name": "read_file",
"description": "Read the contents of a file.",
"input_schema": {
"type": "object",
"properties": {
"file_path": {"type": "string", "description": "Path to the file to read."}
},
"required": ["file_path"]
}
},
# ... 类似地定义 apply_diff 和 run_command
]
def main():
client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
# 1. 初始化对话，给出系统指令
system_prompt = """你是一个专业的编程助手，可以协助用户进行代码项目操作。
你可以使用以下工具来探索和修改项目：
- list_files: 查看目录内容。
- read_file: 读取特定文件内容。
- apply_diff: 通过提供diff格式的补丁来修改文件。
- run_command: 运行安全的构建或测试命令（仅限于白名单内）。
在修改文件前，请务必先查看相关文件内容，确保理解上下文。生成的diff必须精确且可读。"""
messages = [{"role": "user", "content": "请帮我查看当前项目根目录下src文件夹里有什么文件。"}]
# 2. 发送请求，允许工具调用
response = client.messages.create(
model="claude-3-5-sonnet-20241022",
max_tokens=4096,
system=system_prompt,
messages=messages,
tools=TOOLS
)
# 3. 处理响应：可能是文本，也可能是工具调用请求
for block in response.content:
if block.type == 'text':
print("Claude:", block.text)
elif block.type == 'tool_use':
tool_name = block.name
tool_input = block.input
print(f"\n[Claude 请求调用工具: {tool_name}]")
print(f"输入参数: {json.dumps(tool_input, indent=2)}")
# 4. 根据工具名，执行对应的本地函数
result = {}
if tool_name == "list_files":
result = list_files(**tool_input)
elif tool_name == "read_file":
result = read_file(**tool_input)
# ... 处理其他工具
# 5. 将工具执行结果作为新的消息追加，让Claude继续
messages.append({
"role": "assistant",
"content": response.content # 包含工具调用请求的原始响应
})
messages.append({
"role": "user",
"content": [
{
"type": "tool_result",
"tool_use_id": block.id, # 关键：关联之前的调用
"content": json.dumps(result)
}
]
})
# 6. 继续发送新的对话历史给Claude，进入下一轮
# (这里需要循环处理，直到Claude返回纯文本结果)
# ... 循环逻辑
if __name__ == "__main__":
main()
这个框架展示了核心的交互循环。在实际项目中，你需要将其封装成更健壮的服务，处理多轮对话、错误、以及更复杂的工具执行逻辑。
4. 实战演练：一个完整的代码重构任务
光说不练假把式。我们设定一个真实场景： 为一个现有的Express.js API服务器添加环境变量配置和基本的错误处理中间件 。假设项目结构很简单：
my-express-app/
├── src/
│ ├── app.js
│ └── routes/
│ └── index.js
├── package.json
└── .env.example
我们的目标是让AI助手完成以下工作：
- 读取
app.js和package.json，理解现有结构。 - 修改
app.js，将硬编码的端口号改为从环境变量PORT读取。 - 在
app.js中添加一个简单的404错误处理中间件和全局错误捕获中间件。 - 检查是否需要安装
dotenv包，并更新package.json中的依赖。 - 创建一个
.env文件（基于.env.example），并添加PORT变量。
4.1 任务分解与提示词工程
你不能直接对AI说“重构我的Express应用”。需要将任务分解成清晰的、可执行的步骤，并通过系统提示词（System Prompt）来引导。一个高效的提示词可能长这样：
“你正在协助重构一个Node.js Express项目以提升可配置性和健壮性。请按顺序执行以下任务，在每个步骤前请先思考并查看必要文件：
- 探索阶段 ：使用
list_files了解项目根结构，然后使用read_file查看src/app.js和package.json的主要内容，理解当前代码逻辑和依赖。- 配置端口 ：在
src/app.js中，找到硬编码的服务器端口（例如const port = 3000;），将其修改为从环境变量PORT读取，并设置默认值（如8080）。请使用apply_diff进行修改。- 添加错误处理 ：在
src/app.js中所有路由定义之后、app.listen调用之前，添加两个中间件： a. 一个处理404的中间件（当没有路由匹配时返回JSON格式错误）。 b. 一个全局错误处理中间件（接收四个参数err, req, res, next），至少记录错误并返回500状态码的JSON响应。 请分步使用apply_diff。- 依赖管理 ：检查
package.json中是否已包含dotenv依赖。如果没有，请使用apply_diff将其添加到dependencies中。- 环境文件 ：检查项目根目录是否存在
.env文件。如果不存在，请使用read_file查看.env.example（如果有），然后使用apply_diff创建一个新的.env文件，并添加一行PORT=8080。 请记住：每次修改前，先确认文件当前内容；每次修改后，可以简要说明变更原因。现在开始执行第一步。”
这样的提示词有几个优点： 目标清晰 、 步骤原子化 、 隐含了工具使用指令 。AI会按照这个逻辑链，主动调用工具去探索和修改。
4.2 交互过程实录与关键决策点
当你运行脚本并输入上述提示词后，观察AI的行为会非常有趣：
- AI首先调用
list_files(directory=”.”)。它获取了项目根目录列表，确认了src/和package.json的存在。 - 接着调用
read_file(file_path=”src/app.js”)。它仔细分析了现有代码，找到了const port = 3000;这一行，并识别了路由定义和app.listen的位置。 - 生成第一个diff ：AI会生成一个针对
src/app.js的diff，将端口行改为const port = process.env.PORT || 8080;。 这里是一个关键决策点 ：AI可能会添加注释，也可能会调整代码格式。你需要审查这个diff是否精确且符合你的代码风格（比如用||还是??做默认值）。 - 你（或你的程序）应用了这个diff 。然后AI继续下一步，读取
package.json。 - 处理依赖 ：AI发现没有
dotenv，于是生成第二个diff，在package.json的dependencies对象中添加”dotenv”: “^16.0.0”。 另一个决策点 ：AI选择的版本号是否合适？你可能希望它固定为”^16.0.0″或直接”latest”。你可以在提示词中预先说明你的版本管理策略。 - 添加错误处理中间件 ：AI会生成一个较大的diff，在
app.js的合适位置插入两段中间件函数代码。 这里需要仔细审查 ：AI添加的中间件函数签名是否正确？错误响应格式是否符合你的项目API规范？它是否正确地使用了next(err)？ - 创建
.env文件 ：AI调用read_file查看.env.example（如果存在），然后生成创建新文件的diff。
在整个过程中，AI可能会穿插使用 run_command ，比如在修改 package.json 后建议运行 npm install 或 npm list dotenv 来验证。 你必须通过白名单严格控制 run_command 的可执行命令 。
4.3 结果验证与迭代优化
所有修改提议完成后，你可以手动（或让AI通过 run_command ）运行一些验证命令：
# 检查语法
node -c src/app.js
# 如果添加了dotenv，确保在入口文件顶部require了它（AI可能忘了，需要提醒）
# 运行测试（如果有）
npm test
你可能会发现一些问题，比如AI添加的中间件没有正确导出，或者 .env 文件没有在 app.js 最顶部被加载 ( require(‘dotenv’).config() )。这时，你可以开启新一轮对话，将问题反馈给AI：“我发现 .env 配置没有加载，请在 app.js 文件顶部添加 require(‘dotenv’).config() 。” AI会再次调用 read_file 查看当前文件，然后生成新的diff。
这个迭代过程体现了 “人类监督，AI执行” 的协作模式。你负责制定战略、审查关键变更和最终验收；AI负责执行战术性的、高重复性的代码查找、生成和修改任务。
5. 高级技巧、常见问题与避坑指南
用了一段时间后，我积累了一些能极大提升体验和效率的技巧，也踩过不少坑。
5.1 提升效率与效果的实用技巧
- 给AI一个清晰的“角色”和“目标” ：在系统提示词开头，像分配工作一样定义AI的角色。例如：“你是一个经验丰富的Node.js后端工程师，擅长编写清晰、健壮且符合最佳实践的代码。你的任务是以最小侵入的方式改进项目代码，保持现有风格。” 这能引导AI生成更高质量的代码。
- 利用“记忆”或上下文摘要 ：Claude的上下文窗口虽然大（200K），但也不是无限的。对于超大型项目，不要让AI一次性读取所有文件。可以设计一个机制，让AI在探索后，用一段文字总结当前理解的项目核心结构、框架和技术栈，并将这段总结作为后续对话的“短期记忆”放在上下文里，减少重复读取文件的需要。
- 分阶段、分模块处理 ：不要试图在一个对话中让AI重构整个项目。将大任务拆解成独立的小任务，每个任务聚焦一个模块或一个功能点。例如：“第一阶段：重构用户认证模块的配置”、“第二阶段：为所有API路由添加输入验证”。每个阶段结束后，提交代码、运行测试，确保稳定后再进入下一阶段。
- 提供代码风格指南或示例 ：如果你有
.eslintrc、.prettierrc或项目内典型的代码示例，可以在初始提示词中让AI先读取这些配置文件，或者直接贴一小段你希望它遵循风格的示例代码。这能显著统一AI生成的代码风格。 - 结合版本控制（Git） ：在让AI进行一系列修改前，先确保代码已提交到Git。你可以将
git diff命令加入run_command的白名单。在AI完成一个阶段的修改后，让它运行git diff –stat或git diff src/app.js来汇总变更，方便你审查。这比人工一个个文件去对比要高效得多。
5.2 典型问题排查与解决方案
即使准备充分，在实际操作中还是会遇到各种问题。下面是一个快速排查表：
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
AI不断要求读取 node_modules 或 .git 下的文件，消耗大量Token。 |
提示词中未对探索范围做限制，或者 list_files 工具未做深度限制。 |
1. 在系统提示词中明确说明：“请专注于项目源码，避免探索 node_modules 、 .git 、 dist 等生成或依赖目录。” 2. 在 list_files 工具的实现中，加入目录黑名单和递归深度限制。 |
| AI生成的diff无法正确应用（patch失败）。 | 1. AI读取的文件版本与你本地实际版本不一致（中间被其他进程修改）。 2. AI生成的diff格式不标准或行号计算有误。 3. 文件路径不一致（相对路径/绝对路径问题）。 |
1. 确保在单次对话回合中，文件状态是锁定的。实现一个简单的文件状态缓存。 2. 使用更健壮的diff库（如Python的 difflib ）来解析和应用patch，并做好错误捕获，将失败信息反馈给AI。 3. 在工具调用和提示词中统一使用相对于项目根的路径。 |
AI试图运行 rm -rf / 或 curl 等危险命令。 |
run_command 工具没有实施命令白名单或沙箱隔离。 |
立即实施白名单机制！ 只允许与项目构建、测试、代码质量相关的命令。对于复杂需求，考虑让AI生成命令建议，由用户手动执行。 |
AI陷入循环，反复执行相同的工具调用（如不停 list_files ）。 |
提示词指令模糊，或者AI未能在上下文中找到所需信息，陷入困惑。 | 1. 检查提示词，确保任务指令是清晰、可终止的。 2. 在代码中设置工具调用次数上限，达到上限后中断会话并提示用户。 3. 主动介入，在对话中给出更明确的指令，打破循环。 |
| 修改后的代码引入语法错误或逻辑错误。 | AI的代码生成并非100%可靠，尤其涉及复杂逻辑时。 | 1. 审查diff是关键 ：不要盲目应用所有diff。仔细阅读AI提议的每一处变更。 2. 利用验证工具 ：将 npm test 、 eslint 、 typescript –noEmit 等检查命令加入白名单，并在AI完成修改后要求它运行这些检查，将结果反馈给你。 3. 小步快跑 ：每次只让AI修改一个小的、独立的功能点，验证通过后再继续。 |
| API调用成本过高。 | 1. 上下文过长，包含了太多文件内容。 2. AI进行了过多无意义的探索。 3. 任务过于复杂，导致多轮对话。 |
1. 优化提示词，引导AI精准读取关键文件，而非全部。 2. 为 read_file 工具添加文件大小限制，大文件只读取片段。 3. 对于复杂任务，先由人工进行高层设计，再将具体的编码任务拆解给AI。 |
5.3 安全与成本控制红线
这是两个绝对不能忽视的方面：
安全红线 ：
- 永远不要将
run_command的完全控制权交给AI 。白名单是底线。 - 对
apply_diff应用的所有变更进行人工确认 ，尤其是对核心业务逻辑文件、配置文件的修改。可以设计一个“确认模式”，所有diff都需要用户输入y才能应用。 - 隔离环境 ：最好在Docker容器或虚拟机中运行整个AI助手脚本，将其对宿主系统的影响降到最低。
- 敏感信息 ：确保AI不会读取或修改包含密码、密钥、个人信息的文件。可以在
read_file和list_files中设置路径黑名单。
成本控制 ：
- 监控Token使用 ：Anthropic API的计费基于输入/输出Token。在开发脚本时，记录每轮对话的Token消耗。特别关注因读取大文件导致的输入Token激增。
- 设置预算和警报 ：在Anthropic控制台设置使用量预算和警报，防止意外超支。
- 优化上下文管理 ：定期清理对话历史中过时的、不重要的内容。对于长篇文件内容，可以要求AI在理解后，用简短的语言进行总结，然后用总结替代原始长文本进入后续上下文。
6. 与其他AI编程工具的对比与融合
claude-code-tools 代表了一种“低级别”、“高控制度”的AI集成模式。它和市面上其他AI编程工具定位不同：
- vs. GitHub Copilot / Cursor ：Copilot和Cursor是“沉浸式”的IDE插件，在你写代码时提供行内补全和建议，交互是即时且碎片化的。
claude-code-tools则更适合 有计划性的、任务驱动型的 工作，比如“给项目添加日志系统”、“将配置迁移到环境变量”。你可以给它一个目标，然后去喝杯咖啡，回来看它提交的修改提案。前者是“副驾驶”，后者更像是“远程助理”。 - vs. ChatGPT Code Interpreter / Advanced Data Analysis ：OpenAI的代码解释器主要在沙箱环境中运行代码、处理数据。它擅长数据分析和一次性脚本，但对一个已有的大型代码库进行 精准的、结构化的修改 能力较弱，因为它缺乏
apply_diff这种与现有代码库深度交互的原语。 - vs. 自建AI Agent框架（如LangChain） ：
claude-code-tools可以看作是LangChain中“Tools”概念的一个具体、专精的实现。如果你已经在用LangChain，完全可以将这些工具函数封装成LangChain Tool，集成到更复杂的Agent工作流中。claude-code-tools的优势在于其与Claude模型的深度适配和简洁性。
融合使用建议 ：我的工作流是三者结合。 日常编码用Copilot 获取行级补全；遇到需要集中精力设计的模块时，切换到 claude-code-tools ，给它一个明确的重构或实现任务，让它生成方案和代码块；对于探索性的、需要运行代码看结果的数据处理或算法验证，会用 ChatGPT Code Interpreter 。工具是死的，人是活的，根据任务场景选择最趁手的那个，才能最大化提升效率。
最后，我想说的是， pchalasani/claude-code-tools 这个项目打开了一扇门，它展示了将大型语言模型深度、安全地集成到软件开发工作流中的一种可行路径。它目前还不是一个开箱即用的产品，需要你付出一些集成和调试的成本。但这份投入是值得的，因为你获得的不是一个玩具，而是一个可编程的、能理解你代码上下文的强大自动化伙伴。从简单的代码风格统一，到复杂的跨文件重构，很多重复性的编码劳动都可以尝试交给它。关键在于，你要学会如何给它下达清晰、安全的指令，并始终保持“审查者”的角色。这或许就是未来人机协同编程的常态：人类负责战略、创意和审查，AI负责战术、实施和探索。
欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。
更多推荐
11
0- 0
已为社区贡献9条内容
所有评论(0)