说起来，

接手全新方向的第一天

痛点：从测试开发转岗到数据生产。仅有三天交接时间，怎么说呢，原负责同学即将离职，交接材料极其有限。

我从测试开发被转岗到了数据生产，负责一类数据生成工作。雪上加霜的是原来负责这块的同学马上就要离职了只有三天交接时间。

三天能交接什么？打开电脑，手里只有几篇历史周报和一篇刷数据的交接文档。但这个方向是一个完整的循环：刷数据、筛数据、训模型、用 benchmark 评估、分析结果、制定新策略、再刷一批数据。交接文档连这个循环的全貌都没画出来、更别说每个环节的背景知识了。

三天后人就走了。我决定用 Agent 来帮我填这个坑。不是让 Agent 替我干活，而是和它一起把脑子里还没有的知识挖出来、写下来、组织好。说起来，

先亮答案的观点是。最终我沉淀出了什么

痛点：缺乏程序化文档导致协作低效，Agent 只能盲目执行。

经过两周的迭代。最终形成了这套文档架构：

workspace/
├── AGENTS.md # 协作规则
├── wiki/ # 跨项目通用知识
│ ├── runbooks/ # 通用操作手册
│ └── project/ # 关联代码库介绍
└── /
├── wiki/ # 项目知识库
│ ├── background/ # 背景知识
│ ├── runbooks/ # 操作手册
│ ├── results/ # 实验结果
│ └── issues/ # 问题记录
├── change/ # 规划/进展/状态
│ ├── roadmap.md # 长期规划
│ ├── current-progress.md # 近期进展
│ ├── todo.md # 接下来行动
│ └── runs/ # 单次任务执行状态
└── scripts/ # 可执行脚本

两周的文档迭代，换来的是 Agent 真正能帮我干活。说起来，

再看举个例子，"用这批数据起一轮训练"，Agent 会自己去拉代码、挂载磁盘、配比数据、起多机训练。训练过程中自动监控日志、沉淀产出物，跑完之后把结果整理好，顺手把本次进展更新到文档里。整个过程一轮对话完成，老实说，

再比如 benchmark 评估。以前得手动跑完再逐个看数据。现在 Agent 跑完评估后直接给我一份分析报告，哪些指标涨了、哪些跌了、接下来建议调什么。

这些能力不是我写代码实现的。是我把知识写进了文档程序，Agent 读完就知道怎么干。

阶段一这方面，从周报和交接文档到知识沉淀

痛点：零散周报与单一操作手册无法提供完整业务流程视图。说起来，

起点很低。几篇周报，一篇只覆盖刷数据环节的操作命令，一个什么都不懂的我。而我要接手的是从刷数据到筛数据、训模型、评估、分析的完整循环。其实，

提炼方向——让 Agent 帮忙梳理

第一步先是让 Agent 帮我提炼方向。我把最近几篇周报喂进去，问它："这个方向到底要做什么？"它帮我梳理出了一个主梳理文档，把零散的周报内容归纳成了几个主要任务和它们之间的关系。我第一次有了全局视角，

扫盲阶段——填补概念空白

但主梳理文档只有骨架，大量概念是空的。什么是 forward，为什么用 loss 而不是方差做筛选？评估指标怎么算，这些问题 Agent 也答不上来因为它没有我的业务上下文。

于是开始了扫盲。我逐个追问不懂的概念，每次对话结束后把结论写成一篇文档。五次对话，五篇背景知识，这些文档质量不算高，但至少把"我不知道的东西"变成了"我知道但还没整理的东西"。

结构化 Wiki——避免“一锅炖”

随后我把这些散落的文档归进一个 wiki 文件夹。其实，有了统一入口，至少不用满硬盘找文件了。但很快发现如果所有知识都塞在项目 wiki 里下次换项目就全丢了。从于是拆了两层来看，

• 方向层放通用背景知识，实现跨项目复用；
• 项目层放当前项目专属知识。

/为什么"的是背景知识；读完后知道"怎么做"的是操作手册。于是 wiki 下出现 background/ 和 runbooks/ 两个子目录。

说到阶段二。从纯文档到可操作

痛点：缺少可执行脚本与任务进度追踪，使得实际落地仍然繁琐且易出错。

脚本管理与任务追踪

第一个实际任务是通过 MR 队列远程筛选数据。这涉及到可执行脚本管理——光有 wiki 不够，需要建立 scripts/ 目录。每个脚本旁边放一个 index.md)说明它干什么、怎么跑。

我需要一个地方追踪任务进展。roadmap.md` 放长期规划；current-progress.md` 放近几天做了什么；不过，todo.md` 放接下来该干什么。于是 #change` 诞生了。

踩坑与迭代重构

项目组已有训练验证文档，我照着操作却根本跑不通——因为大量背景知识缺失。每卡住一次我就把原因和解法写成新文档。第一轮训练就是这样完成：跑一步卡一次卡一次补一篇，补完继续跑。

• 渐进式披露：
• 公共抽取：
• A/B 解耦：

结构化 Runbook——让 Agent 不迷路

The second reconstruction turned narrative operation docs into structured runbooks—each step lives in its own file with clear:

• 目标
`
`

This granularity lets Agent read only current step。verify success,n advance.

从阶段三来看，多任务并行的状态控制

痛点： 多条流水线并行时“todo” 与 “current‑progress” 混杂导致上下文丢失，Agent 忘记上一步完成情况。

为了解决，这里引入 runs / 。话说回来，每启动一次任务，就在 change/runs / 下创建目录。并放置 state.md ：目标、当前步骤、已验证事实还有恢复点。

完成后将稳定结论同步至 current‑progress.md 。将后续行动写入 todo.md ，随后清理对应 runs 条目。话说回来，

三类文件职责明确：

• runs / ：临时状态记录；
• current‑progress.md ：稳定进度摘要；
• todo.md ：待办行动清单；

有了这套机制后即使三条线并行运行，也能保持每条任务独立且可恢复。Agent 的自主度从“全程盯着”提高到“一轮对话搞定”。

h2 data - id = “ heading - ” 演进方法 / h2> p> 回头看。这是一条清晰演进线，每一步都是因具体问题而产生，不是预先设计好的。ol> li> li> li>

h2 data - id = “ heading - ” 两个落点 / h2> p>

p> 传统做法是把工作留在脑子里或口头传授，一换人就断流。采用项目制管理，把所有关键信息写入结构化仓库。让 Agent 能直接读取，你离开时知识依旧存续。这是一场人与机器共同迭代提高之旅。

p>

p> 从散文件到 wiki。从“一锅炖”到分层分类，从叙述式到步骤薄片，每一步都是需求驱动而来。即使是一篇 md、一条 prompt 或一句规则。也应当视为“知识工件”，先写下来再在实际使用中不断重构。

blockquote>

只有不断迭代，才能趋近完美。按理说，/ p>

---