一人AI公司的多项目管理体系与组织过程资产建设——从"每次翻目录"到"一行指针进项目"

日期: 2026-09-28 | 读者档: 内部决策 | 方法: 多轮检索(3轮递进)+ 本工作区实测盘点

关键词: 一人公司 · 多项目管理 · 组织过程资产 · AGENTS.md · 项目台账 · 知识库 · 上下文工程 · AI数字员工

研究摘要

核心结论前置(6 条):

1. 定位成本是当前最大的隐性开销,且是结构性缺口。 本工作区 7 个项目 7/7 无 AGENTS.md、7/7 无 README,根 AGENTS.md 的硬规则"派单前必读目标项目 AGENTS.md"指向一个全仓 0 命中的载体;台账\ 6 个文件全是横向台账,无"每个项目一行"的登记册。每次派单靠 CIO 临时翻目录。
2. 切换成本的大头不在"真正切换"。 LaPlume et al. 2022 分解:单次切换总代价 576ms(较单任务 +108%),其中"保持可切换准备态" 219ms + "读线索决定任务" 148ms 合计 367ms,约为真正执行切换(183ms)的两倍。减少切换次数与切换前的定位动作,比优化切换本身值钱。
3. 方法论不缺,缺实例。 PMBOK 的 OPA 早已把"项目元信息登记什么"定义清楚(过程政策类 + 知识库类),AGENTS.md 已成开放标准(LF AAIF 托管、6 万+ 仓库、就近优先裁决)。本工作区缺的不是框架,是 7 个项目的实例与一张台账。
4. 多项目并行的可行解是轮转,不是均摊。 社区共识 [轶事级]:周可用工时 <20 小时活跃项目上限 2 个;3 个并行需其一进入维护态。组合登记册 14 字段是防腐底线,但必须裁剪到 8 字段并把 roll-up 规则与列组 owner 书面化,否则"绿色组合由琥珀色项目堆成"会自然发生。
5. 项目级 AGENTS.md 越全越贵,必须精简。 AGENTBENCH 实测:上下文文件使 agent 步数 +2.453.92、成本 **+2023%**,且"context file 提供的 codebase overview 并不有效"。精简常驻 + 情境化知识下沉 skills 是唯一划算口径。
6. 本工作区动作收敛为三件套: ①建 项目\项目台账.md(8 字段);②给 7 个项目补精简版 AGENTS.md;③根 AGENTS.md 加一行指向台账,形成"一行指针进项目"的切换 SOP。衔接现有 CIO 章程与任务卡机制,不推倒重来。最大单项差距是 dev 未接入 thinking kb(无 kb.db、无路由行)。

01 现状诊断:多项目切换的定位成本

1.1 本工作区六条实测信号(2026-09-28 本机盘点)

1.2 切换的实证代价:翻目录不是"小事"

Mark et al. (CHI 2005) 对 24 名信息工作者的观察:工作高度碎片化,57% 的工作片段被打断,平均活动切换间隔 3 分 5 秒;同日恢复被中断工作平均需 25 分 26 秒,且恢复前平均已插入 2.26 个其他工作片段。Mark, Gudith & Klocke (CHI 2008) 进一步发现:被打断的任务反而完成更快、质量无差异,但压力、挫败感、时间压力与努力程度显著更高——代价不体现在产出速度,体现在人与 agent 的状态损耗。

• 57% 工作片段被打断的比例(来源:Mark et al., CHI 2005)
• 25分26秒 同日恢复被中断工作的平均耗时(来源:Mark et al., CHI 2005)
• 3分5秒 平均活动切换间隔(来源:Mark et al., CHI 2005)

