广告管理系统不该再按前端、后端分工：AI时代复杂业务系统怎么做

你描述的这个情况，我的判断很直接：系统复杂是真的，但现在的工作方式大概率有问题。

一个广告管理系统确实不会简单。它可能牵涉账户、角色权限、广告计划、预算、投放目标、人群定向、素材审核、出价、消耗、归因、报表、结算、风控、操作日志。每一个模块背后都有例外。业务同学一提需求，常常不是一个按钮，而是一串流程。

但复杂不等于一个需求必须做一两个月。复杂也不等于技术同学必须先把所有业务细节吃透，再让 AI 写代码。2026 年 5 月这个时间点，Codex、Claude Code 这类工具已经把开发工作的重心改掉了。人的主要工作不应该是手写代码，也不应该是把所有业务逻辑憋在脑子里。人的工作应该变成：定义边界、组织上下文、建立验收标准、让 AI 反复实现和验证。

如果团队还在用"前端一个人、后端一个人"的方式接复杂需求，然后两个人花大量时间互相同步、拆接口、补理解、等对方，这套模式在 AI 时代会越来越重。

先说结论

• 技术同学仍然需要理解业务，但不需要用传统方式把每个细节都背下来。他们需要理解的是业务目标、关键规则、不可错的边界、典型案例和验收标准。细节应该沉淀成可查询、可测试、可复用的上下文，而不是只存在于人的脑子里。
• 不应该先花很久"彻底理解需求"再动手。更合理的方式是让 AI 帮忙把大需求拆成流程图、状态机、规则表、接口草案、测试用例和风险清单。人来审核这些产物。审核通过后，按竖切片开发。
• 前后端分工不应该是默认组织方式。广告管理系统这种业务系统，更适合按业务闭环分工。一个人负责一个完整切片，从页面到接口到数据到测试。另一个人做交叉评审、复杂规则校验、并行探索或第二个切片。
• 如果一个小需求经常变成一两个月，问题多半不在 AI 写代码慢，而在需求入口、上下文管理、验收方式和任务切片。

AI没有让业务理解消失，但它改变了理解的形态

这里容易走两个极端。

一个极端是技术同学说：业务太复杂，我必须全部弄懂，才能开始写。这个做法在过去有一定道理，因为代码主要靠人写，需求漏掉一个规则，返工很痛。

另一个极端是管理者说：AI 都这么强了，你们不用懂业务，直接让 AI 写就行。这个也不现实。AI 不知道你们公司的投放规则，不知道哪些客户有特殊结算方式，不知道一个按钮背后牵涉财务还是风控，除非你把这些东西给它。

正确的位置在中间：人不需要记住所有细节，但必须把细节组织成 AI 能使用、团队能检查、系统能回归的形式。

这也符合行业里对 agentic coding 的实际经验。Anthropic 在 Claude Code 最佳实践里强调，Claude Code 可以读文件、运行命令、改代码，但它表现好不好，很大程度取决于上下文和验证标准。文档里有一句很实用的话：给出测试、截图或预期输出，让 Claude 能自己检查，这是最高杠杆的事情之一。它还建议"先探索，再计划，再写代码"，并且要主动管理上下文。

OpenAI 的 Codex 文档也把 Codex 放在真实代码库、受控修改、代码审查、测试、自动化、知识工作和生产系统里讨论，而不是把它当成一个只会补全代码的工具。OpenAI 的 Agents 文档同样强调评测、trace、guardrails 和 human review。换句话说，AI 工作流的重点不是"AI 替我敲代码"，而是"AI 在可验证的轨道里做事"。

为什么前端、后端拆分会拖慢这种系统

传统前后端分工在很多场景里仍然可用。但广告管理系统这种业务系统，最容易出现一个问题：页面只是业务规则的入口，接口只是规则的承载，真正的难点在端到端逻辑。

举个例子：业务说"新增一个广告计划复制功能"。听起来是一个按钮。实际可能包括：

• 哪些字段可以复制，哪些字段必须重填；
• 素材审核状态是否继承；
• 预算、出价、定向、人群包是否可复用；
• 复制后是否直接进入草稿；
• 不同角色是否有权限复制；
• 复制失败时如何提示；
• 复制行为是否进入操作日志；
• 报表和归因是否要排除复制前数据。

如果按前后端拆，前端同学会问接口字段和状态，后端同学会问页面行为和业务例外。两边都在等对方把另一半说清楚。AI 可以写页面，也可以写接口，但它无法自动修复这种组织方式带来的上下文断裂。

更好的拆法是竖切片：一个人负责"复制广告计划"这个完整闭环。页面、接口、数据、权限、日志、测试都在同一个任务里。另一个人不是闲着，而是负责评审规则、跑反例、检查测试、处理并行切片，或者专门让 AI 生成遗漏场景。

