如何把手动 AI 写作流程变成可复用的 Production Skill

我的第一轮 AI 辅助 Blog 生产顺利完成了，却还不能称为真正可复用。

那篇文章先后经历了研究、Content Brief、英文写作、审计、局部修改、中文原生改写、网站实现、metadata、structured data、responsive QA、发布和线上验证。从结果看，流程已经闭环。

但在执行过程中，太多重要信息仍依赖手动 orchestration。关键规则藏在很长的 task instruction 中，批准散落在不同对话里。到了下一阶段，Owner 有时还要重新说明上一阶段已经发现的边界。只要有人记得每个决定之间的关系，这套流程就能重做；一旦离开那段上下文，复用就变得不可靠。

这正是一轮成功执行与可复用 Production Skill 的差别。Skill 需要保存写作周围的 operating judgment，而不只是把写作步骤再运行一遍。

本文记录我怎样把 HuiyangXie.ca 的 Blog 流程改造成这样的系统。重点是 Production Skill 本身，不展开关键词研究的 provider 细节，也不声称文章可以自行发布。

长 prompt 是流程证据，不是最终架构

第一轮手动执行里已经有很多有效指令：验证来源、准备 Content Brief、控制 claim、写英文稿、分开审计、做局部修改、冻结获批来源、进行中文原生改写、核对中英文事实、把文章交给网站，并检查发布安全。

如果把所有内容复制进一个更长的 prompt，原有顺序可能保留下来，核心问题却没有解决。下一次执行仍要判断：哪些指令适用于当前阶段？现在已经完成到哪里？一个失败应该重开研究、英文、中文，还是网站实现？

于是，我把手动流程当作 process evidence。重复出现的决定可能成为可复用规则；只发生一次的 incident 先保留为例子，除非它暴露了更普遍的边界。Owner correction 的优先级高于方便的推断，因为这些修改最能说明 workflow 原本哪里给了错误行为空间。

提炼规则时，我主要问：

• 哪些决定在多个阶段反复出现？
• 哪些错误来自状态或责任人不清楚？
• 哪些检查可以稳定自动运行，同时不改变编辑权限？
• 哪些失败需要局部修复，而不是从头再来？
• 哪些事实必须完整穿过英文、中文和网站层？
• 即使所有审计 PASS，哪些行动仍要 Owner 明确决定？

这些答案最后变成 module 和 contract。旧 prompt 仍是 provenance，却不再充当 runtime interface。

Module 应该围绕责任拆分

最早的可复用版本把工作分为 Portfolio Research、Topic Readiness 与 Content Brief、英文编辑、中文原生改写、Website Handoff、Publication Verification 和后续 Observation。

这样拆分，是因为它们的运行节奏本来就不同。Keyword discovery 是周期性工作；Content Brief 按文章发生；英文和中文有不同的编辑责任；网站层会引入 route、metadata、schema 和 publication state；观察发生在上线以后，不能因为早期数据不多就把文章重新打开。

若架构只是一条固定的“Step 1 到 Step 20”，每篇文章都会被迫走相同路线。Module 让 Skill 先识别当前状态，再读取对应 contract。已有可靠研究的主题可以直接进入 Brief；中文修改可以从精确锁定的英文来源开始，无需重跑 discovery；网站出错时也可以回到 implementation，而不是重新支付 provider 调用。

不同层的责任因此变得清楚：

责任越明确，自动化反而越容易，因为每个 module 只需回答更小、更具体的问题。

用状态代替对话中的默认理解

最关键的改造，是建立明确 state。

日常沟通里，“approved”“ready”“final”“done”听起来很接近。在生产系统中，它们会授权完全不同的行动。Backlog 中的主题尚未获得生产批准；Content Brief 可以允许开始写作，却未必已经 immutable；通过内部审计的英文稿还没有 Owner approval；可以打开的 preview 也不是 published 页面。Build 成功更不等于 production verification。

因此，Skill 必须同时记录 artifact 与它允许的下一项行动。Owner 最终审核之前，中英文使用 candidate lock：它保存通过内部审计的精确 path 和 hash，让后续准备阶段拥有稳定输入。Candidate lock 不会自动创建 Owner freeze。

