WB-09 WorkBuddy 编程任务与 Worktree：从小脚本到并行修改

这篇带你在 WorkBuddy 中写一个数据处理脚本、修一个小 bug，再用 Worktree 把两项改动分开完成。重点是选对工作目录、看懂变更，并把正确结果带回主分支。

⠀

本篇范围：办公场景里的小脚本、简单原型与本地 Git 并行练习。大型项目的测试、审查和团队工程流程，可继续阅读本仓库的 Claude Code 系列 和 Codex 系列。工具能生成代码，不代表生成结果已经适合生产使用。

---

课程信息

⠀

• 作者：老金

• GitHub：https://github.com/KimYx0207

• 公众号：老金带你玩AI

• X（Twitter）：老金带你玩AI

• 个人博客：https://aiking.dev

• 预计学时：1-2 小时

• 难度等级：⭐⭐ 进阶

• 更新日期：2026年10月3日

• 前置要求：已完成 WB-08 多端协同

---

2026-09-14 历史基准（客户端 5.5.6）：本篇讲在 WorkBuddy 中处理代码任务，沿用文件名中的 Coding Mode 作为主题名称。当前任务输入框按默认（Agent）、计划（Plan）、仅问答（Ask）控制执行方式；5.4.0 起支持 Git 分支选择与 Worktree 任务，5.5.5 起后台任务可查看终端输出并取消。本篇第五步用同一个小仓库演示创建、并行、审阅与合并。

⠀

先搞清：Coding Mode 是什么、给谁用

⠀

1.1 编程任务和执行模式分开看

⠀

写脚本、改 bug、运行测试描述的是任务内容；输入框中的模式决定 WorkBuddy 现在怎样推进任务：

⠀

模式

做什么

本篇怎么选

默认（Agent）

执行任务，可读写文件并调用工具

已明确要修改哪些文件时使用

计划（Plan）

先补充信息、提出方案，确认后再执行

需求不清楚或改动涉及多个步骤时使用

仅问答（Ask）

只咨询、解释，不直接执行任务

先看懂一段代码或报错时使用

⠀

默认 Agent 也能处理办公文档与代码任务；不需要为了写代码寻找一个固定的“Work Mode / Coding Mode”双模式开关。

⠀

1.2 Coding Mode 适合的场景

⠀

✅ 写一段小脚本（数据处理、自动化、爬虫）
✅ 改 bug（你贴报错信息让它修）
✅ 写测试（给你已有的函数补单测）
✅ 起一个 demo 项目（快速验证想法）
✅ 改前端样式（HTML/CSS/JS 的简单调整）
✅ 解释代码（看不懂的代码让它讲）
✅ 做技术原型（验证某个方案可不可行）

⠀

1.3 这些任务先准备工程条件

⠀

• 大型重构：先有可运行的测试、模块边界和小批次变更计划。

• 多服务项目：先理清各服务的启动方式、依赖和数据环境。

• 部署与 CI/CD：先确认目标环境、权限和回退方式，本篇不执行部署。

• 生产代码：无论使用哪款工具，都需要代码审查、相关测试与团队发布流程。

⠀

如果这些条件还没准备好，先缩小为一个可在本地验证的小任务。

⠀

1.4 谁该用 WorkBuddy 的 Coding Mode

⠀

✅ 偶尔写代码的产品经理、运营、数据分析师
✅ 想验证想法、做 demo 的创业者
✅ 学生学编程、做课程作业
✅ 开发者想快速试个原型（不替代主工具）
✅ 写自动化脚本简化日常办公的人

⠀

本篇从小任务开始，便于你看清文件修改与运行结果。是否作为日常主力，按项目工具链、团队规范和实际试用结果判断。

⠀

准备清单：

⠀

✅ WB-08 学完，会基本操作
✅ 有一个真实的代码需求（写个脚本、改个 bug、做个 demo）
✅ 一台装好相关运行环境的电脑（比如写 Python 装好 Python）
✅ 账号有可用积分，先用小任务观察实际消耗

