这几天我怎么用 Cursor 写文章、做脚本，又把它开源了
这几天我在用 Cursor 持续整理 www.zicode.com。表面上看，事情并不复杂：写几篇文章，补几个脚本，把站点从 Wagtail 往 Astro 上继续收拾干净，再顺手把“同步微信公众号草稿”的脚本做成一个可以公开的仓库。
但真正做起来，我越来越明显地感觉到：Cursor 最有意思的地方，并不只是“帮你补代码”，而是它把整个工作过程都变成了一种可以回放、可以复盘、可以再利用的素材。
以前写技术文章，很多时候靠的是记忆。你大概记得自己踩过哪些坑，也大概记得最后怎么修好的，但一旦隔了几天，很多关键细节会迅速模糊。尤其是那种“当时为什么这么改”“为什么这个方案被放弃”“中间试过哪几条路”的内容，最容易丢。
而这正好是我这几天最强烈的一个体会：如果你是用 Cursor 配合 agent 在做事情，那么开发过程本身就已经天然带着一份工作日志。
一、Cursor 写文章，真正有价值的不是“起草”，而是“可回溯”
很多人第一次想到 AI 写文章，关注点都在成文速度上：能不能快速起一个大纲，能不能把一段说明扩成几百字，能不能帮忙改标题。
这些当然有用，但对我来说，真正更值钱的是另一层能力：它能回溯。
这几天我在 www.zicode.com 里做的事情并不是单线程的。文章在写，站点在改，脚本在调，仓库在整理，偶尔还会切出去处理别的项目。换成以前，这种工作方式很容易导致一个问题：等你想写复盘时，脑子里留下来的往往只有结果，不剩过程。
Cursor 的 agent 工作流很不一样。你可以回看前面的交互、它读了哪些文件、改了哪些地方、跑过哪些命令、哪些尝试失败了、后来又为什么换了一个做法。于是文章不再只是“我事后想起了什么”，而更像是“我根据真实工作轨迹重新组织了一遍叙事”。
这带来三个很实际的好处：
- 复盘会更具体，不容易飘在空中。
- 你写建议时，不是在空想，而是在总结刚刚发生过的真实过程。
- 文章里的很多细节，不用靠硬回忆，可以从 agent 历史产出里重新提取。
说得直白一点，Cursor 让“写文章”这件事第一次和“开发过程留痕”真正接上了。
二、当 agent 历史变长之后，它就不只是聊天记录了
这几天我越来越把 agent 历史当成一种“半结构化素材库”来看。
它当然首先是对话，但又不只是对话。里面往往混着几类信息：
- 目标是怎么一步步澄清的。
- 方案是怎么收敛的。
- 文件改动反映了哪些真实取舍。
- 命令输出证明了哪些判断是对的，哪些判断是错的。
- 最后真正落地的东西，和最初想象的东西有哪些偏差。
这跟普通聊天记录最大的区别在于：它天然贴着工程事实。
比如你想复盘一个脚本是怎么做出来的，单看最后那份源码，其实是不够的。源码只会告诉你“结果长这样”，不会告诉你：
- 为什么一开始的目录结构不适合直接开源。
- 为什么某些路径要从硬编码改成配置项。
- 为什么 README 不能只是两行介绍，而必须补齐安装、示例配置和安全说明。
- 为什么推送 GitHub 时，最后走的是 SSH 而不是 HTTPS。
但这些内容，在 agent 历史里恰恰是现成的。它们不是额外补写出来的注释，而是工作本身留下的痕迹。
所以我现在越来越觉得，Cursor 在内容创作上的一个重要价值，不是“代写”，而是“代为保存上下文”。
三、这次最典型的一件事：把同步微信公众号的脚本做出来，再顺手开源
这几天我在 www.zicode.com 里做的一件很具体的事，就是整理同步微信公众号草稿箱的脚本。
原来这个脚本是站点内部使用版本，能用，但明显带着项目现场感：路径是站点内的，配置是站点内的，说明文档也默认你知道它依附在什么目录里。自己用当然没问题，一旦想公开给别人看，问题就来了。
开源不是把文件复制出去就结束了。真正麻烦的部分，通常是这些边角：
- 哪些路径是硬编码的，必须解耦。
- 哪些配置可以公开示例，哪些绝对不能进仓库。
- 哪些说明你自己觉得“大家应该都懂”，其实别人根本不知道。
- 哪些本地便利做法，一旦放到公开仓库里就会变成隐患。
这次我就是直接在 Cursor 里做了这轮整理：先 clone 现有仓库，再把脚本迁进去，再把说明文档补齐，再把本地配置从仓库边界上隔开，最后完成提交和推送。
最终整理出来的开源仓库在这里：
这个仓库现在包含了几样我觉得真正有意义的东西：
- 一个可以独立运行的
sync_wechat_article.py - 一个安全的配置样例
- 一份能把安装、配置、调用方式讲清楚的
README - 对本地密钥和生成文件的忽略规则
换句话说，这次开源的重点不是“把脚本发出去”，而是“把别人真正能接起来的那一段补完整”。
四、脚本本身不难，难的是把“项目内工具”变成“可公开工具”
如果只讨论代码量，这个脚本并不算夸张。它做的事情也很明确：抓文章页、提正文、处理图片、调用微信公众号接口、创建或更新草稿、必要时回写 frontmatter。
真正麻烦的，是当你决定把它公开时，你会被迫重新看一遍边界问题。
例如这次我就明显碰到了几个典型点：
1. 项目路径不能再假定别人和你目录结构一样
内部脚本写久了，很容易默认自己就在那个项目里运行，某个目录就在固定位置，某个资源一定在 astro-site/public 下面。
一旦要开源，这种默认立刻失效。于是路径相关的东西就得从“内部约定”变成“外部配置”，比如 content_root、public_root、node_modules_root 这类配置项，就是在这个过程中补出来的。
2. README 不是装饰，它是可用性的一部分
很多开源仓库最常见的问题，是作者以为自己已经写了 README，读者却还是不知道怎么跑。
这次我对 README 的要求其实很简单：别人第一次点进来，至少要知道四件事。
- 这个仓库是干什么的。
- 需要装什么依赖。
- 配置文件要怎么写。
- 最常见的命令该怎么跑。
这听上去像常识，但真做过几次开源整理之后就会知道，这四件事其实已经能筛掉绝大多数“只对作者本人可用”的项目。
3. 敏感信息不是“记得别传”，而是“默认传不上去”
这点尤其重要。
如果一个仓库要靠作者自己时刻记得“别把真实配置提交进去”，那它迟早会出事。更合理的方式，是在仓库层面把这种风险尽量前置消掉：示例配置只保留占位符，本地配置默认忽略，生成预览文件不进版本控制。
我现在越来越觉得，所谓工程卫生，很多时候就是把“靠自觉”改成“靠默认行为”。
五、反过来，写技术文章这件事本身，也因为 Cursor 变得不太一样
这篇文章本身，其实也是一个例子。
它不是那种“我坐下来，一口气从标题写到结尾”的文章。更像是这样一个过程：
- 先根据这几天真实做过的事，确定几条主线。
- 让 Cursor 帮我把主线展开成一版完整草稿。
- 再回头对照 agent 历史，把其中过于抽象、过于顺滑、过于像模板的部分重新改掉。
- 最后再自己做一轮中文语感上的润色。
所以如果非要问“这篇文章是不是 Cursor 写的”，我觉得比较准确的回答应该是：
它主要是通过 Cursor 写出来的，但不是把提示词一丢就收工，而是把 Cursor 当成起草器、整理器和复盘器，最后再由我自己把叙述节奏、重点和语气收回来。
这也是我现在越来越喜欢的一种工作方式：不是把作者换成 AI，而是把“搜集素材、组织结构、找回上下文”这些很费脑力但并不总是高价值的工作，尽量交给 agent 去辅助完成。
六、如果你也想用 Cursor 写技术文章，我会给几点很实际的建议
这几天边做边写之后，我对这件事有几个非常具体的建议。
1. 不要上来就让它“写一篇完整文章”
这是最容易把文章写得一股 AI 味的方法。
更稳的做法是先给它明确素材边界：最近改了什么、做成了什么、踩了哪些坑、哪些部分值得讲。这样它输出的草稿会更贴近真实过程，而不是一份看起来很完整、其实没什么体温的通用模板。
2. 把 agent 历史当素材，不要只当聊天记录
如果你已经在 Cursor 里真实做了一段工作，那么最有价值的输入常常不是你重新写给它的一段需求，而是之前工作流本身留下来的历史。
回头翻这些历史，能很快找回几个关键东西：
- 当时最初的问题是什么。
- 后来判断改变发生在哪。
- 真正有价值的经验到底来自哪一步。
这些东西一旦找回来，文章就会立得住。
3. 初稿可以快，定稿一定要慢
Cursor 很适合把第一版迅速摊开，但真正决定文章质量的，仍然是后面的删改。
尤其是下面几类地方，我基本都会手动再过一遍：
- 结论是不是说得太满。
- 句子是不是太平均、太像模板。
- 段落之间是不是过度平滑，缺少真实思考的停顿感。
- 有没有把“过程中的犹豫”也写进去，而不是只剩最后的正确答案。
文章一旦只剩“正确答案”，读起来就很容易像说明书；而好的技术文章，往往恰恰要保留一点真实工作里的弯路和判断。
4. 把“经验”写成别人真的能拿去用的建议
这一点我自己也在刻意练习。
很多复盘类文章最大的问题，是作者写得很诚恳，但读者看完不知道能带走什么。要避免这个问题，最简单的方式就是在每一段经验后面追问一句：如果别人明天也遇到类似场景，他能直接照着做什么？
比如这次我真正想给出去的建议，其实就很朴素：
- 用 Cursor 做项目时，别浪费它天然留下来的过程历史。
- 想开源一个内部脚本时，先想“怎么让别人接起来”，再想“怎么把代码发出去”。
- 写技术文章时，先让 agent 帮你找回过程，再由你自己决定最后要讲什么。
七、到最后我反而更确定了一点：AI 写作最有价值的部分，仍然是“增强作者”，不是“替代作者”
这几天做完之后，我对这件事的看法反而更清楚了。
我当然承认，Cursor 可以帮我更快地产出第一版文章，也可以帮我更快地整理脚本、补 README、梳理说明。但如果只把它理解成一个“自动写字机器”，其实有点低估它了。
它更有价值的地方，是把作者从一些高摩擦工作里解放出来：
- 记不清过程时，帮你找回上下文。
- 材料很散时，帮你先搭结构。
- 代码已经写完但很难讲清楚时，帮你先整理表达。
- 一项工作快结束时，帮你顺手把文档、示例配置和开源包装补齐。
换句话说，它不只是提高了“生成速度”，更提高了“复盘密度”。
这也是为什么我会专门写这篇文章。因为对我来说，这几天最有意思的，不只是把 www.zicode.com 的一段工作做完了，也不只是把同步微信公众号的脚本开源了，而是我开始越来越自然地把 Cursor 当成一种长期工作介质：开发在里面推进，文章在里面起草，经验在里面沉淀，最后连复盘本身也能反过来借助这些历史产出完成。
这种感觉挺轻松，也挺新鲜。
你不是在面对一个“帮你写答案”的工具，而更像是在跟一个会留下完整工作轨迹的协作者一起做事。等事情做完，再回头写文章时，你会发现素材其实早就已经在那里了。