我不想再维护一套项目管理系统了：让 Codex 和 Claude Code 自己长出项目脉络
我最近越来越不想把开发过程重新抄进一个看板里，所以这次决定把项目进度做成一层 AI 驱动的“项目脉络”：从 Codex 和 Claude Code 的真实迭代里长出来，再经过人工确认，最后推到 AiTool-content 对外公开。
这几天我有一个越来越强的厌烦感：功能明明是在 Codex 和 Claude Code 里一点点被做出来的，最后却还要我再手工把过程抄进另一套项目管理工具。
那套动作我不是不会做，只是越来越觉得它不诚实。
真正发生过的东西在：
- prompt
- agent 回答
- 改动过的文件
- 验证有没有通过
- 哪一步卡住了
结果我还要再回头补一层“人工翻译过的任务系统”，最后常常只剩下两个结局：
- 要么我懒得补，于是项目进度失真。
- 要么我硬着头皮补，于是我在维护第二套世界。
我不想再造一套传统项目管理模块了。更对的方向是：让项目进度直接从 Codex / Claude Code 的真实工作流里长出来，再经过我确认，最后沉淀成可公开的内容。
我这次真正想解决的，不是“记任务”，而是“记脉络”#
传统项目管理工具最擅长的是：
- 建卡片
- 拖状态
- 记截止时间
- 分配协作者
这些事本身没错，但它们不等于我现在最需要的东西。
我现在更在意的是另一类问题：
- 这个功能为什么突然值得做了？
- 我到底改过几轮判断？
- 哪些 prompt 只是试探，哪些已经变成稳定方向？
- 哪一次修改是真正把事情推过去了？
- 哪些过程值得以后公开写出来？
换句话说，我要的不是一个“任务列表”，而是一条项目脉络。
我最后决定把这件事拆成三层#
我不准备再开一个新系统，而是直接复用我现在已经在用的三套东西：
EvoMap Farmer：负责私有采集、AI 提炼、线程记忆AiTool-content：负责公开内容落盘AiTool：负责网站呈现
这三层一旦接起来，事情就顺了。
为什么“今日工作收件箱”很重要，但它不能单独扛完整件事#
我现在的 今日工作收件箱 已经很接近这个方向了。
它擅长做三件事：
- 导入当天的 Codex / Claude Code 工作痕迹
- 用 AI 把这些内容提炼成“候选”
- 让我在真正写出外部内容之前，先做一次人工确认
所以它天然适合做入口。
但它还不适合单独做“长期项目进度管理”，原因也很直接：
- 它偏当天
- 它偏候选
- 它偏审阅
而项目脉络需要的是：
- 跨天
- 跨轮
- 跨 agent
- 能持续追踪同一个功能主题
所以收件箱可以是门口，但不能是整栋楼。
我准备新增的核心对象，其实只有两个#
老实说，我最怕的是把这件事一想大，就又开始长出一堆概念。
所以我这次强行收住，只加两个对象。
1. project_thread#
这不是任务卡，而是一条功能线程。
它记录的不是“要做什么”，而是“这件事现在推进到了哪、为什么这么推进”。
我现在想让它至少有这些字段：
| 字段 | 含义 |
|---|---|
thread_id | 稳定线程 ID |
project | 属于哪个项目 |
topic | 这条线程在讲哪个功能/方向 |
current_goal | 当前这轮真正想完成什么 |
status | 当前状态 |
latest_summary | 最近一次推进的阶段总结 |
key_decisions | 关键判断，不是流水账 |
open_questions | 还没解决的问题 |
next_prompt | 下一条最合理的 agent 提示词 |
publish_ready | 是否值得转成公开内容 |
这里最关键的一点是：线程不是按仓库建，也不是按 prompt 建，而是按“一个稳定主题”建。
比如：
- 统一工作台简化
- 积分实时刷新修复
- 项目脉络 AI 化
这样才真的有回看价值。
2. public_note_draft#
这个对象的职责就单纯很多：
- 从
project_thread里抽一段可公开的阶段结果 - 填成一篇 Markdown 草稿
- 放进
AiTool-content
它不是原始记录，也不是内部 thread，只是准备拿出去说的话。
它跟传统项目管理最大的区别是什么#
我专门把这件事想了一遍，差别其实很大。
| 传统 PM | 我这次想做的 |
|---|---|
| 人先建卡 | 工作先真实发生 |
| 人再更新状态 | AI 先识别阶段，再由人确认 |
| 目标是协作排期 | 目标是保留真实迭代脉络 |
| 内容偏“任务” | 内容偏“判断、变化、阻塞、下一步” |
| 很容易空转 | 必须绑定真实 prompt / 文件改动 / 验证结果 |
说白了，我不是想把 AI 塞进项目管理，而是想让项目进度直接从 AI 工作流里生出来。
我最在意的一条边界：私有证据，不等于公开内容#
这一层边界如果不提前想清楚，后面一定会翻车。
因为真实工作流里会有很多不适合直接公开的东西：
- 原始 prompt
- 私有路径
- 暂时错误的判断
- 凭证、配置、环境信息
- 还没整理过的碎片推演
所以我现在把边界划成三层：
activity：私有证据，只在本地保存project_thread：内部结构化脉络，可复用但不直接外发AiTool-content：真正对外的成品
为什么我最终决定把公开输出放到 AiTool-content#
这件事我没有重新发明任何新轮子。
因为我已经有了一个非常合适的公开出口：
- 内容只写 Markdown
- 模板和规则已经有了
- 网站读取也已经通了
draft可以天然作为“公开前草稿状态”
这意味着我根本不需要再做一个“发布后台”。
更省力的方式是：
- 先在
EvoMap Farmer里确认一条 thread 值得公开 - 生成一份
public_note_draft - 直接写到
AiTool-content/posts/ - 如果我还想再润一下，就先留着
- 改好之后再正式发出去
这一步最重要的价值是：公开内容和内部过程终于不再脱节。
这套东西落地时，我准备怎么分阶段#
我不打算一口气把它做大。
V1：先从“今日工作收件箱”长出来#
第一步只做这些：
- 新增
project_progress这种 insight 类型 - 在收件箱里增加“项目脉络候选”
- 人工确认后更新
project_thread - 同时生成
AiTool-content的 Markdown 草稿
这一步只解决一件事：
让项目进度不再靠我手抄，而是能从真实 agent 迭代里自己长出来。
V2：再补一个轻量的“项目脉络”页#
到第二步再做长期视图：
- 看到每个项目当前活跃线程
- 看到每条线程的最近推进
- 看到阻塞和下一条 prompt
- 看到哪些线程已经适合写公开内容
它不是看板，更像一面“当前脑内地图”。
V3：最后再让网站前台形成系列感#
等 AiTool-content 的文章积累到一定程度，再考虑：
- 给
/notes增加项目聚合页 - 给同一个 thread 的文章形成 series
- 把“开发迭代”真正变成一个可长期阅读的公开入口
这件事对我来说，真正舒服的地方在哪里#
不是因为它更“高级”，而是因为它终于比较顺手。
我现在越来越确定一件事：
如果一个系统要求我把已经发生过的思考再录入一遍，它迟早会烂掉。
我想要的是另一种感觉：
- 做事的时候，就已经在留下证据
- 证据会被收成 thread
- thread 会变成公开记录
- 公开记录反过来又成为我的长期资产
这样项目、内容、个人表达才会真正连起来。
不是今天为了写一篇文章，硬从工作里抽点东西出来；而是工作本身就带着可以被整理、被回看、被公开的结构。
我给自己留的下一步#
接下来我会先把这件事收得很窄：
- 先在
EvoMap Farmer里补project_progress - 让“今日工作收件箱”先长出“项目脉络候选”
- 把第一批公开草稿直接写进
AiTool-content
我真正想看到的，不是多一个系统，而是一个更自然的闭环：
我在 Codex 和 Claude Code 里推进项目，项目脉络自己被记住，最后再从这个口子安静地流到网站上。
如果这条路走通了，我以后公开写出来的，就不只是结果，而是我这个人这些年是怎么一点点把自己的开发方法长出来的。