从Excel台账到可交互的网页原型，AI如何助力产品经理高效落地复杂业务？本文以CID财务结算中心为例，展示如何利用Codex梳理业务规则、生成PRD并部署原型，强调AI是强大的助理，但产品经理的决策与约束才是关键。

最近我做了一个挺有意思的项目。

不是写一个简单的页面，也不是让 AI 帮我润色几段文案，而是从一堆 Excel、需求记录、业务规则和原型草图开始，利用 Codex，把一个 CID 财务结算中心从 0 梳理到 1，并且真的做成了可以点击的网页原型，部署到了自己的网站。

这次最大的收获不是“AI 可以帮我写多少代码”。

而是我越来越确定一件事：

AI 可以把产品经理的效率放大很多倍，但前提是，产品经理必须知道自己要解决什么问题，也必须知道怎么约束 AI

项目背景：广告CID 财务结算场景

目前集团有 4000 多家客户，参与结算的财务有 4 名。一次完整的结算周期，通常需要一周左右。

表面上看，结算就是把订单金额算出来，再生成结算单。但真正进入业务现场以后，会发现它一点都不简单。

这里面至少涉及：

• AE 的客户和企业归属
• CID 电商广告订单
• 归因订单
• 客户服务费
• 返佣、补贴和其他应付明细
• 银行流水和渠道流水
• 客户到账分配
• 客户余额和金额占用
• CID 内部抵消
• CID 和广告结算单之间的跨业务抵消
• 财务审核、核销、红冲和历史迁移

之前很多工作都分散在不同的 Excel 台账里，全程人工智能，费时费力费人工还易出错。

订单在一张表，归因订单在一张表，客户政策在另一张表，银行流水又是另一张表。财务需要在多个文件之间来回查找、复制、核对。

最麻烦的还不是工作量大，而是：

每一张表看起来都有数据，但没有一张表能说明完整的业务结果

• 当客户退款发生在后续日期怎么办？
• 财务审核前的结算单能不能覆盖？
• 已经核销的金额发现错了，能不能直接改？
• 100 元到账，已经提交分配 80 元以后，到底还剩多少可用？
• CID 的应付结算单和广告应收结算单能不能抵消？

这些问题如果没有统一规则，系统做出来也只是在 Excel 上换了一层皮。

第一件事：不是让 AI 写 PRD，而是先让 AI 理解材料

我一开始没有直接对 Codex 说：“帮我写一个财务结算系统。”这种说法太空了，会进入AI幻觉。

AI 会很快给你一套看起来完整的系统，但里面可能混合了真实业务、常见做法和它自己的猜测。

所以我的第一步是把相关材料交给 AI，包括：

• 需求梳理
• 真实业务台账
• 订单和归因订单资料
• 原型草图
• 页面截图
• 已经确认过的业务规则
• 我自己提供的产品主框架

然后先让它做三件事：

1. 把材料里的事实提取出来。
2. 找出材料之间的冲突。
3. 列出还缺少哪些关键规则。

我要求 AI 强制区分三种内容：

1. 【事实】：材料和用户已经明确确认的内容
2. 【推断】：基于现有信息做出的方案判断
3. 【待确认】：会影响产品实现，但还没有最终结论的内容

这一层非常重要，因为 AI 最大的问题，往往不是不会写，而是写得太顺了。

它可以把一个没有结论的讨论，写成一段非常确定的产品规则。如果产品经理没有把事实和推断拆开，后面 PRD、原型、研发和测试都会建立在错误的地基上。

第二件事：先写主框架和风险，再写 PRD

材料理解完以后，我没有马上让 AI 写 PRD，而是先让它输出需求主框架和风险清单。

主框架包括：

• 谁在使用这个系统
• 每个角色负责什么
• 系统里有哪些核心对象
• 对象之间是什么关系
• 用户从哪里进入
• 每一步要完成什么
• 哪些状态会发生变化
• 哪些异常会阻塞流程
• 哪些内容明确不在本次范围

最后，才进入 PRD。

这次项目中，真正需要被写死的不是按钮颜色，而是这些业务规则：

第一，每个 CRM 客户每天形成一张独立日结算单。

唯一维度是：CRM 客户 + 结算日期 + 结算单类型。

相同维度不能重复生成有效日单，前几天漏掉的日单要能够补生成。

第二，财务审核前和审核后的处理方式不一样。

财务审核前，如果订单或政策发生变化，可以覆盖原日单，但金额变化以后必须重新走 AE 核对。

财务审核以后，不能直接覆盖。

没有核销的，作废以后重新生成；已经核销的，必须先做整笔核销红冲，再作废和重新生成。

第三，提交分配就要占用金额。

到账 100 元，已经提交分配 80 元，系统里就应该显示：

• 到账金额：100
• 占用金额：80
• 可用金额：20

否则多人同时分配时，很容易出现重复使用同一笔钱。

第四，跨广告抵消需要双财务审核。

CID 和广告结算单不是同一个业务模块。跨模块抵消提交以后，既要经过 CID 财务审核，也要经过广告财务审核。任一方驳回，双方占用金额都要释放。

这些规则如果没有在 PRD 里约束清楚，后面的原型再漂亮也没有意义。

第三件事：让 AI 写 PRD，但不让 AI 自己决定业务

我把 Codex 当成一个很强的产品助理，而不是产品负责人。

它可以帮我：

• 整理复杂材料
• 生成流程图
• 提炼对象关系
• 补齐异常场景
• 发现字段遗漏
• 从产品、测试、技术三个视角挑战 PRD

