DAY 03 · 让 AI 手动跑出第一版

今天第一次执行完整任务，但仍然不做自动化。你需要看清 AI 在哪里理解正确、在哪里需要追问、哪里会产生返工。过早自动化只会把这些问题更快地重复。

完成后的结果

今天结束时应保存三样东西：第一版真实输出、执行过程中的确认记录、失败点与返工记录。不要只保留最后那个看起来最好的版本。

第一步：建立本次运行目录

为第一次执行保留证据：

my-first-workflow/
├── TASK.md
├── runs/
│   └── 001/
│       ├── input.md
│       ├── plan.md
│       ├── output-v1.md
│       └── issues.md

把昨天验证过的真实输入复制到 runs/001/input.md。不要直接覆盖原文件；以后需要对比第二次运行。

第二步：执行前先复述，不要直接生成

把 TASK.md 和本次输入交给 AI：

先检查必填输入，再用五条以内复述任务目标、输出结构、完成标准、风险和执行计划。把结果写成 plan.md。此时不要生成最终输出；发现缺失时只提问。

你只检查三件事：

1. 它理解的结果是不是你定义的那个结果；
2. 它是否把边界外的动作加了回来；
3. 它是否发现真实输入里的缺口。

如果复述错误，先修改 TASK.md 或输入，不要用一段临时聊天把它“教会”。工作流要让下一次也能理解。

第三步：确认计划后生成第一版

计划正确后再给出明确确认：

计划确认。现在只生成输出契约规定的内容，保存为 output-v1.md。任何无法从输入验证的事实都放入“待人工确认”，不得补造。

在合成示例中，第一版草稿可能出现这样的结果：

## 草稿
现在可以把数据导出成 CSV。独立开发者可以直接带到自己的分析工具中继续处理，不再被固定报表限制。

## 事实依据
- 支持 CSV 导出 → input.md 第 2 段

## 待人工确认
- “不再被固定报表限制”是价值解释，需确认是否符合产品定位。

这不一定是最终文案，但已经可以依据契约检查。

第四步：逐项验收，不要凭整体感觉

把 Day 2 的完成标准逐条复制到 issues.md，记录结果：

# 第一次运行问题记录

| 检查项 | 通过/失败 | 证据 | 只需返工什么 |
| --- | --- | --- | --- |
| 不超过 280 字 | 通过 | 116 字 | — |
| 事实来自输入 | 通过 | 对应 input.md 第 2 段 | — |
| 价值符合定位 | 待确认 | 输入未给定位边界 | 补充目标受众约束 |

失败时只返工失败部分。若事实依据正确，就不要让 AI 重写全部内容，以免引入新的错误。

第五步：只做一次有记录的返工

使用这种格式提出返工：

检查项【名称】未通过，证据是【具体问题】。保持其余已通过部分不变，只修改【范围】；修改后重新报告该检查项是否通过。

把返工后的版本保存为 output-v2.md，并在 issues.md 记录改变了什么。若连续两次仍失败，先停止，检查任务卡是否缺少规则，不要无限续写提示词。

第六步：区分三类问题

今天发现的问题放进三类：

• 输入问题：真实材料缺字段、格式混乱或含不必要隐私；
• 规则问题：TASK.md 没写清默认值、边界或完成标准；
• 执行问题：规则已经明确，但本次仍未遵守。

前两类应该修文件，第三类才适合在后面的工作流步骤或检查清单里增加约束。

常见错误与修正

只保存最终成品。 没有第一版和问题记录，Day 4 就无法知道哪些步骤值得固定。

边聊边补十几条要求。 把稳定要求写回 TASK.md；一次性的本次信息写回 input.md。

一失败就全部重做。 全量重写会破坏已经通过的部分。记录失败项并局部返工。

急着接 API 或自动发布。 今天的目标是看清过程，不是隐藏过程。

今日练习与验收

确认 runs/001/ 中至少有真实输入、执行计划、第一版输出和问题记录。然后回答：

1. 第一次输出最先失败在哪一条标准？
2. 失败属于输入、规则还是执行问题？
3. 你修改了哪个文件，而不是只在聊天里补充？
4. 最终版本是否通过了同一套标准？

能用文件回答这些问题，就完成 Day 3。明天会把今天真正有效的步骤写成 WORKFLOW.md。