---

第一步：选择工作空间和执行模式（5 分钟）

⠀

1.1 选一个独立工作目录

⠀

在新建任务页点击输入框左下角的选择工作空间，选中你为本次练习准备的目录，例如 D:\workbuddy-code。把测试数据放进去，再核对输入框显示的目录。

⠀

WorkBuddy 会基于所选目录读取、处理和保存文件。选择工作空间不等于已经初始化 Git，也不会自动替你建立完整版本历史。

⠀

1.2 决定先问、先计划，还是开始执行

⠀

点击输入框左侧 + → 模式，可开启计划 Plan或仅问答，两者互斥。非默认模式会在输入框下方显示标识，点标识上的 × 退出后回到默认 Agent。

⠀

先解释代码用仅问答；需要讨论方案用计划；确认要写文件时回到 Agent。Plan 生成方案后，可以继续补充要求，确认方案再开始执行。

⠀

同时查看输入框底部的权限状态，保持默认权限即可开始本篇练习。不要为了找不到目录或暂时无法执行，就打开全局的“允许完全访问”。自然语言中的“先别跑”表达的是任务约束，实际操作仍要结合模式、权限提示和变更记录检查。

⠀

1.3 卡住了怎么办

⠀

问题

处理

找不到旧教程里的双模式开关

使用输入框的 Agent / Plan / 仅问答，代码任务直接写在提示里

看到了文件但任务没有动手

确认是否还处于仅问答或等待计划确认

提示工作目录无权限

重新选择自己有权限的练习目录；确需目录授权时核对具体路径

以为已有 Git 历史却不能回退

在项目目录检查 git status；第五步会从空目录建立练习仓库

---

第二步：跑通第一个代码任务（15 分钟）

⠀

老金带你跑一个所有人都能用的——写一个 Python 数据处理脚本。

⠀

2.1 准备工作

⠀

先确认电脑已有可用 Python，运行 python --version 查看版本。没有时按 Python 官方下载说明安装受支持版本；这是本地运行环境，不是 WorkBuddy 保证内置的依赖。

在选好的练习目录保存 UTF-8 的 data.csv，本题使用以下三行虚构数据：

日期,部门,金额
2026-09-09,运营,200
2026-09-07,研发,120
2026-09-08,运营,100

排序后应依次是 9 月 7、8、9 日。按部门汇总应为：研发总金额 120、平均 120、记录数 1；运营总金额 300、平均 150、记录数 2。合计金额 420、记录数 3，作为运行后核对的参考，不是 App 实测记录。

⠀

2.2 提任务

⠀

在 Coding Mode 里发这段：

⠀

帮我写一个 Python 脚本，做这几件事：
1. 读取当前目录下一个 CSV 文件（文件名：data.csv）
2. 把里面的数据按"日期"列升序排
3. 按"部门"列分组，每组算出总金额、平均金额、记录数
4. 把结果输出到一个新的 Excel 文件 result.xlsx

要求：
- 用 pandas 库（如果没装，告诉我怎么装）
- 代码加注释，关键步骤解释清楚
- 处理异常（文件不存在、列名错误等），出错给友好提示
- 把代码保存到当前选择的练习目录中的 data_process.py（本篇示例为 D:\workbuddy-code\data_process.py；目录不同时使用实际路径）

写完先告诉我怎么运行，别直接跑。

⠀

2.3 你会看到什么

本地文档也可用 WB-01 的独立文件浏览器练习直接打开；这与在当前任务右侧查看产物是两条入口。

⠀

任务生成文件或网页后，可从右侧结果区查看这些内容：

⠀

- 产物：当前任务生成的交付文件
- 工作空间文件：浏览当前工作目录中的文件
- 变更：逐文件查看修改差异
- 浏览器：查看开发中的网页；需要预览时再启动对应本地服务

