背景
本篇文章作为个人的学习记录，原文写得很详细完善，若想更深地了解，可以看原文：
linux.dolinux.dolinux.do ↗Idea
以下记录了我在阅读这篇文章的时候的一些心得
文档管理本质上是在做 prompt engineering
一.保持上下文干净的做法
文档分层分职责 → 使文档独立边界明确
“
deepseek团队将文档分成了agent.md、docs/、和.agent/note/，前者负责开工必读的规则，中者负责说明当前系统的整体项目图谱与开发者规范，后者负责仓库里的决策记录（决策和踩坑log），三类边界明确的、各自放在独立文件夹的文档，让agent读取的时候能够明确不同文档的实际语义。同样除了三类文档的分层分职责，文档内部的文件也进行的结构分层，例如
docs/中分为全景图、子系统规范等等，子系统规范又一系统一页”
文档内防腐 -> 防止激活反向语义与上下文污染
“
最近我vibe coding的时候就经常遇到一种情况：当agent被要求不断维护文档的时候，它一般只会做增量更新，旧的文档就只标注“过时”“以前”“不再生效”之类的词。当文档量不断上升到一定规模的时候，模型因为上下文较长，容易被这些过期的内容影响到真正有用的对活跃文档的注意力；同时本身否定用语会让语义留在模型cache中，然后在一般的模型上，会随着上下文的增长，反而使得否定语义被弱化甚至转成肯定
而deepseek的具体做法就是，
docs/只记当下事实，严禁叙述变迁，文档只描述当前活跃有效的状态”
二.保证prompt下限的做法
给文档内容提供确定性兜底 -> 防止ai拉屎ai吃的情况
“
deepseek用来描述项目图谱的
docs/中，凡是源码或AST能推导出的表格，必须由代码生成器自动跑，文档只负责固定插槽。同时deepseek还通过
CI检查，强制固定上述三类文档的字数上限”
三.记录决策 -> 让agent不耍小聪明，当个老实人
“
dsh中，
.agents/notes/面向将来的维护者和新开的agent，回答的是「当初为什么写成这样、否定过哪些方案才妥协成现在这样」一份
notes中有四个格子：
- promblem描述问题
- decision描述决定
- alternative considered描述被放弃的方案。必须写清楚当时还想过什么、为什么放弃。
- consequence描述收益和代价
通过这四者，后续的协作agent可以对项目的决策逻辑有较好的了解，尤其是
alternative，能有效在记录决策树上的剪枝，防止后续agent重蹈覆辙”
好高级，球博主每天更