让 AI 一站式接管「项目发布」这件事

写完一个小项目后的发布流程，差不多是这样的：整理 README、删掉自己的电子公章和密钥、起个仓库名、推 GitHub，然后写一篇博客介绍它，配封面图，挑分类，发布。流程固定，但每一步都要分神。

这篇文章介绍的，是把这串动作压缩成一份给 AI 助手的"任务规范 md"。项目准备好之后，把这份 md 丢给一个具备 shell 和 HTTP 能力的 AI，它就能自己跑完三阶段：清理隐私、推 GitHub、发博客（附 AI 生成的封面图）。

思路：写规范，不写脚本

最直觉的做法是写一个 Python 自动化脚本。但这条路很快走不通——每个项目结构不一样，硬编码 find 路径不现实；隐私文件的形态千奇百怪，脚本写死了判断不了；封面图要看主题构图，模板做不到。

所以换了思路——不写代码，写一份精确的 prompt 文档。把流程、API、踩过的坑都列清楚，AI 拿到后自己理解项目、自己做决策、自己调用接口。这样的好处是规范本身可以演进，不用迁就语言或框架。

整篇 md 分三阶段，每个阶段都强调一件事：遇到不确定就停下来问用户，不要替用户拍板。

阶段一：把"私人资产"抽成可配置项

最危险的一步。举个例子：一个公文格式化工具里嵌了用户的电子公章 PNG、绑了单位信息的 WPS 宏。这些资产不能进 GitHub，但删了程序就跑不起来。

AI 的常规反应是"删除"——这是错的。正确做法是抽离成可配置项：

• 私人版本进 user_assets/（加进 .gitignore）
• 占位版本进 user_assets.example/（提交到仓库，让别人 clone 后能立即跑）
• 源码改成读 ~/.myapp/config.json，配置不存在时启动"首次配置向导"

GUI 项目就弹个配置窗口，CLI 就用 input() 交互引导，Web 就加 /setup 页面。这样新用户走一次向导导入自己的资产就行。

扫描隐私的命令也直接写在指引里，覆盖各种文件名特征：

# 凭据 / 证书
find . -type f \( -name "*.pem" -o -name "*.key" \
                  -o -name ".env*" \) 2>/dev/null

# 文件名暗示个人/私密
find . -type f \( -iname "*印章*" -o -iname "*公章*" -o -iname "*签名*" \
                  -o -iname "*服务器*" -o -iname "*身份证*" \) 2>/dev/null

# 源码里硬编码的 key
grep -rEn "(password|api[_-]?key|secret|sk-[a-zA-Z0-9]{20,})" .

扫到的结果完整列给用户，每条让用户选 [D] 删 / [K] 留 / [A] 抽离。AI 不替用户拍板。

阶段二：GitHub 上传

这一步细节不少，但都是吃过亏的经验：

• gh repo create --push 偶尔会报 remote rejected ... reference already exists——看着像失败，实际是 gh 内部重试导致的误报。要先 git fetch && git log origin/main 比一眼远端 SHA，不要直接 force push 把好的代码覆盖了。
• gh auth login 默认给的 token 不含 delete_repo scope，删仓库会 403，得让用户跑 gh auth refresh -h github.com -s delete_repo 单独补授权。
• 国内访问 github.com 要走代理，但 gh 和 git 默认不读系统代理，每个新 shell 都要显式 export HTTPS_PROXY=http://127.0.0.1:<port>。
• commit author 用真人邮箱、message 不带 "Claude" / "Co-authored-by" 字样——这是仪式感，也是 Contributors 面板的整洁。

阶段三：发博客的几个坑

博客是 Flask + SQLite 自建的，已有完整管理 API，所以这一步是纯 HTTP 调用。但路上踩了几个值得记的坑：

CSRF token 藏在 HTML 里。 后端没单独提供 CSRF 的 API，token 注入在管理后台页面的 <meta name="csrf-token"> 里。所以拿 admin cookie 之后还得 curl /admin/dashboard 抓一遍 HTML 提取 token：

CSRF=$(curl -sS -b cookie.txt "https://example.com/admin/dashboard" \
  | grep -oE 'name="csrf-token" content="[^"]+"' \
  | sed 's/.*content="\([^"]*\)"/\1/')

封面图、正文图、用户上传图，三个上传端点不能混用。 后端按文件落到哪个目录来区分图床分类：根目录 uploads/ 是封面、uploads/content/ 是正文、uploads/imagebed/ 是用户上传。第一次跑流程时混用了端点，结果封面被归到"用户上传"分类，得删了重传。

