夜雨聆风
我花半天用 AI 做了一个公众号写作工具,也顺手验证了一套 AI 提效工作流
结果是，我用半天做出了一个能用的工具：左边写 Markdown，右边实时预览样式，一键复制格式，先接上 AI 封面图生成，摘要这一步暂时还是手动处理，插图能力准备放到下一期再补。
当然，它现在还只是一个很早期的 MVP 版本，界面也比较粗，现阶段更重要的是先把这条写作发布链路真正跑通。模型选型和 AIGC prompt 也都还只是先跑通可用，离真正精修还有一段距离。
这次最先落地的是公众号写作场景，但它底层想解决的，其实不只是公众号排版，而是一类内容写完之后还要继续格式化、整理、发布的重复劳动。表面上看它像一个写作工具，底层更像一个面向发布场景的文档排版编辑工具。
但做完之后我发现，真正值得讲的不是“AI 又帮我写了一个工具”，而是：我借这个项目验证了，一套 AI 提效方法，个人也能跑通。
写公众号最烦的，很多时候不是写，而是写完之后那一串重复劳动。把 Markdown 内容重新贴进编辑器、调整排版、确认样式有没有乱、补封面图、再写摘要，这些动作单看都不复杂，但很难彻底省掉。写作本身反而是最清楚的一步，真正消耗精力的，是发布前这些零碎但绕不开的环节。
这件事表面上是在做一个工具，实际上我更在意的是另一件事：我想借这个具体痛点，验证个人项目能不能也跑出过去团队里那种“规范化开发”的感觉。
一、编辑器够多了，真正缺的是什么？
如果只看“公众号文章编辑器”这一层，市面上其实已经有不错的工具了，比如 Mdnice 这类产品，在 Markdown 排版和实时预览体验上已经做得很成熟。
我后来把自己最在意的四个需求粗分了一下：
-
左右预览：技术难度不高，Mdnice 这类产品已经做得不错，差异化价值反而最低 -
段落配图：价值高，但复杂度和交互成本都更高，适合后置 -
封面图生成：差异化价值高，而且和公众号发布场景贴得很近 -
AI 摘要：实现难度不算高，但很适合补上整条发布链路 
换句话说，“公众号文章编辑器”本身不是空白，真正还有空间的，是把写作发布链路和 AI 能力补齐。更进一步说，这也不只是公众号场景的问题，而是一类格式化内容发布工具都可能遇到的问题。
但我这次真正想补的，不是“再做一个 Markdown 编辑器”，而是先把公众号这条最真实的写作发布链路里的几个高频痛点串起来，验证一个文档排版编辑工具到底应该把哪些动作真正收回来：
-
写完之后直接复制公众号格式，而不是继续处理 HTML 源码 -
通过 API 直接调用文生图模型，生成适合公众号的封面图 -
在写作界面里直接生成摘要，减少发布前的重复劳动 -
下一版继续补文章插图生成，把正文配图也收进同一条链路
我想做的也不是一个孤立的“编辑器组件”，而是一个更贴近真实工作流的试点：把写作、排版、封面、摘要、插图这些原本分散的动作，尽量收进同一个 AI 辅助流程里。
这件事的关键，不只是“也能调一下大模型 API”，而是尽量减少来回切换。更常见的做法是：文章写在一个地方，封面去另一个模型页面生成，摘要再去第三个对话框里试几版 Prompt，生成后再手动复制回来。单看每一步都不难，但每一步都在打断写作本身。
如果后面再补上正文插图，这种割裂会更明显。你可能需要一边写文章，一边反复切到不同模型页面里描述需求、改 Prompt、等结果、拷回内容，再继续写。真正浪费时间的，往往不是某一次生成，而是这些切换和重复确认。
另外还有一个很现实的问题：现在不少工具的 AI 能力都建立在订阅套餐之上。对于高频创作者，这可能还能接受；但对很多只是偶尔写一篇、偶尔要一张封面图或一段摘要的人来说，单独为几个零散动作各买一份服务，性价比并不高。
所以更理想的状态，是把这些能力变成“写作过程中的一个按钮”，而不是“写作之外还要再开几个网站”。对用户来说，体验上的差别，不是模型强了一点，而是原本分散的动作终于被收回到了同一个上下文里。
这也是它值得做的原因。不是因为它有多大，而是因为它足够真实、足够贴近日常使用，也足够清楚地暴露出：哪些只是已有能力，哪些才是真正值得补的提效能力。
二、为什么个人项目也需要“规范化”？
过去在团队里推动规范化开发时，我一直很认同一件事：减少反复调整，不靠“记得住”，靠的是把需求、边界、验收标准先写清楚。
以前这更像团队协作的方法。现在我发现，个人项目一样适用，而且在 AI 参与之后反而更重要了。
这次开始之前，我没有直接打开编辑器就让 AI 开写，而是先花了将近一小时，把需求说明、技术选型、模块划分、阶段验收标准写进文档。
这件事在没有 AI 的时候，可能只是“做事认真一点”；但在有 AI 的时候，它的意义变了。
AI 在每一次新会话里都没有记忆，它能输出什么，完全取决于它当下能读到什么。文档越清楚，它输出的就越接近你真正想要的东西。
所以设计文档不是附属品，而是整个协作过程的事实来源。这个项目里，像 AI 提供商怎么选、CORS 怎么处理、阶段怎么划分、验收标准怎么定，这些事情都在写代码之前先决策完，再沉淀进文件。
我后来回头看，真正有用的不是“写了一份大文档”，而是我其实在按一套很具体的结构在写：
-
Requirement：先写背景、目标、范围、约束、验收标准 -
Design：再写方案概述、影响范围、风险、验证方式 -
Tasks：最后拆成可独立验证的小步骤
放到这个项目里，大概就是这样：
-
背景：内容写作发布里最烦的是排版、复制、封面、摘要这些重复动作，这次先从公众号场景切入 -
目标：做一个自己真的会用的文档排版编辑工具，而不是只演示一个编辑器 -
范围：先做左右预览、复制公众号格式、封面图、摘要；段落插图明确放到下一版 -
约束：纯前端可跑、用户自带 OpenRouter Key、不引入后端代理 -
验收：能写、能预览、能完成格式化复制与发布，先确保公众号后台这条链路可用，封面和摘要链路可用
也就是说，规范化开发在这里不是一句价值观，而是把“为什么做、这次做什么、不做什么、做到什么算完成”先写成文件。这样 AI 读到的不是一段模糊需求，而是一组有边界的任务说明。
而且这套结构并不是我临时在这个项目里现想出来的。之前我已经把规范编程的模板、执行流程，以及不同团队、不同阶段的落地路径，陆续整理进自己的知识库和模板库里。
这次更像是把过去在团队里总结过的方法，先缩小到一个个人项目里重新跑一遍，看看它在更轻量、更高频的场景里是不是依然成立。
后来再回看，我觉得最有价值的不是“写了文档”，而是这件事把整个过程从“靠聊天临场发挥”，变成了“先文件对齐，再进入对话执行”。
如果你也想试一下，其实可以先从一个极简模板开始：
极简模板
Requirement
背景：现在最痛的点是什么 目标：这次做成什么 范围：这次做什么 / 不做什么 约束：有哪些不能突破的条件 验收：看到什么结果算完成 Design
方案：准备怎么做 风险：最可能卡住的点是什么 验证：最后用什么方式证明它真的可用
三、实现计划，怎么把执行变“机械”？
设计文档回答的是“做什么”，接下来还需要一份实现计划，回答“怎么做”。
这份计划不是模糊的任务列表，而是把工作拆成很多小步骤：每个任务都写清目标、输入、操作、验证。也就是：
-
这一步到底要完成什么 -
需要参考哪些文件、规则或样例 -
具体要改哪里 -
跑什么命令或看什么结果，才能证明这一步真的完成了
这个拆法对 AI 特别重要，因为它天然适合被分段执行。
比如这次项目里，执行上就很接近这样：
-
Task 1：先把设置面板和本地存储打通，验证保存后是否能恢复 -
Task 2：打通 OpenRouter 图片生成，验证返回结构里图片字段到底在哪 -
Task 3：调整复制链路，从复制 HTML 源码改成复制公众号格式 -
Task 4：补测试，确认链接脚注、代码块转换和降级复制都能工作 -
Task 5：做回归验证，看构建、测试和手动粘贴链路是否正常
这次我在 Claude 里其实也真实跑了一遍更完整的流程：先用 Superpowers 把 brainstorm、design、plan 这些步骤串起来，再用 OpenSpec/规格先行的思路把 proposal、design、tasks 这类产物拆清楚。
所以这里说的“先写 spec、再写 plan、最后执行和验证”，并不是我事后总结出来的一套好听说法，而是这次开发过程中实际用过的工作方式。
它的价值在于，AI 不需要每次都重新“理解全局”，它只需要把当前这一步做好。
对个人项目来说，这一点特别重要。因为你不是随时都在一个连续上下文里工作，注意力会中断，工具会切换，第二天再回来时，人的记忆和 AI 的记忆都不一定可靠。但文件可靠。
这里还有一个很有意思的收获：计划文件本身就是冷启动文档。任何一个新的 AI 会话，只要读完计划，就知道下一步应该从哪里接着做。哪怕中间换了工具，切到新的上下文，流程也不会一下断掉。
而且计划够细，还有一个额外价值：它能在编码前就暴露问题，编码后还能对照评审。
这次就提前发现了一个坑。最初计划里写错了 CSS 内联库的方法，用成了那个接受 DOM 对象的版本。如果没有把计划写细，这个问题大概率会拖到编码甚至调试阶段才发现。最后能在动手前就改掉，靠的不是运气，而是计划本身足够可审查。
后面我实际也在按一套很朴素的评审清单回看：
-
这次实现是不是满足最初 requirement 的目标和边界 -
有没有偏离 design 里定下的方案和约束 -
验证记录是不是存在 -
这次踩到的坑，要不要回写进规则、模板或知识条目
所以第三部分真正想表达的不是“计划让执行变机械”，而是：当任务被拆成目标、输入、操作、验证，再加上最后的评审和回写，AI 的执行就不再像一次即兴发挥，而更像在跑一条有护栏的研发流程。
对应到执行层，我现在更常用的也是一个很短的任务卡片：
任务卡片
Task
目标：这一步要完成什么 输入：先读哪些文件 / 规则 / 样例 操作：具体改什么 验证：跑什么命令，看到什么结果才算完成
四、后端出身，为什么能半天做出前端工具？
这件事对我自己也有一点反差感，也让我第一次真切感觉到：过去很多更像团队能力的东西，现在个人也能试着跑起来。
我以前更多是后端开发出身，没有系统的产品经验，也没有前端、UI 设计背景。如果按传统方式让我从零把这样一个工具完整做出来，大概率会在很多细节上来回试错，光是页面结构和交互就要消耗不少时间。
但这次从初稿到可用版本，整体只花了半天左右。
我不觉得这是因为我突然会做前端了。更准确的说，是因为这次工作方式变了：
-
痛点足够具体，目标很清楚 -
设计和计划先行，减少了来回返工 -
AI 负责大部分执行，我主要负责边界判断、验收和回写
整个过程中，真正明显卡住我的，其实只有一个点：OpenRouter 图片生成接口的返回结构和预期不一致。通常图片 URL 应该在一个专门的字段里，但实际返回里，图片是藏在 choices[0].message.content 这个文本字段里的，格式是一段 Markdown 字符串 ，需要用正则把 URL 提取出来。
这个问题 AI 自己发现不了，因为它没有运行时的真实返回数据。得我手动调接口、看原始响应，确认结构之后，再告诉 AI 去哪里取值、用什么方式提取。这大概是整个项目里最典型的“判断在人、执行在 AI”的分工。
除此之外，大部分实现工作，包括组件组织、布局调整、测试补充、复制链路改造，基本都由 AI 完成。
所以这件事最值得强调的，不是“AI 真厉害”，而是：当问题定义足够清楚、过程文件足够完整时，个人也可以把原本更像团队协作的一段工作流，压缩到很短时间内跑通。
五、工具可以切换，但上下文必须继承
这次还有一个让我感受很深的点：我不是一直在同一个工具里做完的。
中间我同时用了 Cursor 和 Claude。工具一换，会话就断；会话一断，背景就容易丢。很多人以为多工具协作的瓶颈在模型，其实更常见的问题是：上下文的连续性很脆弱。
我的做法是把“状态”写进文件，而不是留在聊天记录里。
我维护了一个进度文件，记录每个阶段的状态、已知问题和下一步计划；也专门写了交接文档，把关键文件路径、当前卡点、验证结论和调试建议整理出来。这样切换工具之后，不需要重新从头解释，只要读一遍文件，就能直接从上次停的地方接着做。
效果比我预想的更好。
这件事也让我更确定：多工具协作不是问题，真正的问题是你有没有把上下文外置成可继承的文件。
很多人用 AI 时的摩擦，不来自模型能力，而来自“这个会话里解释过的东西，下个会话全没了”。解决办法不是永远依赖一个上下文更长的工具，而是把背景、状态和决策写进过程文档里。
文件才是唯一能跨会话、跨工具、跨时间保留下来的东西。
六、把坑写回去，才是复利
每次遇到问题，解决完之后，我都会把问题和解法写回设计文档。不是为了做流水账，而是为了把这次的摩擦变成下次的起点。
这次我回写过的几类问题，大概像这样：
这里要区分一下：这些并不都是“把我卡住很久的大 bug”。真正需要我停下来查真实响应、手动确认字段结构的，只有 OpenRouter 图片返回这一处。其他更多是随着实现推进暴露出来的细节修正，而这些恰恰最适合被回写进文档，避免下一次重复踩。
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这些内容如果只停留在聊天记录里，过几天就只剩模糊印象；但一旦写进文档，它就变成了工程资产。
聊天记录和临时对话更适合解决当下问题；而文件、规范和过程文档，才更容易被保留下来，变成下一次还能继续利用的内容。
这也是为什么 AI 提效真正有价值的地方，不只是当下快一点，而是能把一次次试错慢慢沉淀下来，变成后面可以接着用、接着改的资产。
七、这件事，真正改变了什么？
这个项目做到现在，我更愿意把它看成一次 AI Coding 范式的验证，而不是一次单纯的工具开发。
如果只看结果，它当然还是一个个人文档排版编辑工具：可以实时预览样式，可以直接复制格式，可以生成封面图和摘要。
但如果把它放回公众号写作场景里看，这几个能力解决的其实是同一类问题：不是“我不会写”，而是“写完之后还有一串重复劳动”。从排版、复制、封面到摘要，这些动作原本是分散的，现在被尽量收回到一条连续的工作流里。
而公众号只是我这次拿来验证的第一个具体场景，不是这个工具唯一的边界。后面如果继续往下做，它也完全可以延展到其他同样需要格式化、整理和发布的内容场景里。
但如果看过程，它真正改变的其实是三件事：
第一，我的重心开始从“怎么写代码”转向“定义什么问题值得解决、结果怎样算验收通过”。第二，我越来越少依赖长对话来维持上下文，越来越多依赖文件、计划和交接文档。第三，过去很多只在团队里才能跑起来的规范化方法，现在个人项目也可以试点，而且成本比想象中低得多。
所以我不想把这件事简单归结为“AI 写代码更快了”。
更准确的说法是：AI 把我从大量执行细节里解放出来，让我有更多精力去做问题定义、过程控制和结果判断。
代码大部分可以交给 AI，判断力还是要留在人这里。
有一句话我现在越来越认同：
同一个任务，换一个人、换一次会话、换一个工具，结果依然基本可控，这才是从“好用”走向“可用”。
这件事靠的不是更华丽的 Prompt，靠的是文件、流程和回写机制。
如果你也在探索 AI 提效，我更建议你别先从“换哪个模型、抄哪个 Prompt”开始，而是先从一个真实痛点开始，把目标、边界和验收写清楚，再让 AI 参与执行。
你平时写公众号时，最烦的是哪个环节？是排版、封面、摘要，还是发布前那一连串重复操作？欢迎留言聊聊。
目前这个工具也主要还是我自己在本地使用和迭代。如果你也有类似痛点，或者觉得哪个环节最值得补，欢迎留言提建议，我后面会继续迭代修正。
如果这篇文章对你有启发，欢迎关注公众号「智码探路」；我会持续整理一线实践与思考，分享这套工具后续的迭代与修正，也期待和同行一起交流、共同进步。
扩展阅读
《把喜欢的公众号文章，OpenClaw 一键变成自己的知识库》：如果你也关心“内容如何沉淀成AI 可检索资产”，这篇可以作为另一条实践线索。
《AI Coding 从好用到可用，差的不是手感，而是工程能力》：从“模型会不会写”继续往下看，真正影响结果的是工程环境、上下文和规范建设。
《研发效能提升：从传统工程到 AI 协同》：把 AI 协同放回更大的研发效能框架里看，帮助理解这套方法为什么不只是工具技巧。