不只是让 AI 写代码：零售 SaaS 项目如何用 Skills 串起从需求到上线的全流程
读完了 · 6246 字 · 约 8 分钟
加载中...
很多人第一次用 Codex、Claude Code 或其他 AI Coding Agent，最直接的用法是：
“帮我实现一个功能。”
这当然有用，但在真实项目里远远不够。
尤其是零售 SaaS 系统。一个看起来普通的“促销活动管理”功能，背后可能牵动商品、门店、会员、订单、库存、退款、报表和权限。你让 AI 直接写代码，它很可能能写出一部分 CRUD，但不一定知道哪些业务边界最危险，也不一定会主动帮你补测试、想灰度、看回滚、查报表口径。
所以，高效使用 AI 的关键不是把它当成“更快的代码生成器”，而是把它纳入一套工程化流程：用成熟 Skills 把需求澄清、方案收口、计划拆解、开发、测试、上线和迭代串起来。
这篇文章用一个贯穿案例来讲：
为零售 SaaS 系统新增一套门店促销活动管理功能。
它要求总部创建促销活动，按门店、商品、会员等级生效，支持满减、折扣、优惠券互斥，门店端展示活动价，下单时正确计算优惠，订单取消或退款后正确回滚库存、优惠和报表数据。
这不是一个“写几个接口”的小功能，而是一个很适合展示 AI 项目全周期协作方式的真实场景。
先看全局。一个项目不应该从“写代码”开始，而应该从“把问题变清楚”开始。
| 阶段 | 推荐 Skill | AI 的主要职责 | 人的主要职责 |
|---|---|---|---|
| 需求澄清 / 提示词优化 | prompt-optimizer |
把模糊想法整理成可执行需求 | 补业务背景、目标、边界 |
| 方案探索 / 方案收口 | brainstorming |
给出多种技术方案和取舍 | 判断业务阶段、复杂度、风险 |
| 设计文档沉淀 | writing-plans / design spec |
固化模块、数据流、边界 | 审核设计是否符合业务 |
| 实施计划拆解 | writing-plans |
拆任务、标依赖、写验收标准 | 决定优先级和交付节奏 |
| 开发执行 | executing-plans / subagent-driven-development |
按计划小步实现 | 控制范围，避免乱改 |
| 测试驱动开发 | test-driven-development |
先写失败测试，再实现 | 确认核心业务规则 |
| 问题排查 | systematic-debugging |
定位根因，避免猜修 | 提供现象、日志、复现步骤 |
| 前端体验打磨 | frontend-design 类 Skill |
优化页面信息结构和交互 | 判断运营使用场景 |
| 验证收尾 | verification-before-completion |
运行测试、构建、检查结果 | 判断是否可交付 |
| 代码审查 | requesting-code-review / receiving-code-review |
找风险、缺测试、回归点 | 决定是否修改 |
| 上线准备 | finishing-a-development-branch |
整理上线、回滚、发布清单 | 控制发布时间和灰度范围 |
| 复盘迭代 | prompt-optimizer + planning skill |
整理反馈，规划下一轮 | 判断价值和投入产出 |
这张表的重点是：AI 不只参与开发。它应该从项目最早期就介入，帮助你把需求、方案、计划、验证和上线都变得更稳定。
很多项目失败，不是 AI 写代码不行，而是一开始给 AI 的任务就是模糊的。
原始提示词可能是：
帮我做一个促销活动功能。这句话对人也不够，对 AI 更不够。它不知道：
这时适合先用 prompt-optimizer。
你可以这样和 AI 说：
帮我把“做一个促销活动功能”整理成可执行的项目需求。
先不要写代码，先补齐目标用户、核心流程、业务规则、边界场景、验收标准和不做范围。
如果信息不足，请列出需要我确认的问题。优化后的需求可能会变成：
我们要为零售 SaaS 系统新增门店促销活动管理功能。
目标用户：
- 总部运营：创建、编辑、上下架促销活动
- 门店员工：查看商品活动价
- 消费者：下单时享受符合条件的优惠
核心能力：
- 支持按门店、商品、会员等级配置活动范围
- 支持满减、折扣两类活动
- 支持与优惠券互斥
- 支持活动开始、进行中、已结束、已下架状态
- 下单时正确计算优惠
- 订单取消或退款时回滚优惠、库存和报表数据
本期不做：
- 不做复杂规则引擎
- 不做 AI 自动生成促销方案
- 不做跨品牌联合活动这一步的价值是把“想法”变成“项目输入”。输入稳定了，后面的方案和代码才不会一路跑偏。
不要让 AI 一上来写表结构。零售促销是典型的“规则复杂度会不断增长”的功能，必须先做方案比较。
你可以这样说：
请给我 3 种促销活动实现方案，分别说明适合场景、复杂度、扩展性、测试难度、对订单和库存模块的影响，并推荐一个当前阶段最稳的方案。AI 可以给出类似这样的比较：
| 方案 | 适合场景 | 优点 | 风险 |
|---|---|---|---|
| 简单规则配置方案 | 活动类型少，业务刚起步 | 实现快，易测试 | 后续规则多时会膨胀 |
| 规则引擎方案 | 活动规则高度复杂 | 扩展性强 | 初期成本高，调试难 |
| 活动中心 + 价格计算服务 | 中等复杂度，需要长期演进 | 边界清晰，方便接订单 | 需要设计好数据流 |
对大多数零售 SaaS 团队来说，第一期更推荐“活动中心 + 价格计算服务”的折中方案。
原因是它不会像简单 CRUD 那样把所有逻辑塞进订单模块，也不会一开始就引入过重的规则引擎。人的职责是在这里做判断：当前业务规模、团队能力、上线周期、未来扩展，都要一起看。
方案确定后，下一步不是“开始写”，而是拆计划。
你可以这样和 AI 说：
基于已确定方案，请拆成 8-10 个可独立验证的开发任务。
每个任务包含目标、涉及模块、依赖关系、验收标准和测试方式。一份简化计划可以是：
| 任务 | 目标 | 验收标准 |
|---|---|---|
| 数据模型 | 建活动、活动范围、活动规则表 | 能保存门店、商品、会员等级范围 |
| 活动管理 API | 创建、编辑、上下架活动 | 权限正确，状态流转正确 |
| 促销规则计算 | 根据订单明细计算活动优惠 | 未开始、过期、不匹配范围均不生效 |
| 门店端价格展示 | 展示商品活动价 | 活动价与订单计算一致 |
| 订单优惠接入 | 下单时接入促销计算 | 满减、折扣、互斥规则正确 |
| 退款回滚 | 订单取消和退款后处理优惠 | 库存、优惠、报表口径一致 |
| 后台页面 | 活动列表、创建、编辑、上下架 | 运营可完成主流程 |
| 权限控制 | 总部和门店权限隔离 | 门店不能越权改总部活动 |
| 测试与灰度 | 补单测、集成测试、灰度方案 | 可在部分门店先发布 |
计划的意义是让 AI 每次只处理一个明确任务。任务越小，AI 越稳定。
开发阶段可以用 executing-plans 或 subagent-driven-development。但不要让 AI “自由发挥”。
比如第一步只做数据模型和基础 CRUD，你可以这样说：
请只实现促销活动的数据模型和基础 CRUD，不要改订单计算逻辑。
完成后列出改动文件，并运行相关单元测试。
如果发现需要改动订单模块，请先说明原因，不要直接修改。这段话里有三个关键约束：
如果任务可以并行，比如后台页面、规则计算、API 文档互不冲突，可以让 AI 拆成多个子任务：
请把促销活动功能拆成可以并行开发的子任务。
要求每个子任务写清楚负责模块、输入输出、不能改动的边界，以及最终需要交付的测试。适合并行的任务包括：
不适合过早并行的是订单接入和退款回滚，因为它们依赖规则计算稳定。
零售 SaaS 里，促销最危险的不是页面不好看，而是钱算错。
这里要区分三个 Skill：
| Skill | 适合什么时候用 | 解决什么问题 |
|---|---|---|
test-driven-development |
开发前 | 先定义业务规则，再写实现 |
systematic-debugging |
测试失败时 | 找根因，避免猜修 |
verification-before-completion |
交付前 | 确认测试、构建、验证都跑过 |
促销功能至少要覆盖这些测试：
你可以这样要求 AI：
先写失败测试，验证同一订单中满减活动和优惠券不能同时生效。
测试失败后再实现互斥逻辑。
不要为了让测试通过而改测试预期，除非先说明业务规则有歧义。如果测试失败，不要直接说“修一下”。应该这样说：
这个优惠计算测试失败了，请先定位根因。
请说明失败属于数据准备问题、规则判断问题、订单接入问题，还是测试断言问题。
在确认根因前，不要直接修改实现。完成前再要求验证：
在你说完成前，请运行促销规则、订单计算和退款回滚相关测试。
请总结通过了哪些测试、还有哪些测试没有覆盖、是否存在残余风险。这会让 AI 从“写完就结束”变成“验证后再结束”。
促销后台是运营天天用的工具。如果页面只是把字段堆出来，后期一定难用。
这时可以用 frontend-design 类 Skill，让 AI 从用户工作流出发，而不是从组件出发。
你可以这样说：
请按运营人员日常配置促销活动的场景优化后台页面，不要做营销页。
重点提升筛选效率、状态可读性、规则冲突提示和批量操作体验。促销后台至少要关注：
你还可以继续细化：
请检查促销活动创建页的信息结构。
目标是让运营在 3 分钟内完成一个常规满减活动配置。
请指出当前页面中最容易误操作的地方，并给出调整建议。这里人的职责是判断“运营真实怎么工作”。AI 可以优化界面，但业务使用场景必须由人补齐。
零售 SaaS 上线前，最怕三类问题：
所以要让 AI 进入 review 和上线准备状态。
代码审查可以这样说：
请以代码审查视角检查这次促销功能改动。
优先找订单金额错误、库存回滚风险、权限漏洞、并发问题和缺失测试。
请按严重程度排序，不要只总结优点。上线检查可以这样说：
请帮我整理上线前检查清单，包括数据库迁移、灰度门店、回滚方案、订单金额校验、报表口径和客服应答准备。
请标出哪些是必须完成，哪些是建议完成。上线前清单可以包括：
| 检查项 | 为什么重要 |
|---|---|
| 数据库迁移可回滚 | 活动表结构错误会影响发布 |
| 灰度门店配置 | 先控制影响范围 |
| 订单金额抽样校验 | 防止优惠计算错误 |
| 退款回滚验证 | 防止库存和优惠数据错乱 |
| 报表口径确认 | 防止运营数据异常 |
| 权限检查 | 防止门店越权配置活动 |
| 客服话术准备 | 上线后用户咨询可快速响应 |
如果用了 finishing-a-development-branch，可以让 AI 帮你整理最后交付材料：
请帮我整理这次促销功能的交付说明。
包含改动范围、测试结果、上线步骤、灰度策略、回滚方案和已知风险。功能上线不是结束。促销系统上线后，很快会有新需求：
这时不要直接让 AI 加功能，而是先评估影响范围。
基于当前促销活动系统，帮我评估新增“活动效果分析”的影响范围。
先不要写代码，先给数据模型、指标口径、页面入口、权限控制和测试建议。对于更复杂的迭代，比如“AI 自动生成促销方案”，可以这样问：
请帮我设计“AI 自动生成促销方案”的最小可行版本。
要求只基于历史销售数据和库存数据生成建议，不自动发布活动。
请说明数据需求、风险边界、人工确认流程和后续扩展方向。上线后的 AI 协作，重点是让 AI 帮你做影响分析和方案收口，而不是继续无脑堆功能。
如果把上面压缩成一套流程，可以记成：
这套流程背后的分工很简单：
真正高效的 AI 编程，不是让 AI 一次性把项目写完，而是让 AI 在每个阶段都站在正确的位置上。
| 项目阶段 | 推荐 Skill | 你可以怎么用 |
|---|---|---|
| 想法变需求 | prompt-optimizer |
把“做促销功能”变成需求、边界、验收标准 |
| 方案比较 | brainstorming |
比较简单配置、规则引擎、活动中心方案 |
| 设计沉淀 | writing-plans |
写数据模型、模块边界、接口设计 |
| 任务拆解 | writing-plans |
拆 8-10 个可验证开发任务 |
| 开发执行 | executing-plans |
按计划逐步实现 |
| 并行开发 | subagent-driven-development |
拆分后台、API、规则计算等独立任务 |
| 先测后写 | test-driven-development |
先写促销互斥、门店范围、退款回滚测试 |
| 故障排查 | systematic-debugging |
测试失败时先定位根因 |
| 前端打磨 | frontend-design |
优化活动后台、筛选、状态、冲突提示 |
| 完成前验证 | verification-before-completion |
运行测试、构建、关键回归 |
| 代码审查 | requesting-code-review |
找金额、库存、权限、测试风险 |
| 处理审查意见 | receiving-code-review |
判断反馈是否合理，逐条修复 |
| 上线准备 | finishing-a-development-branch |
整理上线说明、灰度、回滚和风险 |
| 后续迭代 | prompt-optimizer + planning skill |
把新需求重新收口，再进入下一轮计划 |
用 AI 做完整项目，最怕的是从一句模糊需求直接冲进代码。
更稳的方式是：让 Skill 帮你把流程变清楚，让 AI 在流程里持续推进，让人始终守住业务判断和验收边界。