⠀

产出包含：

⠀

✅ data_process.py 完整代码（带注释）
✅ 一个 requirements.txt（告诉你装哪些依赖）
✅ 运行说明（怎么装依赖、怎么跑）

⠀

2.4 自己跑一遍

先打开终端，进入保存 data.csv 和 data_process.py 的练习目录，再建立 Python 虚拟环境，避免依赖与其他项目混在一起。以下 Windows PowerShell 命令对应本篇的 D:\workbuddy-code；如果你选择了其他目录，先替换第一行的路径：

Set-Location -LiteralPath 'D:\workbuddy-code'
python -m venv .venv
.\.venv\Scripts\python.exe -m pip install pandas openpyxl
.\.venv\Scripts\python.exe data_process.py

Mac 的环境内解释器路径为 .venv/bin/python，使用同一解释器安装依赖和运行脚本。若没有条件安装依赖，先阅读生成的代码与运行说明，不能把文件生成算成脚本已运行。下面的目录与文件名对应本篇 Windows 示例。

⠀

按它给的说明：

⠀

1. 打开命令行，cd 到 D:\workbuddy-code
2. 创建并使用本节的虚拟环境，安装 pandas 和 openpyxl
3. 使用 2.1 节给出的 data.csv，先核对三行虚构数据和列名
4. 用虚拟环境中的解释器运行 data_process.py
5. 看 result.xlsx 是不是生成了，打开核对数据对不对

⠀

2.5 卡住了怎么办

⠀

❌ 代码跑报错
   → 把完整报错贴回给 WorkBuddy，让它修
   → 常见原因：Python 版本不对、依赖没装、文件路径错

❌ 跑通了但结果不对
   → 把输出和预期对比，告诉 WorkBuddy"哪里不对、期望是什么"
   → 让它加更多调试输出，定位问题

❌ 它直接跑了代码（你没让它跑）
   → 默认 Agent 可以执行任务；先核对当前模式与实际操作记录，准备执行前用 Plan 讨论方案，只解释时用仅问答
   → 回到输入框检查模式和默认权限；方案阶段用 Plan，只解释时用仅问答

❌ 代码写到了错误位置
   → 检查工作目录设置
   → 在提问里明确"保存到 [绝对路径]"

---

第三步：用 Coding Mode 改 bug

⠀

3.1 经典场景：你有一段报错的代码

⠀

把你跑报错的代码贴给 WorkBuddy：

⠀

这段代码报错了，帮我修：

[贴你的代码]

报错信息：
[贴完整报错]

我想实现 [你的目标]。
修完告诉我改了什么、为什么原来的会错。
别直接跑，先解释，我确认后自己跑。

⠀

3.2 你会看到什么

⠀

- WorkBuddy 定位 bug 原因（语法错、逻辑错、环境错）
- 给出修改方案，标注具体改了哪几行
- 解释为什么原来会错、新写法为什么对
- 修改后的完整代码（你直接用）

⠀

3.3 改 bug 的提问技巧

⠀

✅ 给完整报错（别只贴最后一行，前面的调用栈也要）
✅ 给完整代码（别只贴你怀疑的那段，可能是别处引起的）
✅ 说明你想干啥（不然它可能"修对了"但不是你要的）
✅ 说明环境（Python 版本、依赖版本、操作系统）
❌ 别只说"不好使""错了"，信息太少它没法修

---

第四步：起一个本地 demo（验证想法）

⠀

4.1 经典场景：你想快速做个原型

⠀

比如你想验证"一个简单的待办清单网页"想法：

⠀

帮我快速搭一个待办清单的网页 demo：
- 单 HTML 文件（HTML + CSS + JS 都内嵌）
- 能添加、删除、标记完成
- 数据存浏览器 localStorage（不用后端）
- 简洁好看，配色舒服

写完帮我起本地预览，我要在浏览器里看到效果。

