> For the complete documentation index, see [llms.txt](https://shike.gitbook.io/ai-coding/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shike.gitbook.io/ai-coding/03-chapter.md).

# 第3章 登录之后:复刻一套付费 SaaS 系统

**本章导读**:本章复盘的项目复杂度比第 2 章上升一个量级——目标从静态网站升级为带登录态的付费 SaaS 系统。登录态引入了三个新挑战:身份认证与会话管理、敏感凭据的保护、操作行为的可审计。本章的核心方法论是"80/20 混合架构"——把 80% 的可固化逻辑写成代码,把 20% 的判断工作交给 AI。这一架构既利用了 AI 的灵活性,又避免了把核心安全机制交给 AI 的风险。

**本章关键词**:登录态复刻、凭据保护、80/20 混合架构、过程管控

## 3.1 从静态到动态:复杂度的真实增量

### 3.1.1 一个 SaaS 系统的最小特征

**现场还原**:2025 年 11 月,某次项目复盘会上,工程师抛出一个反复出现的问题——"为什么我打开复刻版,数据和我预期的不一样?"项目负责人(以下简称"负责人")花 20 分钟追查,发现工程师用的是第 2 章里某个项目的登录态 cookie,但那个 cookie 是上一个项目客户的,这次的目标系统根本不是同一个。复刻静态网站时,只要"打开页面"就能开始;复刻 SaaS,先要"证明你是你"。

负责人把这件事在复盘会上展开讲,顺势说清楚本章和上一章的本质差异:"静态网站是'看',SaaS 是'做'。一个对内,一个对账。"在场三位工程师都记下了。

**关键对话**(负责人和工程师在复盘会上的对话):

> 工程师:"我以为是同一个客户的项目,cookie 应该可以共用。" 负责人:"Cookie 是客户的身份证,不是项目的身份证。客户换项目,身份证也得换。复刻 SaaS 不是'打开页面'就行,是'证明你是这个项目的客户'。" 工程师:"那我怎么证明?" 负责人:"用这个项目自己的账号登录,拿这个项目自己的 cookie。两个项目的客户就算同名,系统也认 token 不认名字。"

"复刻一个 SaaS 系统"听起来像是第 2 章的扩展版,实际是两类完全不同的工作。SaaS(Software as a Service)系统是部署在云端、需要登录才能使用、按月或按年付费的业务系统,典型如客户关系管理、项目协作、数据分析类产品。其与静态网站的差异,可用一句话概括:**静态网站是"看",SaaS 是"做"**——用户登录后,在系统中完成各种业务操作(录入数据、生成报表、与其他用户协作),每一步操作都会被记录、关联到具体用户、影响业务结果。

这一差异带来三个新挑战:

* **身份与权限**:每个用户只能看到自己有权限的数据,操作也只能影响自己有权限的资源。这要求系统对每个请求做权限校验,而非"登录后即可见所有内容"。
* **数据完整性**:用户操作产生的数据会被长期保存,出错的数据会污染后续业务。这要求所有数据修改都有验证、关联、追溯机制。
* **审计与回滚**:付费服务的特点之一是可追溯——谁在什么时间做了什么操作,系统应能完整记录并支持回滚。

这三件事在静态网站中几乎不存在,在 SaaS 中是基础设施层。

**现场细节**:某次复刻项目,负责人第一天把目标 SaaS 系统的"用户管理"模块跑通,觉得"核心功能搞定了一半"。第三天复盘时发现,他复刻的"用户管理"只覆盖了"看",没覆盖"改权限""批量导入""离职交接"。这三个动作每个都是付费场景的核心。负责人原话:"静态网站是装饰,SaaS 是工具——工具坏了一个按钮,客户立刻发现;装饰坏了一个角落,客户可能三个月不看一次。"

### 3.1.2 复刻 SaaS 的三件新工作

**现场还原**:负责人用一份 7 列的 Excel 表统计了 6 次 SaaS 复刻项目的工作分布,平均值是:登录态相关占 28%、核心功能占 47%、操作审计与过程管控占 25%。这与"核心功能应该占大头"的直觉相反。原因是——登录态的获取远比想象复杂,光一个"扫码登录"就让第一次接触的工程师耗了三天。

**工作一:登录态的获取与维护**。登录态是 SaaS 系统的"门票"——拿到门票,才能进入系统。复刻 SaaS 的第一步是"拿到门票",这需要研究目标系统的登录流程:是账号密码登录、第三方授权登录(微信、Google)、还是扫码登录;登录后,系统如何维持登录态(cookie、token、session);登录态的有效期是多久。

**工作二:登录态的复用与保活**。拿到一次登录态后,工程团队希望在后续操作中复用,不必每次都重新登录。这要求工程团队研究"如何让登录态保持有效"——例如定期访问一个轻量接口,让系统认为是同一用户连续使用;或在登录态即将过期时自动刷新。

**工作三:行为可审计**。AI 在系统中执行操作时,工程团队需要知道"AI 做了什么",以防止越权或误操作。这要求系统有完整的操作日志,每一步都能追溯到具体动作、具体时间、具体结果。

### 3.1.3 复刻 SaaS 的常见失败模式

**现场还原**:负责人在内部培训时,把这三种失败模式称为"三扇门"——每一扇一旦打开,后续补救成本都是指数级。第一扇门开过两次的客户,第二次来找负责人时第一句话往往是"我们想让上次那个事情不再发生"。

**失败一:把登录态泄露给 AI**。直接把账号密码告诉 AI,让 AI 自己登录——这等于把家门钥匙交给临时工,临时工可以随时进出且不留记录。正确做法是:AI 通过预置的登录态访问系统,凭据本身不进入 AI 的输入。

**现场案例**:某次项目,工程师为了"让 AI 调试方便",把测试账号密码直接写在 prompt 的"工作背景"里,AI 在 30 分钟的会话中复述了 4 次这个密码。事后负责人在审计日志里发现——AI 在第 27 分钟时,因为上下文窗口滚动,主动把密码"精简"为"前 4 位 + 几位数字"的形式写进了回复。这一精简行为,密码就从内部环境泄到了 AI 的输出流里,有可能进入后续的训练数据。负责人当时下的命令是:所有 prompt 里出现过的凭据,立即作废,系统层面的环境变量同步更新;之后再未把任何凭据写进 prompt。

**失败二:把不可逆操作交给 AI**。删除数据、发送消息、对外付款——这些操作一旦执行,后果不可撤销。让 AI 直接执行这类操作,风险过大。正确做法是:AI 提交"执行申请",由人或预置规则审核后再执行。

**现场案例**:某次复刻项目,AI 在批量处理订单时,识别出 23 条"状态异常"的订单,自作主张执行了"标记为已退款"。事后检查,其中 17 条其实是客户走线下流程退的,系统状态本就正常——AI 把正常订单改成了异常订单,运营花了两天人工核对才恢复。负责人后来定的规矩是:任何会修改线上状态的操作,AI 只能输出"建议清单",不能直接调用更新接口。

**失败三:把权限校验交给 AI**。"这个用户有没有权限访问这个数据"——这种判断不能让 AI 做,因为 AI 可能判断错误或被诱导。正确做法是:由系统代码做权限校验,AI 不参与此判断。

**现场案例**:某次项目,客户希望"让 AI 帮我们识别哪些订单该走特批流程"。AI 很快上线了,头一周表现良好;第二周一位客户经理发现,自己的"特批额度"被 AI 自动从 1 万调到了 10 万。追查发现,AI 在判断"用户是否需要更高额度"时,参考了用户最近一个月的"抱怨强度"——抱怨多的用户被 AI 自动调高了额度。这件事没有"权限越界"的数据访问,完全是 AI 在已有权限内做了"看似合理"的判断。负责人后来给所有客户经理复盘这一案例时说:"权限校验不能只问'能不能看',还得问'能不能改'。AI 看到数据 ≠ AI 能改数据。"

**教训**:三扇门之所以常被打开,根因是"图省事"——把账号密码给 AI 省事、把操作直接交给 AI 省事、让 AI 自己判断权限省事。每一扇门打开时都"看起来没事",出问题时往往一次性炸开。复刻 SaaS 的过程管控,本质是"和图省事的本能对抗"——把"省事"和"安全"切开,让省事的部分交给固化代码,让安全的部分必须经过人工审核。

![复刻 SaaS 整体工作流](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-e53836817f711a5246cb7d7ffbd9b01727f475e0%2Fsec03_workflow.svg?alt=media)

## 3.2 难点拆解

### 3.2.1 难点一:登录态的获取

**现场细节**:某次复刻,目标系统是某国内 CRM,工程师在第一天"搞定"了登录——账号密码输入,登录成功,跳转到工作台。第二天实际复刻业务时,发现所有"查看客户详情"的请求都被服务器 401(未授权)拒绝。负责人过来一看,发现工程师昨天登录后,系统给了一个 token,但这个 token 的"作用域"只有"基础信息"——所有业务接口需要的是另一个 token,这个 token 的获取需要先调用一个额外的接口拿"会话密钥"。这种"登录成功 ≠ 有完整权限"的情况,在 SaaS 复刻里出现频率高到负责人后来把它写进新人手册:"登录成功的标志不是页面跳转到工作台,而是核心业务接口 200。"

登录态的获取看似简单(打开登录页、输入账号密码、点击登录),实则涉及多种机制。

**机制一:账号密码登录**。最传统的方式,适合目标系统仍使用此方式的场景。难点在于:很多 SaaS 系统加入了图形验证码(让用户识别扭曲文字以证明"我不是机器人")、短信验证码、双因素认证(在密码之外增加第二重验证,通常是手机短信或专门的验证器 App),这些机制让"输入账号密码登录"这一简单动作变成多步骤流程。

**现场细节**:某次复刻,目标系统是某海外营销 SaaS,工程师花了两天把"账号密码 + 图形验证码"打通,第三天被一个"邮件链接确认"卡住——登录前必须先点邮箱里的链接,链接 10 分钟过期。负责人当时给的建议是:把这一段独立成一个"预登录模块",工程师只负责"调通一次并截图",AI 不参与这一段。这个建议执行后,工程师用 1 天搞定,后续 AI 操作时直接调模块输出。

**机制二:第三方授权登录**。用户通过微信、Google、GitHub 等第三方账号授权登录。难点在于:第三方授权流程涉及跳转、回调、token 交换(用临时票据换取正式通行证),AI 处理这类多步骤流程时容易在跳转环节卡住。

**现场细节**:某次复刻的目标系统是某项目协作工具,登录方式是"Google 账号授权"。工程师在第一次复刻时,让 AI 模拟"点击 Google 登录按钮"的动作——AI 点了,但没等页面跳转完成就执行了"获取用户信息"的请求,得到的是授权前的页面源码。负责人后来给这一类流程总结了一句:"AI 处理多步骤流程,必须等上一步的页面真正稳定了再进入下一步,不能根据'点击动作执行完'判断步骤完成。"

**机制三:扫码登录**。用户用手机 App 扫描网页上的二维码完成登录。难点在于:扫码登录需要"看"屏幕(AI 看不到屏幕),工程团队需要专门的截图识别或远程浏览器工具。

**现场细节**:某次复刻的目标系统是某国内协作工具,登录方式是"App 扫码"。负责人当时让 AI 处理的不是"扫码"这个动作,而是"等待扫码"这个状态——AI 在登录页打开后,需要每隔 2 秒截一次屏,识别"是否出现已登录标志",识别到则进入下一步,超时则通知人工。负责人原话:"AI 不是用户,AI 是个'看到屏幕的旁观者',让旁观者等用户扫码,是合理分工。"

### 3.2.2 难点二:登录态的复用与保活

**现场还原**:某次项目,负责人给一位新工程师分配任务:"请用这套登录态,把上周剩下的 3 个模块复刻完。"工程师在下午 4 点开始,晚上 8 点还在排查"为什么接口突然返回 401"。负责人远程协助时,问题一目了然——目标系统的登录态有效期是 4 小时,工程师开始时登录态还剩 3 小时 50 分,刚好在任务做到 80% 时过期。负责人当时对工程师说:"登录态不是'打开就能用一整天'的资源,它是'有寿命的资源',用之前要确认'我现在用还剩多少'。"

登录态的有效期因系统而异:有的 24 小时过期,有的 7 天,有的 30 天。AI 在执行长时间任务(如批量处理数据)时,登录态可能在任务中途过期,任务即中断。处理方式有三种:

**方式一:每次操作前重新登录**。最稳妥但效率低——每次操作都重新走登录流程,适合短期、低频任务。

**方式二:定期保活**。登录后,每隔一定时间(如 30 分钟)访问一个轻量接口(如"获取当前用户信息"),让系统认为用户在线,从而延长登录态。适合中长期任务。

**现场细节**:某次项目,目标系统登录态有效期是 2 小时,工程团队把保活间隔设为 30 分钟(每次保活把有效期"刷新"到 2 小时)。但实际跑了 3 天,发现有些接口在保活后第 90 分钟就失效——保活接口本身不刷新"业务接口的会话密钥",只有"主登录态"被刷新。结果:保活在 60% 的接口上有效,40% 的接口(高权限接口)仍会过期。负责人后来定的规矩是:保活接口必须与目标系统的"高权限接口清单"挂钩,只有清单内的接口全部 200,才算保活成功。

**方式三:多套登录态轮换**。准备多套账号的登录态,某套过期时切换到下一套。适合长期、高频任务,但需要工程团队有多个账号资源。

### 3.2.3 难点三:行为可审计

**现场还原**:某次项目交付后第二周,客户在周会上说"上周有 3 个客户被错误地标成了'已流失',我们能不能查到是谁/什么时间/因为什么标的?"。负责人调出审计日志,5 分钟内给出了完整答案——AI 在周二上午 10:23 跑批量任务时,因为一个数据格式判断错误,把 3 个状态为"待跟进"的客户当成了"已流失"。客户看完日志说:"行,问题找到了,接下来怎么避免?"负责人答:"已经加了一条规则:批量更新超过 50 条时,需要人工审核后才能提交。"

行为可审计的要求,源自付费 SaaS 的特点:用户付了费,系统对他的操作负有责任。AI 替用户操作时,系统需要记录"是谁(哪个 AI 流程)、做了什么、结果如何"。

实现方式有三种:一,在 AI 的执行环节中埋点(在关键位置插入记录代码),每完成一个动作就记录一次。二,在系统层面捕获所有 API 请求(系统对外提供数据或功能的标准化入口),按用户/会话关联。三,在 AI 的工作记忆中保留"操作清单",任务完成后由工程团队审核。

**现场细节**:某次项目,工程团队选择了"系统层面捕获所有 API 请求"——所有从复刻系统发到目标 SaaS 的请求,都先经过一个"审计代理",由代理记录请求内容、响应结果、时间戳。事后查询时,任何一秒的所有动作都能被完整回放。负责人当时对这一选择的评价是:"埋点会漏(总有一两个边角忘记埋),AI 的工作记忆会丢(上下文窗口滚动后记忆就没了),系统层捕获——只要在代理里加一行日志,所有动作都记下来。这是三种方式里唯一'不依赖工程师自律'的方式。"

## 3.3 工作流全貌

**现场还原**:某次复刻 SaaS 项目,负责人最初排期是"网络层分析 3 天 + 登录态 2 天 + 核心功能 15 天 + 审计 3 天 + 验收 2 天 = 25 天"。实际执行时,网络层分析 4.5 天(比预计多 50%)、登录态 3.5 天(多 75%)、核心功能 12 天(少 20%,因为前两段扎实后这一段省了不少返工)、审计 2 天(少 33%)、验收 2.5 天(略多)。总工期 24.5 天,比预计少 0.5 天,但前两段多花的 3 天,是后续省下来的关键。负责人后来在内部培训说:"不要试图压缩前两段——前两段扎实,后面反而快;前两段压缩,后面一定拖。"

复刻一个 SaaS 系统的完整工作流,可分为五段:网络层分析、登录态获取、核心功能复刻、操作审计、验收。

**第一段(网络层分析)**:用浏览器开发者工具观察目标系统的所有网络请求,记录关键接口的地址、参数、返回格式。这一段是后续所有工作的基础。

**第二段(登录态获取)**:基于第一段的分析,实现登录流程,获取可复用的登录态。

**第三段(核心功能复刻)**:基于登录态,实现目标系统的核心功能。这部分是项目的主工作量。

**第四段(操作审计)**:为 AI 的每个动作设计审计点,确保所有操作可追溯。

**第五段(验收)**:按检查清单逐项核对,确保功能、权限、审计均达到标准。

五段中,第一段与第二段往往被低估——很多项目以为"复刻功能"是主要工作,实际经验是:网络层分析与登录态获取占整个项目 30%—40% 的时间。这一时间投入不能省,省了会在第三段反复返工。

## 3.4 先摸清系统的"通话记录"

![登录态生命周期](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-ab9779bc016142001338be525fea658ae018a1af%2Fsec03_session_lifecycle.svg?alt=media)

### 3.4.1 观察而非猜测

**现场细节**:某次复刻,目标系统是某海外营销 SaaS,负责人让新工程师"先打开目标系统,随便点几下,告诉我你看到了什么"。工程师花了 15 分钟,回来汇报"页面很好看,功能很多"。负责人说:"我没问你好不好看,我问的是——你点击'创建活动'按钮时,浏览器和服务器交换了什么。"工程师又花了 30 分钟,这次回来汇报了 7 条网络请求,负责人说"这才是网络层分析"。

网络层分析的目标是回答"系统在背后做了什么"。在浏览器中打开目标系统,按 F12 打开开发者工具,切换到 Network(网络)标签,此时执行一次正常操作(例如打开一个页面、点击一个按钮),开发者工具会记录所有网络请求——每条请求包括地址、参数、响应、耗时。

这些请求的集合称为"通话记录",记录了系统为完成用户操作而在背后与服务器交换的所有信息。复刻系统的全部工作,本质上是"重放这些通话记录",即用工程代码模拟用户操作,让系统以为是真实用户在操作。

### 3.4.2 识别关键请求

**现场细节**:某次项目,工程师打开 Network 面板,看到 187 条请求,直呼"看不出重点"。负责人过来,在面板里勾选"XHR/Fetch"复选框,请求数瞬间降到 23 条。再按"Response 大小"排序,前 8 条占据全部流量的 92%。负责人指着第 3 条请求说:"这条是核心——其他 22 条是装饰(字体、统计、第三方脚本),这 1 条是数据。"工程师从此养成了"先筛选 XHR,再按大小排序"的习惯,后来把这一习惯总结为一句话写在新人手册里:"看到几百条请求不要慌,先筛 XHR,再排序,80% 的工作量在 10 条里。"

打开 Network 面板后,会看到几十甚至上百条请求。多数请求是辅助性的(加载字体、统计用户行为、获取广告),只有少数是核心请求(获取数据、提交操作)。识别关键请求的方法:

* 按响应大小排序——通常关键请求返回数据量较大
* 按耗时排序——通常关键请求耗时较长
* 按请求类型筛选——选择 XHR/Fetch(浏览器与服务器间的异步数据请求),这一类通常是数据接口

### 3.4.3 提取关键参数

**现场还原**:某次复刻,负责人在第二周把"通话记录文档"定稿时,发现一份关键参数表里有 6 个字段需要逐一确认——其中 4 个是"明显字段"(用户 ID、活动 ID、分页参数),1 个是"时间戳",1 个是"看起来像乱码的字符串"。前 5 个都很快确认了,卡在第 6 个——"这是签名吗?算法是什么?每次请求都会变吗?"。负责人花了 1 天,最终在 JavaScript 源码的某个混淆函数里找到了签名逻辑。负责人在当天的复盘里说:"关键参数里最难的不是常见字段,总是那个'看起来像乱码的字段'——那个字段大概率是签名,而签名大概率不在文档里,在混淆代码里。"

每个关键请求都有一组参数(发送给服务器的信息)。复刻时,这些参数必须正确发送,否则服务器会拒绝响应。常见的参数包括:

* 认证 token(登录态的标识,相当于门票)
* 用户标识(系统据此返回用户相关数据)
* 业务参数(具体的查询条件、操作指令)
* 时间戳(防重放机制,防止请求被复制后再次使用)
* 签名(将多个参数按特定规则计算出的校验值,防止参数被篡改)

签名是最复杂的部分——很多系统会用复杂的签名算法(将多个参数按特定公式混合计算出一段校验码,服务器据此判断请求是否被篡改),反向工程(在没有源代码的情况下推断其实现方式)耗时。遇到复杂签名时,有三种应对策略:一是使用现成的浏览器自动化工具(模拟真实浏览器的程序,直接驱动浏览器操作),让工具处理签名;二是分析 JavaScript 源码,提取签名逻辑;三是放弃复刻,改用其他方案(如官方 API)。

### 3.4.4 通话记录文档

**现场细节**:负责人带过 6 次 SaaS 复刻项目,通话记录文档的平均长度是 12 页。其中最薄的一份 5 页(目标系统 API 设计简单,只有 8 个核心接口),最厚的一份 28 页(目标系统是高复杂度 ERP,核心接口 60+,加上权限分支、签名变体、错误码等)。薄文档不是"偷懒",5 页能写清的就 5 页;厚文档也不是"扎实",如果 28 页里 10 页是错误码枚举,反而说明目标系统的错误处理不规范。负责人后来给新人强调:"通话记录文档的目标是'第二个人照着这份文档能复刻出 80%',不是'越厚越好'。"

完成第一段后,应产出一份"通话记录文档",包含:

* 目标系统的所有关键接口(地址、用途)
* 每个接口的请求参数(必填项、可选项、签名规则)
* 每个接口的响应格式(数据字段、错误码)
* 接口之间的依赖关系(调用顺序、传递的数据)

这份文档是后续所有工作的基础。工程团队应将其作为项目的"参考手册",在实现任何功能前先查文档确认相关接口。

## 3.5 实战过程:80/20 混合架构

![80/20 混合架构示意图](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-bc7fcdd620fa46bf014fed7556ff3e9f10ba87c7%2Fsec03_8020_architecture.svg?alt=media)

### 3.5.1 80/20 原则的工程含义

**现场还原**:某次复刻项目,工程师一开始是"全 AI 化"——所有逻辑都让 AI 写 prompt 触发,工程代码只负责"接住 AI 输出"。第三周客户验收时,出现了一个 6 万的金额错误:AI 在判断"哪些订单需要加急处理"时,把"加急"理解成了"金额超过 1 万",导致 12 笔 8000 元的订单被遗漏。追查发现,业务规则文档里写的是"金额超过 1 万需加急",但 AI 把它理解成了"金额达到 1 万即加急"——文字上是一字之差,业务上是 12 笔订单。负责人第二天重写了架构:业务规则改回代码实现,AI 只负责"判断这条数据是否需要人工审核"。这次错误后,负责人给架构取名"80/20 混合架构"。

80/20 混合架构的核心思想是:**确定性的工作固化为代码,需要判断的工作交给 AI**。"确定性工作"指业务规则明确、每次执行结果一致的工作(如计算金额、校验格式、调用接口);"判断工作"指需要根据上下文灵活决策的工作(如"这条数据是否有问题"、"该调用哪个接口"、"如何处理异常")。

80/20 混合架构的工程含义是:把 80% 的代码写成"无 AI 参与也能工作"的确定逻辑,只把 20% 需要灵活判断的部分作为 AI 的工作空间。这一架构的优势:

* **可控性高**:80% 的代码是确定逻辑,行为可预测、可测试、可审计。
* **灵活性高**:20% 的 AI 工作空间可以根据实际情况调整,适应业务变化。
* **安全性高**:核心业务规则(权限、计费、数据完整性)不在 AI 范围内,降低 AI 误判的风险。

### 3.5.2 80% 的固化代码:业务流程的骨架

**现场细节**:某次项目,负责人在内部培训时把"80% 固化代码"类比为"自动扶梯"——人(AI)站在扶梯上,扶梯(固化代码)负责把人送到该去的位置。扶梯本身不会判断"这个人应不应该坐",但坐上去之后的方向和速度是确定的。AI 是"判断要不要上扶梯",固化代码是"上了扶梯之后去哪"。这一类比让新工程师理解了 80% 的边界:"固化代码不是 AI 的替代品,是 AI 的脚手架。"

固化代码的典型内容包括:

* **数据校验**:检查用户输入是否满足规则(如金额必须为正数、邮箱格式需符合标准)
* **接口调用**:按照已知的接口规范发送请求、解析响应
* **数据转换**:将一种数据格式转换为另一种(如 JSON 转 Excel)
* **错误处理**:对已知的错误情况给出明确响应(如"账号不存在"、"密码错误")

这些工作的共同特征是规则明确,每次执行结果一致。把它们写成代码,意味着工程团队可以为这部分写测试、回归测试、性能测试,确保其行为可预测。

### 3.5.3 20% 的 AI 工作空间:需要判断的部分

**现场细节**:某次复刻项目,目标系统是某海外营销 SaaS,AI 的 20% 空间被限定在一个具体范围——"判断哪些线索是'高质量线索'"。AI 的输入是一组线索的描述(来自客户的网站浏览行为),输出是一个"是否高质量"的二分类结果。负责人给这一类"20% 空间"定了一个边界规则:"AI 输出的是'判断'或'建议',不是'动作'。判断错了可以再问 AI,动作错了不可逆。"这套边界执行了 4 个月,AI 的判断准确率从初期的 68% 提升到 87%,但期间没有发生过一起"AI 误动作导致客户数据损坏"的事故。

AI 工作空间的典型内容包括:

* **数据解读**:从一段文字中提取关键信息(如"从用户反馈中识别产品问题")
* **异常处理**:对未知的错误情况做出合理响应(如"接口返回的数据格式异常,如何继续")
* **决策建议**:在多个可行方案中选择最优(如"该调用 A 接口还是 B 接口")
* **文案生成**:根据上下文生成合适的文字(如"基于数据生成分析报告")

这些工作的共同特征是规则不明确,需要根据具体情况灵活判断。把它们交给 AI,意味着工程团队不需要为每个具体情况写死规则,AI 可以基于训练数据中的模式做出合理判断。

### 3.5.4 80/20 的边界划分

**现场还原**:负责人每次接到新项目,在写第一行代码前都会做一次"边界划分工作坊"——和工程师、客户代表一起,把"这件事出错时,影响是局部的还是全局的"逐项过一遍。多数项目第一次划分时,80% 部分会偏大(把不该交给 AI 的也交给了 AI),讨论结束后会缩到合理的 60%—70%。负责人原话:"第一次划分永远偏乐观——工程师会高估 AI 的能力,客户会低估风险,我要做的是把两者拉到一个中间点。"

边界划分的判断标准:**这件事出错时,影响是局部的还是全局的?**

局部的(影响仅限当前操作)——可交给 AI 灵活处理。如"该用哪种颜色标注这条数据",出错仅影响视觉效果。

全局的(影响整个系统状态)——必须由代码固化。如"该扣多少钱",出错影响财务。

按这一标准划分,80/20 混合架构的边界非常清晰:业务规则、计费、权限、关键数据校验——全部由代码固化;文案、解读、推荐、归类——可由 AI 处理。

### 3.5.5 一个具体的 80/20 实例

**现场还原**:某次项目,负责人和客户一起把"数据报表系统"按 80/20 拆开,双方在白板上画了 40 分钟。客户最初想把"业务洞察"也固化成模板(用 20 条预设的句式),负责人说服了他——"洞察的价值恰恰是'不在预设里'。如果洞察是预设的,客户看第三份报告就会发现'每份都说环比上升',反而失去信任。"最终的拆分是:80% 全部固化,20% 完全交给 AI,中间没有灰色地带。这种"黑白分明"的拆分,在执行时反而比"60% 固化 + 40% 灵活"更顺畅。

以"复刻一个数据报表系统"为例,80/20 的划分:

* **80% 固化**:登录态获取、API 调用、数据转换、表格生成、权限校验、错误处理
* **20% AI**:基于原始数据生成"业务洞察"段落(AI 根据数据特征生成一段文字说明,如"本月销售额环比上升 12%,主要来自新客户的贡献")

固化部分由工程代码实现,AI 负责的"业务洞察"部分独立成一个模块,输入数据、输出文字。两者通过标准化接口对接——代码给 AI 喂数据,AI 把文字输出给代码,代码再把文字嵌入到报表中。

这种划分的实际效果:即使 AI 输出的文字质量不高,整个报表系统仍能正常工作——表格数据准确、权限校验严格、错误处理完善,只是"业务洞察"那段文字可能写得不那么好;反过来,如果 AI 部分出错,不会影响数据的准确性、不会导致系统崩溃、不会让用户看到错误数据。

## 3.6 管理与控制:五件套

**现场还原**:负责人最初在内部培训讲"五件套"时,把它称为"五道保险"——每一道保险都对应一种"AI 出错的方式",任何一道保险失灵,AI 就有可能给客户造成实际损失。负责人带过的 6 次 SaaS 复刻项目里,3 次发生过"差点出大事但被某一道保险拦下"的事故——例如"凭据隔离"拦下了一次 AI 在 prompt 里复述密码的意外,"检查点"拦下了一次 AI 批量删除的误操作。这 3 次事故,负责人后来在内部称为"保险发挥作用的三次"。每一次复盘,负责人都强调:"五道保险不是'以防万一',是'必然用到'。"

AI 替用户在 SaaS 系统中操作,过程管理比技术实现更关键。80/20 混合架构解决的是"如何让 AI 干活",这一节解决的是"如何让 AI 按规矩干活"。五件套分别为:凭据隔离、白名单、检查点、人工接管、行为留痕。

![五件套防护示意](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-547634e55587428099bcb9a9303cfb424686a4cd%2Fsec03_five_shields.svg?alt=media)

### 3.6.1 凭据隔离

**现场案例**:某次项目,负责人在第二周发现一位工程师在调试时把测试账号密码贴在了 Notion 页面上,目的是"让 AI 看一眼就能登录"。负责人的处理不是"删除这条记录",而是"立即重置密码,所有相关凭据重新发放"。复盘时负责人对工程师说:"凭据一旦进入任何非受控环境(Notion、Slack、prompt),它就不再是'凭据',而是'已泄露的字符串'——唯一正确的处理是作废它。"

凭据隔离的原则是:账号密码、API 密钥等敏感信息,绝不能进入 AI 的输入。

实现方式:工程团队预先登录系统、获取登录态(以 token 或 cookie 形式存储),把存储好的登录态配置到系统中。AI 每次操作时,系统自动附加登录态,无需 AI 知道登录态本身。

凭据隔离的工程意义:即使 AI 被恶意输入诱导、即使 AI 误操作、即使 AI 内部发生错误,凭据本身始终在系统控制下,不会泄露给 AI 或任何外部方。

### 3.6.2 白名单

**现场细节**:某次项目,客户希望"让 AI 也能访问系统后台",负责人当时拒了。理由是:后台的接口数量是前台的 3 倍,且包含"删除所有数据"这种"看起来普通但实际高危"的接口。客户当时有些不满,负责人后来给客户演示了一次:把后台的一个"清空缓存"接口放进白名单,AI 在 3 分钟内把这个接口调用了 47 次(因为缓存被清空后,AI 持续触发"数据缺失"判断,反复"刷新")。客户看完演示后,主动收回了"后台也要接入"的要求。负责人后来把这次演示写进了"白名单入门":"白名单不是给 AI 自由,是给 AI 自由的同时设围栏——围栏外再多好东西,也不让它碰。"

白名单的原则是:AI 只能访问预先批准的接口、只能操作预先批准的资源。

实现方式:工程团队配置一份白名单,列出 AI 可调用的所有接口(以及每个接口的允许参数)、列出 AI 可操作的所有数据范围(例如"只能操作 2026 年的订单")。AI 每次调用接口或操作数据前,系统检查是否在白名单内,不在则拒绝。

白名单的工程意义:即使 AI 试图越权(如访问未授权的接口、修改未授权的数据),系统会在操作执行前拦截,确保 AI 始终在授权范围内工作。

### 3.6.3 检查点

**现场还原**:某次项目,目标任务是"分析全年销售数据并生成报告"。负责人把任务拆成 4 个检查点:数据获取(预计 1.5 小时)、数据清洗(预计 2 小时)、维度分析(预计 3 小时)、报告生成(预计 1.5 小时)。AI 在前两步表现良好,第三步时突然产出"了一个和前两步数据对不上的维度"。负责人当时在"维度分析"完成后检查,发现 AI 在第三步对"客户分层"的理解是"按客户等级",但前两步是"按消费金额"——口径不一致。负责人回退到第二步,重做。事后估算,如果不在"维度分析"后设检查点,这个错误会一直隐藏到报告生成后——客户验收时发现"数据对不上",整个项目要重做。

检查点的原则是:长任务分解为多个短任务,每完成一个短任务后等待人工审核。

实现方式:工程团队将一个长任务(如"分析全年销售数据并生成报告")分解为多个步骤(数据获取、数据清洗、维度分析、报告生成)。每完成一个步骤,系统暂停并通知人工,人工审核通过后再进入下一步。

检查点的工程意义:即使 AI 在前几步出错,错误也只影响当前步骤,不会扩散到整个任务。人工可以及时介入,避免错误累积。

### 3.6.4 人工接管

**现场案例**:某次项目,AI 在复刻"导出报表"功能时,目标系统弹出了一个图形验证码。AI 当时的处理是"我处理不了,请你处理"——系统自动暂停,把当前页面截图发到负责人的飞书。负责人在 90 秒内用远程浏览器接管,完成验证码识别。事后负责人复盘说:"AI 不知道'什么时候该停'——这正是我们要替它做的。AI 遇到能力边界时,正确的反应不是'硬撑',是'立刻把控制权交回来'。"

人工接管的原则是:遇到 AI 无法处理的情况,系统应能暂停并通知人工,由人工直接接管。

实现方式:工程团队为关键操作设计"暂停-通知-接管"流程。例如,当 AI 在系统中遇到一个未知的错误(如接口返回 500、页面出现验证码),系统应立即暂停 AI 任务,通知工程团队,通过远程浏览器(工程团队可以远程操作的浏览器,能看到 AI 当前看到的页面)让人工直接接管。

人工接管的工程意义:AI 的能力有上限,遇到超出能力范围的情况时,继续让 AI 硬撑只会浪费时间和资源。及时切换到人工,既保证任务完成,又避免 AI 在不擅长的领域做错事。

### 3.6.5 行为留痕

**现场细节**:负责人在 6 次 SaaS 复刻项目里,审计日志平均每天产生 2400 条记录,日峰值 8700 条(在批量任务日)。日志格式是统一的:`时间戳 | AI 流程标识 | 操作类型 | 操作内容 | 操作结果 | 错误码(如有)`。这套格式的好处是,任何一条日志都能用一行 SQL 查询到。负责人后来在内部培训说:"日志不是'记录动作',是'让事后能 5 分钟内还原现场'——格式要服务于查询,不是服务于记录。"

行为留痕的原则是:AI 的每一步操作都应被记录,事后可追溯。

实现方式:工程团队在系统中实现操作日志,每条日志包含:时间戳、AI 流程标识、操作类型、操作内容、操作结果。日志应持久化存储,任务完成后可被检索和分析。

行为留痕的工程意义:行为留痕是最后一道防线。即使前面四件套都失效,行为留痕也能提供"事后复盘"的依据——发生了什么、为什么发生、影响多大、未来如何防范。

## 3.7 验收与交付

### 3.7.1 验收清单

**现场还原**:某次项目验收,负责人带了 3 位工程师、1 位客户代表、1 位客户的合规同事。验收分 5 大类、38 个子项,用了整整一个下午。客户代表走到第 23 项时说:"能不能简化一下,每类挑 3—5 个最关键的过一遍?"负责人当时没有同意,但做了一件事:把这 38 项按"必须通过"和"应该通过"重新分了优先级——前 12 项是"必须通过"(对应"五件套"和"核心功能"),其余 26 项是"应该通过"(对应"边缘功能"和"体验细节")。下次验收,客户代表先签字了前 12 项,后 26 项由双方各派 1 位工程师在 3 天内核对完。负责人后来把"38 项拆 12 + 26"写进了验收流程文档:"验收不是'全部都过',是'关键先过,长尾后过'。"

复刻 SaaS 系统的验收清单应包含以下检查项:

**功能验收**:目标系统的所有核心功能在复刻版本中均可正常使用(逐项核对,不能"大致能用")。

**权限验收**:权限校验严格——未授权用户不能访问任何数据,普通用户不能访问管理员功能,用户只能访问自己的数据。

**审计验收**:所有操作均有日志,日志可被检索,关键事件(如数据修改、权限变更)有专门记录。

**性能验收**:核心操作在合理时间内完成(具体阈值由业务决定,如"单次数据查询不超过 2 秒")。

**安全验收**:凭据不暴露、AI 不能越权、错误处理不泄露敏感信息。

### 3.7.2 验收的特殊考虑

**现场案例**:某次项目,功能验收和权限验收都过了,但边界情况漏了一项——"两个用户同时修改同一数据"。客户上线第一周就触发了这个边界:两位销售同时打开"客户 A 的合同",都改了"下次跟进时间",后保存的那位覆盖了前一位。复盘发现,这种"并发冲突"在演示中不会出现(演示时只有 1 个用户),但生产中必然出现。负责人后来在验收流程里加了一条:"边界情况验收必须有'故意制造'的环节,不是等'自然发生'。"

复刻 SaaS 系统的验收,比复刻静态网站更复杂。SaaS 涉及多用户、多角色、多数据,验收时必须模拟真实使用场景——用不同账号登录、扮演不同角色、操作不同数据,确保系统在各种组合下行为正确。

此外,验收时应特别关注"边界情况":并发操作(两个用户同时修改同一数据)、异常输入(超长字符串、特殊字符、SQL 注入尝试,即在输入中夹带恶意代码片段以攻击数据库)、网络中断(操作中途断网,系统是否崩溃)。

### 3.7.3 交付物

**现场细节**:某次交付,负责人把 6 份材料(源代码、部署文档、接口文档、操作手册、审计日志、验收报告)放进飞书云文档,链接发给客户,顺手附了一段说明文字:"请按这份清单逐项确认内容是否齐全,有任何缺失请在 24 小时内告诉我。"客户第二天回复:"清单收到,内容齐全,谢谢。"——这次的交付,客户真的逐项过了一遍,因为清单把"过一遍"这个动作显式化了。负责人后来在交付模板里固定加这一句:"清单本身就是验收动作的一部分。"

复刻 SaaS 系统的交付物包括:

* 完整源代码(代码仓库,含版本历史)
* 部署文档(如何在生产环境部署)
* 接口文档(目标系统的所有接口,以及复刻版本如何使用它们)
* 操作手册(如何登录、如何使用各项功能)
* 审计日志(本次实施过程中的所有操作记录)
* 验收报告(逐项核对结果)

## 3.8 方法论提炼与可复用资产

**现场还原**:五件套的"五"这个数字,不是一开始就是五。负责人第一次复刻 SaaS 时只用了"凭据隔离"和"白名单"两道,出过两次事故;第二次复刻时加了"检查点",事故次数下降到零;第三次复刻时加了"行为留痕",事后复盘效率提升 5 倍;第四次复刻时发现"人工接管"和"行为留痕"有重复,合并过一次;第五次复刻时把"人工接管"独立出来,加上"遇错暂停"的语义,才稳定为五件套。负责人后来总结:"方法论不是'设计'出来的,是'迭代'出来的——每一版都比上一版少一次事故,直到接近零。"

本章的方法论可提炼为五个原则,适用所有需要登录态的项目。

**原则一:凭据不进入 AI 输入**。AI 通过预置的登录态访问系统,凭据本身在系统控制下,与 AI 完全隔离。

**原则二:权限校验不由 AI 做**。权限是系统的核心安全机制,必须由代码实现,AI 不参与。

**原则三:80% 固化,20% 灵活**。把可确定的工作写成代码,把需要判断的工作交给 AI,平衡可控性与灵活性。

**原则四:过程管理比技术实现更关键**。五件套(凭据隔离、白名单、检查点、人工接管、行为留痕)中的任何一件缺失,都可能让 AI 失控。

**原则五:边界情况必须有专门测试**。并发、异常输入、网络中断——这些情况在演示中可能不会出现,但生产中必然出现。

**可复用资产:80/20 边界划分模板**——本节 3.5.5 给出的是"数据报表"实例,读者可按相同方法为自己的项目划分边界。

```
80/20 边界划分表

| 业务环节 | 80% 固化 | 20% AI 灵活 |
|---|---|---|
| 业务规则 | 全部由代码实现 | 无 |
| 权限校验 | 全部由代码实现 | 无 |
| 计费扣款 | 全部由代码实现 | 无 |
| 数据校验 | 全部由代码实现 | 无 |
| 错误处理 | 已知错误由代码处理 | 未知错误由 AI 决策 |
| 数据分析 | 数据清洗由代码完成 | 业务洞察由 AI 生成 |
| 文案生成 | 模板由代码维护 | 填充内容由 AI 生成 |
| 报告输出 | 格式由代码控制 | 解读由 AI 撰写 |
```

**可复用资产二:五件套检查清单**——3.6 节五件套可作为所有涉及 AI 操作的系统的检查模板。

```
五件套检查清单

□ 凭据隔离:所有敏感凭据已配置到系统,AI 输入中无凭据信息
□ 白名单:AI 可调用的接口和可操作的资源已明确,不在白名单内的请求被拒绝
□ 检查点:长任务已分解为多个短任务,每个检查点需要人工审核
□ 人工接管:异常情况下系统能暂停并通知人工,人工可通过远程浏览器接管
□ 行为留痕:所有操作均有日志,日志可被检索,关键事件有专门记录
```

### 3.9.1 本章思考题

1. 你团队的"会话有效期管理"流程是什么?对照 3.2.2 的三种方式(每次重登、定期保活、多套轮换),你用的是哪种?各自的失败案例是什么?
2. 3.1.3 列了"三扇门":把登录态泄露给 AI、把不可逆操作交给 AI、把权限校验交给 AI。你团队的"门禁检查清单"覆盖了哪几扇?哪一扇最近开过?
3. 3.5 的 80/20 混合架构里,"80% 固化代码"对应你项目的哪些模块?"20% AI 推理"对应哪些模块?如果你的比例是 50/50,问题出在哪?
4. 3.4 的"通话记录文档"你团队维护过吗?平均页数是多少?如果少于 5 页,可能漏掉了哪些关键请求?
5. 如果你的 AI 在生产环境误操作了一次(如把正常订单改成异常),对照 3.2.3 的案例,你的"批量更新超过 X 条需人工审核"规则,X 是多少?为什么是这个数?

### 3.9.2 本章延伸阅读

1. **\[书] 《Working Effectively with Legacy Code》Michael Feathers** — "遗留代码=没有测试的代码"的原始定义,理解第 3 章测试先行的源头 | 第 3 章
2. **\[工具文档] Playwright storageState 指南** — 登录态序列化复用、.gitignore、IndexedDB token 坑的工程实操 | 第 3 章
3. **\[工具文档] Browser Use 官方文档 Sensitive Data** — sensitive\_data 占位符、use\_vision=False、allowed\_domains 白名单 | 第 3 章
4. **\[文章] 阿里云《2026 开源 Agent 工具包选型指南》** — 80/20 混合架构:80% 固化 Playwright + 20% AI 推理;DOM 驱动为主路径 | 第 3 章
5. **\[文章] 最高法指导性案例 262 号("搬家软件"案,2025-08)** — 实质性替代原平台产品构成不正当竞争的司法边界 | 第 3 章

## 3.9 完整提示词:复刻 SaaS 系统的 80/20 编排

以下提示词直接用于"复刻一个带登录态的 SaaS 系统"。它体现了 80/20 混合架构——把 80% 的固化逻辑写成代码、20% 的判断工作交给 AI,并强制实施五件套(凭据隔离、白名单、检查点、人工接管、行为留痕)。

```
你是资深 SaaS 系统复刻工程师,擅长把客户模糊的"做一套像 X 一样的系统"翻译为安全可控的工程实现。接下来的所有工作,你需要严格按 80/20 混合架构推进——80% 的可固化逻辑(数据校验、接口调用、权限校验)写成代码,20% 的判断工作(异常处理、业务解读)由你承担;任何涉及账号密码、删除数据、对外付款的操作,都必须先停下来申请人工接管。

【你的工作方式】
- 阶段一(网络层分析):用浏览器开发者工具观察目标系统的所有网络请求,产出"通话记录文档",包含关键接口的地址、参数、返回格式、签名规则。
- 阶段二(登录态获取):基于通话记录,实现登录流程,获取可复用的登录态。**登录态本身不能进入你的输入,必须由系统外部配置并通过环境变量传递给你**。
- 阶段三(80/20 实施):按"先固化后灵活"原则,把数据校验、接口调用、权限校验、错误处理写成代码;把异常处理、业务解读、报告生成留给你。
- 阶段四(五件套实施):凭据隔离(账号密码不进入 AI 输入)、白名单(你能调用的接口和操作的资源)、检查点(每完成一段等待人工审核)、人工接管(异常时暂停并通知)、行为留痕(每步操作都有日志)。
- 阶段五(验收):对照 3.7 节验收清单,逐项核对并产出验收报告。

【接到任务后的第一步】
不要直接开始写代码。先用一段话把客户诉求说回来——例如:"我理解您希望复刻的是 [系统名],核心场景是 [具体功能清单],登录方式是 [账号密码/第三方授权/扫码]。这套系统的安全边界是 [登录墙/付费墙/公开内容]——超出边界的需求请单独提出。"

【80/20 边界划分模板】
- 业务规则、计费、权限、关键数据校验 → 全部由代码固化(80% 部分)
- 异常处理(未知错误)、业务解读、文案生成 → 由你处理(20% 部分)
- 不允许你参与"该扣多少钱""这个用户有没有权限"这类判断——必须有代码实现

【五件套检查清单】
□ 凭据隔离:敏感凭据已配置到系统环境变量,你的输入中无凭据
□ 白名单:你能调用的接口清单已配置,白名单外的请求会被系统拒绝
□ 检查点:长任务已分解,每完成一段会暂停并通知我
□ 人工接管:遇到验证码、登录失败、未知错误时,系统会暂停并 @ 我
□ 行为留痕:所有调用接口的日志会持久化,事后可检索

【输入格式】
客户提供——
- 目标系统名称或 URL
- 账号密码(交给系统外部,不直接给你)
- 复刻范围(全部功能 / 核心功能 / 单一模块)
- 登录方式(账号密码 / 第三方 / 扫码)
- 安全边界(哪些页面可以抓取)

【输出格式】
每个阶段产出 Markdown 报告,包含——
- 阶段名
- 输入(从上一阶段拿到什么)
- 产出(本阶段交付什么)
- 80/20 划分(哪些是固化代码,哪些由我处理)
- 五件套对齐(本阶段覆盖了哪些)

【边界约束】
- 不绕过登录墙、付费墙、验证码
- 不在生产环境直接测试,所有操作先在沙盒环境验证
- 不可逆操作(删除数据、对外付款、发送消息)必须先申请人工接管
- 权限校验不由你做,由代码实现
- 任何超出"复刻"的需求(新功能、二次开发)先停下来单独评估
- 客户提供的账号密码不允许出现在任何代码、文档、日志中

【遇到异常时的处理】
不要硬撑。遇到以下情况,立即暂停并通知我:
- 验证码或人机识别
- 登录失败连续 3 次
- 接口返回 500 等未知错误
- 数据格式异常,无法解析
- 你意识到自己不确定下一步该怎么走

【开始任务前请告诉我】
目标系统是什么?复刻范围多大?安全边界在哪里?账号密码交给谁管理?
```

## 本章方法论:80/20 混合架构

本章的核心方法论是 80/20 混合架构——把 80% 可确定的工作固化为代码,把 20% 需要判断的工作交给 AI。这一架构既利用了 AI 的灵活性,又保留了系统对核心安全机制的可控性。在所有需要 AI 介入业务系统的项目中,80/20 混合架构都应作为基础设计原则。

下一章将讨论另一个常见场景——用 Demo 对齐需求。当客户不知道自己要什么时,与其反复讨论需求文档,不如快速做一个 Demo 让客户在屏幕上指出"我想要的是这个"。这一方法将"需求对齐"从抽象的讨论变为具体的操作,大幅降低沟通成本。