好的，没问题。作为一名在AI协作领域摸爬滚打多年的老手，我来帮你把这篇关于WorkBuddy模式的文章重新梳理一下，去掉那股AI味儿，让它更像一个行家跟你分享的经验之谈。 --- 你有没有碰过这种事：让AI帮忙改个拼写错误，它愣是给你输出了一篇八百字的前因后果分析，等你读完，黄花菜都凉了。或者，你只是想跟它聊聊某个方案靠不靠谱，它那边已经开始动手建文件了。 这种“鸡同鸭讲”的错位感，其实挺常见的。问题不在于AI能力行不行，而在于你俩压根没在同一个频道上。WorkBuddy就是把这事儿想明白了，直接给了三个模式：Craft、Plan、Ask。不是什么高深莫测的概念，说白了，就是让你选一下“这次，你想让我怎么配合你干”。 ## 三种模式到底有什么不同 咱们先看个总表，心里有个谱，后面再展开细聊。 | | Craft | Plan | Ask | |---|---|---|---| | 一句话 | 你说，我做 | 先想后做 | 只聊不动 | | 能读文件吗 | 能 | 能 | 能 | | 能改文件吗 | 能 | 确认后能 | 不能 | | 能执行命令吗 | 能 | 确认后能 | 不能 | | 你需要做什么 | 交付后验收 | 审核计划，然后验收 | 自己动手 | | 像什么人 | 干活的助手 | 出方案的项目经理 | 给建议的顾问 | 你看，核心的区别就一个字：**干不干**。 ## Craft：你说，我做 Craft是默认模式，也是用得最多的一种。你给它一个明确的指令，它二话不说，直接上手干活——读文件、改代码、跑命令，中间不跟你打岔问“这样可以吗”，活儿干完了，你把结果拿过去验收就行。 **这适合什么样的任务？** 就是你心里门儿清，知道最终要什么结果的那些事儿。 举几个例子： - **修复明确的bug。** 比如你说“UserController 的 getUserById 方法报空指针了，去看下日志修一下”。它就会自己去读代码、定位问题、改掉、验证，然后把结果甩给你。你完全不用在旁边盯着，省心。 - **生成文档。** “根据当前代码结构，给我写一份README出来”。它会扫一遍整个项目，然后把文件写好，放到项目里该放的位置。你打开看看内容对不对就行。 - **批量操作。** “把 src 目录下所有 .js 文件的后缀改成 .ts，并更新所有引用”。这种多步骤但路径明确的事，Craft可以一口气干完，最后再给你一份变更清单，一目了然。 这里有个经验之谈：在Craft模式下，指令越具体，结果越靠谱。你说“优化一下这个函数”，太模糊了它反而不好办；但如果你说“把这个 O(n²) 的双层循环，用 HashMap 优化成 O(n)”，目标清晰，再加上约束条件，它交出来的东西基本上就能直接用。 ## Plan：先想后做 Plan模式，专治那些你三言两语说不清楚，或者实现路径有好几条的任务。 它的流程是这样的：你说需求，它先分析，然后给你一份分步行动计划——第一步做什么，第二步做什么，中间有哪些潜在风险。你仔细看完，觉得方案靠谱，说一句“开始吧”，它才真正动手。 **那什么时候该用Plan呢？** 遇到下面这几种情况，值得考虑： - **实现一个比较大的新功能。** 比如你说“加一个文件上传功能，要支持断点续传”。它不会上来就写代码，而是会先问你：我打算分五步走——先设计接口，再实现分片上传，接着做断点续传的记录逻辑，然后是文件合并，最后写测试。你看这个方案行不行？ - **大规模重构。** 比如要把整个项目从 Ja vaScript 迁移到 TypeScript。这种事要是直接开干，很可能干到一半才发现依赖顺序搞错了，某个模块直接崩了。Plan模式会先帮你做一次全面的范围评估，排好模块迁移的顺序，把所有的风险点都标出来。你确认路线图之后，它才开始动工。 - **改动影响面摸不准的任务。** 你不太确定动一个地方会不会牵连到其他模块，心里没底，那最好先让它出个方案，看看它计划改哪些文件、怎么改，你再决定要不要让它继续。 Plan模式最值钱的地方，在于“先对齐”。你审核计划时，重点看三件事：步骤顺序合不合理？有没有遗漏边界情况？风险点标没标出来？不满意就直接提，它改完再给你看一轮，直到你们俩想法一致。 ## Ask：只聊不动 Ask是三个模式里最“克制”的。它只读文件、只分析、只回答问题，绝对不碰你一个字，也不跑任何命令。 说白了，就是聊天。但它不是瞎聊，它能读懂你的项目代码，所以给出的回答都是基于你的实际代码，而不是泛泛而谈的通用知识。 那什么时候该用Ask呢？主要是你还在想、还在评估、还不准备动手的时候。 - **代码审查。** “帮我看看 PaymentService 这个类有没有设计上的问题”。它读完代码会告诉你：职责太多、直接依赖了具体实现而没抽象接口、有几处异常没处理等等。它只告诉你问题在哪，不会顺手就帮你改掉。 - **技术选型讨论。** “高并发场景下，Redis 和 Memcached 该怎么选”。它可以从数据结构、持久化、集群方案、性能等维度，逐项跟你聊，最后给出一个综合建议。但最终的决定，还是你自己来做。 - **学习和探索。** “给我讲讲我们项目里，event loop 是怎么用的”。它会结合你的实际代码来讲解，比看任何通用的教程都更有针对性。 Ask模式还有个隐藏的好处：它是最安全的探索方式。如果你不确定一个改动会不会搞坏项目，先用Ask模式让它分析一下影响面，聊清楚了，再切到Craft或Plan模式去动手。 ## 怎么选 说到底，选哪个模式，就是回答一个问题：**这个任务，我需要它帮我思考，还是帮我执行？** - **任务明确，目标清晰，你知道要什么**——用Craft。直接干，干完验收就行。 - **任务复杂，实现路径不唯一**——用Plan。先看方案，确认了再干。 - **还在想，不想动任何东西**——用Ask。先聊聊再说。 就拿“给项目加日志功能”来举例，同一个任务在三种模式下，体验完全不同： - **Craft：** 直接在关键模块插日志代码，配置好日志框架，给你一个能跑的日志功能，你验收结果。 - **Plan：** 先列计划——选哪个日志框架、日志级别怎么定、哪些模块要加、测试怎么写——你确认了，它再逐步执行。 - **Ask：** 分析项目现在的日志现状，对比 log4j 和 logback 的优缺点，给你建议，但就是不写一行代码。 ## 进阶玩法：组合着用 在实际干活时，很少有人会一个模式走到黑。比较实用的组合套路，有这么几种： - **Ask → Plan → Craft。** 先用Ask模式讨论需求，搞清楚要做什么、大概怎么做。然后切换到Plan让它出详细方案。确认无误后，再切回Craft执行。处理复杂任务时，我强烈推荐走这条路线，思考足够深入，执行起来也干脆利落。 - **Plan → Craft。** 你对这个领域很熟，需求也清楚，但实现起来比较复杂。那就跳过前期没完没了的讨论，让Plan出一份方案，你确认后，直接让Craft执行。 - **直接Craft。** 简单活儿别绕弯子。改个bug、写个脚本、生成个配置文件，一把梭就完了。 一个不错的习惯是，在发指令前花几秒钟过一下脑子：这活儿需不需要先看方案？如果不需要，Craft直接上。如果心里没底，就Plan先出方案。要是压根还没想好要做什么，就先切换到Ask聊一聊。这个判断本身不花什么时间，但能帮你省掉后期大量的返工成本。 ## 走一遍：一个完整的二次开发项目 光说策略还是有点抽象，我们拿一个具体的场景走一遍流程。假设你手里有一份MUD游戏的源码，打算做二次开发。看看三种模式是怎么配合，把一个项目从零到能跑起来的。 ### 第一阶段：Ask，先把方向聊清楚 源码一拿到手，你先把整个项目文件夹拖进WorkBuddy，切换到Ask模式，然后开始问。 “这个项目是什么架构，主要用了哪些技术？” 它读完一遍代码，告诉你：后端是C写的，走的telnet协议，数据存在文件里，没有用数据库。模块化程度不高，游戏逻辑和业务逻辑混在一起。 这时你心里大概有数了，接着聊需求。 “我想保留核心玩法，但后端想换到现代技术栈，前端再增加一个Web界面，你有什么建议？” 它不会直接动手改，而是跟你讨论：后端可以考虑Go或Rust，各有优劣；数据库从文件迁移到PostgreSQL或MySQL；前端可以用WebSocket代替telnet，这样浏览器可以直接连。它把这些选项的利弊都摊在桌上，你问，它答，来回几轮，方向就慢慢聊出来了。 这个阶段持续多久，完全看你自己——聊到你觉得“好了，我知道要干什么了”为止。Ask模式全程不碰你的文件，所以再怎么聊都是安全的。 ### 第二阶段：Plan，把方案拆解成步骤 方向定了，切换到Plan模式，把聊出来的需求整理成一份正式的执行计划。 你可以这样说：“好的，需求确认了：后端用Go重写，保留MUD核心指令系统，数据迁移到PostgreSQL，前端用WebSocket做一个简单的Web UI。帮我出一份开发计划。” 它开始分析，然后会给你一份像下面这样的东西： **阶段一：环境搭建** 1. 搭建Go项目结构，选型框架（gin或echo） 2. 配置PostgreSQL，设计用户表、房间表、物品表 3. 把原有C代码的协议逻辑搞清楚，整理成文档 **阶段二：核心功能迁移** 1. 实现telnet到WebSocket的双协议接入 2. 迁移指令系统（look、move、take、drop等） 3. 实现房间系统、物品系统、战斗系统 **阶段三：数据迁移** 1. 编写脚本，把原有文件数据导入PostgreSQL 2. 验证数据的完整性 **阶段四：前端** 1. 用React或Vue编写Web终端界面 2. 对接WebSocket连接后端 你仔细看完这份计划，可能会发现有些步骤的顺序不太对，或者有些风险它没有考虑到。比如你发现数据迁移其实应该放在核心功能迁移之前，因为新代码要基于新数据库来写。你直接提出来，它会调整计划，再给你看一轮。这样来回几轮，直到你觉得这个计划完全可以执行了，说一句“开始吧”即可。 ### 第三阶段：Craft，按计划一步一步干 计划确认无误后，切换到Craft模式，它开始执行。 它会先做阶段一的第一步：搭Go项目结构。它会建好目录、配好go.mod、装上gin框架、写好main.go的骨架，然后告诉你“阶段一第一步完成了，你可以看一下”。 你看一下，没什么问题，它就继续往下走。 整个过程是一步一步来的。每完成一个步骤，它都会停下来给你看结果。你验收通过，它才继续下一步。这和那种一口气把整个项目写完的模式完全不同——你是全程参与其中的，随时可以喊停，随时可以调整方向。 如果某个步骤出了问题，你也可以随时切回Ask模式，让它帮你分析错在哪里，搞清楚后，再切回Craft继续执行。 ### 回头看这个流程 - **Ask阶段**，解决了“做什么”和“怎么做”的问题。你没有一上来就写代码，而是先把大方向聊透彻了。 - **Plan阶段**，解决了“按什么顺序做”的问题。你有了一份清晰的路线图，知道每一步大概要干什么，风险点在哪里。 - **Craft阶段**，解决了“怎么把活干完”的问题。你不用每一步都盯着，但关键节点你都能看到结果，随时可以介入干预。 如果一开始就直接用Craft模式会怎样？它很可能基于自己对“MUD游戏”的理解，直接开始写代码了。写出来发现不是你想要的方向，你还得花大量时间改回来。三种模式分开用，本质上就是在不同的决策节点上，选对了自己的参与深度。 ## 最后说两句 三种模式没什么好坏之分，它们只是三种不同的协作姿态。选错了模式，要么是它干活太快你还没准备好，要么是它太磨叽你等不及。选对了，配合起来就会很顺畅。 下次用WorkBuddy之前，先想一句：这次，我需要的是执行，还是方案，还是纯粹的讨论？想清楚了再选模式。