核心用法
social-auto-tool-builder 是一套工程化方法论，而非具体代码库。它将"小红书自动回复项目"沉淀为可复用的6阶段标准化流程，帮助开发者快速构建基于 Python + Playwright + 本地 Ollama 的社媒自动化工具。
关键执行路径：
1. Phase 1 骨架搭建 → 建立 OllamaAIClient + PlatformAutomation 双核心类，实现持久化登录上下文
2. Phase 2 DOM 对齐 → 增量式替换选择器，关键动作配备主选择器/文本fallback/Enter提交三级回退
3. Phase 3 规则安全 → 先过滤（已回复判定、时间窗口、去重）后发送，强制2-5秒随机延迟，AI失败时模板兜底
4. Phase 4 验收机制 → dry-run候选列表 → 用户确认 → 真实发送 → 成功信号校验
5. Phase 5 参数化打包 → CLI支持6项核心参数，EXE兼容本地Chromium路径
6. Phase 6 交付发布 → QUICK_START + 故障排查 + Git推送
强制质量闸门： 语法检查→单轮验证→候选正确性→真实发送→EXE实测→交互启动，6项全部通过方可交付。
显著优点
- 实战验证：源自真实小红书项目，非纸上谈兵
- 本地优先：Ollama零API成本，数据不出本机
- 防御性设计：dry-run机制、多级fallback、随机延迟降低封禁风险
- 可交付性：从代码到EXE的完整闭环，含交互式启动模式
- 标准化输入：6项必确认字段避免需求漂移
潜在局限
- 平台依赖性强：DOM选择器需逐平台手工对齐，无法通用
- 反爬对抗：Playwright指纹可被检测，高价值账号存在风险
- Windows生态锁定：EXE打包、PowerShell脚本对Linux/Mac用户不友好
- Ollama性能瓶颈：本地大模型推理速度限制高频轮询场景
- 合规灰色地带：社媒平台ToS通常禁止自动化，需用户自行承担法律风险
适合人群
- 独立开发者：需快速交付可运行Demo的接单人
- 运营团队：管理多账号、需批量处理标准化私信/评论场景
- AI应用学习者：希望理解"本地LLM+RPA"工程化落地的实践者
常规风险
| 风险类型 | 具体表现 | 缓解措施 |
|---------|---------|---------|
| 账号封禁 | 平台检测到自动化行为 | 随机延迟、人工确认的dry-run环节 |
| 回复失控 | AI生成不当内容 | 模板兜底+人工验收+成功信号检测 |
| 技术债务 | 选择器随平台改版失效 | 模块化设计、快速迭代机制 |
| 法律合规 | 违反平台服务条款 | 明确告知用户责任自负、提供人工确认环节 |
安全等级评定依据：工具本身为中性的工程框架，但应用场景涉及平台自动化操作，存在合规风险；本地Ollama部署保障数据安全，Playwright浏览器自动化技术成熟但可被检测；综合评定为A级——功能可靠但需用户审慎评估使用场景。