把大模型接入一个输入框，可以很快得到一个能回答问题的演示。但如果希望它真正完成工作，例如整理文档、填写表单、发布文章，难点会从“回答是否流畅”转向“操作是否正确、失败后能否恢复”。
这篇文章从工程设计角度，介绍一种容易落地的分工：让 AI 帮助理解和规划，让确定性的程序负责执行，让状态记录负责解释发生了什么。
一、把“生成内容”和“执行动作”分开
假设我们要做一个多平台文章发布工具。输入是标题、正文和图片，输出应该是目标平台上的文章，以及能够追踪的发布结果。
如果把所有事情都交给一个自由运行的模型，每一步都由模型临时决定，会遇到几个问题：相同输入的执行路径可能不同；网页变动时难以定位哪一步失效；网络超时后无法判断是否已经提交。
一种可行的结构是：
用户确认的内容
↓
经过校验的任务参数
↓
版本化的平台操作配置
↓
浏览器执行器
↓
结果核验与本地任务记录
AI 可以在开发阶段协助分析页面、提出选择器和生成配置，但这些产物仍然需要测试。运行阶段则可以只依赖浏览器自动化，不要求每个用户都配置模型服务。
这种设计并不排斥智能，而是把智能放在最需要理解和适应的地方。
二、页面配置需要描述什么
一个最小配置不应该只有“发布按钮的选择器”。它还应该说明：
- 从哪个页面开始，以及允许访问哪些域名；
- 标题和正文分别对应什么控件；
- 哪些字段是必填项，例如标签、摘要或封面；
- 哪一个动作会真正对外提交；
- 什么页面证据能够证明提交成功。
可以用简化的结构表达：
{
"platform": "example-blog",
"version": 1,
"steps": [
{ "action": "fill", "target": "title", "valueFrom": "title" },
{ "action": "fill", "target": "body", "valueFrom": "content" },
{ "action": "click", "target": "publishSettings" },
{ "action": "click", "target": "submit", "commit": true }
],
"success": { "evidence": "publishedArticleLink" }
}
这里的配置只是结构示意，不是任何真实平台可以直接运行的适配文件。真实页面可能使用富文本编辑器、弹窗或异步上传，必须根据实际控件验证。
三、点击完成不等于发布成功
自动化最容易犯的错误，是把“点击按钮没有报错”当成成功。
按钮点击之后，平台可能还在上传图片，也可能提示必填项缺失、要求登录，或者进入审核状态。因此，执行器应区分至少三类结果：
- 已确认成功：读取到成功页面或可识别的文章链接。
- 明确未提交：例如标题校验不通过，提交动作还未发生。
- 结果待核实：提交动作已经发生，但由于超时或页面变化，暂时无法确认结果。
第三种状态尤其重要。此时立即自动重试，可能产生重复文章。更稳妥的做法是先去文章管理页核对，再决定是否重试。
四、让任务中断后仍然能够继续
可靠的工作流需要保存进度，而不仅仅是打印日志。
可以在本地记录任务编号、文章编号、平台、配置版本、当前步骤、提交是否开始、最后更新时间和结果链接。进入关键动作前先写入状态，动作完成后再更新。
例如：
prepared → filling → ready_to_submit → submitting → verified
↘ needs_review
如果程序在 submitting 阶段意外退出，重启后应进入核对流程，而不是从头再次点击发布。
这种机制不能凭空实现跨网站事务，但可以显著减少“程序不知道自己做到哪里”的问题。
五、给自动化保留必要的人机协作
扫码、短信验证、验证码和账号安全提示，不适合通过绕过机制处理。执行器应该保留浏览器窗口，提示用户完成验证，并在确认页面恢复可操作后继续。
同样，平台要求选择内容声明或授权条款时，程序不能为了消除弹窗而任意勾选。可以预先收集明确的发布选项，再将它们作为任务参数执行。
人机协作不应该退化为让用户复制标题和正文。正常的数据录入和按钮操作由程序完成；确实依赖用户身份或判断的步骤才交回用户。
六、如何验证一个最小版本
建议从一个平台、一种编辑模式开始，按下面的顺序验收：
- 标题和正文能否完整写入，包括中文、换行和代码块；
- 登录失效时能否停止，并保留当前任务；
- 必填字段不满足时能否给出具体原因；
- 点击提交后能否读取真实结果；
- 超时之后是否避免重复提交；
- 应用重启后，能否恢复文章和任务状态。
本地模拟页面适合检查执行器的控制逻辑，但不能替代真实平台验收。平台改版后，即使自动化测试仍然通过，真实页面配置也可能已经失效。
结语
AI 应用的价值不只体现在生成了多少文字，也体现在能否把明确的意图转换成可靠的结果。
将内容、配置、执行和结果核验分开，可以让问题更容易定位，让平台变化更容易维护，也让用户更容易信任自动化的行为。对于一个小型工具而言，先让单条工作流完整、可追踪地跑通，通常比同时展示许多尚未接通的功能更有意义。
本文由 AI 辅助撰写，讨论的是通用工程设计思路；文中的配置示例不代表某个平台的现成接口或已验证实现。
