从需求到落地：我用 WorkBuddy 搭建询报价管理系统 + 批量文档流水线的实战全记录

一个人的开发容量，两个人的产出。本文记录我用 WorkBuddy 完整推进一套业务管理系统的全过程，含可直接抄的提示词模板和避坑清单。

一、背景：为什么是 WorkBuddy

我在一家企业负责业务系统开发，手上的活儿很杂：一套集成化的询价/报价管理系统（含供应商门户）、产品库、客户管理，还要兼顾软件操作文档的编写、校对和格式转换。

传统做法是：需求文档自己写、代码自己敲、文档自己排版。人肉推进，一个模块一个模块磨。用了 WorkBuddy 之后，最大的变化是——我只需要把需求想清楚，执行交给它。

这不是一篇软文，是一份可以照抄的实战记录。

二、实战一：用"编号列表"把需求变成系统架构

2.1 我的做法

WorkBuddy 对结构化需求的理解远好于大段口语描述。我每次下需求都用编号列表，例如：

给出边界比堆功能更重要。我会明确写"本期不做"的内容（比如微信生态集成放到二期），避免 Agent 自作主张扩大范围。

2.2 关键经验

1. 需求按模块拆分，一次只推进一个模块。整套需求一次丢过去，得到的方案会偏泛；单模块推进，产出直接能进代码。
2. 先让它出方案再让它写代码。让它先输出功能清单和数据结构设计，人工确认后再进入实现，返工率大幅下降。
3. 先去 GitHub 调研再动手。我给 Agent 的指令里明确要求"先找同类开源项目对比后再设计"，避免闭门造车。它调研后给出的技术选型，比我拍脑袋的方案靠谱。

三、实战二：供应商门户——自助操作体验是关键

供应商门户是这个系统里交互最重的部分。我的提示词核心是描述"角色"和"场景"而不是堆界面字段：

让 WorkBuddy 先产出页面流程图和交互说明，确认逻辑闭环后再生成前端页面。这一步省下的不只是写代码的时间——是本来要花在"口头讲需求、开发理解偏差、来回改"上的沟通时间。

四、实战三：批量文档处理——校对、公文排版、PDF 转换一条龙

这是让我彻底服气的一个场景。软件操作文档要定期更新，以前每次改版都是体力活：错别字校对、编号修正、格式统一、导出 PDF。

现在流程是：

1. 把 .docx 直接丢给 WorkBuddy
2. 一句话指令："校对全文错别字和编号，按公文格式排版后转 PDF"
3. 检查产物，收工

几个实测有效的点：

• Word 列表自动编号经常出现"一、一、""二、二、"这种重复编号，人工排查很痛苦，批量修正一次搞定
• 排版能对齐党政机关公文国标（标题、字体字号、行距、表格、图题），不用手动调格式刷
• PDF 转换在流程末尾自动完成，不需要单独开 Office 操作一遍

批量场景才是 Agent 相对人工的绝对优势区：一份文档人工校排 30 分钟，十份就是一下午；Agent 处理十份和处理一份的边际成本几乎为零。

五、避坑清单（踩过的坑，直接绕行）

1. 别用模糊指令。"帮我优化下文档"不如"校对错别字、修正编号、按 GB/T 9704 排版、导出 PDF"——后者可验收，前者看运气。
2. 外部动作要留给自己确认。涉及发布、发送类的操作，让 Agent 出稿、人来执行，安全和效率兼得。
3. 一次任务一个目标。既要写代码又要改文档还顺便调研，拆成三个任务并行，每个的质量都更高。
4. 要求它同步更新文档。功能变了让 Agent 顺手更新 README 和接口文档，不然文档过期比没有文档更害人。
5. 旧环境依赖提前说清楚。我们项目里有 .NET 3.5 这类老框架依赖，环境准备的坑提前告知 Agent，能省不少来回。

六、效果量化

（注：以上为个人项目实测数据，具体因项目规模而异。）

七、总结

WorkBuddy 对我最大的价值不是"写得快"，而是把"想清楚"和"做出来"之间的距离缩短了。需求用编号列表表达清楚，剩下的拆解、执行、文档同步都有人接住。

如果你也是一个人扛一摊事的开发者/负责人，建议从这三步开始：

1. 挑一个重复性最高的文档任务先跑通（见效最快）
2. 再用它做系统设计的初稿产出（省沟通成本）
3. 最后让它进代码开发主流程（收益最大但要求最高）