之后，Owner 会看到一个整合 package，其中包含中英文文章、preview routes、证据摘要、审计结果和 publication readiness。明确批准后，系统才能 ratify 精确的 candidate hashes、创建 freeze record，并向独立的发布流程交接。

这个区别能防止很隐蔽的漂移。如果 Owner 要求改字，workflow 必须生成新的 candidate 并重跑受影响的检查，不能继续声称旧 hash 已经获批。

“Done” 应该如何定义是另一个更完整的话题。在 Skill 内部，我采用的规则很直接：每个状态都要写清已经验证了什么，以及哪些权限仍然不属于它。

审计成为内部状态转换，而不是一次次会议

手动周期要求 Owner 先后审核 Brief、英文初稿、英文修改、中文初稿、中文修改、视觉实现和发布决定。其中一部分 gate 确实保护重要的编辑权限，另一部分只是因为当时的 workflow 还无法可靠地审计与修复自己。

Low-touch 版本把 routine checks 放入生产流程。Content Brief 接受策略与证据审计；英文分别检查 brief compliance、claim 和 humanization；中文检查 native language、AI pattern、中英文事实、Brief、claim、evidence 与 scope；网站再检查 source、build、render、accessibility、SEO、GEO/retrieval、schema、link 与 draft safety。

这些审计通过后，机器并不会自动成为编辑。它们的作用，是在请求 Owner 判断之前先准备一个更完整、问题更少的 candidate。

Humanization audit 很能说明这个边界。LOW 通常不需要自动修改，除非存在具体 material problem；MEDIUM 一般优先局部修复；HIGH 可以考虑更大范围修改，但事实、策略与证据不能因此松动。评分用来指导行动，不是为了刷分而重写文章。

第一轮 Skill pilot 进一步确认了这一点。自动审计可能给出 LOW，Owner 仍会发现某段过于像教科书、例子不够可信，或标题太像口号。这样的 editorial judgment 不会让审计失去价值，它只是划清了一致诊断和人工判断的边界。

Targeted repair 也需要上限

当 audit 可以自动运行，新的风险是 audit/repair loop。一次改写可能让节奏更自然，却削弱 claim；修正事实后可能产生 Brief mismatch；网站 representation 解决渲染问题时，也可能改变可见含义。

Workflow 为每个 material blocker 建立稳定 ID、audit signature、attempt count 和 status。修复只改变最小必要范围，然后重跑所有相关 regression。只要策略和大部分内容已经通过，就不重新生成整篇文章。

四项规则限制 repair：

• 单个 blocker 最多进行两次 automated repair；
• 正常文章周期最多使用四次 material automated repair actions；
• 失败特征重复或不同 audit 相互拉扯时，立即停止循环；
• 下游 failure 永远不能重跑已经完成的 paid research。

如果问题仍然无法解决，状态会进入 EXCEPTION_OWNER_DECISION_REQUIRED。这不是临时兜底，而是 evidence ambiguity、strategic conflict、privacy risk、unexpected spend 或 repair budget 用尽时的正式交接。

第一批两篇 Low-touch pilot 都在限制内到达 Final Review，没有中途触发 Owner exception。网站层为第一篇使用一次 material repair，为第二篇使用两次，处理了 table representation 与 unpublished relationship 的安全降级。Paid research 没有重跑。

这些只是小规模 pilot 的 process evidence，不能证明以后每个主题都会走完 normal path。

Evidence contract 防止“原创”变成编造

手动 workflow 鼓励使用第一方 evidence，因为它能让 Blog 更有辨识度。早期 Skill 的表述却可能把偏好变成 quota：为了显得原创，每篇文章都被迫增加 anecdote，或反复挖掘同一个 Case。

修订后的 contract 按内容模式判断证据需求。Search-led 文章只有在第一方材料能提升准确性或实用性时才使用；Authority-led 通常需要 practitioner judgment，但没有固定 anecdote 数量；Experiment-led 的主题本身就是实验，因此必须有真实方法、观察或结果作为中心证据。

