一句话总结：我用Kiro+Sonnet 4.5模型纯Vibe Coding，破解了AnyRouter的反爬，也就是acw_sc__v2技术。
一、缘起
从25年初DeepSeek爆火开始深度关注AI，大概年中的时候开始用Cursor做Vibe Coding，到现在（26年1月中）已经Vibe了不少东西，也有实际使用的项目。
前几天看到一个帖子：打渔教程-001：破解Anyrouter之神秘acw_sc__v2实现自动signin签到 - 开发调优 / 开发调优, Lv1 - LINUX DO
这个帖子需要论坛一级权限。说实话这位佬兄排版不太清晰，看的不太明白，但是我看出两个关键点：
第一自动签到的拦路虎是反爬机制（而这个机制连名字都有acw_sc__v2，也不是很复杂）；
第二就是解密这块可以交给AI来完成。
既然解密都可以用AI来完成，别的还有什么难的？于是周末花了半天时间试了一下能不能纯Vibe出来。
二、过程
周末Kiro又把Opus给下了，只有Sonnet 4.5顶上，但我觉得Sonnet除了个别前端极难的问题处理不好，以及爱到处乱写文档之外，代码能力其实并不差。
相信大家AI编程到现在也明白，Vibe效果好不好，基座模型第一，项目规范第二，那么这一个探索性的项目，规范怎么搞？顺带我其实对反爬技术根本不懂。
我的思路是，先开放式探索，摸清状况之后再建立起项目规范来。参考帖子里的提示词，我写了个更通用点的提示词：
分析https://anyrouter.top的登录流程。注意当前环境是Win11，请使用powershell和相关网络工具如curl。这个网站需要代理访问http://127.0.0.1:10809。
我给Coding Agent任务提示词是任务+环境+要求，Agent就不需要预设角色了。
Kiro成功的定位了问题，这是它写的研究报告核心内容：
### 1. 首次访问网站
使用 curl 和 Python requests 访问网站首页：
```bash
curl.exe -x http://127.0.0.1:10809 -I https://anyrouter.top
```
**发现**：
- 服务器：ESA (阿里云)
- 返回状态码：200
- 设置了两个初始 cookies：
- `acw_tc` - 阿里云 WAF token (有效期 1 小时)
- `cdn_sec_tc` - CDN 安全 token (有效期 1 小时)
- 响应头包含：`X-Tengine-Error: denied by http_custom`
### 2. 页面内容分析
**关键发现**：页面返回的是混淆的 JavaScript 代码，而非正常的 HTML 内容。
```javascript
var arg1=‘003F6616C200B652732494ABCF5961DC4E9C5B88’;
// … 大量混淆代码
document[L(0x121)]=‘acw_sc__v2=’+v+L(0x120)+new Date(Date[L(0x119)]()+0x36ee80)
```
**分析结论**：
- 这是阿里云盾的反爬虫保护机制
- JavaScript 代码会计算并生成 `acw_sc__v2` cookie
- 必须执行 JavaScript 才能获得有效的 cookie中间不怎么看得懂，但是结论很清晰，用JS去算这个acw_sc__v2嘛，那我们就是要逆向出这段JS的代码（主要是它是混淆的，人读不懂）。
思路清晰了那就好办，先让Kiro自己写个规则文件：
# 项目规则
## AI Agent 工作语言规范
- **思考和编码**: 使用英文进行内部思考和代码编写
- **用户反馈**: 所有与用户的交流使用中文
- **文档输出**: 所有文档（README.md、docs/、KANBAN.md 等）使用中文编写
- **代码注释**: 代码注释使用中文，便于理解和维护
## 系统环境
- 操作系统：Windows 11
- Shell：PowerShell/CMD
- 不要使用交互式命令，所有命令必须能够自动执行
## 目录结构规范
```
project/
├── src/ # 源代码目录（所有脚本）
│ ├── *.py # Python 脚本
│ └── *.ps1 # PowerShell 脚本（如需要）
├── assets/ # 资源文件目录
│ ├── *.html # 保存的网页
│ ├── *.json # 数据文件
│ └── cookies/ # Cookie 文件
├── docs/ # 文档目录
│ ├── 001-*.md # 探索文档（按序号命名）
│ ├── scripts.md # 脚本清单
│ └── *.md # 其他文档
├── venv/ # Python 虚拟环境
├── .kiro/ # Kiro 配置
│ └── steering/ # 规则文件
├── requirements.txt # Python 依赖
└── README.md # 项目说明
```
### 目录用途
- **src/**: 所有可执行脚本，包括 Python、PowerShell 等
- **assets/**: 从网站保存的内容（HTML、脚本、Cookie、图片等）
- **docs/**: 项目文档、探索记录、技术笔记
- **venv/**: Python 虚拟环境（不提交到版本控制）
## 开发规范
- **优先使用 Python 脚本**进行开发和分析任务
- 使用 Python venv 虚拟环境管理依赖
- 所有 Python 项目必须包含 requirements.txt
- 所有脚本必须放在 `src/` 目录
- 所有保存的网页、数据文件必须放在 `assets/` 目录
- 所有文档必须放在 `docs/` 目录
## 项目特性
### Vibe Coding 模式
**核心理念**：这是一个**纯 Vibe Coding 项目**，由 AI Agent 全自动执行
**执行原则**：
- **禁止要求用户手动操作**（如手动测试、手动调试、手动复制粘贴等）
- 所有测试、验证、调试必须通过自动化脚本完成
- 可以使用 Playwright/Selenium 等工具进行自动化测试和验证
- 所有操作必须可重复、可自动化
### 反爬虫解决方案原则
**技术路线**：
- **坚决采用逆向工程方案**：通过分析和重建 JavaScript 算法来绕过反爬虫保护
- **禁止使用浏览器方案作为最终解决方案**：不使用 Selenium/Playwright 作为生产环境的解决方案
- **浏览器工具仅用于辅助**：可以使用 Playwright 等进行自动化测试、验证、调试，但最终必须实现纯 Python 的逆向方案
- **最终目标**：实现完全独立的 Python 脚本，不依赖浏览器环境
**Playwright 的定位**：
- ✅ 用于自动化测试和验证
- ✅ 用于收集调试数据
- ✅ 用于对比验证 Python 实现的正确性
- ❌ 不作为生产环境的解决方案
- ❌ 不依赖浏览器来生成最终的 cookie
## 开发流程
1. **任务开始前**:
- 读取 `KANBAN.md` 了解当前项目状态和任务优先级
- 读取 `docs/` 目录下的相关文档
- 在看板中将任务移至 “ 进行中”
2. **任务执行中**:
- 按照项目规范进行开发
- 遇到阻塞问题时，在看板中标记为 “ 阻塞” 并说明原因
3. **任务完成后**:
- 更新相关文档（scripts.md、README.md、KANBAN.md 等）
- 在看板中将任务移至 “✅ 已完成”
- 记录完成时间和关键成果
## 脚本管理规范
### scripts.md 文档
在 `docs/scripts.md` 中记录所有脚本信息：
- **创建日期**: 脚本创建的日期时间
- **位置**: 脚本在项目中的路径
- **用途**: 脚本的主要功能和目的
- **状态**: 在用 / 已弃用 / 开发中 / 已完成
- **依赖**: 脚本需要的 Python 包或系统工具
- **运行方式**: 如何执行脚本
### 脚本状态标识
- ✅ **在用**: 当前正在使用的脚本
- ⚠️ **已弃用**: 不再使用但保留的脚本
- **开发中**: 正在开发的脚本
- ✔️ **已完成**: 开发完成但不常用的脚本
- **计划中**: 计划开发的脚本
### 新增脚本时
1. 将脚本文件放入 `src/` 目录
2. 在 `docs/scripts.md` 中添加脚本信息
3. 更新 `requirements.txt`（如有新依赖）
4. 在 README.md 中更新相关说明（如需要）
## 网络配置
- 需要通过代理访问外网
- 代理地址：http://127.0.0.1:10809
- 所有网络请求（curl、Python requests 等）都需要配置代理
## Python 环境设置
```powershell
# 创建虚拟环境
python -m venv venv
# 激活虚拟环境（Windows）
.\venv\Scripts\activate
# 安装依赖
pip install -r requirements.txt
```看起来很复杂，其实一点也不简单……我一般是用自然语言写给Agent，让它自己输出规则文件。
语言规范、系统环境、看板管理、目录管理、文档管理这些基本每个项目都是一样。有了文档管理规则Sonnet乱写文档的毛病也就治了。
这个项目独特的是网络代理、脚本管理（因为探索性项目需要写很多测试代码），以及目标和实施路径，因为我发现AI探索的时候给出的方案，试图走捷径用Playwright直接模拟，所以把技术路线强行写在规则文档里。
一旦看板建立起来之后，我们需要做的事情是下面这样一个循环（有没有发现这是一个PDCA循环？）：
- 用自然语言描述任务，让AI添加到看板（可以一次性写一堆）——Plan
- 让AI认领任务并执行——Do
- 人工复核结果，提出需要调整的点让AI立即修改，如果上下文不够了，要求AI把进展写到任务文档里面，然后新开一个会话，读取任务文档并继续——Check
- 任务结束，如果有值得纳入规则文件的决策、常见错误和解决方案等，让AI自己总结写入规则文件——Action
其中第二步一定要让AI有自己验证的手段，比如这里就是允许它用PlayWright去模拟请求，收集JS算出来的Cookie，用它自己算出来的Cookie和PlayWright算的做比较。
第四步在大的Vibe项目中非常重要，AI会越写越顺。
说实话这个任务是如此顺利根本都没有必要手工验证了。给大家看一下Kiro生成的看板：
# 项目看板 (Project Kanban)
> 本看板用于管理 AI Agent 执行的任务和项目进度
## 使用说明
- ** 待办 (TODO)**: 计划执行的任务
- ** 进行中 (IN PROGRESS)**: 正在执行的任务
- **✅ 已完成 (DONE)**: 已完成的任务
- ** 阻塞 (BLOCKED)**: 遇到问题暂停的任务
### 任务格式
```markdown
- [ ] **[任务编码]** 任务标题 - 简要描述 `优先级: 高/中/低` `标签`
- 详细说明或子任务
- 相关文件: `path/to/file`
```
**任务编码规则**：
- 格式：`[S阶段-T任务号]`
- 示例：`[S2-T1]` 表示阶段2的第1个任务
- 用途：方便快速引用和指定任务
-–
## 待办 (TODO)
### 阶段 5：自动登录和访问功能
- [ ] **[S5-T1]** 实现自动登录功能 `优先级: 高` `功能开发`
- 分析登录接口和参数
- 实现登录请求逻辑
- 处理登录响应和 session
- 支持登录状态保持
- 相关文件: `src/auto_login.py`
- [ ] **[S5-T2]** 实现访问首页功能 `优先级: 高` `功能开发`
- 使用登录后的 session 访问首页
- 验证访问权限
- 提取首页数据
- 相关文件: `src/access_homepage.py`
- [ ] **[S5-T3]** 集成测试和验证 `优先级: 高` `测试`
- 完整流程测试（登录 → 访问首页）
- 错误处理测试
- 批量验证测试
- 相关文件: `src/test_auto_login.py`
- [ ] **[S5-T4]** 更新文档 `优先级: 中` `文档`
- 更新 README.md
- 更新使用指南
- 更新脚本清单
- 添加使用示例
### 可选优化任务
- [ ] **[S4-T3]** 最终验证测试（可选）`优先级: 低` `测试`
- 集成测试
- 性能测试
- 压力测试
- 备注：当前已通过基础测试（3/3），此任务为可选优化
### 监控和维护
- [ ] **定期检查网站算法变更** `优先级: 中` `维护`
- 监控成功率
- 及时发现算法变化
- 更新实现代码
- [ ] **收集用户反馈** `优先级: 低` `改进`
- 收集使用问题
- 持续改进功能
- 优化用户体验
-–
## 进行中 (IN PROGRESS)
<!-- 当前没有进行中的任务 -->
-–
## 阻塞 (BLOCKED)
<!-- 遇到问题需要解决的任务 -->
-–
## ✅ 已完成 (DONE)
### 阶段 4：生产封装 `2026-01-17 完成` ✅
- [x] **[S4-T1]** 创建高级封装 `已完成` `2026-01-17 23:18`
- 脚本：`src/protected_request.py`, `src/test_protected_request.py`
- 功能：
- ✅ 自动处理 cookie 生成和刷新
- ✅ 集成错误处理和重试机制
- ✅ 支持会话管理和 cookie 持久化
- ✅ 提供简单易用的 API（get, post, put, delete）
- ✅ 支持上下文管理器
- ✅ 完整的日志记录
- 测试结果：3/3 通过（100%）
- 成果：生产环境可用的高级封装库
- [x] **[S4-T2]** 编写使用文档 `已完成` `2026-01-17 23:20`
- 更新 README.md，添加完整使用指南
- 提供多个使用示例和 API 文档
- 更新 scripts.md，记录新脚本信息
- 编写最佳实践建议
- 成果：完整的文档和使用指南
**成果**：
- ✅ 生产就绪的高级封装库
- ✅ 简单易用的 API 接口
- ✅ 完整的文档和示例
- ✅ 100% 测试通过
- ✅ 符合逆向工程原则（纯 Python，不依赖浏览器）
### 阶段 2：JS 代码深度分析 `2026-01-17 完成`
- [x] **[S2-T1]** 提取多个 JS 样本 `已完成`
- 分析了 2 个挑战页面样本
- 提取了完整的 JS 代码和 arg1 参数
- 脚本：`src/collect_challenge_samples.py`, `src/analyze_challenge_samples.py`
- [x] **[S2-T2]** 分析代码结构和模式 `已完成`
- 识别了所有混淆模式（变量名、字符串、控制流、反调试）
- 定位了所有关键函数（字符串数组、解码器、核心算法）
- 文档：`docs/004-代码结构分析.md`
- [x] **[S2-T3]** 解析字符串混淆机制 `已完成`
- 理解了 `L(0x…)` 函数（Base64 + URL 解码）
- 提取了完整的字符串数组（42 个元素）
- 提取了 p 值和所有关键字符串
- 脚本：`src/final_extract_p.py`
- [x] **[S2-T5]** 识别核心算法 `已完成`
- XOR 运算实现（已理解）
- 无哈希算法（仅 XOR）
- 输出格式（40 字符十六进制）
- 脚本：`src/deep_analyze_algorithm.py`
- [x] **[S2-T6]** 编写算法分析文档 `已完成`
- 创建了 `docs/003-算法分析.md`
- 创建了 `docs/004-代码结构分析.md`
- 记录了完整的算法流程和伪代码
- [x] **[S2-T4]** 分析 arg1 生成规律 `已完成` `2026-01-17`
- 脚本：`src/analyze_arg1_from_samples.py`
- 分析了 2 个 arg1 样本
- 关键发现：
- ✅ arg1 是 40 字符的十六进制字符串（大写）
- ✅ arg1 由服务器动态生成，每次都不同
- ✅ arg1 具有高度随机性（95%+）
- ✅ 位置变化率 85%（大部分位置不同）
- ❌ 不包含明显的时间戳编码
- ❌ 不能跨会话复用
- 复用性结论：
- arg1 必须每次访问时实时获取
- 需要先访问挑战页面提取 arg1
- 然后使用 cookie_generator.py 生成对应的 cookie
- 报告：`assets/analysis/arg1_pattern_analysis.json`
**成果**：
- 完全理解了算法逻辑（重排 + XOR）
- 完全理解了 arg1 的生成规律和复用性
- 提取了所有关键参数：
- m 数组：`[15, 35, 29, 24, 33, 16, 1, 38, …]`
- p 值：`3000176000856006061501533003690027800375`
- arg1 样本：`AEA7E15B184600512F233A9B8C7E69F6409E9C76`
- arg1 特性：服务器动态生成，不可复用
- 创建了 6 个分析工具
- 生成了 2 份详细文档
- 明确了完整的实现流程
### 阶段 3：Python 原型实现 `2026-01-17 完成`
- [x] **[S3-T1]** 实现字符串解码器 `已完成`
- 通过 `src/final_extract_p.py` 在浏览器中解码
- 成功提取了 p 值和所有关键参数
- Python 实现只需使用固定的参数值
- [x] **[S3-T2]** 实现 Cookie 生成器 `已完成` `2026-01-17`
- 脚本：`src/cookie_generator.py`
- 测试脚本：`src/test_cookie_generator.py`
- 功能：核心算法实现（重排 + XOR）
- 成果：
- ✅ 实现 arg1 重排算法
- ✅ 实现 XOR 运算逻辑
- ✅ 支持多种输入方式（命令行、文件、测试模式）
- ✅ 完整的单元测试（4/4 通过）
- ✅ 无外部依赖，纯 Python 实现
- 测试结果：
```
测试 1: AEA7E15B184600512F233A9B8C7E69F6409E9C76 → 696b56cc81aa07af86017e68336f8057092e0a1b
测试 2: 003F6616E0B8C9A7F5D24E3182A7B5C4D9E6F701 → 9eb1c0670e597ae58a7e0475a4416c1fd1b79cf3
单元测试: arg1 重排 ✅ | XOR 运算 ✅ | 完整生成 ✅ | 边界情况 ✅
```
- [x] **[S3-T3]** 迭代验证和优化 `已完成` `2026-01-17`
- ✅ 使用纯 Python 方案完成完整验证
- ✅ 目标网站：https://anyrouter.top（正确的网站）
- ✅ 验证流程：触发 → 提取 → 生成 → 验证
- 成果：
- ✅ 单次验证：3/3 成功（100%）
- ✅ 批量验证：10/10 成功（100%）
- ✅ 算法正确性已完全验证
- ✅ 纯 Python 逆向工程方案完全可行
- ✅ 达到生产环境标准
- 验证脚本：
- `src/python_verify.py` - 单次完整验证 ✅
- `src/batch_verify_python.py` - 批量验证（10次）✅
- `src/test_python_trigger.py` - 触发机制测试 ✅
- `src/test_cookie_generator.py` - 单元测试（4/4）✅
- 文档：`docs/006-S3T3验证报告.md`（完整验证报告）
**成果**：
- 成功实现核心 Cookie 生成算法
- 完全理解并重建了阿里云盾的算法逻辑
- 代码简洁，无外部依赖，符合逆向工程原则
- 提供完整的单元测试保证代码质量
- 算法正确性已通过充分验证（100% 通过率）
- 创建了完整的验证工具链
- 生成了详细的验证报告
### 阶段 1：自动化工具链搭建 `2026-01-17 完成`
- [x] **[S1-T1]** 安装 Playwright 依赖 `已完成`
- 已安装 playwright==1.57.0 到 venv
- 浏览器驱动下载中（Chromium）
- [x] **[S1-T2]** 创建 JS 代码提取器 `已完成`
- 脚本：`src/playwright_extract.py`
- 功能：自动访问网站，提取 JS 代码和 arg1 参数
- [x] **[S1-T3]** 创建算法验证器 `已完成`
- 脚本：`src/playwright_verify.py`
- 功能：对比浏览器生成的 cookie 与 Python 实现的结果
- [x] **[S1-T4]** 创建调试数据收集器 `已完成`
- 脚本：`src/playwright_debug.py`
- 功能：注入监控代码，收集 JS 执行过程数据
- [x] **[S1-T5]** 创建回归测试器 `已完成`
- 脚本：`src/playwright_test.py`
- 功能：批量测试 Python 实现的成功率
**成果**：
- 完整的 Playwright 自动化工具链（4个脚本）
- 所有工具支持代理配置
- 所有工具支持自动保存数据到 assets/
- 注意：首次运行需等待 Chromium 下载完成
-–
## 备注
### 项目状态说明
**当前状态**: ✅ 项目已完成
**完成阶段**：
- ✅ 阶段 1: 自动化工具链搭建
- ✅ 阶段 2: JS 代码深度分析
- ✅ 阶段 3: Python 原型实现
- ✅ 阶段 4: 生产封装
**核心成果**：
- ✅ Cookie 生成器（`cookie_generator.py`）
- ✅ 高级封装库（`protected_request.py`）
- ✅ 完整的测试套件（100% 通过）
- ✅ 完整的文档（8 份）
**测试结果**：
- 单元测试：4/4 通过（100%）
- 单次验证：3/3 成功（100%）
- 批量验证：10/10 成功（100%）
- 集成测试：3/3 通过（100%）
**生产就绪**：
- ✅ 纯 Python 实现（不依赖浏览器）
- ✅ 简单易用的 API
- ✅ 完整的错误处理
- ✅ Cookie 持久化支持
- ✅ 完整的文档和示例
### 项目阶段说明
- **阶段 1**: 自动化工具链搭建 ✅
- **阶段 2**: JS 代码深度分析 ✅
- **阶段 3**: Python 原型实现 ✅
- **阶段 4**: 生产封装 ✅
**注**: 原阶段 4（优化和容错）已移除，因为：
- 验证已达到 100% 成功率
- 算法稳定可靠，无需额外优化
- 可以直接进入生产封装阶段
### 使用说明
- 每次任务执行前，先查看看板了解当前状态
- 任务完成后，及时更新看板状态
- 遇到阻塞问题时，记录在 BLOCKED 区域并说明原因看板的门道是它最好是自举的，就是看板自己包含如何维护看板的说明，这样你的规则文件就可以只写一句要求AI做任务前去访问看板就行（当然也可以规则里面写看板维护规则）。
这个看板太复杂了点，如果是大的项目我会让AI写得更简洁一些，然后在任务文档中描述任务细节。
从看板可以看到，基本上阶段1把JS混淆代码抽取出来之后，AI就已经看明白逻辑了，后面用Python实现不过是翻译了一下。这也就是说本质上这个算法的代码混淆很大程度只能蒙蔽人的眼睛，对于AI来说是透明的。
我猜测真正的反爬更多要结合用户行为、IP等进行指纹判断，还有就是验证码了。
三、复盘
最后给大家看一下主要的项目结构，有个直观印象：
就是这么简简单单的。
Vibe Coding说是面向文档编程一点都不为过，人类软件工程的套路用在AI一样很有效。现阶段Agent还是需要人类来建立范式，帮助AI把体系中的熵清理出去，最终形成一个正向循环。
本文首发于Linux Do，挂了一级权限，但还是被管理员和谐掉了。看来还是有点价值的，尽管acw_sc__v2并不是什么高级技术，且看且珍惜。另外AnyRouter大善人，有账号的朋友请善待。
继续追问
由知乎直答提供