WorkBuddy 实战入门小技巧——AI 写代码总是跑偏，不是模型不行，是你没让它先读懂需求

用AI写代码90%的人都在犯同一个错误现在 AIGC、Agent 如此发达的时代有人用AI写代码一周做出了完整的后台管理系统。同一时期另一个人也用AI改了三天越改越乱最后全部回滚一行没留。工具一样。差距在哪里不是模型的问题。是用法。第一关先算清楚这笔账不同任务对应不同模型是成本优化的第一步市面上的AI模型现在多到眼花Claude、GPT、Gemini、Qwen、还有一堆国产的。每个都有人说好每个都有人骂。但大多数人在选模型时问的问题都错了。哪个最厉害——这不是你应该问的问题。你应该问的是这个任务值得花多少钱 真实场景某团队开发电商后台用顶配模型写了所有代码月费账单3000元。后来拆分任务架构设计和复杂业务逻辑用Claude 4占20%任务量常规CRUD和重复代码用Claude Haiku占80%月费降到600元代码质量没有明显差异。拿WorkBuddy来说它可以接多个模型你可以根据任务类型手动切换。我自己的用法是这样的需要推理、理解复杂上下文、做架构分析的任务给能力强的模型。写重复代码、补注释、套模板给便宜的。展开代码语言TXT自动换行AI代码解释# 高能力模型Claude 4 / GPT-4o 适用架构设计、复杂业务逻辑推理、调试诡异Bug 特征需要深度上下文理解、多步推理 # 中等模型Claude Sonnet / GPT-4o-mini 适用功能模块开发、接口对接、代码审查 特征有一定复杂度但有明确输入输出 # 轻量模型Haiku / Flash 适用补注释、写测试、套模板、格式转换 特征规则明确、创造性要求低、批量执行同样一个帮我写个工具函数的任务用顶配模型和用便宜模型结果基本没差别但成本差了十倍。龙虾OpenClaw里有一个概念叫工作流你可以把不同任务拆开指定不同节点用不同模型。设计一次以后每次跑都是最优成本组合。 龙虾OpenClaw 工作流节点在OpenClaw里可以建立自动化工作流不同节点指定不同模型。比如需求解析节点用Claude 4代码生成节点用Sonnet注释补全节点用Haiku——一次配置每次运行自动按最优成本组合执行。AI不是免费的当然了也是有免费的但是性能和效果参差不齐。你不知道自己在为什么付钱就是在浪费钱。第二关先让它读懂你再让它动手左不给项目背景直接写代码右先喂项目文档再写代码——两个结果差距明显这是我见过最高频的错误没有之一。需求还没说清楚直接甩给AI帮我写一个用户登录系统。AI真的写了。JWT、刷新token、密码加密、验证码全来了500行看起来像那么回事。但数据库设计和你们项目不一样。状态管理逻辑也不对。接口格式对不上现有系统。白写了。问题不在于AI写得不好而在于它根本不知道你的项目是什么样的。它只能基于一个通用的登录系统去写而不是你们这个具体系统里的登录模块。正确的做法先花5分钟让它消化项目背景再开始写代码。在WorkBuddy里你可以把README、数据库设计、接口文档、甚至核心代码文件都放进对话上下文然后问它你现在理解我们项目的整体架构了吗用自己的话描述一下技术栈是什么数据怎么流转主要有哪些模块。比如Prompt模板 · 项目背景注入展开代码语言TXT自动换行AI代码解释你现在是我们项目的技术负责人以下是项目背景 【技术栈】React 18 TypeScript NestJS PostgreSQL Redis 【项目类型】B端SaaS多租户架构用户量级10-100w 【现有约定】 - 所有接口返回格式{ code: number, data: any, message: string } - 错误码规范2xx成功4xx客户端错误5xx服务端错误 - 认证方式JWT Refresh TokenRedis存储黑名单 - 代码风格ESLint Prettier函数式组件hooks优先 请用自己的话描述一下 1. 你理解的整体架构是什么样的 2. 新增一个模块你会放在哪个目录下 3. 有哪些地方你还不确定需要我补充说明 # 等AI复述确认后再开始提需求等它复述出来你确认它真的理解了再说现在帮我设计登录系统。这一步能省掉至少70%的返工。龙虾OpenClaw里有知识库功能专门解决这个问题——把项目文档、设计稿、接口规范存进去AI每次对话时会主动拉取相关上下文而不是凭空发挥。龙虾OpenClaw 知识库功能把项目README、接口文档、数据库设计、规范文档上传到知识库AI每次对话时自动引用相关上下文不需要每次手动粘贴。项目越大这个功能越值钱。项目背景是AI能力的放大器。背景给得越清晰AI发挥得越准。第三关不会写提示词让AI给你写很多人说我不会写提示词然后对着AI说一句话发现结果不对就觉得AI不好用。这个问题AI自己可以解决。你描述需求用的是日常语言边界模糊隐含假设多。让AI把这些显式化——帮你生成一个精准的提示词你审核一遍确认没问题再把这个提示词发给它执行。 实战案例你说帮我解析Excel里的订单数据。AI会开始问什么格式哪些列输出到哪里换成帮我生成一个精准的提示词让AI解析订单Excel——它生成的提示词会包含列名、输出格式、文件命名规则、错误处理方式比你自己想的全一次执行基本没问题。告诉AI你想做什么让它帮你生成一个精准的提示词然后你把这个提示词再发给它执行。听起来绕但有它的道理。你描述需求用的是日常语言边界模糊隐含的假设很多。AI帮你生成的提示词会把这些隐含假设显式化把边界说清楚把技术约束写进去。比如你想要解析Excel里的订单数据按客户分组生成汇总报表。你直接说这句话AI大概率会问你几个问题或者默默做了一堆你不需要的东西。但如果你先让它生成提示词它会给你这样一段展开代码语言TXT自动换行AI代码解释第一步让AI生成提示词 我需要实现以下功能请帮我生成一个精确的技术提示词 目标[用自然语言描述你想做什么] 输入[数据来源/文件格式/接口] 输出[期望的结果格式] 约束[有什么不能做的、必须遵守的] 技术环境[语言/框架/版本] 请生成一个能直接使用的提示词 要求 - 包含具体的输入输出格式定义 - 明确边界条件和错误处理 - 指定代码风格和命名规范 --- 第二步收到提示词后你审核确认然后直接把它发给AI执行你看一遍确认这就是你想要的把这段话发给AI结果基本一次就对。Prompt模板 · Excel解析AI生成版示例展开代码语言TXT自动换行AI代码解释Python Excel订单解析工具需求 【输入】 - 文件格式.xlsx - 必含列订单号(order_id)、客户名(customer)、金额(amount)、日期(date) - 文件路径作为命令行参数传入 【处理逻辑】 - 按客户名分组 - 计算每组订单总数、金额总和、平均金额 - 过滤掉金额为0或负数的异常数据 【输出】 - 新建xlsx文件文件名客户汇总_YYYYMMDD.xlsx - 保存路径输入文件同目录 - 列顺序客户名 | 订单数 | 总金额 | 平均金额 - 按总金额降序排列 【异常处理】 - 文件不存在输出明确错误信息退出码1 - 必要列缺失列出缺失的列名退出码2 - 解析成功输出处理完成共x条客户记录 【代码规范】 - 使用openpyxl库 - 添加中文注释 - 函数拆分读取/处理/写出各一个函数WorkBuddy里可以保存常用的提示词模板你把高质量的提示词存下来下次类似场景直接复用不用每次从头想。第四关让AI出方案你做判断很多人把AI当执行工具给需求AI来实现。这个分工有一个隐患——你跳过了对方案的判断等发现方向不对时代价很大。合理的分工AI出备选方案 → 你基于项目视角选择 → AI执行选定方案。让AI在动手之前先给你三个备选方案每个说清楚架构选择、技术栈、优缺点、适用场景、工作量估算。Prompt模板 · 方案评审请求展开代码语言TXT自动换行AI代码解释我需要实现实时消息推送功能目前日活10w峰值并发5000 服务端是NestJS请给我3个方案 每个方案包括 1. 技术选型具体到库名和版本 2. 核心架构一句话描述数据流向 3. 优点针对我们的场景 4. 缺点和风险点 5. 实现复杂度低/中/高 6. 水平扩展方案多节点时怎么处理 额外说明 - 我们团队没有Go经验优先考虑JS生态 - 已有Redis可以直接用 - 必须支持消息持久化 最后给一个你的推荐说明理由。你拿着这三个方案从自己对项目的理解出发做判断哪个最适合当前团队的技术能力哪个维护成本最低哪个最能适应将来的扩展需求这个过程有两个收获第一你对要做的东西有了更深的理解后续沟通成本大幅下降。第二AI给出的方案里经常有你没想到的角度这是它见过太多代码库之后的经验浓缩值得认真看。 为什么这样做有价值AI在这个环节通常会给出你没想到的角度。比如某次我让它分析消息队列方案它给出了一个用Redis Streams代替Kafka的方案——理由是我们已有Redis避免引入新中间件降低运维复杂度。这个判断我自己当时没有主动考虑但仔细看后确实是更合适的选择。第五关难点先做Demo别把风险留到最后每个项目都有一两个最不确定的技术点——这些点是整个项目最大的风险。常见错误是把难点留到最后等基础架构都搭好了才发现难点走不通。这时候回头代价极大因为前面的工作已经和你选的技术路线深度绑定了。正确的做法是反过来先攻难点验证可行性再搭其他东西。在WorkBuddy里让AI先做一个最小化验证DemoPrompt模板 · 最小化验证Demo展开代码语言TXT自动换行AI代码解释我需要验证以下技术路线是否可行请写一个最小化Demo 目标实现Web端与服务端的实时双向数据同步 Demo要求 - 只验证核心连接和数据传输其他功能全部省略 - 服务端Node.js ws库不要用Socket.io验证裸WebSocket - 客户端原生HTML 原生WebSocket API - 功能客户端发消息服务端广播给所有连接的客户端 - 文件server.js index.html 两个文件能直接跑 这个Demo跑通后我需要你告诉我 1. 这条路线有哪些生产环境的坑比如断线重连、心跳检测 2. 扩展到多节点时需要额外解决什么问题 3. 是否有更推荐的替代方案 # 只验证技术可行性不要过度封装第六关不满意就回滚——大多数人没用上的功能AI改代码改到一半发现方向不对。很多人的反应疯狂撤销或者对AI说把刚才改的全改回去然后看着AI越改越乱。WorkBuddy里有对话级别的代码回滚。每一步代码修改都有记录你可以找到任意节点直接恢复到那个时间点不用手动撤销不用翻Git历史。 WorkBuddy 回滚操作路径对话历史 → 找到目标对话轮次 → 点击恢复此版本按钮 → 代码文件自动还原到该时间点状态。整个操作不超过3秒。 实战案例某次在做表单验证重构AI把已有的自定义校验逻辑全部替换掉了用了一个更优雅但完全不符合业务规则的写法。发现时已经改了15个文件。直接在WorkBuddy里回滚到重构开始前的那一轮对话15个文件同时恢复30秒搞定。如果手动处理估计要花两小时。这个功能的意义不只是撤销而是让你可以无损试错。改一个思路不行回滚换另一个思路两个方向的代价是一样的——这才是AI辅助开发应该有的安全感。第七关对话越长AI越容易发飘对话越长早期内容在AI的注意力权重中占比越低——这不是bug是机制AI的注意力机制决定了对话越长早期内容权重越低。对话到30轮以后你会发现AI开始写出和之前风格不一致的代码或者把已经解决的bug重新引入。不是AI变笨了是上下文窗口满了。Prompt模板 · 新会话背景交接展开代码语言TXT自动换行AI代码解释## 项目背景## 项目背景新会话交接用 ### 项目状态 - 当前阶段用户模块开发中已完成注册/登录下一步做权限管理 - 技术栈React 18 NestJS PostgreSQL - 代码仓库已提交至 feature/user-module 分支 ### 已确认的技术决策 - 权限模型RBAC角色-权限而非ABAC原因是业务简单 - 前端状态Zustand不用Redux团队熟悉度原因 - API版本/api/v2v1已废弃但要兼容6个月 ### 已解决的问题不要重新引入 - 多租户隔离通过中间件注入tenantId所有查询都加 WHERE tenant_id ? - JWT刷新采用双token方案access 15分钟refresh 7天 ### 本次任务 帮我实现权限管理模块先从数据库设计开始然后是接口定义最后再写代码。 # 粘贴这段到新会话开头AI立刻进入状态处理方法有两种分场景用一种是WorkBuddy里的Compact功能把当前对话的关键内容压缩成一个结构化摘要保留核心上下文然后继续对话。适合一个功能还没做完但对话已经很长的情况。另一种是主动开新会话每完成一个重要功能里程碑就开一个新会话。把当前项目状态、核心约束、接下来要做什么整理成一段背景说明放在新会话开头。让AI重新入职。 龙虾OpenClaw 会话归档完成阶段性功能后让AI帮你生成上面这样的交接文档存入知识库。下次新会话直接引用不用手写。上下文管理是AI辅助开发里最被忽视、影响最大的细节。一个处理得好的团队AI表现稳定处理不好的到后期AI就开始乱改。第八关Git不是可选项是必选项很多人的节奏是AI改完能跑继续。Git等整个功能做完了再提交。这是在和自己赌博。AI不是每一步都能完美测试中间状态随时可能出问题。出了问题没有Git记录你不知道上一个能跑的状态在哪里。很多人的节奏是AI改完能跑继续。Git等整个功能做完了再提交。正确的提交节奏是展开代码语言TXT自动换行AI代码解释# 开始一个功# 开始一个功能前 git commit -m chore: snapshot before [功能名] development # AI完成一个子任务基本测试通过 git commit -m feat(user): add login API with JWT auth # 整个功能完成 git commit -m feat(user): complete user authentication module - Implement login/register endpoints - Add JWT refresh token strategy - Integrate Redis token blacklist - Add unit tests for auth service (coverage 85%) # 让AI帮你写commit message # WorkBuddy里选中改动 → 右键 → AI生成Commit信息WorkBuddy有Git集成可以让AI帮你写commit message甚至自动提交。但什么时候提交、这次改动是否值得提交你自己来判断。AI记不住之前是什么样它没有自我保护意识只有你有。第九关注释、日志、测试——这三件事AI比你勤快很多人的目标是实现功能。功能跑通收工。注释有时间再说测试先上线再说日志出了问题再加。某天出了问题对着没有注释、没有日志的代码不知道从哪里下手。AI在这三件事上做得非常好而且不会嫌烦。你可以直接让它Prompt模板 · 注释规范要求展开代码语言TXT自动换行AI代码解释给以下代码添加给以下代码添加注释要求 1. 函数头部用JSDoc格式包含 param、returns、throws 2. 复杂业务逻辑前加注释重点解释为什么而不是是什么 3. 每个判断分支if/else说明业务含义 4. 不要给显而易见的代码加注释比如 i 就不用注释了 特别注意 - 注释用中文 - 如果某段代码有坑或需要注意的地方加 [WARNING] 标记 - 如果依赖某个外部假设比如调用前必须先鉴权显式写出来 [粘贴你的代码]Prompt模板 · 结构化日志展开代码语言TXT自动换行AI代码解释给这个接口添加给这个接口添加生产级结构化日志要求 日志级别规范 - INFO正常流程关键节点请求进入、处理完成 - WARN非预期但可恢复的情况重试、降级 - ERROR需要人工介入的错误 每条日志的JSON格式 { level: info/warn/error, timestamp: ISO8601, traceId: 从请求头或生成, userId: 如果有的话, action: 操作名称, duration: 耗时ms仅在完成时记录, data: {}, // 关键业务数据 error: {} // 仅在error级别时 } 注意 - 敏感信息密码、token不要打进日志 - 记录请求参数时做脱敏处理 [粘贴你的接口代码]Prompt模板 · 单元测试生成展开代码语言TXT自动换行AI代码解释为以下函数生成为以下函数生成完整的单元测试 测试框架Jest TypeScript 测试要求 1. 正常流程至少3个典型输入的预期输出 2. 边界条件空值、零值、最大值、最小值 3. 异常情况非法输入、网络错误、数据库异常 4. Mock要求外部依赖数据库、Redis、第三方API全部Mock 测试结构要求 - 用 describe 分组组名对应被测场景 - 用 it 描述具体测试描述要业务化不要写should return true要写当用户余额足够时扣款应该成功 - 每个测试独立不依赖其他测试的状态 额外要求 - 生成测试后告诉我当前覆盖率估算以及哪些分支还没覆盖 [粘贴你的函数代码]AI在这三件事上几乎不需要修改直接能用。而这些事情如果靠人往往是最容易在压力下省略的。工程质量不只是功能跑通还有可维护性。让AI帮你守住这条线。第十关给AI装工具是投资回报率最高的事大多数人用AI的方式AI写代码我来跑把结果粘贴回去再让AI继续。这个工作流有一个根本的低效你是信息中转站。接上MCP之后AI可以自己做这件事。MCPModel Context Protocol是给AI接外部工具的标准协议。在WorkBuddy里配置好数据库MCPAI可以直接写SQL、执行、看结果、再优化——不需要你在中间传递数据。接上文件系统MCPAI可以直接读写本地文件。接上浏览器MCPAI可以自己打开页面、截图、验证界面效果。展开代码语言JavaScript自动换行AI代码解释{ mc{ mcpServers: { // 让AI直接操作本地文件系统 filesystem: { command: npx, args: [modelcontextprotocol/server-filesystem, /Users/your-name/projects] }, // 让AI直接执行SQL查询 postgres: { command: npx, args: [modelcontextprotocol/server-postgres], env: { POSTGRES_CONNECTION_STRING: postgresql://... } }, // 让AI直接读写浏览器、截图验证界面 playwright: { command: npx, args: [playwright/mcplatest] } } }每接一个MCPAI的能力就扩展一圈你在中间传递信息的工作量就减少一圈。Skill是另一个维度的资产积累。龙虾OpenClaw的Skill市场里有社区贡献的专用工作流API对接、代码审查、测试生成、文档撰写、数据分析……更重要的是这一点当你完成了一个效果很好的工作流让AI帮你把这个流程总结成一个Skill存起来。展开代码语言TXT自动换行AI代码解释我们刚刚完成了一个效果很好的工作流数据库迁移回滚 请把这个流程总结成一个可复用的Skill Skill格式要求 - 名称简洁能看出用途 - 触发条件什么情况下应该使用这个Skill - 前置检查执行前需要确认的事项 - 执行步骤按顺序列出每步说明做什么、为什么 - 常见错误列出过程中可能踩的坑和解决方案 - 回滚方案如果出问题怎么恢复 生成后存储到 ~/.workbuddy/skills/ 目录下。 # 好的Skill是经验的资产化用得越久积累越多下次遇到类似任务直接调用这个Skill不需要重新描述背景、不需要重新校准方向。之前踩过的坑、找到的最优路径都固化在Skill里了。这是AI能力的资产化。用得越久积累越深效率越高。第十一关别想一步做出微信每次只加一个功能每次都有一个能跑的版本——这才是可控的开发节奏这条是野心和工程经验之间的博弈。拿着AI工具很容易产生一种幻觉这次我可以一次做出一个完整的产品。不行。不是AI不够强而是复杂度不会因为AI存在就消失。功能越多模块间依赖越复杂AI越容易在修改时破坏已有功能。不是AI不够强而是复杂度不会因为AI存在就消失。功能越多模块之间的依赖越复杂改一个地方影响一堆地方AI越容易在修改时破坏已有功能。正确的节奏从最小功能点开始跑通提交再加一个。展开代码语言TXT自动换行AI代码解释我要做一个内容我要做一个内容管理系统请帮我拆解成独立的迭代任务 拆解原则 1. 每个任务完成后系统必须处于可独立运行的状态 2. 任务之间的依赖关系要明确哪些必须先完成 3. 每个任务预计代码量小( 200行) / 中(200-500行) / 大( 500行) 4. 大任务必须继续拆分直到所有任务都是小或中 输出格式 - 任务名 - 完成标准怎么算完成了 - 依赖哪些前置任务 - 规模评估 不要给出时间估算只要任务列表。每一步完成都有一个完整可运行的版本。你的进度是可控的风险是局部的出了问题只影响最新加的那一小块。 正确的迭代节奏示例第一个版本Day 1只有新建文章和文章列表能存到数据库能查出来能跑提交。第二个版本Day 2加编辑文章测试编辑和列表联动正常提交。第三个版本Day 3加分类标签只加分类不加筛选测试通过提交。每一步完成都有一个完整可运行的版本。出了问题只影响最新加的那一小块。WorkBuddy的任务拆解功能可以帮你把大需求拆成独立的小任务每个小任务单独对话完成不互相污染。软件开发从来不是一次成型的。AI帮不了你跳过迭代它只能让每次迭代更快。第十二关开发规范没有消失它有了新名字很多人进入AI时代把以前的工程规范全放下了觉得AI帮你写代码风格统一不再是问题。实际情况是没有规范AI每次生成的代码风格都不一样文件命名方式不同错误处理逻辑不同日志格式不同。一个项目里有AI的多种风格维护成本很高团队协作也会出问题。规范在AI时代变得更重要因为你需要约束的不只是人还有AI。WorkBuddy里有一个叫做Rule的功能就是这个用途。你把团队的规范写进去展开代码语言TXT自动换行AI代码解释## 命名规范 - 文件kebab-caseuser-profile.tsx不是 userProfile.tsx - 组件PascalCaseUserProfile不是 user_profile - 函数camelCase动词开头getUserById不是 userById - 常量SCREAMING_SNAKE_CASEMAX_RETRY_COUNT ## 目录结构 src/ ├── modules/ # 业务模块每个模块自包含 │ └── user/ │ ├── dto/ # 数据传输对象 │ ├── entities/ # 数据库实体 │ └── *.service.ts, *.controller.ts ├── common/ # 跨模块公共代码 └── config/ # 配置文件 ## 禁止事项 - 禁止在Controller里写业务逻辑放Service - 禁止直接 console.log用Logger服务 - 禁止硬编码魔法数字定义常量 - 禁止 any 类型用 unknown 类型守卫 ## 接口规范 所有接口返回格式 { code: 0, data: T, message: success } 错误格式 { code: 40001, data: null, message: 具体错误描述 } Rule配置后的效果配置好Rule之后AI每次生成代码都自动遵守这些约定你不需要在每次对话里重复强调。团队里每个成员用的AI也会产出风格一致的代码Code Review压力大幅下降。以前叫开发规范现在叫Rule。本质没变让一群人和现在的AI协作需要共同遵守的约定。最后说一句实话AI不是万能的。在推理深度、创造性判断、理解复杂业务背景这些地方它依然有明显局限。但在代码生成、文档整理、测试覆盖、方案提案这些日常工作上它已经做得比很多初中级工程师好了。你要做的不是和它比谁写代码写得快——那场比赛你已经输了。你要做的是学会指挥它、审查它、在它走偏时及时纠正把它的能力用到正确的地方。龙虾OpenClaw的热度会过。WorkBuddy也会迭代总有更强的工具出来。爱马仕热过龙虾热过下一个不知道是什么但一定还会有。工具会更换但懂得有效使用AI的能力不会过时。就像以前会用搜索引擎和不会用的人差距不在工具在思维方式。学得慢等你反应过来这轮机会已经过去了。