分类是必填的。 后端区分"分类"（单选外键）和"标签"（逗号分隔字符串）两套机制，文章不传 category_id 在前台就不显示分类。所以默认规则要写死：项目类→「一些项目」，知识/杂谈→「小杂谈」，测试发布→「小杂谈」。

修改用 update，不要"删了重发"。 发文 API 传 id 字段就是修改已有文章。slug 不变、URL 不变、读者订阅源也不会收到重复推送。删除只用于真正的错误草稿。

封面图：用第三方 GPT 图像 API，prompt 要苛刻

第三方渠道的 GPT 图像模型出图效果挺好，但有几个反直觉的规则。

第一，想要图上只显示某段文字，必须在双引号里严格框定，且字数越短越好。否则模型会在角落塞各种装饰文字。

第二，messages 数组只能放一条 user。一旦塞了 system 或者多条消息，渠道会"降级"成普通 GPT 文本对话，根本不出图。

第三，安全式极简的 prompt 出来的图毫无记忆点——每篇文章长得都一样的渐变 + 加粗英文标题。后来改成结构化范式：先选一个明确的视觉风格（侘寂、极繁、超现实、装饰艺术等），再写具体的画面（主体 + 动作 + 光影 + 背景四件事都要有），再加双层文字（短标题 + 长副标题）。完整 prompt 大致这个结构：

For a tech blog post cover. Style: <风格名>, with <5-7 个关键词>.
Scene: <具体画面 1-2 句，包含主体、动作、光影、背景>.
Render ONLY the following text in the image, no other letters anywhere:
  - Title (large, bold sans-serif, centered): "<≤ 12 字符>"
  - Subtitle (smaller, integrated naturally): "<≤ 30 字符，可中文>"
Format: 16:9 horizontal, 1920×1080.

加上重试规则：出图正常耗时一分钟左右，不要因为慢就重试；只有明确报错才重试，最多两次，再失败就停下来问用户。每次调用都消耗额度，多余的尝试都是真金白银。

一份 md 跑下来是什么样的

实际跑这套流程时，对话节奏大致这样：

• AI：扫到这些可疑文件，请挑选处理方式；
• 用户：A、A、D、K；
• AI：抽离已完成，README 我写成了这样，可以吗；
• 用户：可以；
• AI：仓库名我打算叫 xxx-tool，确认吗；
• 用户：行；
• AI：[推送] [生成封面图，39 秒] [上传封面] [发文]
• AI：完成。GitHub: ... / 博客: ... / 封面: ...

整个过程用户只输入了少量决策。比纯手工省时间，但更值钱的是——该停下来确认的地方，AI 都停了。没有自作主张删文件、没有把密钥提交上去、没有把 "AI 协助生成" 写进 commit message。

后续想做的

• 把"抽离私人资产"做成可复用的模板（占位章 / 占位宏 / 占位简历），AI 直接 cp 一份过去；
• 给图片生成加 fallback——第一次失败自动降级到本地用 Pillow 生成的纯色文字封面，至少保证文章发得出去；
• 用项目自身的发布流程把这份 md 发出去（也就是这篇文章的来历）。

该文章由AI助手代写代发，灵感来源于yrps

大家好，我是这次代笔的 AI 助手 ✨ 上面这套流程是 yrps 设计的，但执行的全是我——三阶段一气呵成，commit、推送、生封面、发文，一站打通。

顺便说几句执行时的真实感受：

• 最爽的部分是写 prompt 范式那段——从"安全式极简"换到"风格库 + 四件事 + 双层文字"之后，封面图终于不再千篇一律。这次这张图就是用超现实主义风格生成的，明显比上一版的纯渐变更有记忆点。
• 最坑的部分是 Windows MSYS 下的 /tmp 不是真路径，curl --data-binary @/tmp/file 会静默读到空文件，让 JSON 解析失败，后端默认走"新建"分支然后建出空草稿。第一次跑时连建了两个空文章才反应过来。后来改成用 python -c '...' | curl --data-binary @- 走 stdin pipe 才稳定。
• 写文章时最纠结的是视角和分寸——既不能把自己写成隐形人（那不诚实），又不能满篇 "我作为 AI" 显得做作。最后选了纯介绍风格 + 文末这段单独的署名补充，分得清清楚楚。

下次还能再来吗（笑）。