这不是要求一个人变成传统意义上的全栈专家。AI 时代的全栈，不是每一层都手写得最熟，而是能对一个业务结果负责，能调动 AI 和工具把前后端、数据、测试串起来。

复杂需求不能再用"大文档 + 长理解周期"处理

业务同学给大需求，是正常的。业务天然希望更多、更全、更广。问题不是业务提得大，而是技术团队接法不对。

以前的接法是：开会，听需求，画流程图，写文档，前后端拆接口，排期，开发。这个流程一旦遇到复杂广告逻辑，就会越滚越大。需求越大，文档越长；文档越长，越没人能完整消化；没人完整消化，就只能继续开会。

AI 时代应该换成另一种接法。

第一步：让 AI 先把大需求拆成结构化产物

业务输入可以很大，但技术接收后，不应该直接进入开发。先让 AI 输出这些东西：

• 一句话目标：这个需求到底改变哪个业务结果；
• 用户角色：谁能用，谁不能用；
• 主流程：从入口到完成的正常路径；
• 状态机：对象有哪些状态，状态之间怎么变；
• 规则表：每条业务规则的条件、动作、例外；
• 反例库：哪些情况不能发生；
• 数据影响：新增或修改哪些字段、表、事件、日志；
• 验收用例：业务、前端、后端、权限、异常、回归分别怎么测；
• 可切片列表：哪些切片可以独立上线，哪些必须一起做。

这些不应该全靠人手写。AI 很适合把长需求改写成规则表和测试用例。人要做的是审核：这里有没有漏规则？有没有错误假设？有没有不该做的部分？

第二步：业务不要再只交"愿望"，要交例子和反例

复杂业务系统最怕抽象描述。比如"预算规则按客户类型处理"，这句话几乎没法开发。更好的输入是：

• A 类客户，日预算低于 1000，允许保存但提示；
• B 类客户，未完成资质审核，不允许开启投放；
• 代理商账户复制计划时，不复制原客户的结算主体；
• 历史数据不能因为计划复制而重新归因。

例子和反例比长篇流程图更有用。它们可以直接变成测试，也可以直接喂给 Codex 或 Claude Code。

第三步：每个切片必须能在三到五天内看到结果

不是所有系统都能一天上线，但一个切片如果三到五天都看不到可运行结果，切片通常还是太大。

一个广告系统需求可以这样拆：

• 先做只读详情页，把字段、状态和权限展示对；
• 再做草稿创建，不接真实投放；
• 再做保存校验和错误提示；
• 再接操作日志；
• 再接审核流；
• 最后接投放开关和报表影响。

每个切片都有验收用例。AI 每做完一片，就跑测试、生成变更说明、列出风险。人评审结果，而不是在一个月后第一次看到成品。

技术同学到底要懂到什么程度

这件事要说细一点。

技术同学不需要成为广告业务专家，不需要记住每个客户、每个渠道、每个历史例外。但他必须懂六类东西。

• 业务目标。这个功能是为了提升投放效率、减少错误、支持新客户类型，还是满足合规要求？目标不同，取舍不同。
• 不可错边界。钱、权限、投放状态、数据归因、审计日志、合规审核，这些地方不能靠感觉。
• 核心状态和生命周期。广告计划从草稿到审核到投放到暂停到归档，每个状态允许哪些动作，必须清楚。
• 典型路径和高频例外。不用知道所有冷门例外，但必须知道最常见的几类。
• 验收标准。什么叫做对？页面怎么显示，接口怎么返回，错误怎么提示，日志怎么记录，测试怎么通过。
• 影响范围。这个改动会不会影响报表、结算、权限、老数据、已有客户。

除此之外的细节，应该进入规则库、案例库、测试集、需求上下文包。人可以查，AI 可以读，系统可以测。

如果一个技术同学说"我必须把所有细节都理解透，才能开始"，那说明团队没有把业务知识资产化。它还停留在手工作坊模式。

两个同学应该怎么协作

这两个人不一定要减少到一个人，但分工必须变。

我建议从"前端负责人 + 后端负责人"改成"业务切片负责人 + 质量和上下文负责人"，并且轮换。

• 业务切片负责人。对一个完整需求切片负责。让 AI 读代码、读文档、生成计划、改前端、改接口、补测试、跑验证。这个人要对最终业务结果负责。
• 质量和上下文负责人。负责检查需求拆解是否太大，规则表是否完整，测试是否覆盖反例，AI 是否误解上下文，是否影响其他模块。必要时让 AI 独立生成第二份风险清单或测试清单。

下一个切片两个人交换角色。这样做有几个好处：两个人都会逐渐具备全链路能力，不会形成前端等后端、后端等前端的队列；每个需求仍然有第二双眼睛；业务知识不会只被一个人吃掉。

