AI原生提示词架构设计：让自然语言成为新源码
AI原生提示词架构设计：让自然语言成为新源码
前言
在上一篇《AI时代的代码架构：如何设计让AI更好编程的系统》中，我提出了一个核心观点：代码是cheap的，AI注意力是昂贵的，应该设计专门的架构来适应AI的认知特点。
但如果只优化代码架构，只解决了一半的问题。另一半问题在于：给AI的提示词（Prompt）本身也需要架构。
在探索Claude Code、Clawdbot等AI辅助编程工具的过程中，我发现一个现象：很多人把提示词当成零散的文本片段，想到什么写什么。这就像在机器码时代，程序员直接写0101序列——没有抽象，没有结构，难以维护。
我认为：在AI时代，提示词（Markdown文档）将成为新的"源码"，而代码将成为编译后的"中间产物"。
本文将阐述一套与代码架构相辅相成的AI原生提示词架构设计。
核心洞察：提示词也需要架构
传统误区
很多人认为提示词就是一段自然语言文本：
❌ 错误做法：把所有信息写在一个prompt里
"你是一个C语言程序员，请帮我写一个日志系统。
这个系统需要支持：
1. 输出到文件
2. 输出到控制台
3. 日志级别控制
4. 线程安全
5. 还要支持JSON格式输出
6. 还要支持滚动日志
7. 还要..."问题：
- AI的注意力被分散到10+个细节上
- 核心逻辑容易出错
- 难以维护和扩展
正确思路：模块化 + 按需加载
✅ 正确做法：架构化的提示词
项目/
├── AGENTS.md # 顶层意图（main函数）
├── modules/
│ ├── logger/
│ │ ├── AGENTS.md # 模块意图
│ │ └── skills/ # 按需加载的细节
│ │ ├── output.md
│ │ ├── thread_safety.md
│ │ └── json_format.md
│ └── network/
│ ├── AGENTS.md
│ └── skills/
│ ├── tcp.md
│ └── ssl.md
└── build/ # AI生成的一次性代码
└── src/优势：
- AI的注意力聚焦：每次只关注一个模块的意图
- 降低认知负担：细节放在skills里，按需加载
- 易于维护：修改意图，重新"编译"即可
提示词架构设计
1. AGENTS.md：MD文档的main函数
核心原则：每个AGENTS.md是唯一入口，描述"做什么"，不描述"怎么做"。
项目级AGENTS.md
# AGENTS.md - 项目全局视图
## 项目背景
这是一个高性能网络服务器，支持并发连接和事件驱动架构。
## 核心功能
- 网络连接管理（TCP/SSL）
- 异步事件处理
- 日志记录
- 数据持久化
## 主要模块
- [logger/](modules/logger/AGENTS.md)：日志记录模块
- [network/](modules/network/AGENTS.md)：网络通信模块
- [storage/](modules/storage/AGENTS.md)：数据存储模块
## 对外接口
应用通过`api.h`提供统一的接口：void app_start();
void app_stop();
## 设计原则
- 零循环依赖
- 编译期隔离
- AI注意力优先作用：
- 给AI提供全局视图
- 说明项目背景和目标
- 列出主要模块和依赖关系
- 就像C程序的main函数，是整个系统的入口
模块级AGENTS.md
# Logger Module - AGENTS.md
## 功能定位
记录应用日志到文件和控制台，支持多种日志级别和输出格式。
## 核心接口void logger_log(Logger logger, const char message);
void logger_set_level(Logger* logger, LogLevel level);
void logger_set_output(Logger* logger, OutputTarget target);
## 主要职责
1. 接收日志消息
2. 格式化输出（文本/JSON）
3. 写入目标（文件/控制台）
4. 线程安全保证
## 依赖
- 依赖：无（零依赖模块）
- 被依赖：network、storage
## 细节文档
- [output策略](skills/output.md)：如何支持多种输出格式
- [线程安全](skills/thread_safety.md)：如何保证并发安全
- [性能优化](skills/performance.md)：如何优化日志性能
## 注意事项
- 不要在这个模块中添加网络功能
- 不要阻塞主线程作用：
- 描述模块的职责和边界
- 说明接口和使用方式
- 列出依赖关系
- 指向细节文档（skills）
2. Skills目录：按需加载的细节
核心原则：skills只描述意图和需求，不描述具体实现。
示例：logger/skills/json_format.md
# JSON格式日志输出
## 需求描述
日志需要支持JSON格式输出，便于日志收集和分析系统（如ELK）解析。
## 输出格式{
"timestamp": "2026-02-15T10:30:00Z",
"level": "ERROR",
"module": "network",
"message": "Connection failed",
"context": {
"peer": "192.168.1.100:8080",
"error_code": 110}
}
## 使用场景
- 生产环境日志收集
- 自动化日志分析
- 结构化查询
## 性能要求
- JSON序列化时间 < 100μs
- 不能阻塞主线程
## 不需要关心
- 具体用哪个JSON库（AI自己选择）
- 如何优化性能（AI自己考虑）关键点：
- ✅ 描述"做什么"：支持JSON格式
- ✅ 描述"为什么要做"：便于日志分析
- ✅ 描述"使用场景"：生产环境
- ❌ 不描述"怎么做"：不用告诉AI用哪个库
示例：logger/skills/thread_safety.md
# 线程安全保证
## 需求描述
日志模块可能被多个线程同时调用，必须保证线程安全。
## 关键要求
1. 不能丢失日志消息
2. 不能死锁
3. 性能开销最小化
## 常见场景
- 主线程写日志，工作线程也写日志
- 多个网络连接同时记录错误
## 可选方案（仅供参考，AI可以自行决定）
- 使用互斥锁（简单，但可能阻塞）
- 使用无锁队列（复杂，但性能好）
- 使用线程本地缓冲（延迟写入）
## 性能目标
- 单次日志调用 < 50μs
- 支持至少10个并发线程3. 按需加载策略
核心思想：不是一次性加载所有MD，而是根据AI的注意力范围动态加载。
场景1：AI生成logger模块代码
步骤1：读取 logger/AGENTS.md
→ AI理解模块的整体意图
步骤2：AGENTS.md引用了 skills/output.md
→ AI读取这个文件，了解输出需求
步骤3：AI开始生成代码
→ 只关注当前模块，不受其他模块干扰场景2：AI需要理解logger如何被network使用
步骤1：读取 logger/AGENTS.md
→ 了解logger提供的接口
步骤2：读取 network/AGENTS.md
→ 发现network依赖logger
步骤3：按需加载 skills/json_format.md
→ 了解network需要JSON格式的日志类比：现代操作系统的按需加载
传统程序：
启动时加载所有代码到内存
→ 浪费内存，启动慢
现代程序（动态链接）：
启动时只加载必需的代码
→ 节省内存，启动快
→ 使用到某个模块时，才加载
AI提示词架构：
AI开始工作时，只加载必需的MD
→ 降低上下文消耗
→ 需要细节时，才加载skills与代码架构的对应关系
完美映射
提示词架构（MD） 代码架构（C）
───────────────── ─────────────────
AGENTS.md ↔ api.h / module.h
skills/output.md ↔ src/module/impl.c（实现细节）
项目AGENTS.md ↔ 项目对外接口
按需加载MD ↔ 动态链接/模块化编译核心原则一致性
| 原则 | 提示词架构 | 代码架构 |
|---|---|---|
| 零循环依赖 | AGENTS.md不互相include | .h文件不互相include |
| 清晰边界 | 每个AGENTS.md职责单一 | 每个module职责单一 |
| 按需加载 | skills目录按需读取 | 编译期隔离 |
| 单一入口 | AGENTS.md是main函数 | api.h是唯一对外接口 |
| 意图抽象 | MD描述"做什么" | .h描述接口 |
生成流程
人类维护层（源码）：
├── AGENTS.md
├── modules/*/AGENTS.md
└── modules/*/skills/*.md
↓
↓ AI"编译"
↓
AI生成层（中间产物）：
├── include/*.h
└── src/*/impl.c
↓
↓ 传统编译
↓
机器码（运行产物）：
└── binary技术本质：编程语言演化的延续
历史规律：抽象层不断上升
┌─────────────┬──────────────┬─────────────┬──────────────┐
│ 时代 │ 程序员关注 │ 工具 │ 输出物 │
├─────────────┼──────────────┼─────────────┼──────────────┤
│ 机器码时代 │ 0101序列 │ 手工拨开关 │ 机器码 │
│ 1940s │ │ │ │
├─────────────┼──────────────┼─────────────┼──────────────┤
│ 汇编时代 │ 助记符 │ 汇编器 │ 机器码 │
│ 1950s │ (MOV, ADD) │ │ │
├─────────────┼──────────────┼─────────────┼──────────────┤
│ 高级语言 │ 算法逻辑 │ 编译器 │ 汇编/机器码 │
│ 1970s+ │ (for, if) │ │ │
├─────────────┼──────────────┼─────────────┼──────────────┤
│ AI时代 │ 业务意图 │ 自然语言 │ 代码 │
│ 2020s+ │ (自然语言) │ 编译器 │ │
└─────────────┴──────────────┴─────────────┴──────────────┘每一次革命的本质
机器码 → 汇编：符号抽象
之前：
程序员需要记住：
01001001 = LOAD寄存器
01001010 = ADD操作
01001011 = STORE操作之后：
程序员只需要写：
LOAD A, 10
ADD B, 5
STORE A, result本质：用符号代替数字，降低记忆负担
底层依然存在：CPU还是执行0101，但程序员不需要关心了
汇编 → 高级语言：控制流抽象
之前：
; 计算1到100的和
MOV AX, 0
MOV CX, 100
MOV BX, 1
loop_start:
ADD AX, BX
INC BX
DEC CX
JNZ loop_start
STORE AX, sum之后：
int sum = 0;
for (int i = 1; i <= 100; i++) {
sum += i;
}本质：
- 用控制流（for, if）代替跳转指令
- 用变量名代替寄存器
- 用类型系统代替手动内存管理
底层依然存在：CPU还是执行跳转指令，但程序员不需要关心了
适用范围降低：
- 99%的代码用高级语言
- 1%的极端性能场景（OS内核、驱动）用汇编
高级语言 → AI：意图抽象
之前：
# 发送HTTP请求并处理错误
import requests
try:
response = requests.get('https://api.example.com/users')
if response.status_code == 200:
users = response.json()
for user in users:
print(user['name'])
else:
logger.error(f"HTTP {response.status_code}: {response.text}")
except requests.exceptions.RequestException as e:
logger.error(f"Request failed: {e}")之后（AI时代）：
<!-- network/AGENTS.md -->
# Network Module
## 功能
发送HTTP请求到API服务器，获取用户列表。
## 接口UserList network_fetch_users(Network self);
## 错误处理
如果请求失败，需要：
1. 记录错误日志（通过logger模块）
2. 返回NULL给调用者
3. 不要抛异常（C语言不支持）
## 性能要求
- 超时时间：5秒
- 重试次数：3次本质：
- 用自然语言描述意图，代替具体的控制流
- AI负责"怎么做"，人类只说"做什么"
- 代码成为中间产物，就像今天的汇编
底层依然存在：
- CPU还是执行机器码
- 编译器还是生成汇编
- 但程序员99%不需要关心了
适用范围降低：
- 99%的代码用AI + 自然语言生成
- 1%的极端场景（AI生成代码性能不够）手工写代码
技术演化的规律
规律1：抽象层不断上升
机器码（硬件） → 汇编（符号） → 高级语言（逻辑） → 自然语言（意图）
↓ ↓ ↓ ↓
只有极少数人掌握 少数人 大多数人 所有人规律2：旧技术不会消失，适用范围降低
汇编语言的演化：
1950年代：所有编程都用汇编
1980年代：系统编程用汇编，应用编程用高级语言（90% vs 10%）
2020年代：只有OS内核、驱动、嵌入式用汇编（1% vs 99%）
未来：只有极端性能优化的场景用汇编（0.1% vs 99.9%）手工写代码的演化（预测）：
2020年代：所有编程都手写代码
2030年代：大多数编程用AI生成，少数极端场景手写（10% vs 90%）
2050年代：只有极致性能场景手工写代码（1% vs 99%）
2100年代：只有特殊领域（AI无法理解）手工写代码（0.1% vs 99.9%）规律3：工具复杂度转移
机器码时代：
工具：简单（手工拨开关）
程序员负担：重（需要记住所有0101）
汇编时代：
工具：汇编器
程序员负担：减轻（只需要写助记符）
高级语言时代：
工具：复杂的编译器、链接器、优化器
程序员负担：很轻（只需要写逻辑）
AI时代：
工具：极其复杂的自然语言编译器（大模型）
程序员负担：极轻（只需要描述意图）类比：代码 = 未来的汇编
今天我们如何看待汇编？
场景1：应用开发
工程师：我要写一个Web服务器
选择：Go、Python、Java
绝不会考虑：手写汇编
场景2：系统编程
工程师：我要写Linux内核
选择：C语言，偶尔内联汇编
不会全用：纯汇编
场景3：极致优化
工程师：这个加密循环性能不够
考虑：手写汇编优化这一小段结论：汇编依然存在，但适用范围极小。
明天我们如何看待代码？
场景1：应用开发
工程师：我要写一个Web服务器
做法：写AGENTS.md描述意图
工具：自然语言编译器（NLCC）
生成：Go/Python代码（自动）
绝不会考虑：手写Go代码
场景2：系统编程
工程师：我要写操作系统内核
做法：写关键模块的AGENTS.md
生成：C代码（自动）
偶尔手工优化：极少数性能关键路径
场景3：极致优化
工程师：AI生成的这段代码性能不够
考虑：手工优化这一小段结论：代码依然存在，但99%的人不需要手写。
类比总结
今天：
汇编 → 编译器 → 机器码
程序员写汇编，不需要看生成的机器码
（除非极端性能优化）
明天：
自然语言（MD） → 自然语言编译器（AI） → 代码 → 传统编译器 → 机器码
程序员写MD，不需要看生成的代码
（除非极端性能优化）高级语言不会淘汰汇编：汇编依然在OS内核、驱动中发挥作用
AI不会淘汰高级语言：代码依然是重要的中间层，但适用范围大大降低
未来展望：自然语言编译器（NLCC）
会是什么样的？
项目结构
project/
├── AGENTS.md # 顶层意图描述
├── modules/
│ ├── logger/
│ │ ├── AGENTS.md # 模块意图
│ │ └── skills/ # 按需加载的细节
│ │ ├── output.md
│ │ ├── thread_safety.md
│ │ └── json_format.md
│ └── network/
│ ├── AGENTS.md
│ └── skills/
│ ├── http.md
│ └── ssl.md
└── build/ # 生成的一次性代码
├── src/
│ ├── logger/
│ │ ├── impl.c
│ │ └── internal.h
│ └── network/
│ ├── http.c
│ └── ssl.c
├── include/
│ ├── logger.h
│ └── network.h
├── compile.log # 编译日志
└── test_report.xml # 测试报告工作流程
# 1. 人类修改意图
vim modules/logger/skills/json_format.md
# 2. 触发"编译"
nlcc build
# 3. NLCC自动执行
Reading modules/logger/AGENTS.md...
→ Loading skills/output.md...
→ Loading skills/json_format.md...
Generating code...
→ build/src/logger/impl.c
→ build/include/logger.h
Compiling...
→ gcc -c build/src/logger/impl.c -o build/obj/logger.o
Testing...
→ All tests passed
Build complete!
# 4. 查看生成的代码（可选，就像今天看汇编）
cat build/src/logger/impl.c
# 5. 运行
./build/bin/appNLCC和传统编译器的对比
| 传统编译器（GCC） | 自然语言编译器（NLCC） |
|---|---|
| 输入：C代码 | 输入：自然语言（AGENTS.md） |
| 输出：机器码/汇编 | 输出：C代码 |
| 错误：语法错误、链接错误 | 错误：意图模糊、逻辑矛盾 |
| 优化：寄存器分配、指令调度 | 优化：模块拆分、依赖管理 |
| 调试：看汇编代码（-S） | 调试：看生成的C代码 |
| 工具链：预处理 → 编译 → 汇编 → 链接 | 工具链：意图分析 → 代码生成 → 传统编译 |
实践建议：如何开始
1. 从小项目开始
不要：在大型遗留项目上尝试
应该：在新项目、工具项目、实验性项目开始
推荐起点：
- 个人工具脚本
- 小型库或框架
- 概念验证项目
2. 设计MD架构
步骤1：划分模块
→ 哪些功能是独立的？
→ 依赖关系是什么？
步骤2：编写项目级AGENTS.md
→ 项目背景是什么？
→ 主要模块有哪些？
→ 对外接口是什么？
步骤3：编写模块级AGENTS.md
→ 这个模块做什么？
→ 接口是什么？
→ 依赖哪些模块？
步骤4：编写skills/*.md
→ 需要哪些细节描述？
→ 按场景拆分（不要写成大而全）3. 验证提示词质量
标准：给另一个AI看你的AGENTS.md
- 它能理解这个模块做什么吗？
- 它知道如何使用这个模块吗？
- 它会产生误解吗？
如果AI都有问题，那说明意图描述不够清晰。
4. 维护MD，而不是代码
场景：需要修改logger模块
错误做法：
直接编辑 build/src/logger/impl.c
→ 下次nlcc build时，你的修改被覆盖
正确做法：
编辑 modules/logger/AGENTS.md 或 skills/*.md
→ 运行 nlcc build
→ 重新生成代码5. 代码审查（未来偶尔需要）
场景：性能不够
步骤1：看生成的代码
cat build/src/logger/impl.c
步骤2：找到性能瓶颈
→ 发现JSON序列化太慢
步骤3：选择优化策略
A. 修改AGENTS.md，明确性能要求（推荐）
B. 手工优化这一小段代码（极端情况）人类工程师的职责演化
现在（高级语言时代）
人类工程师的日常：
1. 设计系统架构（模块划分）
2. 定义接口（.h文件）
3. 实现逻辑（.c文件）
4. 调试、测试、优化
5. 维护代码（修复bug、添加功能）
6. Code Review时间分配：
- 架构设计：10%
- 写代码：60%
- 调试测试：20%
- 维护：10%
未来（AI时代）
人类工程师的日常：
1. 设计系统架构（模块划分）
2. 编写意图描述（AGENTS.md）
3. 审查AI生成的代码（偶尔，5%时间）
4. 处理AI搞不定的极端场景（1%时间）
5. 监控系统运行状态时间分配：
- 架构设计：20%
- 编写MD：30%
- 审查代码：5%
- 极端场景：1%
- 监控、优化、学习：44%
核心转变：
- 从"如何实现" → "要实现什么"
- 从"细节控制" → "意图表达"
- 从"代码维护" → "意图维护"
总结
核心观点
提示词也需要架构
- 不是零散的文本，而是有组织的MD文档
- AGENTS.md是唯一入口，skills是按需加载的细节
与代码架构完美对应
- 零循环依赖、清晰边界、单一入口
- 提示词描述意图，代码描述实现
技术演化的延续
- 机器码 → 汇编 → 高级语言 → 自然语言
- 每次抽象都降低程序员负担
- 代码的地位 = 今天汇编的地位
未来已来
- 自然语言编译器（NLCC）会出现
- 代码放在build/目录，成为一次性中间产物
- 人类只维护MD，就像今天只维护C代码
适用范围降低
- AI不会淘汰代码，就像高级语言不会淘汰汇编
- 但99%的场景不需要手工写代码
- 只有极端性能场景才需要
行动建议
现在就开始：
1. 选择一个小项目
2. 设计AGENTS.md架构
3. 编写模块级MD和skills
4. 用AI生成代码
5. 验证、迭代、优化
记住：
- MD是源码，代码是中间产物
- 维护MD，而不是代码
- 意图清晰 > 代码完美作者：twg2020
发布时间：2026-02-15
技术栈：AI架构、提示词工程、自然语言编程
标签：#AI架构 #提示词工程 #自然语言编程 #AGENTS.md
这是继《AI时代的代码架构》后的第二篇思考。核心观点是：在AI时代，提示词（自然语言）将成为新的源码，而代码将成为编译后的中间产物。 这不是科幻，而是编程语言演化的必然趋势。就像高级语言没有淘汰汇编，AI也不会淘汰代码——只是适用的范围会大大降低。欢迎交流讨论！
相关阅读：