1. 从“功能清单”到“工作流引擎”一次开发思维的范式转移我们这行干久了很容易陷入一种“功能驱动”的惯性思维。每当启动一个新项目无论是个人副业还是团队产品第一反应往往是打开一个文档开始罗列那些我们熟悉得不能再熟悉的“积木块”用户认证、管理后台、个人设置页面、支付集成……我们的大脑被训练成了“名词收集器”。这听起来很合理对吧毕竟没有用户系统怎么管理用户没有后台怎么查看数据但问题恰恰出在这里用户从来不为这些“名词”买单。他们购买的是一个结果一个能将自己从A点问题快速、顺畅地带到B点解决方案的“捷径”。这个“捷径”就是工作流。我经历过太多次这样的循环激情满满地开始一个项目花了两周时间搭建了精美的、带社交登录和邮箱验证的用户系统又用了一周做出了一个功能齐全、响应式的仪表盘。看着代码仓库里日益丰满的目录结构内心充满了“建设”的成就感。然而当真正开始实现那个让项目与众不同的、核心的“魔法”功能时最初的热情已经消耗殆尽剩下的只有疲惫和对“屎山”初现端倪的恐惧。最终项目变成了又一个“80%的样板代码 20%的价值核心”的典型产物而那20%的核心往往也因为精力不济而做得粗糙不堪。这就是“名词陷阱”——它让我们沉迷于构建组件却忘记了我们为何而构建。真正的转变是从思考“它是什么”转向思考“它做什么”。与其说“我们需要一个数据库”不如说“我们需要持久化存储用户每次操作产生的数据”。与其说“集成Stripe”不如说“在用户完成核心任务后安全地收取费用”。这种从“名词”到“动词”的视角切换是区分一个功能堆砌的产品和一个真正解决问题的工具的关键。最近随着AI编程工具的成熟这种“动词优先”的思维模式不仅变得更为重要也获得了前所未有的强大助力。当你能够用自然语言描述一个清晰的工作流并交给AI去实现时开发的重心就从“如何砌砖”彻底转向了“如何设计建筑蓝图”。2. “名词陷阱”的深度剖析与破局之道2.1 为什么我们会本能地陷入“名词思维”这背后有一系列深层原因理解它们有助于我们有意识地对抗这种惯性。首先路径依赖与安全感。认证、CRUD、RESTful API……这些是我们训练有素、肌肉记忆般的技能。从学习编程的第一天起我们就在构建这些组件。当面对一个不确定的新领域时回归到这些熟悉、可控的“名词”上能给我们带来巨大的心理安全感。我们知道怎么做一个登录页面我们知道怎么设计用户表这些是可预测、可完成的任务。相比之下定义和实现一个独特的工作流是模糊的、充满未知的它带来的不是安全感而是焦虑。其次工具与框架的引导。现代Web开发框架无论是React、Vue还是Next.js其核心概念就是“组件化”。我们被教导要将UI拆解成可复用的组件Button, Modal, Form。后端框架则围绕着模型Model、视图View、控制器Controller来组织。这些范式本身没有错它们是工程实践的结晶。但危险在于如果我们不加以警惕就会把“实现手段”误当作“设计目标”。我们开始为“有一个漂亮的组件库”而开发而不是为“解决一个具体的用户任务”而开发。最后“完整性”的幻觉。一个拥有登录、注册、个人中心、后台管理的系统看起来就像一个“完整”的产品。它满足了我们对一个软件“应该有什么”的内在 checklist。这种视觉和结构上的完整性能给我们尤其是向非技术背景的伙伴或投资人展示时带来一种虚假的成就感。我们感觉自己已经构建了产品的“骨架”只差填充“血肉”。但很多时候这个“骨架”可能根本不适合你要承载的“血肉”或者那点“血肉”才是产品的全部价值骨架反而成了负担。注意警惕“技术虚荣心”。我们很容易为自己搭建的精巧技术架构而自豪但用户完全感知不到这些。他们只关心自己的问题是否被更快、更好地解决了。如果你的技术选型不是为了优化核心工作流那就可能只是一种自我满足。2.2 从“名词清单”到“动词清单”PRD的质变一份高质量的产品需求文档是强迫团队进行“动词思维”的最佳工具。传统的PRD可能长这样功能列表名词版用户认证系统邮箱/手机号登录第三方OAuth用户个人资料页面头像、昵称、简介编辑主仪表盘数据显示卡片、图表数据管理列表页支持增删改查、筛选、导出系统设置页面主题、通知偏好Stripe支付集成核心功能XXX模块而一个“动词优先”的PRD则完全不同。它通常从一个核心的用户故事或任务开始核心工作流描述动词版作为一个[用户角色]我想要[完成某个目标]以便于[获得某种价值]。例如对于一个图片背景移除工具作为一个电商卖家我想要快速去除商品图片的杂乱背景以便于制作干净的宣传图提升商品点击率。基于这个核心故事我们提炼出最关键的五组动词通常不超过五个这构成了产品的MVP闭环上传用户从本地或拖拽区域选择一张商品图片。预览与调整系统自动识别主体并移除背景用户可以通过画笔工具微调边缘擦除/恢复。替换/编辑用户可以为透明背景的图片选择一个纯色背景或上传一个新的背景图。下载用户选择输出格式PNG, JPG和分辨率一键下载处理后的图片。管理历史可选但属于工作流延伸用户可以在一个简易列表中查看最近处理过的图片进行重新编辑或再次下载。你会发现在这个列表里没有独立的“用户认证”或“设置”功能。认证动词识别用户可能只是为了让“管理历史”这个动词能跨设备生效。如果“管理历史”对初期用户价值不大那么认证甚至可以推迟。设置动词配置偏好可能初期只需要一个开关“是否在处理后自动弹出下载对话框”。这个开关可以直接放在预览页面的一角而不是一个独立的“设置”页面。这种方法的强制约束力是惊人的。当你只有五个“动词槽位”时每一个都必须精打细算。你会反复拷问自己“这个动作是用户达成最终结果的必经之路吗它是在创造价值还是在管理状态” 这就迫使你和团队聚焦于真正的核心——那个将用户从“问题”带到“结果”的最短路径。3. 构建工作流实操框架与核心环节3.1 如何识别并定义核心工作流定义工作流不是一个拍脑袋的过程它需要经过从抽象到具体的拆解。第一步从问题出发而非从技术出发。拿出一张白纸忘掉所有技术实现。只回答一个问题我的用户最痛的点是什么他/她现在是如何笨拙地解决这个问题的例如用户现在可能是手动在Excel里整理数据 - 复制到某个在线工具 - 下载结果 - 再用PS修改 - 最后上传到某个平台。你的产品就是要将这一串离散、费力的动作整合成一个平滑的、自动化的流程。第二步描绘理想路径。用最简单的语言描述这个流程最理想的、一步接一步的状态。尽量使用“用户点击…”、“系统自动…”、“然后显示…”这样的句式。这就是你的核心工作流剧本。以我之前做过的一个“周报自动生成器”为例理想路径是用户授权连接其任务管理工具如Jira、Trello。系统自动拉取指定时间范围内该用户完成的任务条目。系统利用AI将零散的任务标题和描述归纳成一段结构清晰、语言通顺的周报总结。用户在一个编辑界面内可以对AI生成的周报进行润色、删改。用户一键将周报复制到剪贴板或直接导出为Word/PDF。第三步提取关键动词并技术化映射。将上述剧本中的关键动作提取为动词并思考其技术实现映射连接/授权- OAuth2.0 流程获取API访问令牌。拉取- 调用第三方API处理分页和错误重试。归纳- 构造Prompt调用大语言模型API如OpenAI GPT Anthropic Claude解析返回的JSON。编辑- 实现一个富文本编辑器支持基本的格式和修改。导出- 前端生成Blob对象触发下载或服务端渲染文档。这个映射过程就是你的技术设计方案雏形。你会发现数据库设计、API接口、组件结构都自然围绕着支持这些动词来展开而不是反过来。3.2 工作流驱动的技术设计与实现要点当核心工作流清晰后技术架构会呈现出一种“流式”或“管道式”的特征。后端设计面向流程的服务编排。传统的MVC架构可能依然适用但思维要变。你的Controller不再仅仅是CRUD的代理人而是工作流步骤的协调器。以一个图片处理流程为例# 伪代码示例一个工作流协调器 class ImageProcessingWorkflow: def execute(self, upload_file, user_preferences): # 步骤1: 验证与接收 (动词接收) validation_result self.validator.validate(upload_file) if not validation_result.ok: raise InvalidInputError(validation_result.message) # 步骤2: 持久化存储 (动词存储) file_meta self.storage_service.save(upload_file) # 步骤3: 核心处理 - 背景移除 (动词处理) # 这里可能调用内部算法或第三方API processed_image_url self.ai_processor.remove_background(file_meta.url) # 步骤4: 后处理 (动词调整) # 根据用户偏好如背景色进行二次处理 final_image_url self.post_processor.apply(processed_image_url, user_preferences) # 步骤5: 记录历史并返回结果 (动词记录 返回) self.history_service.record(user_id, file_meta, final_image_url) return WorkflowResult(successTrue, output_urlfinal_image_url, history_id...)你的数据模型设计也应服务于流程。除了核心的业务实体表如图片表、用户表很可能需要一张workflow_execution表记录每一次工作流执行的上下文、步骤状态、输入输出和错误信息这对于监控、调试和提供用户历史记录至关重要。前端设计状态机与引导式UI。前端不再是静态页面的集合而是一个动态的状态机反映工作流的进展。状态定义明确工作流有哪几个状态如空闲、上传中、处理中、编辑中、完成、错误。UI映射每个状态对应一个主要的UI视图。例如“处理中”状态显示一个进度条和预计等待时间“编辑中”状态显示编辑器和工具栏“错误”状态显示友好的错误信息和重试按钮。引导与约束通过UI设计引导用户沿着正确路径前进。禁用与当前状态无关的按钮高亮下一步操作。例如在图片上传完成前“开始处理”按钮是灰色的。这减少了用户的认知负担也防止了非法状态的出现。实操心得在前端使用一个集中的状态管理库如Zustand, Redux Toolkit来管理整个工作流的状态非常有效。将工作流状态、步骤数据、错误信息都放在这里所有组件都根据这个状态来渲染。这样状态逻辑清晰且易于实现“断点续传”或“步骤回退”等高级功能。4. AI原生编辑器如何将“动词PRD”转化为代码这正是当前开发体验中最激动人心的部分。像Cursor、Windsurf、Claude Code等AI原生编辑器不仅仅是更智能的代码补全工具它们本质上是工作流实现加速器。当你持有了一份“动词优先”的、描述清晰的PRD时你与AI协作的效率会产生质变。4.1 与AI协作模式的升级从“代码生成”到“解决方案实现”传统的AI辅助编码更像是“超级自动补全”。你写一个函数名它帮你补全内容你写一句注释它生成一行代码。这当然有用但层次较浅。当你基于工作流进行开发时你可以与AI进行更高层次的对话。低效的提示名词思维“帮我写一个用户登录的React组件要有邮箱和密码框一个提交按钮。”AI会生成一个标准的、你可能在任何教程里看到的登录表单组件。它正确但平庸且与你的核心业务逻辑脱节。高效的提示动词思维结合上下文假设你正在构建一个内部设计工具已经有一个处理设计文件的工作流 “在我们的设计工具项目中用户已经通过Slack OAuth登录了。现在在项目主页我需要一个‘新建项目’的入口。这个操作的核心工作流是用户点击按钮 - 弹出模态框 - 用户输入项目名称并选择一个设计文件模板 - 点击创建 - 系统在后台用模板初始化一个项目并重定向到项目编辑器页面。请为这个‘CreateProjectButton’组件及其相关的模态框和创建逻辑生成代码。使用我们已有的useAuth钩子获取用户信息使用projectApi.create函数调用后端成功后用router.push跳转到/editor/[projectId]。”这个提示词里包含了上下文什么项目、用户已登录、触发动作点击按钮、工作流步骤弹窗、输入、选择、创建、跳转、技术约束使用的特定钩子、API、路由方法。AI基于此生成的代码不再是孤立的片段而是直接嵌入到你现有应用逻辑中的、功能完整的解决方案。它甚至能帮你生成相关的状态管理、错误处理代码。4.2 实践策略将PRD分解为AI可执行的指令一份好的“动词PRD”本身就是一份绝佳的AI提示词提纲。你可以直接将其章节或用户故事复制到编辑器的AI聊天框中作为开发某个模块的总体要求。分步骤实施不要一次性让AI生成整个复杂工作流。按照PRD里定义的动词步骤逐个击破。例如先实现“上传并验证文件”这个步骤完成后再基于这个上下文让AI接着实现“调用处理API并轮询结果”。提供上下文AI编辑器通常有“”引用文件或代码块的功能。在给出指令时引用相关的现有代码文件如已有的API客户端定义、类型接口、工具函数能让AI生成的代码更贴合你的项目结构减少适配成本。要求解释在生成关键或复杂的逻辑代码后可以要求AI“为这段代码添加行内注释解释关键决策点”。这不仅能帮助你理解代码也能在后续维护时提供便利。更重要的是这个过程能检验AI是否真正理解了你的工作流意图。迭代与修正AI生成的代码很少能100%完美运行。当出现错误或不符合预期时将错误信息反馈给AI并清晰地指出当前工作流步骤在哪一环出现了偏差。例如“在‘保存处理结果’这一步你生成的函数试图将数据保存到localStorage但根据我们的工作流这里应该调用historyService.save这个API。请修正。”这种开发模式将开发者从繁琐的、重复性的样板代码编写中解放出来更多地扮演“架构师”和“质检员”的角色设计清晰的工作流向AI描述它然后审查和整合AI输出的实现。你的创造力更多地倾注在“设计更好的路径”上而不是“铺设更标准的砖块”上。5. 常见陷阱、问题排查与效能衡量5.1 从“名词”转向“动词”过程中的典型陷阱即使理解了概念在实践初期也难免踩坑。以下是一些常见问题及应对策略陷阱一动词定义过于宽泛或抽象。问题将“管理数据”作为一个动词。这依然是一个名词化的动词没有指导意义。解决必须拆解为具体、可执行的动作序列。例如“管理数据”可以拆解为“筛选出符合条件A的数据条目 -批量修改这些条目的状态字段为‘已处理’ -导出修改后的列表为CSV文件”。这样每个动词都对应一个明确的用户界面操作和后台API调用。陷阱二工作流过于线性缺乏容错和分支。问题只设计了“一帆风顺”的主路径。用户一旦操作失误或网络中断体验就会崩溃。解决为每个关键步骤设计“逃生舱”。例如“上传文件”步骤要支持文件类型错误的实时提示、上传进度的显示、上传失败后的重试机制。“调用AI处理”步骤要考虑处理超时、服务不可用、返回结果格式异常等情况并给出相应的用户提示和后续操作建议如“稍后重试”或“联系支持”。陷阱三过早引入非核心动词。问题虽然认同MVP理念但在设计时总觉得“用户肯定也需要XXX功能”比如“分享到社交网络”、“多语言切换”。这些功能本身可能很好但它们会分散你对核心工作流打磨的注意力。解决严格执行“五个动词”的初始限制。对于任何想加入的新动词追问“没有它用户的核心目标完全无法达成吗”如果答案是否定的就把它放入“Phase 2”的清单。你的第一个版本唯一的目标就是让核心工作流跑通并且体验顺畅。5.2 效能衡量如何评估你构建的是“工作流”而非“功能”如何判断你的转型是否成功可以问自己以下几个问题新用户引导时长一个完全的新用户从首次接触到成功完成一次核心工作流需要多长时间点击多少次这个时间是否在缩短优化工作流就是在优化这个指标用户任务故事你能不能用一句话清晰地向一个不懂技术的人介绍你的产品是“用来做什么的”这句话里应该包含动词。例如“它是一个帮你自动把会议录音转换成总结性文章的工具。”代码结构你的代码仓库里是否有一个清晰的、以核心业务流程命名的模块或目录例如是否有core-workflow/,services/remover/,pipelines/这样的结构而不是只有components/,pages/这种通用结构开发专注度你和你的团队在每日站会上讨论的是“如何优化用户从A到B的第三步”还是“那个设置页面的图标该放左边还是右边”当你开始用这些标准来衡量产品时你就已经走在了正确的道路上。这不仅仅是一种开发方法更是一种产品哲学Don‘t build a platform. Build a path.不要构建一个平台去构建一条路径。最终用户只会为那条能带他们最快抵达目的地的路径付费。而作为构建者我们的最大价值和乐趣也正来自于设计并打磨这条独一无二的路径。下次当你有一个新想法时试着先别问“它需要哪些功能”而是问“用户用它来做什么”。答案就在那一连串的动词之中。
从功能清单到工作流引擎：开发思维的范式转移与AI实践
发布时间：2026/5/27 7:01:05
1. 从“功能清单”到“工作流引擎”一次开发思维的范式转移我们这行干久了很容易陷入一种“功能驱动”的惯性思维。每当启动一个新项目无论是个人副业还是团队产品第一反应往往是打开一个文档开始罗列那些我们熟悉得不能再熟悉的“积木块”用户认证、管理后台、个人设置页面、支付集成……我们的大脑被训练成了“名词收集器”。这听起来很合理对吧毕竟没有用户系统怎么管理用户没有后台怎么查看数据但问题恰恰出在这里用户从来不为这些“名词”买单。他们购买的是一个结果一个能将自己从A点问题快速、顺畅地带到B点解决方案的“捷径”。这个“捷径”就是工作流。我经历过太多次这样的循环激情满满地开始一个项目花了两周时间搭建了精美的、带社交登录和邮箱验证的用户系统又用了一周做出了一个功能齐全、响应式的仪表盘。看着代码仓库里日益丰满的目录结构内心充满了“建设”的成就感。然而当真正开始实现那个让项目与众不同的、核心的“魔法”功能时最初的热情已经消耗殆尽剩下的只有疲惫和对“屎山”初现端倪的恐惧。最终项目变成了又一个“80%的样板代码 20%的价值核心”的典型产物而那20%的核心往往也因为精力不济而做得粗糙不堪。这就是“名词陷阱”——它让我们沉迷于构建组件却忘记了我们为何而构建。真正的转变是从思考“它是什么”转向思考“它做什么”。与其说“我们需要一个数据库”不如说“我们需要持久化存储用户每次操作产生的数据”。与其说“集成Stripe”不如说“在用户完成核心任务后安全地收取费用”。这种从“名词”到“动词”的视角切换是区分一个功能堆砌的产品和一个真正解决问题的工具的关键。最近随着AI编程工具的成熟这种“动词优先”的思维模式不仅变得更为重要也获得了前所未有的强大助力。当你能够用自然语言描述一个清晰的工作流并交给AI去实现时开发的重心就从“如何砌砖”彻底转向了“如何设计建筑蓝图”。2. “名词陷阱”的深度剖析与破局之道2.1 为什么我们会本能地陷入“名词思维”这背后有一系列深层原因理解它们有助于我们有意识地对抗这种惯性。首先路径依赖与安全感。认证、CRUD、RESTful API……这些是我们训练有素、肌肉记忆般的技能。从学习编程的第一天起我们就在构建这些组件。当面对一个不确定的新领域时回归到这些熟悉、可控的“名词”上能给我们带来巨大的心理安全感。我们知道怎么做一个登录页面我们知道怎么设计用户表这些是可预测、可完成的任务。相比之下定义和实现一个独特的工作流是模糊的、充满未知的它带来的不是安全感而是焦虑。其次工具与框架的引导。现代Web开发框架无论是React、Vue还是Next.js其核心概念就是“组件化”。我们被教导要将UI拆解成可复用的组件Button, Modal, Form。后端框架则围绕着模型Model、视图View、控制器Controller来组织。这些范式本身没有错它们是工程实践的结晶。但危险在于如果我们不加以警惕就会把“实现手段”误当作“设计目标”。我们开始为“有一个漂亮的组件库”而开发而不是为“解决一个具体的用户任务”而开发。最后“完整性”的幻觉。一个拥有登录、注册、个人中心、后台管理的系统看起来就像一个“完整”的产品。它满足了我们对一个软件“应该有什么”的内在 checklist。这种视觉和结构上的完整性能给我们尤其是向非技术背景的伙伴或投资人展示时带来一种虚假的成就感。我们感觉自己已经构建了产品的“骨架”只差填充“血肉”。但很多时候这个“骨架”可能根本不适合你要承载的“血肉”或者那点“血肉”才是产品的全部价值骨架反而成了负担。注意警惕“技术虚荣心”。我们很容易为自己搭建的精巧技术架构而自豪但用户完全感知不到这些。他们只关心自己的问题是否被更快、更好地解决了。如果你的技术选型不是为了优化核心工作流那就可能只是一种自我满足。2.2 从“名词清单”到“动词清单”PRD的质变一份高质量的产品需求文档是强迫团队进行“动词思维”的最佳工具。传统的PRD可能长这样功能列表名词版用户认证系统邮箱/手机号登录第三方OAuth用户个人资料页面头像、昵称、简介编辑主仪表盘数据显示卡片、图表数据管理列表页支持增删改查、筛选、导出系统设置页面主题、通知偏好Stripe支付集成核心功能XXX模块而一个“动词优先”的PRD则完全不同。它通常从一个核心的用户故事或任务开始核心工作流描述动词版作为一个[用户角色]我想要[完成某个目标]以便于[获得某种价值]。例如对于一个图片背景移除工具作为一个电商卖家我想要快速去除商品图片的杂乱背景以便于制作干净的宣传图提升商品点击率。基于这个核心故事我们提炼出最关键的五组动词通常不超过五个这构成了产品的MVP闭环上传用户从本地或拖拽区域选择一张商品图片。预览与调整系统自动识别主体并移除背景用户可以通过画笔工具微调边缘擦除/恢复。替换/编辑用户可以为透明背景的图片选择一个纯色背景或上传一个新的背景图。下载用户选择输出格式PNG, JPG和分辨率一键下载处理后的图片。管理历史可选但属于工作流延伸用户可以在一个简易列表中查看最近处理过的图片进行重新编辑或再次下载。你会发现在这个列表里没有独立的“用户认证”或“设置”功能。认证动词识别用户可能只是为了让“管理历史”这个动词能跨设备生效。如果“管理历史”对初期用户价值不大那么认证甚至可以推迟。设置动词配置偏好可能初期只需要一个开关“是否在处理后自动弹出下载对话框”。这个开关可以直接放在预览页面的一角而不是一个独立的“设置”页面。这种方法的强制约束力是惊人的。当你只有五个“动词槽位”时每一个都必须精打细算。你会反复拷问自己“这个动作是用户达成最终结果的必经之路吗它是在创造价值还是在管理状态” 这就迫使你和团队聚焦于真正的核心——那个将用户从“问题”带到“结果”的最短路径。3. 构建工作流实操框架与核心环节3.1 如何识别并定义核心工作流定义工作流不是一个拍脑袋的过程它需要经过从抽象到具体的拆解。第一步从问题出发而非从技术出发。拿出一张白纸忘掉所有技术实现。只回答一个问题我的用户最痛的点是什么他/她现在是如何笨拙地解决这个问题的例如用户现在可能是手动在Excel里整理数据 - 复制到某个在线工具 - 下载结果 - 再用PS修改 - 最后上传到某个平台。你的产品就是要将这一串离散、费力的动作整合成一个平滑的、自动化的流程。第二步描绘理想路径。用最简单的语言描述这个流程最理想的、一步接一步的状态。尽量使用“用户点击…”、“系统自动…”、“然后显示…”这样的句式。这就是你的核心工作流剧本。以我之前做过的一个“周报自动生成器”为例理想路径是用户授权连接其任务管理工具如Jira、Trello。系统自动拉取指定时间范围内该用户完成的任务条目。系统利用AI将零散的任务标题和描述归纳成一段结构清晰、语言通顺的周报总结。用户在一个编辑界面内可以对AI生成的周报进行润色、删改。用户一键将周报复制到剪贴板或直接导出为Word/PDF。第三步提取关键动词并技术化映射。将上述剧本中的关键动作提取为动词并思考其技术实现映射连接/授权- OAuth2.0 流程获取API访问令牌。拉取- 调用第三方API处理分页和错误重试。归纳- 构造Prompt调用大语言模型API如OpenAI GPT Anthropic Claude解析返回的JSON。编辑- 实现一个富文本编辑器支持基本的格式和修改。导出- 前端生成Blob对象触发下载或服务端渲染文档。这个映射过程就是你的技术设计方案雏形。你会发现数据库设计、API接口、组件结构都自然围绕着支持这些动词来展开而不是反过来。3.2 工作流驱动的技术设计与实现要点当核心工作流清晰后技术架构会呈现出一种“流式”或“管道式”的特征。后端设计面向流程的服务编排。传统的MVC架构可能依然适用但思维要变。你的Controller不再仅仅是CRUD的代理人而是工作流步骤的协调器。以一个图片处理流程为例# 伪代码示例一个工作流协调器 class ImageProcessingWorkflow: def execute(self, upload_file, user_preferences): # 步骤1: 验证与接收 (动词接收) validation_result self.validator.validate(upload_file) if not validation_result.ok: raise InvalidInputError(validation_result.message) # 步骤2: 持久化存储 (动词存储) file_meta self.storage_service.save(upload_file) # 步骤3: 核心处理 - 背景移除 (动词处理) # 这里可能调用内部算法或第三方API processed_image_url self.ai_processor.remove_background(file_meta.url) # 步骤4: 后处理 (动词调整) # 根据用户偏好如背景色进行二次处理 final_image_url self.post_processor.apply(processed_image_url, user_preferences) # 步骤5: 记录历史并返回结果 (动词记录 返回) self.history_service.record(user_id, file_meta, final_image_url) return WorkflowResult(successTrue, output_urlfinal_image_url, history_id...)你的数据模型设计也应服务于流程。除了核心的业务实体表如图片表、用户表很可能需要一张workflow_execution表记录每一次工作流执行的上下文、步骤状态、输入输出和错误信息这对于监控、调试和提供用户历史记录至关重要。前端设计状态机与引导式UI。前端不再是静态页面的集合而是一个动态的状态机反映工作流的进展。状态定义明确工作流有哪几个状态如空闲、上传中、处理中、编辑中、完成、错误。UI映射每个状态对应一个主要的UI视图。例如“处理中”状态显示一个进度条和预计等待时间“编辑中”状态显示编辑器和工具栏“错误”状态显示友好的错误信息和重试按钮。引导与约束通过UI设计引导用户沿着正确路径前进。禁用与当前状态无关的按钮高亮下一步操作。例如在图片上传完成前“开始处理”按钮是灰色的。这减少了用户的认知负担也防止了非法状态的出现。实操心得在前端使用一个集中的状态管理库如Zustand, Redux Toolkit来管理整个工作流的状态非常有效。将工作流状态、步骤数据、错误信息都放在这里所有组件都根据这个状态来渲染。这样状态逻辑清晰且易于实现“断点续传”或“步骤回退”等高级功能。4. AI原生编辑器如何将“动词PRD”转化为代码这正是当前开发体验中最激动人心的部分。像Cursor、Windsurf、Claude Code等AI原生编辑器不仅仅是更智能的代码补全工具它们本质上是工作流实现加速器。当你持有了一份“动词优先”的、描述清晰的PRD时你与AI协作的效率会产生质变。4.1 与AI协作模式的升级从“代码生成”到“解决方案实现”传统的AI辅助编码更像是“超级自动补全”。你写一个函数名它帮你补全内容你写一句注释它生成一行代码。这当然有用但层次较浅。当你基于工作流进行开发时你可以与AI进行更高层次的对话。低效的提示名词思维“帮我写一个用户登录的React组件要有邮箱和密码框一个提交按钮。”AI会生成一个标准的、你可能在任何教程里看到的登录表单组件。它正确但平庸且与你的核心业务逻辑脱节。高效的提示动词思维结合上下文假设你正在构建一个内部设计工具已经有一个处理设计文件的工作流 “在我们的设计工具项目中用户已经通过Slack OAuth登录了。现在在项目主页我需要一个‘新建项目’的入口。这个操作的核心工作流是用户点击按钮 - 弹出模态框 - 用户输入项目名称并选择一个设计文件模板 - 点击创建 - 系统在后台用模板初始化一个项目并重定向到项目编辑器页面。请为这个‘CreateProjectButton’组件及其相关的模态框和创建逻辑生成代码。使用我们已有的useAuth钩子获取用户信息使用projectApi.create函数调用后端成功后用router.push跳转到/editor/[projectId]。”这个提示词里包含了上下文什么项目、用户已登录、触发动作点击按钮、工作流步骤弹窗、输入、选择、创建、跳转、技术约束使用的特定钩子、API、路由方法。AI基于此生成的代码不再是孤立的片段而是直接嵌入到你现有应用逻辑中的、功能完整的解决方案。它甚至能帮你生成相关的状态管理、错误处理代码。4.2 实践策略将PRD分解为AI可执行的指令一份好的“动词PRD”本身就是一份绝佳的AI提示词提纲。你可以直接将其章节或用户故事复制到编辑器的AI聊天框中作为开发某个模块的总体要求。分步骤实施不要一次性让AI生成整个复杂工作流。按照PRD里定义的动词步骤逐个击破。例如先实现“上传并验证文件”这个步骤完成后再基于这个上下文让AI接着实现“调用处理API并轮询结果”。提供上下文AI编辑器通常有“”引用文件或代码块的功能。在给出指令时引用相关的现有代码文件如已有的API客户端定义、类型接口、工具函数能让AI生成的代码更贴合你的项目结构减少适配成本。要求解释在生成关键或复杂的逻辑代码后可以要求AI“为这段代码添加行内注释解释关键决策点”。这不仅能帮助你理解代码也能在后续维护时提供便利。更重要的是这个过程能检验AI是否真正理解了你的工作流意图。迭代与修正AI生成的代码很少能100%完美运行。当出现错误或不符合预期时将错误信息反馈给AI并清晰地指出当前工作流步骤在哪一环出现了偏差。例如“在‘保存处理结果’这一步你生成的函数试图将数据保存到localStorage但根据我们的工作流这里应该调用historyService.save这个API。请修正。”这种开发模式将开发者从繁琐的、重复性的样板代码编写中解放出来更多地扮演“架构师”和“质检员”的角色设计清晰的工作流向AI描述它然后审查和整合AI输出的实现。你的创造力更多地倾注在“设计更好的路径”上而不是“铺设更标准的砖块”上。5. 常见陷阱、问题排查与效能衡量5.1 从“名词”转向“动词”过程中的典型陷阱即使理解了概念在实践初期也难免踩坑。以下是一些常见问题及应对策略陷阱一动词定义过于宽泛或抽象。问题将“管理数据”作为一个动词。这依然是一个名词化的动词没有指导意义。解决必须拆解为具体、可执行的动作序列。例如“管理数据”可以拆解为“筛选出符合条件A的数据条目 -批量修改这些条目的状态字段为‘已处理’ -导出修改后的列表为CSV文件”。这样每个动词都对应一个明确的用户界面操作和后台API调用。陷阱二工作流过于线性缺乏容错和分支。问题只设计了“一帆风顺”的主路径。用户一旦操作失误或网络中断体验就会崩溃。解决为每个关键步骤设计“逃生舱”。例如“上传文件”步骤要支持文件类型错误的实时提示、上传进度的显示、上传失败后的重试机制。“调用AI处理”步骤要考虑处理超时、服务不可用、返回结果格式异常等情况并给出相应的用户提示和后续操作建议如“稍后重试”或“联系支持”。陷阱三过早引入非核心动词。问题虽然认同MVP理念但在设计时总觉得“用户肯定也需要XXX功能”比如“分享到社交网络”、“多语言切换”。这些功能本身可能很好但它们会分散你对核心工作流打磨的注意力。解决严格执行“五个动词”的初始限制。对于任何想加入的新动词追问“没有它用户的核心目标完全无法达成吗”如果答案是否定的就把它放入“Phase 2”的清单。你的第一个版本唯一的目标就是让核心工作流跑通并且体验顺畅。5.2 效能衡量如何评估你构建的是“工作流”而非“功能”如何判断你的转型是否成功可以问自己以下几个问题新用户引导时长一个完全的新用户从首次接触到成功完成一次核心工作流需要多长时间点击多少次这个时间是否在缩短优化工作流就是在优化这个指标用户任务故事你能不能用一句话清晰地向一个不懂技术的人介绍你的产品是“用来做什么的”这句话里应该包含动词。例如“它是一个帮你自动把会议录音转换成总结性文章的工具。”代码结构你的代码仓库里是否有一个清晰的、以核心业务流程命名的模块或目录例如是否有core-workflow/,services/remover/,pipelines/这样的结构而不是只有components/,pages/这种通用结构开发专注度你和你的团队在每日站会上讨论的是“如何优化用户从A到B的第三步”还是“那个设置页面的图标该放左边还是右边”当你开始用这些标准来衡量产品时你就已经走在了正确的道路上。这不仅仅是一种开发方法更是一种产品哲学Don‘t build a platform. Build a path.不要构建一个平台去构建一条路径。最终用户只会为那条能带他们最快抵达目的地的路径付费。而作为构建者我们的最大价值和乐趣也正来自于设计并打磨这条独一无二的路径。下次当你有一个新想法时试着先别问“它需要哪些功能”而是问“用户用它来做什么”。答案就在那一连串的动词之中。
