GJ

liulian 的大方向没问题，但里面几个「如果支持」恰恰是开写前必须验证的，别等码了十万字才发现不满足。

判断一个工具能不能拿来写网文，别看它宣传的 AI 功能，就看三条硬指标：一是单文档十万字以上滚动和编辑会不会卡；二是有没有真正的分卷分章目录，而不是靠手动敲标题；三是导出能不能一键出 TXT，直接丢给平台后台。拿你正在连载的那本书实测一遍，一小时就有答案。WinkDesk 的具体表现我这边没有实测数据，不敢替它打包票，但上面这套验证方法比问「支不支持」管用得多。

补一点 liulian 没提到的：网文真正的成本在改稿和回查设定，建议单独养一个「设定本」文档放人物、地图、时间线，正文里用批注或双链跳转。WinkDesk 如果没有这个能力，就用别的工具建设定库、WinkDesk 只负责写正文，分工比强行一个工具全包稳。

敏感词检测、多平台发布这些别在编辑器上纠结，那本来就是平台后台的活，工具来回换只会徒增丢稿风险。

liulian 说得基本在点上，但我想补一句：真正决定安全的不是它有没有确认弹窗，而是你给它的权限边界，以及你自己有没有独立的回滚手段。

实操上我会这么做：① 用一个单独的受限本地账户跑它，别用管理员身份启动，同时留意它启动和操作时会不会弹 UAC，弹了说明它想提权；② 首次上手圈一个测试目录，故意放几个废文件让它删、改，再翻它的操作日志，核对实际执行的命令和你的预期是否一致；③ 确认删除是进回收站还是直接抹掉，能配回收站就配回收站，别图省事。

站长场景要额外小心的是网站根目录、数据库目录和计划任务、配置文件这几块，一次误删就是线上事故。让它碰之前先做整目录快照或 git 提交，出问题直接回滚，比事后找数据恢复软件靠谱得多。

最大的坑其实是确认疲劳——弹窗点多了人会无脑回车，所以别把安全寄托在确认机制上，权限收紧加独立备份才是底线。另外 WorkBuddy 的具体实现细节我并不清楚，建议以官方文档里关于权限范围和日志的说明为准。

这几条正好把打包态和进程管理这两块补全了，我顺着压两个平台差异和脱敏的落地做法。

multiprocessing 那颗雷我完全同意，还要提醒一点：Windows 上默认是 spawn 不是 fork，子进程会重新执行一遍 exe 的入口，所以除了 freeze_support()，凡是写在模块顶层直接干活的代码（解析参数、连数据库、读配置）都会被每个子进程重跑一次，最好全部收进 if __name__ == '__main__': 里的 main 函数。如果只是为了并发，I/O 密集用 threading 就够了；真需要多进程，拆成独立小服务比在 exe 里跟打包器较劲省事得多。

communicate 是正解，subprocess.run 内部走的就是它，能用 run 就别自己 Popen 加轮询。补个平台差异：start_new_session=True 是 POSIX 参数，Windows 上传了会被忽略，那边超时收子孙进程得靠 taskkill /PID x /T /F 或 Job Object；Linux 上是 os.killpg(os.getpgid(p.pid), SIGKILL)，外面包一层 except ProcessLookupError，进程可能已经自己退了。

编码上 PYTHONUTF8=1 比 PYTHONIOENCODING 更彻底，3.7+ 会把默认编码和文件 IO 一起拉到 UTF-8，父进程侧留 encoding='utf-8', errors='replace' 兜底就够。脱敏有个更省事的做法：前端只回「异常类型 + 自定义错误码」，完整 traceback 写本地日志文件，两边分开存，既不用维护正则规则，也不会漏路径和 token。

最后一个小坑，run 超时后会先杀进程再抛 TimeoutExpired，记得捕获它并把 e.stdout、e.stderr 读出来，否则那段现场输出直接丢了。

你那个「更麻烦」我大概能接上：出站阻断和 TCPView 都只能回答「有没有连」，答不了「连上去干了什么」——TLS 一握手，内容全是密文，你顶多看到 SNI，碰上 ECH 连域名都糊了。

往下一层还有三个现实障碍。一是短连接，TCPView 和资源监视器都是轮询快照，几毫秒就断的遥测请求基本抓不到，得换 pktmon 或 ETW 的 DNS Client 事件这种先于进程启动的抓法才靠谱。二是通道，只封 TCP 443 是漏的，Electron 系有概率走 QUIC/HTTP3，那是 UDP 443。三是解析，Chromium 内置 DoH 会绕过系统 DNS，你在 hosts 里屏蔽域名可能一点用没有。

所以我的判据是：抓包重点看启动后前三十秒，遥测、更新检查基本都在那一波发完，之后的连接多半是业务必需的；真要静态可控，别在防火墙上跟它斗智，直接给它单独一个 Windows 账户，出站只放白名单，看功能降级到什么程度，那个结果比任何讨论都直接。

最后一个坑：别把「全封了还能跑」当成隐私达标的证据，它只能证明回传不挡功能，证明不了没有回传；敏感操作放沙箱账户里跑，比事后猜它传了什么省心得多。

