业务人员用 WorkBuddy 自己搞开发？踩坑踩到怀疑人生

前两天，公司业务部门的小李逢人便说：我要用workbuddy搭套"合同评审系统"，以后再也不用找信息部门了，也给公司省了外包费，以后我们自己搞系统就行了"。

老杨回了一句：「你先别高兴，坑还在后头。」

以上这个场景，是不是有点似曾相识？

最近这段时间关于 WorkBuddy 这类"会写代码的AI工具"火得不得了，口号一个比一个诱人：业务人员零基础也能开发软件。老杨在圈里混了快二十年，见过太多"自己搞系统"的热血故事，到头来多半是——开头很猛，中间很乱，上线即翻车，末了还是灰溜溜回来求 IT。

今天老杨就借小李这个项目，把业务人员用 WorkBuddy 搞软件开发的完整链路，从认知、需求、规划、编写、生成、上线到运维，层层分析，不是教你怎么用，是告诉你：哪一步最容易踩坑，怎么绕。

一、先认识 WorkBuddy：它是长工，不是许愿池

小李犯的第一个错，在动手之前就犯了。

他跟我说："杨老师，我准备用 WorkBuddy 给部门做个合同评审系统。"我问他准备怎么做，他说："很简单啊，我就跟它说，帮我做个合同评审系统，它不就出来了？"

这就是绝大多数业务人员对AI工具的第一误解。WorkBuddy 能写代码不假，但它不是许愿池。你扔一句话，它真能吐出个能跑的壳，可那壳里装的是它替你瞎编的逻辑——字段、流程、规则，全是它"觉得应该是这样"。你不懂，它编织的美丽谎言就这样一直错下去。

老杨在这个环节总结三个“坑”送给搞系统的业务人：不要把"聊天"当"开发"，不要把"生成"当"完成"，不要把"工具"当"替身"。WorkBuddy 替你写，但不替你想。业务规则、例外情况、谁来用、怎么管，得你这个懂业务的人拿主意，它替不了。

二、收集需求：别空想，先把现状翻出来

小李的项目是这么来的：他们部门做合同评审全靠微信群甩文件加一张 Excel。销售把合同往群里一丢，领导评审慢、版本乱、谁改了啥说不清，常有条款漏审，返利算错扯皮。小李想搭个"合同评审系统"：录入关键信息、按规则自动流转给评审人、全程留痕、到期提醒。这想法没错，错在后面的每一步。

小李第一个坑，栽在"收集需求"上。

他跟 WorkBuddy 聊系统时，脑子里想的是"一个完美的系统"。结果 WorkBuddy 给他编出一堆用不上的东西：区块链存证、多语言版本、智能风控评分。小李看着内容很牛叉，但真用起来还是一头雾水——他们部门真的需要这些吗？

坑在哪：业务人员最容易犯的，是"凭空设计系统"，把自己当产品经理。但现实就是你不是，你最值钱的是对现有业务的门儿清，而不是很会设计软件系统。

怎么避：动手前，先把业务现状翻出来。把现在那张 Excel 打开，把微信群里真实的评审对话翻一遍，列出三样：

① 真正在用的字段；

② 真实流转步骤；

③ 谁在用、痛在哪。

然后再拉着财务、销售主管各聊半小时，把评审规则、例外情况问清楚。这些喂给 WorkBuddy，它才会长在你业务上，而不是一本正经的胡说八道，系统所需的功能顿时就明确了。

三、项目规划：一口吃不成胖子，先跑通小闭环

第二个坑，是贪大求全。

小李第一版的系统规划，恨不得把录入、评审、返利计算、报表、移动端、权限一次全做。前三天顺，第四天卡在"返利计算逻辑"上——规则太复杂，算出来和财务对不上。他又改又加，越改越乱，差点把项目扔了。

坑在哪：想一次交付完整系统，范围一蔓延，任何一处卡住都可能前功尽弃。

怎么避：用 MVP 思路，先跑通一个最小闭环。

小李此时该做的是：第一版只做"录入合同 + 自动流转 + 全程留痕"，这三个动作跑通、天天有人用，再慢慢加"到期提醒""返利计算""报表"，以此类推，软件开发有时候慢即是快。

四、需求编写：写"说明书"，别甩一句话

