ARTICLE · 1317374
从一份IPD流程文档到一个能对话的智能体:产品开发助手的诞生记
从一份IPD流程文档到一个能对话的智能体:产品开发助手的诞生记 当496行的流程规范变成可以问答的AI助手，产品开发团队少走了哪些弯路？ 做产品开发的人都知道，IPD流程有多复杂。 5个阶段、6个技术评审点、13个职能代表，每个角色在不同阶段要做什么、交什么材料、找谁审批，光是一份流程文档就有496行。新来的PDT经理翻三遍也未必理得清，更别说13个职能代表各自还要关注自己领域的细节。 我们试着把这份流程文档变成了一个可以对话的智能体。现在，任何人打开网页就能问：'我现在在概念阶段，下一步该做什么？''TR4评审需要哪些交付件？''发现技术异常该找谁？'——AI会基于流程规范直接给出答案。 这篇文章记录的是，一个不懂代码的业务顾问，怎样用现成的工具把这个想法变成了实际可用的产品。 为什么要做这件事 我们公司有一套完整的产品开发流程，从概念到上市，每个阶段都有明确的输入、输出和评审要求。这套流程是多年积累的经验，也是质量体系的基础。 但流程文档有个天然的问题：它写得很完整，读起来却很费劲。 PDT经理想知道'计划阶段的关键节点是什么'，他需要在496行文档里找到第3章的3.2节，再对照附录的模板清单。质量代表要准备TR5评审，得先翻到4.4.1.3看自己的职责，再去查TR评审的交付件要求。 每个人都只关心自己当下的问题，但流程文档是按体系结构写的，不是按问题组织的。 这就是我们想解决的：能不能有一个助手，你问它具体问题，它基于流程文档给你准确答案？不用翻文档，不用猜术语，打开就能用。 
用户上传知识文档，配置智能体，前端通过后端代理调用API，AI基于文档回答问题。 从想法到原型的三天 我一开始没打算自己开发。市面上有很多AI对话工具，但要么太通用，要么需要写代码配置。我是做业务咨询的，不是程序员。 后来老师讲解了Qoder Cloud Agent平台，说可以上传知识文件、配置系统提示词、生成API接口，最关键的是有现成的React前端模板。 第一天，我把《产品开发流程.md》上传到平台，配置了智能体的基本信息。这个文件有62KB，496行，覆盖了5个阶段、6个TR评审点、13个职能角色的完整职责。 第二天，我写了系统提示词。核心思路是：你是产品开发流程助手，基于上传的流程文档回答PDT经理和13个职能代表的问题。如果问题超出文档范围，明确告知无法回答。 第三天，我在平台的测试界面验证了10个典型场景。从'概念阶段的主要任务是什么'到'发现技术异常如何处理'，AI都能基于文档给出准确回答。10个测试用例全部通过。 到这里，原型已经跑通了。但原型不等于产品——用户不可能每次都登录平台后台去提问，他们需要一个自己的网页界面。 前端开发：从登录到对话 前端项目是用React + TypeScript + Vite搭建的，UI组件库选了Ant Design。这些都是现成的模板，我只需要调整业务逻辑。 第一个要解决的是用户身份问题。我们的系统要支持多个企业、多种角色登录。PDT经理看到的界面和职能代表不完全一样，不同角色的权限和关注点不同。 登录页设计得很简单：选择企业、选择角色、进入系统。没有复杂的注册流程，因为这是内部工具，用户名单是可控的。 进入系统后是工作台。工作台有四个核心模块：任务清单、异常处理、知识库、用户管理。任务清单展示当前角色在各阶段需要完成的工作；异常处理用于记录和跟踪开发过程中的问题；知识库就是AI对话入口；用户管理是管理员功能。 知识库页面的AI对话界面是重点。我做了消息气泡样式、流式打字机效果、快速问题按钮。用户可以直接输入问题，也可以点击预设的常见问题快速提问。 流式回复的实现有个小细节：前端每1秒轮询一次API，获取到完整响应后，按每10毫秒一个字的速度逐字显示，模拟打字机效果。这样用户体验更自然，不会突然跳出一大段文字。 后端：保护API令牌不暴露 前端做好后，我发现一个问题：QCA平台的API令牌如果直接写在前端代码里，任何人都能从浏览器开发者工具看到。这是安全隐患。 解决方案是加一层后端代理。我用Node.js + Express搭了一个简单的后端服务，前端所有对QCA API的调用都先发给后端，后端再转发给QCA平台。这样API令牌只存在后端的.env文件里，前端看不到。 后端还承担了简单的文件存储功能。用户的任务数据、异常记录都存在服务器的JSON文件里。对于原型阶段，这够用了。后续如果要支持更多用户、更复杂的查询，可以升级到数据库。 这里有个踩坑经验：后端server.js文件开头必须加import 'dotenv/config'，否则.env文件不会被加载，API调用会报TOKEN_INVALID错误。我排查这个问题花了半小时。 部署上线：从本地到公网 本地开发环境跑通后，下一步是部署到公网，让其他同事能通过浏览器访问。 我选了阿里云ECS，2核4G配置，Ubuntu 22.04系统。安全组开放了80、443、3000、22四个端口。 部署架构是：Nginx监听80端口，反向代理到后端的3000端口；后端用PM2管理进程，同时提供静态文件服务和API代理。 部署过程有几个坑： 第一，前端构建产物要复制到后端的public目录。因为server.js是从这个目录读取静态文件的，不是从前端项目的dist目录。 第二，服务器上之前有个项目的Nginx配置强制HTTPS 301跳转，导致HTTP访问被重定向。我花了一些时间才定位到这个冲突，移除那段配置后恢复正常。 第三，.env.production文件里不能包含敏感信息，API令牌只能放在后端的.env文件里。前端环境变量只配置非敏感的API地址。 部署完成后，我访问公网，登录页正常显示，进入系统后AI对话功能可用。从本地开发到公网访问，整个过程用了两天。 
本地验证通过后，部署到阿里云ECS，配置Nginx反向代理和PM2进程管理 API集成的三个教训 回顾整个开发过程，API集成部分踩的坑最多。总结三个教训： 第一，API域名要核对清楚。Qoder平台的API地址是api.qoder.com.cn，不是api.qoder.com。我第一次配置时写错了，导致所有请求都返回TOKEN_INVALID。排查了半天才发现是域名问题。 第二，SDK不等于最优解。QCA平台提供了Node.js SDK，导出的是ManagedClient类。但我试了一下，发现直接用REST API更简单灵活。SDK封装了一层抽象，反而增加了理解成本。对于简单的代理场景，直接调用API就够了。 第三，生产环境必须用后端代理。前端不能直接暴露API令牌，这是基本的安全原则。即使用CORS解决了跨域问题，令牌暴露在前端仍然是风险。加一层后端代理，令牌只存在服务器环境变量里，前端完全看不到。 接下来要做的事 现在系统已经上线可用，但还有很多可以改进的地方。 HTTPS证书还没配置。域名已经备案，接下来要申请SSL证书，把HTTP访问升级为HTTPS。这对于企业级应用是必须的。 数据持久化方案要升级。当前用JSON文件存储数据，适合原型和小规模使用。如果用户量增加，需要迁移到数据库，比如MySQL或PostgreSQL。多用户权限测试还没做。当前系统支持多角色登录，但不同角色的权限控制还没有严格测试。后续要验证：PDT经理能否看到所有任务？职能代表是否只能看到自己领域的任务？管理员能否管理所有用户？ 还有一个更重要的方向：扩展知识库。当前的智能体只基于《产品开发流程.md》一份文档。后续可以把相关的模板、检查表、案例库都加进去，让AI能回答更详细的问题。 最后，我们考虑把这个模式复制到其他流程。IPD流程只是第一个，质量管理流程、供应链管理流程、项目管理流程，都可以用同样的方式做成智能助手。 从一个想法到一个可用的产品，整个过程用了大约一周。 我没有写太多代码，主要是配置、调整和集成。核心工作是理解业务需求、设计用户交互、排查技术问题。 这个项目的价值不在于技术有多复杂，而在于它解决了一个真实的问题：让流程文档从'被动查阅'变成'主动问答'。用户不需要记住流程是怎么组织的，只需要问自己当下的问题，AI会基于规范给出答案。对于其他想做类似尝试的人，我的建议是：先从一个具体的场景开始，用最小的成本验证可行性。不要一开始就追求完美的架构，先让原型跑通，再逐步优化。 流程数字化的第一步，不是买系统，而是让流程本身变得可访问、可问答。