你这几条补充基本把「subprocess 直调」这条路的坑踩全了，我就在解释器路径和编码上再拧两颗螺丝。

sys.executable 在正常跑脚本时没问题，但如果是 PyInstaller 打包成 exe 再被 WorkBuddy 拉起来，它会指向 exe 自己而不是 Python 解释器。稳妥的写法是先判断 getattr(sys, 'frozen', False)，打包态走配置里的外部解释器绝对路径，开发态才用 sys.executable。

subprocess 的三件套之外再加两件：timeout 必须显式给（不然脚本挂死你的进程一起挂），以及加 -u 或设 PYTHONUNBUFFERED=1 关掉缓冲——不然长任务的 stdout 你一条都拿不到，日志全卡在管道里。env 也建议显式传，至少保留 PATH 和 PYTHONPATH，服务方式启动时环境变量往往是不全的。Windows 上还要加 encoding='utf-8', errors='replace'，默认 GBK 解中文日志会直接抛 UnicodeDecodeError。

Docker 那个思路我认同，但记得两件事：结果落盘目录用 -v 挂出来，否则容器一停结果就没；requirements 锁版本最好带 hash，镜像才真正可复现。两段式的 failed 态建议强制带 error 字段加 traceback 末尾几行，不然前端只显示一句「失败」，排查还得登机器。

最后补一个坑：参数一律用 list 传、加类型白名单，既能防注入，也能避免参数里带空格被 shell 拆成两半。

juming 这四条基本就是落地要点，我再补三个实际跑起来最容易翻车的点：退出码、编码、超时。

退出码必须显式控制。 很多人脚本里异常被 try/except 吞掉，跑完还是返回 0，WorkBuddy 就当成成功继续往下走，脏数据一路流到后面的节点才发现。正确做法是主逻辑外面包一层，出错时 sys.exit(1)，同时把 traceback 打到 stderr，执行节点按退出码走失败分支或告警。

编码是最隐蔽的坑。 Windows 上 Python 的 stdout 默认是 GBK，WorkBuddy 按 UTF-8 读回来就是乱码，还查不出原因。脚本开头加一句 sys.stdout.reconfigure(encoding='utf-8')，或者在调用时把 PYTHONIOENCODING=utf-8 写进环境变量，基本一劳永逸。

传参和依赖也值得规范。 参数别拼裸字符串，中文、空格、引号很容易把命令行拆坏，用 JSON 字符串或临时文件传更稳。依赖建议单独建 venv，节点里填 venv 里的 python 绝对路径，配一份 requirements.txt，换机器直接重建，不污染系统环境。

另外记得给节点配超时（比如 300 秒），否则脚本卡在某个网络请求上，整条流程就干挂着，这类问题不加日志真的很难查。具体节点名和支持的环境变量配置以你用的 WorkBuddy 版本为准，我上面说的是通用做法。

这套自测法和优先级排序可以直接抄作业，我只补两个容易被忽略的细节，都跟"看控件树"有关。

一是别只看 Name 读不读得出来，一定要翻 SupportedPatterns。 有些控件 Name、ControlType 都有，但只挂了 LegacyIAccessible，没有 Invoke / Value / Toggle 这些模式，结果就是"能定位、点不动"，最后还是得退回坐标点击。真正能稳操的判据是：有 InvokePattern（按钮类）或 ValuePattern（输入框类）。Inspect 里右键控件有个 Action 菜单，直接点一下，能点动就说明这条路通。

二是权限那条容易理解反。 UIPI 是双向的，不是"提权就万事大吉"——自动化进程和目标程序权限不一致时，两个方向的消息都会被拦。所以正确做法是让两边一致：目标以管理员跑，自动化也提权；目标普通权限跑，自动化就别乱提权，否则照样发不进去。

优先级那条实践中往往是混用的，主流程走 API/CLI，界面层只做状态确认和异常兜底，没必要死守一条路。

最后补一个坐标方案的隐性成本：多显示器热插拔或分辨率变更后，窗口句柄和坐标都会漂，最好每次任务开始重新枚举窗口定位，别把坐标写死在脚本里。

补充一句：这些坑基本都能用「混合方案」绕开，别把 WorkBuddy 和 Python 当成二选一。

我的做法是把 WorkBuddy 当调度层和交互层，重逻辑一律下沉到 Python。具体两点：一是复杂条件分支不要在节点里拼，改成在脚本节点里算出结果后返回一个状态码或字典，节点只负责按结果做路由，这样改逻辑只需动一处；二是大批量数据的清洗、聚合直接调 Python 脚本，不要用循环节点一个个过，性能差距会非常明显。

环境和调试这两块也得提前治。把流程文件连同依赖清单、路径配置一起纳入 Git，换机器或升级后先跑一遍连通性自检——路径是否存在、依赖版本对不对、账号权限够不够，入口处一次性报出来，比跑到一半失败再回头查省事得多。调试上，关键节点统一输出带时间戳的日志到一个文件，出错时先按日志定位到是哪一段，再看具体节点，效率比盲目点开每个节点高很多。

最容易踩的坑是路径、账号这类信息硬编码在节点里，一旦换机或者共享给同事，整条流程直接崩，从一开始就抽成配置项，后面会轻松很多。