大三软件工程在读。年初接了几单软著申报的技术材料需求，被迫从零开始学怎么用AI同时产出能跑的代码和能交的操作说明书。这篇是我的完整复盘。
一、起因：软著的申请需要前后端代码和操作说明书
事情是这样的。今年年初，我通过学长介绍接了几单软著申报的技术材料撰写需求。四套系统——三套工业物联网的（大圆机伺服电机控制、力矩波动分析、车间群控），一套文旅SaaS（酒店和门票联动运营）。
软著申报需要的材料不光是一份操作说明书。对方发来的需求是：每套系统既要有完整的前后端代码，又要有配套的操作说明书。 代码要能跑通，操作说明书要规范，都得能过审核，并且时间仅仅有15天左右。
我打开第一个系统的需求，看到“大圆机伺服电机同步控制”这几个字的时候整个人是懵的。大圆机是什么？伺服电机怎么同步？轨迹规划又是什么东西？我一个都没见过。
并且四套系统如果纯手写，至少要两个月，根本赶不上交付节点。
我当时想：豆包可以做操作说明书的文案部分；Cursor能写代码；ChatGPT可以生成对Cursor的提示词——所以能不能用AI把代码和操作说明书一起搞定？ 我就想试试看吧。结果这一试踩了不少坑，但也摸索出了一套完整的方法。最终四套系统全部交付——代码能跑，操作说明书能看，全部通过审核。以下是我的完整复盘。
二、我的工作流：三个工具各司其职，串成一条线
一开始我把代码和文档混在一起做，结果两边都做不好。后来我根据每个AI工具的特点，摸索出了一套串联流程——上一步的输出就是下一步的输入，首尾呼应，其流程图如下所示：
为什么这样选工具？
豆包的语言能力更强，文本产出更符合中文表达习惯，所以我让它做两件事：开头帮我“摸底”领域知识，结尾帮我根据截图生成操作说明书文案。
ChatGPT在生成结构化指令方面更强，而且它产出的Prompt风格和Cursor适配度很高。所以我让它做中间的“翻译器”——把我的意图转化成Cursor能精确执行的编码指令。
Cursor就不用说了，专注写代码，产出的代码质量比通用对话工具高。
具体流程分四步：
第一步：豆包“摸底”——帮我搞懂这系统到底是什么
我对大圆机、伺服电机、力矩波动这些工业概念完全没概念。每个系统拿到需求之后，先用豆包了解大致情况——这个系统是干什么的、核心功能有哪些、涉及哪些专业术语。比如我会问：
“大圆机是什么设备？伺服电机同步控制一般涉及哪些参数？轨迹规划是什么意思？”
这个阶段的目标不是让豆包写出能用的内容，而是帮我把陌生领域的“黑话”翻译成我能理解的东西。有了基础认知，后面才知道让ChatGPT往哪个方向写指令、让Cursor写什么功能。
第二步：ChatGPT生成对Cursor的提示词
对系统有了理解之后，我先自己设计好架构——功能模块怎么划分、API路由怎么组织、数据库怎么设计。然后把方案投喂给ChatGPT，让它生成给Cursor的具体编码指令。
比如我会对ChatGPT说：
我要用Node.js+Express写一个伺服电机管理系统的后端。请生成一段给Cursor的提示词，要求它完成“电机启动”接口：接收电机ID，先判断当前状态，如果已经在运行就返回提示，否则改状态为running，更新日志，返回成功。
ChatGPT产出的不是代码，而是给Cursor用的、带约束条件的提示词。这比我直接对Cursor说“帮我写电机启动接口”质量高很多——ChatGPT会自动补全参数校验、异常处理、日志记录这些细节要求。
第三步：Cursor写代码 → 本地跑通 → 截图
Cursor拿到提示词后生成代码。我在本地跑起来，npm start看能不能启动、前端页面能不能打开、接口通不通。跑通了就逐个页面截图——登录、设备列表、力矩监控、停机记录，每个关键界面截一张。
如果报错，把报错信息喂回ChatGPT要修复方案，再让Cursor改，循环到跑通为止。
第四步：豆包“收尾”——根据截图生成操作说明书文案
所有核心页面截图准备好之后，连同之前ChatGPT生成的那些提示词一起，依次投给豆包。因为提示词里已经包含了页面功能描述和参数说明，加上截图里的界面元素，豆包就能产出贴合实际系统的文案。每张图配上指令：
这是大圆机力矩监控系统的“力矩监控”页面截图。请写一段操作说明书文案：描述页面展示的数据指标，解释绿/黄/红三色标识的工况含义，说明管理员看到红色报警后的操作。语言短句、主动语态，适合操作工人阅读。
豆包产出每段文案后，我逐段校验——逻辑对不对、步骤全不全、格式规不规范——然后在Word里统一排版成完整的操作说明书。
整个流程串起来就是：
豆包摸底（搞懂领域）→ ChatGPT翻译（生成编码指令）→ Cursor执行（写代码）→ 我跑通截图 → 豆包收尾（根据截图和提示词写文案）→ 我校验排版
三个工具根据各自特点各司其职：
- 豆包：语言能力强，中文表达自然，负责首尾两端的“理解”和“输出”
- ChatGPT：结构化指令强，和Cursor适配度高，负责中间的“翻译”
- Cursor：专注写代码，负责执行
整个过程是串联的，不是并行的。上一步的产出就是下一步的输入，中间断一环都不行。
三、文档写作的Prompt设计：角色锚定法
我总结出的Prompt公式：
角色锚定（你是谁+写给谁看） + 任务拆解（分步告诉AI要写什么） + 输出约束
= 能用的初稿
下面是我做的一个简易对比 ：
四、代码生成的真实体验：两个关键时刻
第三部分我总结了Prompt设计的公式，文字说起来轻飘飘，但代码这边用起来完全是另一回事。有两个时刻让我最难忘。
第一个时刻：电机启动的边界条件bug
前面说了我写伺服电机控制系统。为了让Cursor生成的代码风格统一，我先通过ChatGPT给它生成了一个角色锚定指令：
你是一名有十年经验的Node.js后端工程师，擅长工业物联网系统的API设计，代码风格简洁、命名规范、所有接口必须有参数校验和状态判断。
设定完之后让它写“电机启动”的接口。Cursor很快产出了：接收电机ID，查数据库，改状态为running，返回成功。看起来对。
我本地一跑，bug直接出来了——如果电机已经在运行状态，再点启动，接口照样执行一遍，不报错也不提醒。真要上线的话，操作工人多点几下，系统数据就乱了。
我把报错截图喂给ChatGPT要修复方案，它指出问题：缺少前置状态校验。修复之后是这样的——启动前先判断当前状态，如果已经是running，直接返回“电机已处于运行状态”，不往下走。
这个bug让我明白：AI角色再清楚，也猜不到你没明确说出口的业务规则。边界条件、状态校验、异常处理——这些“你没说，它就不会做”的逻辑，得你自己发现。
第二个时刻：大圆机车间群控系统的结构塌方
我第一次写群控系统的时候偷懒了，直接对Cursor说：“帮我写一个大圆机车间群控管理系统，包含设备管理、生产任务调度、数据统计、操作日志。”
AI很自信地开始吐代码。跑完之后我打开项目目录，傻了——几个文件体量严重失衡，路由文件几百行塞在一起，有的模块又只有一个空壳，增删改查逻辑混在一起。根本没法调，改一个地方崩一片。
后来我换了个方法：先自己定目录结构和功能模块划分，再分块让AI写。
比如先建好后端路由骨架：
routes/
├── deviceRoutes.js → 设备管理（增删改查）
├── taskRoutes.js → 生产任务调度
├── statsRoutes.js → 数据统计
└── logRoutes.js → 操作日志
然后依次告诉Cursor：“现在写deviceRoutes.js，包含获取设备列表、添加设备、编辑设备、删除设备、更新设备状态这五个接口，用Express框架，数据存JSON文件。”写完之后再下一个。
这样做之后效率提升很多：
- 结构是你控制的，出了问题你知道去哪个文件改
- 每个文件体量合理，AI不会写出一坨几百行的大函数
- 面试的时候你能说清楚“我设计了什么，AI帮我写了什么”
这两个时刻教会我同一件事：AI写得快，但你不主导，它一定跑偏。 主导不是说你得比AI会写代码，而是你得比AI清楚“我要什么东西、这个东西长什么样”。
五、校验和迭代：两层标准，各查各的
代码的校验和文档不一样。文档你能用眼睛一行行看，代码必须跑起来才知道对不对。
代码校验我走五步：
- 看结构：文件拆分是否合理，API接口是否对应功能模块，有没有几百行的大文件
- 本地跑起来：
npm start能不能成功启动，前端页面能不能打开，控制台有没有报红 - 功能点抽检：不全部测，但登录、新增、删除、编辑这几个核心操作必须逐个过
- 报错 → 问AI → 改 → 再跑：这四步循环是最费时间的，但也绕不开。每次报错截图问ChatGPT，拿到修复方案后回Cursor改完再跑一遍
- 一个反复踩到的坑：AI写的删除功能经常是“伪删除”——界面显示已删除了，但数据文件里记录还在。这个问题我在三套系统里都碰到过。后来学乖了，每次测完删除功能直接打开data.json确认有没有真的移除
文档校验是另一套逻辑——不用跑，但要用眼睛细看：
- 逻辑一致性：AI写的功能描述和系统实际功能是不是一致？比如简介里写了“支持多角色权限管理”，但系统实际只有管理员一个角色——那就是写多了
- 步骤完整性：假设一个从来没看过系统的人照着操作步骤做，能不能完成？AI最容易跳步，比如写“填写设备信息后点击保存”，但漏了“先选择设备类型”这一步
- 格式规范性：标题层级是不是统一的、截图标注位置对不对、不同模块的描述风格是不是一致的
我还整理了一份“AI写操作说明书常见问题清单”，每份文档校验的时候对着过一遍——逻辑矛盾、步骤跳步、表述模糊、术语混用。这套清单是在四个项目里反复碰壁攒下来的，后面写文旅系统的时候效率就高了很多，因为大部分常见问题提前避开了。
总结下来就是：代码靠跑，文档靠看。两边的检验都不能省，省了交付的时候一定炸。
六、最终成果和我的总结
整套项目做完，最终交付：
- 四套系统的完整前后端代码，可本地运行
- 四套系统操作说明书，累计约一万五千多字
- 涵盖工业物联网和文旅SaaS两个完全不同领域
- 全部通过了软著申报的审核
成果展示：
复盘下来，我最大的两个认知：
关于AI写文档： AI不会主动写出能交付的好内容，但一个能拆解需求、设计Prompt、建立校验标准的人，可以用AI高效做到。核心能力不是“跟AI聊天”，是理解需求、拆任务、定标准、改到位。
关于AI写代码： AI写代码是真的快，但它写的代码你不能直接用。你得当那个“懂业务逻辑、知道边界条件在哪、能定位bug”的人。AI是你的加速器，不是你的替代品。
如果这篇文章让你对我做的事有更多了解，欢迎联系我交流。
附：四套系统的操作说明书样本（已脱敏），可以点击这里查看：docs.qq.com/doc/DSXpzTF…
