飞书PRD到代码实现：AI编程工作流实战测评

# 从飞书PRD到代码落地：一次完整的AI编程工作流深度复盘 最近完成了一个真实研发需求，以Codex为核心协作工具。 需求本身不算庞大——阅读器需要实现“高光场景插卡”和“高光段落气泡”两个功能。但真正想验证的，不是这两个功能的最终写法，而是另一件事：能否把日常处理PRD、拆解需求、编写方案、修改代码、验证结果的流程，固化成一个稳定的AI workflow？ 不是每次都靠临时发挥和AI对话。而是把流程封装成一个Skill，让AI明确：需求从哪里读取，读完如何拆解，什么时候必须停下来等待我确认，什么时候才能动手改代码。 真实工程场景中，问题往往不在于AI不会写代码。问题在于它太急于往前冲。PRD尚未完整读取，它就敢猜测；需求范围未经确认，它就直接开发；仓库存在本地改动，它依然继续；构建没有跑通，它也可能轻描淡写地说“应该没问题”。这非常危险。 因此这次想复盘的是：一次从飞书PRD到代码实现的完整AI编程workflow。 图片说明：从飞书PRD链接到本地快照、需求拆解、技术方案、代码实现和QA的完整流程。 ## 一、第一步不是写代码，而是读取真实需求源头 这次会话的第一句话其实很平常。用户给出一个飞书Wiki链接，说道：“这是PRD。” 若是普通AI编程方式，下一步大概是直接把PRD丢给AI，说“请根据这个需求改代码”。AI随后开始搜索代码、猜测结构、修改文件。表面上看很快，但这里存在一个隐患：AI到底有没有读取到真实的需求源头？ 如果需求仅散落在聊天上下文里，后续每一步都会变得不可靠。它可能记错、遗漏，甚至把自己臆测的内容当作需求。 因此workflow的第一件事并非进入代码仓库，而是接入飞书CLI，先将需求文档完整读下来。 这一步会把飞书里的PRD拉取到本地，保存成快照和metadata。本次对应的工作流目录结构如下： source/ — 保存PRD快照 analysis/ — 保存需求拆解和待确认问题 planning/ — 保存技术方案和任务拆解 qa/ — 保存测试用例和验收清单 output/ — 保存实现摘要和验证结果 这里最重要的不是目录美观。而是它将一次聊天转化成了一组可回溯、可确认、可交接的本地文件。普通prompt依赖上下文记忆，workflow依赖阶段产物。这个差异极大。 图片说明：需求入口来自飞书文档，workflow会先读取并保存真实需求源头。 ## 二、读完PRD之后，真正重要的是需求拆解 把PRD拉取下来后，依然不能直接写代码。因为“读到了文档”和“理解了需求”之间，存在不小的距离。 本次workflow的下一步，是产出两个文件：requirements.json 和 open-questions.md。 requirements.json并非简单总结，而是将需求拆解成工程可处理的对象。例如明确范围、非目标、涉及的API接口、UI规则、埋点要求等。这不是为了让文档显得正式，而是为了让AI先将自己的理解暴露出来。 AI最让人头疼的特点之一，是它看起来非常自信。它常常把“我猜测是这样的”描述成“需求就是这样”。所以需求拆解的价值，就是打开这个黑盒，让人先审视一遍：范围是否准确？非目标是否写清楚？接口字段有没有猜错？UI规则和埋点有无遗漏？ open-questions.md则负责将不确定项沉淀下来。例如本次涉及：高光插卡是否跟随书籍插图开关？icon_type = 7是否完全以后端返回为准？点击跳转本期是否需要完整实现？高光插卡与神段评、作家插图的优先级如何处理？ 用户补充完这些信息后，AI再读取该文件，将方案收敛。这一步看似缓慢，但它解决了一个真实问题：如果需求理解有误，在这个阶段纠正成本很低；等代码写完后再纠正，成本则高昂许多。 图片说明：需求拆解、Open Questions、技术方案和验证结果都沉淀为本地文件。 ## 三、Skill不是提示词，是一份工作说明书 本次真正起作用的，是一个名为qm-prd-workflow的Skill。 以前我也容易把Skill理解为“更长、更详细的提示词”。但这次跑完后发现，Skill更像一份给AI的员工手册。它不是告诉AI“你要更聪明”，而是规定：你在哪些目录工作，先读什么，每一步产出什么文件，什么时候必须停下来向人确认，哪些动作绝对不能自主决定。 例如这个workflow会明确项目边界：主App仓库在哪里，阅读器组件仓库在哪里，工作流产物根目录在哪里。它也会定义流程关卡：飞书PRD intake、本地快照、需求分析、Open Questions、技术方案、任务拆解、代码实现、QA和verification。还会列明禁止动作：用户确认需求理解和技术方案之前，不得修改项目代码；仓库存在未提交改动时停止；禁止自动stash、commit、reset、clean；严禁将分析文档散落到业务仓库。 这些规则听上去并不性感，但恰恰是工程协作中最有价值的部分。普通prompt像临时交代一句“帮我看看这个需求”，Skill更像给新同事的一份岗位操作指南。AI不缺执行力，它缺的是一套稳定的工作边界。 图片说明：SKILL.md、scripts、references和assets共同组成一套可复用的工作说明书。 ## 四、Human in the Loop不是每一步盯着AI Human in the Loop很容易变成一句空话。仿佛只要流程里有人点了确认，就叫人在环。但真正有价值的地方，不是让人每一步都盯着AI，而是把人的判断力放到最关键的位置。 本次workflow设置了几个明确的停顿点。需求理解后停下来：人确认范围和非目标。Open Questions后停下来：人补充接口、UI、埋点、开关逻辑。技术方案后停下来：人确认实现方向。进入实现前停下来：如果仓库存在本地改动，AI不自作主张处理，而是等人决定。 这次ios\_qmnovel有本地改动时，workflow没有自动stash或reset。最终用户明确说“无须管ios\_qmnovel本地改动，进入代码实现”，AI才继续，只修改qmreader。这个细节很小，但极为重要。因为AI最让人不放心的地方，就是它会替你处理你没有授权它处理的事情。 好的workflow应该反过来：AI负责推进、记录、执行和提醒风险；人负责确认方向、补充上下文、收敛方案和承担关键决策。好的workflow不是把人从流程中拿掉，而是把人放在最有判断价值的位置。 ## 五、具体代码实现只是workflow的验证样例 最后，这个需求确实进入了代码实现阶段。但具体业务实现不是主角，它只是这条workflow的一个验证样例。 简单来说，最后代码层面做了以下几件事：新增YYHighlightParaView，解析chapters.highlight字段，支持icon\_type=7映射reader\_a\_remark\_bubble\_default，将高光插卡接入段末插件管理，补上插卡曝光和点击埋点。 这些实现证明了一件事：workflow不是只会写文档，它可以从飞书PRD一路走到真实的代码改动。但更重要的是，它让交付结果更可靠，产出可复用的产物，增加对代码实现的掌控——尤其是第一版代码实现的掌控。后续还可以根据需要引用和分享产物。 ## 六、如果你也想写一个Skill，先写边界，再写能力 这次跑完以后，对Skill的理解变得更加具体。如果你也想把自己的重复工作固化成一个Skill，建议先别急着写一大段提示词，先写边界。 可以从这些问题入手：入口是什么？是飞书链接、PRD文档、截图，还是接口说明？真实需求如何读取？能否优先接入飞书CLI、GitHub issue等，而不是仅靠聊天上下文？每一步产物放在哪里？需求要拆成什么结构——范围、非目标、接口、UI、埋点、风险、Open Questions？哪些节点必须等人确认——需求理解、技术方案、进入实现、验证阻塞？哪些动作禁止自动执行——例如reset、stash、commit，或者在未确认前修改业务代码？ 这些限制不是束缚AI，恰恰相反，它们是在帮AI变得可信。一个好Skill不是让AI看起来更聪明，而是让AI在重复工作中更稳定、更可控、更可交付。 ## 写在最后 这次高光插卡需求本身不是重点。重点在于更清楚地看到：AI编程要稳定下来，不能只靠“更会提问”。它需要workflow。 接入飞书CLI，是为了让AI读取真实需求源头。需求拆解，是为了让AI先暴露理解。Human in the Loop，是为了让人在关键节点做判断。本地artifacts，是为了让过程可追溯、可交接、可复盘。 AI协作最重要的变化不是“人被拿掉”，而是人终于可以从重复推进中抽身出来，将注意力放到更重要的判断上。后续可以不断完善workflow skill，引入多agent协作、代码性能检测、产物归档到云端形成知识库等。

来源：互联网