AI 降低了实现成本，却没有同步降低理解成本。过去，开发者在逐行编码中被迫建立系统的心智模型；现在，代码可以在人尚未理解接口、边界与异常路径之前生成。实现与理解由此脱钩：代码更快出现，恢复设计意图和判断改动影响的成本却没有消失。
这不意味着人必须理解每一行代码。被稳定接口、测试和契约封闭的实现，可以隐藏在边界之后；但契约不可能预见所有变化，长期系统也必然遭遇意外故障。人可以不长期保有完整的心智模型，工程却必须保留一条重新理解系统的路径。
Agent 的短暂性使这一点更加重要。主 Agent 和子 Agent 都不会持续存在，上一轮形成的认识不能依赖它们记住，只能沉淀在 Skill、Spec、测试、代码和接口中。新的瓶颈因此不是谁能读完全部代码，而是：设计意图、当前决定与验收依据，能否在多次生成、修改和 Agent 交接后仍被准确恢复。
简洁是对共同理解的压缩
代码生成便宜以后，方案不清楚似乎也可以先写，偏了再用 Prompt 修正。但方案中的空白会被 Agent 自行补全，多轮修订又会让新旧决定同时留在上下文里。系统未必最终错误，却可能在反复解释、返工和校正中，付出远高于生成本身的协调成本。
编码前的质询不是为了穷尽细节，而是区分已经确认的决定、仍待验证的假设和明确排除的范围，防止 "没有讨论" 在实现中静默变成 "已经决定"。
"增加数据导出" 并不是一个完整决定：导出当前筛选结果还是全部数据，同步返回还是异步生成，权限和文件期限如何处理，都可能改变实现方向。
Agent 应先从代码和文档中恢复已有事实，只追问产品取舍、领域边界和关键技术岔路。彼此独立的问题可以同轮提出，依赖上一答案的问题留到下一轮；轮数取决于决策依赖图的深度，每轮问题数量则受人的注意力限制。质询的目的不是问得最多，而是用最少轮次消除代价最高的猜测。
会话适合形成决定，不适合保存当前真相。有效结论进入 Spec，值得追溯的重大变化进入 ADR，已经落实的行为进入代码和测试。决定改变时，应替换 Spec 中的旧结论，而不是继续追加补充说明。单一真相来源不是删除历史，而是把当前结论与演进历史分开。
这也是简洁真正的价值。长方案不仅多花 Token，也使人更难完整重读，让背景、旧结论、备选方案和当前约束在模型注意力中彼此竞争。简洁不是删掉细节，而是提高决策密度：只保留会改变行动的当前结论，并把散落的约束压缩成稳定概念。
领域驱动设计中的 **Ubiquitous Language（统一语言）**就是这种压缩。一个好的名称会同时携带一组边界；vertical slice 不只是任务名称，还意味着一个用户可感知、端到端成立且能够独立验证的行为。需求、Spec、代码和测试使用同一个词，后续 Agent 才不必重新推断 exportTask、reportJob 和 downloadRequest 是否指向同一概念。
定义缩短的不只是表达，也缩短了理解路径。共同语言越稳定，Agent 越少重新解释，也越不容易在实现中遗漏由这个名称共同承载的约束。相同原则还应进入代码：先复用现有代码、标准库、平台能力和已有依赖，只有它们都不能满足需求时，才新增最小实现。简洁不是少理解，而是理解以后少制造。
康威定律：短暂 Agent 会把制品结构变成软件结构
传统团队可以把部分知识保存在长期成员的记忆与关系中，主 Agent 和子 Agent 却只为一次任务存在。它们退出后，没有进入 Skill、Spec、测试和代码的认识不会成为隐性知识，而会直接消失。因此，每次任务都在从这些制品中重新实例化一个临时组织：人提供持续的意图与责任，制品保存项目记忆，Agent 提供短暂的计算能力。
这也改变了康威定律在 Agent 工程中的表现。持续塑造软件的，不是某一轮 Agent 的临时协作拓扑，而是后续 Agent 反复读取的语言、任务边界和交接协议。如果 Spec、测试和代码按 Controller、Service、Repository 切分，系统就更容易沿技术层增长；如果它们围绕用户行为和 Vertical Slice 组织，模块便更可能围绕领域能力内聚。
当执行者是短暂 Agent 时，软件结构会映射持久化制品中的任务划分。
Skill 不会单独决定架构，却会持续施加架构压力。它反复要求 Agent 用什么概念理解系统、从哪里切分任务、以什么单位验证完成；这些微小选择累积起来，最终会沉积为代码的目录、接口和依赖关系。
因此，一次任务的交付不只是留下可运行代码，还要让下一批 Agent 能够恢复系统的当前状态。它不需要重现上一轮的完整思考，只需要找到仍然有效的决定、已经成立的行为，以及下一步应当沿用的领域边界。
共识必须变成可运行的证据
Spec 保存 "我们决定做什么"，却不能证明实现仍然遵守决定。自然语言可能被误解，也可能在长时间执行中退出注意力。要让共识穿过一批批短暂 Agent，还必须把它转化为可运行的行为证据。
测试是一种外置的行为存储。 它不保存上一批 Agent 如何思考，而是保存系统已经承诺什么。会话可以被压缩，但后来修改一旦破坏既有行为，测试就会重新变红。
因此，Spec 保存当前意图，测试保存已经成立的行为。
Grill 阶段用统一语言把需求拆成用户可感知的行为；实现时直接取出一条 Slice，将它写成从用户入口到可观察结果的测试，一次只闭环一条 Slice，避免 Agent 在当前行为尚未成立时被后续任务拉走，使项目始终保持可运行、可解释和可回退。
测试不应只证明 Controller 调用了 Service、Service 又调用了 Repository，而应证明这些层真正协作完成了一件用户的事。否则，每层测试都绿，系统仍可能从未端到端工作。
红与绿必须是两次真实运行。第一次红，证明测试能够识别目标行为尚不存在；实现后的绿，证明本次修改使其成立；未来再次变红，则说明后续修改破坏了已经存储的行为。红 --- 绿不是 TDD 的仪式，而是行为写入外部存储的证明。
但测试全绿只说明用户行为仍然成立，不能证明代码结构健康。实现仍可能命名混乱、耦合严重，让下一批 Agent 难以恢复理解。因此还需要一把稳定的 Review 尺子。LLM 通常已经知道常见的设计原则与代码坏味道，Skill 无须重新教授这些知识；它要做的是重新设定判断分布，防止长上下文稀释标准，也防止模型把代码库中反复出现的坏味道当成正常惯例。Review 应将 "是否实现 Spec" 与 "结构是否健康" 分开，并要求每项判断具有具名、可定位的证据。只有发现具体问题后才进入 Refactor；每次只做不改变行为的小步修改，并在每一步后重新运行测试。
整条工程闭环最终可以压缩为一句话： Spec 压缩共识，测试固化行为，Review 稳定尺度，Refactor 收敛结构。 这些制品不是任务完成后的附属记录，而是短暂 Agent 之间真正的协作界面。
Description 是组织冷启动的第一个 Context Pointer
每一批 Agent 进入项目，都需要恢复项目的语言、约束和工作方式。常见做法是让一份巨大的 AGENTS.md 始终留在上下文中，里面同时放入架构说明、命名规范、测试规则、发布流程和历史决定。但这些知识并不在每个任务、每轮交互中都相关。全部常驻不仅消耗 Token，也会让无关规则与当前约束争夺注意力。
可以把 AGENTS.md 本身视为一条项目 Skill 的正文，而不是每轮重复加载的背景资料。常驻上下文中的只有这条 Skill 的 Description ：它说明项目知识解决什么问题，以及遇到哪些任务时必须读取 AGENTS.md。只有命中触发条件，Agent 才加载正文。
知识需要持续存在，不等于知识需要持续可见。
Description 因而是项目知识的第一个 Context Pointer 。它负责从当前上下文指向 AGENTS.md；AGENTS.md 再通过下一层 Pointer，按任务分支指向 Spec、ADR、领域文档、操作流程或其他 Reference。代码和测试则保存已经落实的事实与行为。
Description
→ AGENTS.md
→ 当前分支所需的 Spec、ADR 或 Reference
→ 代码与测试这种结构把知识的存储 与加载 分开了。项目可以保留完整知识，但 Agent 每次只换入当前行动所需的部分。它类似虚拟内存：材料仍然存在，只是不必全部同时进入工作集。好的 Description 是一条准确的加载条件：什么任务如果不读取这份项目知识，就容易做错。
同样，AGENTS.md 也不应成为项目百科。它的任务是恢复项目最上层的工作模型，并把 Agent 路由到当前分支所需的材料；只有所有相关任务都必须知道的不变量，才值得直接留在正文。低频规则、特定分支的细节和历史解释继续放在下一层 Pointer 后面。
渐进式披露因此不是简单地 "少加载"，而是建立一条可靠的恢复路径：
需要时能够逐层找到，不需要时不让它进入注意力。
Agent 可以短暂，也不必始终携带完整的项目心智模型。真正需要持续存在的是项目知识及其入口；真正需要进入上下文的，只是当前任务所必需的那一部分。