第三个坑，在写需求这一步，最隐蔽也最要命。

小李最开始就一句："帮我做个合同评审系统。"WorkBuddy 生成的字段名乱七八糟，评审规则写死在代码里。更离谱的是——公司大量是框架协议，不用逐单评审，可系统默认每单都走全流程，销售天天被通知评审，烦得要死。

坑在哪：一句话的需求，等于把解释权全交给 AI。但它不懂你的例外，就按通用套路来，生成的是"别人的系统"，不是你的。

怎么避：给 WorkBuddy 写一份结构化需求说明书，五个要素缺一不可：

① 角色；② 场景；③ 业务规则；④ 字段；⑤ 例外。

这份说明书你写，它照着落地，出来的才是"你的系统"。

五、生成项目：分步生成、步步验证，别一把梭

第四个坑，在"生成"这一下，最容易心态崩。

小李图省事，让 WorkBuddy 一次性把数据库、前端、后端全生成了。这是业务人员搞开发最常见的错误，代价就是系统一运行满屏报错；改好一个，另三处又崩。看不懂代码，只能干瞪眼。

坑在哪：一把梭生成整套，任何一环出错，你根本分不清是哪的问题，改都不知道从哪下手。

怎么避：让 WorkBuddy 分步来。先生成数据库和页面空壳，跑通一个能打开、能存数据的"空系统"；再一个模块一个模块加功能，每加一个就当场验证、能跑再进下一步。哪步出问题一眼定位，不会牵一发动全身。

六、上线：灰度+指引，别直接甩给全员

第五个坑，是"上线即翻车"的经典剧本。

小李开发的系统一跑通，兴奋，直接拉全员来用系统。结果第一天就乱套：销售不会用，乱填字段；评审人收不到提醒（权限没配）；领导打开一脸懵，以为又是个花架子。群里吐槽一片，这个项目差点被叫停。

坑在哪：你把"能跑"当成"能上线"，跳过了培训和灰度测试环节，要知道真实用户的手比你想象的笨、但场景的应用比你设想的野。

怎么避：先找 3 个销售 + 1 个领导，灰度试用两周。这期间把权限配好、提醒调通，顺手出一份两页纸操作指引。等这小撮人用顺了、没大毛病，再扩到全员。

七、运维：生成不是终点，留好三样东西

第六个坑，最容易被忽略——以为生成完就完事。系统跑起来，小李觉得大功告成，转头忙别的。结果几天后，业务领导要加"客户信用额度校验"。小李让 WorkBuddy 改，改完了却产生了新 的bug，评审提醒全部失灵，甚至有的功能页面也变了，他看不懂代码，不知道问题出在哪里，最后还是灰溜溜找 IT 救火，前后又折腾一周。

坑在哪：业务系统不是一次性工程，业务一变它就得出问题。你不会代码，又没留交接材料，出问题只能抓瞎。

怎么避：生成时就要 WorkBuddy 同步产出三样：

① 操作文档；② 改动说明（每段干嘛、谁动的）；③ 建个反馈群，谁用着不对劲立刻说。

关键改动，别自己闷头让 AI 改，找懂点技术的人来复核。

八、老杨的避坑六步法

业务人员用 WorkBuddy 搞开发，记牢这六步：

第一，先看业务现状，别空想系统；

第二，MVP 小闭环，别一口吃成胖子；

第三，写结构化需求说明书，别甩一句话；

第四，分步生成、步步验证，别一把梭；

第五，灰度上线+操作指引，别直接甩全员；

第六，留文档、建反馈、关键改动找人复核，别生成即终点。

最后总结一下：

老杨认为，业务人员用 WorkBuddy 自己搞软件，不是不行，是大有可为——它真正的好处，是让最懂业务的人，亲手把系统做出来，不用排队等 IT、不用被外包忽悠。但它不是许愿池，它检验的是你对自己业务的熟知程度，要什么、例外是什么、谁来用；如果你糊里糊涂，它就戏精附体，一本正经的胡说八道满足你的情绪价值，结果做出的系统根本没法用。

让业务部门"自己搞系统"的老板，请先回答老杨一个问题：你舍得让业务人员花时间把需求、规则、例外写清楚吗？舍得给他们试错的空间吗？要是只想扔句话就要个系统，那生成的不是系统，而是一堆烂尾工程。