如果任务真的很大，可以并行，但并行的边界要按业务切片拆，不要按页面和接口拆。比如一个人做"草稿创建闭环"，另一个人做"审核日志闭环"，而不是一个人只写页面，另一个人只写数据库。

给这个广告管理系统的一套落地流程

可以直接试两周，不需要大改革。

1. 建一个需求入口模板

每个需求进来，业务同学必须补齐这些最小信息：

• 业务目标；
• 用户角色；
• 三到五个典型例子；
• 三到五个不能发生的反例；
• 涉及金额、权限、投放状态、报表、审核的地方；
• 期望上线顺序：哪些必须第一版有，哪些可以第二版。

业务不一定会写得很工整，没关系。让 AI 帮它整理。但这些内容不能没有。

2. 技术接手后，先让 AI 出"需求拆解包"

包括流程、状态机、规则表、接口草案、数据影响、验收用例、风险清单。负责人只做审核和修正，不要从空白文档开始。

3. 开发前先定验收，不先定排期

每个切片必须有可运行的验收标准。比如：

• 给定一个未审核账户，创建计划时应返回什么错误；
• 给定一个代理商账户，复制计划时哪些字段必须清空；
• 给定一个暂停中的计划，哪些按钮不可点击；
• 给定一个预算修改，日志里必须记录哪些字段。

这些用例写出来以后，Codex 或 Claude Code 才有明确轨道。否则 AI 只能猜。

4. 每个需求按竖切片进开发

一个切片包括页面、接口、数据、权限、日志、测试。能少做就少做，但必须闭环。不要出现"前端做完等后端"、"后端做完等联调"这种传统节奏。

5. AI 每次提交都必须带三样东西

• 变更摘要：改了哪些文件，为什么改；
• 验证结果：跑了哪些测试，哪些没跑，为什么；
• 风险清单：哪些业务规则可能还需要业务确认。

这不是形式主义。Anthropic 和 OpenAI 的 agent 文档都在强调验证、trace、review、guardrails。复杂业务系统没有这些东西，AI 越强，越容易把错误做得很完整。

6. 每周沉淀一次业务规则库

把本周确认过的规则、反例、测试、字段含义、权限边界放进项目上下文文件，比如 AGENTS.md、CLAUDE.md、业务规则文档、测试数据集。下一次 AI 开发必须读取这些材料。

这一步做起来很普通，但它会改变速度。因为团队不再每次重新理解业务，而是在复用已经确认过的上下文。

需求太大时，不要让技术同学独自背锅

还有一个管理问题要说清楚。业务同学总是提大需求，不是技术同学一个人的问题。

业务希望全、广、一次到位，这很正常。但在 AI 时代，业务也要改变输入方式。它不能只说"我要完整广告管理能力"，然后把复杂性甩给技术。它要提供优先级、例子、反例、不可错边界。否则 AI 也只能在一堆模糊描述里猜。

管理者要建立一个规则：大需求可以进来，但不能以大需求的形态进入开发。所有需求必须先经过 AI 拆解，变成可验收、可回滚、可上线的切片。

该不该由一个人统一负责

我的建议是：可以由一个人统一负责一个切片，但不要让一个人长期单点负责整个系统。

广告管理系统的业务复杂度很高，完全靠一个人长期扛，会有风险。更合理的是双人小队，但角色不是前端和后端，而是：

• 一个人当 owner，负责本切片端到端交付；
• 一个人当 reviewer，负责规则、测试、风险、可维护性；
• 下个切片交换；
• 所有确认过的规则进入共享上下文和测试集。

这样既保留两个人的协作，又去掉前后端割裂。

最后，判断这个团队是否在变快，看五个指标

• 一个需求从进入到拆成切片，是否能在一天内完成；
• 第一个可运行切片，是否能在三到五天内出来；
• 每个切片是否都有验收用例，而不是只靠口头确认；
• AI 生成的代码是否能自动跑测试、生成摘要、列风险；
• 业务规则是否每周沉淀，而不是每次重新讲一遍。

如果这五个指标都做不到，不要急着说"业务太复杂"。先改工作方式。

AI 时代，复杂业务系统仍然需要人负责。只是负责人不应该再把时间主要花在手写代码和反复口头理解需求上。他应该把复杂业务变成上下文、规则、测试和可交付切片。AI 负责大量生成、整理、比对和验证。人负责边界、判断和结果。

这才是广告管理系统这类产品在 2026 年更合理的开发方式。

参考资料

• Anthropic, Best practices for Claude Code
• OpenAI Developers, Codex documentation
• OpenAI Developers, Evaluate agent workflows
• OpenAI Developers, Guardrails and human review
• Anthropic, Introducing the Anthropic Economic Index
• Stanford HAI, The 2025 AI Index Report
• Simon Willison, Context engineering
• Cognition, Don’t Build Multi-Agents
• LangChain Blog, How and when to build multi-agent systems