"23 分 15 秒"是误引,本报告不使用。 核查 21 篇引用该数的博文(oberien's Blog),原始论文《The Cost of Interrupted Work》中从未出现"23";该研究的实际结论是被打断任务用时反而更短、压力显著更高。数字仅见于 Gloria Mark 的三次访谈与 WSJ 报道。有出处的两个数是:Mark 2005 的 25 分 26 秒,以及 Iqbal & Horvitz 的 11–16 分钟解决中断。

核心结论: 切换成本的大头发生在并未真正切换的准备与判读阶段:保持准备态 219ms + 读线索决定任务 148ms 合计 367ms,约为真正执行切换(183ms)的两倍——减少切换与切换前的定位动作,比优化切换本身值钱。

单次切换总代价 576ms 的构成说明:准备与判读阶段(219ms + 148ms)合计 367ms,约为真正切换(183ms)的两倍。套到本工作区:每次派单前的"翻目录、找任务卡、确认技术栈"正是那 367ms 的放大版——定位动作未完成,真正的工作根本没开始。

1.3 无台账时的三种典型失败模式

无项目元信息载体的三种失败模式

• 反复重问 每次派单让 AI 员工重新确认技术栈/部署方式/当前阶段,同样的问题在不同会话重复消耗 token 与等待时间。
• 静默幻觉 无载体可查时,模型按训练先验补全"该项目大概是什么形态",写进任务卡后成为错误指令源。
• 越级考古 为定位一个项目翻 16 张任务卡 + 20 份交付报告,过程资产越丰富反而越难入口,违反"产出物归集"的初衷。

核心结论: 本工作区的切换成本不是"习惯问题",是载体缺失——硬规则指向 0 个文件,元信息无处登记,知识库零路由。补载体是纯工程问题,不需要新方法论。

02 理论与业界基线:OPA 与项目级上下文

2.1 组织过程资产(OPA):经典答案早已存在

PMBOK 将 OPA 定义为"执行组织所特有并使用的计划、过程、政策、程序和知识库",是多数项目管理过程的输入,分两大类:①过程、政策和程序(指南/标准、模板、变更控制程序、财务控制程序、问题与缺陷管理程序、收尾要求、风险管理框架、沟通要求);②组织知识库(配置管理库、财务数据库、历史信息与经验教训库、项目档案、测试评估数据库)。更新口径明确:第一类通常不属项目工作、由 PMO 或职能部门维护;第二类在整个项目期间随项目信息持续更新。OPA 与事业环境因素(EEF)的分界在于:OPA 源于组织内部,EEF 源于外部、团队不可控。

软件过程领域有同名概念:CMMI 把 OPA 定义为"描述、实现与改进过程的工件",其 OPD 实践要求建立**过程资产库(PAL)**跨项目共享最佳实践与经验教训。[未核实] ISO 21500:2021 术语表是否仍收录 "organizational process assets",本轮检索未直接抓到该条目。

2.2 知识管理理论:为什么"存了却用不上"

知识管理四条主干

• SECI 四模式 Nonaka:社会化(隐→隐)、外化(隐→显)、组合(显→显)、内化(显→隐);知识经"知识螺旋"上升,需与 ba(共享情境)、知识资产互动。外化(隐→显)正是一人公司最缺、也最该被载体承接的一步。
• Alavi & Leidner 四环节 KM 过程视图 = 知识创造、存储/检索、传递、应用。调查显示 74% 受访者认为组织最佳知识不可获取、68% 认为错误被重复犯下——存进去不等于取得到。
• 知识基于观(RBV) 知识嵌入文化、惯例、政策、系统与文档及个体,难模仿、构成持续竞争优势;关键在"应用既有知识创造新知识"的能力,而非知识存量。
• PARA 按可操作性组织 Tiago Forte:Projects / Areas / Resources / Archives 四顶层类目,反对按学科主题归档;组织系统必须"省时间而非耗时间",不与执行工具连接的 PKM 方法终将束之高阁。

2.3 AGENTS.md:项目级上下文的开放标准

• 标准与托管:由 OpenAI Codex、Amp、Google Jules、Cursor、Factory 共同发起,2025-12-09 由 OpenAI 与 Anthropic 捐给 Linux Foundation 旗下 Agentic AI Foundation(AAIF)托管(agents.md 官网);格式无强制字段,纯 Markdown。
• 裁决规则:"离被编辑文件最近的 AGENTS.md 优先,用户显式 prompt 覆盖一切";大 monorepo 用嵌套 AGENTS.md(OpenAI 主仓当时 88 个),每个子包一份,就近生效。层级合并模型 = root + 子目录 + 用户全局三层,具体覆盖通用;.cursorrules / CLAUDE.md / .windsurfrules 可用 symlink 迁到单一真源。
• 采纳规模:6 万+ 开源仓库使用,兼容 Claude Code、Cursor、Copilot、Codex、Gemini CLI、Devin、Windsurf、Amp、Cline、Roo 等;Claude Code 例外,官方变通是写 @AGENTS.md 引入。
• 工程口径:AGENTS.md 应保持精简,过多上下文会劣化模型表现;超出常驻上下文的情境化知识下沉到 Agent Skills(SKILL.md + YAML frontmatter)按需加载。

2.4 上下文工程三层与 IDE 目录级规则

Anthropic《Effective context engineering for AI agents》给出三层:compaction(压缩摘要)、structured note-taking(持久化 NOTES.md / to-do,跨重置续接)、sub-agent 架构(子代理检索只回传 1000–2000 token 精炼摘要);落地模型 = CLAUDE.md 前置加载 + glob/grep 即时检索的混合。原则一句话:找到能最大化期望结果的最小高信号 token 集,上下文是有限注意力预算。

IDE 侧已把"项目级"做成了目录级粒度:Cursor 四类规则(Project .cursor/rules/*.mdc、User、Team、AGENTS.md)按 glob 精确到文件/目录生效;Windsurf 从 workspace 及子目录 .windsurf/rules 自动发现。[轶事级] 用户级全局规则目录长期缺失,Cursor 官方 2025 年答复无全局 rules 目录,变通是 symlink。

核心结论: 理论侧(PMBOK/CMMI)回答了"登记什么",业界侧(AGENTS.md/IDE 规则)回答了"放在哪、谁优先"。对本工作区意味着:直接照抄口径即可,不需要发明框架;唯一要做的是把 7 个项目的实例填进去,并让根 AGENTS.md 的硬规则指向真实载体。

03 多项目并行的管理方法

3.1 WIP 上限:多项目必须每项目单独看板

Atlassian 的 Kanban WIP Limits 口径:"Stop starting, start finishing"。个人层面 WIP 起点可设为 1,多人共享池 1.5–2 张卡/人。多项目必须每个项目单独看板——合并板的总 WIP 上限会掩盖单项目阻塞,所有项目看起来都在动,实际每个都卡着。

边界条件必须写明:WIP 上限在任务大小未标准化时失效(一个任务 1 天、另一个 1 周,限值没有意义);更稳健的替代是把流程第一步作为约束、让下游自动拉取(社区共识,非研究)[部分核实]。

3.2 组合登记册:14 字段与两条防腐规则

最小字段集(Portfolio Hub)= 每行一个项目、14 列:ID / 项目名 / Owner / Sponsor / 战略目标 / 阶段 / RAG / 起止 / 预算 / 已花费 / 完工预测(EAC) / 差异 / 优先级分。两条关键观察:EAC 是多数表格漏掉的一列;战略目标列才是把"项目清单"变成"组合"的那一列。

比字段更重要的是两条防腐规则:

1. roll-up 规则必须书面化,否则"绿色组合由琥珀色项目堆成"会自然发生;
2. 刷新契约:每列组指定 owner / 来源系统 / 更新节奏——"跟踪表腐烂是因为名义上人人有责,实际等于没人负责"。

PMI 口径的状态报告 10 节可作为刷新节奏的骨架:报告头 / 总体 RAG + 分项(每个非绿必须带一行原因和具名恢复动作)/ 给发起人的三句话摘要 / 本期完成 / 下期计划 / 里程碑(基线日期永不变)/ 预算(含 EAC)/ 前五大风险 / 需发起人决策项(带截止日与延误后果)/ 较上期变更。月度必更三件:叙述性回顾、绩效复盘(进度/成本/范围/质量/资源/风险六维)、里程碑三列并置(原定到期日/当前计划到期日/实际交付日)。RAG 定义:绿=按计划,黄=需发起人准备支援,红=已出问题需主动关注。

3.3 多 agent 并行的文件互斥

多 agent 文件互斥的四条纪律

• 一 agent 一 git worktree 每 agent 独立分支 + 工作副本,冲突推迟到合并阶段;Superset 生产环境并行跑 10 个 agent 各占 worktree 各开 PR;Claude Code 原生支持 subagent isolation: "worktree"。
• 承认语义冲突代价 两边各自能编译、合起来坏,文本 merge 检测不出;STORM 论文提出写时状态一致性校验优于事后合并;运维代价 = 每 worktree 重跑依赖、磁盘膨胀、端口冲突、共享同一数据库。
• 爆炸半径纪律 父 agent 不得编辑任何在跑子代理爆炸半径内的文件(barrel export、共享类型、config);无非重叠工作时空转是正确行为。
• 并行数 ≤ 可 review 吞吐 任务有依赖则不可并行;并行数不得超过可及时 review 的能力,否则冲突在合并阶段集中爆发。

3.4 活跃项目数:共识、轮转制与反方口径

• [轶事级] 社区共识:每周可用工时 <20 小时时,活跃项目上限 2 个;3 个并行需要其中一个已进入维护态(Passivebook,明确标注为 Indie Hackers 社区共识而非研究)。
• [轶事级] 反向证据:多产品可行,前提是轮转而非均摊——同一套部署/同一 stack 才能复用上下文、一个产品当期聚焦其余保持稳定、必须有 kill 标准、必须有一张含诚实状态的 portfolio 总览页(Gravam,2026-07-24)。
• [轶事级] 单人跑 10 个 SaaS:2 个真正赚钱、3 个赚零花、5 个基本不赚钱,80% 时间给那 2 个(DEV,2026-02-21)。
• [未核实] Solo founder 口径:管理 1–2 个产品的独立创始人每小时收入是管理 4 个及以上者的 3–5 倍;约 73% 创始人经历 burnout;每次项目间切换损失 15–25 分钟(bradyward.ai,未标注数据源,不可直接引用)。

核心结论: 对本工作区意味着——当期活跃项目压到 2 个、其余进维护态;每项目独立看板(即每项目自己的 任务卡\);登记册只留 8 个字段但 roll-up 规则与列组刷新责任必须写进台账脚注;多 agent 并行沿用文件互斥铁律,worktree 是主方案,语义冲突靠 review 吞吐兜底。

04 知识库与记忆体制:thinking kb 的可复用资产与接入差距

4.1 thinking 四级存储(本机实测,可直接复用)

thinking 四级存储 L0–L4

• L0 章程层 AGENTS.md,硬约束 <200 行,常驻上下文;跨岗位通用。
• L1 岗位层 各岗位 agent.md + .kimi-code\mcp.json + skills,随实例挂载。
• L2 文档层 项目文档按需 Read,不预注入;对应 Anthropic 的"最小高信号 token 集"。
• L3 检索层 kb.db(FTS5 全文索引)+ kb.toml 分类(ideas/notes/summary/tools/gongwen/docs),按需检索。
• L4 冷归档 超期内容出库,防检索噪声(对应 kb 的 TTL 与归档处置)。

实测:thinking 已有 kb.toml + kb.db(FTS5)+ docs\记忆体制.md;研报产线产出落 D:/code/thinking/notes/学习/研报/,台账已登记 13 篇(2026-09-03 至 2026-09-26),本篇为第 14 篇,且是首次以 dev 工作区治理为题。

接入差距(一句话): dev 无 kb.db、无 kb.toml、根 AGENTS.md 无一行指向 thinking kb 的路由。资产在隔壁,路由是零。

4.2 记忆架构两派与 token 账

• A 派·内嵌可编辑块:Letta/MemGPT Memory Blocks 持久化到 DB、可被 agent 自编辑、多 agent 共享 block,2026 年演进为 MemFS + sleep-time dreaming 后台整理。

• B 派·检索式事实库:Mem0 ADD-only 抽取 + 图实体链接,论文报 LoCoMo 92.5、token 成本省 90%+。

• 5,000–20,000 token 无记忆层时每会话重建上下文的成本(来源:PROJECTMEM, arXiv 2606.12329)

• 800–1,500 token MCP 投影紧凑摘要模式的加载成本(来源:同上)

• +90% Mem0 论文报告的 token 节省(来源:arXiv 2504.19413)

PROJECTMEM(arXiv 2606.12329,2026-06)主张 local-first、append-only 纯文本事件日志经 MCP 投影为紧凑摘要——与"台账一行 + 指针"同构:不重建全量,只加载投影。

Cline Memory Bank 是可直接对照的工程模板:6 个分层 markdown(projectbrief → productContext / systemPatterns / techContext → activeContext → progress),"每次任务开始必须读全部文件",上下文将满时执行 update memory bank 落盘再开新会话。六层中,activeContext 与 progress 正是本工作区台账"当前阶段 RAG + 最近进展"要承接的两层。

4.3 "记忆 vs 上下文"的界分

context engineering 管单次推理内放什么;memory engineering 管跨调用/跨会话的持久与可信。OpenAI Agents SDK 的 session 记忆两招:超 max_turns 整轮裁剪 + 旧轮摘要;长期 memory note 按相关性切片注入。学术侧五族划分(上下文内压缩、检索增强存储、反思自改进、分层虚拟上下文、策略化学习管理)已收敛;近饱和 LoCoMo 的模型在多会话任务掉到 40–60%,说明单点高分不等于跨会话可靠。

核心结论: 对本工作区意味着——thinking 的 L0–L4 是现成可复用资产,dev 的差距是"一行路由 + 一个 db 接入",不是"重建一套库"。台账承担 L1 与 L2 的项目切面,kb 接入承担 L3;先补路由,再评估 db 级接入。

05 落地方案:项目台账 + 项目级 AGENTS.md + 快速切入 SOP

5.1 三件套设计(衔接现有 CIO 章程,不推倒重来)

三件套

• ① 项目台账 新建 D:\code\dev\项目\项目台账.md,每项目一行、8 字段(见 5.2)。根 AGENTS.md 加一行指向它。这是"每个项目一行"的组合登记册,dev 工作区的唯一项目元信息入口。
• ② 项目级 AGENTS.md 7 个项目各补一份精简版(见 5.3),只写常驻必需项,情境化知识下沉 skills。补上后,根 AGENTS.md 既有的"项目级 AGENTS.md 必读硬规则"自动由空转变为生效,规则零改动。
• ③ 切换 SOP 一条命令 / 一行指针(见 5.4):台账行 → 该行指针列 → 读目标项目 AGENTS.md → 进入开发状态。CIO 派单前置动作固化为此步。

5.2 台账最小字段:从 14 字段裁到 8 字段

裁掉的 6 列:ID(一行一项目,行号即 ID)、Owner/Sponsor(一人公司恒定)、起止/EAC/差异/预算类财务列(本工作区无预算约束,且是腐烂重灾区)。代价要认:不做财务与差异分析,台账只管定位与健康度,不做投资组合优化。

脚注必须写死两条防腐规则:① roll-up 规则书面化(项目行标黄时,组合不允许整体标绿);② 刷新契约(每列组指定更新时机,"最近进展日期"随每次交付更新,超期即触发复核)。

5.3 项目级 AGENTS.md 精简口径(反方证据必须先读)

AGENTBENCH《Evaluating AGENTS.md》实测:上下文文件平均使 agent 步数 +2.453.92、**成本 +2023%**,且"context file 提供的 codebase overview 并不有效"。结论:不是越全越好,精简才是省钱。

精简口径四条:

1. 常驻只写四件事——一句话目标、技术栈、入口(代码/任务卡/部署)、硬规则指针;行数预算对齐 L0 章程的 <200 行口径,目标 ≤50 行。
2. 情境化知识(领域约定、字段口径、踩坑记录)下沉 skills 按需加载,不进常驻。
3. 冲突裁决交给标准:就近优先,用户显式 prompt 覆盖一切;禁止在项目 AGENTS.md 里重复根章程内容(重复 = 白付 token + 规则打架)。
4. 内容有 TTL:阶段变更即复核,防止项目 AGENTS.md 变成第二份腐烂 wiki。

5.4 切换 SOP:一条命令 / 一行指针

第 1 步  读 D:\code\dev\项目\项目台账.md,按项目名定位那一行
第 2 步  取该行"入口指针"列 → 读 项目\<名>\AGENTS.md(≤50 行)
第 3 步  取"部署方式"与"最近进展日期",据此构造派单上下文
第 4 步  进入 CIO 既有派单流程(硬闸①②照旧,零改动)

四步全部只读、零写入、可在无头派单前完成。"一行指针进项目"的收益不在于省下多少毫秒,在于把定位动作从"翻 16 张任务卡 + 20 份交付报告"降为"读一行 + 读一个 50 行文件"。

核心结论: 对本工作区意味着——三件套的总工作量是 1 个新文件 + 7 份精简 AGENTS.md + 根 AGENTS.md 加一行;根章程的硬规则、任务卡机制、文件互斥铁律全部原样保留,只把规则指向的载体补上。

06 风险与反方观点

6.1 文档腐烂是常态,不是意外

核心结论: 知识从写下到复用的每一环都存在大比例失效:写的时候 65% 说没时间写、维护时 56% 说保持最新最难、放着不动 70% 的过期页有实质错误、该打开时 60% 从未打开、真正被复用的只有 1.3%。

• 抽查 10 页超 6 个月未更新的 wiki,7 页存在实质错误(废弃接口/改名服务/已删流程),且这些页面月均仍有 12 次访问;流程文档半衰期约 6 个月,12 个月后有 75–80% 概率至少一项关键事实已变 [注意:厂商博客自述样本,非同行评审]。
• State of Docs 2025(444 名文档从业者):56% 的 API 团队把"保持文档最新"列为最大挑战,超过写作质量/结构/工具;77% 用自创方式组织文档。
• ICSE 2020(146 名从业者):65% 认为"没有时间写文档"是文档流程问题中唯一被多数人视为重要的项;维护冗余与重复内容占可维护性讨论约 71%。
• IBM 323 名软件工程师两轮调查:文档十大问题中最严重的是不完整、歧义、不正确;过时(obsoleteness)位列 blocker 级。
• Stack Overflow 2025(49,000+ 受访者):"文档糟糕/缺失"自 2018 年起每次都在开发者挫败感前三(二手汇总)[部分核实]。
• [未核实] 中型工程团队每年因"考古式编码"损失 2,000+ 小时、67% 缺乏可靠文档(Replay 博客,营销数据,方法未公开)。

wiki 腐烂是复利反馈环而非纪律问题:搜索持续推旧页 → 读者失去信任 → 作者宁可新建页也不改旧页 → 重复页分裂维护 → 再次腐烂。结构化干预只有一条被验证有效:廉价归档(删除需确定性,归档可逆才真的会发生)。过时文档比没有文档更糟——它制造"权威外观的错误信息",一次误导平均浪费 30–60 分钟。

6.2 PKM 失败实证:存得多不等于用得上

• 中文 PKM 实证:某作者 3127 条笔记中真正回看用上的不超过 40 条,利用率约 1.3%;47 个顶级分类导致"存一篇先想归属"的决策链抵消收益;换 3+ 工具者 70% 时间花在配置/迁移/找插件 [注意:个人经验贴,非统计研究]。
• 卡片笔记在 1600 张规模崩塌:核心卡片反向链接 40+ 条中真正有价值的不超过 5 条;"复杂系统依赖持续维护,高压下维护最先被放弃,熵增快于简单系统"。
• 一名作者删除 7 年/1 万条笔记的"第二大脑",理由是系统"替代了思考"、为归档而阅读、制造延宕;结构≠思考、标签≠洞见。
• Pocket 数据:超 60% 收藏内容从未被打开;Heptabase 第 3 周维护成本上来。
• Karpathy LLM Wiki 讨论的一致归因:人类放弃 wiki 不是因为懒,是 bookkeeping 维护负担增长快于价值;中文 wiki 规模上限比英文更低(英文 100–200 素材,中文可能 60–80 就吃力);幻觉会通过交叉引用复利传播。

6.3 过度工程化反方:治理本身可能是负资产

• AGENTBENCH 成本账:上下文文件使 agent 步数 +2.453.92、成本 +2023%,且 codebase overview 并不有效——给 7 个项目各写一份大而全的 AGENTS.md,是可测量的亏损。精简是硬约束,不是风格偏好。
• WIP 上限的边界条件:任务大小未标准化时限值失效;合并板与单板各有一半道理,解法是"每项目单独看板 + 首步约束",不是照搬一个数字。
• 台账的临界点:8 字段是刻意裁剪的结果。14 字段全上,就复制了"47 个顶级分类"的失败模式——存之前先想归属,决策链抵消收益。
• 本地实证的两面:1.3% 利用率与 1600 张卡片崩塌同样会打向本台账;唯一的解是把"最近进展日期"做成单指标健康度,超期即复核。

6.4 防腐规则(三件套的保险丝)

三件套防腐规则

• 廉价归档 项目结项不删除、直接整行移入归档区;归档可逆才真的会发生,确定性删除永远不会发生。
• 刷新契约 每列组写明更新时机与责任口径;"最近进展日期"随每次交付强制更新,超 14 天未更新自动标黄。
• 指标 唯一健康指标 = 台账行的最近进展日期陈旧度;第二指标 = 各项目 AGENTS.md 行数(>50 行即触发瘦身)。
• roll-up 书面化 任一项目行非绿,组合不允许整体标绿;防止"绿色组合由琥珀色项目堆成"。

核心结论: 对本工作区意味着——台账按"腐烂是常态"设计:8 字段封顶、每列有刷新时机、廉价归档、单一健康指标。任何超出这四条的字段与流程,先过 AGENTBENCH 的成本账再上。

结语

这份诊断可以压成三句话。第一,本工作区的切换成本是载体缺失,不是方法论缺失——7/7 无 AGENTS.md、硬规则指向 0 个文件、6 个台账无项目维度,三条都是可一次性补齐的工程事实。第二,业界答案已经收敛且互相印证:OPA 登记什么、AGENTS.md 放在哪、WIP 与登记册怎么防腐、上下文越全越贵,每一项都有标准或实证支撑,照抄口径即可。第三,落点只有三件套:一张 8 字段台账、7 份精简 AGENTS.md、根章程加一行指针——总改动不触碰 CIO 章程、任务卡机制与文件互斥铁律,风险集中在"台账会不会烂",而防腐规则已经写进方案。要不要开工,是唯一的决策点。

参考文献

1. Organizational Process Assets: Definitions, Examples & Templates, ProjectManager, 2023-11-28。https://www.projectmanager.com/blog/organizational-process-assets
2. 组织过程资产(OPA)构成, yymuse。https://yymuse.com/pm/artifact/organizational-process-assets/
3. 希赛网:PMP 组织过程资产包括哪些内容, 2025-09-11。https://www.educity.cn/pmp/5418875.html
4. PMBOK 2.3 组织过程资产(更新口径)。http://pmp6.chn.ai/chapter/105
5. PMBOK 事业环境因素和组织过程资产(OPA/EEF 分界)。http://pmp6.chn.ai/chapter/1035
6. CMMI-DEV Organizational Process Definition(过程资产库 PAL)。http://chrguibert.free.fr/cmmi12/cmmi-dev/text/pa-opd.php
7. ISO 21500:2021 样本 PDF【未核实:术语条目未直接抓到】。https://cdn.standards.iteh.ai/samples/75704/66d8037f5925439480f7ccce8a86a5bf/ISO-21500-2021.pdf
8. Nonaka, Toyama & Konno (2000) SECI, Ba and leadership, Long Range Planning 33(1)。https://uk.sagepub.com/sites/default/files/upm-binaries/9925_039585Ch02.pdf
9. Nonaka (1994) A Dynamic Theory of Organizational Knowledge Creation, Organization Science 5(1)。https://www.uky.edu/~gmswan3/575/Nonaka_1994.pdf
10. Alavi & Leidner (2001) Review: Knowledge Management and Knowledge Management Systems, MIS Quarterly 25(1)。http://www.cs.unibo.it/gaspari/www/teaching/14_KM_KMsystems_Alavi_MISQ.pdf
11. Tiago Forte, The PARA Method。https://fortelabs.com/blog/para/
12. Tiago Forte, The P.A.R.A. Method(2017)。https://medium.com/@fortelabs/the-p-a-r-a-method-a-universal-system-for-organizing-digital-information-342968918736
13. Mark, Gudith & Klocke (2008) The Cost of Interrupted Work: More Speed and Stress, CHI'08。https://ics.uci.edu/~gmark/chi08-mark.pdf
14. Mark et al. (2005) No task left behind?, CHI 2005(57% 片段被打断、25 分 26 秒)。https://ics.uci.edu/~gmark/CHI2005.pdf
15. LaPlume et al. (2022) 任务切换代价成分分解。https://openaccess.city.ac.uk/id/eprint/28330/8/LaPlume_et_al_2022.pdf
16. Task Switch Costs Scale With Dissimilarity Between Task Rules, J. Exp. Psychol. General。https://psycnet.apa.org/manuscript/2024-79046-001.pdf
17. Hirsch et al. (2018) mixing cost 与 dual-task cost 相关, Front. Psychol。https://pmc.ncbi.nlm.nih.gov/articles/PMC7171593/
18. 23 分 15 秒误引核查, oberien's Blog, 2023-11-05。https://blog.oberien.de/2023/11/05/23-minutes-15-seconds.html
19. AGENTS.md 官方站(标准与 FAQ:就近优先裁决)。http://agents.md/
20. AGENTS.md 格式与采纳规模, codingagents.md。https://codingagents.md/formats/agents-md
21. Standardize project context with AGENTS.md and Agent Skills, Red Hat Developer, 2026-07-27。https://developers.redhat.com/articles/2026/07/27/standardize-project-context-agentsmd-and-agent-skills
22. agent.md 规范草案(三层合并模型)。https://github.com/agentmd/agent.md
23. Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?, arXiv 2602.11988。https://arxiv.org/pdf/2602.11988v1
24. dbt-core AGENTS.md 实例。https://github.com/dbt-labs/dbt-core/blob/main/AGENTS.md
25. Anthropic, Effective context engineering for AI agents, 2025-09。https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
26. Cursor Rules 文档。https://cursor.com/docs/rules
27. Windsurf Memories / 目录级规则。https://docs.windsurf.com/windsurf/cascade/memories
28. Cline Memory Bank(六层)官方文档。https://docs.cline.bot/features/memory-bank
29. Letta, Memory Blocks。https://www.letta.com/blog/memory-blocks
30. Mem0 论文, arXiv 2504.19413, 2025-04-28。https://arxiv.org/abs/2504.19413
31. PROJECTMEM, arXiv 2606.12329, 2026-06。https://arxiv.org/abs/2606.12329
32. Memory for Autonomous LLM Agents(综述), arXiv 2603.07670。https://arxiv.org/html/2603.07670v1
33. Context vs. Memory Engineering, Machine Learning Mastery, 2026-07-02。https://machinelearningmastery.com/?p=24568
34. OpenAI Cookbook: Agents SDK Sessions Memory。https://developers.openai.com/cookbook/examples/agents_sdk/session_memory.md
35. Atlassian, Kanban WIP Limits。https://www.atlassian.com/agile/kanban/wip-limits
36. WIP 上限边界条件讨论, PM StackExchange【社区共识,非研究】。https://pm.stackexchange.com/questions/30940
37. Portfolio Hub, Project Portfolio Management Template(14 字段与两条防腐规则), 2026-06-24。https://portfoliohub.io/blog/project-portfolio-management-template
38. PM Info Hub, Project Status Report Template(10 节结构)。https://pminfohub.org/templates/status-report
39. PMI Monthly Project Status Report Template。https://www.scribd.com/document/850367446/PMI-Monthly-Project-Status-Report-Template
40. Mastt, Project Portfolio Template, 2025-04-25。https://www.mastt.com/resources/project-portfolio-template
41. 组合状态报告结构(60 秒仪表盘), Template.umatuna.com, 2026-02-05。https://template.umatuna.com/project-portfolio-status-report-template/
42. Worktree Isolation 工作流(10 agent 并行)。https://github.com/agentpatterns-ai/website/blob/main/workflows/worktree-isolation.md
43. STORM 论文(语义冲突与写时一致性), arXiv。https://arxiv.org/html/2605.20563v1
44. Parallel Subagent Safety 规则(爆炸半径纪律)。https://github.com/nalviggi101/ai-dev-rulebook/blob/main/claude/rules/parallel-subagent-safety.md
45. Managing Multiple Projects as an Online Solopreneur, Passivebook【轶事级:社区共识】。https://passivebook.com/online-business/time-management/managing-multiple-products/
46. What I Learned Building Multiple Products at Once, Gravam, 2026-07-24【轶事级】。https://gravam.com/blog/what-i-learned-building-multiple-products-at-once
47. The Unglamorous Truth About Running 10 SaaS Products Solo, DEV, 2026-02-21【轶事级】。https://dev.to/kapilsuham/the-unglamorous-truth-about-running-10-saas-products-solo-ja3
48. The Solo Founder Operating Model, bradyward.ai, 2026-05-20【未核实:未标注数据源】。https://bradyward.ai/resources/operations/solo-founder-operating-model
49. The documentation review that never happens, Moonpool, 2026-05-03【厂商博客自述样本】。https://moonpool.ai/resources/blog/knowledge-management/documentation-review-never-happens
50. Wiki Rot: Why Wikis Decay, datadef.io, 2026【工具厂商指南】。https://datadef.io/guides/en/wiki-rot
51. State of Docs 2025(444 名从业者)。https://www.stateofdocs.com/2025/documentation-tooling-and-api-docs
52. State of Documentation 2026: 30 Stats From 8 Reports, happysupport, 2026-06-06【二手汇总】。https://www.happysupport.ai/en/blog/state-of-documentation-2026
53. Aghajani et al., Software Documentation: The Practitioners' Perspective, ICSE 2020。https://homepages.dcc.ufmg.br/~figueiredo/disciplinas/papers/icse2020aghajani.pdf
54. Uddin & Robillard, How API Documentation Fails, IEEE Software。https://giasuddin.ca/wp-content/uploads/2020/12/ieeesoftware2015-how-api-documentation-fails.pdf
55. The $200,000 Ghost, Replay, 2026-02-18【未核实:营销数据,方法未公开】。https://www.replay.build/blog/the-200-000-ghost-why-documentation-decay-risk-in-static-wikis-is-killing-your-velocity
56. Why Your Docs Go Stale and How to Fix It, tela Blog, 2026-06-30。https://telawiki.com/tela/tela-blog/1057/why-your-docs-go-stale-and-how-to-fix-it
57. Outdated Documentation, Scribelet, 2026-04-16。https://scribelet.app/blog/outdated-documentation
58. 我的知识管理从0到1:踩坑与重生(3127 条笔记/1.3% 利用率), Worktile, 2026-07-03【个人经验,非统计研究】。https://worktile.com/kb/p/3977778
59. 深度分析:Karpathy 的 Wiki 与 PKM 赛道的变数, SimonAKing, 2026-04-06。https://simonaking.com/blog/pkm/
60. 数字断舍离的顿悟(删除 1 万条笔记), 36氪, 2025-07-25。https://m.36kr.com/p/3371378101522951
61. 用 LLM 编译知识(Karpathy wiki 归因), 星汉, 2026-05-02。https://nebula.zleo.ai/writing/karpathy-llm-wiki
62. 让基层干部更多下沉服务群众, 人民日报, 2024-07-09(报表重复率近 50%)。http://paper.people.com.cn/rmrb/html/2024-07/09/nw.D110000renmrb_20240709_1-10.htm
63. "一张表"里看变化, 半月谈, 2025-06-17。http://www.banyuetan.org/jczl/detail/20250617/1000200033136021750143484679231953_1.html
64. 一手实测:本工作区 项目\ 7 目录、根 AGENTS.md 全局 glob、台账\ 6 文件盘点(thinking/dev 工作区,2026-09-28)。

数据口径说明

1. 图表 1(LaPlume 2022):分项 219ms + 148ms + 183ms = 550ms,与原文"单次切换总代价 576ms"不完全相等;占比 41%/28%/34% 按原论文标注,四舍五入后合计 103%。本报告按原论文口径呈现,不做二次调平。来源 openaccess.city.ac.uk/id/eprint/28330。
2. 图表 2(五组失效信号):五条口径互不相同、分母各异(State of Docs=444 名文档从业者、wiki 抽查=10 页样本、Pocket=用户收藏行为、ICSE=146 名从业者、3127 条笔记=单人经验),仅并列展示失效信号的普遍性,不构成同口径对比;1.3% 为个人经验贴数据,非统计研究。
3. 内部实测六条(7/7 无 AGENTS.md、glob 0 命中、台账 6 文件、项目形态、thinking kb 未接入、无元信息载体)为 2026-09-28 本机盘点,一手数据。
4. 未核实项:bradyward.ai solo founder 3–5 倍与 15–25 分钟切换损失(未标注数据源);Replay 2,000+ 小时/年(营销数据,方法未公开);ISO 21500:2021 是否收录 OPA 术语条目。引用时均保留原标注。
5. 轶事级项:活跃项目数 2 个上限、轮转制、10 SaaS 时间分配均为社区/个人经验,非研究结论,只作方向参照,不作决策依据。
6. 厂商口径:Moonpool wiki 抽查 7/10、半衰期 6 个月为厂商博客自述样本,非同行评审;Stack Overflow 数据为二手汇总。
7. "23 分 15 秒"为被误引数字,原始论文中不存在;本报告只使用有出处的 Mark 2005 的 25 分 26 秒与 Iqbal & Horvitz 的 11–16 分钟。
8. AGENTBENCH 成本 +2023%、步数 +2.453.92 为 arXiv 2602.11988 评测结果,特定模型与仓库条件下测得,不可外推为常数。

AI 辅助调研生成,数据以原始文献为准,仅供学习研究参考。