⠀

4.2 你会看到什么

⠀

- 产物或工作空间文件：查看生成的 todo.html
- 浏览器：按任务实际启动的本地预览查看网页效果
- 你能点添加、删除、标记完成，跟真实网页一样

⠀

这个单 HTML 例子可以先用浏览器打开，通常不需要后端环境；若任务另启了本地服务，按运行说明核对进程和端口。先验证添加、删除、完成标记及刷新后的保存结果，再决定是否扩大原型范围。

⠀

4.3 注意事项

⠀

⚠️ demo 适合验证想法，不适合上线（代码质量、安全性都没打磨）
⚠️ 复杂交互（多页面、登录、数据库）做完整 demo 较慢
⚠️ 想正式上线，让 WorkBuddy 出原型，再让开发者打磨

---

第五步：Worktree 跟练——两个任务分开改，再带回主分支

⠀

Worktree 是同一个 Git 仓库的另一份工作目录。 每份目录可以检出自己的分支，文件改动分开保存，但仍共享提交和分支等 Git 数据。它不隔离电脑上的端口、数据库或账号权限，所以两个任务也不能随意操作同一个外部资源。

⠀

普通任务适合单点修改；准备同时推进两项独立改动时，再打开 Worktree。本练习使用本地的小仓库，不需要远程仓库、GitHub 授权或部署。

⠀

5.1 准备一个有初始提交的练习仓库

⠀

在一个新建的空目录中准备两个文件，例如 D:\workbuddy-code\worktree-demo。不要拿已有业务仓库覆盖练习。

⠀

report.py：

⠀

sales = [2400, 1950]
refunds = [120, 50]
print("销售额合计：", sum(sales))

⠀

README.md：

⠀

# 门店报表练习

脚本目前只计算销售额，接下来要补上退款后的净销售额。

⠀

在该目录的 PowerShell 中执行：

⠀

git init -b main
git add report.py README.md
git commit -m "Add report workshop baseline"
python report.py
git status --short

⠀

应该看到销售额合计为 4350，最后的状态为空。如果 Git 提示作者身份未设置，先为这个练习仓库设置自己的 Git 身份再提交。初始提交很重要：Worktree 要从一个真实的提交开始。

⠀

5.2 从同一个基础分支创建两个任务

⠀

1. 在 WorkBuddy 新建任务页，通过输入框左下角的选择工作空间选中练习仓库。

2. 确认分支是 main。普通文件夹没有 Git 分支；有 Git 仓库时才会出现可用的分支选择与 Worktree 入口。

3. 输入任务 A 的提示，打开输入框下方默认关闭的 Worktree 开关。

4. 在 Base Branch（基础分支）选择 main，再发送。等创建完成后，任务会开始执行。

5. 回到新建任务页，再用同一工作空间、同一 main 基础分支创建任务 B，也打开 Worktree。

⠀

任务 A：

⠀

只修改 report.py，让它计算净销售额：销售额合计减去退款额合计。
保留现有两组数据，输出“净销售额合计：”和计算结果。
运行 python report.py，结果应为 4180。
不要修改 README.md，不安装依赖，不提交、不推送。
完成后说明实际工作目录、修改文件和运行结果。

⠀

任务 B：

⠀

只修改 README.md，补上 python report.py 的运行方法。
解释销售额为 4350、退款额为 170，完成退款计算修复后净销售额应为 4180。
这是与 report.py 修复配套的说明；不要声称本分支的旧脚本已经输出 4180。
不要修改 report.py，不安装依赖，不提交、不推送。
完成后说明实际工作目录和修改文件。

⠀

任务列表会出现 Worktree 标识和各自的分支标签，分支名类似 workbuddy/main-a3f8c2b1。任务工作目录位于用户目录下的 WorkBuddy/Worktrees，具体目录以任务实际显示为准。

⠀

这里有两个容易误会的地方：

