Carson Gross 在 2026 年 9 月 21 日发表的文章中，为智能体编程提出了一项新约定：将选定的 Markdown 文件存放在 `/src/md` 目录中，与它们协助生成的代码放在一起。他的核心主张并不是说文字会真正取代实现，而是认为 Markdown 正越来越多地承载那些目前隐藏在一次性提示词中的设计意图。
这一提议之所以把 Markdown 视作类似源代码的载体，是因为它既是纯文本，又便于比较差异、搜索，并可在拉取请求中接受审阅，而且人和语言模型都能直接处理。Gross 建议把模块概览、功能说明、数据模型注释、应用程序接口注释和基础设施注释放在相关代码附近，同时把更高层级的流程文档留在问题跟踪器或维基等系统中。
他为测试设定了辅助性角色。测试应当依据 Markdown 提供自动化确认，而文字则继续作为面向人和智能体的说明，阐述系统做什么、为什么这样做，以及绝不能做什么。这样的分工旨在让设计意图更易于审阅，同时避免把每一项设计决定都塞进低层级的测试语法。
这篇文章是在提出论证和一项约定，并不能证明 `/src/md` 已经成为成熟的工程标准。Gross 表示，他尚未广泛使用这种结构，也预计自己的想法会发生变化。他还提醒，Markdown 需要一个“复杂度预算”，必须谨慎维护，并偶尔与生成的代码同步，包括把对文档所做的修改反向落实到实现中。
因此，实际要回答的问题并不是团队是否应该把每一条提示词都倾倒进代码仓库，而是一个规模较小、持续维护的源代码层级意图层，能否在不沦为陈旧杂乱信息的前提下减少歧义。这篇文章给出了一个有用的答案：让 Markdown 紧邻代码，使其可以接受审阅，并把它当作持续演进的、类似规范的产物，而不是提示词的永久记录。