与 AI 共造一件工具：我用 WorkBuddy 做出「群聊捕手 · AI 社群分析工具」的全过程

从一句模糊的抱怨，到一款可部署的运营工具——这一次，我负责"想清楚要什么"，把"怎么实现"交给了 WorkBuddy。

引子：一个不会写代码的人，也能造工具吗

很长一段时间里，"做一个软件工具"对不会写代码的人来说是一件需要仰仗别人的事——得有产品经理写需求、工程师写代码、测试查漏、运维上线。任何一个环节缺位，想法就只能停留在脑子里。

《群聊捕手》的起点，其实只是一句抱怨：私域运营每天要在动辄几千条的群消息里翻找，最怕漏掉那条本该第一时间回复的客诉。我想要一个能自动把群聊记录分门别类、还能提前预警负面情绪的小工具。

真正让这件事发生的，是 WorkBuddy。这篇文章不谈产品本身的功能有多全，而是想认真记录一次协作实验：当"提出想法的人"和"实现想法的人"合二为一时，一件工具是怎样被造出来的。

一、协作方式的改变：我出想法，它出实现

传统开发是一条流水线，需求、开发、测试、运维分属不同的人和阶段。而与 WorkBuddy 的合作，更像是一个不断收敛的对话闭环——我用自然语言表达意图，它把意图翻译成可运行的东西，我再基于结果给出反馈，如此往复。

这个闭环里，我始终只做一件事：说清楚"要什么"。 我不需要关心用什么框架、目录怎么组织、代码怎么写才优雅——这些"怎么实现"的问题，交给对面那位不知疲倦的伙伴。

它带来的最直接改变是：想法与验证之间的距离被压缩到了几分钟。 过去从"我想要个功能"到"我看到它跑起来"，中间隔着漫长的排期与沟通；现在，隔着的只是一段对话。

二、从一句话到可部署：一次对话贯通全链路

真正动手时，WorkBuddy 把「群聊捕手」的诞生拆成了一条清晰的流水，而这条流水是在同一个对话窗口里一气呵成的。

• 需求对话：我描述场景——面向私域运营、处理 500 人群日均 2000 条消息、要能分级和预警。
• 模块拆解：它主动把工具拆成四大能力——智能分级、情绪预警、线索萃取、话术推荐，并逐一确认逻辑。
• 代码生成：聊天记录解析器、分析引擎、前端仪表盘被依次写出，纯前端计算，保证响应速度。
• 自测校验：它用 Node 对引擎做冒烟测试，还主动发现并修正了一个把运营自己发的广告误判成"商机"的问题。
• 部署交付：最终打包成一个纯静态站点，可直接运行起来，离线也能运行。

让我印象最深的，不是它能写代码——而是它会主动自测、主动发现问题。那个"运营账号误判"的坑，是它在测试后自己指出来并修好的，而不是等我去发现。这种"负责到底"的工作方式，才是它区别于普通代码生成的地方。

三、把 bug 交给对话：反馈即指令

工具做出来只是开始，真正用起来才见真章。第一版上手后，我很快遇到了几个实实在在的问题。而我做的，仅仅是把问题用大白话说给它听。

四类问题，四次对话，四个补丁：示例数据在本地打开时加载失败，它改成内联数据让离线也能用；上传文件后输入框没回填，它补上了回写逻辑；消息分级明细只能切一个类别，它定位到是事件绑定丢失，改用事件委托修好；我想要 PDF 导出，它引入合适的库并解决了中文渲染乱码的细节。

整个过程里，我不需要懂"为什么会出 bug"，只需要说清楚"哪里不对"。 反馈就是指令，一句"这里有问题"，换回来的是一串已经落盘、可以立刻验证的修复。这种确定性，是过去跨团队沟通里很难得到的。

四、一个工作台，五种角色

回过头看整个项目，最触动我的是：一件原本需要一个小团队协作的事，被同一个助手接力完成了。 它在不同阶段扮演着完全不同的角色。

它当产品经理，把我一句模糊的抱怨拆成清晰的需求；当工程师，写出解析器、分析引擎和仪表盘；当测试工程师，跑冒烟测试、揪出误判；当设计与文案，产出宣传封面、流程图乃至这篇文章；最后当运维，把成品部署到创空间。

这并不意味着专业分工不再重要，而是说——对于一个有想法但资源有限的个体，AI 把"从 0 到 1"的门槛显著降低了。它不替代团队的深度，但它填补了个人的广度。

最后：工具的意义，在于放大想法

《群聊捕手》最终是一个能用、好用、可部署的运营工具，但对不会写代码的人而言，它更像一份证据：一个不写代码的人，凭借清晰的想法和一个足够强的协作者，也能把脑中的构想落地成现实。

WorkBuddy 在这个过程里没有替我"决定要做什么"——那始终是我的判断。它做的是把每一个决定，快速、可靠地变成可以运行的结果。技术的价值，从来不在于炫技，而在于让更多人的想法有机会被实现。这一次，我确切地感受到了这一点。