Evidence 还要有 claim state。已有记录支持的 process observation、新加入并得到 Owner 确认的事实、需要外部来源的 current claim、以及不应写入文章的 unsupported/private claim，分别处理。Owner 新证据会记录 provenance 与 disclosure boundary，不会假装它早已存在于旧 Case 中。

这样做之后，文章的可信度反而更高。Originality 来自真实决定和观察，而不是硬塞个人细节。

中英文 production 也遵循同一原则。锁定英文控制事实、thesis、example、attribution 和 claim boundary；中文负责自然的语序、节奏、术语与编辑表达。EN↔ZH factual regression 检查两者关系，却不要求逐句翻译。

网站实现会暴露编辑阶段看不到的问题

一份文档在编辑上完成，并不代表已经可以安全上线。

一次 pilot 中，comparison table 的内容正确，renderer 却把 Markdown syntax 当作普通文字显示。网站层改用支持的 semantic markup，并保持可见含义不变。另一次，文章想关联的 Workflow 仍未发布。这个关系继续保存在 structured handoff data 中，访客正文则安全降级为普通文字，没有形成 dead link。

这些情况最后变成可复用规则：

• Blog、Work/Case 与 Workflow 使用不同的 typed fields；
• unpublished destination 会被过滤、隐藏或显示为安全文字；
• 没有内容的 related section 要干净消失；
• semantic table 和 list 在改变网站 representation 时仍要保留原意；
• title suffix、author formatting 等 site-owned values 从网站配置读取，而不是由编辑 handoff 硬编码。

对已经获准进入 production queue 的文章，Blog Skill 可以把中英文实现为 published:false 页面并完成 preview checks。它仍不能发布、stage Git、deploy，或吸收无关的网站修改。

这条分界是刻意保留的。Publication Adapter 只接受 Owner 批准的精确 package。一篇 Blog 的 release 不能因为和其他 workstream 共用 working tree，就顺带带上未获授权的视觉改动。

从第一版 Skill 到 Low-touch workflow，真正改变了什么

第一版 private Skill 提取了 module 与质量 safeguard。之后的 pilot 暴露出 Topic Approval、Brief approval 与 freeze、evidence provenance、humanization action、中文 route、semantic table 和 unpublished link 等规则仍有歧义。这些发现被收进一个窄范围 patch，没有推倒重来。

Low-touch 版本接着改变了 interaction model。日常 Brief、draft、claim、language 与 implementation gate 变成内部 audit 和受控 repair；candidate lock 保持精确文件稳定；多次正常中途 review 被合并成一次 Owner Final Review。遇到 workflow 无法安全决定的事项时，exception gate 仍然存在。

目标从来不是让人完全退出，而是把人的注意力放在真正会改变含义、权限或 release state 的地方。

我现在会用五个方面判断一套 Production Skill 是否可复用：

• 状态清楚：每个 module 都能找到 canonical input，并知道允许的下一步。
• 证据受控：claim 有 provenance、disclosure limit 和明确排除项。
• 修复有纪律：failure 触发小范围修改，而不是整篇 regeneration。
• 责任不混淆：编辑、中英文、网站和发布的 ownership 相互独立。
• 审核可执行：Final Review package 呈现重要决定，无需 Owner 重建整次执行。

这些属性让 workflow 可以被检查，也让真正的 exception 更容易识别。

可复用，是把判断保存成可执行结构

手动周期让我看到哪些决定最重要；当这些决定离开对话记忆，进入 artifact、state、audit、repair rule 和 ownership boundary，Skill 才真正开始发挥作用。

有些事情仍然刻意留给人。即使所有 automated checks 通过，Owner 仍可以拒绝主题、质疑 evidence、改变编辑方向或不批准发布。Skill 的责任是准备一份连贯、可追溯的 candidate，并把值得人判断的问题清楚地呈现出来。

这也是我判断其他 AI-assisted production workflow 的标准：不仅要问指令能否重跑，还要问 evidence、state、exception 和 authority 能否一起被保留下来。