Appearance
把一次成功任务变成普通人可复用的工作流
嘿，你有没有遇到过这种情况：某个任务你做了一次，效果特别好，领导满意、同事夸、自己也觉得挺顺。但第二次再让你做，还是得从头琢磨一遍，甚至忘了上次是怎么做的。
我踩过这个坑太多次了，后来慢慢总结出一个习惯：别一上来就想全自动化，先老老实实手动跑通并检查至少三次。 稳了之后，再把它存成模板、项目规则、Skill 或者定时任务。这样每次复用的是一个已经验证过的方法，而不是把第一次的运气放大成第二次的灾难。
聊到这里你可能会问：什么任务值得花这个功夫？我们接着往下看。
什么任务值得复用
适合做成工作流的：
- 每周项目状态更新；
- 月度经营简报；
- 会议纪要和行动项；
- 商品上新资料包；
- 客户访谈总结；
- 固定栏目文章和短视频脚本；
- 课程讲义和练习；
- 定期竞品、政策或数据监测。
这些任务的共同点是：输入稳定、步骤重复、输出格式固定。
反过来，下面这些就先别急着流程化：
- 只做一次、没有稳定输入的任务；
- 每次都需要重大创意方向或高层决策；
- 规则还在频繁变化；
- 涉及无法人工检查的高风险动作；
- 第一次结果尚未验证。
讲完了"适不适合"，我们来看看具体怎么做。我拆成了八个步骤，从最轻量到最重量的顺序来。
第一步：记录一次成功任务
任务做完之后，别只留着最终文件就完了。花五分钟记一下你是怎么做的。我用的是这个格式，特别简单：
text
工作名称：每周项目状态更新
输入：本周会议记录、任务清单、风险列表
受众：项目负责人和管理层
固定步骤：核日期与负责人 → 汇总进展 → 提炼风险 → 列出决定和下周事项
输出：一页管理层摘要 + 团队邮件草稿
检查：数字可追溯；每个行动项有负责人和日期；风险有影响和下一步
停止点：邮件只生成草稿；缺少资料时先询问；不修改任务系统就这一段文字，它就是后面所有事情的骨架。我自己经常在任务刚做完、记忆还热乎的时候记，否则过两天细节就模糊了。
第二步：把输入变成固定清单
输入乱，输出一定乱。这是我用血泪经验换来的——有一次我做月度简报，数据源混了两个不同的口径，结果全白做了。
所以每周开始前，我会对着这个清单过一遍：
- [ ] 时间范围明确；
- [ ] 最新会议记录齐全；
- [ ] 任务状态导出日期正确；
- [ ] 预算、进度和风险使用同一口径；
- [ ] 私人和无关信息已移除；
- [ ] 上周遗留行动项已包含。
输入稳定了，后面的自动化才有意义。这个道理说着简单，但太容易被跳过了。
第三步：先保存成任务模板
最省事的复用方式就是存一段任务说明。不用什么工具，直接文本就行：
text
根据本周附件制作项目状态更新。
输出一页管理层摘要和一封团队邮件草稿。摘要依次包含：本周结论、进展、偏差、风险、需要决定的事项和下周行动。每个行动项必须有负责人和日期。
数字只使用附件，冲突时列出差异。缺失信息标为待确认。邮件不发送，任务系统不修改。完成前逐项对照上周遗留行动和本周资料。适合那些频率不算高、每次资料要人工挑选的任务。我平时会把这种模板存在项目根目录的 tasks/ 里，下次直接复制粘贴。
第四步：需要共享背景时创建项目
如果每次做同一个任务都要翻同一套资料——品牌规范、历史样例、术语表——那创建一个项目来统一管理这些共享背景就很有必要了。
项目里应该维护这些东西：
- 项目目的和受众；
- 认可的数据来源；
- 固定术语和指标口径；
- 模板和优秀样例；
- 禁用表达；
- 审批人和对外动作边界；
- 过期信息的更新日期。
注意一个细节：每周仍然新建独立任务，项目只负责提供共享背景。千万别把所有周报都堆在同一个无限膨胀的任务里——我干过这事，后面找东西找到崩溃。
第五步：步骤稳定后制作 Skill
当同一个流程连续三次都成功，而且每次都是重复同样的步骤和检查，这时候可以考虑做成 Skill 了。
帮你生成 Skill 的提示词可以这样写：
text
请根据这三次已经完成的项目周报任务，提取一个"每周项目状态更新" Skill。
保留共同的输入要求、处理顺序、输出结构、检查清单和禁止动作。不要把某一周的客户名、数字或事件写进 Skill。生成后给出正常、缺资料和要求直接发送三类测试。Skill 草稿出来之后，一定人工检查一遍。核心原则就一条：Skill 里只存方法，不存敏感业务内容。 客户的名称、具体数字、内部事件统统放项目或任务里，别写进 Skill。
第六步：需要外部资料时再使用 Plugin
只有一种情况才值得接 Plugin：你每次都要从同一个外部服务拉数据——比如 Drive、Slack、邮件、CRM 或者项目管理工具。
接之前先给自己画个圈，越窄越安全：
- 只读优先；
- 限制到一个文件夹、频道或项目；
- 只获取本周时间范围；
- 不发送、不修改、不删除；
- 找不到资料时返回缺口，不扩大搜索；
- 记录每次使用的来源。
连上之后别直接用到正式业务上，先在测试项目里跑一跑，确认没问题再迁移。权限这个东西，一放开就不好收。
第七步：最后才考虑定时任务
定时任务是最后一步，不是第一步。前提是输入来源稳定、输出已经可靠、而且每次运行不需要即时判断。
一个适合定时的目标大概长这样：
text
每周一上午检查指定项目资料，生成本周会议议程草稿，列出上周未完成行动、当前风险、需要决定的事项和缺失资料。只生成草稿并通知我审核，不发送给团队，不修改任何外部系统。定时不等于放手不管。每次运行后仍然要扫一眼来源日期、运行结果和失败信息。我见过太多次定时任务静默失败了三个月没人知道。
第八步：用三类样本验证
上定时任务之前，用三类样本把流程测一遍：
正常样本
资料齐全，应该生成完整成品。
缺失样本
故意删掉一个负责人或关键文件，看它能不能标出缺口并停止猜测。
越界样本
给它一个越权的要求，比如"生成后直接发给所有人"，看它会不会停在草稿和人工批准前。
如果流程在边界样本里失控了，先别上定时任务，回去把检查点加固。
一张选择表
选工具的时候，够用就好。对着这个表选最轻的那一档：
| 需要解决的问题 | 最小合适方式 |
|---|---|
| 偶尔重复同一说明 | 保存任务模板 |
| 多个任务共享资料和背景 | 创建项目 |
| 步骤、格式和检查长期固定 | 制作 Skill |
| 需要连接外部服务 | 安装并审查 Plugin |
| 固定时间重复执行 | 定时任务 |
| 需要代码、命令或技术系统修改 | 进入 Codex 开发者路线 |
从左边最简单的开始试，搞不定再往右走一步。选复杂方案来证明自己厉害，最后累的是自己。
维护工作流
工作流不是做好了就一劳永逸。每个月或者规则有变化的时候，快速过一下：
- 数据来源是否仍有效；
- 指标、价格、政策和模板是否过期；
- Plugin 权限是否还真的需要；
- 输出格式是否仍适合受众；
- 哪些错误反复出现；
- 是否需要增加或删除人工审核点；
- 定时任务失败时会不会明确通知你。
建议给工作流记上版本号和验证日期。否则团队里有人还在用旧规则跑了两个月，等你发现的时候数据已经对不上了。
常见失败
聊几个我亲身经历和见过的坑：
第一次成功就急着全自动跑起来
第一次顺利很可能只是样本简单。至少把正常、缺失、越界三种情况都测一圈再上线。这个坑我一共踩了两次才长记性。
把真实业务内容写进了 Skill
Skill 存的是方法和模板。具体的客户名、数字、项目资料，放在当前项目或任务里。混在一起的问题在于：下次换一个客户，Skill 就废了。
自动化以后没人复核了
自动化帮你省掉的是重复劳动，不是把责任也省掉了。对外成品和高风险动作，最终确认的那个人还是你。没有这一步，出问题只是时间问题。
用一个超大流程处理所有场景
周报、PPT、邮件和数据更新，这些可以共享同一个事实底稿。但各自的输出和验收步骤应该独立。一个流程管所有事，调试的时候你会恨自己的。
完成门槛
动手之前，先拿这个清单对照一下自己做到哪了：
- [ ] 已手动完成并检查同类任务至少三次。
- [ ] 输入、步骤、输出、检查和停止点都有记录。
- [ ] 选择了最小够用的复用方式。
- [ ] Skill 或模板没有写入真实敏感业务内容。
- [ ] 正常、缺失和越界样本均测试。
- [ ] 定时任务只生成可审核结果，不擅自对外执行。
- [ ] 有负责人和定期更新日期。
下一步
这套方法说完了，接下来就是动手。去 Codex 技巧与场景实战 挑一个你手头实际的任务——PPT、电商、漫剧、办公文件、研究还是数据——把上面的流程走一遍。第一次可能慢一点，但第二次你就会感谢自己。