但它不能替我决定：

• 哪条业务规则最终成立
• 哪个角色拥有审批权限
• 哪些范围必须一期完成
• 哪个异常由谁负责处理

所以 PRD 写完以后，我又让 AI 分别模拟三种角色审核：

产品视角

• 这个需求是不是真的解决了业务问题？
• 用户路径是否完整？
• 范围有没有膨胀？

测试视角

• 正常状态写了，异常状态呢？
• 重复提交怎么办？
• 部分核销怎么办？
• 权限不足怎么办？
• 金额边界和历史数据怎么验收？

技术视角

• 对象关系是否清楚？
• 日单生成是否幂等？
• 金额占用是否有一致性规则？
• 外部订单、银行流水和广告结算单的数据边界在哪里？

这个过程让我意识到，AI 很适合做“反向提问的人”。

它不一定能替你做最后决定，但很适合帮你发现：

“这里是不是还没有写清楚？”

第四件事：调整 AI 生成的网站，而不是接受第一版结果

PRD 确认以后，才进入原型。

第一版原型很快就能生成出来，但第一版通常只是“能看”，不代表“能用”。

我做的调整主要有几类。

1. 沿用已有 B 端产品风格

原来网站已经有运营提成模块，所以 CID 不能突然变成一套完全不同的视觉设计。我保留了原来的：

• 左侧导航
• 顶部导航
• 表格密度
• 状态标签
• 抽屉
• 确认弹窗
• 主色和间距

新增页面看起来应该像同一个产品的下一版，而不是 AI 随手生成的另一个系统。

2. 把复杂规则放进交互状态

“财务审核后不能直接修改”不是写一段说明就结束了。

在原型里，它应该体现为：

• 作废/重生按钮
• 核销红冲确认
• 影响金额展示
• 关联单据
• 审核轨迹

“100 元到账、80 元占用、20 元可用”也不能只写在 PRD 里，页面上必须能看到这三个金额的关系。

3. 补齐不同角色看到的内容

AE、CID 财务、广告财务看到的不是完全相同的任务。

所以工作台里需要有：

• 待 AE 核对
• 待 CID 财务审核
• 待广告财务审核
• 疑似重复流水
• 历史迁移差异

原型的价值，就是把这些流程和状态提前暴露出来。

第五件事：部署不是“把文件传上去”

很多人说“我已经部署了”，其实只是把一个 HTML 文件复制到了服务器。

但真正的部署至少还要做几件事：

• 确认 Nginx 实际使用的根目录。
• 确认当前线上页面是什么。
• 发布前备份旧文件。
• 上传新的 HTML 和图片资源。
• 验证首页和关键页面状态码。
• 检查页面是否真的包含新增入口。
• 检查旧页面是否没有被破坏。

这次我把原型部署到了自己的网站根目录。

用户访问首页，默认先看到个人介绍；从左侧可以进入运营提成和 CID 结算。

这对我来说不只是“把网页放上去”，而是把整个产品方案变成了一个可以被别人打开、点击、体验和讨论的作品。

这次真正做出来的是什么？它不是一套已经接入生产数据的财务系统。

它是一套完成了业务梳理、规则定义、产品设计、交互验证和线上部署的可交互产品原型。

它至少把这些问题从“脑海里的想法”变成了可讨论的页面：

• 客户和企业怎么映射
• 政策版本怎么生效
• 订单怎么进入结算
• 每天的日结算单怎么生成
• 收款怎么分配
• 金额怎么占用
• CID 和广告怎么抵消
• 已核销错账怎么红冲
• 历史数据怎么迁移

以前大家讨论产品，经常停留在：

“这里应该有一个按钮。”

现在可以直接打开页面：

“这个按钮在这里，点击以后打开这个抽屉，金额会从可用变成占用，审核通过以后进入已核销。”

这就是原型的意义。

未来，产品经理应该如何和 AI 协作？

我现在不会把 AI 理解成一个“替代产品经理”的工具。

更准确地说，它像一个高效率的产品助理、研究员、文档工程师和原型助手。

但它有几个明显的边界：

• 它不了解你公司真实的权责关系
• 它无法替你承担业务决策
• 它不知道哪些规则是老板一句话，哪些规则是系统底线
• 它会把不确定的内容写得很确定
• 它很容易生成看起来完整、实际不能落地的方案

所以未来的产品工作，不是“让 AI 自由发挥”，而是建立一套人与 AI 的协作机制：

人负责方向、事实、判断、取舍和约束。

AI 负责提取、整理、推理、检查、生成和重复劳动。

一个比较稳定的协作流程应该是：

业务材料和主框架 → AI 事实分层 → 风险清单 → PRD → 产品/测试/技术审核 → 原型 → 交互说明 → 部署验证。

每一步都有交付物，每一步都有人确认。

如果没有边界，越聪明的 AI 越容易把错误的前提写得越完整。

写在最后

这次用 Codex 做 CID 财务结算，对我来说更像一次产品方法的实验。

我想验证的不是：“AI 能不能生成一个网站？”

而是：“一个产品经理，能不能带着 AI，把一个复杂业务从混乱材料推进到可评审、可交互、可部署？”

答案是可以。

但前提是你不能把方向盘交出去。

你要知道业务为什么这样做，要知道哪些规则不能错，也要敢于一次次把 AI 生成的结果退回去重做。

AI 可以让产品经理走得更快。但产品经理要自己决定，走向哪里。