为什么代码和内容共用一套交付闭环

所属项目： 个人 AI 助理

前段时间，我给开发协作和内容生产各写了一套流程。

开发那边有需求、设计、任务拆解、测试和部署；内容那边有选题、发布包、图卡、预览和发布。看上去分得很清楚。

真正跑起来后，我发现两套流程里反复出现同一类规则：需求放哪里、过程怎么记、什么时候提交、如何验证、做完后留下什么。两边各写一遍，短期没问题，时间一长就会开始不一致。

这次我把这些重复部分抽成了一份公共规则。不是想把写文章变成软件工程，而是想让不同类型的工作，至少有一个相同的交付底座。

两类工作，最后都会卡在“做完之后”

一个功能做完，可能代码已经在仓库里，但没有写清楚验证方式；一篇内容做完，可能图片已经发了，但最终正文和发布链接没被记录。

这类问题在没有 AI 时也存在。AI 参与之后会更明显：它让修改速度变快，版本变多，聊天里很快堆满实现、解释、备选方案和临时结论。

如果没有固定落点，最常见的结果不是完全丢失，而是下次要继续时，得花不少时间重新拼上下文。

所以我抽出的公共流程只回答六个问题：

1. 这件事为什么做，交付什么？
2. 过程里哪些判断值得留下？
3. 在什么节点留一个可回看的版本？
4. 用什么方式证明它真的完成了？
5. 最终产物、链接和使用方式在哪里？
6. 下一次遇到类似事情，什么经验可以直接复用？

现在，所有需要持续推进、留痕或验收的工作，都先在 workspace 根目录建一份唯一的 REQ：

REQS/2026-08-06-short-slug/
└── README.md

它不是素材目录，也不取代项目里的代码、文章或图片。它只承担需求档案的角色。

README 的固定结构是：需求分类、背景、设计方案、执行记录、交付产物、复盘总结。

这种分工能避免一个常见混乱：项目里既有一份 REQ，workspace 根目录又有一份 REQ，两边写着不同的进度。现在正式档案只认根目录那份；项目里保留项目真正需要的东西，例如源码、内容稿、发布素材包和输出文件。

每次 REQ 还会绑定一个 req_id。它和目录同名，方便把当前会话、阶段提交和之后的成本或过程统计串起来。不是所有人都需要这层，但对一个会持续迭代的个人系统来说，能追溯总比靠记忆好。

公共规则规定了几个阶段：

立项 → 关键留痕 → 阶段提交 → 最小验证 → 交付 → 复盘

它不规定每一阶段具体做什么。

开发任务进入 coding 的专业流程：先看影响范围，必要时拆任务；用测试、类型检查、构建或运行结果验证；上线前后再做对应核验。

内容任务进入 40toretire-social 的专业流程：先登记选题和事实边界；建立发布包；生成图卡和手机预览；得到确认后再把标题、正文和单张图片投递到发布群；最终发布仍由人在 App 里完成。

这也是我觉得它们能共用底座、却不能互相替代的原因。内容不该被要求写单元测试，开发也不该被要求做图卡预览；但两边都需要清楚地知道自己交付了什么，以及凭什么说交付完成。

另一个容易重复的规则是 commit。

我不想因为“有流程”就让每个中间文件都提交一次。公共规则只要求在可运行、可预览或可复核的阶段留版本。

对内容来说，比较自然的节点是：发布包骨架、可预览版本、确认后的定稿；对代码来说，可能是功能能运行、测试通过、部署完成。

commit 之后，把标识记回 REQ。以后看一份档案，就能找到对应的代码或内容版本；看一次提交，也能知道它属于哪件事。

我想减少的不是步骤，而是重复猜测。

当 AI 参与的工作变多，最贵的往往不是写出第一版，而是几天后再回来时，重新弄清楚：当时为什么这样决定？哪一版是真的？有没有验证过？接下来该做什么？

公共生命周期不能回答所有问题，但它把这些基础问题固定下来。剩下的空间，留给代码、内容和每一次具体判断。

规则以后还会改。真正有用的部分会留下，只有仪式感的部分应该删掉。先让它跑起来，再看它能不能让下一次工作轻一点。

还在路上，先记下来。