⠀

• 新任务从所选 Base Branch 的 HEAD 提交开始，不包含源工作区的未提交改动。若基础材料尚未提交，先保存到合适的提交，或明确让任务在自己的目录重新建立材料。

• Base Branch 创建后锁定，任务内也没有切换分支入口。选错基础分支时，保留已经产生的结果，重新创建正确的任务；不要在原任务里强行切分支。

⠀

5.3 在各自目录审阅，确认任务没有互相覆盖

⠀

打开每个任务右侧的变更，A 应只出现 report.py，B 应只出现 README.md。工作空间文件区应分别对应两个任务的工作目录。

⠀

需要用本地终端核对时，先确认终端当前目录是该任务的 Worktree，再运行：

⠀

git status --short
git diff --stat
git diff

⠀

回到原练习目录运行 python report.py，此时仍应显示 4350：任务 A 的修改尚未带回主分支。在任务 A 的目录运行同一命令才应得到 4180。若原目录已经被改，先停下检查任务是否真的开启了 Worktree，以及是否让它写了原目录的绝对路径。

⠀

5.4 保存两个任务的成果，再合并回练习仓库

⠀

本节采用 Git 的本地提交与合并，不假设 WorkBuddy 会自动合并任务。

⠀

在确认任务 A 已结束、改动正确后，在 A 的工作目录执行：

⠀

git add report.py
git commit -m "Calculate net sales"

⠀

在确认任务 B 已结束后，在 B 的工作目录执行：

⠀

git add README.md
git commit -m "Document net sales calculation"

⠀

返回原练习目录，先用 git worktree list 核对路径和分支。复制两个任务的真实分支名，替换下面变量中的提示文字；不要照抄示例随机后缀。

⠀

$taskBranchA = '从任务 A 复制的完整分支名'
$taskBranchB = '从任务 B 复制的完整分支名'
git switch main
git status --short
git diff main...$taskBranchA -- report.py
git diff main...$taskBranchB -- README.md

⠀

确认当前在 main、状态为空，且两份差异正是前面审阅过的内容，再执行：

⠀

git merge --no-ff --no-edit $taskBranchA
git merge --no-ff --no-edit $taskBranchB
python report.py
git status --short

⠀

最终应该得到 4180，README 也包含相同的算式，工作目录状态为空。合并若发生冲突，先保留两个任务分支并查看冲突文件；不要用“全部接受”或强制重置代替判断。

⠀

普通任务切换分支时遇到未提交改动，WorkBuddy 会提供提交、Stash 和丢弃选项。Stash 可包含未跟踪文件；丢弃会放弃改动。本练习通过先审阅并提交避免这一步，不用丢弃来清场。

⠀

5.5 结束任务与释放空间

先分清发送新消息和停止任务。模型执行时继续输入消息，补充要求会先进入输入框上方的队列；队列里的消息可以编辑、删除或拖动调序。当前一轮输出和工具调用结束后，消息按顺序继续处理。5.6.0修复了新消息误中断上一轮长命令及消息越过队列的问题；需要停止时使用停止入口，并检查后台命令状态。

可以在前面的练习任务生成结果时补一句“结果保留原始日期”。若看到队列，先核对这条要求再等待本轮结束；任务已经完成时，这句话会作为下一轮处理，不必为了出现队列而制造一个长时间运行的任务。已经进入对话流的消息可以查看或复制，但不能再按队列方式回退编辑。

⠀

先确认任务与后台命令已经停止；如有后台命令，在详情中查看终端输出，再按需要取消。把分支名、提交和运行结果记在任务里，核实成果已经合并或另有保留后，再处理任务归档与 Worktree 空间。

⠀

达到 Worktree 数量限制时，客户端可能要求按时间范围清理任务工作区、分支和文件。确认前逐项核对范围，尚有唯一副本时取消清理。归档、完成提示和清理目录都不等于代码已合并。

