先确认输入，再对照完整交付物
下面保留了原始材料、逐项结果和完整报告。先独立处理输入，再用参考结果检查遗漏与分歧。
页面展示原创合成文章与参考草稿；本轮没有连接 Typefully、写入草稿、排期或发布。
本站原创合成材料。先看输入独立练习，再切换参考结果对照。
原始长文
# 先把结果定义清楚，再安排自动化 作者：shancha｜合成练习文章｜2026-10-17 [F01] 本次练习使用 8 封合成邮件，涉及需求确认、等待反馈、账单、收据、订阅、资料和上下文不足的询问。它们不来自生产邮箱。 [F02] 分类规则采用 6 个业务标签，并用 Review 留下需要人工判断的例外。一封邮件在本流程中只选一个主标签。 [F03] 练习交付包含一张分类表、两份回复草稿和一页每日简报。草稿只展示在练习页面，没有写入 Gmail，也没有发送。 [F04] 会议时间、报价和交付日期没有得到确认时，回复只能说明待核对，不能替用户承诺。 [F05] 建议先用少量样例验证规则，再单独核对真实邮箱中的工具能力和写入范围，最后才考虑保存 Skill 或设置 Routine。 [F06] 这次没有测量节省时间、分类准确率或收入变化；真实邮箱自动化尚未验证。不能从练习结果推导效率提升数字。 这篇文章希望传达的是一种工作顺序：先确定交付物和验收条件，把不确定的信息留下来，然后再决定哪部分值得重复运行。内容改写也沿用这条原则：每个具体判断都能追到原文，排期与发布由作者决定。
编辑要求
渠道：X 串文 5 条、LinkedIn 1 篇。 语气：具体、克制，保留“合成练习”和“尚未实测”。 每条草稿附来源编号；未知的效果数字不补写。 本轮只在文件中交付，发布动作留给作者。
按本篇规则编写的完整参考结果，未写入第三方服务。表格较宽，可左右滑动查看。
| 草稿 | 渠道 | 事实依据 | 参考正文 |
|---|---|---|---|
| X-1 | X 串文 | F01 F03 F06 | 1/ 我用 8 封合成邮件练习了一套收件箱整理流程：先定义分类规则，再看分类表、回复草稿和每日简报。这里分享练习方法，真实邮箱流程仍待验证。 |
| X-2 | X 串文 | F02 | 2/ 规则是 6 个业务标签，再加 Review 处理不确定项。上下文不够时，先留下问题；一封邮件只选一个本流程主标签。 |
| X-3 | X 串文 | F03 F04 | 3/ 这组样例有两份回复草稿。会议时间、报价和交付日期尚未确定时，草稿只说明待核对，保留给人做决定。 |
| X-4 | X 串文 | F05 | 4/ 下一步的顺序：样例校准 → 核对真实连接能力 → 小批试跑 → 验收后保存 Skill → 再考虑 Routine。每个阶段单独看结果。 |
| X-5 | X 串文 | F06 | 5/ 本次没有测量节省时间或准确率，也没有写入真实 Gmail。先把输入、预期结果和例外说清楚，再判断自动化是否值得继续。 |
| LI-01 | F01—F06 | 这次用 8 封合成邮件做了一个流程练习，重点放在“交付物是否说得清楚”。 输出是一张分类表、两份回复草稿和一页每日简报。6 个业务标签之外，保留 Review 处理上下文不足的邮件。 我特别关注两件事：一是每条判断能回到原邮件，二是未知的时间、报价和交付日期不会被草稿擅自确认。 练习之后，仍需要核对真实 Gmail 连接能力、小批试跑与人工验收，才能讨论 Skill 和 Routine。本次未测量节省时间或准确率，也没有写入真实邮箱。 你的重复工作里，哪一份交付物最值得先定义清楚？ |
当前页面和下载包中的文字是参考答案，没有对应的 Typefully draft_id。
JSON 样例仅包含内容、标题和 share: false；publish_at、plan_at 等排期字段均省略。
审稿摘要｜合成样例 输入：1 篇文章，F01—F06。 交付：X 串文 5 条、LinkedIn 1 篇。 来源：具体数字均来自原文；保留合成练习与未验证限制。 待你确认：语气、目标账号、链接、平台长度与格式。 未完成：真实草稿写入、排期、发布与发布后数据。 任何“提升效率 XX%”之类原文没有的数字，都应退回修改。
把材料与工具准备清楚
先在文件里改写
- 下载原文与编辑要求，第一次不看参考草稿。
- 选定两个目标渠道，并准备自己允许参考的语气样例。
- 把不可改动的数字、日期、结论与限定语单独列出。
接入 Typefully 前
- 确认自己的 social set 与 X、LinkedIn 账号。
- 核对实际可用的草稿创建、读取与发布工具。
- API 密钥通过安全输入提供，先验证连接，不在提示词或下载文件中填入密钥。
先用下面的材料和指令完成一次文件练习。接入自己的服务时，核对实际账号、可用工具与操作范围，再按每步的检查点继续。
先下载原始材料与规则 ↓执行与接管边界
以下动作以已约定的输入、账号和范围为前提；设置 Routine 不会扩大授权范围。
可自动执行
只依据已提供文章生成分渠道本地草稿和事实对照表，不新增效果数据。
需要确认
写入 Typefully 前确认 social set、平台账号与正文；排期、分享和发布分别确认。
失败后接管
保存超时先按账号与 draft_id 查重，暂停后续写入；无保存能力时交付文件，意外排期由你检查并处理。
先提取事实，保留原文的限定语
把这篇文章当作唯一事实来源。先做 F01—F06 对照表，区分已经发生的样例练习、对后续流程的建议，以及尚未测量的效果。
“两份草稿”不能变成“两封已发送邮件”；合成练习也不能改成真实客户案例。先核对这些边界，再进入文案改写。
只读 source-article.md。输出事实清单：编号、原文依据、类型（样例事实/建议/未验证）、可用于文案的表达、必须保留的限定语。不得补查外部数据，不改写成真实邮箱实测，不生成节省时间或准确率数字。先交付 facts.md。一张可回查到 F01—F06 的事实清单，明确没有生产邮箱实测。
数字 8、6、2 的含义没有变化；F06 里的未测量信息仍然存在。
把渠道、读者和语气写成编辑要求
同一事实可以用不同结构表达：X 串文每条只讲一个要点；LinkedIn 用完整段落交代背景、方法和问题。
本练习不要求复用平台界面，也不写死每个平台的最新限制。发布前在当前编辑器核对字数、链接、分段和预览。
根据 editorial-brief.json 和 facts.md，写出两种内容大纲：X 5 条串文、LinkedIn 1 篇。每段标事实编号。语气具体克制；第一段交代是合成练习。先展示大纲，不连接账号，不排期。两份结构不同、事实一致的大纲。
原文里的“建议”没有升级为“已经实现”，每个段落都有来源编号。
生成草稿，再逐条做事实与语气审阅
把一次完整的改写分成生成和审阅两轮。审阅时先看内容是否准确，再看有没有重复、夸张、无法理解的缩写或突然改变的口吻。
参考草稿是一种可用答案。你可以调整开头、结尾和叙述顺序，但不能改变样例状态或凭空增加业务结果。
按已确认大纲生成 X 串文和 LinkedIn 草稿。正文之外附“草稿 id → 事实编号”表。再独立检查：新增数字、遗漏的限定语、把计划写成完成、重复论点、未经确认的承诺。发现问题直接修订，并列出改动。只写 drafts.md。5 条 X 文本、1 篇 LinkedIn 文本和事实对照表。
每条具体判断均能回到原文；两个版本都保留合成练习和未验证范围。
先核对账号与工具，再准备草稿请求
Typefully 官方 API 说明支持 X 与 LinkedIn 的内容草稿。这里提供的 draft-payload.json 是按已公开字段编写的请求体样例，未执行。
确认 social set、平台账号和请求范围后，才允许创建草稿。样例省略发布与排期字段，share 为 false；正式使用前仍需对照当时的 API 和账号能力。
先只读检查我的 Typefully 连接与目标 social set：<填写>，列出对应的 X、LinkedIn 账号以及可用工具。检查 draft-payload.json 只用于创建普通草稿：没有 publish_at、plan_at 或即时发布参数，share 为 false。仅展示核对结果和拟执行请求，不调用写入工具。密钥不得回显。可核对的目标账号清单与请求预览。
没有把社交账号显示名当作唯一身份；不包含排期、即时发布或公开分享参数。
只保存明确批准的草稿，并回读验证
你确认正文和账号后，先保存一个草稿检查格式。成功创建应有实际返回的 draft_id，再回读标题、平台、正文和状态。
请求超时不代表创建失败。先查已经出现的草稿，再决定是否重试。页面里的参考答案不能当成账号里已经创建成功的证据。
只在我确认具体账号与请求后，创建这一个普通草稿；不排期、不发布、不生成公开分享链接。记录返回的 draft_id 并回读核对正文、平台和草稿状态。工具不可用则保留文件，写明未写入。结果不明时先查重，不重复创建，不覆盖已有草稿。实际草稿 id 与回读结果，或明确的未写入说明。
平台和账号正确，内容没有丢段；状态仍为草稿，没有发布记录。
保存改写方法，发布作为独立决策
验收后可以把原文要求、事实表、改写结构和审阅规则存为 Skill。每篇新文章都要重新建立事实清单，不沿用旧样例的数字。
发布或排期需要你再次确认具体内容、渠道和时间。可以先把时间建议写在文档里，不把建议直接变成平台任务。
把验收后的改写方法写成 content-repurpose Skill：输入原文与编辑要求，提取事实，生成渠道大纲，改写，自查，交付草稿与来源表。写入 Typefully、公开分享、排期和发布都是独立阶段，默认停在本地文件。不创建定时发布任务，不跨 Bot 委派。一份能用于新文章的 Skill 草案和人工审稿清单。
下一篇换输入后仍先核对事实；没有自动继承旧账号、时间或发布授权。
卡住时先看证据，再决定下一步
改写里突然出现效率提升数字
退回事实表逐句核对。原文未测量的效果只写未测量，不能由模型补出。
X 串文最后一条缺少上下文
检查每条是否能独立理解，第一条明确练习范围，必要限定语在相关条目重复保留。
草稿保存失败或超时
先查目标账号是否已经创建，核对 draft_id。权限或套餐不支持时保留文件，不重复发送创建请求。
保存后变成排期内容
检查请求字段与工具行为，停止继续写入。先由你核查平台状态，再处理；不要用一次“存草稿”确认推导发布授权。
平台预览和本地文本不一致
在实际编辑器核对链接、分段、长度和媒体，先人工修订；本页没有验证平台最终渲染。
完成前，逐项核对
勾选用于本次自查，刷新后重置；不代表真实服务已经通过验证。
已核对 0 / 6 项
原始输入与参考答案分开下载
第一次先交原始材料和规则，不提前提供参考答案。验收后，再下载报告与全部提示词保存。
把官方能力与练习结果分别核对
内容更新日期： · 修改页面不等于重新核验资料或实操。
资料核验：未核验 · 暂无核验日期
尚无本案例单独核验官方资料的记录；下列来源供复核，不能视为已核验。
实操核验：未核验
未核验真实账号、外部工具写入、定时执行或长期运行效果；合成练习与页面自查不能替代实操核验。
页面展示原创合成文章与参考草稿；本轮没有连接 Typefully、写入草稿、排期或发布。
- Typefully API 官方概览 ↗
支持的平台、认证与草稿工作流；本页未调用 API。
- Typefully API 参考 ↗
字段参考公开的创建草稿说明；未验证全部端点，也未执行创建与回读。
- Grok Bot：应用与共享电脑 ↗
核对连接方式、可见范围与账号内共享状态。
- Grok Bot：Skills 与 Routines ↗
先验证一次手动任务，再保存与安排重复运行。