公众号流水线在 Windows 上的一次端到端打通

流水线本身分两段：前半段负责账号工作区、选题、结构与阶段台账，后半段负责写作契约、体检、排版与草稿。前半段一开始就能跑，后半段连 --help 都进不去。

原因出在第二行代码：脚本第 12 行 import fcntl。这是一个只在类 Unix 系统存在的模块，用来做文件锁。它出现在一个名为 finish 的步骤里，作用是在创建草稿时防止两个进程同时写入。

一个文件锁，挡住了一整段流程。

第一处，命令名。技能文档里写的是 python3，而在这台机器上 python3 指向应用商店的占位程序，真正的解释器叫 python。文档与参考文件里一共 16 处，全部改掉。

第二处，引用路径。技能文档指向仓库内的 docs/setup.md，但技能被复制到工作区技能目录后，这个相对路径已经指错了地方。改成指向仓库真实位置。

第三处，就是那个文件锁。改成条件导入：系统有 fcntl 就用，没有就跳过。锁的语义因此降级——单人单机使用没有影响，但并发保护确实没了。这是取舍，不是缺陷修复。

第四处最隐蔽，也最值得记下来。脚本会把结果以 JSON 形式打印出来，其中包含一个警告符号。在中文 Windows 的控制台里，标准输出的默认编码是 GBK，这个符号编不出来，程序直接抛异常退出。于是出现了一个很误导人的现象：活儿已经干完了，状态已经写进台账，进程却以失败退出。

解决办法不动一行代码：给运行环境加一个变量，把标准输出编码固定为 UTF-8。

现在这条链可以用一条命令驱动，环境变量、路径与密钥注入都封装在里面。密钥存在本地文件里，不进命令行、不进日志，也不进版本库——.gitignore 里已经加了一行。

还有一件事值得说明：运行时的文件夹锁降级以后，同一台机器上并行发起两次创建草稿的操作不再互斥。对单人或单任务场景，这个风险可以接受；如果后续要上多任务并发，这里需要换用 Windows 的文件锁实现，而不是继续跳过。

跨平台的坑往往不在业务逻辑，而在三行环境代码里。找到它们的方式不是读文档，是把流程真跑一遍，直到它交出成果。

这是一篇链路验证稿。