⠀

问题

处理

Worktree 开关不出现

检查选中的目录是否真有 Git 仓库和初始提交，普通文件夹不支持

任务看不到刚改的内容

核对基础分支与提交；源工作区未提交内容不会自动带入

两个任务改到同一处

检查是否关闭了 Worktree，或提示里用了原目录的绝对路径

切换分支提示已被占用

保持每个 Worktree 使用各自分支，在 main 合并任务分支即可

本地预览端口冲突

Worktree 只分开工作目录，改用不同端口或停止另一项预览

想在任务内换分支或再 fork

当前 Worktree Task 不支持，回新建任务页选择正确基础分支

⠀

本节面向桌面端、单个 Git 仓库。云端 WorkBuddy、CodeBuddy、非 Git 项目和跨仓库任务不能直接套用这套 Worktree Task 步骤。

---

5.6 把项目约定留在仓库里

需要让新任务沿用项目约定时，官方支持项目目录中的 .codebuddy/ 配置：规则、Agent、技能、斜杠命令和 CODEBUDDY.md 记忆文件；同时兼容仓库中的 AGENTS.md。项目级同名代理、技能和规则优先于用户级配置。

本地练习可先只写一份 .codebuddy/CODEBUDDY.md，说明“运行 report.py 应得到净销售额 4180；修改前查看当前分支；不推送远程”。在新任务中请它说明读到了哪些约定，再用文件差异和运行结果检查是否遵守。提示词与配置不是权限硬限制，不需要为这一步修改全局配置。详见 官方项目说明。

第六步：跟其他工具配合

⠀

老金讲讲 WorkBuddy Coding Mode 在你工具链里的位置。

⠀

6.1 跟 Claude Code / Codex 的搭配

⠀

场景判断：
- 偶尔写点代码、做 demo、写脚本 → WorkBuddy Coding Mode
- 日常开发、写生产代码、复杂重构 → Claude Code
- 多入口协作、CI/CD、长任务 → Codex

工具切换：
- 在 WorkBuddy 写个原型，验证想法 OK
- 把代码丢进 Claude Code 做深度打磨、写测试、加错误处理
- 用 Codex 做 Code Review、跑 CI、协作合并

⠀

6.2 跟 GitHub 配合

⠀

先按第五步在本地分支中完成修改、检查和合并。需要把改动交给团队审阅时，再准备提交说明与 PR 描述，并核对远程仓库权限和可用工具。

⠀

连接器出现在列表中，不等于已经拥有 Git 推送或创建 PR 的权限。让 WorkBuddy 先准备变更摘要，明确确认后再执行提交、推送和创建 PR；本篇练习不要求连接 GitHub。

⠀

6.3 跟本地编辑器配合

⠀

- WorkBuddy 写代码 → 你在 VS Code 里看 / 调整
- WorkBuddy 起 dev server → 你在浏览器里看效果
- WorkBuddy 跑测试 → 你看测试报告
- 形成"AI 写 + 人审 + 工具链配合"的循环

---

第七步：编程任务的边界和常见问题

⠀

7.1 本篇没有覆盖的工程工作

⠀

本篇的小脚本和 Worktree 练习不能替代大型代码库的测试体系、性能分析、多服务联调或生产发布。遇到这些任务，先说明项目规模、已有测试与运行环境，再选择合适的工具链和任务范围；不要只靠换一款 AI 工具来保证结果。

⠀

7.2 常见坑

⠀

⚠️ 直接跑了不该跑的代码（删文件、改系统配置）
   → 在提问里明确"先别跑，等我确认"
   → 在输入框核对默认权限；先看方案时用 Plan，并仔细阅读实际操作提示
   → 别让它在重要目录工作

⚠️ 写完代码不告诉你依赖
   → 在提问里明确"列出所有依赖和安装命令"
   → 让它生成 requirements.txt 或 package.json

