分享下工作中的 AI 实践，现在模型用 glm5.2 更多，工具司内用的，写得很糙，也不放出来了，纯唠嗑下，想看看这种实践方向对不对，有没有更好用的。

设计

前提是有一个让 AI 能够记录错误、任务、项目等信息的环境。 实际上就是个 cli 工具，再用 skill + hook 去教 AI 用这个 cli ，以及设计工作流、记录机制。至于记录就是一堆有目录结构的 md 、yaml 、json 文件，放到了 ~/ 下的一个文件夹里。

在这个环境下，让 AI 放手去干，不需要提前喂入私域知识 skill 文档。

刚开始，AI 肯定会错，人工介入得会很频繁，会遇到各种烧脑的错误，代码也要逐行 cr ，但哪怕只是改一行入参错误，也要在对话框中告诉 AI 原来为什么错，应该改成什么。环境会让 AI 能够记录这些信息。等 AI 熟悉项目后，就轻松了。

不需要担心有限的上下文，subagent 也不必要，一旦触发压缩，让 AI 读取回环境中记录的任务、环境上下文即可，在环境信息足够的一次对话下，AI 经过多轮压缩后还能保持工作流，并完成任务。

实际开发需求，往往涉及很多仓库，在该环境中不断让 AI 完成任务，自然而然也记录了项目之间的关系、开发者常给该项目的称呼、痛点等等。

rag 是有用的，但不需要多高的准确度，用小的 Embedding 模型 + sqlite 本地跑，只是为了 AI 方便根据任务提示词，自己弄一些关键词去环境中搜记录、相关任务等等信息，搜出来一个目录，让 AI 挑着读去。

例子

昨天的一个任务提示词，“将当前旧组件 1.129 。0 版本依赖的新提交，迁移至重构后的新组件”。

背景是重构了一个十多 w 代码的组件，拆分成了两个新组件，其中一个要被其它地方复用，所以 AI 一共要看 3 个独立项目仓库。仅一句话，AI 就在环境中找到了一切信息，然后花费 20 分钟，3 轮上下文压缩后，100%完成了迁移。

没有人工介入，我也很惊讶，可能是因为 AI 已经非常熟悉这个几个项目了，就算没有告诉它要保持长任务运行，因为信息足够，AI 也自然而然地一轮对话完成。

之前的重构任务花了一个月多，这一个月一直在环境中让 AI 完成任务，最开始我让 AI 直接按要求重构所有代码，效果很不好，业务逻辑一塌糊涂，但目录结构那些有模有样。后面根据各功能模块，逐个重构，核心数据流、架构古法编程，逐行 cr ，跑通业务，指出问题。现在我可能都忘记了一些细节的数据流、坑点、妥协，但 AI 还记得，并偶尔在完成新任务时，发现问题。

多人参与

把 ~/ 下那个文件夹提交成个 git 仓库，别人 clone 就行，做了多用户区分，所以各记录各的，给 AI 提供信息时，是参考所有用户的记录的。

碎碎念

业务文档全在无数产品 prd 里，先辈的文档、流程图也只是冰山一角，很多和现存代码映射不上，老组件多年迭代，代码逻辑不忍直视，一行 3 年前的 // todo 这里有问题 的注释，让我眉头一皱。靠 AI 自动生成 repo wiki 和业务逻辑也是两码事，还缺失了上下游组件链路的依赖理解，用不了。

所以，一开始就不想人工提前梳理出一堆文档，就是懒了，干看老代码太烧脑了，仅做了顶层排期和大概项目结构理解，就直接让 AI 开干，再一边实现了这个“环境”。

这套跑下来 token 消耗量挺大的，不过都是司内额度，狠狠蹬了。