⚠️ 代码风格不一致（每次写法不同）
   → 给它一份你的代码风格样本参考
   → 让它遵循某个 lint 规则（PEP8、ESLint 等）

⚠️ 改了不该改的文件
   → 工作目录要隔离（专门给 WorkBuddy 一个目录）
   → Changes 面板每次看一眼，确认改对地方

⠀

7.3 安全注意

⠀

🚫 别让它在生产代码仓库直接改（用分支 + PR）
🚫 别让它执行危险命令（rm -rf、DROP TABLE 这种）
🚫 别把生产环境凭证（数据库密码、API Key）写进代码
✅ 涉及公司代码的，先问 IT 同意
✅ 用 Git 管版本，改错了能回滚

---

完成这篇后你应该有什么

⠀

✅ 能选择正确工作空间，并区分 Agent、Plan 与仅问答
✅ 完成过两个 Worktree 的独立修改、逐项审阅与本地合并
✅ 跑通过一个代码任务（推荐数据处理脚本）
✅ 试过让它改 bug 或起 demo
✅ 知道 Coding Mode 适合 / 不适合的场景
✅ 知道怎么跟 Claude Code / Codex 配合（不同任务用不同工具）
✅ 做过安全自检（隔离目录、别跑危险命令、用 Git）

---

常见问题

⠀

Q1：WorkBuddy 写代码比 Claude Code 差很多吗？
不能仅凭工具名下结论。用同一个小任务比较生成结果、测试通过情况、审查成本和现有工具链兼容性，再决定哪种工作流更适合。

⠀

Q2：能用 WorkBuddy 写生产代码吗？
可以把它用于准备代码改动，但能否进入生产取决于审查、测试和团队发布流程。使用 Claude Code 或 Codex 生成的代码也需要这些检查。

⠀

Q3：Coding Mode 消耗积分多吗？
取决于所用模型、任务处理量和重试情况，不能保证比所有办公任务都多或更少。先试一个小任务，在「订阅和用量」中查看实际消耗。

⠀

Q4：能让它直接发 PR 吗？
需要可用的 Git / 平台工具和对应仓库权限。先完成本地修改与检查，再准备 PR 描述；确认提交、推送和创建 PR 的范围后才执行，不从“连接器已显示”推断远程写入已经获授权。

⠀

Q5：我是程序员，WorkBuddy 对我有啥用？
对你来说是辅助工具——写临时脚本、做技术调研、跑 demo 验证想法、写文档。是否作为主力，按已有工具链、测试和实际任务结果判断。

⠀

Q6：能跑我的现有项目代码吗？
能。把项目目录设成工作目录，让 WorkBuddy 读取、分析、修改。但别让它直接改生产代码，先复制一份让它改，确认对了再合并回去。

⠀

Q7：Coding Mode 支持哪些编程语言？
可以把不同语言的代码交给它生成、解释或修改；能否运行还取决于本机解释器、编译器、依赖和项目工具链。先用该项目已有的构建或测试命令核对，不把某种语言名出现在回答中当成已经完整支持，也不保证模型会主动说明所有不熟悉的内容。

⠀

Q8：写完的代码版权算谁的？
生成代码的使用与权利范围，要看适用服务协议、第三方依赖许可和代码来源。保留依赖与来源信息，商用时按实际条款确认；不能只凭账号归属判断全部代码权利。

---

接下来学什么

⠀

✅ 想搞清企业账号、积分席位、对比所有工具 → WB-10
✅ 已经够用了 → 把前几篇的工坊都跑一遍巩固
✅ 你是开发者，想深入编程 → 转到本仓库 Claude Code 系列或 Codex 系列

---

课程制作：老金
最后更新：2026年10月3日
许可：本课程采用 MIT License；转载、复制或二次分发时必须保留版权声明与许可声明

---

下一步

⠀

下一篇：WB-10 WorkBuddy 企业账号、安全与对比完整指南。